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