從 RAG 到 RAGless這個(gè)詞最近在檢索增強(qiáng)生成這個(gè)圈子里逐漸熱了起來(lái)。我在瀏覽 Hacker News 時(shí)看到一個(gè)很有意思的項(xiàng)目標(biāo)題Show HN: RAGless – similar to RAG, but $0 LLM API costs at runtime。第一反應(yīng)是懷疑第二反應(yīng)是覺(jué)得這個(gè)視角很值得展開(kāi)聊聊。長(zhǎng)期做知識(shí)庫(kù)問(wèn)答、客服機(jī)器人、內(nèi)部文檔檢索的同學(xué)應(yīng)該都有體會(huì)RAG 本身并不難搭難的是 runtime 階段的 LLM API 費(fèi)用像流水一樣出去尤其當(dāng)知識(shí)庫(kù)復(fù)雜、用戶問(wèn)題多、單次上下文又很長(zhǎng)的時(shí)候賬單會(huì)迅速變得不可控。RAGless 這個(gè)名字想表達(dá)的并不是“不需要大模型”也不是“比 RAG 更聰明”而是把成本發(fā)生的位置做了一次關(guān)鍵遷移盡量把開(kāi)銷留在離線和索引階段讓 runtime 階段不再依賴外部 LLM API。這篇文章我會(huì)圍繞 RAGless 這個(gè)思路做一次系統(tǒng)的拆解。我們會(huì)先理清 RAG 到底貴在哪再討論 RAGless 的實(shí)現(xiàn)原理與適用邊界最后帶大家用本地向量檢索的方式落地一個(gè)最小可運(yùn)行 Demo。通過(guò)這個(gè) Demo哪怕你不調(diào)用任何商用 LLM API也可以讓用戶通過(guò)自然語(yǔ)言查到自己知識(shí)庫(kù)里的準(zhǔn)確答案。適合正在做知識(shí)庫(kù)問(wèn)答、剛接觸 RAG、或者被 LLM API 賬單困擾的開(kāi)發(fā)者閱讀。1. RAG 與 RAGless先搞清楚兩個(gè)概念1.1 傳統(tǒng) RAG 的工作流程RAG 的全稱是 Retrieval-Augmented Generation也就是檢索增強(qiáng)生成。它的核心目的是讓大語(yǔ)言模型在回答問(wèn)題時(shí)能夠參考外部知識(shí)庫(kù)中檢索出來(lái)的內(nèi)容而不是只依賴模型自身的參數(shù)記憶。一個(gè)標(biāo)準(zhǔn) RAG 流程通常包含四個(gè)階段。第一階段是文檔預(yù)處理。我們需要把 PDF、Word、Markdown、數(shù)據(jù)庫(kù)表等不同來(lái)源的文檔讀出來(lái)做清洗、段落切分去掉頁(yè)眉頁(yè)腳、表格噪聲等無(wú)關(guān)內(nèi)容。第二階段是索引構(gòu)建。將切分好的文本塊通過(guò) Embedding 模型轉(zhuǎn)化為向量然后寫(xiě)入向量數(shù)據(jù)庫(kù)例如 Milvus、Qdrant、Elasticsearch、pgvector或者內(nèi)存中的 FAISS 索引。第三階段是查詢檢索。當(dāng)用戶輸入問(wèn)題時(shí)我們需要先把問(wèn)題也轉(zhuǎn)成向量然后去向量庫(kù)或索引中做相似度搜索召回與問(wèn)題最相關(guān)的一批文檔片段。第四階段是增強(qiáng)生成。把召回的片段、用戶問(wèn)題、系統(tǒng)提示詞一起拼進(jìn) Prompt送給 LLM由 LLM 總結(jié)生成一段自然語(yǔ)言回答。RAG 之所以受歡迎是因?yàn)樗戎苯邮褂么竽Ｐ投嗔艘粋€(gè)“外部記憶”通道回答更有依據(jù)相對(duì)不容易胡編亂造知識(shí)也能及時(shí)更新。所以無(wú)論是個(gè)人知識(shí)庫(kù)、企業(yè)客服機(jī)器人還是輔助研發(fā)文檔搜索大家都會(huì)優(yōu)先考慮這套方案。1.2 RAG 的成本到底花在了哪里很多教程里只會(huì)告訴你 RAG 能夠提高回答準(zhǔn)確性卻很少明確告訴你傳統(tǒng) RAG 的 runtime 階段也就是用戶每發(fā)起一次提問(wèn)時(shí)都包含一次甚至多次 LLM API 調(diào)用。舉個(gè)例子用戶問(wèn)了一句“我們公司請(qǐng)假流程是什么”系統(tǒng)先要調(diào)用向量檢索拿到 5 個(gè)片段然后把問(wèn)題、片段、系統(tǒng)提示詞拼成一個(gè)很長(zhǎng)的 Prompt發(fā)給 LLM。LLM 返回結(jié)果以后還需要把這 5 個(gè)片段一起計(jì)入輸入 token。假設(shè)平均每個(gè)片段 300 token5 個(gè)片段就是 1500 token再加上指令、歷史記錄單次請(qǐng)求的輸入可能接近 2200 token輸出可能又是幾百 token。這個(gè)成本并不僅僅體現(xiàn)在單價(jià)上它還會(huì)被以下因素放大。第一用戶量和提問(wèn)次數(shù)會(huì)持續(xù)增加成本線性甚至非線性增長(zhǎng)。第二Context 越長(zhǎng)輸入 token 越多成本越高。第三一旦引入 Agent、ReAct、多輪規(guī)劃等機(jī)制一次用戶提問(wèn)可能觸發(fā)好幾次 LLM API 調(diào)用成本成倍上漲。第四LLM API 的調(diào)用還有延遲、頻控、網(wǎng)絡(luò)抖動(dòng)的問(wèn)題高并發(fā)下體驗(yàn)不穩(wěn)定。所以當(dāng)你看到 RAGless 標(biāo)題中$0 LLM API costs at runtime這幾個(gè)字時(shí)應(yīng)該已經(jīng)明白它是在針對(duì)以上這些痛點(diǎn)做文章不否認(rèn)離線構(gòu)建有成本不否認(rèn)場(chǎng)景有限制但希望在運(yùn)行時(shí)把外部 API 調(diào)用請(qǐng)求降為 0。1.3 RAGless 的核心思想把“生成答案”改成“定位答案”如果你只是想從知識(shí)庫(kù)里找到一個(gè)明確的事實(shí)比如“項(xiàng)目上線時(shí)間”“服務(wù)器地址”“報(bào)銷標(biāo)準(zhǔn)”其實(shí)并不需要讓大模型現(xiàn)場(chǎng)寫(xiě)一篇小作文。你真正需要的是把問(wèn)題定位到知識(shí)庫(kù)中最相關(guān)的某一段或某幾段內(nèi)容然后原樣呈現(xiàn)給用戶。這就是 RAGless 的核心思想查詢時(shí)不調(diào)用 LLM 來(lái)重新表達(dá)和生成而是直接通過(guò)檢索系統(tǒng)返回最匹配的原文片段讓用戶在原文中找到答案。用一句話說(shuō)RAG 是“檢索 閱讀 組織 生成答案”RAGless 是“檢索 定位 返回原文片段”。這是不是完全沒(méi)有 LLM 參與呢也不一定。在離線階段完全可以借助 LLM 對(duì)文檔做摘要、提煉關(guān)鍵詞、生成別名、構(gòu)建知識(shí)圖譜等。只不過(guò)這些成本一次性發(fā)生不會(huì)因?yàn)槟忝刻於鄦?wèn)了 1 萬(wàn)次而持續(xù)增加。這就把“查詢成本”替換成“索引成本”把“按次付費(fèi)”變成了“固定投入”。1.4 RAGless 的適用與不適用場(chǎng)景RAGless 并不適合所有場(chǎng)景但它適合很大一部分真實(shí)業(yè)務(wù)。先說(shuō)適合的場(chǎng)景。企業(yè)制度文檔查詢“年假怎么休”“報(bào)銷限額是多少”“客戶歸屬如何判定”答案本來(lái)就在制度原文中。產(chǎn)品幫助文檔 / FAQ用戶問(wèn)“如何重置密碼”直接把操作步驟對(duì)應(yīng)的原文片段返回效果非常直接。法律、醫(yī)療、金融等強(qiáng)合規(guī)領(lǐng)域只返回原文不額外生成衍生內(nèi)容反而更可控。那不適合的場(chǎng)景有哪些呢需要跨文章、跨片段進(jìn)行多跳推理的問(wèn)題比如“A 部門(mén)規(guī)定和 B 部門(mén)規(guī)定沖突時(shí)怎么辦”。需要把多個(gè)信息匯總后改寫(xiě)為一段綜述的問(wèn)題比如“分析一下近三個(gè)季度銷售額變化的原因”。用戶缺乏閱讀耐心或者非技術(shù)人員需要口語(yǔ)化答案的場(chǎng)景。理解這一點(diǎn)非常重要因?yàn)樗鼪Q定了這個(gè)思路能走多遠(yuǎn)也避免我們看到一個(gè)新概念后就盲目替換自己已經(jīng)做好的整套系統(tǒng)。2. 為什么運(yùn)行時(shí) LLM API 成本值得被單獨(dú)討論2.1 一次問(wèn)答的隱性成本如何計(jì)算很多剛開(kāi)始做 RAG 的開(kāi)發(fā)者在自測(cè)階段不會(huì)覺(jué)得貴因?yàn)橐惶炜赡苤粶y(cè)試幾十次?？梢坏┫到y(tǒng)上線或者做成內(nèi)部工具服務(wù)上百個(gè)員工問(wèn)題量會(huì)迅速上升。假設(shè)我們做一個(gè)非常粗略的計(jì)算模型用戶每天提問(wèn) 10000 次每次請(qǐng)求上下文包含若干文檔片段折合輸入約 2000 token輸出長(zhǎng)度約 300 token那么單日 token 消耗約為 2000 萬(wàn)輸入 300 萬(wàn)輸出。把這個(gè)量換算成收費(fèi) API 的計(jì)費(fèi)不同模型價(jià)格差異很大你只需要把上面的 token 數(shù)乘以每千 token 單價(jià)就能算出可觀的月賬單。更麻煩的是多輪對(duì)話。為了保持上下文一致許多 RAG 應(yīng)用會(huì)把用戶歷史聊天記錄也一并發(fā)送到 API這讓單次輸入的 token 數(shù)越來(lái)越膨脹。加上檢索到的片段本身通常沒(méi)有做太多剪枝用戶問(wèn)第三輪、第四輪時(shí)Prompt 已經(jīng)變得又長(zhǎng)又臃腫而大部分歷史內(nèi)容與當(dāng)前問(wèn)題沒(méi)有直接關(guān)系屬于無(wú)效支出。相對(duì)而言如果把運(yùn)行時(shí)方案換成“向量檢索 原文片段返回”成本主要落在本地的 CPU/GPU 計(jì)算與向量相似度計(jì)算上。沒(méi)有 API 調(diào)用自然也就沒(méi)有 token 賬單、沒(méi)有并發(fā)超限、沒(méi)有外網(wǎng)鏈路延遲。2.2 除了錢(qián)還有延遲、穩(wěn)定性與隱私“runtime 零 LLM API 成本”帶來(lái)的另一個(gè)好處是延遲可控。調(diào)用外部大模型 API 通常需要幾百毫秒到幾秒不等受網(wǎng)絡(luò)狀況和模型負(fù)載影響。向量檢索則更快在小規(guī)模數(shù)據(jù)集中一次本地向量檢索可能只需要幾十毫秒。對(duì)于知識(shí)庫(kù)條目比較固定、答案要求即時(shí)返回的場(chǎng)景這種體驗(yàn)差異很重要。穩(wěn)定性也一樣重要。商用 API 有頻控、限流、服務(wù)故障、模型下線的風(fēng)險(xiǎn)。你在本地做向量檢索只要索引沒(méi)壞、服務(wù)能啟動(dòng)查詢性能就是穩(wěn)定可預(yù)期的。還有一個(gè)不可忽視的點(diǎn)是數(shù)據(jù)安全。很多企業(yè)知識(shí)庫(kù)內(nèi)容很敏感不適合發(fā)給外部 API。RAGless 如果只靠本地向量化與本地檢索那么用戶問(wèn)題與文檔內(nèi)容都可以不出內(nèi)網(wǎng)。它在隱私合規(guī)上顯然更加友好。2.3 從 RAG、Agentic RAG 到 RAGless 的路線變化如果觀察 RAG 的發(fā)展趨勢(shì)你會(huì)發(fā)現(xiàn)今年的熱點(diǎn)其實(shí)有兩條路線。一條是 Agentic RAG也就是讓 Agent 自主規(guī)劃?rùn)z索策略決定先查哪個(gè)庫(kù)、拆解成幾個(gè)子問(wèn)題、調(diào)用哪類工具然后多輪迭代。這條路能處理更復(fù)雜的問(wèn)題但 token 消耗和延遲也成倍增加。另一條就是 RAGless 這種“降本路線”。它把能離線做成的事情盡量離線完成把 runtime 階段需要實(shí)時(shí)調(diào)用的智能能力降到最低。它不追求用一次昂貴的大模型調(diào)用解決所有問(wèn)題而是承認(rèn)大量用戶真實(shí)問(wèn)題其實(shí)都是“查找類問(wèn)題”。所以RAGless 并不是 Agentic RAG 的反義詞也不是要否定大模型生成的潛力。它是一種適合固定知識(shí)域、高頻查詢場(chǎng)景的工程權(quán)衡方案。3. RAGless 的核心原理拆解3.1 離線階段把知識(shí)庫(kù)處理成“可檢索的答案片段”既然 runtime 不再有大模型幫你總結(jié)歸納那么離線階段就更需要精心設(shè)計(jì)文檔結(jié)構(gòu)。核心目標(biāo)之一是讓知識(shí)庫(kù)中的文本切塊盡可能獨(dú)立成“一個(gè)可作答的片段”。舉一個(gè)反例如果文檔以連續(xù)三段長(zhǎng)文存儲(chǔ)檢索模塊命中之后返回的是整整三千字用戶根本看不清答案。切分策略要考慮句子邊界、段落邊界、標(biāo)題層級(jí)還要盡可能避免把語(yǔ)義相關(guān)的上下文切開(kāi)。所以在 RAGless 中文檔切分不是可有可無(wú)的預(yù)處理而是決定檢索質(zhì)量的基礎(chǔ)設(shè)施。更進(jìn)階的做法是在切分前用規(guī)則或模型給文檔生成一個(gè)結(jié)構(gòu)化摘要或者把每個(gè)片段附上來(lái)源、標(biāo)題、上下文檔信息。這樣檢索返回的不只是“一段文字”而是一個(gè)帶來(lái)源的答案卡片。3.2 索引階段本地 Embedding 與多維索引如果希望用戶用自然語(yǔ)言檢索那還是需要把文本轉(zhuǎn)換成向量。向量模型可以完全運(yùn)行在本地或內(nèi)網(wǎng)例如使用開(kāi)源的 Sentence-BERT 系列模型。這一步不需要調(diào)用外部 LLM API。在數(shù)據(jù)規(guī)?？煽氐那闆r下我們甚至可以直接把向量存入內(nèi)存使用 NumPy 做矩陣內(nèi)積。當(dāng)數(shù)據(jù)量達(dá)到百萬(wàn)級(jí)時(shí)再考慮 FAISS、Milvus、Qdrant 等專業(yè)索引。除了向量索引還可以同時(shí)構(gòu)建倒排索引用于關(guān)鍵詞檢索這樣后續(xù)可以做向量與關(guān)鍵詞的混合排序彌補(bǔ)向量模型對(duì)專業(yè)名詞、縮略語(yǔ)可能不敏感的問(wèn)題。3.3 查詢階段雙路召回取代 LLM 生成用戶輸入問(wèn)題之后系統(tǒng)會(huì)把問(wèn)題向量化然后與索引中的文檔向量做相似度比對(duì)得到 top-k 候選。這一步的關(guān)鍵在于 Query 的理解質(zhì)量如果只做向量檢索可能出現(xiàn)“語(yǔ)義相近但關(guān)鍵詞不匹配”的召回缺失。所以很多工程實(shí)現(xiàn)會(huì)采用雙路召回一路做 Dense Vector Search也就是向量檢索另一路做稀疏檢索如 BM25。最后在重排階段合并兩路結(jié)果。由于不需要把候選片段發(fā)給大模型讓模型閱讀后重新組織語(yǔ)言整個(gè)查詢鏈路就是“向量化 Query 相似度計(jì)算 排序 結(jié)果格式化”。哪怕每天 10 萬(wàn)次查詢主要開(kāi)銷也只是計(jì)算資源而不是 token。3.4 常見(jiàn)誤區(qū)RAGless 不是“不用 LLM”理解 RAGless 的時(shí)候很容易走極端這是需要特別注意的。RAGless 不是反對(duì) LLM也不是說(shuō)所有 LLM 都完全沒(méi)有參與。它真正反對(duì)的是“用戶在運(yùn)行時(shí)每次提問(wèn)都必須調(diào)用一次 LLM API”這種按次付費(fèi)的模式。在離線階段LLM 依然很有價(jià)值。比如對(duì)文檔做糾錯(cuò)和改寫(xiě)讓文本更適合檢索自動(dòng)提取文檔關(guān)鍵詞和同義詞增強(qiáng)召回將長(zhǎng)文檔拆成結(jié)構(gòu)化問(wèn)答對(duì)識(shí)別文檔中的實(shí)體、時(shí)間、人物關(guān)系補(bǔ)充到索引中為文檔片段生成摘要作為檢索結(jié)果的卡標(biāo)題。這些任務(wù)可以批量執(zhí)行也可以定時(shí)增量執(zhí)行成本是可控的。一次預(yù)計(jì)算多次使用這是把“智能能力”用在刀刃上的做法。4. 環(huán)境準(zhǔn)備與原型方案設(shè)計(jì)4.1 方案整體架構(gòu)在實(shí)際動(dòng)手寫(xiě)代碼前我們先明確一下這個(gè)最小 Demo 的整體鏈路。它由下面幾部分組成文檔源存放少量測(cè)試文檔用來(lái)模擬企業(yè)知識(shí)庫(kù)。文本加載器讀取 JSON 格式的文檔內(nèi)容并切分為多個(gè)片段。本地向量化模型將片段文本映射成固定長(zhǎng)度的向量。向量索引模塊將向量保存到一個(gè)矩陣中并提供相似度查詢。檢索查詢?nèi)肟诎延脩糇匀徽Z(yǔ)言問(wèn)題轉(zhuǎn)化為向量返回最相關(guān)的幾個(gè)片段。整體查詢流程如下用戶輸入問(wèn)題系統(tǒng)調(diào)用同一個(gè)本地模型生成問(wèn)題向量系統(tǒng)計(jì)算問(wèn)題向量與所有文檔片段的向量余弦相似度系統(tǒng)按相似度從高到低排序返回前 k 個(gè)片段附帶標(biāo)題與文檔編號(hào)用戶直接閱讀原文片段不需要再經(jīng)過(guò)大模型生成。你會(huì)發(fā)現(xiàn)整個(gè)流程沒(méi)有任何外部 API 調(diào)用所以從理論上說(shuō)運(yùn)行時(shí)不會(huì)產(chǎn)生 LLM API 費(fèi)用。這個(gè) Demo 規(guī)模很小不追求做完整搜索引擎但足以展示 RAGless 與標(biāo)準(zhǔn) RAG 在運(yùn)行機(jī)制上的差異。4.2 技術(shù)選型與版本說(shuō)明我選擇 Python 3.9 以上版本作為示例環(huán)境主要依賴如下sentence-transformers用于加載本地 Embedding 模型numpy用于存儲(chǔ)向量矩陣并做相似度計(jì)算json和rePython 標(biāo)準(zhǔn)庫(kù)用于數(shù)據(jù)讀取和文本切分。版本需要根據(jù)你的項(xiàng)目實(shí)際情況調(diào)整本文示例以常見(jiàn)環(huán)境為例重點(diǎn)演示配置思路。如果你之前沒(méi)有安裝sentence-transformers可以執(zhí)行下面的命令安裝pip install sentence-transformers numpy這里要提醒一下sentence-transformers第一次加載模型時(shí)會(huì)從模型倉(cāng)庫(kù)下載模型文件因此需要網(wǎng)絡(luò)能夠正常訪問(wèn)模型下載地址。如果網(wǎng)絡(luò)環(huán)境不允許可以提前下載好模型文件并加載本地路徑或者更換成你內(nèi)網(wǎng)可訪問(wèn)的模型源。具體模型名稱也需要根據(jù)實(shí)際環(huán)境調(diào)整。4.3 示例項(xiàng)目目錄為了后文講解清晰我們先把項(xiàng)目結(jié)構(gòu)定義好ragless-demo/ ├── data/ │ └── docs.json ├── src/ │ ├── loader.py │ ├── embedder.py │ ├── search.py │ └── app.py └── requirements.txtdocs.json存放原始業(yè)務(wù)文檔一條記錄代表一篇文檔。src/loader.py負(fù)責(zé)加載文檔并切分片段。src/embedder.py負(fù)責(zé)本地向量化。src/search.py負(fù)責(zé)向量索引和 Top-K 檢索。src/app.py提供命令行問(wèn)答入口。5. 從零實(shí)現(xiàn)一個(gè) RAGless 最小可運(yùn)行 Demo5.1 準(zhǔn)備測(cè)試文檔我們先創(chuàng)建數(shù)據(jù)文件data/docs.json內(nèi)容模擬一個(gè)企業(yè)知識(shí)庫(kù)中的幾條規(guī)范說(shuō)明。這里我加入了一些與 RAG、文檔管理相關(guān)的內(nèi)容方便觀察檢索結(jié)果是否合理。{ documents: [ { id: doc-001, title: RAG 的基本流程, content: RAG 是檢索增強(qiáng)生成的縮寫(xiě)通常由文檔預(yù)處理、向量索引構(gòu)建、用戶問(wèn)題檢索和大模型生成四個(gè)階段組成。它能夠結(jié)合外部知識(shí)庫(kù)中的文檔片段幫助大模型回答更準(zhǔn)確的問(wèn)題。 }, { id: doc-002, title: RAG 的運(yùn)行時(shí)成本, content: 在傳統(tǒng) RAG 中用戶每次提問(wèn)都會(huì)調(diào)用大模型 API。輸入 token 包括檢索到的文檔片段、問(wèn)答歷史與系統(tǒng)提示詞因此當(dāng)用戶量和上下文長(zhǎng)度增長(zhǎng)時(shí)運(yùn)行時(shí)會(huì)話成本會(huì)顯著增加。 }, { id: doc-003, title: RAGless 的設(shè)計(jì)思路, content: RAGless 是一種讓運(yùn)行時(shí)盡量不調(diào)用大模型 API 的檢索方案。它通過(guò)高質(zhì)量的文檔切分和本地向量檢索直接向用戶返回原文片段將成本從按次付費(fèi)的生成請(qǐng)求轉(zhuǎn)化為固定的離線索引成本。 }, { id: doc-004, title: 向量檢索與混合檢索, content: 向量檢索能夠理解語(yǔ)義找到與問(wèn)題意思相近的片段?；旌蠙z索則同時(shí)使用關(guān)鍵詞檢索和向量檢索再通過(guò)重排融合結(jié)果適合處理專業(yè)名詞多、縮略語(yǔ)多的場(chǎng)景。 }, { id: doc-005, title: 企業(yè)知識(shí)庫(kù)的常見(jiàn)問(wèn)答場(chǎng)景, content: 員工關(guān)心的問(wèn)題往往比較明確例如請(qǐng)假流程、報(bào)銷標(biāo)準(zhǔn)、服務(wù)器地址、項(xiàng)目上線時(shí)間等。這類問(wèn)題的答案已經(jīng)存在于制度文檔中通過(guò)檢索返回原文即可解答。 } ] }在真實(shí)項(xiàng)目里這個(gè)文件可能會(huì)替換為數(shù)據(jù)庫(kù)中的文檔表或者對(duì)象存儲(chǔ)中保存的 Markdown / PDF 數(shù)據(jù)。這里的核心是給后續(xù)處理提供“標(biāo)題 正文”結(jié)構(gòu)。5.2 文檔切分模塊下面編寫(xiě)src/loader.py。它的職責(zé)是讀取上面的 JSON 文件然后對(duì)長(zhǎng)文本做簡(jiǎn)單切分。實(shí)際業(yè)務(wù)文檔往往很長(zhǎng)不能把整篇文檔作為一個(gè)片段返回所以我們實(shí)現(xiàn)了一個(gè)按句子邊界切分的小函數(shù)。# 文件路徑ragless-demo/src/loader.py import json import re def load_documents(data_path): 加載 JSON 文檔返回文檔列表。 with open(data_path, r, encodingutf-8) as f: data json.load(f) return data[documents] def split_text(text, max_len120, overlap20): 按句子邊界切分文本。 如果單個(gè)句子太長(zhǎng)再按 max_len 長(zhǎng)度截?cái)唷?使用 overlap 保留相鄰片段之間的上下文。 # 按中文句號(hào)、問(wèn)號(hào)、感嘆號(hào)、分號(hào)、換行符分割句子 sentences re.split(r(?[。\n]), text) sentences [s.strip() for s in sentences if s.strip()] chunks [] current for sent in sentences: # 如果加入當(dāng)前句后會(huì)超過(guò) max_len先保存當(dāng)前片段 if len(current) len(sent) max_len and current: chunks.append(current) # 截?cái)鄷r(shí)保留末尾 overlap 個(gè)字符避免上下文斷裂 current current[-overlap:] if overlap 0 else current sent if current: chunks.append(current) # 如果某個(gè)句子本身過(guò)長(zhǎng)按 max_len 硬切 final_chunks [] for chunk in chunks: while len(chunk) max_len: final_chunks.append(chunk[:max_len]) chunk chunk[max_len - overlap:] if overlap 0 else chunk[max_len:] if chunk: final_chunks.append(chunk) return final_chunks def build_chunks(documents): 將文檔列表轉(zhuǎn)換為帶元信息的片段列表。 chunk_list [] for doc in documents: text doc[content] title doc[title] doc_id doc[id] parts split_text(text) for idx, part in enumerate(parts): chunk_list.append({ doc_id: doc_id, title: title, chunk_index: idx, text: part, }) return chunk_list這個(gè)模塊將文檔正文按句子粒度拆分。為什么要這么做呢因?yàn)槟阕罱K返回給用戶的是一段可直接閱讀的內(nèi)容而不是把整篇文檔都塞給用戶。切分后的每個(gè)片段需要盡量保持語(yǔ)義完整片段之間增加少量重疊是為了避免檢索時(shí)正好落在兩個(gè)片段的邊界上。5.3 本地 Embedding 與向量索引接下來(lái)編寫(xiě)src/embedder.py與src/search.py。這一步是整個(gè) RAGless 方案的“智能基礎(chǔ)設(shè)施”。我們需要使用一個(gè)本地向量化模型將所有片段轉(zhuǎn)換成向量然后存進(jìn)一個(gè)矩陣。# 文件路徑ragless-demo/src/embedder.py from sentence_transformers import SentenceTransformer class LocalEmbedder: 本地向量化器不依賴任何 LLM API。 def __init__(self, model_nameparaphrase-multilingual-MiniLM-L12-v2): # 選擇一個(gè)多語(yǔ)言或中文模型按實(shí)際環(huán)境調(diào)整 self.model SentenceTransformer(model_name) def embed_texts(self, texts): 將多個(gè)文本編碼為向量并做 L2 歸一化。 vectors self.model.encode( texts, normalize_embeddingsTrue, show_progress_barFalse, ) return vectors def embed_query(self, query): 將單個(gè)查詢文本編碼為向量。 vector self.model.encode( [query], normalize_embeddingsTrue, show_progress_barFalse, ) return vector[0]這里使用的是 Sentence-BERT 方案它把一整段句子映射為向量。之所以選擇它是因?yàn)槲覀兿Ｍ脩魡?wèn)題與文檔片段之間具備語(yǔ)義可比性。比如用戶問(wèn)“每次問(wèn)知識(shí)庫(kù)問(wèn)題是不是都要花錢(qián)”如果只用關(guān)鍵詞索引很難匹配到“運(yùn)行時(shí)成本”這一篇文檔。而向量模型可以找到語(yǔ)義相近的文本。然后是src/search.py負(fù)責(zé)把片段向量組裝成一個(gè)矩陣并提供 Top-K 相似度查詢。# 文件路徑ragless-demo/src/search.py import numpy as np class VectorSearchEngine: 簡(jiǎn)單的內(nèi)存向量檢索器。 def __init__(self, chunks, embedder): self.chunks chunks self.embedder embedder self.vectors None self.build_index() def build_index(self): texts [c[text] for c in self.chunks] vectors self.embedder.embed_texts(texts) self.vectors np.array(vectors) def search(self, query, top_k3): query_vec self.embedder.embed_query(query) # 向量已經(jīng)歸一化點(diǎn)積等價(jià)于余弦相似度 scores self.vectors query_vec top_indices np.argsort(scores)[::-1][:top_k] results [] for idx in top_indices: results.append({ score: float(scores[idx]), chunk: self.chunks[idx], }) return results這里的代碼非常短但它已經(jīng)完成了一個(gè)傳統(tǒng) RAG 中“檢索”步驟的大部分工作。我們使用點(diǎn)積代替余弦相似度是因?yàn)槊恳恍邢蛄吭?Embedding 階段已經(jīng)做了歸一化點(diǎn)積結(jié)果天然落在 -1 到 1 之間數(shù)值越高表示越相似。5.4 命令行問(wèn)答入口最后寫(xiě)src/app.py把所有模塊串起來(lái)進(jìn)入交互式循環(huán)。當(dāng)用戶輸入一個(gè)問(wèn)題時(shí)系統(tǒng)會(huì)直接在本地庫(kù)中檢索最相關(guān)片段然后輸出結(jié)果。為了便于閱讀我會(huì)把排序、格式化輸出都放在這個(gè)入口文件中。# 文件路徑ragless-demo/src/app.py import sys import os # 添加項(xiàng)目根目錄到 sys.path方便直接運(yùn)行 src/app.py sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))) from src.loader import load_documents, build_chunks from src.embedder import LocalEmbedder from src.search import VectorSearchEngine def main(): base_dir os.path.dirname(os.path.dirname(os.path.abspath(__file__))) data_path os.path.join(base_dir, data, docs.json) # 1. 加載文檔并切分 documents load_documents(data_path) chunks build_chunks(documents) print(f文檔數(shù): {len(documents)}, 片段數(shù): {len(chunks)}) # 2. 構(gòu)建本地向量索引 print(正在加載本地向量模型并構(gòu)建索引...) embedder LocalEmbedder() engine VectorSearchEngine(chunks, embedder) print(索引構(gòu)建完成。輸入 exit 退出。\n) # 3. 進(jìn)入問(wèn)答循環(huán) while True: query input(請(qǐng)輸入問(wèn)題).strip() if query.lower() in {exit, quit, q}: break if not query: continue results engine.search(query, top_k3) print(\n 檢索結(jié)果 ) for rank, r in enumerate(results, start1): chunk r[chunk] print(f\n[Top{rank}] 相似度: {r[score]:.4f}) print(f來(lái)源: {chunk[doc_id]} - {chunk[title]}) print(f片段: {chunk[text]}) print(\n\n) if __name__ __main__: main()在這個(gè)入口文件里我們沒(méi)有調(diào)用任何外部大模型 API。用戶問(wèn)什么系統(tǒng)就檢索什么最終返回的永遠(yuǎn)是知識(shí)庫(kù)中的原文片段。你可以把這句話理解成 RAGless 和傳統(tǒng) RAG 最直觀的差異傳統(tǒng) RAG 返回的是一段“根據(jù)檢索內(nèi)容生成的回答”RAGless 返回的是一段“和問(wèn)題最匹配的知識(shí)庫(kù)原文”。5.5 運(yùn)行與驗(yàn)證完成代碼后在項(xiàng)目根目錄執(zhí)行cd ragless-demo python src/app.py首次運(yùn)行時(shí)sentence-transformers會(huì)下載模型文件所以需要耐心等待。如果下載失敗可以檢查網(wǎng)絡(luò)環(huán)境或者手動(dòng)下載模型后把 LocalEmbedder 中的模型名改成模型文件所在目錄。運(yùn)行后的輸出大致如下文檔數(shù): 5, 片段數(shù): 8 正在加載本地向量模型并構(gòu)建索引... 索引構(gòu)建完成。輸入 exit 退出。 請(qǐng)輸入問(wèn)題RAGless 為什么可以降低 API 成本隨后系統(tǒng)會(huì)返回與問(wèn)題最相關(guān)的 Top3 片段。注意相似度分?jǐn)?shù)會(huì)因模型迭代版本、文本切分方式而略有變化這里不寫(xiě)死具體數(shù)值。你拿到結(jié)果后可以對(duì)照我們的預(yù)期關(guān)于 RAGless 設(shè)計(jì)思路的 doc-003 片段應(yīng)該出現(xiàn)在較前位置其次可能是 doc-002 關(guān)于傳統(tǒng) RAG 運(yùn)行時(shí)成本的說(shuō)明。這個(gè)測(cè)試雖然簡(jiǎn)單但它演示了一個(gè)完整閉環(huán)自然語(yǔ)言問(wèn)題 → 本地向量化 → 知識(shí)庫(kù)檢索 → 返回來(lái)源與原文片段。在這一過(guò)程中不需要 API Key不需要記錄 token 消耗也不存在按次計(jì)費(fèi)。如果你希望嘗試中文效果更合適的本地模型可以更換 Embedding 模型名稱例如常見(jiàn)的bge-small-zh-v1.5或text2vec-base-chinese等。由于不同模型對(duì)語(yǔ)言和領(lǐng)域適配度不同建議用你自己的知識(shí)庫(kù)數(shù)據(jù)進(jìn)行驗(yàn)證后再做決定。6. 常見(jiàn)問(wèn)題與排查清單RAGless 實(shí)現(xiàn)起來(lái)難度不大但真正放到業(yè)務(wù)中還是會(huì)遇到各種細(xì)節(jié)問(wèn)題。下面整理了幾類高頻問(wèn)題與排查思路。問(wèn)題現(xiàn)象常見(jiàn)原因解決思路檢索返回片段與問(wèn)題不相關(guān)切分粒度不合理或文檔本身沒(méi)有覆蓋問(wèn)題調(diào)整切分窗口增加同義詞與關(guān)鍵詞擴(kuò)展所有問(wèn)題都返回同一篇文檔文檔主題太接近向量空間無(wú)法區(qū)分增加文檔元信息約束引入 BM25 關(guān)鍵詞召回用戶提問(wèn)是長(zhǎng)句返回片段太短切分窗口過(guò)小語(yǔ)義被切斷調(diào)大max_len或按段落標(biāo)題維度切分模型加載失敗或下載卡住網(wǎng)絡(luò)受限、模型文件不完整預(yù)下載模型并加載本地路徑檢查文件是否完整線上向量矩陣占用內(nèi)存過(guò)高文檔片段總量太大切換為 FAISS、Milvus 或 Qdrant 等專業(yè)向量索引用戶覺(jué)得原文不友好還是需要一句話答案場(chǎng)景不適合純?cè)姆祷卦黾与x線生成的摘要字段檢索時(shí)把摘要作為展示文案既然寫(xiě)到這里我們?cè)侔哑渲袔讉€(gè)典型問(wèn)題展開(kāi)看看。6.1 文檔切分邊界導(dǎo)致答案不完整這是最常見(jiàn)的問(wèn)題。比如文檔中寫(xiě)了“請(qǐng)假 3 天以內(nèi)由部門(mén)負(fù)責(zé)人審批超過(guò) 3 天由 HR 總監(jiān)審批”如果切分時(shí)把這句話拆成兩個(gè)片段用戶問(wèn)“請(qǐng)假 4 天找誰(shuí)審批”時(shí)檢索系統(tǒng)可能只返回了前半句。解決方案不是簡(jiǎn)單把切分窗口調(diào)大而是采用結(jié)構(gòu)化切分策略優(yōu)先按 Markdown 標(biāo)題層級(jí)、序號(hào)列表節(jié)點(diǎn)、表格行來(lái)切分而不是機(jī)械地按字?jǐn)?shù)切。如果原文檔是按條目組織的切分時(shí)盡量把一個(gè)完整條目保留在同一片段內(nèi)。6.2 用戶問(wèn)法和文檔寫(xiě)法差異很大向量模型雖然理解語(yǔ)義但并不是萬(wàn)能的。用戶可能用口語(yǔ)問(wèn)“請(qǐng)年假按什么規(guī)矩走”而文檔里寫(xiě)的是“員工帶薪年休假管理規(guī)范”。兩者在字面上相差極大向量檢索也可能匹配不到。工程上有幾個(gè)常見(jiàn)補(bǔ)救方法使用混合檢索在向量檢索之外疊加 BM25 關(guān)鍵詞檢索擴(kuò)充索引別名離線為每個(gè)片段生成可能被問(wèn)到的同義說(shuō)法建立用戶查詢?nèi)罩居涗洓](méi)有命中的問(wèn)題定期補(bǔ)充同義表達(dá)。RAGless 把成本壓力轉(zhuǎn)移到索引側(cè)之后這些“離線笨功夫”反而更容易做因?yàn)椴恍枰紤]每次運(yùn)行時(shí)調(diào)用大模型的花費(fèi)。6.3 純?cè)姆祷氐珮I(yè)務(wù)方想要一句話總結(jié)如果產(chǎn)品經(jīng)理明確要求“讓用戶直接看到一句結(jié)論”那么可以考慮一種折中方案離線階段為每個(gè)片段提前生成一個(gè)短摘要檢索時(shí)先展示摘要用戶點(diǎn)擊后再展開(kāi)原文。更進(jìn)一步還可以為高頻問(wèn)題預(yù)生成問(wèn)答對(duì)提前把“一個(gè)問(wèn)題、一句答案、一段原文依據(jù)”綁定好。用戶在 runtime 提問(wèn)時(shí)只做“問(wèn)題到預(yù)生成問(wèn)答對(duì)”的檢索仍然不需要調(diào)用外部 LLM API。6.4 想要把 LLM 保留在 runtime 但控制成本如果你的業(yè)務(wù)確實(shí)離不開(kāi)運(yùn)行時(shí)生成那么同樣可以參考 RAGless 的降本思路先進(jìn)行一次純檢索只有檢索結(jié)果的置信度低于閾值時(shí)才調(diào)用 LLM API 做一次總結(jié)。這樣的策略可以大幅削減調(diào)用次數(shù)而不是徹底禁止調(diào)用。從成本角度來(lái)說(shuō)它已經(jīng)比每次提問(wèn)都讓大模型生成要?jiǎng)澦愕枚唷?. 進(jìn)階把 RAGless 做得更像一個(gè)產(chǎn)品7.1 引入混合檢索與重排只做向量檢索在真實(shí)場(chǎng)景中往往不夠。一個(gè)更穩(wěn)定的結(jié)構(gòu)是向量檢索負(fù)責(zé)語(yǔ)義召回BM25 負(fù)責(zé)關(guān)鍵詞召回兩路結(jié)果合并后再通過(guò)一個(gè)重排模型或規(guī)則排序。對(duì)于規(guī)模不大的場(chǎng)景甚至可以用一個(gè)簡(jiǎn)單的線性加權(quán)公式。# 示意代碼向量分?jǐn)?shù)與關(guān)鍵詞分?jǐn)?shù)的線性融合 def hybrid_score(semantic_score, keyword_score, alpha0.7): return alpha * semantic_score (1 - alpha) * keyword_score這里的核心是可解釋性如果用戶輸入一個(gè)公司內(nèi)部縮寫(xiě)詞比如“PO”向量模型可能不知道它代表“產(chǎn)品負(fù)責(zé)人”但 BM25 可以在文檔中直接命中“PO”。兩路互補(bǔ)能夠明顯提升召回質(zhì)量。不同行業(yè)、不同知識(shí)庫(kù)權(quán)重alpha也不同需要通過(guò)測(cè)試集去定。7.2 增量更新與索引構(gòu)建流水線知識(shí)的有效期決定了 RAGless 系統(tǒng)的保鮮程度。上線之后你不可能每次都重建全量索引。建議采用增量流水線新文檔入庫(kù)后將內(nèi)容寫(xiě)入消息隊(duì)列后臺(tái)任務(wù)重新切分、向量化并請(qǐng)求更新索引舊文檔被修改時(shí)需要同步刪除舊片段每天凌晨執(zhí)行一次全量一致性檢查。這種設(shè)計(jì)有一個(gè)明顯優(yōu)勢(shì)用戶可以容忍后臺(tái)任務(wù)跑幾分鐘但很難接受每次問(wèn)答都要等大模型慢慢生成。RAGless 把時(shí)間壓力從查詢鏈路轉(zhuǎn)移到后臺(tái)鏈路恰恰符合這類業(yè)務(wù)訴求。7.3 緩存同一類查詢結(jié)果在傳統(tǒng) RAG 中即使用戶問(wèn)同樣的問(wèn)題每次也會(huì)調(diào)用一次 API因?yàn)樯山Y(jié)果帶有隨機(jī)性。RAGless 的檢索結(jié)果通常非常穩(wěn)定同一問(wèn)題得到的文檔向量也很接近。因此我們可以為高頻問(wèn)題建立緩存將問(wèn)題做歸一化處理計(jì)算其向量指紋再通過(guò)簡(jiǎn)單緩存直接返回結(jié)果連向量檢索都可以省掉。這會(huì)把運(yùn)行時(shí)成本進(jìn)一步壓低響應(yīng)時(shí)間也能降到更低。7.4 評(píng)估檢索質(zhì)量而不是只看生成答案好不好RAG 項(xiàng)目的常規(guī)評(píng)估習(xí)慣是讓用戶看最終生成答案是否順眼、是否正確。但 RAGless 沒(méi)有生成環(huán)節(jié)所以我們要把評(píng)估焦點(diǎn)放到檢索命中率上。建議建立一個(gè)小型測(cè)試集每個(gè)測(cè)試問(wèn)題標(biāo)注出“正確答案應(yīng)該來(lái)自哪個(gè)文檔的哪個(gè)片段”。然后計(jì)算以下指標(biāo)RecallK前 K 個(gè)結(jié)果中是否包含正確答案片段命中平均排序位置返回片段與問(wèn)題的時(shí)間/主題分布是否合理。有了這個(gè)測(cè)試集調(diào)參、換模型、改切分方式時(shí)都能有量化的對(duì)比依據(jù)而不是靠拍腦袋。8. 總結(jié)與學(xué)習(xí)路線這篇文章從 RAGless 這個(gè)項(xiàng)目標(biāo)題切入拆解了它的核心思想把知識(shí)庫(kù)問(wèn)答的成本從“用戶每次提問(wèn)時(shí)的按次付費(fèi) API 調(diào)用”轉(zhuǎn)移到“一次性的離線索引建設(shè)”。在運(yùn)行時(shí)我們可以通過(guò)“本地向量化 向量檢索 返回原文片段”來(lái)完成很大一部分知識(shí)庫(kù)問(wèn)答任務(wù)不依賴外部 LLM API。圍繞這個(gè)思路我們實(shí)際完成了一個(gè)最小 Demo。它的數(shù)據(jù)量很小代碼也很簡(jiǎn)單但已經(jīng)包含了加載文檔、切分片段、本地向量化、相似度檢索、結(jié)果輸出這幾個(gè)關(guān)鍵模塊。你也可以把data/docs.json替換成自己的 FAQ 表格或者在build_chunks中接入自己業(yè)務(wù)里存放 Markdown 文檔的數(shù)據(jù)庫(kù)讓這套方案直接跑在真實(shí)數(shù)據(jù)上。接下來(lái)如果想繼續(xù)深入可以按下面的路線學(xué)習(xí)。第一步理解向量檢索原理。學(xué)習(xí)余弦相似度、向量索引、ANN 近鄰搜索等基礎(chǔ)概念。只有理解了向量空間里的“近似”是什么你才清楚為什么有些問(wèn)題會(huì)召回失敗有些召回結(jié)果又為什么異?？煽俊５诙窖a(bǔ)充關(guān)鍵詞檢索與重排知識(shí)。RAGless 不是堆一個(gè) Embedding 模型就完成的工作它更接近一個(gè)完整的搜索引擎切分、索引、召回、重排、緩存每個(gè)環(huán)節(jié)都會(huì)影響最終體驗(yàn)。第三步嘗試在合適場(chǎng)景中替換傳統(tǒng) RAG 的生成環(huán)節(jié)。你可以把一個(gè)已經(jīng)在調(diào)用 LLM API 的問(wèn)答場(chǎng)景保留 A/B 對(duì)照組把服務(wù)層改成先檢索原文如果用戶反饋原文足夠直接再考慮徹底切斷 runtime 生成請(qǐng)求。第四步關(guān)注成本建模與評(píng)估。這篇文章多次強(qiáng)調(diào)“把成本放到離線階段”但離線建設(shè)也需要算力、需要人力維護(hù)。只有在問(wèn)題場(chǎng)景足夠固定、內(nèi)容邊界足夠清晰時(shí)RAGless 的收益才會(huì)最大化。如果這個(gè)思路對(duì)你有啟發(fā)建議先不要急著換掉你的整套 RAG 系統(tǒng)而是準(zhǔn)備一小部分邊界明確的知識(shí)庫(kù)做一個(gè) RAGless 原型再用真實(shí)用戶問(wèn)題去對(duì)比檢索效果、響應(yīng)體驗(yàn)和賬單差異。自己親手跑一遍應(yīng)該比任何理論分析都能幫你判斷它終究適不適合你的項(xiàng)目。希望這篇教程能給你提供一些不同角度的思考。