在公司里做了大半年企業(yè)知識(shí)庫相關(guān)的項(xiàng)目踩坑踩到懷疑人生最后總算是攢出了一套從文檔導(dǎo)入到檢索調(diào)優(yōu)的完整流程。今天把這段經(jīng)驗(yàn)整理出來核心就一句話讓大模型基于私有數(shù)據(jù)精準(zhǔn)回答難點(diǎn)不在模型而在知識(shí)庫全鏈路的工程化。企業(yè)知識(shí)庫最關(guān)鍵的三個(gè)環(huán)節(jié)是數(shù)據(jù)進(jìn)來、知識(shí)存好、答案找到。文檔導(dǎo)入決定數(shù)據(jù)質(zhì)量分塊策略決定檢索粒度向量化和重排決定召回準(zhǔn)確性提示詞組裝決定最終生成效果任何一環(huán)沒做好用戶問出來的答案都會(huì)像“胡說八道”。這篇文章面向兩類人一類是準(zhǔn)備給團(tuán)隊(duì)搭私有知識(shí)庫的技術(shù)負(fù)責(zé)人另一類是已經(jīng)搭好了但發(fā)現(xiàn)檢索效果稀爛、想系統(tǒng)調(diào)優(yōu)的開發(fā)者。我會(huì)把選型思路、文檔預(yù)處理細(xì)節(jié)、檢索優(yōu)化手段和評(píng)測(cè)方法完整過一遍盡量給出可以直接抄作業(yè)的方案。1. 企業(yè)知識(shí)庫的整體設(shè)計(jì)與技術(shù)選型1.1 先搞清楚需求知識(shí)庫到底在解決什么問題很多團(tuán)隊(duì)一開始就把“用大模型回答問題”當(dāng)成目標(biāo)這是典型的把手段當(dāng)目的。企業(yè)知識(shí)庫真正的問題域是私有數(shù)據(jù)散落在PDF、Word、Excel、網(wǎng)頁、PPT、內(nèi)部Wiki里員工要用的時(shí)候找不到找到了讀不完讀完了難以總結(jié)更別提單量驚人的重復(fù)咨詢。大模型的價(jià)值是讓這些沉淀的資料變成“隨問隨答”的助手。所以知識(shí)庫的衡量標(biāo)準(zhǔn)不是“有沒有接入大模型”而是這幾個(gè)指標(biāo)回答是否有依據(jù)能否定位到原始文檔的章節(jié)或頁碼對(duì)同一類問題是否穩(wěn)定換了措辭還能不能檢索到同一份資料新增文檔后能否及時(shí)生效舊文檔下線后回答里不會(huì)殘留過期信息是否支持多輪追問用戶能逐步縮小問題范圍。我在項(xiàng)目初期做了一次需求訪談發(fā)現(xiàn)業(yè)務(wù)方最關(guān)心的不是“模型聰明不聰明”而是“能不能快速找到那頁合同里寫了什么”“報(bào)廢流程第幾條適用”。這決定了我后續(xù)所有設(shè)計(jì)都圍繞“檢索”展開而不是圍繞“生成”展開。1.2 技術(shù)路線選型RAG、微調(diào)還是混合方案私有數(shù)據(jù)接入大模型有幾種主流方式我把它們放一起對(duì)比方案適用場(chǎng)景優(yōu)點(diǎn)缺點(diǎn)維護(hù)成本RAG檢索增強(qiáng)文檔多、更新頻繁、需要可溯源無需訓(xùn)練文檔即插即用回答可引用出處依賴檢索質(zhì)量切片策略影響大中模型微調(diào)風(fēng)格模仿、格式固定、術(shù)語統(tǒng)一生成結(jié)果穩(wěn)定不依賴外部檢索每次數(shù)據(jù)變化要重訓(xùn)容易過擬合高向量庫全文檢索混合中英文混合、同義詞多、專有名詞多召回率更高詞法語義互補(bǔ)兩套系統(tǒng)都要維護(hù)中純提示詞工程知識(shí)量小、上下文能塞得下實(shí)現(xiàn)最快不適用于大規(guī)模文檔低我的經(jīng)驗(yàn)是企業(yè)知識(shí)庫千萬首站壓RAG不要一上來就微調(diào)。微調(diào)適合讓模型改變說話風(fēng)格、學(xué)會(huì)特定輸出格式不適合真正注入事實(shí)性知識(shí)。因?yàn)槠髽I(yè)文檔動(dòng)輒上千頁微調(diào)既無法保證新知識(shí)及時(shí)更新又容易讓模型把訓(xùn)練數(shù)據(jù)里的舊常識(shí)帶進(jìn)來和私有數(shù)據(jù)搞混。RAG方案最大的優(yōu)勢(shì)是數(shù)據(jù)與模型解耦換一批文檔就能換一套知識(shí)回答的每個(gè)觀點(diǎn)都能回溯到原文。如果你后續(xù)發(fā)現(xiàn)某些固定格式的場(chǎng)景確實(shí)需要微調(diào)比如合同條款生成、報(bào)表標(biāo)題規(guī)范化再單獨(dú)對(duì)這部分做LoRA微調(diào)也不用推翻RAG主干。還有人問要不要直接上Agent框架。我的建議是知識(shí)庫問答先別急著上Agent先把“查得準(zhǔn)”這件事打磨好。Agent更像是在回答流程里疊加了工具調(diào)度和任務(wù)拆解如果底層檢索本身就是壞的Agent只會(huì)更快地把錯(cuò)誤信息包裝成自信答案。2. 文檔導(dǎo)入與預(yù)處理從數(shù)據(jù)源到高質(zhì)量語料2.1 文檔解析與清洗企業(yè)里最常見的存量數(shù)據(jù)就是一堆PDF但PDF分兩類原生PDF和掃描件。原生PDF可以直接提取文本但排版常?；靵y段落被截?cái)?、表格錯(cuò)位、頁眉頁腳混入正文。掃描件必須走OCR這一步的質(zhì)量直接決定后續(xù)效果。如果OCR出來的文本是垃圾后面無論切片還是向量化都救不回來。我用過的解析工具鏈有兩種方案PDF文本提取用PyMuPDF對(duì)原生電子版PDF效果穩(wěn)定能保留段落位置信息掃描件走PaddleOCR中文識(shí)別精度比開箱即用的Tesseract好很多尤其在印刷體上表現(xiàn)不錯(cuò)Word和PDF統(tǒng)一轉(zhuǎn)化成結(jié)構(gòu)化內(nèi)容再逐塊抽取標(biāo)題、正文、表格、圖片備注HTML網(wǎng)頁內(nèi)容用BeautifulSoup抽正文去掉導(dǎo)航欄、廣告角落、cookie提示等噪聲。清洗步驟里容易被漏掉的有三類頁眉頁腳、目錄、重復(fù)段落。頁眉頁腳不處理解碼后每個(gè)切片都會(huì)帶著公司名和頁碼這會(huì)讓同名片段反復(fù)出現(xiàn)擠占最后大模型的上下文窗口目錄則是浪費(fèi)如果切片里全是“第2章 3.1 4.2”之類的內(nèi)容檢索系統(tǒng)會(huì)誤以為這是有效知識(shí)重復(fù)段落一般出現(xiàn)在多份文檔整合進(jìn)同一知識(shí)庫的時(shí)候比如三份文檔里都粘貼了同一段合規(guī)說明會(huì)導(dǎo)致檢索時(shí)重復(fù)召回浪費(fèi)上下文。清洗后的數(shù)據(jù)建議落到統(tǒng)一的JSONL或Markdown格式每個(gè)記錄都保留元數(shù)據(jù)包括文檔ID、源文件路徑、一級(jí)標(biāo)題、二級(jí)標(biāo)題、頁碼、修訂日期。這一步看著繁瑣但后期調(diào)試“回答引用哪一份文檔”時(shí)能省掉大量時(shí)間。2.2 分塊策略與切片參數(shù)分塊是整個(gè)文檔導(dǎo)入流程里最容易被低估的參數(shù)但它的敏感程度不亞于模型上下文長(zhǎng)度。切片太大單個(gè)向量承載的語義太泛檢索系統(tǒng)返回的內(nèi)容像一篇沒頭沒尾的說明文切片太小語義被切碎答案里缺上下文。我做過一批測(cè)試固定問題查同一份技術(shù)手冊(cè)加入重疊部分為15%的500字切片時(shí)精確率顯著高于100字小切片和2000字大切片。切片原則可以總結(jié)成以下幾點(diǎn)不要純按字?jǐn)?shù)硬切優(yōu)先按文檔結(jié)構(gòu)切標(biāo)題、段落、列表項(xiàng)盡量完整每塊控制在300到500個(gè)中文字符之間復(fù)雜技術(shù)文檔可以縮小到200字左右相鄰塊設(shè)置10%到15%的重疊盡量避免句子被硬生生截?cái)郙arkdown格式下的表格盡可能整體保留寧可塊大一點(diǎn)也不要拆碎代碼示例單獨(dú)成塊不要和說明文字混在一起否則向量檢索時(shí)容易被語義污染。實(shí)際操作中我用的是遞歸字符分塊器先按Markdown標(biāo)題分再按段落分最后才是按字符數(shù)截?cái)?。代碼實(shí)現(xiàn)大概是這樣的from langchain.text_splitter import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter markdown_splitter MarkdownHeaderTextSplitter( headers_to_split_on[(##, H2), (###, H3)] ) sections markdown_splitter.split_text(clean_doc) text_splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap60, separators[\n\n, \n, 。, , , ] ) chunks [] for section in sections: chunks.extend(text_splitter.split_text(section.metadata[content]))這里有個(gè)細(xì)節(jié)分隔符順序很重要中英文混排的情況下“?！焙汀啊北仨毞旁诳崭裰胺駝t英文句子會(huì)被空格先切開整段語義就散了。我一開始沒注意中文文檔效果還行切到英文操作手冊(cè)時(shí)答案頻頻缺料后來才發(fā)現(xiàn)是分隔符排序的鍋。3. 向量化與索引構(gòu)建3.1 嵌入模型選型中文場(chǎng)景下的坑向量化負(fù)責(zé)把文本塊映射成高維向量檢索時(shí)用余弦距離找最相似的塊。這里最大的坑是直接用OpenAI的text-embedding-ada-002處理國內(nèi)企業(yè)文檔中文專有名詞、公司內(nèi)部縮寫、業(yè)務(wù)黑話經(jīng)常編碼不出有效距離。企業(yè)內(nèi)部文檔里充滿了“整機(jī)事業(yè)部”“EOL通知”“客訴8D報(bào)告”這類詞匯它們?cè)谕ㄓ孟蛄磕Ｐ屠餂]有足夠語義支撐檢索效果自然上不去。我最終選了BGE-M3或者bge-large-zh作為主力嵌入模型支持中文、英文和多語言混合內(nèi)容。BGE的整體向量維度比OpenAI的老模型小一些但處理中文相近語義的表現(xiàn)反而更好。如果你有GPU可以本地部署沒有GPU也可以走一些支持私有化部署的推理服務(wù)。嵌入模型有兩個(gè)參數(shù)需要注意查詢向量和文檔向量是否需要分別處理以及是否啟用“指令前綴”。BGE的中文檢索建議在查詢側(cè)加“為這個(gè)句子生成表示以用于檢索相關(guān)文章”后綴文檔側(cè)建索引時(shí)不加。加上查詢指令后平均檢索精度能提升好幾個(gè)點(diǎn)。這不是玄學(xué)它讓同一個(gè)模型在處理兩端輸入時(shí)處于不同的表示分布中。3.2 向量數(shù)據(jù)庫與混合檢索向量數(shù)據(jù)庫選型上如果文檔量在百萬級(jí)以下、不需要分布式部署Chroma或者M(jìn)ilvus Lite完全夠用如果是千萬級(jí)或者有高并發(fā)訴求Milvus或者Elasticsearch自帶向量插件是更穩(wěn)的路線。我個(gè)人更偏向Elasticsearch因?yàn)槠髽I(yè)里很多團(tuán)隊(duì)本來就在用ES做日志和全文搜索復(fù)用基礎(chǔ)設(shè)施能少維護(hù)一套系統(tǒng)。但純向量檢索有一個(gè)明顯的盲區(qū)精確詞匹配。比如員工搜“MSDS”文檔里寫的是“物質(zhì)安全數(shù)據(jù)表”兩個(gè)表述在語義上相近向量檢索能找到反過來搜“安全數(shù)據(jù)表”可能向量庫里返回一堆安全管理制度反而精確詞語沒排上來。解決這種問題就靠混合檢索向量召回一批候選結(jié)果BM25全文檢索再撈一批精確匹配結(jié)果最后合并去重?；旌蠙z索的合并策略有幾個(gè)細(xì)節(jié)要注意向量檢索和全文檢索的分?jǐn)?shù)量綱不同不能直接相加需要做min-max歸一化或者排序分融合建議給精確匹配的結(jié)果留一定的權(quán)重增益但也不要讓它完全壓過語義結(jié)果否則又會(huì)退化成純關(guān)鍵詞搜索每路檢索先各自取top50合并后再統(tǒng)一排序取top10原始top100里的有效結(jié)果比例會(huì)明顯下降所以候選池不能太小。我遇到過一個(gè)典型場(chǎng)景用戶問“報(bào)價(jià)單里的稅率怎么改”文檔里原文是“修改T-Code字段以變更增值稅率”。詞面上完全沒有交集但語義相關(guān)度很高這就是混合檢索發(fā)揮價(jià)值的地方。純BM25搜“稅率”可能返回一堆財(cái)務(wù)制度返回不到操作手冊(cè)純向量檢索找“修改T-Code”又能出來但混合后效果最穩(wěn)。3.3 索引元數(shù)據(jù)與權(quán)限過濾企業(yè)知識(shí)庫繞不開權(quán)限問題特別是合同、人事制度、財(cái)務(wù)流程這類敏感文檔。粗放的做法是把所有文檔統(tǒng)一入庫檢索時(shí)全量召回但這樣只要跨部門提問就可能泄露信息。我的建議是在索引構(gòu)建時(shí)就把權(quán)限字段寫進(jìn)元數(shù)據(jù)查詢時(shí)同步帶上用戶權(quán)限過濾條件。具體實(shí)現(xiàn)上每個(gè)文檔導(dǎo)入時(shí)標(biāo)記所屬部門、訪問級(jí)別標(biāo)簽、允許查詢的角色。檢索請(qǐng)求過來時(shí)先從用戶體系里獲取權(quán)限列表再在向量數(shù)據(jù)庫查詢條件里加上filter。這一步必須在索引階段完成不能靠回答階段后置裁剪因?yàn)橄蛄空倩乇旧砭蜕婕罢Z義相似度一旦敏感內(nèi)容和公開內(nèi)容語義相近后置裁剪已經(jīng)來不及了。我自己在項(xiàng)目里遇到的教訓(xùn)是權(quán)限過濾字段不要用中文枚舉值統(tǒng)一映射成內(nèi)部權(quán)限ID。一方面避免歧義另一方面在做布爾過濾時(shí)不容易踩分詞坑。4. 檢索調(diào)優(yōu)與評(píng)測(cè)4.1 建立評(píng)測(cè)集先有一個(gè)“金標(biāo)準(zhǔn)”大多數(shù)團(tuán)隊(duì)翻車的開始是沒有評(píng)測(cè)集就開始調(diào)參數(shù)。你以為在優(yōu)化檢索實(shí)際上只是在基于兩三個(gè)問題自我感覺良好。正確做法是先準(zhǔn)備一份“金標(biāo)準(zhǔn)”評(píng)測(cè)集包含至少50到100個(gè)真實(shí)業(yè)務(wù)問題每個(gè)問題標(biāo)注對(duì)應(yīng)正確答案所在的文檔塊ID。評(píng)測(cè)集構(gòu)建有兩條路徑第一條是從業(yè)務(wù)方收集高頻咨詢問題讓知識(shí)管理員標(biāo)注第二條是拿已有的工單系統(tǒng)、客服記錄、內(nèi)部問答平臺(tái)歷史記錄來抽取。我在項(xiàng)目里用的是第二種因?yàn)楣斡涗浝锶钦鎸?shí)用戶實(shí)際關(guān)心的問題還能直接看到過往人工回答的質(zhì)量。評(píng)測(cè)指標(biāo)不要只報(bào)一個(gè)“回答正確率”?；卮鹫_率依賴大模型生成環(huán)節(jié)干擾因素多更適合拆成檢索指標(biāo)和生成指標(biāo)兩類。檢索指標(biāo)關(guān)注召回率和命中位置生成指標(biāo)關(guān)注答案完整性、引用正確性和事實(shí)一致性。我最常用的兩個(gè)指標(biāo)是Recall10正確答案是否出現(xiàn)在前10個(gè)候選塊里以及MRR正確答案排在第幾位。后一個(gè)尤其關(guān)鍵因?yàn)長(zhǎng)LM讀上下文時(shí)排得越靠前的塊被采信的概率越高。4.2 召回參數(shù)調(diào)優(yōu)召回階段可調(diào)的參數(shù)其實(shí)不多但每一檔都有明顯效果。最常見的是top_k、score閾值、是否啟用重排序模型以及索引構(gòu)建時(shí)的分塊引入的隱式影響。先看top_k。很多RAG教程默認(rèn)top_k3或5但在企業(yè)文檔場(chǎng)景里我強(qiáng)烈建議先用top_k20甚至top_k50跑評(píng)測(cè)然后觀察正確答案實(shí)際排在什么位置。有的場(chǎng)景下答案真的排在第十位左右如果設(shè)置top_k3神仙大模型來了也無法生成正確答案。調(diào)優(yōu)時(shí)先放開top_k讓重排序模型重新校準(zhǔn)候選順序再收緊最終進(jìn)入LLM的上下文數(shù)量。再看score閾值。向量相似度得分在不同嵌入模型、不同文檔類型下分布差異很大直接固定一個(gè)閾值不現(xiàn)實(shí)。我見過不少代碼里寫著score 0.8結(jié)果檢索系統(tǒng)對(duì)某些格式文檔一個(gè)結(jié)果都不返回。正確姿勢(shì)是先統(tǒng)計(jì)一批真實(shí)問題下命中答案的得分分布畫個(gè)箱線圖再根據(jù)分布選閾值往往能在“漏檢”和“誤檢”之間找到平衡點(diǎn)。重排序模型是性價(jià)比最高的組件。第一階段的向量檢索可以粗糙一點(diǎn)先把候選池放大然后用cross-encoder型重排模型逐對(duì)打分。cross-encoder會(huì)同時(shí)讀入問題和候選文檔計(jì)算真正的語義匹配度精度遠(yuǎn)高于向量向量之間的余弦距離。我實(shí)測(cè)下來接入bge-reranker之后MRR提升大約20%到30%這個(gè)數(shù)據(jù)在各行業(yè)場(chǎng)景下都比較穩(wěn)。4.3 生成階段的提示詞組裝檢索做得好只成功了一半。同樣的檢索結(jié)果提示詞組織不同最終答案質(zhì)量相差很多。我常用的生成提示詞包含四部分系統(tǒng)指令、上下文文檔塊、用戶問題、約束要求。系統(tǒng)指令里明確角色定位和回答范圍上下文文檔塊按相關(guān)性從高到低排列同時(shí)保留每個(gè)塊的元信息包括來源文檔名和原文頁碼用戶問題就是原始自然語言約束要求里一定要寫明“只根據(jù)提供的內(nèi)容回答如果內(nèi)容不足以回答問題請(qǐng)直接說明”。這里有一個(gè)容易踩的坑上下文擠爆。top_k20意味著20個(gè)文檔塊進(jìn)入大模型如果每塊400字就是8000字上下文已經(jīng)占到中等上下文窗口的一半。這樣既增加tokens成本也給模型更多“挑錯(cuò)的素材”。我建議在重排序后只保留top_k5到8個(gè)塊進(jìn)入生成階段剩下的塊作為擴(kuò)展證據(jù)隱藏保留不直接喂給模型。組裝模板沒有標(biāo)準(zhǔn)答案但我給出一個(gè)可復(fù)用的示例你是一名嚴(yán)格的企業(yè)知識(shí)庫問答助手。 請(qǐng)只基于以下資料回答問題不要引用任何外部知識(shí)。 如果資料不足以回答請(qǐng)直接說明“根據(jù)現(xiàn)有資料無法回答”。 資料如下按相關(guān)度排序 [1] 《ERP操作手冊(cè)》第6章第3節(jié)修改稅率的操作步驟 [2] 《財(cái)務(wù)流程說明》第2節(jié)稅率變更審批時(shí)限 用戶問題報(bào)價(jià)單里的稅率怎么改 請(qǐng)給出簡(jiǎn)潔、有依據(jù)的回答并在回答末尾列出引用來源。這個(gè)模板看起來簡(jiǎn)單但有兩個(gè)隱藏設(shè)計(jì)一是通過“只基于資料”切斷模型的通用知識(shí)幻覺二是通過強(qiáng)制末尾列出引用讓用戶能自查答案來源。后者對(duì)企業(yè)場(chǎng)景特別管用員工看到引用出處后信任度會(huì)大幅提升。4.4 檢索時(shí)不放過細(xì)節(jié)同義詞、縮寫和跨語言企業(yè)文檔里的術(shù)語多樣性比想象中嚴(yán)重。同一個(gè)產(chǎn)品型號(hào)有人寫成“ABC-100”有人寫成“ABC100”還有人寫成“abc 100”。這種情況下如果元數(shù)據(jù)里保留別名映射檢索效果立刻不一樣。我在文檔預(yù)處理階段增加了一個(gè)可選的“術(shù)語擴(kuò)展表”把公司內(nèi)部的縮寫、曾用名、本地化叫法統(tǒng)一維護(hù)成同義詞表。檢索時(shí)把用戶問句中的詞自動(dòng)替換為規(guī)范表達(dá)再送進(jìn)向量檢索前后效果差異很大?？缯Z言場(chǎng)景也不能忽略。很多外企文檔是中英混排的用戶用英文問但相關(guān)中文文檔里根本沒有對(duì)應(yīng)英文詞。這種情況靠單一嵌入模型有時(shí)搞不定建議在索引側(cè)同時(shí)存一個(gè)英文翻譯字段或中英混合向量。成本增加的只是一些存儲(chǔ)和embedding計(jì)算但對(duì)跨國業(yè)務(wù)的知識(shí)庫來說收益非常明顯。5. 常見問題與排查技巧實(shí)錄5.1 回答看起來合理但找不到出處這是知識(shí)庫上線后最典型的問題大模型把話說得圓滿但答案里找不到對(duì)應(yīng)的原文。先說結(jié)論這種問題大多出在“生成階段喂了太多與問題不相關(guān)的上下文”。我在排查時(shí)先看檢索日志確認(rèn)最終進(jìn)入LLM的文檔塊里有沒有正確答案本身。如果沒有說明召回或重排階段出了問題如果有但回答還是不準(zhǔn)確那多半是提示詞里給了模型自由發(fā)揮的空間。我的排查順序是抓取單個(gè)失敗case打印召回候選的前50條看正確答案是否在候選池里如果不在檢查分塊是否把答案切碎或者嵌入模型對(duì)專業(yè)詞匯是否無感如果在候選池但被重排到后面調(diào)整重排模型或者檢查top_k截?cái)辔恢萌绻嘏藕笠呀?jīng)排到前幾塊但回答依然不對(duì)改提示詞約束強(qiáng)制模型只引用給定塊內(nèi)容最后確認(rèn)一下元數(shù)據(jù)里的引用字段是否正確渲染因?yàn)楹芏嗲闆r下答案是對(duì)的只是前端把引用丟失了。5.2 新增文檔后回答還是舊信息知識(shí)庫與普通數(shù)據(jù)庫不同它沒有“實(shí)時(shí)同步”的概念。新增文檔必須重新切片、重新向量化、重新入索引。如果導(dǎo)入流程沒有覆蓋“刪除過期文檔”這一步舊數(shù)據(jù)就會(huì)一直和新數(shù)據(jù)爭(zhēng)搶召回名額。我會(huì)做一個(gè)簡(jiǎn)單的狀態(tài)管理表記錄文檔hash、導(dǎo)入時(shí)間、狀態(tài)活躍、過期、待清理。每隔一段時(shí)間跑一次清理任務(wù)把過期文檔對(duì)應(yīng)的向量從庫里刪除。注意是物理刪除不是打標(biāo)記否則向量檢索還是能碰到。這一點(diǎn)特別是用ES做存儲(chǔ)時(shí)容易漏不從索引里刪除來源ID等于白刪。5.3 長(zhǎng)文檔回答不符合預(yù)期長(zhǎng)文檔經(jīng)常出現(xiàn)的問題是答案分散在多個(gè)章節(jié)。比如用戶問“資金審批流程”第1章講申請(qǐng)條件第3章講審批人第6章講時(shí)限沒有一個(gè)切片能覆蓋完整答案。這時(shí)候靠單塊檢索必然漏解決方案有兩種。第一種是“父文檔返回”構(gòu)建切片時(shí)記錄所屬的父章節(jié)檢索時(shí)命中多個(gè)子塊后把父章節(jié)整體取回讓大模型閱讀更大范圍的完整內(nèi)容。第二種是“多輪檢索”第一輪用用戶問題定位包含核心信息的切片第二輪用這些切片的內(nèi)容反向檢索關(guān)聯(lián)切片。我個(gè)人傾向先用父文檔返回實(shí)現(xiàn)簡(jiǎn)單且效果穩(wěn)定多輪檢索容易引入噪聲。5.4 評(píng)測(cè)指標(biāo)看似很高實(shí)際上線用戶并不滿意這是個(gè)特別容易被忽視的坑。評(píng)測(cè)集如果只從已有文檔里標(biāo)注很容易“污染”。因?yàn)闇y(cè)試問題里的關(guān)鍵詞通常和文檔原文重疊度高檢索系統(tǒng)就算退化成關(guān)鍵詞匹配也能得分。但真實(shí)用戶不會(huì)照著文檔措辭提問他們會(huì)說“審批卡住了怎么辦”而文檔里寫的是“審批超時(shí)處理機(jī)制”。解決這個(gè)問題的做法是評(píng)測(cè)集必須包含“用戶口語化改寫”版本。把業(yè)務(wù)方提供的高頻問題由不同人改寫成三種以上說法包括簡(jiǎn)寫、錯(cuò)別字、省略上下文的口語化表達(dá)。用這種評(píng)測(cè)集去測(cè)才能真正反映檢索系統(tǒng)的泛化能力。6. 寫在最后我踩過最深的坑如果只能分享一條經(jīng)驗(yàn)我想說企業(yè)知識(shí)庫不是大模型項(xiàng)目是數(shù)據(jù)工程項(xiàng)目。決定下限的是文檔解析干不干凈、分塊合不合理、元數(shù)據(jù)完不完整決定上限的才是模型和調(diào)優(yōu)技巧。把數(shù)據(jù)管道做扎實(shí)即使用中等規(guī)模的模型也能有像樣的回答質(zhì)量倒過來想靠一個(gè)強(qiáng)模型硬扛爛數(shù)據(jù)那就是花最多的錢買最壞的用戶體驗(yàn)。最后再分享一個(gè)小技巧上線之后不要急著鋪開全量文檔選一個(gè)業(yè)務(wù)高頻問題集中的小部門做灰度看真實(shí)問題命中率配合后臺(tái)日志持續(xù)迭代。我見過不少項(xiàng)目在演示環(huán)境里效果驚艷一上線就被真實(shí)提問擊穿原因就是演示問題都是提前挑好的。讓知識(shí)庫在日常問題里保持高命中率比一次性喂幾千份文檔更重要。