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