RAG 落地血淚史
最近看到一篇很實的經驗分享 Production RAG: what I learned from processing 5M+ documents，作者花了八個月在 RAG 壕溝裡打滾，處理過上千萬頁的文件。我覺得他講的每一點都很有感，尤其是那種「prototype 跑得很順 → 上 production 全壞掉」的既視感，以下整理一些我覺得最值參考的點：
從 LangChain 到痛苦重構
他們一開始跟大家一樣，LangChain + LlamaIndex 一條龍，demo 兩天搞定，小規模測試 (100 docs) 看起來完美。結果一丟進 9M 頁文件，品質就不行了，最後只剩使用者能分辨回答好壞。想當然就只好重構系統，一個元件一個元件重寫，這段真的我個人也遇過，很多問題根本不會在 notebook 裡出現，只會在 production 親自踩坑體驗才懂。
ROI 最高幾個的技巧
Query Generation：
不是所有語意都在使用者最後一句 query 裡，他讓 LLM 先幫忙「展開問題」成多個 semantic + keyword query，再平行檢索後交給 reranker。這樣能撈到更多相關文件，搜尋覆蓋率高很多。Reranking：
他說這是最划算的五行 code，實測結果顯示 chunk 排名常常大洗牌，reranker 幾乎能救回不少，作者測試最有效配置是 50 chunks in，然後取前 15 out 。Chunking Strategy：
這是整個流程裡最耗時間、但最值得花時間的事，他們針對每個企業都重新設計 chunk 流，檢查兩件事不要切在句子中間
每個 chunk 能單獨構成一個語意單位
Metadata to LLM：
不要只丟文字，附上 title、author、section name 給 LLM，回答準度會提升超多。Query Routing：
很多問題根本不用 RAG，例如「誰寫的?」或「幫我總結這篇」，他們加了一個小 router，自動分流給 API 或 LLM 回答，避免浪費 embedding + vector cost。
他們的技術棧（一路踩坑進化）
這演進路線做過的人應該都很有共鳴，從最紅的開源組合開始，一路被現實修正XD
他們最後把整個架構開源成一個 MIT 專案 agentset-ai/agentset，裡面是 production 級的設計，蠻適合拿來 benchmark 自己的 pipeline。
作者：Chi