春節之后的一個月的時間內，微信和小紅書上數了下大概有 150 多個過來咨詢 RAG 在企業落地的網友，一路聊下來按照對方的訴求大概分為三類，第一種是最多的就是年后返工公司領導讓落地 RAG，但是一時沒有頭緒的過來咨詢的；第二種是看過我公眾號上的相關案例后，想外包給我來做具體實施的；第三種有點出乎意料的是，相關的媒體來交流行業觀察的。

第一種類型也是最開始比較多的，最初我也是問啥答啥，但是大概聊了五六個之后發現情況有點不對，大部分其實是比較基礎的問題，或者我認為問大模型能比問我更快掃盲的，再加上后來確實肉眼可見的人在變多，我索性和每個人說如果是咨詢的話 200 塊每小時（現在漲到了 500），這樣就大部分人就索性不問了，雖說前后也是有十幾個人很干脆的問完問題后直接發了紅包，不過不得不說收費確實是個很好的互相篩選。

以上是碎碎念，言歸正傳，這篇給大家介紹下我目前幾個項目實踐踩坑過程中總結出的些經驗。不過拋開以下細枝末節，個人最大的體感是，做 RAG 的垂直場景落地的關鍵要素其實一直都不是大模型，怎么把數據檢索出來才是問題的根本。簡單的向量搜索也只是召回，如何做二次精排，以及插入多樣性之后再做一次 Re-Ranking 等等方法也是需要從實踐中來到實踐中去。當然，這些細節也是后續重點和大家一起探討的。

1、技術選擇與應用場景誤解

1.1 長文本處理、微調和 RAG 的比較和適用場景

誤解：RAG 總是優于直接使用大模型或微調模型

澄清：

直接使用大模型適合：簡單查詢、通用知識問答、即時響應場景，如客服常見問題解答

微調適合：需要模型深度理解特定領域語言和概念（如醫療術語、法律條文）、語料相對固定且有限、追求統一輸出格式和風格的場景

RAG 適合：需要實時獲取最新信息、處理大量不斷更新的文檔（如產品手冊、法規更新）、需要提供信息源引用以增強可信度的場景

混合方案的優勢：基于領域微調模型結合 RAG 架構往往效果往往比單一方法效果最佳

1.2 RAG 的實際能力與局限性

誤解：RAG 可以回答任何關于文檔的問題

澄清：

RAG 本質上是"檢索增強"而非"完全理解"，它基于檢索片段進行回答

不擅長回答如"這份報告的整體結構是什么"或"文檔中的論點如何遞進發展"等需要全局理解的問題

檢索效果受分塊粒度影響顯著：過大的分塊會包含無關信息干擾答案，而過小的分塊會丟失上下文關聯

最后，在需要多角度綜合或推理的問題上表現受限，如"基于這些財務數據，公司未來三年的發展戰略應該是什么"

1.3 對 RAG 成本和復雜度的誤解

誤解：RAG 總是比微調更簡單或成本更低

澄清：

RAG 系統包括文檔處理、向量化、存儲、檢索、排序等多個環節，每個環節都有大量的優化空間

隨著文檔數量增長，存儲和檢索成本呈近似線性增長，大規模應用需考慮成本控制策略

維護成本往往被低估：文檔更新、向量重新計算、檢索策略調整等也需要持續投入，除非你的知識庫是一成不變的

對比分析：處理 10 萬頁專業文檔，一次性微調模型可能比長期維護 RAG 系統更經濟，當然前提還是文檔的更新是相對緩慢的

2、技術實現層面的誤解

2.1 分詞策略誤解

誤解：使用默認的分詞策略適用于所有語言和領域

澄清：

語言特性差異：中文需要字詞級分詞而非空格分詞，專業中文術語需要作為整體處理

領域特性適配：法律文本中的"第 X 條"、醫療文本中的"xx 指標"等也需要作為整體保留

技術實現對比：

基礎分詞：簡單按句號、逗號等標點切分

語義分詞：考慮段落、小節語義完整性的智能切分

混合分詞：結合文檔結構（標題、章節）和語義邊界的復合切分

2.2 向量化過程的常見誤區

誤解：所有內容都需要向量化，且使用相同的向量模型

澄清：

內容類型差異化處理：

文本內容：適合使用文本 embedding 模型

表格數據：可考慮結構化向量化或表格專用 embedding

代碼片段：代碼專用 embedding 通常效果更好

向量模型選擇依據：

通用應用：OpenAI text-embedding-3-large、Cohere embed v3 等通用模型足夠

專業領域：BGE、GTE 等開源模型可針對垂直領域微調提升效果

混合索引策略：關鍵詞索引+向量索引的雙重索引往往比單一索引效果更好

維度與性能權衡：更高維度并非總是更好，1536 維 vs512 維在許多應用中差異不顯著但成本相差 3 倍

2.3 檢索策略選擇的盲區

誤解：簡單的余弦相似度檢索足以滿足所有需求

澄清：

多樣化檢索策略比較：

BM25：適合精確關鍵詞匹配，在技術文檔、產品手冊中表現良好

向量檢索：適合語義理解，在客戶問詢、意圖分析中表現良好

混合檢索：結合兩者優勢，實踐中對召回率的提升也有些明顯的效果

參數調優經驗：

top_k 值選擇：一般推薦 3-5 個片段，太多會引入噪音，太少可能缺失關鍵信息

相似度閾值：0.7-0.8 是常見起點，但需要大家根據自己的業務場景容錯性進行自定義調整

檢索增強技術：

查詢改寫：將用戶問題轉化為更適合檢索的形式

結果重排序：根據多維度相關性（不僅是向量相似度）重新排序

2.4 排序策略的優化空間

誤解：檢索結果的相似度分數直接反映其相關性

澄清：

多維度排序因素：

相關性：向量相似度只是一個維度

時效性：更新時間可作為排序權重，當然這種更適用于新聞、政策等時效性較高的內容

權威性：可給官方文檔、核心政策等設置更高權重

排序策略優化路徑：

初始階段：單一向量相似度排序

進階階段：加入多因素加權排序

高級階段：引入專門的重排序模型（如 Cohere rerank）

用戶交互數據價值：點擊、停留時間、反饋等用戶行為數據是優化排序的重要反饋，當然前提是使用的人足夠多

2.5 大模型選擇的考量

誤解：更大、更新的模型總是更好

澄清：

性能與成本平衡：

小模型（7-13B）：適合簡單總結、標準化回復，成本低、速度快

中型模型（13-70B）：大多數企業應用的性價比選擇

大型模型（70B+）：復雜推理、多輪對話場景的最佳選擇

閉源 vs 開源權衡：

閉源 API 優勢：質量穩定、維護成本低、快速上手

開源模型優勢：數據安全、可定制性強、長期成本可控

注：如果真的不是公司合規限制，初期POC階段能用商業API的就別動手本地部署，有卡也別部，除非上來能部署個DeepSeek-R1滿血版的。

3、項目實施層面的誤解

3.1 過早本地化部署的陷阱

誤解：企業應該從一開始就追求完全自主可控的本地部署

澄清：

快速 POC 的價值：

驗證商業價值是技術路徑選擇的前提，"有沒有用"先于"怎么用"

最快 POC 路徑：云服務部署 RAGFlow/LlamaIndex + 商業 API + 簡化數據集

典型 POC 周期：精簡方案 2-4 周，完整方案 4-8 周

敏感數據處理策略：

實體識別和替換：使用 NER 工具識別并替換敏感實體（人名、機構名、金額等）

令牌化替換：保留數據結構，但用占位符替換實際內容，如"客戶 A"、"金額 X"

本地向量化：在本地完成向量化，只把向量而非原始文本發送至云端

混合架構：敏感數據本地處理，非敏感數據云端處理

分階段部署策略：

階段一：云服務+商業 API（速度優先）

階段二：混合部署（關鍵組件本地化）

階段三：完全本地化（根據業務需求選擇性實施）

3.2 完美主義陷阱

誤解：RAG 系統必須達到接近 100%的準確率才能上線

澄清：

漸進式目標設定：

初始可接受準確率：70-80%（取決于業務容錯性）

中期目標準確率：80-90%（基于用戶反饋優化）

長期理想準確率：90%+（持續迭代提升）

實用性優先原則：

解決 80%常見問題的 80%系統比解決 100%問題但永遠不上線的系統更有價值

提供替代路徑：當系統無法準確回答時，引導用戶轉向人工渠道

錯誤類型區分：

致命錯誤：提供錯誤信息導致使用同事判斷失誤（需嚴格控制）

非致命錯誤：信息不完整或部分不準確（可接受一定比例）

3.3 忽視用戶反饋的誤區

誤解：RAG 是一次性建設項目

澄清：

反饋閉環機制：

直接反饋：點贊/點踩、評分、問題報告

間接反饋：使用時長、重復提問率、人工求助轉化率

反饋分析：識別常見失敗模式和根本原因

持續優化策略：

數據側優化：補充缺失信息、調整分塊策略

檢索側優化：調整檢索參數、改進排序算法

生成側優化：優化提示詞模板、調整模型參數

A/B 測試價值：

對比不同切片策略、檢索方法或排序算法的實際效果

數據驅動決策而非主觀判斷

3.4 數據質量 vs 數據量的誤解

誤解：更多的文檔意味著更好的 RAG 效果

澄清：

數據質量評估維度：

相關性：與業務問題的直接關聯程度，這部分是重中之重，如果引入了很多噪聲，也為調優工作增加了很多負擔

時效性：信息的更新狀態

權威性：信息來源的可靠程度

結構化程度：信息的組織清晰度

數據預處理關鍵步驟：

去重：識別并合并重復或高度相似內容

清洗：移除格式標記、無意義內容、噪音數據

結構化：將非結構化內容轉化為結構化形式

數據更新策略：

增量更新：只處理新增或變更內容

定期全量更新：針對關鍵數據源的周期性刷新

基于時效性的差異化更新頻率

4、行業最佳實踐的思考

4.1 技術棧選擇的平衡

最佳實踐：

開源框架選擇考量：

RAGFlow：適合快速部署，內置多種優化策略

LlamaIndex：靈活性高，適合定制開發

LangChain：生態豐富，社區支持廣泛

商業 API 與開源模型混合使用：

核心功能使用高質量商業 API（如 DeepSeek-R1、Qwen 2.5 Max 等）

非核心或高頻場景可考慮本地開源模型（如 DeepSeek-R1:32b/70B 等）

向量數據庫選擇因素：

小規模應用：FAISS、Chroma 等輕量級選項足夠

大規模應用：Weaviate、Milvus、Pinecone 等分布式解決方案

特殊需求：Qdrant（過濾功能強）、PGVector（與現有 PostgreSQL 集成）

4.2 靈活配置和二次開發的重要性

最佳實踐：

配置化 vs 代碼化：

初期：以 UI 配置為主快速驗證

中期：轉向 Python API 獲取更多控制力

長期：核心功能代碼化以支持定制和持續優化

組件化架構優勢：

分詞組件可獨立升級而不影響其他部分

向量數據庫可平滑遷移或替換

大模型供應商可靈活切換

擴展接口預留：

數據源接口：支持未來接入新數據源

評估接口：便于接入第三方評估工具

人工干預接口：在自動化流程中預留人工介入點

4.3 評估和迭代策略

最佳實踐：

多維度評估指標：

準確性：回答中正確信息的比例

完整性：回答覆蓋問題所需信息的程度

相關性：回答與問題的直接關聯程度

有用性：回答對用戶實際問題的解決價值

標準測試集構建：

覆蓋核心業務場景的典型問題

包含邊界情況和挑戰性問題

定期更新以反映業務變化

監控體系建設：

技術監控：響應時間、錯誤率、系統負載

業務監控：使用頻率、解決率、用戶滿意度

成本監控：API 調用量、存儲使用量、計算資源消耗

以上算是個比較完整的 checklist，大家可以針對自己的業務實踐辨證參考，其實總結下來也就是兩個原則：場景聚焦策+業務價值驅動。初期要從單一明確的場景入手，POC 之后再進行擴展，其次優先解決業務價值提升明顯的問題。當然，還有一個重要的原則就是要公司內部跨部門協作，一個好的 RAG 應用一定靠用戶反饋不斷迭代出來的。