越來越多的業(yè)務(wù)開始用 LLM 構(gòu)建知識(shí)庫問答但賬單也在不知不覺上漲每次用戶提問都要把檢索到的文檔片段拼進(jìn) Prompt再調(diào)用一次模型接口按 Token 計(jì)費(fèi)的成本像滾雪球一樣增加?？吹?Show HN 上的 RAGless 這個(gè)項(xiàng)目后我重新梳理了一遍“檢索增強(qiáng)生成”的成本模型。它提出的思路聽起來很直接運(yùn)行時(shí)不再調(diào)用 LLM也就沒有運(yùn)行時(shí) LLM API 費(fèi)用看起來和 RAG 效果相似但成本曲線完全不同。本文會(huì)拆解 RAGless 的核心思想并提供一個(gè)可以在本地直接運(yùn)行的最小 Python 示例幫助你判斷它適合用在你自己的知識(shí)庫問答項(xiàng)目中。1. RAGless 是什么它解決了什么問題1.1 從 RAG 的成本痛點(diǎn)說起RAGRetrieval-Augmented Generation檢索增強(qiáng)生成是目前構(gòu)建 LLM 知識(shí)庫應(yīng)用最常見的架構(gòu)。用戶輸入問題后系統(tǒng)先從一個(gè)外部知識(shí)庫中檢索出相關(guān)文檔片段再把“問題 文檔片段”一起發(fā)送給大語言模型讓模型基于給定材料生成答案。這樣做能緩解大模型幻覺、支持私有知識(shí)更新所以搜索、客服、企業(yè)內(nèi)網(wǎng)問答等場景都大量采用 RAG。但 RAG 有一個(gè)容易被低估的成本點(diǎn)在線階段每次問答都要調(diào)用一次 LLM API。這里的成本不只是輸入幾個(gè)字那么簡單。為了給模型足夠的上下文可能需要把幾段甚至幾千字的知識(shí)庫文本塞進(jìn) Prompt。隨著文檔長度、并發(fā)用戶數(shù)和調(diào)用頻率上升Token 費(fèi)用會(huì)線性增長。即使是低價(jià)的模型接口當(dāng)業(yè)務(wù)每天有數(shù)十萬次問答時(shí)也是一筆不能忽視的開支。再加上多次重試、日志調(diào)試、意圖判斷等額外調(diào)用實(shí)際成本常常高于預(yù)期。1.2 RAGless 的核心思想RAGless 并不是完全取消知識(shí)庫檢索而是改變“為每個(gè)問題現(xiàn)場生成答案”的路徑。它主張把大部分知識(shí)提前處理成固定的問答對(duì)或答案片段存放在一個(gè)離線構(gòu)建的結(jié)構(gòu)化緩存中。線上用戶提問時(shí)系統(tǒng)只做輕量的文本匹配和檢索把命中的答案直接返回。整個(gè)線上請(qǐng)求鏈路里沒有 LLM API 調(diào)用因此可以說 runtime 階段的 LLM API 成本趨近于 0。這樣設(shè)計(jì)的道理在于很多知識(shí)庫問題是有重復(fù)模式的。比如“如何重置密碼”“支持哪些導(dǎo)出格式”“某個(gè)接口的限流閾值是多少”這些問題背后的文檔內(nèi)容是穩(wěn)定的。如果每次用戶問同樣的問題系統(tǒng)都重新調(diào)用大模型生成一遍答案其實(shí)是在重復(fù)消費(fèi)算力。更好的辦法是用一次性離線生成把文檔里的知識(shí)“固化”下來線上以讀取代替推理。需要強(qiáng)調(diào)一點(diǎn)RAGless 并不是把模型徹底扔掉。離線階段仍然需要使用 LLM 或人工編輯來生成高質(zhì)量答案只是這部分費(fèi)用從“每一次用戶請(qǐng)求”轉(zhuǎn)變成“每新增一批文檔或更新一次知識(shí)庫”。對(duì)于文檔變動(dòng)不頻繁、高頻重復(fù)問題多的場景這種成本轉(zhuǎn)移通常能夠帶來數(shù)量級(jí)上的 API 費(fèi)用下降。2. RAG 與 RAGless 的概念對(duì)比2.1 兩種架構(gòu)的過程差異先回顧一次典型的 RAG 問答鏈路用戶輸入問題。系統(tǒng)對(duì)問題做向量化。在向量數(shù)據(jù)庫中檢索相關(guān)文檔片段。把問題和片段組裝成 Prompt。調(diào)用 LLM API 生成答案。返回答案給用戶。RAGless 的思路則是把第 4、5 步從線上移除轉(zhuǎn)而在離線完成離線下把原始文檔切分、清洗。使用 LLM 或人工把文檔改成問答對(duì)、摘要、結(jié)論卡片。將問答對(duì)保存為帶索引的本地?cái)?shù)據(jù)。用戶輸入問題時(shí)系統(tǒng)直接對(duì)問題做文本檢索。如果匹配到合適的離線問答對(duì)直接返回固定的答案否則走降級(jí)策略。2.2 適用邊界與選型對(duì)比維度RAGRAGless運(yùn)行時(shí) LLM API 成本每次請(qǐng)求都產(chǎn)生理想情況下為 0回答靈活性高能綜合多段內(nèi)容推理低依賴離線預(yù)生成的答案知識(shí)更新時(shí)間改文檔后即可嘗試但仍需驗(yàn)證需要重新執(zhí)行離線構(gòu)建流程實(shí)現(xiàn)復(fù)雜度需要向量庫、Embedding、Prompt 工程文本檢索較簡單核心在離線生產(chǎn)鏈路適合場景文檔復(fù)雜、推理型、長尾問題多FAQ 穩(wěn)定、文檔變更慢、高并發(fā)讀場景如果業(yè)務(wù)中有大量非結(jié)構(gòu)化的長文檔且用戶提問非常發(fā)散RAGless 的覆蓋能力會(huì)比較有限。反之如果答案大多能由單一文檔片段或明確的規(guī)則得出RAGless 就能用更低的成本實(shí)現(xiàn)接近 RAG 的體驗(yàn)。這就是為什么在很多推薦方案里RAGless 常被定位為 RAG 的“前置緩存層”。用戶問題先經(jīng)過離線問答庫匹配命中時(shí)直接返回不命中才調(diào)用 RAG 或 LLM API。這樣既保證了長尾問題的效果又能大量削減重復(fù)問題的在線開銷。3. 環(huán)境準(zhǔn)備與項(xiàng)目結(jié)構(gòu)3.1 運(yùn)行環(huán)境說明本文的演示代碼只依賴 Python 標(biāo)準(zhǔn)庫不需要安裝 TensorFlow、PyTorch、向量數(shù)據(jù)庫等重型組件也不需要注冊(cè)任何 LLM API。代碼在 Python 3.9 環(huán)境下可以直接運(yùn)行。如果你本機(jī)還沒有 Python 環(huán)境推薦安裝 3.10 或更高版本。雖然示例沒有使用第三方庫但真實(shí)項(xiàng)目中 RAGless 仍然可能用到 BM25、向量檢索或數(shù)據(jù)庫。本文先以盡量簡單的方案說明原理確保讀者不被環(huán)境問題擋住。3.2 項(xiàng)目目錄規(guī)劃為了方便閱讀建議先建立如下目錄結(jié)構(gòu)ragless-demo/ ├── documents/ │ ├── product_manual.txt │ └── faq.txt ├── offline_build.py ├── ragless_engine.py └── main.pydocuments/ 存放原始知識(shí)文檔可以理解為離線階段的輸入。offline_build.py 負(fù)責(zé)讀取文檔并生成問答對(duì)。ragless_engine.py 實(shí)現(xiàn)在線檢索與匹配。main.py 用于演示用戶查詢?nèi)肟?。如果只是跑通最小示例也可以把所有代碼寫在一個(gè)文件中。但把離線構(gòu)建和在線查詢拆開更符合 RAGless 的思想因?yàn)樗鼜?qiáng)調(diào)兩類任務(wù)運(yùn)行頻率完全不同。4. 核心原理拆解4.1 離線階段把知識(shí)固化成 QA 對(duì)“離線固化”是 RAGless 最重要的步驟。假設(shè)你有一份產(chǎn)品使用手冊(cè)文檔中某一段寫到MegaNote 支持 Markdown 導(dǎo)入導(dǎo)出最大附件為 100MB導(dǎo)出文件默認(rèn)保存在 “下載/MegaNote” 目錄。如果讓 RAG 系統(tǒng)實(shí)時(shí)回答它需要找到這段文字并讓 LLM 組織語言。RAGless 則提前把它變成若干問答對(duì)問題MegaNote 支持哪些導(dǎo)入導(dǎo)出格式答案MegaNote 支持 Markdown 導(dǎo)入導(dǎo)出。來源product_manual.txt問題MegaNote 最大附件大小是多少答案最大附件為 100MB。來源product_manual.txt這些問答對(duì)可以由 LLM 自動(dòng)生成也可以由運(yùn)營人員手動(dòng)編輯。由于生成過程發(fā)生在離線即使調(diào)用多次 LLM也只會(huì)產(chǎn)生一次性成本。知識(shí)更新頻率越低離線構(gòu)建的收益越明顯。4.2 在線階段輕量文本檢索與匹配在線階段不再使用 LLM 生成新文本而是把用戶問題和離線問答庫中的“問題”進(jìn)行匹配。匹配可以有很多做法字符串包含判斷Jaccard 相似度BM25 關(guān)鍵詞檢索向量相似度檢索為了控制成本和復(fù)雜度最簡單的方式是使用字符序列相似度與關(guān)鍵字重合度結(jié)合。Python 自帶difflib.SequenceMatcher它能給出兩個(gè)字符串的相似比例適合做一個(gè)小型基線系統(tǒng)。中文場景下按字符比較也有一定效果但真正的生產(chǎn)系統(tǒng)建議使用分詞與倒排索引。4.3 為什么能把成本降到 0用戶在線請(qǐng)求只發(fā)生兩類計(jì)算一是計(jì)算用戶問題與離線問答庫中問題的相似度二是讀取匹配到的答案并返回。這兩類計(jì)算都是本地 CPU 操作不涉及外部模型服務(wù)因此不會(huì)產(chǎn)生 LLM API 費(fèi)用。本質(zhì)上RAGless 是把“生成答案”這個(gè)最昂貴的動(dòng)作從請(qǐng)求路徑上移除了。離線生成的問答對(duì)相當(dāng)于一種帶語義的緩存。這種緩存比普通結(jié)果緩存更聰明它可以借助 LLM 對(duì)文檔進(jìn)行改寫和歸納把用戶可能的問法覆蓋得更廣而不是只針對(duì)某個(gè)歷史查詢串。5. 完整實(shí)戰(zhàn)案例用 Python 實(shí)現(xiàn)一個(gè)最小 RAGless5.1 準(zhǔn)備原始語料我們先創(chuàng)建一份簡短的原始產(chǎn)品文檔用于模擬真實(shí)的離線輸入。在documents/product_manual.txt中寫入MegaNote 是一個(gè)本地優(yōu)先的筆記軟件。支持 Markdown 導(dǎo)出。 最大附件為 100MB。免費(fèi)版用戶最多創(chuàng)建 10 個(gè)筆記本。 數(shù)據(jù)默認(rèn)保存在本機(jī)可以設(shè)置端到端加密。隨后創(chuàng)建documents/faq.txt問如何重置密碼 答打開登錄頁點(diǎn)擊“忘記密碼”輸入注冊(cè)郵箱按郵件提示完成重置。 問如何導(dǎo)出筆記 答在筆記詳情頁右上角點(diǎn)擊菜單選擇“導(dǎo)出 Markdown”。 問免費(fèi)版和付費(fèi)版有什么區(qū)別 答免費(fèi)版最多 10 個(gè)筆記本付費(fèi)版無筆記本數(shù)量限制并支持端到端加密。這里的內(nèi)容是演示數(shù)據(jù)不構(gòu)成對(duì)任何真實(shí)產(chǎn)品的背書。生產(chǎn)中你可以把原始文檔替換為內(nèi)部 Wiki、操作手冊(cè)或數(shù)據(jù)庫導(dǎo)出的知識(shí)條目。5.2 離線構(gòu)建問答庫接下來編寫offline_build.py。真實(shí)項(xiàng)目中這個(gè)腳本會(huì)調(diào)用 LLM API讓模型根據(jù)原始文檔生成各種問法。為了最小化演示我們使用一組規(guī)則從原始語料中拆出問答并保存成易于匹配的結(jié)構(gòu)化數(shù)據(jù)。# offline_build.py 離線階段讀取原始文檔生產(chǎn)結(jié)構(gòu)化 QA 對(duì)。 真實(shí)實(shí)現(xiàn)中這里會(huì)調(diào)用 LLM 對(duì)文檔進(jìn)行改寫和問題擴(kuò)展。 本示例為便于運(yùn)行使用規(guī)則與手工種子數(shù)據(jù)代替。 import json from pathlib import Path def load_text(path: Path) - str: return path.read_text(encodingutf-8) def generate_qa_pairs(): qa_pairs [] # 這部分如果接入真實(shí) LLM可以用 Prompt 讓模型從文檔生成多種問法。 # 離線階段調(diào)用模型是允許的因?yàn)橹粫?huì)在文檔更新時(shí)執(zhí)行一次。 qa_pairs.append({ question: MegaNote 支持什么格式導(dǎo)入導(dǎo)出, answer: MegaNote 支持 Markdown 導(dǎo)入導(dǎo)出。, source: product_manual.txt }) qa_pairs.append({ question: MegaNote 最大附件是多少, answer: 最大附件為 100MB。, source: product_manual.txt }) qa_pairs.append({ question: 免費(fèi)版可以創(chuàng)建幾個(gè)筆記本, answer: 免費(fèi)版用戶最多創(chuàng)建 10 個(gè)筆記本。, source: product_manual.txt }) qa_pairs.append({ question: 如何重置密碼, answer: 打開登錄頁點(diǎn)擊“忘記密碼”輸入注冊(cè)郵箱按郵件提示完成重置。, source: faq.txt }) qa_pairs.append({ question: 如何導(dǎo)出 Markdown, answer: 在筆記詳情頁右上角點(diǎn)擊菜單選擇“導(dǎo)出 Markdown”。, source: faq.txt }) qa_pairs.append({ question: 免費(fèi)版和付費(fèi)版有什么區(qū)別, answer: 免費(fèi)版最多 10 個(gè)筆記本付費(fèi)版無筆記本數(shù)量限制并支持端到端加密。, source: faq.txt }) out_path Path(qa_store.json) out_path.write_text( json.dumps(qa_pairs, ensure_asciiFalse, indent2), encodingutf-8 ) print(f離線 QA 已生成共 {len(qa_pairs)} 條 - {out_path}) if __name__ __main__: generate_qa_pairs()運(yùn)行這個(gè)腳本后目錄下會(huì)生成qa_store.json。它相當(dāng)于 RAGless 的“離線知識(shí)緩存”。5.3 實(shí)現(xiàn)在線檢索引擎現(xiàn)在編寫ragless_engine.py。這個(gè)模塊負(fù)責(zé)加載離線問答庫、對(duì)用戶輸入做歸一化、計(jì)算相似度并返回答案。整個(gè)模塊不包含任何大模型調(diào)用因此非常適合放在高并發(fā)請(qǐng)求鏈路中。# ragless_engine.py RAGless 在線檢索引擎。 只做本地文本比較不調(diào)用任何 LLM API。 import json import re from difflib import SequenceMatcher from typing import List, Dict def normalize_text(text: str) - str: 歸一化統(tǒng)一小寫、去掉標(biāo)點(diǎn)與多余空格。 text text.lower() text re.sub(r[\s。、【】、《》.,!?;:\()[\]{}], , text) return text.strip() def char_similarity(a: str, b: str) - float: 基于字符序列的相似度適合 Demo。 a normalize_text(a) b normalize_text(b) if not a or not b: return 0.0 return SequenceMatcher(None, a, b).ratio() def keyword_overlap(query: str, candidate: str) - float: 將文本按長度切分成詞計(jì)算 Jaccard 重合度。 def tokens(text: str): text text.lower() return set(re.findall(r[\w\u4e00-\u9fa5], text)) q_tokens tokens(query) c_tokens tokens(candidate) if not q_tokens: return 0.0 inter len(q_tokens c_tokens) union len(q_tokens | c_tokens) return inter / union if union else 0.0 class RAGlessEngine: def __init__(self, qa_path: str qa_store.json): with open(qa_path, encodingutf-8) as f: self.qa_pairs: List[Dict[str, str]] json.load(f) def search(self, query: str, threshold: float 0.35) - Dict: best_score 0.0 best_item None for item in self.qa_pairs: # 綜合字符相似度與關(guān)鍵詞重合度 sim char_similarity(query, item[question]) overlap keyword_overlap(query, item[question]) score 0.6 * sim 0.4 * overlap # 如果用戶問題中包含了關(guān)鍵答案詞也可適當(dāng)提高權(quán)重 if item[answer] and any(word in query for word in item[answer][:5]): score 0.05 if score best_score: best_score score best_item item if best_item and best_score threshold: return { answer: best_item[answer], source: best_item[source], score: round(best_score, 4), mode: hit_offline } return { answer: None, source: None, score: round(best_score, 4), mode: no_hit_offline }這里的關(guān)鍵在于search只在本地運(yùn)行沒有任何網(wǎng)絡(luò)請(qǐng)求所以在線上不會(huì)產(chǎn)生模型 API 費(fèi)用。5.4 編寫主程序驗(yàn)證效果接下來編寫main.py模擬用戶通過命令行輸入問題。# main.py from ragless_engine import RAGlessEngine def main(): engine RAGlessEngine(qa_store.json) questions [ 如何導(dǎo)出 Markdown 文件, 最大附件大小是多少, MegaNote 免費(fèi)版可以建幾個(gè)筆記本, 能導(dǎo)出 PDF 嗎, ] for q in questions: result engine.search(q) print( * 60) print(問題, q) print(匹配模式, result[mode]) if result[mode] hit_offline: print(答案, result[answer]) print(命中來源, result[source]) print(相似度分?jǐn)?shù), result[score]) else: print(提示離線庫未命中可以考慮降級(jí)到 RAG 或人工客服。) print(當(dāng)前最高相似度, result[score]) if __name__ __main__: main()5.5 運(yùn)行與預(yù)期結(jié)果在項(xiàng)目目錄下依次執(zhí)行python offline_build.py python main.py預(yù)期會(huì)得到類似下面的輸出 問題 如何導(dǎo)出 Markdown 文件 匹配模式 hit_offline 答案 在筆記詳情頁右上角點(diǎn)擊菜單選擇“導(dǎo)出 Markdown”。 命中來源 faq.txt 相似度分?jǐn)?shù) 0.xxxx 問題 最大附件大小是多少 匹配模式 hit_offline 答案 最大附件為 100MB。 命中來源 product_manual.txt 相似度分?jǐn)?shù) 0.xxxx 問題 MegaNote 免費(fèi)版可以建幾個(gè)筆記本 匹配模式 hit_offline 答案 免費(fèi)版用戶最多創(chuàng)建 10 個(gè)筆記本。 命中來源 product_manual.txt 相似度分?jǐn)?shù) 0.xxxx 問題 能導(dǎo)出 PDF 嗎 匹配模式 no_hit_offline 提示離線庫未命中可以考慮降級(jí)到 RAG 或人工客服。 當(dāng)前最高相似度 0.xxxx從輸出可以看到前三個(gè)問題都命中了離線答案最后一個(gè)問題因?yàn)殡x線庫沒有對(duì)應(yīng)內(nèi)容而返回未命中。整個(gè)過程中沒有任何 LLM API 請(qǐng)求發(fā)生。6. 如何在真實(shí)項(xiàng)目中使用 LLM 離線生成問答對(duì)上面的演示使用了手工寫死的問答對(duì)但在真實(shí)業(yè)務(wù)中文檔數(shù)量可能成千上萬手工編寫不現(xiàn)實(shí)。更合理的做法是使用 LLM 在離線構(gòu)建階段自動(dòng)生成問答對(duì)。離線構(gòu)建時(shí)你可以把切分后的文檔片段交給模型讓它產(chǎn)出相關(guān)問題。一個(gè)典型的提示詞結(jié)構(gòu)可能像這樣你是一名知識(shí)庫整理助手。請(qǐng)閱讀下面的文檔片段生成最多 5 個(gè)用戶可能詢問的問題并為每個(gè)問題給出直接答案。 要求 1. 問題要覆蓋不同表述方式。 2. 答案只基于給定片段不要額外推測。 3. 如果某片段不能形成問答輸出空列表。 文檔片段 {chunk} 請(qǐng)按 JSON 數(shù)組返回格式為 [{question: ..., answer: ...}]需要注意不同模型的上下文長度和返回格式能力可能有差異。以當(dāng)前主流大模型 API 為例有些模型支持很長的上下文但具體支持哪些模型名、上下文長度上限是多少都會(huì)隨服務(wù)版本動(dòng)態(tài)調(diào)整。在離線任務(wù)中你可以根據(jù)模型官網(wǎng)的接口文檔調(diào)整參數(shù)也可以使用開源模型部署到本地來完成離線生成?？傊x線構(gòu)建只關(guān)心“是否能一次性生成高質(zhì)量問答對(duì)”成本敏感度低很多。把離線生成結(jié)果保存到qa_store.json后在線引擎不需要改動(dòng)就能繼續(xù)使用。這樣你就得到了一套“離線 LLM 提煉知識(shí) 在線零 LLM 成本”的 RAGless 基礎(chǔ)架構(gòu)。7. 常見問題與排查思路7.1 離線問答庫匹配不到問題怎么辦問題現(xiàn)象常見原因解決思路用戶問題與離線問法差異大離線生成的問題覆蓋不足在離線 Prompt 中要求模型擴(kuò)展同義改寫相似度閾值設(shè)置過高正規(guī)問法也匹配不上查看分?jǐn)?shù)分布降低閾值或增加兜底邏輯匹配到錯(cuò)誤答案不同問題文本長得像但語義不同引入關(guān)鍵詞排除表或向量檢索輔助用戶問復(fù)雜多跳問題離線答案庫是點(diǎn)狀回答通過人工或模型生成關(guān)聯(lián)路徑必要時(shí)降級(jí)到 RAG如果經(jīng)常出現(xiàn)未命中可以先輸出所有候選問題的相似度分?jǐn)?shù)觀察分布。不要把閾值拍腦袋設(shè)死應(yīng)該基于一批歷史真實(shí)問題做評(píng)測后確定。7.2 文檔更新后線上答案不生效怎么辦RAGless 的知識(shí)來源于離線構(gòu)建的 QA 庫因此文檔變更不會(huì)自動(dòng)同步到線上。正確做法是把“文檔更新”變成一次可追蹤的離線流水線檢測到文檔變更。觸發(fā)離線問答生成任務(wù)。將新生成的 QA 先寫入預(yù)發(fā)布庫。用歷史問題回歸測試。通過后切換線上加載文件。如果你使用 JSON 單文件保存 QA建議引入版本號(hào)或發(fā)布時(shí)間字段。這樣即使出現(xiàn)問題也能快速回滾到上一個(gè)穩(wěn)定版本。7.3 相似度算法在中文場景下效果差怎么辦本文為了演示只用了SequenceMatcher它在處理中文時(shí)更多是基于字符順序無法理解同義詞。生產(chǎn)環(huán)境可以這樣優(yōu)化使用 jieba 進(jìn)行中文分詞。使用 BM25 或 TF-IDF 做召回。對(duì)用戶問題和離線問題分別計(jì)算向量再使用向量相似度重排。引入同義詞詞表例如“重置密碼”和“忘記密碼怎么辦”建立等價(jià)關(guān)系。檢索質(zhì)量的提升并不一定需要在線調(diào)用 LLM。你可以離線為每個(gè)問題生成多組“用戶問法”這樣在線檢索就退化成類似搜索引擎的匹配同樣不會(huì)產(chǎn)生模型費(fèi)用。8. 最佳實(shí)踐與工程建議8.1 把 RAGless 設(shè)計(jì)成緩存層而不是唯一方案RAGless 最適合作為高并發(fā)重復(fù)問題的第一道閘門。在完整生產(chǎn)方案中你可以先查離線庫命中則直接返回未命中再去調(diào)用 RAG 或 LLM。這個(gè)“先查緩存再走模型”的模式能最大程度保障回答質(zhì)量同時(shí)顯著降低平均成本。不要把 RAGless 當(dāng)成所有問題的萬能鑰匙否則用戶一旦詢問復(fù)雜問題體驗(yàn)會(huì)很差。8.2 設(shè)計(jì)完整的離線構(gòu)建與評(píng)測流程離線構(gòu)建是 RAGless 的質(zhì)量源頭必須有流程保障。我給團(tuán)隊(duì)的建議是每一個(gè)文檔片段至少覆蓋 2 到 3 種用戶問法。生成回答后需要做準(zhǔn)入檢查過濾空答案、明顯重復(fù)和包含隱私信息的答案。對(duì)重要知識(shí)設(shè)置人工確認(rèn)環(huán)節(jié)因?yàn)殄e(cuò)誤答案一旦被離線庫緩存影響范圍比普通單次回答更大。每次部署前使用歷史問題做回歸測試計(jì)算命中率和答案正確率。8.3 權(quán)衡成本與延遲很多團(tuán)隊(duì)只關(guān)注 API 賬單忽略了另一個(gè)收益延遲。在線 LLM 調(diào)用通常需要數(shù)百毫秒到數(shù)秒而本地文本檢索通常在毫秒級(jí)完成。RAGless 不僅能把成本降為 0還能顯著改善接口響應(yīng)速度。如果你的服務(wù)對(duì)延遲有硬性要求可以考慮在架構(gòu)圖上把離線庫里命中率高的請(qǐng)求全部走本地檢索。8.4 安全與權(quán)限邊界把知識(shí)固化到離線庫后需要注意知識(shí)權(quán)限問題。比如文檔中可能包含“僅內(nèi)部可見”的內(nèi)容如果在 QA 庫里沒有做角色區(qū)分用戶可能通過匹配問題拿到不該看到的答案。建議給每個(gè)問答對(duì)增加權(quán)限標(biāo)簽在線檢索時(shí)先根據(jù)用戶身份過濾候選集再計(jì)算相似度。對(duì)涉及刪除、賬號(hào)、支付等內(nèi)容不要輕易讓離線庫直接返回答案應(yīng)當(dāng)保留人工或在線模型的復(fù)核通道。8.5 監(jiān)控與可觀測性RAGless 依然需要監(jiān)控。重點(diǎn)觀察離線庫命中率命中數(shù) / 總請(qǐng)求數(shù)。未命中原因是長尾問題、離線庫更新滯后還是用戶問法差異過大。相似度分?jǐn)?shù)分布如果大量命中答案分?jǐn)?shù)接近閾值說明需要擴(kuò)充問法。答案來源分布了解哪些文檔被頻繁提問優(yōu)先維護(hù)這些內(nèi)容。只有建立這些指標(biāo)你才能知道 RAGless 是否真的在幫你省錢也能發(fā)現(xiàn)什么時(shí)候需要切換到 RAG 或增加 LLM 兜底。8.6 從最小閉環(huán)開始迭代如果你準(zhǔn)備實(shí)踐 RAGless不要一開始就搭建復(fù)雜的索引、向量庫和離線流水線。建議先選定一個(gè)文檔穩(wěn)定、重復(fù)問題多的 FAQ 場景用最簡單的方式生成 50 到 100 條問答對(duì)做一個(gè)命令行版本測試命中率。命中率穩(wěn)定后再加入文檔自動(dòng)解析、在線 API 和版本管理。這樣既能把成本控制住又能快速驗(yàn)證思路是否適合你的業(yè)務(wù)。如果在開發(fā)中你也為 RAG 的高額 API 費(fèi)用頭痛可以先從文檔中最常被用戶提問的部分入手離線整理成問答對(duì)然后逐步擴(kuò)大覆蓋面。哪天你發(fā)現(xiàn)在線模型調(diào)用量大幅減少而用戶滿意度沒有下降就說明 RAGless 已經(jīng)在你的系統(tǒng)里真正發(fā)揮作用了。