生成全鏈路解析：從文檔加載到評估的大模型知識庫工程實(shí)踐)
很多開發(fā)者第一次接觸大模型時(shí)第一反應(yīng)是“調(diào)用 API 太簡單了”把 Prompt 封裝好用戶問題丟給 GPT 或國內(nèi)商用模型一個(gè)聊天機(jī)器人就上線了。但真正進(jìn)入企業(yè)項(xiàng)目就會發(fā)現(xiàn)API 只是一個(gè)入口真正難的部分在于怎么讓模型“看到”私有知識、怎么控制幻覺、怎么評估系統(tǒng)效果、怎么在有限顯存環(huán)境下做推理部署。這些問題背后正是 LLM 工程化的完整鏈路。如果說 LLM 工程是一門需要體系化學(xué)習(xí)的課程那么 GenAI 和 RAG 就是其中最核心的兩個(gè)板塊。RAG 不是“把一個(gè) PDF 塞給大模型”這種一句話能講清的操作而是一套數(shù)據(jù)工程、檢索系統(tǒng)、生成策略和評估體系的組合。這也是這門 Udemy 課程第三部分的重點(diǎn)從純 Prompt 調(diào)用走向生產(chǎn)級知識庫應(yīng)用。這篇文章會以該課程第三部分為線索梳理 RAG 完整鏈路文檔加載、切分、向量化、檢索、生成、Agentic RAG 和 OAG 等進(jìn)階方向、FP16/FP32/BF16 精度問題以及 RAG 知識庫評估指標(biāo)。如果你正在做知識庫問答、想系統(tǒng)學(xué)習(xí) LLM 工程或者正從傳統(tǒng)后端轉(zhuǎn)向 AI 應(yīng)用開發(fā)這篇內(nèi)容應(yīng)該能幫你建立一份更清晰的行動地圖。1. 為什么 RAG 是 LLM 落地繞不開的方向先做一個(gè)判斷在 2025 年這個(gè)時(shí)間點(diǎn)RAG 已經(jīng)不只是“一個(gè)技術(shù)方案”而是 LLM 應(yīng)用落地事實(shí)上的標(biāo)準(zhǔn)形態(tài)。聊天、寫作、翻譯可能用不到 RAG但凡是涉及私有數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)、專業(yè)文檔的場景RAG 幾乎都是第一選擇。原因在于 LLM 本身有三大硬約束。第一知識截止。預(yù)訓(xùn)練模型的知識停留在訓(xùn)練數(shù)據(jù)截止時(shí)間訓(xùn)練之后發(fā)生的事情它不知道。如果你問它某個(gè)產(chǎn)品上周發(fā)布的新功能它大概率會一本正經(jīng)地編一個(gè)答案。第二私有數(shù)據(jù)不可見。企業(yè)內(nèi)部的規(guī)章制度、產(chǎn)品手冊、客服工單、專利文檔模型在訓(xùn)練時(shí)根本沒有見過。直接讓模型回答這些內(nèi)容它只能靠“合理猜測”而合理猜測在專業(yè)場景里往往就是事故。第三幻覺問題。即使模型不知道答案它也會因?yàn)檎Z言模型的本質(zhì)而生成一個(gè)看起來通順的回復(fù)。這不是模型“壞”而是概率生成機(jī)制導(dǎo)致的必然結(jié)果。解決幻覺最有效的工程手段之一就是用檢索到的真實(shí)內(nèi)容去約束生成范圍。沒有 RAG 的時(shí)候要讓模型掌握新的領(lǐng)域知識主流方案是微調(diào)Fine-tuning。但微調(diào)的成本高、周期長每次知識更新都要重新訓(xùn)練一輪。更關(guān)鍵的是微調(diào)擅長改變模型的行為方式和表達(dá)風(fēng)格卻并不擅長記憶大量新事實(shí)。讓一個(gè) 7B 模型通過微調(diào)背下一本 500 頁的產(chǎn)品手冊既不經(jīng)濟(jì)也容易過擬合。RAG 的思路是把“記憶”從模型內(nèi)部搬到外部給模型一本可以隨時(shí)翻閱的參考書這個(gè)參考書就是你的知識庫。模型回答之前先從參考書里找出與問題最相關(guān)的幾個(gè)片段再把這些片段作為上下文交給模型生成答案。用“開卷考試”來類比 RAG 和普通 Prompt 生成的區(qū)別非常直觀。但在真實(shí)項(xiàng)目中這套“開卷考試”的工程復(fù)雜度遠(yuǎn)高于想象。很多人以為 RAG 就是“向量數(shù)據(jù)庫 Prompt”實(shí)際做下去才發(fā)現(xiàn)文檔怎么拆、按什么粒度拆、檢索用什么向量、top-k 怎么設(shè)、重排怎么做、效果用什么指標(biāo)來衡量每一步都可能讓最終效果出現(xiàn)數(shù)倍的差距。2. RAG 完整鏈路與核心概念2.1 RAG 的標(biāo)準(zhǔn)流程一個(gè)標(biāo)準(zhǔn)的 RAG 系統(tǒng)由四個(gè)環(huán)節(jié)組成。第一數(shù)據(jù)準(zhǔn)備階段。原始文檔需要經(jīng)過加載、解析、清洗、切分變成適合檢索的文本塊chunk。這個(gè)環(huán)節(jié)經(jīng)常被低估但它的質(zhì)量直接決定了整個(gè)知識庫的上限。如果原始文檔是 PDF頁眉頁腳、表格、掃描圖片都會成為干擾項(xiàng)如果切分粒度不對再好的向量模型也檢索不準(zhǔn)。第二索引構(gòu)建階段。每個(gè)文本塊通過 embedding 模型轉(zhuǎn)換為向量寫入向量數(shù)據(jù)庫。同時(shí)可以保留原始文本和元數(shù)據(jù)來源、頁碼、標(biāo)題等方便后續(xù)溯源。第三檢索階段。用戶輸入問題后先把問題也轉(zhuǎn)換為向量然后在向量數(shù)據(jù)庫中做相似度檢索取回最相關(guān)的 top-k 個(gè)文本塊。更復(fù)雜的系統(tǒng)會在這個(gè)階段加入關(guān)鍵詞檢索和重排模型。第四生成階段。把檢索到的文本塊和用戶問題組裝成 Prompt交給 LLM 生成最終答案。為了減少幻覺Prompt 中通常會明確要求模型只基于檢索內(nèi)容作答無法回答時(shí)要明確說明。2.2 RAG 和微調(diào)不是二選一很多入門者會在 RAG 和微調(diào)之間糾結(jié)。我的建議是先分清楚你要解決的是哪一類問題。RAG 適合解決“知識更新”和“私有數(shù)據(jù)接入”的問題。比如 FAQ 問答、產(chǎn)品文檔問答、行業(yè)報(bào)告摘要。它的優(yōu)勢是知識可以隨時(shí)更新、答案可以溯源一次數(shù)據(jù)更新不需要重新訓(xùn)練模型。微調(diào)更適合解決“行為方式”和“輸出格式”的問題。比如讓模型學(xué)習(xí)某個(gè)業(yè)務(wù)場景下的固定話術(shù)、指令遵循習(xí)慣或者把輸出格式嚴(yán)格限定成系統(tǒng)需要的 JSON 結(jié)構(gòu)。微調(diào)改變的是模型的“性情”RAG 給的是模型的“素材”兩者服務(wù)的層次完全不同。生產(chǎn)系統(tǒng)里常見的做法是兩者結(jié)合先微調(diào)出一個(gè)懂業(yè)務(wù)話術(shù)的底座模型再用 RAG 為它提供實(shí)時(shí)事實(shí)。對大部分團(tuán)隊(duì)來說RAG 的性價(jià)比上限更高因?yàn)樗簧婕坝?xùn)練資源。不要一上來就微調(diào)先把 RAG 鏈路跑通。2.3 從 RAG 到 Agentic RAG 和 OAG課程第三部分的內(nèi)容里進(jìn)階方向會從“單次 RAG”延伸到“Agentic RAG”和“OAG”這類新概念。理解這兩個(gè)概念有助于看清楚 RAG 演進(jìn)的脈絡(luò)。Agentic RAG 的核心變化是把 RAG 從“一次檢索 一次生成”升級為“多輪決策循環(huán)”。簡單說就是讓 LLM Agent 承擔(dān)檢索規(guī)劃的角色。它先理解用戶問題決定是否要檢索、檢索什么拿到檢索結(jié)果后判斷信息是否足夠如果不夠就改寫查詢詞再檢索或者調(diào)用外部工具獲取信息最后綜合多輪結(jié)果生成答案。這種設(shè)計(jì)解決的是復(fù)雜問題拆解場景。比如用戶問“幫我對比一下 A 產(chǎn)品和 B 產(chǎn)品在三個(gè)維度的差異”單次向量檢索很難把三個(gè)維度一次找全。Agent 可以把這個(gè)問題拆成多個(gè)子問題分別檢索再匯總。這就是 LLM Agent 與 RAG 結(jié)合的典型價(jià)值。OAG 指的是 Ontology-Augmented Generation即本體增強(qiáng)生成。它和 RAG 的區(qū)別在于RAG 檢索的是非結(jié)構(gòu)化的自然語言文本OAG 使用的是結(jié)構(gòu)化的本體或知識圖譜。本體會預(yù)先定義實(shí)體、關(guān)系和規(guī)則比如在通信協(xié)議文檔中“ACK/NACK”“RRC 狀態(tài)”這樣的概念和它們之間的關(guān)聯(lián)會被顯式建模。生成時(shí)系統(tǒng)先從本體中查詢符合邏輯約束的事實(shí)再交給 LLM 生成。在專業(yè)領(lǐng)域比如 3GPP 協(xié)議規(guī)范、醫(yī)療指南、金融監(jiān)管文件這類文檔中OAG 比普通 RAG 更容易保證語義一致性。普通 RAG 容易把不同版本的協(xié)議內(nèi)容混在一起而基于本體的檢索可以根據(jù)版本關(guān)系和實(shí)體約束做更精確的過濾。RAG 和 OAG 并不互斥一個(gè)成熟的專業(yè)知識庫系統(tǒng)往往兩種手段同時(shí)使用。3. 文檔加載解析全流程容易被低估的一環(huán)如果說 RAG 鏈路中有一個(gè)最容易被低估、但又最決定效果上限的環(huán)節(jié)那一定是文檔加載和切分。很多團(tuán)隊(duì)把大量時(shí)間花在調(diào) Prompt 和換模型上卻忽略了知識庫的“地基”。實(shí)際上如果輸入到向量庫的文本本身就是臟的、碎的、無上下文的再好的檢索模型也救不回來。3.1 不同文檔類型的加載難點(diǎn)先從加載開始?，F(xiàn)實(shí)項(xiàng)目里遇到的文檔遠(yuǎn)比教科書例子復(fù)雜。PDF 是最常見的格式但 PDF 內(nèi)部差異很大。文本型 PDF 可以直接抽取文字但頁眉頁腳會污染正文表格型 PDF 抽取后可能變成一段無結(jié)構(gòu)的字符串掃描型 PDF 需要先 OCR而 OCR 又可能引入錯字。Word 文檔的問題在于樣式標(biāo)記和批注PPT 的難點(diǎn)在于每頁內(nèi)容太碎片化。HTML 頁面則需要抽取正文、剝離導(dǎo)航和腳本。這些工作屬于典型的數(shù)據(jù)工程聽起來不“AI”但直接決定下游質(zhì)量。在這個(gè)階段可以借助 LangChain 的 document loader 體系。它提供了針對 PDF、Word、HTML、Markdown、PowerPoint 等多種格式的加載器。也可以引入 Unstructured 等解析庫來做表格識別和 OCR。不過不能只依賴現(xiàn)成工具業(yè)務(wù)文檔的布局規(guī)則往往需要自己寫解析邏輯。3.2 文本切分策略切分是另一個(gè)關(guān)鍵決策點(diǎn)。切分的核心矛盾是塊太大向量化后語義會被稀釋檢索不夠精準(zhǔn)塊太小上下文不完整LLM 生成時(shí)看到的背景信息太少。經(jīng)驗(yàn)上的常見范圍是 200 到 500 個(gè) token。但這只是起點(diǎn)具體值要根據(jù)文檔類型和測試效果調(diào)整。切分方式也分幾個(gè)層次。固定大小切分最簡單按 token 數(shù)硬切但會切斷句子和段落。遞歸字符切分是 LangChain 中最常用的方式它按分隔符優(yōu)先級遞歸嘗試盡量保住段落和句子結(jié)構(gòu)適合通用文檔。按 Markdown 標(biāo)題切分適合結(jié)構(gòu)化文檔能保證每個(gè)塊對應(yīng)一個(gè)語義完整的章節(jié)。語義切分則利用 embedding 的相似度來決定邊界效果最好但計(jì)算成本高。切分時(shí)還要設(shè)置 overlap也就是相鄰塊之間的重疊區(qū)域。Overlap 的意義在于如果一條知識恰好落在切分邊界上沒有重疊就會導(dǎo)致它被切斷檢索時(shí)自然找不到。一般建議 overlap 設(shè)置為 chunk size 的 10% 到 20%。下面給出一段基于 LangChain 的 PDF 加載與切分示例代碼。這段示例使用 LangChain 0.x 早期的 API 寫法新版中的導(dǎo)入路徑可能有調(diào)整請以你安裝的包版本為準(zhǔn)。# document_prepare.py from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加載 PDF 文檔 loader PyPDFLoader(./data/product_manual.pdf) documents loader.load() print(f加載得到 {len(documents)} 頁內(nèi)容) # 2. 遞歸字符切分 splitter RecursiveCharacterTextSplitter( chunk_size400, # 每個(gè)文本塊的目標(biāo)大小token 級別 chunk_overlap50, # 相鄰塊重疊大小 separators[\n\n, \n, 。, , , , , ], ) chunks splitter.split_documents(documents) print(f切分后得到 {len(chunks)} 個(gè)文本塊) # 3. 查看第一個(gè)塊的元信息和前 200 字 print(chunks[0].page_content[:200]) print(chunks[0].metadata)在真實(shí)項(xiàng)目中不建議把所有文檔類型都統(tǒng)一走同一條切分邏輯。正確做法是先對文檔做分類規(guī)章制度類按章節(jié)切產(chǎn)品手冊類按功能模塊切FAQ 類按問答對整體保留。切分策略應(yīng)該被當(dāng)成一個(gè)可配置的參數(shù)允許在評估后反復(fù)調(diào)整而不是寫死一次就不動了。4. 環(huán)境準(zhǔn)備與依賴安裝要動手跑通 RAG 示例需要先準(zhǔn)備一套 Python 環(huán)境。下面的環(huán)境清單不針對特定版本建議以“安裝時(shí)最新穩(wěn)定版”為準(zhǔn)本文重點(diǎn)演示通用思路。操作系統(tǒng)推薦 macOS 或 LinuxWindows 也可以運(yùn)行但依賴安裝時(shí)更容易遇到編譯問題。Python 版本建議 3.9 以上最好使用 3.10 或 3.11。核心依賴拆成三部分向量化與檢索框架langchain、langchain-community、langchain-openai。向量存儲chromadb 或者 faiss-cpu。文檔解析pypdf、unstructured、pandas。模型調(diào)用openai如果使用國內(nèi)大模型則改成對應(yīng) SDK。創(chuàng)建虛擬環(huán)境并安裝依賴python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install langchain langchain-community langchain-openai pip install chromadb faiss-cpu pip install pypdf unstructured如果你要調(diào)用 OpenAI 接口需要提前配置環(huán)境變量。如果使用其他模型服務(wù)或本地部署的模型替換對應(yīng)的 embedding 和 LLM 類即可。export OPENAI_API_KEY你的密鑰如果你所在環(huán)境無法直接使用境外模型服務(wù)可以選擇國內(nèi)廠商提供的兼容接口或者使用本地部署的模型。這個(gè)選擇不影響 RAG 的架構(gòu)思路只影響具體調(diào)用方式。5. 向量化與檢索RAG 的核心決策點(diǎn)5.1 Embedding 模型選擇文本塊準(zhǔn)備好之后下一步是向量化。這一步的核心是選擇一個(gè)合適的 embedding 模型。Embedding 模型會把一段文本映射成高維向量語義相近的文本在向量空間中的距離也更近。目前選擇很多OpenAI 提供了 text-embedding-3-small 和 text-embedding-3-large國內(nèi)也有 BGE、M3E 等開源中文 embedding 模型還有各種本地可部署的模型。選擇 embedding 模型時(shí)有三個(gè)考量因素。第一是語言適配。如果你的知識庫主要是中文建議優(yōu)先在中文語料上表現(xiàn)更好的模型或者做多語言模型而不是直接使用以英文為重心的小模型。第二是維度與成本。維度越高通常表達(dá)能力越強(qiáng)但存儲和計(jì)算成本也越高。text-embedding-3-small 默認(rèn)只有幾百維對于大多數(shù)知識庫場景已經(jīng)夠用。第三是推理環(huán)境。如果知識庫部署在內(nèi)部網(wǎng)絡(luò)無法訪問外部 API那就必須選擇可在本地 GPU 或 CPU 上運(yùn)行的 embedding 模型。開源模型在本地部署完全沒有問題。5.2 向量數(shù)據(jù)庫選型向量數(shù)據(jù)庫的作用是存儲向量并支持快速相似度檢索。選型可以從項(xiàng)目規(guī)模出發(fā)。FAISS 是 Meta 開源的向量檢索庫不是一個(gè)完整數(shù)據(jù)庫不提供數(shù)據(jù)持久化和權(quán)限管理但它輕量、高效適合原型驗(yàn)證和小規(guī)模項(xiàng)目。Chroma 是一個(gè)更完整的本地向量數(shù)據(jù)庫提供了簡單的 API 和持久化能力適合中小團(tuán)隊(duì)快速起步。Milvus 和 Qdrant 是面向生產(chǎn)環(huán)境的分布式向量數(shù)據(jù)庫支持水平擴(kuò)展、多租戶、權(quán)限控制和豐富的過濾能力適合數(shù)據(jù)量達(dá)到幾十萬甚至上百萬條級別的系統(tǒng)。選型建議個(gè)人學(xué)習(xí)和搭建原型直接用 FAISS 或 Chroma企業(yè)項(xiàng)目評估 Milvus、Qdrant如果團(tuán)隊(duì)已經(jīng)引入了 Elasticsearch 8.x 且同時(shí)在用 ES 做全文檢索也可以考慮用它內(nèi)置的向量檢索能力以減少運(yùn)維組件的數(shù)量。5.3 檢索策略向量檢索、混合檢索與重排很多人把 RAG 的檢索等同于“向量相似度檢索”但這只是起點(diǎn)。向量檢索適合語義相關(guān)性判斷比如“最大負(fù)載多少”能找到包含“負(fù)載能力”的文檔即使沒有“最大負(fù)載”這四個(gè)字。缺點(diǎn)是對精確關(guān)鍵詞不敏感。關(guān)鍵詞檢索比如 BM25恰恰相反它擅長精確匹配比如產(chǎn)品型號、錯誤碼、人名但無法理解同義改寫。真實(shí)知識庫中這兩類問題同時(shí)存在。于是就有了混合檢索同時(shí)執(zhí)行向量檢索和關(guān)鍵詞檢索再把兩部分結(jié)果合并用重排序模型Rerank重新打分選出最終進(jìn)入 Prompt 的內(nèi)容。重排階段通常把候選從 20 條壓縮到 3 到 5 條能顯著提升生成質(zhì)量但也會帶來額外的計(jì)算延遲。對于剛起步的團(tuán)隊(duì)建議先用純向量檢索跑通流程再加入關(guān)鍵詞檢索和重排逐步驗(yàn)證每一步帶來的收益不要一上來就堆復(fù)雜組件。下面是一個(gè)基于 Chroma 和 LangChain 的完整檢索問答示例。這里使用 LangChain 中常見的RetrievalQA封裝。# rag_qa.py from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA # 1. 初始化 embedding 模型 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) # 2. 把上一步切分好的 chunks 寫入 Chroma 向量庫 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) # 3. 構(gòu)建檢索器 retriever vectorstore.as_retriever( search_typesimilarity, search_kwargs{k: 4}, ) # 4. 初始化生成模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 5. 構(gòu)建 RAG 問答鏈 qa_chain RetrievalQA.from_chain_type( llmllm, retrieverretriever, return_source_documentsTrue, ) # 6. 執(zhí)行查詢 query 產(chǎn)品手冊中該設(shè)備的最大負(fù)載是多少 result qa_chain.invoke({query: query}) print(答案, result[result]) print(\n--- 參考來源 ---) for doc in result[source_documents]: print(來源, doc.metadata.get(source, 未知)) print(內(nèi)容, doc.page_content[:100])這個(gè)代碼里有幾個(gè)細(xì)節(jié)值得注意。search_kwargs{k: 4}表示只取回 4 個(gè)最相關(guān)的文本塊。k 值太小容易漏答案k 值太大則會把無關(guān)內(nèi)容塞給 LLM讓答案跑偏。一般從 4 到 6 起步再根據(jù)評估效果調(diào)整。temperature0是問答場景的常見配置。知識庫問答要求穩(wěn)定、忠實(shí)不需要創(chuàng)造性輸出。而寫文案、頭腦風(fēng)暴類場景才需要提高溫度。return_source_documentsTrue一定要保留否則你很難知道答案是來自知識庫還是模型自己編的。生產(chǎn)系統(tǒng)中來源溯源是知識庫功能的基本要求。5.4 從示例到生產(chǎn)系統(tǒng)上面的示例跑通之后要往生產(chǎn)系統(tǒng)走還有幾件事需要補(bǔ)充。一是索引的增量更新。文檔會更新、刪除、追加不能每次全量重建。實(shí)踐中會引入調(diào)度任務(wù)和消息隊(duì)列按文檔哈?；虬姹咎柵袛嗍欠裥枰匦孪蛄炕６窍蛄繑?shù)據(jù)庫的安全性。私有知識庫通常涉及敏感數(shù)據(jù)。向量庫本身往往沒有嚴(yán)格的權(quán)限模型需要在應(yīng)用層做好訪問控制對用戶查詢和檢索結(jié)果做權(quán)限過濾。三是檢索質(zhì)量監(jiān)控。線上系統(tǒng)一般會記錄每次查詢的召回文檔、相關(guān)性分?jǐn)?shù)和最終答案并定期抽樣做人工評估。這樣當(dāng)某個(gè)知識點(diǎn)的檢索質(zhì)量下降時(shí)可以及時(shí)定位是數(shù)據(jù)更新問題還是模型變更問題。6. LLM 精度問題FP16、FP32、BF16 在工程中的取舍在 RAG 示例中你可能用的是托管模型 API不需要關(guān)心權(quán)重存儲的精度問題。但如果你要做本地推理、私有化部署或者用開源模型搭建知識庫那么 LLM 的精度問題就是繞不開的工程決策。6.1 為什么精度問題值得關(guān)注大模型的權(quán)重是一組浮點(diǎn)數(shù)。浮點(diǎn)數(shù)的表示精度和范圍由格式?jīng)Q定。同一個(gè)模型參數(shù)用不同精度存儲和計(jì)算會直接影響三件事顯存占用、推理速度、輸出質(zhì)量。先給一個(gè)粗略的顯存估算。一個(gè) 7B70 億參數(shù)參數(shù)的模型以 FP32 存儲參數(shù)大小約為 7 × 4 字節(jié)等于 28GB。FP16 或 BF16 是半精度每個(gè)參數(shù) 2 字節(jié)所以約 14GB。如果再算上推理過程的中間激活值實(shí)際占用會更高。這也是為什么 8GB 顯卡幾乎跑不動 7B 模型的全量推理通常需要配合 4bit 量化。6.2 三種精度格式背后的設(shè)計(jì)差異FP32 是單精度浮點(diǎn)數(shù)寬度 32 位其中指數(shù)位 8 位尾數(shù)位 23 位。它是 CPU 和 GPU 上最通用的標(biāo)準(zhǔn)格式精度最高。模型預(yù)訓(xùn)練和科學(xué)計(jì)算常用 FP32 作為基準(zhǔn)。缺點(diǎn)是顯存占用大、計(jì)算速度相對慢。FP16 是 IEEE 半精度浮點(diǎn)數(shù)寬度 16 位其中指數(shù)位 5 位尾數(shù)位 10 位。相比 FP32它節(jié)省一半顯存計(jì)算速度也更快。但指數(shù)位只有 5 位導(dǎo)致它能表示的數(shù)值范圍變小。當(dāng)某個(gè)權(quán)重?cái)?shù)值很大時(shí)會被表示成無窮大當(dāng)數(shù)值極端小時(shí)又容易變成 0。這就是“溢出”和“下溢”問題。在訓(xùn)練大模型時(shí)如果直接用 FP16梯度很容易在反向傳播中丟失。BF16 是 Brain Floating Point也是 16 位但指數(shù)位有 8 位和 FP32 相同尾數(shù)位只有 7 位。它的巧妙之處在于“犧牲精度保留范圍”。因?yàn)楹?FP32 擁有相同的指數(shù)范圍BF16 在高數(shù)值范圍下更不容易溢出訓(xùn)練時(shí)穩(wěn)定性明顯優(yōu)于 FP16。代價(jià)是尾數(shù)少同一個(gè)數(shù)值BF16 能表示的小數(shù)精度比 FP16 低。6.3 三種精度的對比精度格式位寬指數(shù)位尾數(shù)位主要優(yōu)點(diǎn)主要缺點(diǎn)常見用途FP3232 位8 位23 位精度最高顯存占用大、計(jì)算慢預(yù)訓(xùn)練基準(zhǔn)、科學(xué)計(jì)算、調(diào)試FP1616 位5 位10 位顯存減半、速度快數(shù)值范圍小訓(xùn)練易溢出混合精度訓(xùn)練、GPU 推理BF1616 位8 位7 位數(shù)值范圍與 FP32 相同訓(xùn)練穩(wěn)定尾數(shù)少精度略低大模型預(yù)訓(xùn)練、推理部署6.4 實(shí)際工程中的選擇建議在本地部署開源 LLM 做知識庫推理時(shí)更穩(wěn)妥的選擇通常是 BF16而不是 FP16。因?yàn)榇竽Ｐ屯评黼A段對數(shù)值范圍更敏感FP16 在極端權(quán)重分布下偶爾會出現(xiàn)輸出質(zhì)量劣化。而在需要極致推理速度時(shí)GPU 對 FP16 的計(jì)算吞吐往往更高這時(shí)可以使用 FP16 并做針對性評測確認(rèn)任務(wù)指標(biāo)沒有明顯回退再做選擇。如果顯存實(shí)在不夠就需要考慮量化方案把權(quán)重降低到 INT8 甚至 INT4。量化后模型文件更小推理速度提升但會有更明顯的精度損失。是否可接受不能拍腦袋決定必須在業(yè)務(wù)測試集上做對比評估。這里真正容易踩坑的地方是很多人看到模型量化后“看起來回答還挺正常”就直接上生產(chǎn)結(jié)果在專業(yè)術(shù)語密集、格式要求嚴(yán)格的場景中量化模型頻繁答非所問。任何精度選擇都應(yīng)該和評估體系綁定用數(shù)據(jù)決策而不是憑感覺。7. RAG 知識庫指標(biāo)如何評估一套 RAG 系統(tǒng)很多開發(fā)者在把 RAG 系統(tǒng)搭起來之后會遇到一個(gè)尷尬問題系統(tǒng)已經(jīng)能運(yùn)行了但到底好還是不好說不清楚。如果連好壞都無法量化后續(xù)優(yōu)化就無從下手。RAG 系統(tǒng)的評估是這部分課程非常強(qiáng)調(diào)的內(nèi)容。7.1 先從離線評估集開始在討論指標(biāo)之前先建立一個(gè)基本前提評估需要一套固定的測試集。沒有測試集談指標(biāo)都是紙上談兵。測試集的構(gòu)建方式是從知識庫中挑選一批有代表性的文檔針對它們設(shè)計(jì) 50 到 100 條問題并為每個(gè)問題標(biāo)注期望答案或至少標(biāo)注“應(yīng)該從哪些文檔片段中檢索”。這個(gè)集合稱為黃金集。以后每次調(diào)整切分參數(shù)、更換 embedding 模型、修改檢索策略都在同一套黃金集上跑看指標(biāo)變化。7.2 檢索質(zhì)量指標(biāo)RAG 系統(tǒng)的檢索環(huán)節(jié)直接決定了“模型看到了什么”。如果檢索結(jié)果里根本沒有正確答案生成環(huán)節(jié)再強(qiáng)也白搭。所以檢索質(zhì)量必須獨(dú)立評估。Hit Rate 是最直觀的指標(biāo)表示在檢索返回的 top-k 結(jié)果中是否至少有一條是相關(guān)的。如果檢索了 100 個(gè)問題其中 85 個(gè)問題在 top-5 結(jié)果里有正確答案Hit Rate5 就是 85%。它反映的是“有沒有召回”。MRR 全稱是 Mean Reciprocal Rank用于衡量第一個(gè)相關(guān)結(jié)果出現(xiàn)在什么位置。如果第一個(gè)相關(guān)問題排在第 1 位得 1 分排在第 3 位得 1/3 分。MRR 越高說明相關(guān)結(jié)果越靠前。它反映的是“召回到什么位置”。Precisionk 和 Recallk 則進(jìn)一步細(xì)化了準(zhǔn)確率評估。Precisionk 表示返回的 k 個(gè)結(jié)果中有多少比例是相關(guān)的Recallk 表示所有相關(guān)文檔中被召回的比例。這些指標(biāo)之間的關(guān)系可以這樣理解Hit Rate 是底線MRR 是排序質(zhì)量Recall 和 Precision 是更嚴(yán)格的雙向評估。在實(shí)際項(xiàng)目中通常先看 Hit Rate再關(guān)注 MRR最后結(jié)合業(yè)務(wù)需求看是否要調(diào)整 k 值。7.3 生成質(zhì)量指標(biāo)檢索質(zhì)量好不代表最終答案好。LLM 可能沒有遵循 Prompt 指令、可能遺漏關(guān)鍵信息、也可能在檢索內(nèi)容之外自行發(fā)揮。生成質(zhì)量需要單獨(dú)評估。Faithfulness忠實(shí)度衡量生成內(nèi)容是否忠實(shí)于檢索到的上下文。如果模型明明看到資料里寫“最大負(fù)載 50kg”卻在答案里說“最大負(fù)載 80kg”就是不忠實(shí)。這個(gè)問題本質(zhì)上就是幻覺。Answer Relevancy答案相關(guān)性衡量生成內(nèi)容是否切題是否回答了用戶的問題。有時(shí)候模型復(fù)述了一堆原文但用戶問的是“怎么解決”模型回答的是“是什么”就是不相關(guān)。這兩個(gè)指標(biāo)在生產(chǎn)系統(tǒng)中都可以自動計(jì)算也可以抽樣人工評分。自動計(jì)算的典型工具是 RAGAS它利用 LLM 作為評測器輸入問題和答案以及檢索文檔返回上述指標(biāo)的分?jǐn)?shù)。但要注意用 LLM 評 LLM 會有偏好偏差關(guān)鍵業(yè)務(wù)場景建議保留人工抽檢環(huán)節(jié)。7.4 一個(gè)最小化的 MRR 計(jì)算示例理解 MRR 最快的方式是親自動手實(shí)現(xiàn)一次。下面的偽代碼演示了 MRR 的計(jì)算邏輯。# eval_mrr_example.py def reciprocal_rank(relevant_rows, k): relevant_rows: 檢索結(jié)果列表按相關(guān)性分?jǐn)?shù)降序排列 k: 只看前 k 條結(jié)果 返回該查詢的 reciprocal rank 值 for rank, row in enumerate(relevant_rows[:k], start1): if row[is_relevant]: return 1.0 / rank return 0.0 # 示例一次查詢的檢索結(jié)果按相關(guān)性從高到低 query_result [ {doc_id: doc_1, is_relevant: False}, {doc_id: doc_2, is_relevant: True}, {doc_id: doc_3, is_relevant: False}, ] k 3 rr reciprocal_rank(query_result, k) print(f本次查詢的 reciprocal rank: {rr}) # MRR 就是多次查詢 reciprocal rank 的均值 all_queries [ {doc_id: doc_1, is_relevant: False}, {doc_id: doc_2, is_relevant: True}, {doc_id: doc_3, is_relevant: False}, ] def mean_reciprocal_rank(queries, k): total 0.0 for query in queries: total reciprocal_rank(query, k) return total / len(queries) mrr_value mean_reciprocal_rank([query_result, query_result], k3) print(fMRR3: {mrr_value})在實(shí)際項(xiàng)目中你可能不會手寫這些指標(biāo)而是借助 Ragas 或其他評測框架。但理解計(jì)算邏輯非常重要。只有理解每個(gè)指標(biāo)在獎勵什么、懲罰什么你才能在調(diào)優(yōu)時(shí)判斷“指標(biāo)上升是否真的意味著系統(tǒng)變好”。8. 常見問題與排查思路RAG 系統(tǒng)在開發(fā)階段的問題非常多很多現(xiàn)象看起來相近但原因完全不同。下面整理了一份常見問題排查表可以收藏備用。問題現(xiàn)象可能原因排查方式解決方案啟動時(shí)依賴安裝失敗Python 版本不兼容或缺少編譯環(huán)境查看 pip 錯誤日志確認(rèn) Python 版本升級到 Python 3.10或使用 conda 創(chuàng)建隔離環(huán)境知識庫檢索不到相關(guān)內(nèi)容文檔切分過大或過小語義被稀釋或截?cái)啻蜷_向量庫查看文本塊語句是否完整調(diào)整 chunk_size 和 chunk_overlap重新向量化答案和用戶問題不相關(guān)檢索返回了無關(guān)內(nèi)容且進(jìn)入了 Prompt打印 source_documents 查看召回文檔調(diào)整 top-k、加入混合檢索或重排模型回答出現(xiàn)幻覺檢索結(jié)果為空模型被迫自行補(bǔ)全檢查檢索結(jié)果的相似度分?jǐn)?shù)是否過低設(shè)置相似度閾值明確要求模型不知道就說不知道檢索到正確內(nèi)容但答案反而混亂塞進(jìn) Prompt 的上下文太多或相互矛盾檢查 source_documents 的數(shù)量和內(nèi)容降低 k 值或?qū)ξ臋n做去重和版本過濾專業(yè)術(shù)語大量出現(xiàn)時(shí)效果變差embedding 模型對專業(yè)領(lǐng)域理解不足在黃金集上對比不同 embedding 模型的指標(biāo)替換為領(lǐng)域微調(diào)過的 embedding 模型或引入關(guān)鍵詞檢索向量庫持久化后重啟數(shù)據(jù)丟失未配置持久化目錄或使用了純內(nèi)存模式檢查向量庫初始化參數(shù)配置 persist_directory 或使用服務(wù)端向量數(shù)據(jù)庫本地部署模型顯存不足精度選了 FP32/FP16模型參數(shù)過大查看顯存占用日志切換到 BF16 或量化到 INT8/INT4驗(yàn)證效果答案經(jīng)常引用過時(shí)文檔知識庫沒有增量更新機(jī)制檢查文檔更新時(shí)間戳引入數(shù)據(jù)版本管理和索引重建任務(wù)排查 RAG 問題有一個(gè)通用順序先確認(rèn)檢索階段有沒有正確召回再確認(rèn) Prompt 組裝有沒有問題最后再懷疑生成模型。很多人第一反應(yīng)是“模型不行”結(jié)果花了很多時(shí)間換模型問題依舊。實(shí)際上RAG 系統(tǒng)的大部分效果問題都出在數(shù)據(jù)和檢索環(huán)節(jié)。9. 最佳實(shí)踐與工程建議RAG 項(xiàng)目做到最后拼的往往不是某個(gè)環(huán)節(jié)的極致優(yōu)化而是工程體系是否完整。下面這幾條最佳實(shí)踐來自常見生產(chǎn)項(xiàng)目的經(jīng)驗(yàn)總結(jié)。9.1 從最小可行 RAG 開始不要在一開始就引入 Agentic RAG、混合檢索、知識圖譜等復(fù)雜組件。第一步應(yīng)該用最快的速度跑通“文檔加載 向量化 檢索 生成”的最小鏈路讓業(yè)務(wù)方看到效果也讓自己對數(shù)據(jù)情況有感知。然后再用評估數(shù)據(jù)驅(qū)動優(yōu)化。否則復(fù)雜系統(tǒng)一旦出問題定位成本會非常高。9.2 把文檔預(yù)處理當(dāng)成第一優(yōu)先級知識庫項(xiàng)目的天花板往往在文檔預(yù)處理階段。建議對文檔格式做一次全面盤點(diǎn)把“哪些文檔適合直接切分”“哪些文檔需要 OCR”“哪些文檔需要專門解析表格”列成明細(xì)表。對經(jīng)常出現(xiàn)的固定版式可以寫專門的解析函數(shù)而不是寄希望于一個(gè)通用解析器搞定所有文檔。9.3 檢索環(huán)節(jié)先保證召回再做精排在檢索鏈路設(shè)計(jì)上可以用兩級思路第一級盡量放寬條件保證相關(guān)文檔能被召回第二級用重排模型或更精細(xì)的過濾邏輯把真正有用的內(nèi)容排到前面。先優(yōu)化 Hit Rate再優(yōu)化 MRR最后才看生成質(zhì)量。這個(gè)順序不能反。9.4 Prompt 要明確約束生成行為生成階段的 Prompt 至少應(yīng)該包含三部分系統(tǒng)指令、檢索上下文、用戶問題。系統(tǒng)指令要明確告訴模型“只能依據(jù)檢索內(nèi)容回答不要使用訓(xùn)練時(shí)學(xué)到的知識補(bǔ)充如果檢索內(nèi)容不足回答不知道”。同時(shí)要求模型在回答時(shí)引用來源編號。這個(gè)設(shè)計(jì)能顯著降低幻覺率也讓溯源成為可能。9.5 記錄完整的運(yùn)行日志線上 RAG 系統(tǒng)建議記錄每次請求的完整鏈路原始問題、改寫后的問題如果有、召回的文檔列表、相似度分?jǐn)?shù)、送入 Prompt 的最終上下文、模型輸出、耗時(shí)。這些日志既是調(diào)試故障的依據(jù)也是后續(xù)搭建自動化評測集的數(shù)據(jù)來源。很多團(tuán)隊(duì)忽略了這一步等到上線后效果變差才發(fā)現(xiàn)沒有任何線索可以回溯。9.6 安全與權(quán)限是最后的底線如果知識庫包含了內(nèi)部資料或用戶隱私數(shù)據(jù)在架構(gòu)設(shè)計(jì)之初就要考慮權(quán)限隔離。不要讓一個(gè)用戶可以檢索到另一個(gè)用戶私有范圍的內(nèi)容。向量數(shù)據(jù)庫層的過濾能力很重要應(yīng)用層也要做身份認(rèn)證和操作審計(jì)。涉及敏感數(shù)據(jù)的項(xiàng)目務(wù)必在測試環(huán)境驗(yàn)證權(quán)限過濾邏輯后再上線并準(zhǔn)備好回滾方案。10. 總結(jié)LLM 工程師的核心能力模型回到這門 Udemy 課程第三部分的整體定位它真正想訓(xùn)練的能力不是“會調(diào)用 API”而是“會設(shè)計(jì)一套完整的 GenAI 系統(tǒng)”。從 RAG 鏈路到 Agent 概念從精度問題到評估指標(biāo)這些知識點(diǎn)串聯(lián)起來指向的是 LLM 工程師的四種核心能力。第一是數(shù)據(jù)工程能力。知道如何從真實(shí)業(yè)務(wù)文檔中提取可用知識如何處理 PDF、Word、HTML 等復(fù)雜格式如何設(shè)計(jì)切分策略。第二是檢索系統(tǒng)設(shè)計(jì)能力。知道如何選 embedding、如何選向量數(shù)據(jù)庫、如何設(shè)計(jì)混合檢索和重排而不是只會調(diào)用一個(gè)現(xiàn)成接口。第三是模型部署與成本控制能力。理解 FP16、BF16、量化的取舍知道在有限的 GPU 資源下如何平衡速度和質(zhì)量。第四是評估能力。能建立測試集能看懂指標(biāo)變化能通過數(shù)據(jù)定位瓶頸。這是區(qū)分“能跑 Demo”和“能上生產(chǎn)”的分水嶺。如果這篇文章讓你有收獲建議馬上選一份實(shí)際文檔按照第二章到第五章的流程搭一個(gè)最小知識庫再做一套 50 條問題的評估集記錄當(dāng)前指標(biāo)。然后試著調(diào)整 chunk_size、切換 embedding 模型、加入重排觀察指標(biāo)和答案質(zhì)量的變化。做 LLM 應(yīng)用開發(fā)最大的誤區(qū)是以為“視頻課刷完就是會了”。真正值回票價(jià)的方式是把課程里的評估方法用到自己的知識庫里把系統(tǒng)從“能跑”改到“好用”。RAG 工程中還有很多細(xì)節(jié)值得深入比如更復(fù)雜的文檔解析、Agent 多輪檢索、基于本體的約束生成、以及更細(xì)粒度的評測體系。每一條都值得再單獨(dú)寫一篇實(shí)踐筆記。 檢索增強(qiáng)生成全鏈路解析：從文檔加載到評估的大模型知識庫工程實(shí)踐
很多開發(fā)者第一次接觸大模型時(shí)第一反應(yīng)是“調(diào)用 API 太簡單了”把 Prompt 封裝好用戶問題丟給 GPT 或國內(nèi)商用模型一個(gè)聊天機(jī)器人就上線了。但真正進(jìn)入企業(yè)項(xiàng)目就會發(fā)現(xiàn)API 只是一個(gè)入口真正難的部分在于怎么讓模型“看到”私有知識、怎么控制幻覺、怎么評估系統(tǒng)效果、怎么在有限顯存環(huán)境下做推理部署。這些問題背后正是 LLM 工程化的完整鏈路。如果說 LLM 工程是一門需要體系化學(xué)習(xí)的課程那么 GenAI 和 RAG 就是其中最核心的兩個(gè)板塊。RAG 不是“把一個(gè) PDF 塞給大模型”這種一句話能講清的操作而是一套數(shù)據(jù)工程、檢索系統(tǒng)、生成策略和評估體系的組合。這也是這門 Udemy 課程第三部分的重點(diǎn)從純 Prompt 調(diào)用走向生產(chǎn)級知識庫應(yīng)用。這篇文章會以該課程第三部分為線索梳理 RAG 完整鏈路文檔加載、切分、向量化、檢索、生成、Agentic RAG 和 OAG 等進(jìn)階方向、FP16/FP32/BF16 精度問題以及 RAG 知識庫評估指標(biāo)。如果你正在做知識庫問答、想系統(tǒng)學(xué)習(xí) LLM 工程或者正從傳統(tǒng)后端轉(zhuǎn)向 AI 應(yīng)用開發(fā)這篇內(nèi)容應(yīng)該能幫你建立一份更清晰的行動地圖。1. 為什么 RAG 是 LLM 落地繞不開的方向先做一個(gè)判斷在 2025 年這個(gè)時(shí)間點(diǎn)RAG 已經(jīng)不只是“一個(gè)技術(shù)方案”而是 LLM 應(yīng)用落地事實(shí)上的標(biāo)準(zhǔn)形態(tài)。聊天、寫作、翻譯可能用不到 RAG但凡是涉及私有數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)、專業(yè)文檔的場景RAG 幾乎都是第一選擇。原因在于 LLM 本身有三大硬約束。第一知識截止。預(yù)訓(xùn)練模型的知識停留在訓(xùn)練數(shù)據(jù)截止時(shí)間訓(xùn)練之后發(fā)生的事情它不知道。如果你問它某個(gè)產(chǎn)品上周發(fā)布的新功能它大概率會一本正經(jīng)地編一個(gè)答案。第二私有數(shù)據(jù)不可見。企業(yè)內(nèi)部的規(guī)章制度、產(chǎn)品手冊、客服工單、專利文檔模型在訓(xùn)練時(shí)根本沒有見過。直接讓模型回答這些內(nèi)容它只能靠“合理猜測”而合理猜測在專業(yè)場景里往往就是事故。第三幻覺問題。即使模型不知道答案它也會因?yàn)檎Z言模型的本質(zhì)而生成一個(gè)看起來通順的回復(fù)。這不是模型“壞”而是概率生成機(jī)制導(dǎo)致的必然結(jié)果。解決幻覺最有效的工程手段之一就是用檢索到的真實(shí)內(nèi)容去約束生成范圍。沒有 RAG 的時(shí)候要讓模型掌握新的領(lǐng)域知識主流方案是微調(diào)Fine-tuning。但微調(diào)的成本高、周期長每次知識更新都要重新訓(xùn)練一輪。更關(guān)鍵的是微調(diào)擅長改變模型的行為方式和表達(dá)風(fēng)格卻并不擅長記憶大量新事實(shí)。讓一個(gè) 7B 模型通過微調(diào)背下一本 500 頁的產(chǎn)品手冊既不經(jīng)濟(jì)也容易過擬合。RAG 的思路是把“記憶”從模型內(nèi)部搬到外部給模型一本可以隨時(shí)翻閱的參考書這個(gè)參考書就是你的知識庫。模型回答之前先從參考書里找出與問題最相關(guān)的幾個(gè)片段再把這些片段作為上下文交給模型生成答案。用“開卷考試”來類比 RAG 和普通 Prompt 生成的區(qū)別非常直觀。但在真實(shí)項(xiàng)目中這套“開卷考試”的工程復(fù)雜度遠(yuǎn)高于想象。很多人以為 RAG 就是“向量數(shù)據(jù)庫 Prompt”實(shí)際做下去才發(fā)現(xiàn)文檔怎么拆、按什么粒度拆、檢索用什么向量、top-k 怎么設(shè)、重排怎么做、效果用什么指標(biāo)來衡量每一步都可能讓最終效果出現(xiàn)數(shù)倍的差距。2. RAG 完整鏈路與核心概念2.1 RAG 的標(biāo)準(zhǔn)流程一個(gè)標(biāo)準(zhǔn)的 RAG 系統(tǒng)由四個(gè)環(huán)節(jié)組成。第一數(shù)據(jù)準(zhǔn)備階段。原始文檔需要經(jīng)過加載、解析、清洗、切分變成適合檢索的文本塊chunk。這個(gè)環(huán)節(jié)經(jīng)常被低估但它的質(zhì)量直接決定了整個(gè)知識庫的上限。如果原始文檔是 PDF頁眉頁腳、表格、掃描圖片都會成為干擾項(xiàng)如果切分粒度不對再好的向量模型也檢索不準(zhǔn)。第二索引構(gòu)建階段。每個(gè)文本塊通過 embedding 模型轉(zhuǎn)換為向量寫入向量數(shù)據(jù)庫。同時(shí)可以保留原始文本和元數(shù)據(jù)來源、頁碼、標(biāo)題等方便后續(xù)溯源。第三檢索階段。用戶輸入問題后先把問題也轉(zhuǎn)換為向量然后在向量數(shù)據(jù)庫中做相似度檢索取回最相關(guān)的 top-k 個(gè)文本塊。更復(fù)雜的系統(tǒng)會在這個(gè)階段加入關(guān)鍵詞檢索和重排模型。第四生成階段。把檢索到的文本塊和用戶問題組裝成 Prompt交給 LLM 生成最終答案。為了減少幻覺Prompt 中通常會明確要求模型只基于檢索內(nèi)容作答無法回答時(shí)要明確說明。2.2 RAG 和微調(diào)不是二選一很多入門者會在 RAG 和微調(diào)之間糾結(jié)。我的建議是先分清楚你要解決的是哪一類問題。RAG 適合解決“知識更新”和“私有數(shù)據(jù)接入”的問題。比如 FAQ 問答、產(chǎn)品文檔問答、行業(yè)報(bào)告摘要。它的優(yōu)勢是知識可以隨時(shí)更新、答案可以溯源一次數(shù)據(jù)更新不需要重新訓(xùn)練模型。微調(diào)更適合解決“行為方式”和“輸出格式”的問題。比如讓模型學(xué)習(xí)某個(gè)業(yè)務(wù)場景下的固定話術(shù)、指令遵循習(xí)慣或者把輸出格式嚴(yán)格限定成系統(tǒng)需要的 JSON 結(jié)構(gòu)。微調(diào)改變的是模型的“性情”RAG 給的是模型的“素材”兩者服務(wù)的層次完全不同。生產(chǎn)系統(tǒng)里常見的做法是兩者結(jié)合先微調(diào)出一個(gè)懂業(yè)務(wù)話術(shù)的底座模型再用 RAG 為它提供實(shí)時(shí)事實(shí)。對大部分團(tuán)隊(duì)來說RAG 的性價(jià)比上限更高因?yàn)樗簧婕坝?xùn)練資源。不要一上來就微調(diào)先把 RAG 鏈路跑通。2.3 從 RAG 到 Agentic RAG 和 OAG課程第三部分的內(nèi)容里進(jìn)階方向會從“單次 RAG”延伸到“Agentic RAG”和“OAG”這類新概念。理解這兩個(gè)概念有助于看清楚 RAG 演進(jìn)的脈絡(luò)。Agentic RAG 的核心變化是把 RAG 從“一次檢索 一次生成”升級為“多輪決策循環(huán)”。簡單說就是讓 LLM Agent 承擔(dān)檢索規(guī)劃的角色。它先理解用戶問題決定是否要檢索、檢索什么拿到檢索結(jié)果后判斷信息是否足夠如果不夠就改寫查詢詞再檢索或者調(diào)用外部工具獲取信息最后綜合多輪結(jié)果生成答案。這種設(shè)計(jì)解決的是復(fù)雜問題拆解場景。比如用戶問“幫我對比一下 A 產(chǎn)品和 B 產(chǎn)品在三個(gè)維度的差異”單次向量檢索很難把三個(gè)維度一次找全。Agent 可以把這個(gè)問題拆成多個(gè)子問題分別檢索再匯總。這就是 LLM Agent 與 RAG 結(jié)合的典型價(jià)值。OAG 指的是 Ontology-Augmented Generation即本體增強(qiáng)生成。它和 RAG 的區(qū)別在于RAG 檢索的是非結(jié)構(gòu)化的自然語言文本OAG 使用的是結(jié)構(gòu)化的本體或知識圖譜。本體會預(yù)先定義實(shí)體、關(guān)系和規(guī)則比如在通信協(xié)議文檔中“ACK/NACK”“RRC 狀態(tài)”這樣的概念和它們之間的關(guān)聯(lián)會被顯式建模。生成時(shí)系統(tǒng)先從本體中查詢符合邏輯約束的事實(shí)再交給 LLM 生成。在專業(yè)領(lǐng)域比如 3GPP 協(xié)議規(guī)范、醫(yī)療指南、金融監(jiān)管文件這類文檔中OAG 比普通 RAG 更容易保證語義一致性。普通 RAG 容易把不同版本的協(xié)議內(nèi)容混在一起而基于本體的檢索可以根據(jù)版本關(guān)系和實(shí)體約束做更精確的過濾。RAG 和 OAG 并不互斥一個(gè)成熟的專業(yè)知識庫系統(tǒng)往往兩種手段同時(shí)使用。3. 文檔加載解析全流程容易被低估的一環(huán)如果說 RAG 鏈路中有一個(gè)最容易被低估、但又最決定效果上限的環(huán)節(jié)那一定是文檔加載和切分。很多團(tuán)隊(duì)把大量時(shí)間花在調(diào) Prompt 和換模型上卻忽略了知識庫的“地基”。實(shí)際上如果輸入到向量庫的文本本身就是臟的、碎的、無上下文的再好的檢索模型也救不回來。3.1 不同文檔類型的加載難點(diǎn)先從加載開始?，F(xiàn)實(shí)項(xiàng)目里遇到的文檔遠(yuǎn)比教科書例子復(fù)雜。PDF 是最常見的格式但 PDF 內(nèi)部差異很大。文本型 PDF 可以直接抽取文字但頁眉頁腳會污染正文表格型 PDF 抽取后可能變成一段無結(jié)構(gòu)的字符串掃描型 PDF 需要先 OCR而 OCR 又可能引入錯字。Word 文檔的問題在于樣式標(biāo)記和批注PPT 的難點(diǎn)在于每頁內(nèi)容太碎片化。HTML 頁面則需要抽取正文、剝離導(dǎo)航和腳本。這些工作屬于典型的數(shù)據(jù)工程聽起來不“AI”但直接決定下游質(zhì)量。在這個(gè)階段可以借助 LangChain 的 document loader 體系。它提供了針對 PDF、Word、HTML、Markdown、PowerPoint 等多種格式的加載器。也可以引入 Unstructured 等解析庫來做表格識別和 OCR。不過不能只依賴現(xiàn)成工具業(yè)務(wù)文檔的布局規(guī)則往往需要自己寫解析邏輯。3.2 文本切分策略切分是另一個(gè)關(guān)鍵決策點(diǎn)。切分的核心矛盾是塊太大向量化后語義會被稀釋檢索不夠精準(zhǔn)塊太小上下文不完整LLM 生成時(shí)看到的背景信息太少。經(jīng)驗(yàn)上的常見范圍是 200 到 500 個(gè) token。但這只是起點(diǎn)具體值要根據(jù)文檔類型和測試效果調(diào)整。切分方式也分幾個(gè)層次。固定大小切分最簡單按 token 數(shù)硬切但會切斷句子和段落。遞歸字符切分是 LangChain 中最常用的方式它按分隔符優(yōu)先級遞歸嘗試盡量保住段落和句子結(jié)構(gòu)適合通用文檔。按 Markdown 標(biāo)題切分適合結(jié)構(gòu)化文檔能保證每個(gè)塊對應(yīng)一個(gè)語義完整的章節(jié)。語義切分則利用 embedding 的相似度來決定邊界效果最好但計(jì)算成本高。切分時(shí)還要設(shè)置 overlap也就是相鄰塊之間的重疊區(qū)域。Overlap 的意義在于如果一條知識恰好落在切分邊界上沒有重疊就會導(dǎo)致它被切斷檢索時(shí)自然找不到。一般建議 overlap 設(shè)置為 chunk size 的 10% 到 20%。下面給出一段基于 LangChain 的 PDF 加載與切分示例代碼。這段示例使用 LangChain 0.x 早期的 API 寫法新版中的導(dǎo)入路徑可能有調(diào)整請以你安裝的包版本為準(zhǔn)。# document_prepare.py from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加載 PDF 文檔 loader PyPDFLoader(./data/product_manual.pdf) documents loader.load() print(f加載得到 {len(documents)} 頁內(nèi)容) # 2. 遞歸字符切分 splitter RecursiveCharacterTextSplitter( chunk_size400, # 每個(gè)文本塊的目標(biāo)大小token 級別 chunk_overlap50, # 相鄰塊重疊大小 separators[\n\n, \n, 。, , , , , ], ) chunks splitter.split_documents(documents) print(f切分后得到 {len(chunks)} 個(gè)文本塊) # 3. 查看第一個(gè)塊的元信息和前 200 字 print(chunks[0].page_content[:200]) print(chunks[0].metadata)在真實(shí)項(xiàng)目中不建議把所有文檔類型都統(tǒng)一走同一條切分邏輯。正確做法是先對文檔做分類規(guī)章制度類按章節(jié)切產(chǎn)品手冊類按功能模塊切FAQ 類按問答對整體保留。切分策略應(yīng)該被當(dāng)成一個(gè)可配置的參數(shù)允許在評估后反復(fù)調(diào)整而不是寫死一次就不動了。4. 環(huán)境準(zhǔn)備與依賴安裝要動手跑通 RAG 示例需要先準(zhǔn)備一套 Python 環(huán)境。下面的環(huán)境清單不針對特定版本建議以“安裝時(shí)最新穩(wěn)定版”為準(zhǔn)本文重點(diǎn)演示通用思路。操作系統(tǒng)推薦 macOS 或 LinuxWindows 也可以運(yùn)行但依賴安裝時(shí)更容易遇到編譯問題。Python 版本建議 3.9 以上最好使用 3.10 或 3.11。核心依賴拆成三部分向量化與檢索框架langchain、langchain-community、langchain-openai。向量存儲chromadb 或者 faiss-cpu。文檔解析pypdf、unstructured、pandas。模型調(diào)用openai如果使用國內(nèi)大模型則改成對應(yīng) SDK。創(chuàng)建虛擬環(huán)境并安裝依賴python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install langchain langchain-community langchain-openai pip install chromadb faiss-cpu pip install pypdf unstructured如果你要調(diào)用 OpenAI 接口需要提前配置環(huán)境變量。如果使用其他模型服務(wù)或本地部署的模型替換對應(yīng)的 embedding 和 LLM 類即可。export OPENAI_API_KEY你的密鑰如果你所在環(huán)境無法直接使用境外模型服務(wù)可以選擇國內(nèi)廠商提供的兼容接口或者使用本地部署的模型。這個(gè)選擇不影響 RAG 的架構(gòu)思路只影響具體調(diào)用方式。5. 向量化與檢索RAG 的核心決策點(diǎn)5.1 Embedding 模型選擇文本塊準(zhǔn)備好之后下一步是向量化。這一步的核心是選擇一個(gè)合適的 embedding 模型。Embedding 模型會把一段文本映射成高維向量語義相近的文本在向量空間中的距離也更近。目前選擇很多OpenAI 提供了 text-embedding-3-small 和 text-embedding-3-large國內(nèi)也有 BGE、M3E 等開源中文 embedding 模型還有各種本地可部署的模型。選擇 embedding 模型時(shí)有三個(gè)考量因素。第一是語言適配。如果你的知識庫主要是中文建議優(yōu)先在中文語料上表現(xiàn)更好的模型或者做多語言模型而不是直接使用以英文為重心的小模型。第二是維度與成本。維度越高通常表達(dá)能力越強(qiáng)但存儲和計(jì)算成本也越高。text-embedding-3-small 默認(rèn)只有幾百維對于大多數(shù)知識庫場景已經(jīng)夠用。第三是推理環(huán)境。如果知識庫部署在內(nèi)部網(wǎng)絡(luò)無法訪問外部 API那就必須選擇可在本地 GPU 或 CPU 上運(yùn)行的 embedding 模型。開源模型在本地部署完全沒有問題。5.2 向量數(shù)據(jù)庫選型向量數(shù)據(jù)庫的作用是存儲向量并支持快速相似度檢索。選型可以從項(xiàng)目規(guī)模出發(fā)。FAISS 是 Meta 開源的向量檢索庫不是一個(gè)完整數(shù)據(jù)庫不提供數(shù)據(jù)持久化和權(quán)限管理但它輕量、高效適合原型驗(yàn)證和小規(guī)模項(xiàng)目。Chroma 是一個(gè)更完整的本地向量數(shù)據(jù)庫提供了簡單的 API 和持久化能力適合中小團(tuán)隊(duì)快速起步。Milvus 和 Qdrant 是面向生產(chǎn)環(huán)境的分布式向量數(shù)據(jù)庫支持水平擴(kuò)展、多租戶、權(quán)限控制和豐富的過濾能力適合數(shù)據(jù)量達(dá)到幾十萬甚至上百萬條級別的系統(tǒng)。選型建議個(gè)人學(xué)習(xí)和搭建原型直接用 FAISS 或 Chroma企業(yè)項(xiàng)目評估 Milvus、Qdrant如果團(tuán)隊(duì)已經(jīng)引入了 Elasticsearch 8.x 且同時(shí)在用 ES 做全文檢索也可以考慮用它內(nèi)置的向量檢索能力以減少運(yùn)維組件的數(shù)量。5.3 檢索策略向量檢索、混合檢索與重排很多人把 RAG 的檢索等同于“向量相似度檢索”但這只是起點(diǎn)。向量檢索適合語義相關(guān)性判斷比如“最大負(fù)載多少”能找到包含“負(fù)載能力”的文檔即使沒有“最大負(fù)載”這四個(gè)字。缺點(diǎn)是對精確關(guān)鍵詞不敏感。關(guān)鍵詞檢索比如 BM25恰恰相反它擅長精確匹配比如產(chǎn)品型號、錯誤碼、人名但無法理解同義改寫。真實(shí)知識庫中這兩類問題同時(shí)存在。于是就有了混合檢索同時(shí)執(zhí)行向量檢索和關(guān)鍵詞檢索再把兩部分結(jié)果合并用重排序模型Rerank重新打分選出最終進(jìn)入 Prompt 的內(nèi)容。重排階段通常把候選從 20 條壓縮到 3 到 5 條能顯著提升生成質(zhì)量但也會帶來額外的計(jì)算延遲。對于剛起步的團(tuán)隊(duì)建議先用純向量檢索跑通流程再加入關(guān)鍵詞檢索和重排逐步驗(yàn)證每一步帶來的收益不要一上來就堆復(fù)雜組件。下面是一個(gè)基于 Chroma 和 LangChain 的完整檢索問答示例。這里使用 LangChain 中常見的RetrievalQA封裝。# rag_qa.py from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA # 1. 初始化 embedding 模型 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) # 2. 把上一步切分好的 chunks 寫入 Chroma 向量庫 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) # 3. 構(gòu)建檢索器 retriever vectorstore.as_retriever( search_typesimilarity, search_kwargs{k: 4}, ) # 4. 初始化生成模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 5. 構(gòu)建 RAG 問答鏈 qa_chain RetrievalQA.from_chain_type( llmllm, retrieverretriever, return_source_documentsTrue, ) # 6. 執(zhí)行查詢 query 產(chǎn)品手冊中該設(shè)備的最大負(fù)載是多少 result qa_chain.invoke({query: query}) print(答案, result[result]) print(\n--- 參考來源 ---) for doc in result[source_documents]: print(來源, doc.metadata.get(source, 未知)) print(內(nèi)容, doc.page_content[:100])這個(gè)代碼里有幾個(gè)細(xì)節(jié)值得注意。search_kwargs{k: 4}表示只取回 4 個(gè)最相關(guān)的文本塊。k 值太小容易漏答案k 值太大則會把無關(guān)內(nèi)容塞給 LLM讓答案跑偏。一般從 4 到 6 起步再根據(jù)評估效果調(diào)整。temperature0是問答場景的常見配置。知識庫問答要求穩(wěn)定、忠實(shí)不需要創(chuàng)造性輸出。而寫文案、頭腦風(fēng)暴類場景才需要提高溫度。return_source_documentsTrue一定要保留否則你很難知道答案是來自知識庫還是模型自己編的。生產(chǎn)系統(tǒng)中來源溯源是知識庫功能的基本要求。5.4 從示例到生產(chǎn)系統(tǒng)上面的示例跑通之后要往生產(chǎn)系統(tǒng)走還有幾件事需要補(bǔ)充。一是索引的增量更新。文檔會更新、刪除、追加不能每次全量重建。實(shí)踐中會引入調(diào)度任務(wù)和消息隊(duì)列按文檔哈?；虬姹咎柵袛嗍欠裥枰匦孪蛄炕６窍蛄繑?shù)據(jù)庫的安全性。私有知識庫通常涉及敏感數(shù)據(jù)。向量庫本身往往沒有嚴(yán)格的權(quán)限模型需要在應(yīng)用層做好訪問控制對用戶查詢和檢索結(jié)果做權(quán)限過濾。三是檢索質(zhì)量監(jiān)控。線上系統(tǒng)一般會記錄每次查詢的召回文檔、相關(guān)性分?jǐn)?shù)和最終答案并定期抽樣做人工評估。這樣當(dāng)某個(gè)知識點(diǎn)的檢索質(zhì)量下降時(shí)可以及時(shí)定位是數(shù)據(jù)更新問題還是模型變更問題。6. LLM 精度問題FP16、FP32、BF16 在工程中的取舍在 RAG 示例中你可能用的是托管模型 API不需要關(guān)心權(quán)重存儲的精度問題。但如果你要做本地推理、私有化部署或者用開源模型搭建知識庫那么 LLM 的精度問題就是繞不開的工程決策。6.1 為什么精度問題值得關(guān)注大模型的權(quán)重是一組浮點(diǎn)數(shù)。浮點(diǎn)數(shù)的表示精度和范圍由格式?jīng)Q定。同一個(gè)模型參數(shù)用不同精度存儲和計(jì)算會直接影響三件事顯存占用、推理速度、輸出質(zhì)量。先給一個(gè)粗略的顯存估算。一個(gè) 7B70 億參數(shù)參數(shù)的模型以 FP32 存儲參數(shù)大小約為 7 × 4 字節(jié)等于 28GB。FP16 或 BF16 是半精度每個(gè)參數(shù) 2 字節(jié)所以約 14GB。如果再算上推理過程的中間激活值實(shí)際占用會更高。這也是為什么 8GB 顯卡幾乎跑不動 7B 模型的全量推理通常需要配合 4bit 量化。6.2 三種精度格式背后的設(shè)計(jì)差異FP32 是單精度浮點(diǎn)數(shù)寬度 32 位其中指數(shù)位 8 位尾數(shù)位 23 位。它是 CPU 和 GPU 上最通用的標(biāo)準(zhǔn)格式精度最高。模型預(yù)訓(xùn)練和科學(xué)計(jì)算常用 FP32 作為基準(zhǔn)。缺點(diǎn)是顯存占用大、計(jì)算速度相對慢。FP16 是 IEEE 半精度浮點(diǎn)數(shù)寬度 16 位其中指數(shù)位 5 位尾數(shù)位 10 位。相比 FP32它節(jié)省一半顯存計(jì)算速度也更快。但指數(shù)位只有 5 位導(dǎo)致它能表示的數(shù)值范圍變小。當(dāng)某個(gè)權(quán)重?cái)?shù)值很大時(shí)會被表示成無窮大當(dāng)數(shù)值極端小時(shí)又容易變成 0。這就是“溢出”和“下溢”問題。在訓(xùn)練大模型時(shí)如果直接用 FP16梯度很容易在反向傳播中丟失。BF16 是 Brain Floating Point也是 16 位但指數(shù)位有 8 位和 FP32 相同尾數(shù)位只有 7 位。它的巧妙之處在于“犧牲精度保留范圍”。因?yàn)楹?FP32 擁有相同的指數(shù)范圍BF16 在高數(shù)值范圍下更不容易溢出訓(xùn)練時(shí)穩(wěn)定性明顯優(yōu)于 FP16。代價(jià)是尾數(shù)少同一個(gè)數(shù)值BF16 能表示的小數(shù)精度比 FP16 低。6.3 三種精度的對比精度格式位寬指數(shù)位尾數(shù)位主要優(yōu)點(diǎn)主要缺點(diǎn)常見用途FP3232 位8 位23 位精度最高顯存占用大、計(jì)算慢預(yù)訓(xùn)練基準(zhǔn)、科學(xué)計(jì)算、調(diào)試FP1616 位5 位10 位顯存減半、速度快數(shù)值范圍小訓(xùn)練易溢出混合精度訓(xùn)練、GPU 推理BF1616 位8 位7 位數(shù)值范圍與 FP32 相同訓(xùn)練穩(wěn)定尾數(shù)少精度略低大模型預(yù)訓(xùn)練、推理部署6.4 實(shí)際工程中的選擇建議在本地部署開源 LLM 做知識庫推理時(shí)更穩(wěn)妥的選擇通常是 BF16而不是 FP16。因?yàn)榇竽Ｐ屯评黼A段對數(shù)值范圍更敏感FP16 在極端權(quán)重分布下偶爾會出現(xiàn)輸出質(zhì)量劣化。而在需要極致推理速度時(shí)GPU 對 FP16 的計(jì)算吞吐往往更高這時(shí)可以使用 FP16 并做針對性評測確認(rèn)任務(wù)指標(biāo)沒有明顯回退再做選擇。如果顯存實(shí)在不夠就需要考慮量化方案把權(quán)重降低到 INT8 甚至 INT4。量化后模型文件更小推理速度提升但會有更明顯的精度損失。是否可接受不能拍腦袋決定必須在業(yè)務(wù)測試集上做對比評估。這里真正容易踩坑的地方是很多人看到模型量化后“看起來回答還挺正常”就直接上生產(chǎn)結(jié)果在專業(yè)術(shù)語密集、格式要求嚴(yán)格的場景中量化模型頻繁答非所問。任何精度選擇都應(yīng)該和評估體系綁定用數(shù)據(jù)決策而不是憑感覺。7. RAG 知識庫指標(biāo)如何評估一套 RAG 系統(tǒng)很多開發(fā)者在把 RAG 系統(tǒng)搭起來之后會遇到一個(gè)尷尬問題系統(tǒng)已經(jīng)能運(yùn)行了但到底好還是不好說不清楚。如果連好壞都無法量化后續(xù)優(yōu)化就無從下手。RAG 系統(tǒng)的評估是這部分課程非常強(qiáng)調(diào)的內(nèi)容。7.1 先從離線評估集開始在討論指標(biāo)之前先建立一個(gè)基本前提評估需要一套固定的測試集。沒有測試集談指標(biāo)都是紙上談兵。測試集的構(gòu)建方式是從知識庫中挑選一批有代表性的文檔針對它們設(shè)計(jì) 50 到 100 條問題并為每個(gè)問題標(biāo)注期望答案或至少標(biāo)注“應(yīng)該從哪些文檔片段中檢索”。這個(gè)集合稱為黃金集。以后每次調(diào)整切分參數(shù)、更換 embedding 模型、修改檢索策略都在同一套黃金集上跑看指標(biāo)變化。7.2 檢索質(zhì)量指標(biāo)RAG 系統(tǒng)的檢索環(huán)節(jié)直接決定了“模型看到了什么”。如果檢索結(jié)果里根本沒有正確答案生成環(huán)節(jié)再強(qiáng)也白搭。所以檢索質(zhì)量必須獨(dú)立評估。Hit Rate 是最直觀的指標(biāo)表示在檢索返回的 top-k 結(jié)果中是否至少有一條是相關(guān)的。如果檢索了 100 個(gè)問題其中 85 個(gè)問題在 top-5 結(jié)果里有正確答案Hit Rate5 就是 85%。它反映的是“有沒有召回”。MRR 全稱是 Mean Reciprocal Rank用于衡量第一個(gè)相關(guān)結(jié)果出現(xiàn)在什么位置。如果第一個(gè)相關(guān)問題排在第 1 位得 1 分排在第 3 位得 1/3 分。MRR 越高說明相關(guān)結(jié)果越靠前。它反映的是“召回到什么位置”。Precisionk 和 Recallk 則進(jìn)一步細(xì)化了準(zhǔn)確率評估。Precisionk 表示返回的 k 個(gè)結(jié)果中有多少比例是相關(guān)的Recallk 表示所有相關(guān)文檔中被召回的比例。這些指標(biāo)之間的關(guān)系可以這樣理解Hit Rate 是底線MRR 是排序質(zhì)量Recall 和 Precision 是更嚴(yán)格的雙向評估。在實(shí)際項(xiàng)目中通常先看 Hit Rate再關(guān)注 MRR最后結(jié)合業(yè)務(wù)需求看是否要調(diào)整 k 值。7.3 生成質(zhì)量指標(biāo)檢索質(zhì)量好不代表最終答案好。LLM 可能沒有遵循 Prompt 指令、可能遺漏關(guān)鍵信息、也可能在檢索內(nèi)容之外自行發(fā)揮。生成質(zhì)量需要單獨(dú)評估。Faithfulness忠實(shí)度衡量生成內(nèi)容是否忠實(shí)于檢索到的上下文。如果模型明明看到資料里寫“最大負(fù)載 50kg”卻在答案里說“最大負(fù)載 80kg”就是不忠實(shí)。這個(gè)問題本質(zhì)上就是幻覺。Answer Relevancy答案相關(guān)性衡量生成內(nèi)容是否切題是否回答了用戶的問題。有時(shí)候模型復(fù)述了一堆原文但用戶問的是“怎么解決”模型回答的是“是什么”就是不相關(guān)。這兩個(gè)指標(biāo)在生產(chǎn)系統(tǒng)中都可以自動計(jì)算也可以抽樣人工評分。自動計(jì)算的典型工具是 RAGAS它利用 LLM 作為評測器輸入問題和答案以及檢索文檔返回上述指標(biāo)的分?jǐn)?shù)。但要注意用 LLM 評 LLM 會有偏好偏差關(guān)鍵業(yè)務(wù)場景建議保留人工抽檢環(huán)節(jié)。7.4 一個(gè)最小化的 MRR 計(jì)算示例理解 MRR 最快的方式是親自動手實(shí)現(xiàn)一次。下面的偽代碼演示了 MRR 的計(jì)算邏輯。# eval_mrr_example.py def reciprocal_rank(relevant_rows, k): relevant_rows: 檢索結(jié)果列表按相關(guān)性分?jǐn)?shù)降序排列 k: 只看前 k 條結(jié)果 返回該查詢的 reciprocal rank 值 for rank, row in enumerate(relevant_rows[:k], start1): if row[is_relevant]: return 1.0 / rank return 0.0 # 示例一次查詢的檢索結(jié)果按相關(guān)性從高到低 query_result [ {doc_id: doc_1, is_relevant: False}, {doc_id: doc_2, is_relevant: True}, {doc_id: doc_3, is_relevant: False}, ] k 3 rr reciprocal_rank(query_result, k) print(f本次查詢的 reciprocal rank: {rr}) # MRR 就是多次查詢 reciprocal rank 的均值 all_queries [ {doc_id: doc_1, is_relevant: False}, {doc_id: doc_2, is_relevant: True}, {doc_id: doc_3, is_relevant: False}, ] def mean_reciprocal_rank(queries, k): total 0.0 for query in queries: total reciprocal_rank(query, k) return total / len(queries) mrr_value mean_reciprocal_rank([query_result, query_result], k3) print(fMRR3: {mrr_value})在實(shí)際項(xiàng)目中你可能不會手寫這些指標(biāo)而是借助 Ragas 或其他評測框架。但理解計(jì)算邏輯非常重要。只有理解每個(gè)指標(biāo)在獎勵什么、懲罰什么你才能在調(diào)優(yōu)時(shí)判斷“指標(biāo)上升是否真的意味著系統(tǒng)變好”。8. 常見問題與排查思路RAG 系統(tǒng)在開發(fā)階段的問題非常多很多現(xiàn)象看起來相近但原因完全不同。下面整理了一份常見問題排查表可以收藏備用。問題現(xiàn)象可能原因排查方式解決方案啟動時(shí)依賴安裝失敗Python 版本不兼容或缺少編譯環(huán)境查看 pip 錯誤日志確認(rèn) Python 版本升級到 Python 3.10或使用 conda 創(chuàng)建隔離環(huán)境知識庫檢索不到相關(guān)內(nèi)容文檔切分過大或過小語義被稀釋或截?cái)啻蜷_向量庫查看文本塊語句是否完整調(diào)整 chunk_size 和 chunk_overlap重新向量化答案和用戶問題不相關(guān)檢索返回了無關(guān)內(nèi)容且進(jìn)入了 Prompt打印 source_documents 查看召回文檔調(diào)整 top-k、加入混合檢索或重排模型回答出現(xiàn)幻覺檢索結(jié)果為空模型被迫自行補(bǔ)全檢查檢索結(jié)果的相似度分?jǐn)?shù)是否過低設(shè)置相似度閾值明確要求模型不知道就說不知道檢索到正確內(nèi)容但答案反而混亂塞進(jìn) Prompt 的上下文太多或相互矛盾檢查 source_documents 的數(shù)量和內(nèi)容降低 k 值或?qū)ξ臋n做去重和版本過濾專業(yè)術(shù)語大量出現(xiàn)時(shí)效果變差embedding 模型對專業(yè)領(lǐng)域理解不足在黃金集上對比不同 embedding 模型的指標(biāo)替換為領(lǐng)域微調(diào)過的 embedding 模型或引入關(guān)鍵詞檢索向量庫持久化后重啟數(shù)據(jù)丟失未配置持久化目錄或使用了純內(nèi)存模式檢查向量庫初始化參數(shù)配置 persist_directory 或使用服務(wù)端向量數(shù)據(jù)庫本地部署模型顯存不足精度選了 FP32/FP16模型參數(shù)過大查看顯存占用日志切換到 BF16 或量化到 INT8/INT4驗(yàn)證效果答案經(jīng)常引用過時(shí)文檔知識庫沒有增量更新機(jī)制檢查文檔更新時(shí)間戳引入數(shù)據(jù)版本管理和索引重建任務(wù)排查 RAG 問題有一個(gè)通用順序先確認(rèn)檢索階段有沒有正確召回再確認(rèn) Prompt 組裝有沒有問題最后再懷疑生成模型。很多人第一反應(yīng)是“模型不行”結(jié)果花了很多時(shí)間換模型問題依舊。實(shí)際上RAG 系統(tǒng)的大部分效果問題都出在數(shù)據(jù)和檢索環(huán)節(jié)。9. 最佳實(shí)踐與工程建議RAG 項(xiàng)目做到最后拼的往往不是某個(gè)環(huán)節(jié)的極致優(yōu)化而是工程體系是否完整。下面這幾條最佳實(shí)踐來自常見生產(chǎn)項(xiàng)目的經(jīng)驗(yàn)總結(jié)。9.1 從最小可行 RAG 開始不要在一開始就引入 Agentic RAG、混合檢索、知識圖譜等復(fù)雜組件。第一步應(yīng)該用最快的速度跑通“文檔加載 向量化 檢索 生成”的最小鏈路讓業(yè)務(wù)方看到效果也讓自己對數(shù)據(jù)情況有感知。然后再用評估數(shù)據(jù)驅(qū)動優(yōu)化。否則復(fù)雜系統(tǒng)一旦出問題定位成本會非常高。9.2 把文檔預(yù)處理當(dāng)成第一優(yōu)先級知識庫項(xiàng)目的天花板往往在文檔預(yù)處理階段。建議對文檔格式做一次全面盤點(diǎn)把“哪些文檔適合直接切分”“哪些文檔需要 OCR”“哪些文檔需要專門解析表格”列成明細(xì)表。對經(jīng)常出現(xiàn)的固定版式可以寫專門的解析函數(shù)而不是寄希望于一個(gè)通用解析器搞定所有文檔。9.3 檢索環(huán)節(jié)先保證召回再做精排在檢索鏈路設(shè)計(jì)上可以用兩級思路第一級盡量放寬條件保證相關(guān)文檔能被召回第二級用重排模型或更精細(xì)的過濾邏輯把真正有用的內(nèi)容排到前面。先優(yōu)化 Hit Rate再優(yōu)化 MRR最后才看生成質(zhì)量。這個(gè)順序不能反。9.4 Prompt 要明確約束生成行為生成階段的 Prompt 至少應(yīng)該包含三部分系統(tǒng)指令、檢索上下文、用戶問題。系統(tǒng)指令要明確告訴模型“只能依據(jù)檢索內(nèi)容回答不要使用訓(xùn)練時(shí)學(xué)到的知識補(bǔ)充如果檢索內(nèi)容不足回答不知道”。同時(shí)要求模型在回答時(shí)引用來源編號。這個(gè)設(shè)計(jì)能顯著降低幻覺率也讓溯源成為可能。9.5 記錄完整的運(yùn)行日志線上 RAG 系統(tǒng)建議記錄每次請求的完整鏈路原始問題、改寫后的問題如果有、召回的文檔列表、相似度分?jǐn)?shù)、送入 Prompt 的最終上下文、模型輸出、耗時(shí)。這些日志既是調(diào)試故障的依據(jù)也是后續(xù)搭建自動化評測集的數(shù)據(jù)來源。很多團(tuán)隊(duì)忽略了這一步等到上線后效果變差才發(fā)現(xiàn)沒有任何線索可以回溯。9.6 安全與權(quán)限是最后的底線如果知識庫包含了內(nèi)部資料或用戶隱私數(shù)據(jù)在架構(gòu)設(shè)計(jì)之初就要考慮權(quán)限隔離。不要讓一個(gè)用戶可以檢索到另一個(gè)用戶私有范圍的內(nèi)容。向量數(shù)據(jù)庫層的過濾能力很重要應(yīng)用層也要做身份認(rèn)證和操作審計(jì)。涉及敏感數(shù)據(jù)的項(xiàng)目務(wù)必在測試環(huán)境驗(yàn)證權(quán)限過濾邏輯后再上線并準(zhǔn)備好回滾方案。10. 總結(jié)LLM 工程師的核心能力模型回到這門 Udemy 課程第三部分的整體定位它真正想訓(xùn)練的能力不是“會調(diào)用 API”而是“會設(shè)計(jì)一套完整的 GenAI 系統(tǒng)”。從 RAG 鏈路到 Agent 概念從精度問題到評估指標(biāo)這些知識點(diǎn)串聯(lián)起來指向的是 LLM 工程師的四種核心能力。第一是數(shù)據(jù)工程能力。知道如何從真實(shí)業(yè)務(wù)文檔中提取可用知識如何處理 PDF、Word、HTML 等復(fù)雜格式如何設(shè)計(jì)切分策略。第二是檢索系統(tǒng)設(shè)計(jì)能力。知道如何選 embedding、如何選向量數(shù)據(jù)庫、如何設(shè)計(jì)混合檢索和重排而不是只會調(diào)用一個(gè)現(xiàn)成接口。第三是模型部署與成本控制能力。理解 FP16、BF16、量化的取舍知道在有限的 GPU 資源下如何平衡速度和質(zhì)量。第四是評估能力。能建立測試集能看懂指標(biāo)變化能通過數(shù)據(jù)定位瓶頸。這是區(qū)分“能跑 Demo”和“能上生產(chǎn)”的分水嶺。如果這篇文章讓你有收獲建議馬上選一份實(shí)際文檔按照第二章到第五章的流程搭一個(gè)最小知識庫再做一套 50 條問題的評估集記錄當(dāng)前指標(biāo)。然后試著調(diào)整 chunk_size、切換 embedding 模型、加入重排觀察指標(biāo)和答案質(zhì)量的變化。做 LLM 應(yīng)用開發(fā)最大的誤區(qū)是以為“視頻課刷完就是會了”。真正值回票價(jià)的方式是把課程里的評估方法用到自己的知識庫里把系統(tǒng)從“能跑”改到“好用”。RAG 工程中還有很多細(xì)節(jié)值得深入比如更復(fù)雜的文檔解析、Agent 多輪檢索、基于本體的約束生成、以及更細(xì)粒度的評測體系。每一條都值得再單獨(dú)寫一篇實(shí)踐筆記。