【検索勉強会2024春】RAG改善からみたクエリ・ドキュメント理解とリランキング

2024年5月31日の「Search Engineering Tech Talk 2024 Spring」で登壇発表した資料です
https://search-tech.connpass.com/event/318126/

Transcript

1. Search Engineering Tech Talk 2024 Spring 2024年5月31日(金) FRAIM株式会社 水野多加雄 RAG改善からみたクエリ・ドキュメント理解 とリランキング
2. ©2024 FRAIM Inc. All Rights Reserved. 会社概要・自己紹介 2 開発部ML Unit責任者 水野 多加雄(@mzntaka0) 社名　 所在地 連絡先 設立日 代表者 事業内容 Webサイト FRAIM株式会社　/　FRAIM Inc. (旧: 株式会社日本法務システム研究所 ) 東京都渋谷区千駄ヶ谷5-17-14 MSD20ビル5階 sales_team@fraim.co.jp 2018年4月27日 堀口 圭(代表取締役社長 弁護士) クラウド ドキュメント ワークスペース LAWGUE の研究・開発・提供 https://lawgue.com/ Forbes Under 30 Asia 2021 Enterprise Technology 部門 三菱UFJ銀行主催 2021年 第8回 Rise Up Festa DX部門 最優秀企業賞 主に自然言語処理・検索 /Elasticsearch、 バックエンドその他機械学習関連の開発担当 開発環境: Vim/tmux(とJupyterLab) 2017年から機械学習エンジニアとしてインバウンド向け記事の文 章要約・分類、Elasticsearch検索システム開発、 NEDOプロジェク ト(文書解析)、デジタル庁法制事務デジタル化、百貨店での人流 解析、病院向け音声認識 /OCRシステム、Tokyo Girls Collection のAI審査員、など複数機械学習のプロジェクトでの研究・開発に従 事
3. 弊社プロダクト - LAWGUEの概要・RAG実装
4. ©2024 FRAIM Inc. All Rights Reserved. 弊社プロダクト - LAWGUEの概要 4 独自エディタとドキュメントに関する様々な提案・レコメンド機能を提供し、ユーザーのナレッジ活用・ドキュメント作成を支援 している。
5. ©2024 FRAIM Inc. All Rights Reserved. 弊社プロダクト - LAWGUEの概要 5 独自エディタとドキュメントに関する様々な提案・レコメンド機能を提供し、ユーザーのナレッジ活用・ドキュメント作成を支援 している。そ れらの機能を支える基盤としてElasticsearch(on Elastic Cloud)を利用中。 主に検索・機械学習技術を活用している機能
6. ©2024 FRAIM Inc. All Rights Reserved. これまでの検索改善 6 実施例 • ベクトル検索を Elasticsearchに移行した ◦ 全文検索で活用していたElasticsearchを活かしてベクトル検索を実施することで、コスト削減、 ベクトル検索×フィルタリング等の検索技術連携の容易化が実現した • Elasticsearchのトークナイザを Sudachiに移行した ◦ ユーザークエリ要望に対してRecallが向上し、喜んでもらえた ▪ 正規化により表記揺れに強くなった ▪ 誤字をある程度吸収してくれる ▪ 数字表現に強くなった ▪ 固有名詞表現（会社名等）の抽出精度向上　など • 完全一致検索や AND/OR/NOT検索を実装した ◦ 詳細検索したいユーザーの要望を実現し、カスタマーサクセスに貢献できた →これらを含む種々施策が、後述のRAGの実装効率や精度向上に寄与する部分もあった
7. ©2024 FRAIM Inc. All Rights Reserved. 自社ナレッジを根拠とした RAG機能の構築 7 2023年3月末にLAWGUEとChatGPT連携をリリースし、その後さらに自社組織アカウントにアップロードしたナレッジ(契約書、社内規 程、その他任意のドキュメント)を根拠に、生成AIで質問回答するRAG機能をリリースした https://lawgue.com/news/3914/ https://lawgue.com/news/4754/
8. ©2024 FRAIM Inc. All Rights Reserved. (参考)RAGについて 8 RAG(Retrieval Augmented Generation)は、LLMだけではもっともらしい嘘（Hallucination）を生成してしまう課題に対して、Retrievalを組み合 わせることで根拠ドキュメントに記載されている情報(事実)に基づいた回答を生成する試み 複数パターン検索した結果のランキングをマージしたりリランキングしたりするRAG Fusionという考え方もある https://storialaw.jp/blog/9916 https://towardsdatascience.com/forget-rag-the-future-is-rag-fusion-1147298d8ad1 RAGの仕組み RAG Fusion
9. ©2024 FRAIM Inc. All Rights Reserved. (参考)RAGのデモ作成 9 2023年5月末にRAGを使ったデモを作って、ユーザーヒアリングを進めた(当時は chatgpt-retrieval-pluginをElasticsearchに繋いでお手製Frontendで検証した)
10. RAGの課題と クエリ・ドキュメント意図、リランキングを用いた改善
11. ©2024 FRAIM Inc. All Rights Reserved. RAGで生じた課題 ①適切なドキュメントが根拠の上位に来ない場合がある 例) たまたま同じキーワードが含まれる関係のないドキュメントがランクしてしまった ②ユーザーのクエリ意図に合った回答ができていない場合がある 例) 類似のドキュメントを出してほしいのに、テキスト回答が返ってきた 用語定義を聞いているのに、関連のオペレーション方法が返ってきた (結論) →RAGの新たな課題というよりは、検索や質問応答・対話タスクで従来から分析・改善が行わ れてきた課題 (の一部または関連 )であることがほとんどの認識 →過去の文献・研究を参照しつつ、粛々と改善を進めていくことが重要であると考える ユーザー検証やヒアリングを重ねた結果、目立った課題として以下2つが挙げられた （他にも細かい話は様々ある)
12. ©2024 FRAIM Inc. All Rights Reserved. RAGで生じた課題 ①適切なドキュメントが根拠の上位に来ない場合がある ②ユーザーのクエリ意図に合った回答ができていない場合がある 本日は、以下のような改善策を念頭に試行錯誤の一部を共有します (勉強会用にデータセットを例示として作成、主に会社規程データ) • クエリ・ドキュメント理解による適切な根拠マッチング • リランキングによる候補ドキュメントの精査 今回の解決時の制約条件 • tokenをなるべく消費しない ◦ ビジネスモデルにもよるが、tokenの消費とコストが比例するためなるべく少なく済むような 工夫が必要 ◦ 別途、LLM(プロンプト) API or ローカルモデルでどちらがコスト安か要検証 ◦ 現状は、ローカルモデル(個別タスクモデル)の方が安い試算 • 回答生成時のトークン制約の中で、高精度で上位に根拠ドキュメントを持ってくる必要がある (Top@5~10程度を想定)
13. ©2024 FRAIM Inc. All Rights Reserved. 参考書籍 色々な本や論文を参照する中で、特にRAG関連で紹介・お薦めしたい本 「自然言語処理シリーズ 2　質問応答システム 」 • 2009年発行の読み尽くされている本だが、今改めて読むと質問応答タスクの分析が 詰め込まれており、RAG改善に困っている人のヒントになりそう • 改善のための仮説を立てた時に、もう一度振り返って該当する過去研究を探すス タート地点に良いかもしれない →現在の技術とうまく組み合わせることで、改善の兆しが見える可能性がある https://www.coronasha.co.jp/np/isbn/9784339027525/ 以下の分類を大枠として、自然言語インターフェス、自然言語検索やその他検索関連の話まで RAGに通ずる話 が多数含まれている • ファクトイド型 (穴埋め問題 ) ◦ 回答が人名、地名、組織名、値段、日時、距離など短い言葉で簡潔に表されるものに限定 • ノンファクトイド型質問応答 (記述型問題 ) ◦ 定義型質問回答 ◦ why型質問回答 ◦ how型質問回答
14. ©2024 FRAIM Inc. All Rights Reserved. RAG改善の検討 14 Query Routing/Natural Language Understanding 方策1: 分類モデル作る 方策2: ReActを使う etc Agent3 (Knowledge Q&A) Agent4 (Similarity Search) Elasticsearch or Knowledge Graph Agent5 (Full-text Search) Response Request Agent1 Meta Question LLM(共通/個別タスクごとに調整したモデル) 方策1: Azure OpenAI 方策2: ローカルLLM Elasticsearch (Vector DB) Elasticsearch Knowledge Reranking/Refinement/Fact Checking (Cross Encoder, JaColBert) Agent2 Document-Level Tasks(*) (Summarization, Check/Validation…) Elasticsearch Query Understanding Retrieval Reranking • Userがどのような要望・結果を望んでいるかを認識し、どの Agent(タスク)に流すと最適な結果が得られそうか推定する • Retrieval時の精度向上のためのメタデータを抽出する Userの要望に沿ったナレッジリソースを探 索・発見する Userの要望を満たす根拠かどうか確認・ 検証・精緻化する Generation 質問に沿った回答を生成する Agent6 (Fact/Template -based Text Generation) Elasticsearch or Knowledge Graph 自然言語インターフェス (NLI)を用いたタスク実行の設計　※ユーザーニーズや UXの観点から、NLIが適切かは個別検討が必要 ドキュメント登録・理解が別途必要 Elasticsearch
15. ©2024 FRAIM Inc. All Rights Reserved. RAG改善の検討 15 Query Routing/Natural Language Understanding 方策1: 分類モデル作る 方策2: ReActを使う etc Agent3 (Knowledge Q&A) Agent4 (Similarity Search) Elasticsearch or Knowledge Graph Agent5 (Full-text Search) Response Request Agent1 Meta Question LLM(共通/個別タスクごとに調整したモデル) 方策1: Azure OpenAI 方策2: ローカルLLM Elasticsearch (Vector DB) Elasticsearch Knowledge Reranking/Refinement/Fact Checking (Cross Encoder, JaColBert) Agent2 Document-Level Tasks(*) (Summarization, Check/Validation…) Elasticsearch Query Understanding Retrieval Evaluation • Userがどのような要望・結果を望んでいるかを認識し、どの Agent(タスク)に流すと最適な結果が得られそうか推定する • Retrieval時の精度向上のためのメタデータを抽出する Userの要望に沿ったナレッジリソースを探 索・発見する (今回は話さない) Userの要望を満たす根拠かどうか確認・ 検証・精緻化する Generation 質問に沿った回答を生成する (今回は話さない) Agent6 (Fact/Template -based Text Generation) Elasticsearch or Knowledge Graph 本日はこの辺のお話 Elasticsearch 自然言語インターフェス (NLI)を用いたタスク実行の設計　※ユーザーニーズや UXの観点から、NLIが適切かは個別検討が必要 ドキュメント登録・理解が別途必要
16. ©2024 FRAIM Inc. All Rights Reserved. RAGの改善策(質問応答時 ) 16 Query Understanding Retrieval ※自社ベクトルモデルを利用 Evaluation Query Search Result Task example Model/tool example Natural Language Understanding(Joint/Multi-task) • Intent Classification • Slot Filling • JointBERT • DIET etc Query(Intent) Classification • SetFit, Fastfit, Semantic-Router(LLM) etc NER • BERT-CRF • LUKE • SpaCy(tool) • DSPy(LLM, tool) etc Query Extension / Rewriting • HyDE(LLM) • Synonym Dict, Wordnet etc Text2SQL(DSL/RDF) https://github.com/eosphoros-ai/Awesome-Text2S QL?tab=readme-ov-file https://arxiv.org/abs/2309.17122 Query Understanding Task example Model/tool example Reranking • japanese-reranker(Cross Encoder) • (Ja)ColBERT • etc Evaluation
17. ©2024 FRAIM Inc. All Rights Reserved. RAG改善の検討 (文書登録時 ) 17 Metadata Extraction (Document Chunking) etc Search Engine/Vector Store (Elasticsearchなど) document Task example Model/tool example Chunk Classification • SetFit, Fastfit, Semantic-Router(LLM) etc NER • BERT-CRF • LUKE • SpaCy(tool) • DSPy(LLM, tool) etc Metadata Extraction そのほか、Text Summarization、Triple Extraction(Knowledge Graph) etc
18. Chunk Classification
19. ©2024 FRAIM Inc. All Rights Reserved. 【Chunk Classification】SetFit(2022) 19 SetFitによるFew-shot learningをintfloat/multilingual-e5-baseをベースに実施 クラスごとのデータが少量(~60程度)の時に有利 https://arxiv.org/pdf/2209.11055 https://medium.com/@meetgandhi586/comparing-setfit-fastfit-and-semantic-router-fin ding-the-best-nlp-chatbot-intent-detection-d8161a7ad117
20. ©2024 FRAIM Inc. All Rights Reserved. 【Chunk Classification】データセットの構築 20 • サンプル規程データセットのChunkごと(正確には意味単位になりそうな項の単位)以下の8ラベルのいずれかを 付与 この規程で稟議とは、職制に基づく主管部の各担当者が所 管事項または受命事項の業務処理に際し、自己の責任権限 事項を超える事項および重要事項について、これを実施に 移すにあたり事前に決裁権者に決裁を求めることをいう ✅ label_1 label_2 label_3 … label_8
21. ©2024 FRAIM Inc. All Rights Reserved. 【Chunk Classification】アノテーションツールについて 21 • 300~400件程度のアノテーションを実施した(数時間~1日) • 今回は、doccanoを主に利用し、label studioも少し試した ◦ 細かい話で、doccanoはスマホでもアノテーションしやすくてよかった ◦ 一方、label studioの方がSlot Filling and Intent Classificationやその他 LLM周りのアノテーションも充実していて良誘う • prodigy, Argillaといったactive learning系ツールも検証予定 https://github.com/doccano/doccano https://labelstud.io/ https://prodi.gy/ https://docs.argilla.io/en/latest/index.html
22. ©2024 FRAIM Inc. All Rights Reserved. 【Chunk Classification】SetFitでfinetuning前後のデータ分布 22 UMAPで3次元に次元削減し、finetuning前(左)とfinetuning後を視覚的に定性比較 finetuning後で、明らかにデータがまとまっている
23. ©2024 FRAIM Inc. All Rights Reserved. 【Chunk Classification】SetFit多クラス分類の評価 23 テストデータのクラスごとの偏り、データ数過少などあり評価しきれない部分もあるが、 ベースラインモデルとしてサクッと作るのには悪くなさそう label_1 label_2 label_3 label_4 label_5 label_6 label_7 label_8
24. ©2024 FRAIM Inc. All Rights Reserved. 【Chunk Classification】まとめ 24 • SetFitなどの少量のデータである程度の精度を出すには良さそう • アノテーションの効率化・半自動化のベースモデルに使えそう ◦ Active LearningやHuman in the loopへの応用 • (本当は、Query (Intent) Classificationもやった上でドキュメントを絞り込み、精度 向上するかを検証した結果も出したかった) • クエリ・ドキュメント理解の一つの手法として色々応用がありそう
25. Reranking
26. ©2024 FRAIM Inc. All Rights Reserved. 【Reranking】Cross Encoderについて 26 https://www.sbert.net/examples/applications/cross-encoder/README.html Bi-Encoder: あらかじめSentence A, Bのベクトルを生成し、その後にベクトル類似度を測る Cross-Encoder: Sentence A, Bを[SEP]などで連結してモデルに渡し、[0, 1]の類似度を出力する 精度: △ 速度: ◯ 精度: ◯ 速度: △ Vector Searchに利用される ことが多い Rerankingに利用されること が多い Bi-Encoderで絞って、 Cross-Encoderで精緻化するイメージ
27. ©2024 FRAIM Inc. All Rights Reserved. 【Reranking】japanese-reranker 27 Cross-Encoderベースモデルを日本語データセット(JSQuAD等)を用いて学習させたもの Bi-Encoderでの約550万件でのベクトル検索結果@100をxsmallでrerankingした結果、精度(acc@1~10)向上が見 られた https://secon.dev/entry/2024/04/02/080000-japanese-reranker-tech-report/ Cross-Encoderベースモデル xsmallでのreranking結果
28. ©2024 FRAIM Inc. All Rights Reserved. 【Reranking】japanese-rerankerを検証してみた 28 検証用に簡易的な規程の質問応答データセットを作成 複数サンプル規程のChunkから質問文をLLMで生成し、そのChunkを根拠として紐づける Chunk Chunk Chunk Document ①〜可能ですか？ ②〜とはなんですか？ ③〜教えてください etc LLM ①Chunk文に基づいた質問文を3つずつ生成 ②生成した質問文の根拠として生成元 Chunkを紐 づける 根拠 • 生成された質問が必ずしもChunkを根 拠とするものとは限らないが、根拠にな りやすいものは生成されるだろうという 仮定 • 質問に対してrelevantなdocumentは1 件 • 自分のドメインでざっくり検証したい時 に使えるかも？ • あくまでお試し ※LLMに生成データ商用利用不可など制約があるものの 場合は注意が必要 →1,000件程度のデータセットを作成した
29. ©2024 FRAIM Inc. All Rights Reserved. 【Reranking】japanese-rerankerを検証してみた 29 ランキング評価ライブラリのranx(便利)を利用して、Bi-EncoderでTop@30を取得後にjapanese-reranker未実施・ 実施後にTop@10でどうなるか評価した relevantなdocumentが1件でも評価できそうなHit RateとMRRが本命の指標で、あとは参考値(適合性スコアは5に 設定) (Bi-Encoderで得たTop@30での参考指標結果) Top@30からreranking未実施・実施(上が未実施、下が実施)後にTop@10に絞って評価
30. ©2024 FRAIM Inc. All Rights Reserved. 【Reranking】まとめ 30 • Cross-EncoderベースのRerankingでRAGの根拠ドキュメント選定の精度 改善につながりそうな示唆が得られた • JaColBERTも試したい • モデルサイズによって処理速度が異なり、本番でどこまでどのモデルで ワークするかを検証する必要がある。モデル量子化やONNX/torch-ortな どで速度改善が可能か今後検証
31. ©2024 FRAIM Inc. All Rights Reserved. まとめ 31 • RAGをユーザー含めて検証した結果いくつか課題がみつかった • RAGの新たな課題というよりは、検索や質問応答・対話タスクで従来から分析・改善が行われ てきた課題(の一部または関連)であることがほとんどの認識であり、過去の文献・研究を参照し つつ、粛々と改善を進めていくことが重要であると考える • 既存の手法ではあるがRAG改善に利用できそうなモデルや手法をいくつかサンプルデータを用いて 試行錯誤した結果を共有した • 今後特にクエリ・ドキュメント理解の部分に力をいれて改善していきたい
32. THANK YOU !