Enterprise AI / 企業落地

企業內部搜尋的最佳成績只有 32.96 分——瓶頸不在模型,在檢索

賴家榮 Andy Lai - FULLDOT news 發表文章的作者
賴家榮 Andy Lai
FULLDOT news 總編輯 · SAIP-TAIWAN CAIO
2026-08-07 09:40:00 | 出處: Choubey et al., "Benchmarking Deep Search over Heterogeneous Enterprise Data", arXiv:2506.23139
企業內部搜尋的最佳成績只有 32.96 分——瓶頸不在模型,在檢索 | FULLDOT news
發表文章的作者 賴家榮 觀點劃重點

一份針對企業異質資料的檢索基準測試指出:即使是表現最好的 agentic RAG 方法,平均分數也只有 32.96。作者明確指出瓶頸在檢索——系統經常只拿到部分證據就開始推理。這解釋了為什麼很多企業知識庫「問簡單的還行、問複雜的就亂答」。

企業導入知識庫問答系統後,常見的回饋是:「問簡單的問題還可以,問複雜一點的就開始亂講。」

這個現象有量化的解釋。一份針對企業異質資料的檢索基準測試給出的結果是:即使表現最好的方法,平均分數也只有 32.96

先界定:企業搜尋跟網路搜尋不同在哪

Prafulla Kumar Choubey 等人的〈Benchmarking Deep Search over Heterogeneous Enterprise Data〉(arXiv:2506.23139,2025 年 6 月 29 日投稿)建立的測試環境,包含 39,190 件企業文件,涵蓋文件、會議逐字稿、Slack 訊息、GitHub 與網址。

作者指出這些來源「在結構上各不相同,且經常包含人與人之間的互動」。

這句話是關鍵。企業裡真正有價值的資訊,很多不在正式文件裡,而在對話中。「上次那個客戶的問題後來怎麼解決的」——答案可能散落在一段 Slack 討論、一份會議紀錄和一個 GitHub commit 訊息裡。

網路搜尋的資料是為了被閱讀而寫的;企業內部的資料是為了當下溝通而寫的。後者預設讀者已經知道背景。

機制:為什麼是檢索出問題

論文的診斷很明確:「我們強調檢索是主要瓶頸:現有方法難以進行深度搜尋並取得所有必要證據。因此它們經常在部分脈絡上進行推理,導致效能顯著下降。」

用查案的比喻最清楚:模型不是推理能力不夠,是證據沒收集齊就開始下結論。而且它不會告訴你證據不齊——它會用手上那三成的資料,很有自信地講出一個完整的答案。

這也是為什麼這類錯誤特別危險:答案聽起來完整且合理,看不出來缺了東西。

論文所測的是「多跳推理」——需要串連多個來源才能回答的問題。這正是企業實際會問的問題類型。

邊界:什麼情況下不會遇到這個問題

  • 單一來源、單一跳 「這台機器的扭力規格是多少」——答案就在手冊某一頁,檢索難度低。
  • 資料已經結構化 查詢 ERP 裡的訂單,那是資料庫查詢不是語意檢索。
  • 問題範圍窄且固定 常見問題集那類,可以事先驗證過。

會踩到的是:需要跨系統、跨時間、跨格式串連的問題。而這類問題往往正是導入知識庫最初想解決的痛點。

對台灣企業的意義

這份研究對正在建知識庫的企業有兩個直接推論。

一、驗收要用多跳問題,不能只用單跳問題。示範時問「保固期多久」看起來都很厲害,因為那是單跳。要測的是「A 客戶去年那批貨的異常,跟我們後來改的製程有沒有關係」——這需要串連客訴紀錄、製程變更單與品管報告。

二、投資順序應該是先修檢索,不是先換模型。這與我們在向量資料庫選型那篇的結論一致:檢索品質(切塊策略、混合檢索、重排序)的影響遠大於資料庫或模型的選擇。這份基準測試替那個判斷提供了量化依據。

另外值得注意的是「不可回答」的處理。論文的測試集同時包含可回答與不可回答的查詢。系統能不能誠實說「這個我查不到」,跟它能不能答對一樣重要——而多數企業在驗收時只測前者。

需要保留的懷疑

這份基準使用合成資料管線模擬企業工作流程,而非真實企業資料。作者的作法是生成互相關聯的內容與具備標準答案的多跳問題,這讓評估可控,但與真實環境仍有差距。

32.96 這個分數的計算方式與滿分基準,需查閱論文全文,本文未引述評分細節。不宜直接理解為「正確率 33%」——它是該論文定義下的綜合分數。

另外投稿日為 2025 年 6 月,模型能力在此期間持續變化,實際數字可能已有改善。但「檢索是瓶頸」這個結構性判斷,與多個獨立來源的觀察一致。

常見問題

為什麼企業知識庫問簡單問題可以、問複雜問題就出錯?

依 arXiv:2506.23139 的研究,主要瓶頸在檢索而非生成。系統難以完整取得所有必要證據,因此經常在部分脈絡上進行推理。簡單問題多為單一來源的單跳查詢,檢索難度低;複雜問題需串連多個來源(多跳推理),檢索不完整時模型仍會產出看似完整的答案,且不會提示證據不足。

驗收企業知識庫時該測什麼樣的問題?

應以多跳問題為主,即需要串連多個來源、跨系統或跨時間才能回答的問題,而非單一文件即可回答的單跳問題。此外應同時測試「不可回答」的查詢,確認系統能誠實表示查不到,而非勉強生成答案。多數企業驗收時僅測試可回答的問題,因而高估系統能力。

知識庫效果不好,該先換模型還是先修檢索?

依該研究的診斷,檢索是主要瓶頸。實務上應優先檢視切塊策略、是否採用關鍵字與向量的混合檢索、以及是否加入後段重排序。這些調整的投報率通常高於更換模型或向量資料庫。

下一步

建立自己的多跳測試題是最有效的驗收方式。可搭配上下文腐化那篇一起看——一個講證據收不齊,一個講收齊了也可能讀不仔細,兩者都會影響最終答案品質。

出處

本文引述出自 Prafulla Kumar Choubey、Xiangyu Peng、Shilpa Bhagavath、Kung-Hsiang Huang、Caiming Xiong、Chien-Sheng Wu〈Benchmarking Deep Search over Heterogeneous Enterprise Data〉,arXiv:2506.23139,2025 年 6 月 29 日投稿,arxiv.org/abs/2506.23139。加註引號者為論文摘要原文之中譯。

該基準採合成資料管線建構,非真實企業資料。32.96 為該論文定義下之綜合分數,非正確率百分比。

AI 講師 賴家榮 Andy Lai
專業 AI & 行銷講師

企業 AI 轉型、RAG 向量庫與數位行銷內訓 | 賴家榮 老師親授

樹德 / 輔英 / 屏東大學兼任講師!手把手帶領企業團隊打造專屬 AI 代理與高轉化品牌流量。

本篇文章出處來源聲明
MEDIA CITATION
原始發行媒體 Choubey et al., "Benchmarking Deep Search over Heterogeneous Enterprise Data", arXiv:2506.23139
發表文章的作者 賴家榮 Andy Lai