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

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

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

1、技術(shù)選擇與應(yīng)用場景誤解

1.1 長文本處理、微調(diào)和 RAG 的比較和適用場景

誤解：RAG 總是優(yōu)于直接使用大模型或微調(diào)模型

澄清：

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

微調(diào)適合：需要模型深度理解特定領(lǐng)域語言和概念（如醫(yī)療術(shù)語、法律條文）、語料相對固定且有限、追求統(tǒng)一輸出格式和風(fēng)格的場景

RAG 適合：需要實(shí)時獲取最新信息、處理大量不斷更新的文檔（如產(chǎn)品手冊、法規(guī)更新）、需要提供信息源引用以增強(qiáng)可信度的場景

混合方案的優(yōu)勢：基于領(lǐng)域微調(diào)模型結(jié)合 RAG 架構(gòu)往往效果往往比單一方法效果最佳

1.2 RAG 的實(shí)際能力與局限性

誤解：RAG 可以回答任何關(guān)于文檔的問題

澄清：

RAG 本質(zhì)上是"檢索增強(qiáng)"而非"完全理解"，它基于檢索片段進(jìn)行回答

不擅長回答如"這份報(bào)告的整體結(jié)構(gòu)是什么"或"文檔中的論點(diǎn)如何遞進(jìn)發(fā)展"等需要全局理解的問題

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

最后，在需要多角度綜合或推理的問題上表現(xiàn)受限，如"基于這些財(cái)務(wù)數(shù)據(jù)，公司未來三年的發(fā)展戰(zhàn)略應(yīng)該是什么"

1.3 對 RAG 成本和復(fù)雜度的誤解

誤解：RAG 總是比微調(diào)更簡單或成本更低

澄清：

RAG 系統(tǒng)包括文檔處理、向量化、存儲、檢索、排序等多個環(huán)節(jié)，每個環(huán)節(jié)都有大量的優(yōu)化空間

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

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

對比分析：處理 10 萬頁專業(yè)文檔，一次性微調(diào)模型可能比長期維護(hù) RAG 系統(tǒng)更經(jīng)濟(jì)，當(dāng)然前提還是文檔的更新是相對緩慢的

2、技術(shù)實(shí)現(xiàn)層面的誤解

2.1 分詞策略誤解

誤解：使用默認(rèn)的分詞策略適用于所有語言和領(lǐng)域

澄清：

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

領(lǐng)域特性適配：法律文本中的"第 X 條"、醫(yī)療文本中的"xx 指標(biāo)"等也需要作為整體保留

技術(shù)實(shí)現(xiàn)對比：

基礎(chǔ)分詞：簡單按句號、逗號等標(biāo)點(diǎn)切分

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

混合分詞：結(jié)合文檔結(jié)構(gòu)（標(biāo)題、章節(jié)）和語義邊界的復(fù)合切分

2.2 向量化過程的常見誤區(qū)

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

澄清：

內(nèi)容類型差異化處理：

文本內(nèi)容：適合使用文本 embedding 模型

表格數(shù)據(jù)：可考慮結(jié)構(gòu)化向量化或表格專用 embedding

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

向量模型選擇依據(jù)：

通用應(yīng)用：OpenAI text-embedding-3-large、Cohere embed v3 等通用模型足夠

專業(yè)領(lǐng)域：BGE、GTE 等開源模型可針對垂直領(lǐng)域微調(diào)提升效果

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

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

2.3 檢索策略選擇的盲區(qū)

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

澄清：

多樣化檢索策略比較：

BM25：適合精確關(guān)鍵詞匹配，在技術(shù)文檔、產(chǎn)品手冊中表現(xiàn)良好

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

混合檢索：結(jié)合兩者優(yōu)勢，實(shí)踐中對召回率的提升也有些明顯的效果

參數(shù)調(diào)優(yōu)經(jīng)驗(yàn)：

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

相似度閾值：0.7-0.8 是常見起點(diǎn)，但需要大家根據(jù)自己的業(yè)務(wù)場景容錯性進(jìn)行自定義調(diào)整

檢索增強(qiáng)技術(shù)：

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

結(jié)果重排序：根據(jù)多維度相關(guān)性（不僅是向量相似度）重新排序

2.4 排序策略的優(yōu)化空間

誤解：檢索結(jié)果的相似度分?jǐn)?shù)直接反映其相關(guān)性

澄清：

多維度排序因素：

相關(guān)性：向量相似度只是一個維度

時效性：更新時間可作為排序權(quán)重，當(dāng)然這種更適用于新聞、政策等時效性較高的內(nèi)容

權(quán)威性：可給官方文檔、核心政策等設(shè)置更高權(quán)重

排序策略優(yōu)化路徑：

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

進(jìn)階階段：加入多因素加權(quán)排序

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

用戶交互數(shù)據(jù)價值：點(diǎn)擊、停留時間、反饋等用戶行為數(shù)據(jù)是優(yōu)化排序的重要反饋，當(dāng)然前提是使用的人足夠多

2.5 大模型選擇的考量

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

澄清：

性能與成本平衡：

小模型（7-13B）：適合簡單總結(jié)、標(biāo)準(zhǔn)化回復(fù)，成本低、速度快

中型模型（13-70B）：大多數(shù)企業(yè)應(yīng)用的性價比選擇

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

閉源 vs 開源權(quán)衡：

閉源 API 優(yōu)勢：質(zhì)量穩(wěn)定、維護(hù)成本低、快速上手

開源模型優(yōu)勢：數(shù)據(jù)安全、可定制性強(qiáng)、長期成本可控

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

3、項(xiàng)目實(shí)施層面的誤解

3.1 過早本地化部署的陷阱

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

澄清：

快速 POC 的價值：

驗(yàn)證商業(yè)價值是技術(shù)路徑選擇的前提，"有沒有用"先于"怎么用"

最快 POC 路徑：云服務(wù)部署 RAGFlow/LlamaIndex + 商業(yè) API + 簡化數(shù)據(jù)集

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

敏感數(shù)據(jù)處理策略：

實(shí)體識別和替換：使用 NER 工具識別并替換敏感實(shí)體（人名、機(jī)構(gòu)名、金額等）

令牌化替換：保留數(shù)據(jù)結(jié)構(gòu)，但用占位符替換實(shí)際內(nèi)容，如"客戶 A"、"金額 X"

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

混合架構(gòu)：敏感數(shù)據(jù)本地處理，非敏感數(shù)據(jù)云端處理

分階段部署策略：

階段一：云服務(wù)+商業(yè) API（速度優(yōu)先）

階段二：混合部署（關(guān)鍵組件本地化）

階段三：完全本地化（根據(jù)業(yè)務(wù)需求選擇性實(shí)施）

3.2 完美主義陷阱

誤解：RAG 系統(tǒng)必須達(dá)到接近 100%的準(zhǔn)確率才能上線

澄清：

漸進(jìn)式目標(biāo)設(shè)定：

初始可接受準(zhǔn)確率：70-80%（取決于業(yè)務(wù)容錯性）

中期目標(biāo)準(zhǔn)確率：80-90%（基于用戶反饋優(yōu)化）

長期理想準(zhǔn)確率：90%+（持續(xù)迭代提升）

實(shí)用性優(yōu)先原則：

解決 80%常見問題的 80%系統(tǒng)比解決 100%問題但永遠(yuǎn)不上線的系統(tǒng)更有價值

提供替代路徑：當(dāng)系統(tǒng)無法準(zhǔn)確回答時，引導(dǎo)用戶轉(zhuǎn)向人工渠道

錯誤類型區(qū)分：

致命錯誤：提供錯誤信息導(dǎo)致使用同事判斷失誤（需嚴(yán)格控制）

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

3.3 忽視用戶反饋的誤區(qū)

誤解：RAG 是一次性建設(shè)項(xiàng)目

澄清：

反饋閉環(huán)機(jī)制：

直接反饋：點(diǎn)贊/點(diǎn)踩、評分、問題報(bào)告

間接反饋：使用時長、重復(fù)提問率、人工求助轉(zhuǎn)化率

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

持續(xù)優(yōu)化策略：

數(shù)據(jù)側(cè)優(yōu)化：補(bǔ)充缺失信息、調(diào)整分塊策略

檢索側(cè)優(yōu)化：調(diào)整檢索參數(shù)、改進(jìn)排序算法

生成側(cè)優(yōu)化：優(yōu)化提示詞模板、調(diào)整模型參數(shù)

A/B 測試價值：

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

數(shù)據(jù)驅(qū)動決策而非主觀判斷

3.4 數(shù)據(jù)質(zhì)量 vs 數(shù)據(jù)量的誤解

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

澄清：

數(shù)據(jù)質(zhì)量評估維度：

相關(guān)性：與業(yè)務(wù)問題的直接關(guān)聯(lián)程度，這部分是重中之重，如果引入了很多噪聲，也為調(diào)優(yōu)工作增加了很多負(fù)擔(dān)

時效性：信息的更新狀態(tài)

權(quán)威性：信息來源的可靠程度

結(jié)構(gòu)化程度：信息的組織清晰度

數(shù)據(jù)預(yù)處理關(guān)鍵步驟：

去重：識別并合并重復(fù)或高度相似內(nèi)容

清洗：移除格式標(biāo)記、無意義內(nèi)容、噪音數(shù)據(jù)

結(jié)構(gòu)化：將非結(jié)構(gòu)化內(nèi)容轉(zhuǎn)化為結(jié)構(gòu)化形式

數(shù)據(jù)更新策略：

增量更新：只處理新增或變更內(nèi)容

定期全量更新：針對關(guān)鍵數(shù)據(jù)源的周期性刷新

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

4、行業(yè)最佳實(shí)踐的思考

4.1 技術(shù)棧選擇的平衡

最佳實(shí)踐：

開源框架選擇考量：

RAGFlow：適合快速部署，內(nèi)置多種優(yōu)化策略

LlamaIndex：靈活性高，適合定制開發(fā)

LangChain：生態(tài)豐富，社區(qū)支持廣泛

商業(yè) API 與開源模型混合使用：

核心功能使用高質(zhì)量商業(yè) API（如 DeepSeek-R1、Qwen 2.5 Max 等）

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

向量數(shù)據(jù)庫選擇因素：

小規(guī)模應(yīng)用：FAISS、Chroma 等輕量級選項(xiàng)足夠

大規(guī)模應(yīng)用：Weaviate、Milvus、Pinecone 等分布式解決方案

特殊需求：Qdrant（過濾功能強(qiáng)）、PGVector（與現(xiàn)有 PostgreSQL 集成）

4.2 靈活配置和二次開發(fā)的重要性

最佳實(shí)踐：

配置化 vs 代碼化：

初期：以 UI 配置為主快速驗(yàn)證

中期：轉(zhuǎn)向 Python API 獲取更多控制力

長期：核心功能代碼化以支持定制和持續(xù)優(yōu)化

組件化架構(gòu)優(yōu)勢：

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

向量數(shù)據(jù)庫可平滑遷移或替換

大模型供應(yīng)商可靈活切換

擴(kuò)展接口預(yù)留：

數(shù)據(jù)源接口：支持未來接入新數(shù)據(jù)源

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

人工干預(yù)接口：在自動化流程中預(yù)留人工介入點(diǎn)

4.3 評估和迭代策略

最佳實(shí)踐：

多維度評估指標(biāo)：

準(zhǔn)確性：回答中正確信息的比例

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

相關(guān)性：回答與問題的直接關(guān)聯(lián)程度

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

標(biāo)準(zhǔn)測試集構(gòu)建：

覆蓋核心業(yè)務(wù)場景的典型問題

包含邊界情況和挑戰(zhàn)性問題

定期更新以反映業(yè)務(wù)變化

監(jiān)控體系建設(shè)：

技術(shù)監(jiān)控：響應(yīng)時間、錯誤率、系統(tǒng)負(fù)載

業(yè)務(wù)監(jiān)控：使用頻率、解決率、用戶滿意度

成本監(jiān)控：API 調(diào)用量、存儲使用量、計(jì)算資源消耗

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