最近這半年幾乎每隔幾天就有人拿著公司內(nèi)部文檔來找我員工手冊(cè)、項(xiàng)目驗(yàn)收?qǐng)?bào)告、新產(chǎn)品培訓(xùn)資料、客服話術(shù)庫(kù)……問題都差不多——能不能讓大模型直接基于這些資料回答問題做成一個(gè)內(nèi)部問答機(jī)器人能而且現(xiàn)在做起來的成本比大多數(shù)人想象中低很多。答案就是RAG全稱Retrieval-Augmented Generation檢索增強(qiáng)生成。我第一次搭完一套能跑的RAG智能問答助手只花了兩天從文檔清洗、切片入庫(kù)到檢索驗(yàn)證、接入對(duì)話模型再上線跑通。這篇文章就把整個(gè)過程中的關(guān)鍵原理、每一步的具體操作以及運(yùn)行一周后踩到的三個(gè)檢索質(zhì)量坑完整寫出來。適合有基本Python基礎(chǔ)、正準(zhǔn)備給團(tuán)隊(duì)做私有知識(shí)庫(kù)問答的系統(tǒng)開發(fā)者參考。原理部分我用最直白的說法講清楚實(shí)操部分直接給可運(yùn)行的代碼。1. 為什么我需要一個(gè)“會(huì)查資料”的問答助手1.1 對(duì)話模型再?gòu)?qiáng)也答不好沒讓它看過的資料先說個(gè)我實(shí)際遇到的場(chǎng)景。某公司人力部門想用大模型回答員工關(guān)于考勤、請(qǐng)假、報(bào)銷的問題于是直接把員工手冊(cè)扔給通用對(duì)話模型問“年假怎么算”。結(jié)果模型給出的答案和公司手冊(cè)對(duì)不上反而更像網(wǎng)上的勞動(dòng)法規(guī)科普。原因并不復(fù)雜。大模型的本質(zhì)是一個(gè)基于海量文本訓(xùn)練出來的“下一個(gè)詞預(yù)測(cè)器”它記住的是互聯(lián)網(wǎng)上的通用規(guī)律和常識(shí)并不天然知道某個(gè)公司內(nèi)部手冊(cè)里寫了什么。訓(xùn)練數(shù)據(jù)里沒有你的員工手冊(cè)、沒有你的產(chǎn)品文檔、沒有你的項(xiàng)目驗(yàn)收?qǐng)?bào)告它當(dāng)然不可能憑空編出正確答案。更麻煩的是模型存在知識(shí)截止時(shí)間就算你試了很多提示詞技巧它也不可能知道手冊(cè)今年剛修訂的條款。所以想讓模型回答私有領(lǐng)域的問題唯一可靠的做法是把相關(guān)資料作為上下文“喂”給它讓它邊查資料邊回答。開卷考試永遠(yuǎn)比閉卷考試靠譜這就是RAG的核心思路。把文檔提前切好、存好等用戶提問時(shí)先檢索出相關(guān)片段再讓模型基于這些片段作答。1.2 RAG與微調(diào)的邊界誰解決什么問題為什么先嘗試RAG很多第一次接觸這個(gè)問題的人第一反應(yīng)是“那我去微調(diào)一個(gè)模型”。這我特別理解因?yàn)椤拔⒄{(diào)”聽起來更像一勞永逸的方案把知識(shí)直接寫進(jìn)模型參數(shù)里之后調(diào)用就不用帶資料了。但實(shí)際做過幾次微調(diào)項(xiàng)目之后我現(xiàn)在的結(jié)論是除非你的需求是改變模型的行為風(fēng)格、輸出格式或者做特定任務(wù)否則大多數(shù)“想讓模型知道某份資料”的需求都應(yīng)該先試RAG。我這么說的理由有三條。第一微調(diào)的成本高且周期長(zhǎng)每次資料更新都要重新訓(xùn)練一輪而RAG只是把文檔重新切塊入庫(kù)幾分鐘就能完成第二微調(diào)容易引入“災(zāi)難性遺忘”模型在學(xué)新知識(shí)的同時(shí)可能把原有的能力搞亂第三微調(diào)并不能根治幻覺模型在回答時(shí)依然可能“憑印象”發(fā)揮因?yàn)樗举|(zhì)上還是在閉卷作答。我之前遇到一個(gè)團(tuán)隊(duì)想做制度庫(kù)問答找外部資源微調(diào)了一個(gè)開源模型前前后后花了好幾周。結(jié)果上線后一問到訓(xùn)練數(shù)據(jù)里沒覆蓋的新制度模型照樣一本正經(jīng)地胡說。后來換成了RAG只做了一件事——把制度文檔切塊入庫(kù)回答時(shí)強(qiáng)制模型引用原文片段問題立刻解決。這個(gè)對(duì)比讓我印象很深知識(shí)更新的場(chǎng)景里RAG不是“備選方案”而是“首選方案”。2. RAG四大環(huán)節(jié)拆解從切文檔到生成回答2.1 索引階段把PDF變成一顆“可檢索的樹”整個(gè)RAG管道可以拆成四個(gè)階段索引、檢索、增強(qiáng)、生成。我建議先別急著寫代碼把這四個(gè)環(huán)節(jié)吃透后面遇到問題才能定位到具體環(huán)節(jié)。第一個(gè)階段是索引也有人叫“入庫(kù)”。原始文檔通常是一份幾十頁的PDF或Word模型一次只能讀有限的上下文不能把整本手冊(cè)全塞進(jìn)去。所以第一步是把文檔拆成一個(gè)個(gè)“片段”行業(yè)內(nèi)叫chunk。為什么要切塊如果一整本手冊(cè)作為一個(gè)片段向量的語義信息會(huì)被平均掉檢索時(shí)根本無法精確找到“年假怎么算”對(duì)應(yīng)的那一頁如果切得太碎比如按一句話切又容易丟失上下文導(dǎo)致檢索回來的片段只有半句結(jié)論沒有前因后果。我常用的做法是先把Word或PDF解析成純文本去掉頁眉、頁腳、頁碼和目錄這些噪聲然后按標(biāo)題層級(jí)和段落語義把內(nèi)容切成大約500個(gè)token一個(gè)的chunk每個(gè)chunk會(huì)記錄來源章節(jié)、頁碼等元信息。這一步很像給一本書做目錄和小結(jié)只不過這個(gè)“小結(jié)”是后續(xù)檢索的最小單位。切好塊之后要做的是Embedding也就是把每段文字轉(zhuǎn)成一組向量?？梢源直┑乩斫鉃榻o每段文字在“語義空間”里標(biāo)一個(gè)坐標(biāo)語義越接近的文字坐標(biāo)距離越近。這樣用戶提問時(shí)我只需要把問題也轉(zhuǎn)成向量就能在庫(kù)里找最接近的片段。最后這些向量會(huì)存進(jìn)向量數(shù)據(jù)庫(kù)傳統(tǒng)數(shù)據(jù)庫(kù)按字段查詢向量庫(kù)專門做高維向量的相似度搜索返回“語義上最相似”的TopN條記錄。2.2 檢索階段向量找相近關(guān)鍵詞找精確兩者不矛盾第二個(gè)階段是檢索。用戶輸入一個(gè)問題系統(tǒng)先把它做同樣的Embedding再用余弦距離等方式和庫(kù)里的所有片段向量做最近鄰搜索返回得分最高的前幾個(gè)片段。這里有一個(gè)大多數(shù)人第一次做RAG容易踩的認(rèn)知誤區(qū)以為向量檢索能解決一切。其實(shí)向量檢索擅長(zhǎng)的是“語義相似”它對(duì)泛化表達(dá)、同義改寫特別有效。比如用戶問“離職要提前多久說”手冊(cè)里寫的是“解除勞動(dòng)合同需要提前通知”兩句話沒有共同詞匯但向量檢索能發(fā)現(xiàn)它們語義相近。但它也有明顯短板對(duì)專有名詞、編號(hào)、縮寫、精確型號(hào)很鈍感。公司內(nèi)部系統(tǒng)簡(jiǎn)稱“DSAP”手冊(cè)里全稱“業(yè)務(wù)數(shù)據(jù)支撐平臺(tái)”用戶問“DSAP怎么登錄”向量檢索很可能召回不到。這時(shí)候需要關(guān)鍵詞檢索來兜底比如BM25這種經(jīng)典算法它按字面重合度打分看到“DSAP”就直接命中原文。所以生產(chǎn)級(jí)RAG現(xiàn)在普遍做混合檢索向量召回一批語義相近的關(guān)鍵詞召回一批字面精確的再把兩批結(jié)果合并去重。用生活化的說法向量檢索像“靠意思找人”關(guān)鍵詞檢索像“看身份證認(rèn)人”兩者互補(bǔ)才是完整的檢索能力。2.3 增強(qiáng)與生成把“證據(jù)片段”塞進(jìn)提示詞里第三個(gè)階段叫增強(qiáng)很多人把它理解成簡(jiǎn)單的“拼字符串”其實(shí)沒那么簡(jiǎn)單。核心是把檢索到的若干片段整理成有結(jié)構(gòu)的上下文塞進(jìn)提示詞模板里讓模型閱讀這些片段之后再作答。我常用的提示詞模板長(zhǎng)這樣你是一名企業(yè)內(nèi)部知識(shí)庫(kù)問答助手。請(qǐng)只根據(jù)以下提供的資料片段來回答用戶的問題。 回答要求 1. 如果資料中有明確依據(jù)請(qǐng)先給出結(jié)論再引用對(duì)應(yīng)片段編號(hào)說明依據(jù)。 2. 如果資料中沒有相關(guān)信息請(qǐng)直接回答“資料中未找到相關(guān)內(nèi)容”不要自行推測(cè)。 3. 不要使用資料之外的常識(shí)進(jìn)行補(bǔ)充除非你明確說明這是推測(cè)。 資料片段 [1]來源員工手冊(cè) 第3章 考勤管理 內(nèi)容... [2]來源員工手冊(cè) 第4章 休假制度 內(nèi)容... 用戶問題試用期離職需要提前幾天申請(qǐng)最后一個(gè)階段是生成。模型拿到增強(qiáng)后的提示詞在自己的語言能力幫助下從給定的片段里提取并組織答案。這里有個(gè)關(guān)鍵參數(shù)溫度。我會(huì)在RAG場(chǎng)景里把temperature調(diào)到0或接近0因?yàn)槲覀円氖侵矣谫Y料的答案而不是發(fā)散創(chuàng)造。整個(gè)鏈路的名稱也由此而來先Retrieval檢索再Augmented增強(qiáng)提示詞最后Generation生成答案。3. 環(huán)境準(zhǔn)備與選型我需要準(zhǔn)備哪些工具和模型3.1 選型對(duì)照三套可落地方案我實(shí)際跑過的體驗(yàn)了解了原理接下來是選型。很多教程一上來就推薦一大堆框架反而把初學(xué)者搞暈。我按落地成本和資源條件把實(shí)際跑過的組合分成三套方案Embedding模型生成模型向量庫(kù)適合場(chǎng)景方案A全API調(diào)用供應(yīng)商的Embedding接口通用對(duì)話大模型APIChroma本地持久化快速原型驗(yàn)證不想折騰GPU方案B混合部署本地開源Embedding模型CPU可跑通用對(duì)話大模型APIChroma或FAISS數(shù)據(jù)量不大、對(duì)檢索延遲有要求方案C全本地本地開源Embedding模型本地量化開源對(duì)話模型Milvus或Qdrant數(shù)據(jù)敏感、必須離線部署我個(gè)人的建議是第一次跑通直接用方案A或方案B先驗(yàn)證效果不要一上來就追求全本地。全本地方案要處理GPU資源、模型量化、推理框架等問題學(xué)習(xí)曲線陡很多。我曾經(jīng)幫某公司做過一個(gè)內(nèi)部知識(shí)庫(kù)Demo一開始就上全本地結(jié)果一周時(shí)間大部分花在部署模型上業(yè)務(wù)方連效果都沒看到。后來改成方案B一天就把Demo跑起來了效果反饋好之后再慢慢規(guī)劃本地化。Embedding模型方面我常用的做法是優(yōu)先選開源中文表現(xiàn)穩(wěn)定的模型例如bge系列或m3e系列。它們?cè)谥形恼Z義匹配上比很多通用多語言模型更討喜而且支持CPU推理幾百M(fèi)B內(nèi)存就能跑。向量庫(kù)的選擇上入門用Chroma足夠因?yàn)閜ip安裝就能用、數(shù)據(jù)自動(dòng)持久化在本地目錄適合中小知識(shí)庫(kù)數(shù)據(jù)量到百萬級(jí)向量以上再考慮Milvus這類分布式方案?？蚣芊矫鍸angChain和LlamaIndex確實(shí)能省不少代碼但我建議第一遍手寫把鏈路里每一行都搞明白之后再?zèng)Q定要不要上框架。3.2 環(huán)境搭建最容易忽略的依賴版本問題環(huán)境搭建的坑往往不在邏輯而在依賴版本。我給你們看一份我跑通全鏈路的最低依賴清單python3.10 chromadb0.4.24 sentence-transformers pypdf python-docx rank-bm25 openai我特別想提醒幾個(gè)坑。第一個(gè)是numpy版本沖突chromadb對(duì)numpy版本有要求如果你不小心裝了過新的numpy啟動(dòng)向量庫(kù)時(shí)大概率會(huì)報(bào)底層庫(kù)加載失敗解決辦法是把numpy固定到兼容版本再裝第二個(gè)是sentence-transformers和transformers、torch三者之間有版本聯(lián)動(dòng)建議在干凈虛擬環(huán)境里一次裝齊不要零散安裝第三個(gè)是中文路徑問題Chroma持久化目錄如果包含中文或特殊字符某些版本下會(huì)報(bào)錯(cuò)項(xiàng)目目錄最好用英文。另外如果你手頭沒有獨(dú)立GPU生成模型部分要走API路線這樣開發(fā)機(jī)上只需要跑Embedding一個(gè)普通的CPU實(shí)例就能撐住。如果你堅(jiān)持本地部署7B量級(jí)的對(duì)話模型建議量化到4bit并且準(zhǔn)備至少6GB以上顯存否則推理速度會(huì)讓人失去耐心。裝完環(huán)境后先跑一個(gè)最小的“文檔-檢索-回答”閉環(huán)Demo成功之后再往里填業(yè)務(wù)數(shù)據(jù)這是效率最高的推進(jìn)方式。4. 手把手搭一個(gè)“某公司員工手冊(cè)問答”Demo4.1 第一步文檔清洗與切分這一步?jīng)Q定了后面90%的質(zhì)量實(shí)踐部分我以一個(gè)虛擬的“某公司員工手冊(cè)”為例假設(shè)它是大約120頁的Word文檔包含考勤、休假、薪酬、報(bào)銷、保密等章節(jié)。我會(huì)帶著你把完整鏈路跑一遍。文檔清洗是這個(gè)步驟里最臟最累的活但絕對(duì)值得做。我的標(biāo)準(zhǔn)流程是先用python-docx把Word轉(zhuǎn)成純文本然后用正則把頁眉、頁腳、頁碼、目錄項(xiàng)剝掉再把“第X章”和“X.X”這類標(biāo)題單獨(dú)標(biāo)記出來。不要小看這一步很多項(xiàng)目后來檢索效果差查到最后發(fā)現(xiàn)是清洗階段把章節(jié)標(biāo)題弄丟了導(dǎo)致語義單元全亂。清洗完成后就是切分。我寫了一個(gè)比較穩(wěn)的切分函數(shù)原則是“優(yōu)先按標(biāo)題層級(jí)其次按自然段合并”import re def split_into_chunks(text, max_tokens500, overlap_tokens80): # 先把標(biāo)題行識(shí)別出來 lines text.split(\n) chunks [] current_chunk current_title for line in lines: stripped line.strip() if not stripped: continue # 以“第X章”、“X.X”、“X.X.X”為標(biāo)題邊界 if re.match(r^(第[一二三四五六七八九十百千]章|\d(\.\d)*), stripped): if current_chunk: chunks.append({ title: current_title, content: current_chunk.strip() }) current_title stripped current_chunk stripped continue current_chunk \n stripped # 簡(jiǎn)單估算token數(shù)超過閾值就切一段 if len(current_chunk) max_tokens * 1.3: chunks.append({ title: current_title, content: current_chunk.strip() }) # 保留尾部少量token作為重疊避免邊界斷語義 overlap current_chunk[-overlap_tokens:] current_chunk overlap if current_chunk: chunks.append({ title: current_title, content: current_chunk.strip() }) return chunks這段代碼核心思想是當(dāng)遇到一個(gè)新的章節(jié)標(biāo)題時(shí)把上一個(gè)chunk保存下來當(dāng)chunk長(zhǎng)度超標(biāo)時(shí)保留最后幾十個(gè)token作為下一個(gè)chunk的開頭這樣“年假滿10年”和“年假滿20年”這類被切到不同塊的內(nèi)容至少會(huì)有一小段交叉不至于徹底斷裂。切分結(jié)果里我給每個(gè)chunk帶了title字段后面檢索時(shí)可以直接展示“來源章節(jié)”這對(duì)用戶確認(rèn)答案非常有用。4.2 第二步Embedding入庫(kù)與檢索驗(yàn)證切完之后就是向量化入庫(kù)。這里我強(qiáng)烈建議單獨(dú)寫一個(gè)初始化腳本而不是在問答主程序里每次重新嵌入因?yàn)镋mbedding幾百個(gè)chunk雖然快但每次啟動(dòng)都跑一遍就太浪費(fèi)了。from sentence_transformers import SentenceTransformer import chromadb # 加載Embedding模型CPU即可第一次運(yùn)行會(huì)下載權(quán)重 model SentenceTransformer(bge-m3) # 創(chuàng)建Chroma客戶端數(shù)據(jù)持久化到本地 ./rag_db 目錄 client chromadb.PersistentClient(path./rag_db) collection client.get_or_create_collection( nameemployee_handbook, metadata{hnsw:space: cosine} # 用余弦距離衡量語義相近程度 ) # 假設(shè)chunks是上一節(jié)切分得到的list ids [fchunk_{i} for i in range(len(chunks))] documents [c[content] for c in chunks] metadatas [{title: c[title]} for c in chunks] # 成批轉(zhuǎn)為向量并寫入 embeddings model.encode(documents, normalize_embeddingsTrue).tolist() collection.add( idsids, documentsdocuments, metadatasmetadatas, embeddingsembeddings )入庫(kù)之后不要急著接大模型先做一步純檢索驗(yàn)證。這一步很關(guān)鍵如果檢索階段拿回來的片段就是錯(cuò)的后面接什么模型都救不回來。def search(query, top_k5): q_emb model.encode([query], normalize_embeddingsTrue).tolist() results collection.query( query_embeddingsq_emb, n_resultstop_k, include[documents, metadatas, distances] ) return results # 驗(yàn)證一下“試用期離職”這個(gè)問題 results search(試用期員工提出離職需要提前幾天) for i, doc in enumerate(results[documents][0]): title results[metadatas][0][i][title] print(fTop{i1} [來源:{title}] {doc[:100]}...)我實(shí)際跑這段時(shí)發(fā)現(xiàn)前兩條確實(shí)命中了休假制度相關(guān)章節(jié)但第三條已經(jīng)開始跑偏回到了考勤章節(jié)。這說明單靠向量檢索的前3個(gè)結(jié)果里有噪聲正?，F(xiàn)象后面我重排序章節(jié)會(huì)專門處理。但至少這一步能讓你直觀感受到“檢索質(zhì)量”是什么也方便后續(xù)做參數(shù)調(diào)優(yōu)。4.3 第三步把檢索結(jié)果組裝成Prompt并接入對(duì)話模型檢索驗(yàn)證通過后接生成模型就只剩最后一步了組裝提示詞調(diào)用接口。我習(xí)慣把所有上下文片段編號(hào)然后要求模型在回答時(shí)標(biāo)注編號(hào)這樣用戶能對(duì)照原始文檔也方便排查問題。def build_prompt(query, search_results): context_lines [] for i, doc in enumerate(search_results[documents][0]): title search_results[metadatas][0][i][title] context_lines.append(f[{i1}]來源{title}\n{doc}) prompt f你是一名企業(yè)內(nèi)部知識(shí)庫(kù)問答助手請(qǐng)只根據(jù)以下資料片段回答用戶問題。 如果資料中沒有明確依據(jù)請(qǐng)回答“資料中未找到相關(guān)內(nèi)容”不要自行推測(cè)。 回答時(shí)先給結(jié)論再引用片段編號(hào)說明依據(jù)。 資料片段 {chr(10).join(context_lines)} 用戶問題{query} return prompt對(duì)話模型的接入現(xiàn)在大部分服務(wù)端都提供兼容格式的接口調(diào)用方式大同小異。我用一個(gè)通用的OpenAI SDK風(fēng)格示例from openai import OpenAI client OpenAI( api_key你的密鑰, base_url你的模型服務(wù)地址 ) def ask(query): results search(query, top_k5) prompt build_prompt(query, results) resp client.chat.completions.create( model你的模型名稱, messages[ {role: system, content: 你是嚴(yán)謹(jǐn)?shù)闹R(shí)庫(kù)問答助手。}, {role: user, content: prompt} ], temperature0.0, # 關(guān)鍵RAG場(chǎng)景追求確定性不要發(fā)散 streamFalse ) answer resp.choices[0].message.content return answer, results # 試一下 answer, results ask(試用期員工提出離職需要提前幾天) print(answer)跑完之后你會(huì)看到模型根據(jù)檢索到的片段給出了帶編號(hào)依據(jù)的回答。這一步完成后一個(gè)最樸素的RAG系統(tǒng)就已經(jīng)能用了。接下來真正拉開差距的是上線之后那些“看著能用但經(jīng)常出錯(cuò)”的細(xì)節(jié)問題。5. 運(yùn)行兩天后遇到的三類檢索質(zhì)量問題和我的修復(fù)方案5.1 “答案被攔腰切斷”——chunk邊界設(shè)計(jì)不當(dāng)系統(tǒng)運(yùn)行到第二天有人來問“全年帶薪年假天數(shù)怎么算”。模型回答里只寫了“工作滿1年不滿10年享受5天年假”后半段“滿10年不滿20年享受10天”完全沒出現(xiàn)。用戶一看就反饋“答案不完整”。我第一反應(yīng)是調(diào)大生成模型的上下文沒用。后來把檢索返回的片段打出來一看才發(fā)現(xiàn)命中的前3個(gè)chunk里只有第一個(gè)chunk包含了“滿1年不滿10年”的部分而“滿10年不滿20年”位于同一個(gè)小節(jié)的下一段被切分函數(shù)分到了另一個(gè)chunk且那個(gè)chunk的相似度排名掉到了第6名以外。這個(gè)案例讓我意識(shí)到切分不能只看token數(shù)還要考慮語義單元。同一類規(guī)則最好放在同一個(gè)chunk里。我的修復(fù)方案是兩件事第一把“年假規(guī)則”這一類小節(jié)整體設(shè)為一個(gè)chunk而不是機(jī)械地按長(zhǎng)度切第二把默認(rèn)top_k從3提升到召回20條之后再做重排避免因?yàn)榕琶▌?dòng)漏掉關(guān)鍵片段。修復(fù)后重新測(cè)試完整答案回來了。5.2 “看起來很有道理但完全不對(duì)”——需要重排序而不是單純信任TopK另一個(gè)經(jīng)典問題是“幻覺型錯(cuò)誤”。有員工問“如何申請(qǐng)加班調(diào)休”模型居然按照“加班工資”的規(guī)則回答了一大段。單獨(dú)看那一段結(jié)構(gòu)和口吻都很正經(jīng)但完全不是用戶想要的。查日志后我發(fā)現(xiàn)檢索階段返回的片段里確實(shí)包含“加班工資”的段落而且和“加班調(diào)休”的向量相似度很高。問題在于向量檢索擅長(zhǎng)找“語義相近”但不擅長(zhǎng)判斷“意圖相關(guān)”。在向量空間里“加班調(diào)休”和“加班工資”的距離可能比“加班調(diào)休”和“請(qǐng)假流程”還近所以單純按照向量相似度排序正確答案經(jīng)常排在錯(cuò)誤答案后面。解決辦法是在向量召回之后加一層重排序。我引入了cross-encoder類型的中文重排序模型比如bge-reranker系列。它的做法不是先轉(zhuǎn)成向量再比距離而是把“用戶問題”和“每個(gè)候選片段”一起拼起來輸入模型逐對(duì)打分精度更高代價(jià)是速度慢所以只對(duì)召回后的候選集做。具體代碼如下from transformers import AutoModelForSequenceClassification, AutoTokenizer rerank_model_name bge-reranker-v2-m3 tokenizer AutoTokenizer.from_pretrained(rerank_model_name) rerank_model AutoModelForSequenceClassification.from_pretrained(rerank_model_name) def rerank(query, candidates): pairs [[query, doc] for doc in candidates] inputs tokenizer(pairs, paddingTrue, truncationTrue, return_tensorspt) scores rerank_model(**inputs).logits.view(-1).tolist() # 返回按得分降序的索引 return sorted(range(len(scores)), keylambda i: scores[i], reverseTrue) # 假設(shè)從向量檢索取回20個(gè)候選 results search(如何申請(qǐng)加班調(diào)休, top_k20) candidates list(results[documents][0]) ranked_idx rerank(如何申請(qǐng)加班調(diào)休, candidates) # 只取重排后前2個(gè)并過濾低分片段加上重排之后正確答案的排名明顯上升“加班工資”那段被壓下去了。這里還要配合一個(gè)閾值過濾相關(guān)性得分低于某個(gè)值的片段直接丟棄寧可不答也不要拿無關(guān)資料硬答。閾值需要在你的具體語料上調(diào)沒有一個(gè)萬能值我在這套手冊(cè)上取的是0.4左右。5.3 “明明有文檔卻沒檢索到”——混合檢索補(bǔ)漏第三個(gè)問題最隱蔽。有人問“班車T3線?？磕男┱军c(diǎn)”系統(tǒng)回答“資料中未找到相關(guān)內(nèi)容”但我用關(guān)鍵詞在庫(kù)里人工搜明明有這段寫的是“通勤車三號(hào)線”。這就是我之前提到的向量檢索對(duì)編號(hào)、縮寫的盲區(qū)?！癟3線”這種寫法和“三號(hào)線”在向量空間里的距離并不近尤其是在既有中文字符又有字母數(shù)字混合的情況下。光靠向量召回就是找不到。修復(fù)方案是加混合檢索。我在系統(tǒng)里維護(hù)了一套BM25關(guān)鍵詞索引對(duì)每個(gè)chunk做關(guān)鍵詞打分然后把BM25召回的結(jié)果和向量召回的結(jié)果合并去重后一起進(jìn)入重排階段。這樣即使是完全靠字面匹配才能找到的內(nèi)容也能被撈回來。核心實(shí)現(xiàn)不復(fù)雜。先對(duì)文檔做分詞然后基于詞頻建立倒排索引查詢的時(shí)候同時(shí)算BM25得分。當(dāng)然生產(chǎn)環(huán)境如果已經(jīng)有了Elasticsearch直接用它的BM25能力會(huì)更省事。我在這套Demo里的做法是引入rank-bm25庫(kù)配合jieba分詞做中文適配代碼大致這樣import jieba from rank_bm25 import BM25Okapi # 初始化時(shí)構(gòu)建BM25索引 tokenized_chunks [list(jieba.cut(c[content])) for c in chunks] bm25 BM25Okapi(tokenized_chunks) def hybrid_search(query, top_k_from_vector20, top_k_from_bm2520, final_top_k5): # 向量召回 vec_results search(query, top_ktop_k_from_vector) # BM25召回 query_tokens list(jieba.cut(query)) bm25_scores bm25.get_scores(query_tokens) bm25_top_indices sorted(range(len(bm25_scores)), keylambda i: bm25_scores[i], reverseTrue)[:top_k_from_bm25] # 合并去重后統(tǒng)一重排 candidate_set set() for doc in vec_results[documents][0]: candidate_set.add(doc) for idx in bm25_top_indices: candidate_set.add(chunks[idx][content]) candidates list(candidate_set) # 進(jìn)入重排階段取前N個(gè)這一版改完之后T3線的問題解決了順帶把“DSAP系統(tǒng)無法登錄”這類縮寫問題也解決了一大半。到這一步這個(gè)RAG系統(tǒng)才算真正具備了一點(diǎn)“能用”的底氣。6. 這套系統(tǒng)上線前必須做好的三件事評(píng)估、兜底、成本6.1 用一個(gè)小腳本評(píng)估“有沒有答對(duì)”很多團(tuán)隊(duì)把RAG跑通就上線然后靠用戶罵罵咧咧來發(fā)現(xiàn)問題這個(gè)成本太不可控了。我現(xiàn)在的習(xí)慣是上線前先準(zhǔn)備至少二三十條問答測(cè)試集覆蓋典型問題、邊界問題、否定表述、縮寫問題這幾類然后做一個(gè)半自動(dòng)評(píng)估。評(píng)估分兩層。第一層看檢索命中率給定問題檢索返回的前幾個(gè)片段里有沒有包含答案所在的原始段落如果檢索都錯(cuò)了生成一定錯(cuò)問題出在索引和檢索環(huán)節(jié)第二層看生成正確率模型給出的答案內(nèi)容是否正確、是否忠于引用片段。第一層可以腳本化第二層目前最穩(wěn)的還是人工抽檢或者用一個(gè)獨(dú)立的評(píng)估模型來打分避免用回答模型自己給自己評(píng)分。我給團(tuán)隊(duì)寫過一個(gè)簡(jiǎn)單的評(píng)估腳本邏輯就是遍歷測(cè)試集調(diào)用系統(tǒng)拿到答案和引用片段然后讓另一個(gè)模型按1到5分評(píng)估答案和標(biāo)準(zhǔn)答案的一致程度。分?jǐn)?shù)低于3的自動(dòng)進(jìn)入bad case清單每周人工過一遍。這套機(jī)制價(jià)值不在于精確測(cè)量而在于讓質(zhì)量波動(dòng)可見并且給后續(xù)優(yōu)化提供方向。6.2 兜底策略不知道勝過一本正經(jīng)胡說RAG的底線不是“每個(gè)問題都答得很漂亮”而是“答錯(cuò)的成本可控”。我做過一個(gè)很重要的設(shè)定當(dāng)檢索結(jié)果的最高相關(guān)性得分低于閾值時(shí)系統(tǒng)不進(jìn)入生成環(huán)節(jié)直接返回“資料中暫時(shí)未找到相關(guān)內(nèi)容請(qǐng)補(bǔ)充關(guān)鍵詞或咨詢相關(guān)部門”。這比讓模型硬答更安全尤其是面向企業(yè)內(nèi)部員工時(shí)錯(cuò)誤答案造成的信任損失遠(yuǎn)大于“不知道”帶來的不便。同時(shí)在提示詞里反復(fù)強(qiáng)調(diào)“未找到就直說”并把“不要自行推測(cè)”寫成強(qiáng)制性要求?；卮鸬恼故卷撁嫔弦矔?huì)把命中的原文片段一并展示出來用戶自己能核對(duì)答案出處。這個(gè)設(shè)計(jì)看起來樸素但對(duì)提升可信度非常有效很多用戶反饋“能看到來源答錯(cuò)了也敢相信”。6.3 成本賬用300頁文檔運(yùn)行一個(gè)月大概花多少錢最后算一筆賬讓大家心里有數(shù)。假設(shè)員工手冊(cè)清洗后約有3000到5000個(gè)chunk取決于切分粒度Embedding這一步如果是本地CPU跑基本就是一次性幾十分鐘的電費(fèi)如果走API的Embedding接口按token計(jì)費(fèi)幾千個(gè)chunk總共也就幾十萬token費(fèi)用可以忽略。向量庫(kù)存儲(chǔ)更是小頭幾千條向量也就幾MB。真正的成本在問答階段。每一輪問答需要把用戶問題做一次Embedding再把檢索到的幾百上千token片段和生成結(jié)果一起消耗模型token。假設(shè)一次問答約消耗1500個(gè)token的總輸入輸出如果每天200次問答、一個(gè)月6000次用通用API模型一個(gè)月的花費(fèi)大約在幾十到幾百元量級(jí)具體取決于你選的模型檔位。如果改成全本地部署主要是硬件折舊和電費(fèi)一次投入買一塊消費(fèi)級(jí)顯卡就能撐住不少并發(fā)。聽起來是不是不算貴但我要提醒RAG真正的隱性成本不是算力而是人工。文檔版本管理、切片邊界維護(hù)、bad case跟進(jìn)、用戶反饋迭代這些都需要有人持續(xù)投入。如果文檔本身寫得含糊不清RAG的上限也就到那里了。上線前最好明確由誰負(fù)責(zé)定期更新知識(shí)庫(kù)內(nèi)容這比研究任何技術(shù)參數(shù)都重要。最后分享一個(gè)小經(jīng)驗(yàn)不要等系統(tǒng)上線后才開始積累bad case。從第一天起我就習(xí)慣把每天的query、答案、命中的原文片段全部記錄到日志里每周固定半小時(shí)翻一遍錯(cuò)誤案例。這件事堅(jiān)持下來你會(huì)發(fā)現(xiàn)大部分問題都出在文檔本身寫得不夠清楚或者切塊不合理上而不是模型不夠強(qiáng)。先把手頭文檔整理干凈比換更貴的模型管用得多。RAG系統(tǒng)的價(jià)值上限約等于你文檔整潔程度的上限。