アーカイブ / RAG / LLM
文書索引を作り直さず社内検索を改善する――質問側だけを調整する方法
DevRev Search / Index-Preserving Query Adaptation
概要
- 複数の検索器と言語モデルの判定を組み合わせ、技術サポート検索の関連性データを作る。
- 文書索引を固定し、質問側の変換器だけを調整する方法を評価した。
- DevRev Searchでは質問側のみの調整が両側調整を上回り、SciFactでは両側調整との差が1～2%以内と報告された。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、DevRev Search / Index-Preserving Query Adaptationの仕組み
- 01問い合わせと文書
- 02複数検索器で候補収集
- 03関連文書を判定
- 04質問側のみ調整
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
社内検索には問い合わせ履歴と文書が多くあっても、「この質問にはこの文書が役立つ」という関連性の印が不足しやすい。検索モデルを業務向けに調整しようとしても、質問と文書の両方の変換器を更新すると、保存済み文書の検索用索引を作り直す必要がある。
複数の組織や部門が別々の索引を持つ場合、この更新作業は重くなる。研究は、関連性データの作成と、索引を保ったまま行う調整を組み合わせる。
手法
まず実際の問い合わせから不自然な質問や重複を除く。語の一致を見る検索器と、文章を数値の並びに変えて意味の近さを見る検索器を合わせ、各質問の候補文書を広く集める。言語モデルが、質問への回答に役立つ内容を持つ候補を選び、学習用の質問と文書の組を作る。
次に、質問を検索用の数値へ変える側だけをLoRAで調整する。LoRAは元のモデルの大部分を固定し、少数の追加パラメータを学習する方法である。文書側の数値と索引は保持するため、例えば「接続が切れる」という問い合わせに合う既存文書を探す設定を変えても、全書類の変換をやり直さずに済む。
新規性
著者らは二つの課題を一つの手順で扱う。まず、複数の検索器が集めた候補文書を言語モデルで絞り、技術サポート向けの関連性データを自動作成する。次に、そのデータで質問側の変換器だけを調整し、文書側の索引を固定する。
複数の組織が別々の索引を持つ環境では、文書側を更新するたびに全件を再処理する負担がある。質問側だけの調整は、この更新範囲を小さくする提案である。
従来手法との違い
比較の基準は、調整前の検索器と、質問・文書の両方の変換器を調整する方法である。著者らのDevRev Searchでの実験では質問側だけの調整が両側調整を上回り、SciFactでは両側調整が上回ったものの、差は1～2%以内だったと報告する。
この関係はデータやモデルに依存する。著者らは調整する層やLoRAの設定も比較し、最適な組み合わせがモデルとデータセットによって変わることを示している。
実験結果
著者らは技術サポートのDevRev Searchと、科学文献のSciFactで検索を評価した。DevRev Searchは一質問あたり平均13.6件、SciFactは平均1.1件の関連文書がある。検索上位十件に関連文書が入る割合を示すRecall@10で、調整前、質問側のみ、両側調整を比較した。
本文で確認できる範囲では、DevRev Searchでは質問側のみが両側調整を上回り、SciFactでは両側調整との差が1～2%以内と報告される。正確な各条件のRecall@10の数値は示された本文にないため、効果の大きさを一律の値として扱えない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：複数部門の技術問い合わせ検索に使う。入力は問い合わせ文と、既に索引化された各部門のサポート文書。出力は回答の根拠となる文書の上位候補とする。
問い合わせ履歴から質問を選び、既存の文書索引を固定したまま質問側の変換器を部門ごとに調整する。例えば製品名の略称を含む問い合わせで関連文書が上位に来るかを確認し、回答文の生成は別の工程として評価する。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：一部門の問い合わせと文書から、担当者が関連文書を確認した小さな評価集合を作る。現行検索を基準に、同じ固定索引で質問側だけを調整した検索器を試す。
Recall@10に加え、上位候補に誤った製品の文書が混ざる割合、索引更新に要する時間、未見の問い合わせでの成績を測る。自動で付けた関連性ラベルも一部を人が確認し、学習データの誤りが改善を見かけ上のものにしていないか調べる。
限界と課題
著者らは、評価が英語の問い合わせと限られた分野に留まり、他分野や多言語への一般化は未確認と述べる。質問側だけの調整には両側調整に対する性能の上限がありうる。また、再順位付けとの組み合わせや、検索を使った回答生成の成果は直接測っていない。
編集上は、言語モデルによる関連性ラベルの誤りと、部門ごとの専門語が検索結果に与える影響を調べたい。索引を固定できる利点があっても、問い合わせに必要な根拠が上位に現れるかは別途確かめる必要がある。
出典
元のタイトル・要旨を確認する（英語）
Succeeding at Scale: Enterprise Retrieval Benchmark Construction and Index-Preserving Query Adaptation for Multi-Tenant Search
Large-scale multi-tenant retrieval systems generate extensive query logs but lack curated relevance labels for effective domain adaptation, resulting in substantial underutilized "dark data." This challenge is compounded by the high cost of model updates, as jointly fine-tuning query and document encoders requires full corpus re-indexing, which is impractical in multi-tenant settings with thousands of isolated indices. We introduce DevRev-Search, a passage retrieval benchmark for technical customer support built via a fully automated pipeline. Candidate generation uses fusion across diverse sparse and dense retrievers, followed by an LLM-as-a-Judge for consistency filtering and relevance labeling. We further study and systematically evaluate index-preserving query-only adaptation strategies that fine-tune only the query-encoder while keeping the document indices fixed. Experiments on DevRev-Search, SciFact, and FiQA-2018 show that parameter-efficient fine-tuning of the query encoder delivers a remarkable quality-efficiency trade-off, enabling scalable and practical enterprise multi-tenant retrieval.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-09-30