專案 · 實驗研究
企業 RAG 評估
用一系列實驗拆解企業 RAG 在檢索、回答與評估上的失敗原因。
這個專案在做什麼
企業做 RAG 時，很容易先選向量資料庫、Embedding 或框架，卻沒有先確認資料是否真的需要檢索。這個專案用 200 份文件與 20 個問題建立 Baseline，再逐步找出檢索失敗發生在哪裡，最後只改動有證據支持的環節。
常見做法先建 RAG，再看答案像不像分數不理想時同時換模型、切分、檢索與提示，很難知道哪個改動真正有效。
這次做法先跑 Baseline，再診斷單一失敗點用固定問題比較方法，標記取回內容，控制變因後才進行優化。
從「要不要做」到「哪裡需要改」
實驗順序先確認長內容、關鍵字搜尋和 RAG 各自能做到什麼，再用人工標記的檢索結果定位問題。
階段做了什麼得到的結果
Baseline比較關鍵字搜尋與直接塞入不同數量文件59 / 88 / 93 分
RAG v1建立基本檢索流程，以相同問題測試77 分
診斷20 題 × 每題前 5 段，共標記 100 個檢索片段失敗題 5 題
優化只加入 Query Rewriting 與調整 Top-K88 分，失敗題降至 2 題
分數變化告訴了什麼
RAG v1 並沒有自動勝過所有 Baseline。真正的進步來自先讀懂失敗，再針對查詢與取回數量做有限改動。
便宜且容易建立，但對語意不同、用詞不一致的問題表現有限。
用來確認最低基準系統可用，但 20 題中仍有 5 題出現檢索失敗。
先診斷，不急著堆更多元件Query Rewriting 加上 Top-K 調整，把失敗題降到 2 題。
相對 v1 提升 14.3%哪些技術沒有急著加進去
20 題的樣本足以找方向，但不足以支撐一次加入太多變因。專案因此保留了幾個刻意不做的決定。
沒有直接跳過 Baseline
如果簡單方法已經足夠，就不必為了使用 RAG 而增加系統複雜度。
沒有同時更換所有元件
每一輪只改可被失敗分類支持的環節，保留因果判斷。
沒有立刻加 Reranker
小樣本下容易把調整做成對測試題的過度擬合。
沒有把總分當作唯一答案
把檢索失敗拆開，才能知道下一步該改查詢、取回內容還是評估方式。