小編精選 - 技術文章翻譯 · 11月04日

新的 RAG「Decision RAG」速度快！便宜！又好用！🍜

⚖️ 前言

最近像 Jev 這類專門用於判斷的模型陸續出現了呢。不需要生成文章，只會回傳「是」的可信程度。最近有篇論文提出把這種判斷模型拿來做 RAG 的檢索，叫做「DecisionRAG」，所以我就用自己的方式消化整理了一下。後半段也和一般的 RAG（以下記為 NaiveRAG）做了比較驗證。

🎯 目標讀者

熱愛 RAG 的人
對判斷模型有興趣的人
對向量搜尋的精準度不滿意的人

😢 傳統 RAG 的問題點

NaiveRAG 會透過關鍵字匹配或向量相似度來找文件。這種搜尋常常會撈到多餘的內容，或漏掉真正的答案。搜尋階段漏掉的答案，無論 LLM 再怎麼聰明也補不回來。那麼就把 LLM 等級的智慧帶進搜尋吧！！這就是 DecisionRAG 的想法。話雖如此，若在搜尋時使用 LLM，成本和時間都會增加。正當大家為此苦惱時，就出現了判斷模型（Decision Model）。那就把它拿來用在搜尋上吧。

📚 階層式追蹤

大家去圖書館找書時，不會一本一本把所有書都翻開吧？通常會先從電影區→導演的書架→作品，一層一層縮小範圍。DecisionRAG 也是一樣，先把文件做成樹狀結構，再由各層的判斷模型決定「要開哪個書架」。因為被捨棄的書架內容完全不看，所以即使文件量龐大也能很快，這就是它的機制。

⚡ 聰明卻很快！

NaiveRAG 很快，但常常只因為語意接近就撈到不是答案的內容。AgenticRAG 雖然因為 LLM 會反覆搜尋而很聰明，但速度慢、成本高。GraphRAG 則能沿著人或物的關聯追蹤，但要建立圖結構很麻煩。

DecisionRAG 讓判斷模型不輸出文章，只輸出可信度。因此就能用接近 NaiveRAG 的速度，發揮 AgenticRAG 的智慧。

🗂️ 在搜尋前先將文件整理成階層

DecisionRAG 的前提是資料本身具有像「類別 → 文件 → chunk」這樣的階層。若是手冊或公司內部 Wiki，只要把資料夾或標題直接當成階層即可。若是沒有結構的資料，論文中則是先用分群把資料分成群組，再讓 LLM 為各群組撰寫說明文字。

🔁 搜尋方法

取得階層資料的子層資訊
由判斷模型比對問題與子層說明文字並給出機率
只保留前 k 筆（top-k），進入下一層

重複這個流程直到最底層，最後把留下的 chunk 交給生成用 LLM 就可以了。

🧪 實際驗證！真的做出來量測看看

前面一直在解說論文，但總會想：「真的有這麼美的事嗎？」所以我實際做出來量測看看。

🌐 範例網站

歡迎到這個也用於驗證的網站，親自體驗速度與精準度。

如果流量集中，畫面可能會顯示「流量集中中」並停止，敬請見諒🙇‍♂️

🏗️ 驗證環境

DecisionRAG 使用判斷模型 Jev（jev-1.14.0），並把階層放在 DynamoDB 中。NaiveRAG 則是用 Titan v2 做嵌入，從 S3 Vectors 檢索，再用 Cohere Rerank 3.5 做重新排序。兩者的回答模型都是 Claude Haiku 5.5。

🌲 測試資料與階層

文件發行來源　chunk 數量　模型
就業規則　厚生勞動省　77
育兒・介護休業等相關規則的規定範例　厚生勞動省　51
法令 11 部（勞動基準法等）　e-Gov 法令 API　805
法令修訂通知　根據 e-Gov 的修法履歷製作　65

DecisionRAG 必須有階層結構（樹狀）才能運作。這次將約 1000 個 chunk 分成 4 個階層：大分類（8）→ 文件（31）→ 章（120）→ 條（998）。

📝 評估方式

我把各種不同類型的問題打亂順序，做了 3 輪驗證。

種類　題數　例子
直白查詢　12　新錄用員工的試用期是幾個月？
改寫查詢　12　爺爺的喪禮時要請假，公司能休幾天？
多跳查詢　12　如果是自己提出離職，最晚要提前幾天提出？另外，公司要解雇員工時，法律規定要提前幾天通知？
數值型　8　課長的職務津貼每個月多少錢？
時間型　10　請告訴我上個月刊登的所有公告。
無法回答　10　員工餐廳的每日定食多少錢？

評估指標的意義
指標　定義
Hit@1　第 1 名的 chunk 是否正確
Recall@5　交給回答 LLM 的 chunk 中，包含正解的比例
TTFT　從送出問題到收到回答第一個 token 為止的時間
Cost　每個 query 的費用（USD）

📊 結果

方式　Hit@1　Recall@5　TTFT　Cost/query
DecisionRAG　0.91　0.91　1.63 秒　$0.0013
NaiveRAG　0.72　0.78　1.65 秒　$0.0024

這次驗證中，DecisionRAG 在各方面都勝過了 NaiveRAG。

還不能說它比 NaiveRAG 更快。標題中的「快！」請理解成和 NaiveRAG 差不多快的意思。

成本內訳中，DecisionRAG 的 Jev 花費為 $0.0011，回答花費為 $0.0002。NaiveRAG 則是 Rerank 花費 $0.0020，回答花費 $0.0004。其實 NaiveRAG 的費用大多都花在 Rerank 上了……

各類型查詢的 Hit@1 如下。

種類　DecisionRAG　NaiveRAG
直白查詢　0.97　0.92
改寫查詢　0.92　0.58
多跳查詢　0.78　0.75
數值型　0.96　0.75
時間型　0.96　0.56
無法回答　0.90　0.77

尤其在改寫與時間型問題上差距特別大。

🤔 DecisionRAG 要採用嗎？

我認為最大的優點是對改寫問題很強。而且變得更聰明了，成本卻幾乎砍半。另外，因為每個階層都會留下分數，所以之後可以追查是在哪一層掉下去的，也更容易調校，這點也很不錯。對於因為表達方式或措辭不同而一直無法做出好精準度的向量搜尋，我認為很有效。反過來說，如果向量搜尋本來就有足夠的精準度，或是沒有使用 Rerank 的情況，導入的好處就比較薄弱。

🌱 階層的新鮮度決定回答品質

我認為 DecisionRAG 的關鍵與其說是搜尋，不如說是階層建構。文件會日積月累地增加，所以需要定期整理分類。搜尋時交給判斷模型，人的重點則放在資料分類的維護上。若在新增資料時，也讓判斷模型先分辨「這比較像既有的書架？還是需要新書架？」就不必每次都由人工判斷，而能在適當時機進行調整。維持階層的新鮮度，會直接反映在回答準確度上。

階層資料要由 LLM 建立，還是由判斷模型建立，做法有很多種，但無論如何都會產生成本。這個成本並沒有算進這次驗證的數字裡。若要採用，建議把階層建構的運作與成本也一併納入評估。

🍜 總結

把搜尋交給判斷模型後，精準度比 NaiveRAG 更高，成本則幾乎減半。速度也差不多。雖然標題寫得像「快、便宜、好用」的萬能 RAG，但像 GraphRAG 那種把搜尋結果再接到下一次搜尋的 hop 型搜尋，我認為它還是不太擅長。其他方面也可能會依資料或問題而有適合與不適合的情況。因為成本低，建議先小規模驗證，再考慮導入。

我認為 DecisionRAG 的出現，抓成「RAG 的選項又多了一個」這樣的理解就剛剛好。

RAG 常常會處理機密性很高的資料，因此像 Jev 這類外部 API 有時不太好使用。如果是像 Strands Decider2B 這種可以在自家環境中執行的模型，就能避免把資料送出外部，但因為要讓伺服器持續運作，並不是只按使用量計費。希望像 OpenAI 的 Decisions API 這種按量計費的判斷模型，也能由大型雲端廠商推出呢。

原文出處：https://qiita.com/kikuziro/items/cc82e6e4e4c215eac99f