利用者の聞き方と、文書の書き方はふつう一致しません。1つの問いを言い換えて何度も検索し、結果を混ぜるのがマルチクエリです。
言い換えを0個から3個まで増やして測りました。1個足した時点がいちばん良く、3個に増やすと元の水準近くまで戻りました。
言い換えを0個から3個まで増やして測りました。1個の時点がいちばん良く、そこから増やすと下がります。
マルチクエリで言い換えを増やすと成績がどう動くのかを、実際に走らせて測りました。使ったのは社内規程を模した文書13件と、語が食い違う問い5件です。
言い換えは文書の中身を見ずに、聞き方だけを変えて用意しました。生成AIに作らせる部分を手で置いた形です。
const rrfN = (lists, k = 60) => {
const score = new Map();
for (const l of lists)
l.forEach((x, r) => score.set(x.i, (score.get(x.i) || 0) + 1 / (k + r + 1)));
return [...score.entries()].map(([i, s]) => ({ i, s })).sort((a, b) => b.s - a.s);
};
const qs = [q, ...VARIANTS[q].slice(0, nv)];
const ids = (nv === 0 ? bm25(q) : rrfN(qs.map((x) => bm25(x)))).map((x) => x.i);
やり方 適合率@3 再現率@3 nDCG@3 そのまま1つで検索 0.400 0.700 0.542 言い換えを1つ足す 0.533 0.900 0.845 言い換えを2つ足す 0.400 0.700 0.661 言い換えを3つ足す 0.400 0.700 0.661 問い そのまま 言い換えあり ホテル代の限度額 1 / 2 1 / 2 出張手当は日帰りだと 2 / 2 2 / 2 仮払の申請 2 / 2 1 / 2 消耗品の購入 1 / 1 1 / 1 レポートの提出期限 0 / 2 1 / 2
上の表を見てください。言い換えを1つ足した行がいちばん良いです。nDCGは0.542から0.845に上がりました。
ところが2つ目からは下がります。3つ足しても0.661で、1つのときの0.845には届きません。
適合率と再現率にいたっては、言い換えなしと同じ0.400と0.700に戻りました。増やした分の手間が結果に出ていません。
下の内訳が理由を示しています。報告書の問いは0件から1件に改善しました。ここは狙いどおりです。
一方で仮払の問いは2件から1件に落ちています。差し引きすると全体はほぼ動きません。
外した言い換えの結果も混ざるので、正解の順位が押し下げられます。言い換えを増やすほど、この押し下げが積み上がります。
1つ足した時点が頂点。2つ目からは下がる。
This can involve rewriting unclear queries, generating multiple variations, or expanding queries with additional context.原文Docs by LangChain「Retrieval」 この内容の有効期限2027-02-18
1つの問いから複数の言い換えを作り、それぞれで検索して結果を混ぜます。聞き方と書き方の食い違いを埋めるための手立てです。
マルチクエリは、1つの問いを言い換えて何度も検索し、結果を混ぜる手法です。
利用者は「ホテル代」と聞きますが、規程には「宿泊費」と書いてあります。語が違うと、語で探す検索は見つけられません。
LangChainの文書も、検索の前段として入力された問いを変えて検索の質を上げるという手立てを挙げています。マルチクエリはその一種です。
同じ文書には、不明瞭な問いを書き直したり、複数の言い換えを作ったり、文脈を足して広げたりすることが含まれると書かれています。3番目の広げる方はクエリ拡張の記事で扱っています。
混ぜる部分は順位の逆数を足す方式を使いました。複数の検索で上位に来た文書ほど、混ぜたあとも上に来ます。
この性質があるので、外した言い換えが増えると正解が沈みます。前の節で3個に増やしたときに下がったのは、この混ぜ方の性質がそのまま出たものです。
測ってみて分かったのは、言い換えなしの成績を先に取っておかないと判断できないということでした。0.845という数字だけを見ても良し悪しは決まりません。0.542という出発点があって初めて、1個足す価値があると言えます。そして3個の0.661を見て、そこで止める判断ができます。
Query enhancement: Modify the input question to improve retrieval quality.原文Docs by LangChain「Retrieval」 この内容の有効期限2027-02-18
検索の回数が言い換えの数だけ増えます。加えて言い換えを作る生成AIの呼び出しが1回入ります。
マルチクエリを入れると、問い1件あたりの処理が増えます。何が増えるのかを分けて見ます。
前の節の計測では、検索の回数が5回から20回になりました。言い換え3つで、問い5件ぶんです。
言い換えの数をnとすると、検索はn+1倍になります。検索基盤の負荷はそのまま比例します。
言い換えを作る呼び出しが、検索の前に1回入ります。この1回は利用者を待たせる時間に直接乗ります。
LangChainの文書は、段が決まった構成について生成AIの呼び出し回数の上限が分かるので、応答時間が読みやすいとしています。マルチクエリは呼び出しが1回増えますが、回数自体は決まったままです。
前の節の実測では、言い換え1個で検索が2倍、nDCGは0.542から0.845でした。ここは見合っています。
3個に増やすと検索は4倍ですが、nDCGは0.661です。4倍払って、1個のときより悪いという結果になりました。
検索回数は言い換えの数に比例して増える。成績は比例しない。
Latency is generally more predictable in 2-Step RAG, as the maximum number of LLM calls is known原文Docs by LangChain「Retrieval」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る