一次 RAG 上線翻車：從「能跑」到「能交付」的五個坑

上週給一個製造業客戶交付 RAG 知識庫系統。需求聽起來簡單：把內部技術文件餵給大型語言模型，讓產線工程師能用自然語言提問。

結果上線第一天就翻車了。

坑一：文件格式比想像中髒得多

客戶給了 200 多份 PDF，其中三分之一是掃描件。OCR 出來的表格全是亂碼，公式變成了天書。我們用的 chunking 策略是按段落切分，但技術手冊的段落經常跨頁，切完語意全碎。

教訓：上線前必須做文件品質審計。不是看「有多少份」，而是抽樣看「切完能不能讀」。我們後來加了個預處理流水線：先按標題層級重組，再按語意相似度合併碎片區塊。

坑二：向量檢索的「差不多」陷阱

用預設的 cosine 相似度，top-5 召回看起來都很相關。但實際回答時，模型經常把不同產品的參數混在一起——因為它們在向量空間裡確實很近。

教訓：檢索後必須加一層元資料過濾。我們按產品線和文件版本加了 filter，召回精準度從 62% 拉到 89%。這個改動花了半天，但省了客戶兩週的客訴處理。

坑三：延遲不是模型的問題

客戶抱怨「問一個問題要等 15 秒」。我們第一反應是模型太慢，換了個更快的模型——還是 15 秒。

最後定位到是向量資料庫的索引沒建好。Milvus 預設設定在小數據集上反而比暴力搜尋慢，因為索引建構本身就有開銷。

教訓：先 profiling，再最佳化。別憑直覺換模型。

坑四：使用者不會用「好問題」

工程師習慣問「3號機溫度異常怎麼辦」，但文件裡寫的是「設備過熱故障排除流程」。語意差距導致檢索不到相關內容。

教訓：在檢索前加一層 query rewrite。用一個小模型把使用者問題改寫成語料庫風格，效果立竿見影。這個技巧成本極低，但 ROI 很高。

坑五：監控缺位

上線後我們沒有任何使用數據。不知道哪些問答失敗了，不知道使用者最常問什麼，不知道系統瓶頸在哪。

教訓：Day 1 就要埋點。記錄查詢、召回結果、使用者滿意度（哪怕只是一個 thumbs up/down）。沒有數據，最佳化就是盲人摸象。

總結

RAG 不是「接個 API 就完事」的技術。從文件清洗到檢索最佳化，從延遲調校到使用者行為分析，每個環節都有坑。交付不是 demo 跑通，而是系統能穩定服務真實使用者。

下次再做 RAG 專案，我會把 40% 的時間花在數據品質和監控上，而不是調模型參數。