穿越火線IP代言人宋雨琦領銜嘉年華！CF學院新人輔導員恭迎校長！
美商務部長稱若中方不給予更多控制權(quán)TikTok將被停用，外交部回應
在企業(yè)級場景中，一個精準的知識庫問答工具至關(guān)重要。本文深入剖析RAG（檢索增強生成）技術(shù)，從知識提取、分塊、嵌入、存儲與索引、檢索到回答生成及效果評估等各個環(huán)節(jié)，詳細闡述其核心選型與優(yōu)化思路，助力讀者掌握打造高精準度知識庫助手的完整策略。
像Dify、Coze這樣的低代碼Agent搭建工具，通過將RAG內(nèi)的各類能力進行封裝，供用戶在GUI界面上點擊幾下即可進行配置。這卻給很多用戶造成了一種假象——好像拖拉拽一下就能配置好一個知識庫問答工具，打造一個企業(yè)級的知識庫助手。
從實際落地上來看，上層封裝好的能力有其局限性，低代碼平臺能夠達到的問答精準度上限明顯，可能50、60分都算很不錯的了；但這個分數(shù)，對于企業(yè)級場景是完全不可用的。你會允許AI在回答一些公司財務問題、行政問題上有一絲一毫的偏差嗎？因此，從50分到90分的過程，才是RAG真正大顯神威之處。
但這個過程并不是一蹴而就的（即搞定1處就全盤皆贏），從知識的提取、向量化、分塊、索引、檢索到最終生成，每一步都有各種各樣的優(yōu)化策略可供選擇，不同的策略適應不同的場景、數(shù)據(jù)的質(zhì)量和生成的要求等。
可以說，真正的RAG工作是由一系列復雜、細致的優(yōu)化策略疊加而來，這不僅要求你隨時更新自己的知識體系、掌握最新的優(yōu)化方向進程，更需要你了解數(shù)據(jù)形態(tài)和業(yè)務場景，能夠結(jié)合最終生成訴求來倒推如何去選擇這一系列策略的配合。
之前在一文了解RAG到底是什么？一文中淺介紹了RAG核心技術(shù)。那么，本文將分享下各個環(huán)節(jié)上的核心選型和優(yōu)化思路，作為一張RAG策略地圖供大家交流學習。
01知識提取（Extracting）
知識的形態(tài)可以分為：結(jié)構(gòu)化（表格）、半結(jié)構(gòu)化（網(wǎng)頁）、非結(jié)構(gòu)化（PDF、Word等）。和數(shù)據(jù)庫這樣結(jié)構(gòu)化數(shù)據(jù)不同的是，知識庫往往存在大量非結(jié)構(gòu)化數(shù)據(jù)（如視頻、音頻、PDF、網(wǎng)頁等），這雖然極大地擴展了知識面，但也為準確的識別帶來了技術(shù)難題。
像Dify、Langchain、LlamaIndex這些框架都自帶了一些提取器，但同時也支持豐富的其他loader器的能力集成。以Dify為例，它不僅支持自研的文件抽取方案，同時也支持了Unstructured的抽取方案。
目前市面上，較為常見的一些外部抽取工具有：
其中，Unstructured是目前較火的一種通用抽取工具，支持常見各種豐富的文檔格式，適合作為一種基礎通用的抽取工具選型。抽取階段的難點其實在于——PDF和圖片文字提取上。
PDF的難點在于其靈活、豐富的布局本質(zhì)上蘊含和嵌套了大量的關(guān)系，例如圖片插在一堆文字中間，它可能是上一段話的一個示意圖；同時，PDF這種格式又把標題、小標題、第一點/第二點等這樣的布局拍平了，難以通過像讀取網(wǎng)頁里的title、body那樣能夠很輕易的讀取到內(nèi)容結(jié)構(gòu)。
另外，企業(yè)內(nèi)大量還存在的一類文檔為圖片，圖片的精準識別尤其在金融行業(yè)應用極多。以某基金公司為例，其需要對新設管理人提交的資料進行審核，資料中包含大量的管理人學歷、簡歷等照片；另外，針對中期監(jiān)管訴求，需要定期收集基金的銀行電子回單去進行監(jiān)管審核等。
這些都對從圖片中提取和識別文字的精準度有極高要求，例如上圖中納稅人識別號這種比較小的字母，直接使用大模型效果較差，通常我們會借助OCR（光學字符識別OpticalCharacterRecognition）來進行實現(xiàn)。
目前我們自己應用過的產(chǎn)品中，閉源工具Textin和開源工具百度飛漿整體效果和性價比還算可控，大家也可以結(jié)合自己的業(yè)務去試試，平衡下準確度和費用的關(guān)系。
02知識分塊（Chunking）
將知識抽取完成后，我們就擁有了大量的知識信息，這些信息可能是文字、圖片等，這些知識以文檔集合整理在一起。但在交給大模型進行向量化處理之前，需要進行分塊處理。為什么需要分塊，而不是一整個文檔扔給大模型呢？這是因為大模型一次吞吐的上下文有限。
例如Qwen3的上下文長度為32768tokens，約5萬字左右），這些上下文不只是查詢知識庫召回的內(nèi)容塊長度，還有用戶問題query、提示詞prompt等。另外，即使有段時間各家的大模型都在努力加長上下文長度，但足夠的上下文并不代表著精確性，也有可能會召回干擾性的內(nèi)容塊，從而更容易造成模型的幻覺。
因此，在有限上下文長度背景下，分塊技術(shù)相對能更精準檢索，從而降低模型幻覺和算力成本。那么，該按照什么邏輯進行分塊呢？常見的分塊方式有如下幾種：
當然，實際按照什么邏輯分塊，是需要漸進式調(diào)整后得出的。例如，最開始可以先按照最常規(guī)的固定字符數(shù)分塊，通過查看分塊和召回測試看看效果；如果效果不佳，再調(diào)整字符數(shù)大小或是增加分隔符遞歸分塊，甚至手動調(diào)整分塊內(nèi)容等。
另外，分塊本身是為了服務于檢索，這就避不開要面向索引去進行分塊邏輯的處理了。常見的幾種在分塊階段就要為后續(xù)索引進行邏輯呼應的分塊技巧有這幾種：混合生成父子文本塊：先生成粒度較大的文本塊，再切分成更小的子文本塊，父子文本塊用ID進行映射關(guān)聯(lián)。
在檢索階段，先檢索到子文本塊，再通過ID找出其父文本塊，從而將2者一并傳遞給大模型，提升更加豐富和準確的回答。
生成文本塊元數(shù)據(jù)：分塊后同步為該文本塊生成對應的元數(shù)據(jù)（如標題、頁碼、創(chuàng)建時間、文件名等），從而在檢索時，能夠結(jié)合元數(shù)據(jù)作為過濾器來更高效進行檢索（該功能目前Difyv1.1.0版本已經(jīng)開始支持做配置了）生成摘要+細節(jié)文本塊：
類似于父子關(guān)系，摘要則是由粗及淺，為文檔生成概要性摘要信息，再將摘要和細節(jié)文本塊關(guān)聯(lián)起來生成遞歸型多層級索引：類似于父子、摘要+細節(jié)，遞歸型則是劃分了更多層級的索引樹，自上而下是逐漸由粗到細的信息量后續(xù)還會專門展開索引相關(guān)內(nèi)容，這里先拋磚引玉帶一下，分塊、索引、檢索這3塊技術(shù)應當整合在一起進行整體考慮。
03知識嵌入（Embedding）
分塊好后，下一步則需要對這些不同塊的知識進行語義理解和編碼了，這也是整個RAG過程中，第一次需要使用到大模型的場景。常見的嵌入方式有2種——稀疏嵌入和稠密嵌入，而我們通常討論較多的都是稠密嵌入。簡而言之，稠密嵌入能夠更好的捕捉語義關(guān)系，而稀疏嵌入在計算存儲上更高效。
1.稠密嵌入是一種將離散符號（如詞、句子、用戶、物品等）映射到低維連續(xù)向量空間中的表示方法。在這個向量中，大部分元素都是非零的實數(shù)，每個維度都隱式地表達某種語義或特征。
2.稀疏嵌入是一種將數(shù)據(jù)映射到高維向量空間中的表示方法，其中大多數(shù)維度的值為0，只有少數(shù)維度有非零值。目前應用較多的方式是2者進行結(jié)合實現(xiàn)混合檢索，稠密嵌入負責捕捉語義關(guān)系，稀疏嵌入則更多應用如BM25（基于詞的重要性對文檔和查詢進行匹配）這樣的方法，既做到了語義上的相關(guān)性，也做到了關(guān)鍵詞匹配的精準性。
常見的稠密嵌入大模型有OpenAI、Jina、Cohere、Voyage、阿里Qwen這幾家公司的，可以在https://huggingface.co/spaces/mteb/leaderboard去查看全球目前較新的Embedding模型排名。
截至當日，多語言embedding模型中排名第一的為gemini-embedding-001，第二三四名竟然都是阿里的Qwen-Embedding系列，這還挺讓人驚喜的。不過排名僅供參考，還是要根據(jù)自己實際任務類型去做測量。
另外，不止生成模型可以做微調(diào)（我們往往說的大模型微調(diào)都是指偏生成響應側(cè)側(cè)大模型），其實嵌入模型也是支持做微調(diào)的，但很少有公司涉及。如果有一些高度專業(yè)化的知識（如醫(yī)學、律師）、有特定的格式要求或者文化本地化需求，則最后一步再可以考慮嵌入模型的微調(diào)。
通過微調(diào)，可以生成更優(yōu)質(zhì)的文本嵌入，使語義相似的文本在嵌入空間中的距離更加接近。
04知識存儲&索引
經(jīng)過embedding后，我們會生成大量的嵌入數(shù)據(jù)，這些數(shù)據(jù)當然不能以我們常見的關(guān)系型/非關(guān)系型數(shù)據(jù)庫進行存儲了，而是需要特定的向量數(shù)據(jù)庫來以嵌入形式存儲向量。
存儲的目標是為了更好更快的檢索，因此，這一部分我們會將存儲和索引一起來展開。先來看有哪些向量數(shù)據(jù)庫？目前比較火的有Milvus、Faiss、Chroma、Weaviate、Qdrant、Pinecone、ElasticSearch，當然國內(nèi)各家大廠（如騰訊）也都建立了向量數(shù)據(jù)庫的生態(tài)。
如果你想輕量級測試和小項目應用，可以首選Faiss（Facebook開源的向量數(shù)據(jù)庫）；如果你是企業(yè)商用，則可以考慮Milvus；如果你之前在用ElasticSearch的搜索/數(shù)據(jù)庫功能，也可以繼續(xù)考慮使用他們的向量數(shù)據(jù)庫功能。另外，Dify官方默認的向量數(shù)據(jù)庫則是Weaviate，說明該組件在企業(yè)商用上也是ok的。
當我們將向量存入數(shù)據(jù)庫后，則需要對應建立索引。索引是有效組織數(shù)據(jù)的過程，就像我們?nèi)ヒ患裔t(yī)院后的指南圖一樣，它通過顯著降低對大型數(shù)據(jù)集的耗時查詢，在相似度檢索上起到重要作用。常見的索引方式有如下幾類：
這里核心講解3種索引思想：FLAT精確搜索：對所有數(shù)據(jù)進行暴力性遍歷，當然只適合小批量數(shù)據(jù)啦IVF_FLAT倒排文件索引+精確搜索：將向量數(shù)據(jù)劃分為若干個簇，計算查詢向量與每個簇中心的距離，找出相似度最高的n個簇，再在這些簇里面檢索目標向量。
就像你要找到「貓」在哪里，先快速找到「動物類」的簇在哪里。HNSW基于圖結(jié)構(gòu)的近似最近鄰搜索：目前性能最好的ANN（近似最近鄰搜索）算法之一，它通過構(gòu)建一個多層導航圖（如頂層、中層、底層），不同層級的密度逐步變大，讓查詢時能像坐地鐵一樣“跳躍式”地快速接近目標點。目前Dify中Weaviate的默認索引方式就是HNSW。
05知識檢索（Retrieval）
前面準備了這么多之后，才來到最后的檢索部分，而這也是RAG（Retrieval-AugmentedGeneration）中R（Retrieval）真正起作用的開始。檢索前，常見的處理方式有如下幾種，其中查詢結(jié)構(gòu)轉(zhuǎn)化和查詢翻譯是常用的一些檢索前優(yōu)化方式，查詢路由應用相對沒那么多：1.查詢結(jié)構(gòu)轉(zhuǎn)化
2.查詢翻譯
3.查詢路由
檢索前處理處理說明邏輯路由根據(jù)用戶問題選擇合適的數(shù)據(jù)源或檢索方式語義路由根據(jù)用戶問題選擇合適的提示詞模板通過上述處理，完成檢索后，對應也有一些可以優(yōu)化的策略：
上述提供了一些檢索前后的優(yōu)化思路，其中像查詢結(jié)構(gòu)轉(zhuǎn)化、查詢翻譯、重排基本都是相對必須的一些優(yōu)化點，查詢路由、壓縮、校正等是否需要可以根據(jù)問答效果再考慮是否選用。
還有一些新興方向，如Self-RAG（讓大模型自我決策是否要搜索、搜什么、搜到的夠不夠、是否要需要搜索），讓大模型自己對檢索效果進行優(yōu)化目前成本和響應時間上還不甚理想，但這未來注定會是一個長期會進化的方向，可能會通過微調(diào)多個特定的小模型來進行實現(xiàn)，可以持續(xù)關(guān)注。
06回答生成（Generation）
當我們檢索到了相關(guān)知識分塊后，最后一步就是將用戶查詢、檢索到的知識庫文本塊一并喂給大模型，讓大模型利用自身的能力來回答用戶的問題了。到這一步，其實知識庫RAG的工作就結(jié)束了。那么，為了更好的生成結(jié)果，我們還能做的有什么呢？
這里就不過多展開了。
07效果評估（Evaluation）
評估某種程度上對整個系統(tǒng)的價值起著決定性的作用，假設我們要給客戶去交付一款知識庫問答產(chǎn)品，到底用什么指標去衡量效果就成為了驗收的關(guān)鍵卡點。
但事實上，不同的客戶和場景對應進行效果評估的評測集、評測模型都是不一樣的。這里先推薦幾種市面上常見的通用評估指標或框架：
1.檢索評估評估框架關(guān)注指標RAGTRIAD（RAG三角）上下文相關(guān)性忠實度答案相關(guān)性RAGAS上下文精確率上下文召回率上下文實體召回率噪聲敏感度DeepEval上下文精確率召回率相關(guān)性等
2.生成評估評估框架關(guān)注指標RAGAS答案相關(guān)性忠實度多模態(tài)忠實度多模態(tài)相關(guān)性DeepEval答案相關(guān)性忠實度等
