簡(jiǎn)介這份PDF是一份面向AI應(yīng)用開(kāi)發(fā)者與架構(gòu)師的技術(shù)參考資料聚焦如何將RAG檢索增強(qiáng)生成技術(shù)與DeepSeek模型深度整合并圍繞行業(yè)知識(shí)庫(kù)的構(gòu)建給出完整的API設(shè)計(jì)范式。文檔從RAG基本原理與DeepSeek架構(gòu)特點(diǎn)切入系統(tǒng)梳理數(shù)據(jù)采集、預(yù)處理、知識(shí)表示與存儲(chǔ)、模型微調(diào)等知識(shí)庫(kù)構(gòu)建環(huán)節(jié)并重點(diǎn)講解API設(shè)計(jì)中的可擴(kuò)展性、安全性、易用性與性能原則涵蓋知識(shí)檢索、生成、更新三類(lèi)接口的定義、實(shí)現(xiàn)方法及配套代碼示例。內(nèi)容還包含醫(yī)療、金融、教育等行業(yè)案例以及API測(cè)試優(yōu)化與未來(lái)趨勢(shì)展望。資源為單個(gè)PDF文件共29頁(yè)壓縮包大小約2.02MB目錄完整、圖文清晰便于按章節(jié)查閱。目前已有99人學(xué)習(xí)使用適合需要落地大模型知識(shí)庫(kù)應(yīng)用或設(shè)計(jì)相關(guān)服務(wù)接口的技術(shù)人員參考。1. RAG技術(shù)深度整合為什么行業(yè)知識(shí)庫(kù)繞不開(kāi)API設(shè)計(jì)這道坎把DeepSeek接進(jìn)RAG流程、再包一層API給業(yè)務(wù)方調(diào)用這件事單看每一步都不難但真正讓它從“能跑”變成“能上線”的恰恰是那層最容易被人當(dāng)牛皮紙一樣帶過(guò)的API設(shè)計(jì)。RAG技術(shù)深度整合這件事難點(diǎn)從來(lái)不在“調(diào)通一個(gè)大模型”而在于檢索出來(lái)的內(nèi)容怎么組織進(jìn)Prompt、多輪會(huì)話怎么控制上下文、命中結(jié)果怎么溯源以及整套邏輯怎么以穩(wěn)定的接口形態(tài)暴露給前端和業(yè)務(wù)系統(tǒng)。這篇筆記基于用DeepSeek構(gòu)建行業(yè)知識(shí)庫(kù)的實(shí)戰(zhàn)經(jīng)驗(yàn)把API設(shè)計(jì)范式拆開(kāi)來(lái)講覆蓋檢索鏈路、切塊參數(shù)、接口契約與真實(shí)踩坑給正在做知識(shí)庫(kù)問(wèn)答的工程師一條能直接落地的路徑。2. 從DeepSeek選型到RAG架構(gòu)先把檢索生成的骨架立住2.1 DeepSeek在RAG里的定位生成器選型與參數(shù)邊界行業(yè)知識(shí)庫(kù)的RAG系統(tǒng)里DeepSeek扮演的是生成器Generator不是檢索器。它負(fù)責(zé)讀入“檢索到的證據(jù)片段 用戶問(wèn)題”然后生成回答。選它做生成器常見(jiàn)做法是看重它在中英文混合場(chǎng)景下的生成質(zhì)量以及開(kāi)源權(quán)重配合自部署帶來(lái)的數(shù)據(jù)私密性——行業(yè)知識(shí)庫(kù)往往涉及工藝參數(shù)、內(nèi)部規(guī)范這類(lèi)敏感內(nèi)容把數(shù)據(jù)送到外部API總歸不踏實(shí)。既然是自部署模型參數(shù)就繞不開(kāi)。以DeepSeek系列模型為例部署時(shí)常見(jiàn)做法是用vLLM或SGLang做推理服務(wù)前者吞吐表現(xiàn)好后者在長(zhǎng)上下文場(chǎng)景下更穩(wěn)。我自己一般會(huì)先用vLLM跑通因?yàn)樗腛penAI兼容接口可以直接復(fù)用現(xiàn)有SDK省去一層適配。啟動(dòng)命令大致是vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-14B \ --served-model-name deepseek-rag \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --port 8000這個(gè)命令里值得注意的參數(shù)是--gpu-memory-utilization不要貪心設(shè)成0.98推理時(shí)的KV Cache會(huì)隨時(shí)漲留出一點(diǎn)余量給CUDA context和碎片。--max-model-len設(shè)32768意味著單次輸入輸出總token不能超過(guò)這個(gè)值后面設(shè)計(jì)API時(shí)所有上下文截?cái)噙壿嫸嫉脟@這個(gè)上限來(lái)做。選型上還有一條邊界要?jiǎng)澢宀皇撬袌?chǎng)景都需要滿血版R1這樣的推理模型。行業(yè)知識(shí)庫(kù)里的問(wèn)題大多是“某個(gè)參數(shù)的范圍是多少”“某條流程的下一步是什么”這類(lèi)事實(shí)性問(wèn)題用蒸餾后的Qwen系列就夠推理模型反而會(huì)因?yàn)樗季S鏈太長(zhǎng)拖慢首token響應(yīng)。如果業(yè)務(wù)方要求每個(gè)回答都給出推理過(guò)程再用大推理模型不遲。2.2 混合檢索鏈路關(guān)鍵詞召回與向量召回的互補(bǔ)邏輯RAG的檢索層是整套系統(tǒng)的命脈檢索質(zhì)量直接決定生成質(zhì)量。行業(yè)知識(shí)庫(kù)有一個(gè)顯著特征大量問(wèn)法里的關(guān)鍵詞和文檔原文高度重合比如“閥門(mén)泄漏處理流程”這種短語(yǔ)用戶就是這么問(wèn)的文檔里也大概率有這句話。純向量檢索在這種場(chǎng)景下反而可能因?yàn)檎Z(yǔ)義向量化把“閥門(mén)”和“泄漏”拆散到不同維度導(dǎo)致召回的片段不夠完整。我一般會(huì)做混合檢索ES的BM25關(guān)鍵詞召回 向量庫(kù)的語(yǔ)義召回再用RRFReciprocal Rank Fusion合并排序。這樣既保住了“原文命中”的精確性又覆蓋了“換個(gè)說(shuō)法也能搜到”的泛化需求。檢索服務(wù)的偽代碼示意def hybrid_search(query: str, top_k: int 8) - list[Document]: # 關(guān)鍵詞召回走ES的match查詢重視詞面重合 bm25_hits es.search( indexindustry_kb, body{query: {match: {content: query}}, size: top_k} ) # 向量召回走向量庫(kù)的相似度檢索 query_vec embed_model.encode(query) vec_hits vector_db.search(query_vec, top_ktop_k) # RRF合并兩個(gè)列表按排名加權(quán)而不是按分?jǐn)?shù)加權(quán) return rrf_merge(bm25_hits, vec_hits, k60)RRF合并里有個(gè)初學(xué)者容易忽略的細(xì)節(jié)為什么用排名而不是用相似度分?jǐn)?shù)因?yàn)锽M25的分?jǐn)?shù)和向量余弦相似度不在同一個(gè)量綱上直接加和等于誰(shuí)的分?jǐn)?shù)范圍大誰(shuí)說(shuō)了算。RRF只關(guān)心每條文檔在兩個(gè)列表里的名次公式是score sum(1 / (k rank))k取60是Lucene社區(qū)常用的經(jīng)驗(yàn)值實(shí)際調(diào)參時(shí)可以在這個(gè)基礎(chǔ)上微調(diào)。檢索層還要處理一個(gè)工程問(wèn)題行業(yè)知識(shí)庫(kù)的文檔經(jīng)常有版本迭代“GB/T 12345-2024”和“GB/T 12345-2017”可能同時(shí)存在。檢索時(shí)如果只做語(yǔ)義相似度新舊版本會(huì)被同時(shí)命中生成器就不知道該聽(tīng)誰(shuí)的。常見(jiàn)做法是在ES索引里把標(biāo)準(zhǔn)號(hào)和版本號(hào)做成獨(dú)立字段檢索時(shí)帶上版本過(guò)濾條件這個(gè)后文在API設(shè)計(jì)里會(huì)再展開(kāi)。3. 把行業(yè)文檔變成可檢索的知識(shí)從解析、切塊到入庫(kù)3.1 文檔解析與圖片類(lèi)知識(shí)的處理行業(yè)知識(shí)庫(kù)的源文件格式相當(dāng)雜Word、PDF、掃描件、Excel參數(shù)表、還有大量圖片形式的設(shè)備銘牌和流程圖。RAG對(duì)這塊的處理直接決定知識(shí)能不能被檢索到。文本類(lèi)PDF可以用MinerU這類(lèi)解析工具做版面還原把段落、表格、頁(yè)眉頁(yè)腳先區(qū)分開(kāi)。每解析完一個(gè)文檔先做一次“轉(zhuǎn)文本校驗(yàn)”——抽出前20行人工掃一眼格式亂了就換解析參數(shù)這步的經(jīng)驗(yàn)值比調(diào)模型還重要。圖片類(lèi)知識(shí)是個(gè)容易翻車(chē)的重災(zāi)區(qū)。RAG知識(shí)庫(kù)能不能存圖片能但存進(jìn)去之前得先想清楚檢索時(shí)怎么把圖片內(nèi)容撈出來(lái)。常見(jiàn)做法是OCR先把文字提取出來(lái)再把OCR文本和圖片路徑一起存進(jìn)知識(shí)庫(kù)檢索時(shí)命中OCR文本返回的引用結(jié)果里附帶圖片路徑前端展示圖片。對(duì)流程圖這類(lèi)純圖形內(nèi)容OCR基本失效只能靠人工在圖上標(biāo)注關(guān)鍵節(jié)點(diǎn)說(shuō)明把標(biāo)注文本作為檢索內(nèi)容。解析后需要把不同類(lèi)型的內(nèi)容分開(kāi)處理。表格是行業(yè)知識(shí)庫(kù)里價(jià)值最高的形態(tài)——閥門(mén)型號(hào)對(duì)應(yīng)壓力等級(jí)材料牌號(hào)對(duì)應(yīng)適用溫度范圍。直接把表格整塊切進(jìn)向量庫(kù)語(yǔ)義檢索幾乎必然失敗因?yàn)楸砀竦恼Z(yǔ)義是二維的向量化卻是按行讀取的。常見(jiàn)做法是把每行Excel/表格數(shù)據(jù)轉(zhuǎn)成一條“字段-值”對(duì)的自然語(yǔ)言描述再入庫(kù)比如“型號(hào)Q41F-16C公稱壓力1.6MPa適用溫度-29℃~150℃”。轉(zhuǎn)換腳本示意import pandas as pd df pd.read_excel(valve_spec.xlsx) documents [] for _, row in df.iterrows(): # 把表格行轉(zhuǎn)成可檢索的自然語(yǔ)言描述 desc 、.join(f{col}:{row[col]} for col in df.columns if pd.notna(row[col])) documents.append({ id: fvalve_{row[型號(hào)]}, content: desc, source: valve_spec.xlsx, page: row.get(頁(yè)碼, ) })這里有個(gè)細(xì)節(jié)拼接字段時(shí)要用中文冒號(hào)加頓號(hào)做分隔而不是JSON序列化。原因是向量化模型對(duì)“:{”這種符號(hào)密集的文本不敏感反而會(huì)把注意力放到標(biāo)點(diǎn)上。轉(zhuǎn)成自然語(yǔ)言后語(yǔ)義向量分布更均勻后續(xù)檢索命中率會(huì)明顯提升。3.2 切塊策略與向量化參數(shù)怎么設(shè)才能不翻車(chē)切塊是RAG里“玄學(xué)”濃度最高的環(huán)節(jié)。切得太小單塊語(yǔ)義不完整切得太大向量化后語(yǔ)義被稀釋還容易撞上模型的上下文窗口上限。常見(jiàn)的做法是按語(yǔ)義段落切而不是按固定字符數(shù)硬切。對(duì)行業(yè)標(biāo)準(zhǔn)類(lèi)文檔先按章節(jié)標(biāo)題切成大塊再把超過(guò)500字的塊按句號(hào)、分號(hào)做二次切分最后保留相鄰塊的overlap。我一般用的切塊參數(shù)是chunk_size 400字符overlap 80字符。400這個(gè)數(shù)字對(duì)中文比較合適大約能覆蓋5到8個(gè)完整句子嵌進(jìn)Prompt后既不會(huì)太碎也不會(huì)太臃腫。overlap取chunk_size的20%目的是避免一個(gè)完整語(yǔ)義被從中間切斷導(dǎo)致兩頭都檢索不到。切塊在代碼里的實(shí)現(xiàn)邏輯是def split_document(text: str, chunk_size: int 400, overlap: int 80) - list[str]: chunks [] start 0 while start len(text): end start chunk_size # 回退到最近的句號(hào)/分號(hào)避免切斷語(yǔ)義 if end len(text): for sep in (。, , \n): idx text.rfind(sep, start, end) if idx ! -1: end idx 1 break chunks.append(text[start:end]) start max(end - overlap, start 1) # 保證切分有推進(jìn) return chunks這套切塊邏輯適合標(biāo)準(zhǔn)、規(guī)程類(lèi)文檔。但行業(yè)知識(shí)庫(kù)里還有一類(lèi)資料不適用設(shè)備操作手冊(cè)典型特征是步驟之間靠“1. 2. 3.”編號(hào)關(guān)聯(lián)切成獨(dú)立塊后會(huì)丟失步驟先后關(guān)系。對(duì)這種文檔我會(huì)按章節(jié)整體入庫(kù)不做細(xì)粒度切分檢索時(shí)命中章節(jié)再做一次滑窗截取。向量化模型的選型也會(huì)影響切塊策略。如果用的是BGE系列這類(lèi)中文向量模型它的最大序列長(zhǎng)度通常只有512 tokenchunk_size設(shè)置過(guò)大反而導(dǎo)致向量化時(shí)被截?cái)唷Ｈ绻玫腅mbedding模型支持8192 token長(zhǎng)文本那可以適當(dāng)調(diào)大chunk_size減少塊數(shù)量、降低檢索噪聲。這個(gè)聯(lián)動(dòng)關(guān)系很多人會(huì)忽略只調(diào)向量模型不調(diào)切塊參數(shù)等于白調(diào)。4. RAG API接口設(shè)計(jì)范式從同步請(qǐng)求到流式輸出的落地4.1 接口契約與請(qǐng)求響應(yīng)結(jié)構(gòu)知識(shí)庫(kù)RAG系統(tǒng)最終要暴露成API給前端或業(yè)務(wù)系統(tǒng)調(diào)用接口契約設(shè)計(jì)得不好檢索層做得再好也白搭。常見(jiàn)的做法是設(shè)計(jì)兩個(gè)接口一個(gè)用于單輪問(wèn)答一個(gè)用于流式輸出。單輪問(wèn)答接口適合異步場(chǎng)景和內(nèi)部系統(tǒng)對(duì)接流式接口適合前端對(duì)話頁(yè)面。接口路徑和請(qǐng)求結(jié)構(gòu)示意from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): query: str # 用戶問(wèn)題 conversation_id: str # 會(huì)話標(biāo)識(shí)用于多輪上下文管理 top_k: int 6 # 召回條數(shù) temperature: float 0.3 # 生成溫度 standard_version: str # 標(biāo)準(zhǔn)版本過(guò)濾如 2024 class ChatResponse(BaseModel): answer: str citations: list[dict] # 引用來(lái)源文檔名、頁(yè)碼、原文片段 conversation_id: str token_usage: dict這個(gè)接口設(shè)計(jì)里三個(gè)字段是關(guān)鍵citations是行業(yè)知識(shí)庫(kù)問(wèn)答的命根子業(yè)務(wù)方拿回答去審計(jì)、去追溯時(shí)全靠它token_usage記錄了每次調(diào)用的消耗方便做成本核算和配額管理conversation_id則關(guān)聯(lián)了后續(xù)要說(shuō)的多輪上下文管理。請(qǐng)求參數(shù)里給top_k和temperature設(shè)置默認(rèn)值很有必要。top_k默認(rèn)6是檢索質(zhì)量與Token消耗的平衡點(diǎn)行業(yè)知識(shí)庫(kù)的問(wèn)題答案通常集中在一兩個(gè)文檔片段里top_k拉太大會(huì)引入無(wú)關(guān)噪聲。temperature默認(rèn)0.3則是因?yàn)橹R(shí)庫(kù)問(wèn)答屬于事實(shí)型任務(wù)生成溫度太高會(huì)“發(fā)揮過(guò)頭”編造出不存在的參數(shù)。流式接口的響應(yīng)格式建議直接兼容OpenAI的SSE協(xié)議前端用現(xiàn)成的SDK就能對(duì)接省去自研協(xié)議解析。響應(yīng)結(jié)構(gòu)里要額外增加citations字段用data:前綴逐條推送給前端讓頁(yè)面在打字機(jī)輸出答案的同時(shí)渲染引用來(lái)源。兼容協(xié)議的具體實(shí)現(xiàn)async def stream_chat(query: str, conv_id: str): docs retrieve_documents(query) # 混合檢索 prompt build_prompt(docs, query) async for token in llm.stream(prompt): # 用SSE格式推送給前端每行一個(gè)data: yield fdata: {json.dumps({type: token, content: token})}\n\n4.2 上下文管理窗口溢出與命中過(guò)濾RAG對(duì)話一旦進(jìn)入多輪上下文管理就成了最頭疼的問(wèn)題。行業(yè)知識(shí)庫(kù)的用戶經(jīng)常會(huì)追問(wèn)“那它的適用溫度呢”這個(gè)“它”指代的是上一輪問(wèn)題里的設(shè)備型號(hào)。如果API不做多輪上下文拼裝生成器根本不知道“它”是什么。常見(jiàn)的做法是用對(duì)話歷史 檢索結(jié)果的拼裝策略先把最近兩輪對(duì)話作為上下文再?gòu)闹谐槿〕鰧?shí)體詞補(bǔ)充到檢索Query里。DeepSeek這類(lèi)模型能理解指代消解但前提是把指代對(duì)象顯式寫(xiě)進(jìn)Prompt。多輪上下文管理的關(guān)鍵代碼def build_prompt(conversation_history: list[dict], docs: list[Document], query: str) - str: # 只保留最近兩輪對(duì)話作為上下文 recent conversation_history[-4:] # 兩輪對(duì)話共4條消息 context \n.join( f{msg[role]}: {msg[content]} for msg in recent ) evidence \n\n.join( f[{i1}] {doc.content} for i, doc in enumerate(docs) ) prompt f請(qǐng)基于以下檢索到的資料回答問(wèn)題回答中標(biāo)注引用編號(hào)如[1]。 檢索資料 {evidence} 對(duì)話歷史 {context} 當(dāng)前問(wèn)題{query} return prompt這里有個(gè)容易被忽略的點(diǎn)對(duì)話歷史只保留最近兩輪不是越多越好。行業(yè)知識(shí)庫(kù)問(wèn)答里每輪對(duì)話都會(huì)帶入檢索片段檢索片段動(dòng)輒幾百上千字保留五輪以上對(duì)話Prompt幾乎必然撐爆上下文窗口。DeepSeek模型的max context length是1048576 tokens不假但那是模型支持的上限不是知識(shí)庫(kù)問(wèn)答應(yīng)該挑戰(zhàn)的上限。上下文越長(zhǎng)檢索片段占比越稀薄模型越容易忽略關(guān)鍵證據(jù)。截?cái)嗍潜匾某杀究刂剖侄?。在多輪?chǎng)景下還要解決檢索Query重寫(xiě)的問(wèn)題。用戶說(shuō)“那它的溫度范圍呢”直接拿原問(wèn)題去檢索必然失敗。常見(jiàn)做法是在檢索前加一步“Query改寫(xiě)”把最后一輪問(wèn)題結(jié)合對(duì)話歷史重寫(xiě)成完整問(wèn)題?？梢杂靡粋€(gè)小模型專(zhuān)門(mén)做改寫(xiě)也可以直接用DeepSeek生成提示詞里注明“根據(jù)對(duì)話歷史把指代不明的提問(wèn)改寫(xiě)為完整的獨(dú)立問(wèn)題”。另外接口層建議增加一個(gè)“檢索命中過(guò)濾”參數(shù)。行業(yè)知識(shí)庫(kù)存在大量同義詞、上游下游概念用戶問(wèn)“閥門(mén)口徑”文檔里寫(xiě)“公稱通徑DN”向量檢索能召回但相關(guān)性分?jǐn)?shù)不會(huì)太高。API參數(shù)里暴露min_score閾值低于閾值的檢索片段直接丟棄寧可答“抱歉知識(shí)庫(kù)中沒(méi)有相關(guān)答案”也不要讓模型從弱相關(guān)片段里硬編。這個(gè)設(shè)計(jì)能擋掉很大一部分“一本正經(jīng)胡說(shuō)八道”的問(wèn)題。5. 避坑排查RAG技術(shù)整合中的五個(gè)翻車(chē)現(xiàn)場(chǎng)5.1 接DeepSeek時(shí)報(bào)“no api key for provider route”現(xiàn)象請(qǐng)求DeepSeek接口時(shí)后端日志拋錯(cuò)llm-deepseek: no api key for provider route deepseek-official請(qǐng)求直接失敗。原因這個(gè)報(bào)錯(cuò)幾乎全部出在使用了類(lèi)似OpenAI網(wǎng)關(guān)、LiteLLM這類(lèi)統(tǒng)一接入層時(shí)路由配置里把“deepseek-official”指向了DeepSeek服務(wù)但環(huán)境變量里沒(méi)有配置對(duì)應(yīng)的API Key。接入層不知道往哪里塞密鑰直接拒絕請(qǐng)求。解決檢查接入層配置中deepseek-official對(duì)應(yīng)的環(huán)境變量名通常是DEEPSEEK_API_KEY。把密鑰補(bǔ)進(jìn)環(huán)境變量后重啟接入層服務(wù)。如果是自部署的DeepSeekAPI Key可以隨便填一個(gè)占位符但環(huán)境變量不能不設(shè)。自部署路徑下更常見(jiàn)的問(wèn)題反而是沒(méi)跑vLLM服務(wù)就發(fā)請(qǐng)求先確認(rèn)http://localhost:8000/v1能通。5.2 檢索召回一堆無(wú)關(guān)片段生成質(zhì)量直線下降現(xiàn)象檢索環(huán)節(jié)返回的top_k結(jié)果里前幾名和問(wèn)題根本沒(méi)關(guān)系生成器把這些片段全塞進(jìn)Prompt后回答開(kāi)始跑偏。原因行業(yè)文檔解析不干凈是首要原因。PDF里的頁(yè)眉頁(yè)腳、目錄、版本修訂記錄沒(méi)濾掉這些內(nèi)容被當(dāng)成正文切塊入庫(kù)檢索時(shí)高頻詞“范圍”“標(biāo)準(zhǔn)”會(huì)把這些垃圾塊全召回。解決解析階段加一道過(guò)濾器把每頁(yè)重復(fù)出現(xiàn)的行頁(yè)眉頁(yè)腳先剔除再跑切塊。另外把向量檢索閾值調(diào)高一點(diǎn)BGE系列模型的余弦相似度低于0.6的命中直接扔掉寧可召回少一些也別讓垃圾進(jìn)Prompt。5.3 多輪對(duì)話后回答開(kāi)始“張冠李戴”現(xiàn)象用戶連續(xù)問(wèn)了三個(gè)問(wèn)題第一個(gè)問(wèn)題是“A設(shè)備的壓力等級(jí)”第三個(gè)問(wèn)題回答里的參數(shù)明顯是B設(shè)備的。原因多輪上下文拼裝策略里保留了過(guò)多歷史輪次檢索結(jié)果和舊對(duì)話混在一起模型分不清當(dāng)前問(wèn)題該匹配哪段證據(jù)。解決嚴(yán)格限制上下文只保留最近兩輪并在Prompt里把“當(dāng)前問(wèn)題”和“歷史對(duì)話”用分隔符明確隔開(kāi)。出現(xiàn)此類(lèi)問(wèn)題時(shí)最直接的排查辦法是打開(kāi)日志看拼裝后的完整Prompt——是檢索片段混進(jìn)了舊話題還是對(duì)話歷史里本身含有沖突信息一眼就能定位。5.4 知識(shí)庫(kù)里的圖片永遠(yuǎn)檢索不到現(xiàn)象知識(shí)庫(kù)里明明存了設(shè)備銘牌照片圖片上也印著型號(hào)和參數(shù)用戶提問(wèn)時(shí)卻搜不到任何相關(guān)內(nèi)容。原因圖片沒(méi)有走OCR或者OCR文本沒(méi)進(jìn)入檢索索引。直接把圖片文件傳進(jìn)向量庫(kù)向量模型不認(rèn)識(shí)圖片圖片本身不會(huì)產(chǎn)出可用于向量檢索的文本。解決入庫(kù)邏輯調(diào)整成“圖片 → OCR提取文本 → 文本和圖片路徑綁定入庫(kù)”。檢索時(shí)命中的是OCR文本返回結(jié)果的citations里帶上圖片路徑。流程圖類(lèi)圖片OCR效果差需要在圖片入庫(kù)前人工補(bǔ)充文字說(shuō)明再把說(shuō)明文本一并存入知識(shí)庫(kù)。5.5 檢索質(zhì)量不錯(cuò)但生成答案比預(yù)期長(zhǎng)很多或根本不引用現(xiàn)象檢索片段明顯包含了正確答案但生成答案把事情從頭講到尾還不標(biāo)注引用編號(hào)。原因Prompt里對(duì)“引用編號(hào)”的約束寫(xiě)得不夠強(qiáng)硬——“請(qǐng)標(biāo)注引用編號(hào)”這種措辭模型可以聽(tīng)也可以當(dāng)成建議忽略。輸出格式約束弱模型自由發(fā)揮空間大。解決把引用要求改成硬性格式約束并要求輸出必須帶引用標(biāo)記沒(méi)有引用的句子不應(yīng)出現(xiàn)。另外可以在API層對(duì)生成結(jié)果做一次后處理抽取出所有[編號(hào)]標(biāo)記清點(diǎn)編號(hào)是否都在檢索片段范圍內(nèi)不在范圍內(nèi)的直接丟棄該段內(nèi)容寧可短答也不留錯(cuò)誤引用。6. 進(jìn)階讓RAG結(jié)果更可信的驗(yàn)證方法與一個(gè)具體技巧驗(yàn)證RAG系統(tǒng)質(zhì)量不能只靠“看著像是對(duì)的”。行業(yè)知識(shí)庫(kù)里有標(biāo)準(zhǔn)答案完全可以做離線評(píng)測(cè)。常見(jiàn)做法是人工整理200到300條“問(wèn)題-標(biāo)準(zhǔn)答案-來(lái)源文檔”三元組跑一遍評(píng)測(cè)腳本衡量?jī)蓚€(gè)指標(biāo)檢索命中率標(biāo)準(zhǔn)答案對(duì)應(yīng)的文檔是否出現(xiàn)在top_k結(jié)果里和生成準(zhǔn)確率生成答案里是否包含標(biāo)準(zhǔn)答案的關(guān)鍵實(shí)體和數(shù)值。這個(gè)評(píng)測(cè)集最好覆蓋每個(gè)知識(shí)子目錄避免只測(cè)了某個(gè)板塊。一個(gè)很實(shí)用的驗(yàn)證技巧是“溯源抽查”。在評(píng)測(cè)腳本里加一段邏輯把每道題的檢索結(jié)果打印出來(lái)人工檢查答案對(duì)應(yīng)的原文片段在不在檢索結(jié)果里如果不在把Query和原文片段拿出來(lái)對(duì)比看看是切塊把關(guān)鍵內(nèi)容切散了還是Embedding模型沒(méi)理解同義表達(dá)。我遇到過(guò)一種情況原文檔寫(xiě)的是“公稱壓力”測(cè)試問(wèn)題問(wèn)的是“設(shè)計(jì)壓力”語(yǔ)義上強(qiáng)相關(guān)但向量相似度不到閾值被過(guò)濾掉了。后來(lái)在庫(kù)里補(bǔ)充了同義詞映射表公稱壓力, 設(shè)計(jì)壓力, 額定壓力檢索前做一次詞表替身才徹底解決。日常維護(hù)層面建議保留一套“壞回答日志”每次現(xiàn)場(chǎng)問(wèn)答出現(xiàn)明顯錯(cuò)誤時(shí)把“原始問(wèn)題、檢索到的片段、生成結(jié)果”存成一條記錄每周集中復(fù)看一次把錯(cuò)誤歸因到檢索層或生成層。這個(gè)習(xí)慣能快速暴露知識(shí)庫(kù)里的存量問(wèn)題——是文檔缺內(nèi)容還是切塊太碎、還是Prompt的格式約束被模型繞過(guò)去了。落到API設(shè)計(jì)上還有一個(gè)值得做的細(xì)節(jié)響應(yīng)結(jié)構(gòu)里增加retrieval_debug字段記錄本次檢索使用的Query改寫(xiě)結(jié)果和命中的文檔ID。內(nèi)部調(diào)試時(shí)把這個(gè)字段打開(kāi)生產(chǎn)環(huán)境時(shí)關(guān)閉能省掉大量“為什么答錯(cuò)了”的排查時(shí)間。整套R(shí)AG技術(shù)深度整合本質(zhì)上是把“檢索、生成、溯源”三個(gè)環(huán)節(jié)用接口這條線串起來(lái)形成一條任何一環(huán)出錯(cuò)都能快速定位的鏈路。這套方案在多個(gè)行業(yè)知識(shí)庫(kù)項(xiàng)目里沉淀過(guò)希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取