我們內(nèi)部折騰了兩周把散落在十幾個(gè)共享目錄、Wiki、工單系統(tǒng)里的資料統(tǒng)一收進(jìn)了一個(gè)真正跑在生產(chǎn)環(huán)境的私有化 RAG 知識(shí)庫(kù)。從最開(kāi)始的需求梳理、框架選型到后來(lái)的文檔解析、向量檢索調(diào)優(yōu)再到最后的多租戶權(quán)限隔離和上線運(yùn)維每一步都踩了不少坑。這篇文章就把完整架構(gòu)和數(shù)據(jù)流轉(zhuǎn)鏈路攤開(kāi)講重點(diǎn)說(shuō)清楚那些官方文檔不會(huì)寫的細(xì)節(jié)以及我們自己實(shí)測(cè)下來(lái)覺(jué)得最值得注意的地方。如果你也正準(zhǔn)備在企業(yè)里搭一套私有化 RAG 知識(shí)庫(kù)這篇應(yīng)該能幫你省下一大半試錯(cuò)時(shí)間。1. 為什么必須私有化需求驅(qū)動(dòng)的三個(gè)關(guān)鍵判斷先別急著聊技術(shù)選型。很多團(tuán)隊(duì)拿到“知識(shí)庫(kù)”需求就直接開(kāi)搞結(jié)果做一半發(fā)現(xiàn)數(shù)據(jù)合規(guī)過(guò)不了、模型效果不滿意、迭代改不動(dòng)推到重來(lái)。我們前期花了整整兩天梳理需求最終得出三個(gè)核心結(jié)論所有架構(gòu)決策都圍繞這三個(gè)判斷展開(kāi)。1.1 數(shù)據(jù)出境與合規(guī)風(fēng)險(xiǎn)決定了大方向企業(yè)要入庫(kù)的文檔里有銷售合同、客戶檔案、內(nèi)部研發(fā)方案、財(cái)務(wù)審批材料這些數(shù)據(jù)連傳上公有云都要層層審批更別提直接丟給在線大模型接口做檢索生成。內(nèi)部推演過(guò)一條數(shù)據(jù)流的路徑用戶提問(wèn)→檢索命中→拼接上下文→發(fā)送給在線模型→返回答案。在這個(gè)過(guò)程中原始文檔片段已經(jīng)暴露給了第三方服務(wù)商這在我們這種對(duì)數(shù)據(jù)管控有硬性要求的場(chǎng)景里是絕對(duì)不能接受的。所以私有化不只是“省錢”或者“折騰”而是合規(guī)底線的必然選擇。這也意味著全文檢索鏈路里的每一個(gè)環(huán)節(jié)——embedding 模型、向量數(shù)據(jù)庫(kù)、LLM 推理服務(wù)全部都要落到自己可控的服務(wù)器上。想清楚這一層后面的所有選型標(biāo)準(zhǔn)就清晰了。1.2 “私有化”的現(xiàn)實(shí)定義模型和框架都要可控市面上的開(kāi)源 RAG 框架比如 Dify、MaxKB、FastGPT、RAGFlow還有直接用 LangChain 或 LlamaIndex 自研的都能做私有化部署。但“能部署”和“能生產(chǎn)落地”是兩碼事。我們測(cè)試過(guò)幾個(gè)主流項(xiàng)目發(fā)現(xiàn)它們默認(rèn)的文檔解析邏輯比較理想化遇到掃描件、PPT 轉(zhuǎn)文字、復(fù)雜表格這些真實(shí)企業(yè)文檔效果就會(huì)明顯下滑。后面每一層都需要自己動(dòng)手改或者是寫插件或者是用外部解析服務(wù)替換內(nèi)置邏輯。因此我們定了一個(gè)基本原則框架只承擔(dān)流程編排和底座能力核心環(huán)節(jié)解析、切分、向量化、檢索、重排、生成必須能插拔替換。這也是最終選擇自研內(nèi)層邏輯外面接開(kāi)源組件的原因。1.3 開(kāi)源框架選型對(duì)比Dify 值得用但別迷信開(kāi)箱即用當(dāng)時(shí)認(rèn)真對(duì)比了四個(gè)開(kāi)源項(xiàng)目列表給大家參考框架定位優(yōu)勢(shì)主要瓶頸Dify低代碼 LLMOps 平臺(tái)工作流可視化、生態(tài)成熟、插件多內(nèi)置解析偏弱復(fù)雜生產(chǎn)場(chǎng)景仍需二次開(kāi)發(fā)MaxKB知識(shí)庫(kù)問(wèn)答上手快中文場(chǎng)景做了優(yōu)化靈活性一般重排和權(quán)限控制偏基礎(chǔ)FastGPT知識(shí)庫(kù)問(wèn)答工作流功能全面有商業(yè)化團(tuán)隊(duì)重邏輯定制時(shí)改動(dòng)成本較高RAGFlow文檔深度解析解析排版表現(xiàn)較好自定義鏈路復(fù)雜版本迭代快社區(qū)文檔跟不上我們最后沒(méi)有單選任何一個(gè)而是把其中某個(gè)框架作為管理界面和 API 入口底層的文檔解析、切分策略、向量檢索邏輯都換成了自己的實(shí)現(xiàn)。這樣做的好處是保留社區(qū)的維護(hù)力量同時(shí)關(guān)鍵鏈路全部握在自己手里出問(wèn)題時(shí)能定位到代碼行。2. 兩周時(shí)間線完整架構(gòu)與數(shù)據(jù)流轉(zhuǎn)過(guò)程架構(gòu)設(shè)計(jì)沒(méi)有一步到位是在踩坑過(guò)程中逐步修正的。最終落地的形態(tài)是一個(gè)五層結(jié)構(gòu)每層解決一類問(wèn)題。2.1 總體架構(gòu)五層結(jié)構(gòu)各司其職第一層是數(shù)據(jù)接入層負(fù)責(zé)把散落在共享目錄、Wiki、工單附件、郵箱附件里的文件收集起來(lái)。我們寫了一個(gè)定時(shí)掃描程序按文件指紋md5 大小做增量識(shí)別避免重復(fù)入庫(kù)。第二層是文檔解析與預(yù)處理層。所有文件先進(jìn)統(tǒng)一格式轉(zhuǎn)換PDF 優(yōu)先提取內(nèi)嵌文本沒(méi)有文本層的走 OCRWord 和 PPT 調(diào)用底層轉(zhuǎn)換接口先轉(zhuǎn)成 PDF 再進(jìn)解析管線表格類文檔單獨(dú)標(biāo)記不走默認(rèn)切分邏輯。這一層的產(chǎn)出是“帶層級(jí)結(jié)構(gòu)的純凈文本段落坐標(biāo)元信息”。第三層是切分與向量化層。切分策略選了“Markdown 標(biāo)題層級(jí) 固定窗口兜底”的混合模式。先盡量按文檔的標(biāo)題結(jié)構(gòu)切出大塊再把大塊里的長(zhǎng)段落按 token 窗口二次切分。做完之后每一條切塊都會(huì)保留原始文檔 ID、標(biāo)題路徑、頁(yè)碼供后續(xù)引用溯源使用。第四層是檢索層。檢索邏輯采用了“雙路召回”也就是關(guān)鍵詞檢索和向量檢索并行各自召回一批候選結(jié)果再用重排模型統(tǒng)一打分。關(guān)鍵詞這邊用的 BM25向量那邊用的余弦相似度。雙路召回的意義在于向量檢索擅長(zhǎng)語(yǔ)義相近但字面不同的情況比如問(wèn)“離職流程”匹配到“員工離崗手續(xù)”關(guān)鍵詞檢索擅長(zhǎng)精確匹配專有名詞和編號(hào)比如“GL-2024-013”這類編號(hào)。兩路結(jié)果合并后取 top N 進(jìn)入重排。第五層是生成層。Prompt 模板把我們需要的上下文格式、引用格式、拒答策略都寫死LLM 只做“基于給定內(nèi)容回答”這件事。這里必須強(qiáng)調(diào)LLM 默認(rèn)的“自由發(fā)揮”傾向是知識(shí)庫(kù)問(wèn)答的大敵所以系統(tǒng)提示詞寫得非常嚴(yán)格還加了輸出格式校驗(yàn)不滿足引用要求的回答直接打回重答。一層層拆解下來(lái)數(shù)據(jù)流轉(zhuǎn)的路徑就很清晰了文件系統(tǒng) → 定時(shí)抓取 → 格式轉(zhuǎn)換 → 文本提取 → 標(biāo)題層級(jí)識(shí)別 → 混合切分 → 向量化入庫(kù) 建立倒排索引 → 用戶提問(wèn) → 雙路召回 → 重排 → 組裝上下文 → LLM 生成 → 帶引用的回答返回。2.2 文檔預(yù)處理的隱藏成本格式歸一化比想象中費(fèi)時(shí)間真實(shí)企業(yè)環(huán)境里的文檔格式遠(yuǎn)比教程里的純文本復(fù)雜。我們第一天就把一個(gè) 900MB 的共享目錄全量灌進(jìn)去結(jié)果發(fā)現(xiàn) PDF 文件里混著大量掃描件Word 文檔還帶著各種修訂批注PPT 里的文字是圖形化嵌入的抽取出來(lái)全是亂碼。后來(lái)專門花了三天寫解析適配層掃描 PDF 先用 OCR 服務(wù)轉(zhuǎn)出文本層再走正常流程Word 轉(zhuǎn) PDF 后用版本兼容的處理參數(shù)避免格式丟失PPT 直接按頁(yè)抽文字并保留“標(biāo)題→正文→備注”的結(jié)構(gòu)。每個(gè)格式的處理代碼量不大但邊界情況極多比如圖片型 PDF 的分辨率閾值、表格線的跨頁(yè)截?cái)唷⒍嗉?jí)列表的縮進(jìn)還原這些都是在實(shí)際文件里逐個(gè)磨出來(lái)的。格式歸一化這一層如果沒(méi)做好后面切分和檢索的效果會(huì)被直接拉低一個(gè)檔次。2.3 切分策略混合模式兼顧效率與準(zhǔn)確率切分是決定檢索效果的核心環(huán)節(jié)之一。我們前后試過(guò)純固定窗口256/512 tokens、純語(yǔ)義切分、按標(biāo)題切分三種策略最終選擇了混合模式原因在于純固定窗口雖然實(shí)現(xiàn)簡(jiǎn)單但會(huì)把完整語(yǔ)義塊攔腰切斷。比如一段介紹某系統(tǒng)部署步驟的文本正好被切到兩個(gè)窗口里查詢“部署步驟”時(shí)只能召回片段生成答案就缺少上下文。純語(yǔ)義切分效果好一些但計(jì)算成本高處理長(zhǎng)文檔時(shí)速度讓人著急而且開(kāi)源的語(yǔ)義切分模型對(duì)特定行業(yè)術(shù)語(yǔ)的斷句并不總是準(zhǔn)確?；旌夏Ｊ降牟僮髁鞒淌窍茸R(shí)別 Markdown 標(biāo)題結(jié)構(gòu)將文檔按 H1/H2/H3 層級(jí)切出大段對(duì)每個(gè)大段按固定窗口進(jìn)一步切分窗口大小設(shè)為 480 tokens重疊 80 tokens如果某大段的文本長(zhǎng)度小于窗口大小則保留整段每條生成的切塊補(bǔ)寫元數(shù)據(jù)來(lái)源文件、標(biāo)題路徑、頁(yè)碼范圍、切分序號(hào)。這里面有個(gè)容易忽略的細(xì)節(jié)不同企業(yè)的文檔風(fēng)格差異很大有的標(biāo)題規(guī)范比如制度類、操作手冊(cè)類有的標(biāo)題混亂比如歷史項(xiàng)目總結(jié)、外部伙伴發(fā)來(lái)的交付材料。所以還要加一道兜底規(guī)則如果標(biāo)題層級(jí)稀疏就默認(rèn)采用固定窗口切分避免整段大文本入庫(kù)后檢索召回率過(guò)低。2.4 向量化模型與向量庫(kù)的選型效果和資源的權(quán)衡embedding 模型選型直接決定檢索的上限。我們測(cè)試了 OpenAI 的 embedding 接口效果最好但數(shù)據(jù)要出網(wǎng)第一時(shí)間排除了。開(kāi)源的幾個(gè)主流選擇里重點(diǎn)對(duì)比了 BGE 系列、M3E 系列和我們自己微調(diào)的行業(yè)向量模型。測(cè)試結(jié)果匯總?cè)缦聝?nèi)部數(shù)據(jù)評(píng)估集 50 組業(yè)務(wù)問(wèn)題指標(biāo)是命中率 recall5模型命中率平均延遲ms備注BGE-large-zh-v1.50.8218通用性好穩(wěn)定M3E-base0.7612資源占用少但專業(yè)詞匯表現(xiàn)一般bge-m30.8425多語(yǔ)言支持好稍微吃資源自研微調(diào)模型0.8528數(shù)據(jù)量大之后可考慮投入產(chǎn)出比不高實(shí)際生產(chǎn)選了 bge-m3因?yàn)樗鼘?duì)中英文混排的文檔兼容性更好加上公司內(nèi)部有大量雙語(yǔ)材料這個(gè)優(yōu)勢(shì)很關(guān)鍵。向量庫(kù)選了 pgvector沒(méi)有上 Milvus。原因是數(shù)據(jù)量在百萬(wàn)級(jí) token 量級(jí)時(shí)pgvector 足夠穩(wěn)定而且能共用 PostgreSQL 自帶的事務(wù)、權(quán)限、備份機(jī)制少維護(hù)一個(gè)組件。 Milvus 適合千萬(wàn)級(jí)以上的大規(guī)模場(chǎng)景但對(duì)小團(tuán)隊(duì)來(lái)說(shuō)運(yùn)維成本偏重。2.5 重排模塊召回率再高不如排序準(zhǔn)重排是整個(gè)檢索鏈路里投入產(chǎn)出比最高的一環(huán)。最初我們只做向量檢索召回的 top 8 片段直接拼進(jìn) prompt結(jié)果不少回答引用了正確文件但內(nèi)容不精準(zhǔn)。加入重排模型之后候選片段先交給一個(gè)輕量級(jí) cross-encoder 重新打分再取最相關(guān)的 3 到 4 段進(jìn)入生成階段答案連貫性和準(zhǔn)確性都有了顯著提升。重排模型用的是 bge-reranker-base。它有 2.8 億參數(shù)按我們的并發(fā)量放到單張 GPU 上推理延遲在 15 到 30ms 之間完全在可接受范圍內(nèi)。重排這個(gè)環(huán)節(jié)很容易被新手忽略但實(shí)際效果提升非常直觀我建議只要資源允許一定要加。3. 兩周踩坑實(shí)錄最耗時(shí)間的六個(gè)問(wèn)題這一部分是全文最想分享的內(nèi)容。每個(gè)坑都真實(shí)發(fā)生過(guò)寫出來(lái)希望你能繞開(kāi)。3.1 掃描版 PDFOCR 鏈路繞不開(kāi)第一個(gè)坑就是掃描版 PDF。公司共享目錄里有相當(dāng)一部分合同和歸檔材料是掃描件沒(méi)有內(nèi)嵌文本層。最初我們的解析流程只認(rèn)文本層結(jié)果這些文件靜默失敗日志里只有一行“extract text failed”檢索時(shí)這些文檔永遠(yuǎn)召不回來(lái)。排查鏈路先寫腳本批量統(tǒng)計(jì)各 PDF 的文本層提取成功率發(fā)現(xiàn) 18% 的文檔沒(méi)有文本層對(duì)這些文檔抽樣人工檢查確認(rèn)是掃描件接入 OCR 服務(wù)對(duì)分辨率不足 300 DPI 的圖片做了放大預(yù)處理在解析流程里增加“文本層提取失敗則自動(dòng)進(jìn)入 OCR”的 fallback 邏輯?，F(xiàn)在回頭想這批掃描件的正確處理是整個(gè)知識(shí)庫(kù)覆蓋率的基石。沒(méi)有 OCR主要業(yè)務(wù)資料缺失知識(shí)庫(kù)的價(jià)值直接減半。OCR 服務(wù)的內(nèi)存和 GPU 占用也要提前規(guī)劃我們是分批任務(wù)隊(duì)列跑的避免和在線推理服務(wù)搶資源。3.2 表格被切得七零八落標(biāo)題層級(jí)策略的盲區(qū)第二個(gè)坑來(lái)自表格文檔。我們把一份產(chǎn)品規(guī)格說(shuō)明書推進(jìn)知識(shí)庫(kù)里面包含了各種參數(shù)對(duì)照表。默認(rèn)切分邏輯按標(biāo)題段落切分表格部分被當(dāng)成普通文本切成了多個(gè)片段導(dǎo)致用戶問(wèn)“XX 型號(hào)的最大負(fù)載”時(shí)檢索結(jié)果無(wú)法把完整表格行召回回答要么拼錯(cuò)參數(shù)要么只返回半行數(shù)據(jù)。解決方法是給表格單獨(dú)開(kāi)一條預(yù)處理分支識(shí)別出表格塊后用 OCR/表格結(jié)構(gòu)識(shí)別工具還原成 Markdown 表格格式并讓它作為一個(gè)獨(dú)立的不可切分單元整體入庫(kù)。這樣雖然單塊 token 數(shù)變大了但表格的回完整率明顯提高。這個(gè)坑也引出一個(gè)經(jīng)驗(yàn)切分策略一定要考慮文檔的結(jié)構(gòu)類型不能拿一套規(guī)則打天下。3.3 向量檢索召回高但答非所問(wèn)缺少重排第三坑就是前文提到的重排環(huán)節(jié)缺失?，F(xiàn)象是recall5 的命中率已經(jīng)到 0.84很多問(wèn)題能選中正確文檔但生成的答案還是會(huì)跳過(guò)關(guān)鍵信息引用片段和問(wèn)題相關(guān)性不夠緊密。排查鏈路把 RAG 的完整輸入輸出打印出來(lái)逐條對(duì)比命中片段與正確答案發(fā)現(xiàn)很多候選片段本身包含答案出處但排序太靠后prompt 的上下文窗口里塞進(jìn)了無(wú)關(guān)片段加入 bge-reranker 之后把 top 8 重排成 top 3答案質(zhì)量明顯穩(wěn)定。這個(gè)坑給我的教訓(xùn)是指標(biāo)不能只看“召回”和“命中”要實(shí)測(cè)最終的答案準(zhǔn)確率和用戶滿意度。召回只是中間指標(biāo)重排才是連接召回和最終生成質(zhì)量的關(guān)鍵橋梁。3.4 Embedding 模型對(duì)專業(yè)詞匯的識(shí)別不足中文翻譯腔的坑中文專業(yè)術(shù)語(yǔ)有個(gè)特點(diǎn)正式名稱口語(yǔ)叫法差異很大。比如公司內(nèi)部的“營(yíng)運(yùn)資金周轉(zhuǎn)天數(shù)”員工提問(wèn)時(shí)往往說(shuō)“資金周轉(zhuǎn)要多久”兩個(gè)短語(yǔ)的向量距離可能并不近。我們?cè)谧詼y(cè)時(shí)發(fā)現(xiàn) BM25 對(duì)這種差異完全無(wú)能為力向量模型的效果也很依賴訓(xùn)練數(shù)據(jù)里有沒(méi)有類似表達(dá)。這個(gè)問(wèn)題的處理思路有兩個(gè)方向在認(rèn)識(shí)層加一個(gè)同義詞擴(kuò)展模塊給用戶問(wèn)題先做實(shí)體規(guī)范化把口語(yǔ)表達(dá)替換成知識(shí)庫(kù)內(nèi)的標(biāo)準(zhǔn)叫法積累真實(shí)的用戶提問(wèn)數(shù)據(jù)后續(xù)針對(duì)高頻業(yè)務(wù)場(chǎng)景微調(diào)向量模型。第一版先做了詞表擴(kuò)展效果立竿見(jiàn)影。這也說(shuō)明RAG 落地不是純粹調(diào)模型知識(shí)工程術(shù)語(yǔ)表、實(shí)體庫(kù)、別名庫(kù)的建立同樣重要。3.5 并發(fā)與權(quán)限隔離小團(tuán)隊(duì)最容易忽略的硬骨頭第五個(gè)坑是權(quán)限。知識(shí)庫(kù)上線一周后不同部門開(kāi)始高頻使用問(wèn)題就來(lái)了A 部門的銷售合同B 部門的員工通過(guò)知識(shí)庫(kù)的開(kāi)放檢索也能看到摘要。雖然在系統(tǒng)層面我們沒(méi)有開(kāi)放公開(kāi)查詢但內(nèi)部接口的鑒權(quán)邏輯一開(kāi)始寫得比較粗只校驗(yàn)了用戶是否登錄沒(méi)有校驗(yàn)他能看哪些文檔。這里必須講清楚并發(fā)層面的問(wèn)題向量檢索本身很快但 embedding 推理和 LLM 生成都是資源大戶。第一版上線時(shí)我們所有的請(qǐng)求共用一個(gè)向量模型和同一個(gè) LLM 服務(wù)一旦多人同時(shí)提問(wèn)GPU 占滿后請(qǐng)求排隊(duì)猛增首字延遲從 800ms 飆到 8 秒體驗(yàn)非常差。解決方案是把 embedding 服務(wù)和 LLM 推理服務(wù)分開(kāi)部署分別設(shè)置獨(dú)立并發(fā)隊(duì)列限制最大等待時(shí)間給不同部門的數(shù)據(jù)設(shè)置可見(jiàn)性標(biāo)簽檢索前先用元數(shù)據(jù)過(guò)濾數(shù)據(jù)源再做向量查詢對(duì)搜索請(qǐng)求做資源隔離內(nèi)部員工用量大的部門分配獨(dú)立隊(duì)列避免互相擠占。權(quán)限這塊務(wù)必要在架構(gòu)設(shè)計(jì)階段就放進(jìn)去后期補(bǔ)的話要改的鏈路太長(zhǎng)。我們的經(jīng)驗(yàn)是先用“文檔級(jí)權(quán)限”打底后續(xù)再按需細(xì)粒度到段落級(jí)甚至字段級(jí)。3.6 增量更新與臟數(shù)據(jù)不是把文件丟進(jìn)系統(tǒng)就完事第六個(gè)坑來(lái)自“增量更新”。最初我們的數(shù)據(jù)管道是每天全量重建索引文件一變就全部重新跑一遍解析和 embedding。這樣最簡(jiǎn)單但成本高而且當(dāng)某些文件被刪除或更新時(shí)舊版本內(nèi)容還殘留在向量庫(kù)里走查時(shí)會(huì)發(fā)現(xiàn)知識(shí)庫(kù)答案和當(dāng)前版本不一致。后來(lái)調(diào)整成增量更新機(jī)制全量掃描共享目錄比較文件指紋新增的文件走全文解析進(jìn)入向量庫(kù)變更的文件先刪除舊版本的全部切塊再重新入庫(kù)刪除的文件根據(jù)文檔 ID 清除所有切塊。刪除邏輯看起來(lái)簡(jiǎn)單但真做起來(lái)有很多邊界問(wèn)題比如同一文檔在多個(gè)目錄里存在副本、文件名被修改但內(nèi)容沒(méi)變、PDF 屬性導(dǎo)致的指紋判斷失敗。最終我們用了“文件 ID 內(nèi)容 Hash 更新時(shí)間”的組合判定穩(wěn)定性才上來(lái)。數(shù)據(jù)更新還有個(gè)容易漏的細(xì)節(jié)如果同時(shí)更新了 embedding 模型版本舊向量和新向量不能混用。我們踩過(guò)一次全部向量用了新模型重算之后檢索效果才好起來(lái)。這種“模型版本升級(jí)必須重建索引”的流程要寫進(jìn)變更管理文檔。4. 效果評(píng)測(cè)與調(diào)優(yōu)用指標(biāo)說(shuō)話別憑感覺(jué)知識(shí)庫(kù)搭完沒(méi)人敢說(shuō)“看起來(lái)行”就上線。我們搭建了一套內(nèi)部評(píng)測(cè)流程用來(lái)對(duì)比不同參數(shù)和模塊的效果。4.1 評(píng)測(cè)集構(gòu)建50 道真實(shí)業(yè)務(wù)問(wèn)題起步評(píng)測(cè)集是人工整理的真實(shí)業(yè)務(wù)需求分布在 6 個(gè)場(chǎng)景制度查詢、合同要素、項(xiàng)目流程、IT 支持、供應(yīng)商管理、財(cái)務(wù)術(shù)語(yǔ)。每個(gè)場(chǎng)景 8 到 12 個(gè)問(wèn)題總共 50 道。所有問(wèn)題都經(jīng)過(guò)業(yè)務(wù)方確認(rèn)標(biāo)注了標(biāo)準(zhǔn)答案和答案出處文檔。評(píng)測(cè)指標(biāo)主要看三項(xiàng)recallk正確文檔是否出現(xiàn)在前 k 個(gè)召回結(jié)果里答案忠實(shí)度生成答案是否與檢索到的片段一致由人工評(píng)分占比最重用戶滿意度實(shí)際使用反饋比例。這套評(píng)測(cè)集后來(lái)成為我們每次調(diào)優(yōu)的基準(zhǔn)。沒(méi)有評(píng)測(cè)集改參數(shù)就像在黑房間里換燈泡換了也不知道亮沒(méi)亮。4.2 實(shí)測(cè)對(duì)比切分、重排、精排分別帶來(lái)多少提升我們用同一組評(píng)測(cè)集跑了幾輪對(duì)比實(shí)驗(yàn)。結(jié)果給大家參考實(shí)驗(yàn)配置recall5答案忠實(shí)度5分制純固定窗口 256 tokens無(wú)重排0.743.1混合切分無(wú)重排0.813.4混合切分 bge-reranker0.834.2混合切分 bge-reranker 同義詞擴(kuò)展0.864.5這組數(shù)據(jù)很直觀重排和同義詞擴(kuò)展帶來(lái)的提升都是實(shí)打?qū)嵉摹?shí)際工作中建議按這個(gè)順序調(diào)優(yōu)——先做混合切分再加重排最后補(bǔ)術(shù)語(yǔ)和別名庫(kù)每一步都能觀測(cè)到正向效果。4.3 人工回歸測(cè)試自動(dòng)化指標(biāo)之外的最后一道關(guān)卡自動(dòng)化指標(biāo)能篩選出大部分明顯問(wèn)題但真實(shí)用戶體驗(yàn)維度比如回答的語(yǔ)氣是否生硬、引用排版是否清晰、遇到模糊問(wèn)題時(shí)是否合理地追問(wèn)還是要人工走查。我們安排了兩個(gè)業(yè)務(wù)同事和三個(gè)研發(fā)輪流做回歸測(cè)試每個(gè)人根據(jù)自己熟悉的場(chǎng)景提 20 個(gè)問(wèn)題把不滿意的情況錄下來(lái)每周開(kāi)一次會(huì)歸因。這套“A/B 評(píng)測(cè) 人工回歸”雙軌機(jī)制保證了優(yōu)化方向不是拍腦袋也讓業(yè)務(wù)方感知到知識(shí)庫(kù)在持續(xù)變好溝通成本顯著降低。5. 上線部署與后續(xù)演進(jìn)建議知識(shí)庫(kù)從實(shí)驗(yàn)室走到生產(chǎn)環(huán)境有幾個(gè)部署細(xì)節(jié)如果不提前規(guī)劃上線當(dāng)天就會(huì)手忙腳亂。5.1 硬件配置參考中等規(guī)模團(tuán)隊(duì)夠用型先說(shuō)我們用的配置供參考。團(tuán)隊(duì)人數(shù)大約 200 人活躍使用峰值約 40 人并發(fā)。實(shí)際用的算力和存儲(chǔ)如下組件資源配置備注LLM 推理服務(wù)1 張 24GB 顯存 GPU例如 4090實(shí)際負(fù)載在 70% 左右部署 Qwen2.5-14B-Instruct 或同檔位模型Embedding 服務(wù)純 CPU 服務(wù)16 核 32GB 內(nèi)存bge-m3 在 CPU 上推理延遲還可以接受重排服務(wù)1 張 8GB 顯存 GPUbge-reranker-base 沒(méi)有壓力業(yè)務(wù) API 數(shù)據(jù)庫(kù)8 核 16GB 內(nèi)存2 臺(tái)做冗余pgvector 數(shù)據(jù)庫(kù)與業(yè)務(wù) API 同機(jī)部署這里多說(shuō)一句如果不是特別大的并發(fā)不要一上來(lái)就上多卡大模型集群。先跑起來(lái)看真實(shí)負(fù)載再逐步擴(kuò)容成本控制會(huì)好很多。5.2 更新策略增量入庫(kù) 定期全量重建增量更新和全量重建要配合使用。日常工作靠增量更新保證時(shí)效性但每季度要做一次全量重建目的是清理歷史臟數(shù)據(jù)、統(tǒng)一模型版本、重新校準(zhǔn)切分參數(shù)。全量重建的流程我們寫成了腳本化的運(yùn)維任務(wù)整個(gè)過(guò)程大概是停寫操作導(dǎo)出舊庫(kù)備份用新配置跑一遍全量解析和向量化切換新索引庫(kù)保留舊庫(kù)三天的回滾期。整個(gè)流程自動(dòng)化之后運(yùn)維成本非常低。要注意的關(guān)鍵點(diǎn)是全量重建期間查詢服務(wù)不能被阻塞太久。我們的做法是先建新索引庫(kù)最后通過(guò)一個(gè)路由文件把檢索請(qǐng)求切到新庫(kù)切換過(guò)程秒級(jí)完成。5.3 Agentic RAG下一步的演進(jìn)方向第一版知識(shí)庫(kù)上線之后檢索問(wèn)答的準(zhǔn)確率基本可用了但用戶的期待是不斷上升的?，F(xiàn)在大家不再滿足于“你給我一段文檔摘要”而是希望我直接幫忙處理一個(gè)多步驟事務(wù)比如“查一下某供應(yīng)商的最近三份合同里付款條款有什么差異整理成對(duì)比表”。這種需求單靠“一次檢索 一次生成”是搞不定的需要對(duì) query 做任務(wù)拆解、多輪檢索、子問(wèn)題匯總也就是 Agentic RAG 的思路。我們目前正在規(guī)劃把工作流引擎放進(jìn)去讓大模型可以調(diào)用多個(gè)檢索工具、對(duì)比工具、表格生成工具形成端到端的任務(wù)處理鏈路。就目前的實(shí)踐經(jīng)驗(yàn)來(lái)說(shuō)Agentic RAG 的工程復(fù)雜度比單輪 RAG 要高不少但確實(shí)是企業(yè)知識(shí)庫(kù)從“問(wèn)答機(jī)器人”走向“業(yè)務(wù)智能體”的關(guān)鍵一步。后續(xù)有機(jī)會(huì)再單獨(dú)寫一篇把多智能體協(xié)作里的狀態(tài)管理、工具調(diào)用、失敗重試這些細(xì)節(jié)講透。最后再分享一個(gè)我個(gè)人的體會(huì)搭建私有化 RAG 知識(shí)庫(kù)真正的難點(diǎn)從來(lái)不在大模型本身而在于怎么把企業(yè)里雜亂無(wú)章的資料工程化地變成結(jié)構(gòu)化的可用知識(shí)。切分策略、解析鏈路、權(quán)限模型、增量更新、效果評(píng)測(cè)這些“臟活累活”做扎實(shí)之后大模型才有一個(gè)靠譜的地基。而所謂架構(gòu)本質(zhì)上就是在這堆臟活累活之上找一個(gè)最省心、最可控、最可持續(xù)演進(jìn)的組織方式。