在企業(yè)級(jí)場(chǎng)景中，一個(gè)精準(zhǔn)的知識(shí)庫(kù)問答工具至關(guān)重要。本文深入剖析RAG（檢索增強(qiáng)生成）技術(shù)，從知識(shí)提取、分塊、嵌入、存儲(chǔ)與索引、檢索到回答生成及效果評(píng)估等各個(gè)環(huán)節(jié)，詳細(xì)闡述其核心選型與優(yōu)化思路，助力讀者掌握打造高精準(zhǔn)度知識(shí)庫(kù)助手的完整策略。

像Dify、Coze這樣的低代碼Agent搭建工具，通過將RAG內(nèi)的各類能力進(jìn)行封裝，供用戶在GUI界面上點(diǎn)擊幾下即可進(jìn)行配置。這卻給很多用戶造成了一種假象——好像拖拉拽一下就能配置好一個(gè)知識(shí)庫(kù)問答工具，打造一個(gè)企業(yè)級(jí)的知識(shí)庫(kù)助手。

從實(shí)際落地上來看，上層封裝好的能力有其局限性，低代碼平臺(tái)能夠達(dá)到的問答精準(zhǔn)度上限明顯，可能50、60分都算很不錯(cuò)的了；但這個(gè)分?jǐn)?shù)，對(duì)于企業(yè)級(jí)場(chǎng)景是完全不可用的。你會(huì)允許AI在回答一些公司財(cái)務(wù)問題、行政問題上有一絲一毫的偏差嗎？因此，從50分到90分的過程，才是RAG真正大顯神威之處。

但這個(gè)過程并不是一蹴而就的（即搞定1處就全盤皆贏），從知識(shí)的提取、向量化、分塊、索引、檢索到最終生成，每一步都有各種各樣的優(yōu)化策略可供選擇，不同的策略適應(yīng)不同的場(chǎng)景、數(shù)據(jù)的質(zhì)量和生成的要求等。

可以說，真正的RAG工作是由一系列復(fù)雜、細(xì)致的優(yōu)化策略疊加而來，這不僅要求你隨時(shí)更新自己的知識(shí)體系、掌握最新的優(yōu)化方向進(jìn)程，更需要你了解數(shù)據(jù)形態(tài)和業(yè)務(wù)場(chǎng)景，能夠結(jié)合最終生成訴求來倒推如何去選擇這一系列策略的配合。

之前在一文了解RAG到底是什么？一文中淺介紹了RAG核心技術(shù)。那么，本文將分享下各個(gè)環(huán)節(jié)上的核心選型和優(yōu)化思路，作為一張RAG策略地圖供大家交流學(xué)習(xí)。

01知識(shí)提?。‥xtracting）

知識(shí)的形態(tài)可以分為：結(jié)構(gòu)化（表格）、半結(jié)構(gòu)化（網(wǎng)頁(yè)）、非結(jié)構(gòu)化（PDF、Word等）。和數(shù)據(jù)庫(kù)這樣結(jié)構(gòu)化數(shù)據(jù)不同的是，知識(shí)庫(kù)往往存在大量非結(jié)構(gòu)化數(shù)據(jù)（如視頻、音頻、PDF、網(wǎng)頁(yè)等），這雖然極大地?cái)U(kuò)展了知識(shí)面，但也為準(zhǔn)確的識(shí)別帶來了技術(shù)難題。

像Dify、Langchain、LlamaIndex這些框架都自帶了一些提取器，但同時(shí)也支持豐富的其他loader器的能力集成。以Dify為例，它不僅支持自研的文件抽取方案，同時(shí)也支持了Unstructured的抽取方案。

目前市面上，較為常見的一些外部抽取工具有：

其中，Unstructured是目前較火的一種通用抽取工具，支持常見各種豐富的文檔格式，適合作為一種基礎(chǔ)通用的抽取工具選型。抽取階段的難點(diǎn)其實(shí)在于——PDF和圖片文字提取上。

PDF的難點(diǎn)在于其靈活、豐富的布局本質(zhì)上蘊(yùn)含和嵌套了大量的關(guān)系，例如圖片插在一堆文字中間，它可能是上一段話的一個(gè)示意圖；同時(shí)，PDF這種格式又把標(biāo)題、小標(biāo)題、第一點(diǎn)/第二點(diǎn)等這樣的布局拍平了，難以通過像讀取網(wǎng)頁(yè)里的title、body那樣能夠很輕易的讀取到內(nèi)容結(jié)構(gòu)。

另外，企業(yè)內(nèi)大量還存在的一類文檔為圖片，圖片的精準(zhǔn)識(shí)別尤其在金融行業(yè)應(yīng)用極多。以某基金公司為例，其需要對(duì)新設(shè)管理人提交的資料進(jìn)行審核，資料中包含大量的管理人學(xué)歷、簡(jiǎn)歷等照片；另外，針對(duì)中期監(jiān)管訴求，需要定期收集基金的銀行電子回單去進(jìn)行監(jiān)管審核等。

這些都對(duì)從圖片中提取和識(shí)別文字的精準(zhǔn)度有極高要求，例如上圖中納稅人識(shí)別號(hào)這種比較小的字母，直接使用大模型效果較差，通常我們會(huì)借助OCR（光學(xué)字符識(shí)別OpticalCharacterRecognition）來進(jìn)行實(shí)現(xiàn)。

目前我們自己應(yīng)用過的產(chǎn)品中，閉源工具Textin和開源工具百度飛漿整體效果和性價(jià)比還算可控，大家也可以結(jié)合自己的業(yè)務(wù)去試試，平衡下準(zhǔn)確度和費(fèi)用的關(guān)系。

02知識(shí)分塊（Chunking）

將知識(shí)抽取完成后，我們就擁有了大量的知識(shí)信息，這些信息可能是文字、圖片等，這些知識(shí)以文檔集合整理在一起。但在交給大模型進(jìn)行向量化處理之前，需要進(jìn)行分塊處理。為什么需要分塊，而不是一整個(gè)文檔扔給大模型呢？這是因?yàn)榇竽Ｐ鸵淮瓮掏碌纳舷挛挠邢蕖?/p>

例如Qwen3的上下文長(zhǎng)度為32768tokens，約5萬字左右），這些上下文不只是查詢知識(shí)庫(kù)召回的內(nèi)容塊長(zhǎng)度，還有用戶問題query、提示詞prompt等。另外，即使有段時(shí)間各家的大模型都在努力加長(zhǎng)上下文長(zhǎng)度，但足夠的上下文并不代表著精確性，也有可能會(huì)召回干擾性的內(nèi)容塊，從而更容易造成模型的幻覺。

因此，在有限上下文長(zhǎng)度背景下，分塊技術(shù)相對(duì)能更精準(zhǔn)檢索，從而降低模型幻覺和算力成本。那么，該按照什么邏輯進(jìn)行分塊呢？常見的分塊方式有如下幾種：

當(dāng)然，實(shí)際按照什么邏輯分塊，是需要漸進(jìn)式調(diào)整后得出的。例如，最開始可以先按照最常規(guī)的固定字符數(shù)分塊，通過查看分塊和召回測(cè)試看看效果；如果效果不佳，再調(diào)整字符數(shù)大小或是增加分隔符遞歸分塊，甚至手動(dòng)調(diào)整分塊內(nèi)容等。

另外，分塊本身是為了服務(wù)于檢索，這就避不開要面向索引去進(jìn)行分塊邏輯的處理了。常見的幾種在分塊階段就要為后續(xù)索引進(jìn)行邏輯呼應(yīng)的分塊技巧有這幾種：混合生成父子文本塊：先生成粒度較大的文本塊，再切分成更小的子文本塊，父子文本塊用ID進(jìn)行映射關(guān)聯(lián)。

在檢索階段，先檢索到子文本塊，再通過ID找出其父文本塊，從而將2者一并傳遞給大模型，提升更加豐富和準(zhǔn)確的回答。

生成文本塊元數(shù)據(jù)：分塊后同步為該文本塊生成對(duì)應(yīng)的元數(shù)據(jù)（如標(biāo)題、頁(yè)碼、創(chuàng)建時(shí)間、文件名等），從而在檢索時(shí)，能夠結(jié)合元數(shù)據(jù)作為過濾器來更高效進(jìn)行檢索（該功能目前Difyv1.1.0版本已經(jīng)開始支持做配置了）生成摘要+細(xì)節(jié)文本塊：

類似于父子關(guān)系，摘要?jiǎng)t是由粗及淺，為文檔生成概要性摘要信息，再將摘要和細(xì)節(jié)文本塊關(guān)聯(lián)起來生成遞歸型多層級(jí)索引：類似于父子、摘要+細(xì)節(jié)，遞歸型則是劃分了更多層級(jí)的索引樹，自上而下是逐漸由粗到細(xì)的信息量后續(xù)還會(huì)專門展開索引相關(guān)內(nèi)容，這里先拋磚引玉帶一下，分塊、索引、檢索這3塊技術(shù)應(yīng)當(dāng)整合在一起進(jìn)行整體考慮。

03知識(shí)嵌入（Embedding）

分塊好后，下一步則需要對(duì)這些不同塊的知識(shí)進(jìn)行語(yǔ)義理解和編碼了，這也是整個(gè)RAG過程中，第一次需要使用到大模型的場(chǎng)景。常見的嵌入方式有2種——稀疏嵌入和稠密嵌入，而我們通常討論較多的都是稠密嵌入。簡(jiǎn)而言之，稠密嵌入能夠更好的捕捉語(yǔ)義關(guān)系，而稀疏嵌入在計(jì)算存儲(chǔ)上更高效。

1.稠密嵌入是一種將離散符號(hào)（如詞、句子、用戶、物品等）映射到低維連續(xù)向量空間中的表示方法。在這個(gè)向量中，大部分元素都是非零的實(shí)數(shù)，每個(gè)維度都隱式地表達(dá)某種語(yǔ)義或特征。

2.稀疏嵌入是一種將數(shù)據(jù)映射到高維向量空間中的表示方法，其中大多數(shù)維度的值為0，只有少數(shù)維度有非零值。目前應(yīng)用較多的方式是2者進(jìn)行結(jié)合實(shí)現(xiàn)混合檢索，稠密嵌入負(fù)責(zé)捕捉語(yǔ)義關(guān)系，稀疏嵌入則更多應(yīng)用如BM25（基于詞的重要性對(duì)文檔和查詢進(jìn)行匹配）這樣的方法，既做到了語(yǔ)義上的相關(guān)性，也做到了關(guān)鍵詞匹配的精準(zhǔn)性。

常見的稠密嵌入大模型有OpenAI、Jina、Cohere、Voyage、阿里Qwen這幾家公司的，可以在https://huggingface.co/spaces/mteb/leaderboard去查看全球目前較新的Embedding模型排名。

截至當(dāng)日，多語(yǔ)言embedding模型中排名第一的為gemini-embedding-001，第二三四名竟然都是阿里的Qwen-Embedding系列，這還挺讓人驚喜的。不過排名僅供參考，還是要根據(jù)自己實(shí)際任務(wù)類型去做測(cè)量。

另外，不止生成模型可以做微調(diào)（我們往往說的大模型微調(diào)都是指偏生成響應(yīng)側(cè)側(cè)大模型），其實(shí)嵌入模型也是支持做微調(diào)的，但很少有公司涉及。如果有一些高度專業(yè)化的知識(shí)（如醫(yī)學(xué)、律師）、有特定的格式要求或者文化本地化需求，則最后一步再可以考慮嵌入模型的微調(diào)。

通過微調(diào)，可以生成更優(yōu)質(zhì)的文本嵌入，使語(yǔ)義相似的文本在嵌入空間中的距離更加接近。

04知識(shí)存儲(chǔ)&索引

經(jīng)過embedding后，我們會(huì)生成大量的嵌入數(shù)據(jù)，這些數(shù)據(jù)當(dāng)然不能以我們常見的關(guān)系型/非關(guān)系型數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)了，而是需要特定的向量數(shù)據(jù)庫(kù)來以嵌入形式存儲(chǔ)向量。

存儲(chǔ)的目標(biāo)是為了更好更快的檢索，因此，這一部分我們會(huì)將存儲(chǔ)和索引一起來展開。先來看有哪些向量數(shù)據(jù)庫(kù)？目前比較火的有Milvus、Faiss、Chroma、Weaviate、Qdrant、Pinecone、ElasticSearch，當(dāng)然國(guó)內(nèi)各家大廠（如騰訊）也都建立了向量數(shù)據(jù)庫(kù)的生態(tài)。

如果你想輕量級(jí)測(cè)試和小項(xiàng)目應(yīng)用，可以首選Faiss（Facebook開源的向量數(shù)據(jù)庫(kù)）；如果你是企業(yè)商用，則可以考慮Milvus；如果你之前在用ElasticSearch的搜索/數(shù)據(jù)庫(kù)功能，也可以繼續(xù)考慮使用他們的向量數(shù)據(jù)庫(kù)功能。另外，Dify官方默認(rèn)的向量數(shù)據(jù)庫(kù)則是Weaviate，說明該組件在企業(yè)商用上也是ok的。

當(dāng)我們將向量存入數(shù)據(jù)庫(kù)后，則需要對(duì)應(yīng)建立索引。索引是有效組織數(shù)據(jù)的過程，就像我們?nèi)ヒ患裔t(yī)院后的指南圖一樣，它通過顯著降低對(duì)大型數(shù)據(jù)集的耗時(shí)查詢，在相似度檢索上起到重要作用。常見的索引方式有如下幾類：

這里核心講解3種索引思想：FLAT精確搜索：對(duì)所有數(shù)據(jù)進(jìn)行暴力性遍歷，當(dāng)然只適合小批量數(shù)據(jù)啦IVF_FLAT倒排文件索引+精確搜索：將向量數(shù)據(jù)劃分為若干個(gè)簇，計(jì)算查詢向量與每個(gè)簇中心的距離，找出相似度最高的n個(gè)簇，再在這些簇里面檢索目標(biāo)向量。

就像你要找到「貓」在哪里，先快速找到「動(dòng)物類」的簇在哪里。HNSW基于圖結(jié)構(gòu)的近似最近鄰搜索：目前性能最好的ANN（近似最近鄰搜索）算法之一，它通過構(gòu)建一個(gè)多層導(dǎo)航圖（如頂層、中層、底層），不同層級(jí)的密度逐步變大，讓查詢時(shí)能像坐地鐵一樣“跳躍式”地快速接近目標(biāo)點(diǎn)。目前Dify中Weaviate的默認(rèn)索引方式就是HNSW。

05知識(shí)檢索（Retrieval）

前面準(zhǔn)備了這么多之后，才來到最后的檢索部分，而這也是RAG（Retrieval-AugmentedGeneration）中R（Retrieval）真正起作用的開始。檢索前，常見的處理方式有如下幾種，其中查詢結(jié)構(gòu)轉(zhuǎn)化和查詢翻譯是常用的一些檢索前優(yōu)化方式，查詢路由應(yīng)用相對(duì)沒那么多：1.查詢結(jié)構(gòu)轉(zhuǎn)化

2.查詢翻譯

3.查詢路由

檢索前處理處理說明邏輯路由根據(jù)用戶問題選擇合適的數(shù)據(jù)源或檢索方式語(yǔ)義路由根據(jù)用戶問題選擇合適的提示詞模板通過上述處理，完成檢索后，對(duì)應(yīng)也有一些可以優(yōu)化的策略：

上述提供了一些檢索前后的優(yōu)化思路，其中像查詢結(jié)構(gòu)轉(zhuǎn)化、查詢翻譯、重排基本都是相對(duì)必須的一些優(yōu)化點(diǎn)，查詢路由、壓縮、校正等是否需要可以根據(jù)問答效果再考慮是否選用。

還有一些新興方向，如Self-RAG（讓大模型自我決策是否要搜索、搜什么、搜到的夠不夠、是否要需要搜索），讓大模型自己對(duì)檢索效果進(jìn)行優(yōu)化目前成本和響應(yīng)時(shí)間上還不甚理想，但這未來注定會(huì)是一個(gè)長(zhǎng)期會(huì)進(jìn)化的方向，可能會(huì)通過微調(diào)多個(gè)特定的小模型來進(jìn)行實(shí)現(xiàn)，可以持續(xù)關(guān)注。

06回答生成（Generation）

當(dāng)我們檢索到了相關(guān)知識(shí)分塊后，最后一步就是將用戶查詢、檢索到的知識(shí)庫(kù)文本塊一并喂給大模型，讓大模型利用自身的能力來回答用戶的問題了。到這一步，其實(shí)知識(shí)庫(kù)RAG的工作就結(jié)束了。那么，為了更好的生成結(jié)果，我們還能做的有什么呢？

這里就不過多展開了。

07效果評(píng)估（Evaluation）

評(píng)估某種程度上對(duì)整個(gè)系統(tǒng)的價(jià)值起著決定性的作用，假設(shè)我們要給客戶去交付一款知識(shí)庫(kù)問答產(chǎn)品，到底用什么指標(biāo)去衡量效果就成為了驗(yàn)收的關(guān)鍵卡點(diǎn)。

但事實(shí)上，不同的客戶和場(chǎng)景對(duì)應(yīng)進(jìn)行效果評(píng)估的評(píng)測(cè)集、評(píng)測(cè)模型都是不一樣的。這里先推薦幾種市面上常見的通用評(píng)估指標(biāo)或框架：

1.檢索評(píng)估評(píng)估框架關(guān)注指標(biāo)RAGTRIAD（RAG三角）上下文相關(guān)性忠實(shí)度答案相關(guān)性RAGAS上下文精確率上下文召回率上下文實(shí)體召回率噪聲敏感度DeepEval上下文精確率召回率相關(guān)性等

2.生成評(píng)估評(píng)估框架關(guān)注指標(biāo)RAGAS答案相關(guān)性忠實(shí)度多模態(tài)忠實(shí)度多模態(tài)相關(guān)性DeepEval答案相關(guān)性忠實(shí)度等