RIT-RAGが示す、文書の構造を地図にして探すAI検索の新しい形
ニュースの概要
arXivで、文書コーパス（＝AIが参照する文書の集まり）の構造を生かす新しいRAG手法「RIT-RAG」が公開された。従来のエージェント型RAGは文書を細かなチャンク（断片）に切って扱うため、本当に関連する箇所と、言葉が似ているだけの箇所を見分けにくく、文書全体の構造も失われやすい。RIT-RAGは、事前に目次やサイトマップから各文書のツリーを作っておく。質問が来ると、まず広い範囲でチャンク検索を行い、その結果をツリー上の位置に対応づけて探索の入口とする。AIはそこから構造をたどって必要な情報へ進む。断片の寄せ集めではなく、文書の地図を使って探す発想が特徴である。
引用元: 検索誘導型ツリーで文書コーパスを探索する新しいRAG手法「RIT-RAG」（arXiv）
分析・見解
断片検索が抱える「似ているだけの箇所」問題
従来のRAGは、文書を数百字ほどの断片に切り、質問と意味が近いものを取り出す。この方式は手軽だが、弱点がある。言葉が似ているだけで、実際には別の話をしている断片も拾ってしまうのだ。たとえば社内規程で「退職」という語が出てくる箇所は、退職金の計算、手続き、競業避止と何通りもある。断片だけ見ても、どの話題の一部なのか判断しにくい。
さらに、切り出した時点で「第3章の2節にある」という位置の情報が消える。人間なら目次を見て当たりを付けるところを、AIは目隠しで探すことになる。
検索結果を「ツリー上の入口」に変えるという発想
RIT-RAGの工夫は、検索を捨てずに使い方を変えた点にある。広めのチャンク検索で得た結果を、事前に作った文書ツリーのどこにあたるかに対応づける。つまり検索は答えを出す役ではなく、探索の出発点を示す役に回る。
ここが面白い。純粋な木構造の探索は、最初の分岐を誤ると戻りにくい。逆に純粋な検索は、構造を使えない。両者を組み合わせれば、検索の「広く拾う力」と、ツリーの「文脈を保つ力」を互いの弱点を補う形で使える。図書館に例えると、司書がまず棚の見当を付け、そこから利用者が目次をたどって本を開くようなものだ。
事前コンパイル型の流れと共通する設計思想
この手法は、当サイトで扱ってきたCorpus2Skillのような「文書を先に整理し、使う側が階層をたどる」流れとも相性が良い。オフラインで構造を作り、質問時は軽く動く。重い処理を前もって済ませておく設計は、運用コストを読みやすくする利点もある。
ただし課題も残る。目次やサイトマップが整っていない文書では、ツリーそのものの質が下がる。PDFのスキャン資料や、見出しが雑に付けられた社内文書は典型例だ。構造を使う手法は、構造の品質に成果が左右される。
評価は「精度」だけでなく「たどった道筋」でも見るべき
今後の注目点は、検索精度の数字だけではない。AIがどの順に節を開き、なぜその答えに至ったかが、ツリーの経路として残る。これは回答の根拠を人が検証しやすいという意味で、実務では大きな価値になる。誤答が出たときも、どの分岐で迷ったかを特定でき、改善の手がかりになる。
ビジネスへの影響
社内文書の「目次の質」がAI活用の成否を左右する
この流れは、企業にとって地味だが重要な示唆を持つ。構造を使うRAGが広がるほど、元文書の見出し設計、章立て、サイトマップの整備が、そのまま検索精度に直結する。AI導入のために高価な新ツールを買う前に、マニュアルや規程集の見出しを整える方が、費用対効果が高い場合がある。まずは問い合わせの多い文書から、見出しの粒度をそろえる作業を始めるとよい。
導入判断では「検証のしやすさ」を比較軸にする
ベンダー選定の際は、回答精度だけでなく、探索の経路を確認できるかを聞きたい。経路が見えれば、法務や経理のように根拠が重要な部署でも運用しやすい。小さな文書群でRIT-RAG型と従来型を同じ質問で比べ、正答率と確認にかかる時間の両方を測るのが現実的である。
なお、研究段階の手法を本番へ入れるには、更新頻度への対応も確認が要る。文書が頻繁に改訂される職場では、ツリーの再作成が運用の負担にならないかを、事前に見積もっておくべきである。