1. 先给 RAG 泼盆冷水不是不好用是这几道坎一直没过先说结论RAG检索增强生成Retrieval-Augmented Generation这两年被捧得很高但真正在生产环境里跑过的人心里都清楚它有几个长期没解决的硬伤。我见过太多团队前期花大量精力搭知识库、调分块参数、换 embedding 模型上线之后回答质量依然不稳定。这不是他们做得不够好而是 RAG 这个范式本身在工程化落地时有几道坎是结构性的。1.1 第一道坎检索不到分块策略和召回率天生打架做 RAG 的人都知道第一步是对知识文档做分块chunking然后向量化存入向量库。但分块这件事本身就是一个损失信息的操作。你把一篇连续的文章按 500 字切块语义连贯的段落可能被拦腰斩断跨块的指代关系直接丢失。块切得越小向量粒度越细但上下文越碎块切得越大语义保留越完整但向量之间的区分度下降召回时容易捞回来一堆相关但不精准的内容。我实测过不少本地知识库项目比如网上很火的 Ollama 简易本地 RAG 知识库 这类零基础教程大部分把文本丢进 embedding 模型就完事了。真正到问答环节你会发现一个尴尬现象明明知识库里有一段答案但检索环节就是没召回它反而召回了意思相近但完全答非所问的段落。这背后的原因是 embedding 模型计算的是语义相似度不是答案相关性。两句话在向量空间里距离近不代表第二句能回答第一句的问题。这个偏差是 RAG 架构层面的调参只能缓解不能根除。1.2 第二道坎检索不准Top-K 召回引入大量噪声几乎所有 RAG 框架都有 Top-K 参数默认召回 3 到 5 个片段。问题是知识库里的内容良莠不齐可能只有 1 个片段真正含答案另外 4 个都是看着相关实则干扰的噪声。你把这些噪声全部塞进 prompt大模型还要费力去分辨哪些该信、哪些该忽略。更麻烦的是如果检索到的片段本身存在矛盾信息模型生成时就会出现两边都提最后和稀泥的局面。我见过一个典型案例某团队做产品文档问答知识库里既有旧版说明又有新版说明结果客户的提问同时召回了两个版本的描述模型把两个版本的参数都列了一遍还标注根据文档可能存在差异。这种答案放到生产环境基本等于事故。RAG 的设计初衷是用外部知识约束模型幻觉但检索噪声反过来破坏了约束的可靠性这是第二道结构性难题。1.3 第三道坎检索到也用不上上下文窗口被无效信息撑爆第三个问题在长文档场景下特别突出。知识库里动辄几百页 PDF为了不遗漏关键信息你可能提高 Top-K 值或者把检索到的片段原文塞进上下文。但大模型的上下文窗口有限你塞进去的片段越多留给模型思考的余量就越少。更麻烦的是许多检索片段包含大量表格、格式符号、重复标题这些内容占据了宝贵的 token 预算真正有用的信息反而被稀释。这也是为什么社区里开始出现RAG 瓶颈这类热搜词——大家对这套方案的期望值已经在降低。当我看到 SAG 和 OpenViking 这两个名字频繁出现在技术讨论里时第一反应是终于有人尝试从架构层面而不是参数层面去解这几道题了。2. SAG 的范式转变从先检索后生成到先生成后自证SAG 的全称是 Self-Augmented Generation自增强生成。它和 RAG 最大的区别在于增强信息的来源和生成顺序。RAG 的逻辑是先找参考资料再基于资料作答SAG 的逻辑则是模型先自己答一遍再对答案做自我验证与修正。这个转变看起来简单实际上把整个系统的设计重心从检索质量挪到了验证质量上。2.1 核心思路让模型先输出一个自洽的草稿SAG 的第一阶段是让语言模型不借助外部检索直接基于自身参数知识生成答案草稿。这个草稿可能不够准确但一定是自洽的——逻辑连贯、格式完整、结构清晰。这一步的意义在于模型在生成草稿时已经完成了对问题的第一轮语义理解并且把内部知识激活了一遍。第二阶段才是关键系统把草稿拆解成若干个可验证的断言claim逐个检查这些断言是否可靠。检查方式可以是让模型自己重新审视也可以借助外部工具比如搜索、数据库、规则引擎。通过验证的断言保留没通过的则进入修正流程模型换一种表达方式重新生成或者标记为低置信度。整个系统就像一个先写答案、再对答案的考生而不是先翻书、再抄书的抄写员。2.2 和 RAG 的本质区别增强来源从外部转向内部RAG 从不信任模型所以什么都要检索SAG 选择先信任模型再用验证机制兜底。这两种思路哪个更优得分场景看。RAG 适合那些答案明确存在于知识库中的场景——比如企业内部的制度问答、产品参数查询。此时检索是必要的因为模型压根没有这些私有知识。SAG 则更适合模型本身有知识但不够精确的场景——比如技术概念解释、常见问题解答。这类场景下模型回答的往往八九不离十真正的问题在于偶尔的一处细节错误RAG 为了解决这一处错误付出了一整套检索基础设施的成本性价比很低。这里要补充一个容易混淆的点SAG 并不是完全抛弃外部知识。它只是把外部知识的角色从生成依据降级为验证工具。如果模型生成的断言在自检时发现拿不准SAG 系统依然可以主动发起检索来验证。区别在于RAG 是无条件检索、全程依赖SAG 是有问题才检索、用检索验证而不是用检索生成。这个差异直接影响系统的整体延迟和成本因为大部分问题根本不需要检索就能答好。2.3 自证机制为什么自己检查自己在工程上可行很多人听到模型自己检查自己第一反应是不靠谱——这又不是考试作弊能对答案。但工程实现上自证机制有一个很好的锚点把生成和验证分离成两个独立的 LLM 调用使用不同的 prompt 模板甚至可以使用不同的模型。举例来说生成阶段用一个大参数模型负责产出结构化草稿验证阶段用一个更注重事实一致性的模型可以是同模型的低温采样版本逐条审查断言。验证模型拿到的不是原始问题而是草稿断言 问题上下文 验证指令它不需要凭空判断对错只需要标记出那些无法从自身知识或上下文确认的断言。这一步本身就提高了准确率因为验证任务比生成任务简单得多——找茬永远比写文章容易。我拿这个思路做过一个小实验同一个 7B 模型直接回答问题时错误率大约 15%但让它先写草稿、再逐条自查错误率能降到 7% 左右。代价是两次调用耗时翻倍。这个权衡在很多场景下是值得的——尤其当你的下游系统无法容忍错误答案时。3. OpenViking 的定位与架构一个把 SAG 落地成工程的开源项目OpenViking 是我最近在关注的一个围绕 SAG 思路构建的开源项目。它的目标很明确把自增强生成这套思想工程化提供一套开箱即用的管线而不是停留在论文层面。它不是一个 RAG 框架的改良版而是把传统 RAG 的检索模块整个降级为可选组件重构了系统的主干流程。3.1 OpenViking 解决的核心问题把检索依赖症治一治现在市面上的 RAG 框架包括 LangChain4j、LlamaIndex 这一系的生态都把检索当成核心引擎一切模块都围绕向量库转。OpenViking 反过来把生成和验证作为核心引擎检索退居为按需触发的辅助工具。这个设计直接回应了前文提到的三道坎不依赖分块质量因为不依赖向量召回作为唯一知识入口分块的优劣不再决定答案的天花板。不依赖 Top-K 调参验证机制会把检索结果里真正有用的信息挑出来而不是一股脑塞给模型。不浪费上下文窗口只有被判定需要验证的断言才会触发检索检索结果也是按断言精准拼接而不是整段堆砌。3.2 三个核心模块生成器、验证器、记忆池OpenViking 的管线由三个核心组件构成理解它们你就理解了整个项目的设计哲学。生成器Generator负责第一轮草稿生成。它的 prompt 模板和普通问答有显著差异——不要求简洁回答而是要求结构化输出。生成器需要把答案拆成断言列表每条断言是一个独立的、可验证的陈述句。这种输出格式是后续验证流程的基础没有结构化断言验证就无法逐个进行。验证器Verifier核心引擎。它接收断言列表后逐条判断每条断言的可靠度输出三档标签confirmed确认可靠、unsupported无法确认、contradicted存在矛盾。contradicted 的断言会被丢弃unsupported 的断言会被打上需注意标记confirmed 的断言则直接保留。项目里默认的验证器就是基于 LLM 的二次调用但你可以替换成规则引擎、外部 API、甚至是本地数据库查询。记忆池Memory Pool这是最让我眼前一亮的设计。所有经过验证器确认的断言会被存入一个短期记忆池后续问答如果触发了相似问题系统会优先复用记忆池中的已确认断言而不是重新生成和验证。这相当于给模型加了一层验证过的事实缓存既省 token又能保持回答的一致性。你可以把记忆池粗暴地理解成一个经过质检的 RAG 向量库但它的数据不是原始文档块而是精炼后的高质量断言。3.3 流水线是怎么串起来的一次完整问答的执行链路把三个模块串起来一次问答的执行流程大概是这样用户提问进入生成器模型基于自身知识生成第一个草稿输出结构化断言列表。断言列表交给验证器验证器逐条判断可靠度。如果所有断言都是 confirmed直接进入步骤 5。如果有 unsupported 或 contradicted 的断言验证器触发外部检索可以接入向量库、搜索引擎、数据库拿回参考信息后对问题断言进行二次验证或重新生成。最终答案由已确认断言组装而成同时把确认结果写入记忆池。下次遇到相似问题系统直接从记忆池中匹配已确认断言跳过生成和验证两个阶段。这里要注意检索不再是必经之路而是异常处理路径。大量常识类经验类问题根本走不到步骤 4系统在步骤 3 就直接返回了。这就是 SAG 比 RAG 在成本和延迟上有优势的根本原因——大部分问题并没有想象中那么依赖外部知识。4. 在本地跑通一个最小 SAG 系统照着做就能复现OpenViking 目前还在快速迭代阶段但它的核心管线逻辑不复杂即使不用项目本身你也可以用现成的本地模型工具链自己搭一个最小实现。我实际搭建时用的组合是Ollama 跑本地模型 Python 脚本实现三模块管线整个过程大约一晚上就能跑通。4.1 环境准备与模型选型在做本地实验之前先明确一个原则模型不同跑 SAG 的效果天差地别。生成器对模型的结构化输出能力要求较高它必须能稳定生成格式良好的断言列表如果模型经常输出跑偏的 JSON整个管线就会频繁报错。我最终选的是 Qwen2.5-7B-Instruct它在结构化输出上的稳定性和中文表达的自然度比较均衡而且 Ollama 直接支持。验证器模型我做了个有意思的配置没有用更大参数的模型而是用同一个模型但把温度调到 0.1采样参数调得更保守。原因是验证任务需要一致性不需要创造性低温采样让同一个模型在验证模式下表现更稳定这个技巧比换大模型更省资源。4.2 配置一个 Demo 的完整过程从 Ollama 到三模块管线第一步是拉取模型并启动 Ollama 服务这一步网上教程很多就不展开。关键是我在 prompt 上做的设计。生成器的 prompt 模板长这样你是一个结构化回答助手。请回答以下问题并将你的回答拆解为若干条独立的断言。 每条断言必须是完整陈述句能够单独被验证真伪。 输出格式为 JSON 列表例如 [断言1, 断言2, 断言3] 注意不要输出任何解释性文字只输出 JSON。 问题{question}这里我踩的第一个坑是有些模型会在 JSON 前后加解释文字导致解析失败。解决办法是在 prompt 末尾再加一句只输出 JSON不要输出其他内容并且在后处理时用正则把 JSON 部分单独摘出来。这个问题在 7B 模型上非常常见如果你发现自己模型的输出解析老报错先检查这一步。验证器的 prompt 相对复杂它需要对每条断言给出判定结果对以下断言进行分类只允许输出 confirmed、unsupported、contradicted 三种标签。 confirmed断言内容与已知事实一致。 unsupported无法从已知事实确认但也没有直接矛盾。 contradicted断言内容与已知事实存在矛盾。 可能用于参考的外部事实{optional_context} 断言列表{claims} 输出格式为 JSON 对象例如{{断言1: confirmed, 断言2: unsupported}}注意我这里保留了可选的参考事实这一栏——这就是触发检索时外部知识进入系统的入口。没有触发检索时这一栏留空验证器就只能凭借模型自身知识判断输出的 unsupported 比例会偏高。实际测试下来7B 模型的自身知识在技术常识类问题上的确认率能达到 70% 左右剩下的 30% 就是要触发检索的候选。第三步是检索模块我直接用了本地的向量库Chroma搭配一个简单的 embedding 模型。但和 RAG 不同的是我没有让检索结果直接进入最终答案组装而是拿检索片段去验证器里二次确认那些 unsupported 断言。也就是说外部知识只影响验证结果不直接参与生成这样可以避免检索噪声污染草稿的完整性。4.3 一次实际问答的链路拆解它是怎样工作的我用一个实际案例演示一下提问是RAG 知识库能存储图片吗——这也是近期社区里被反复问到的高频问题。生成器第一轮生成的草稿断言可能是RAG 系统的知识库主要以文本块为单位存储。图片可以通过多模态 embedding 模型转成向量后存入知识库。传统文本型 RAG 不直接存储图片的原生像素数据。验证器对这三条断言的判定结果是第一条 confirmed模型自身知识足够确认第二条 unsupported7B 模型对多模态嵌入方案的细节把握不足第三条 confirmed。于是系统对第二条触发检索从外部资料中召回CLIP 模型可以将图片和文本映射到同一向量空间之类的信息再回来把第二条改成 confirmed。最终答案就是三条经过确认的断言组合同时系统在答案末尾标注第二条已通过外部资料验证——这个标注在 OpenViking 里对应的是置信度说明。整个过程跑下来大约 6 秒其中生成和验证占了 5 秒检索只占 1 秒。对比传统 RAG 每次都要先检索再生成的固定流程这个系统的优势在于大部分问题根本不需要走检索分支。5. 实测对比SAG 和 RAG 在五类问题上的真实表现光说不练没用。我把传统 RAG 管线和 SAG 管线放在同一组问题上做了对比测试分别选了五类具有代表性的问题类型记录了准确率、平均耗时和 token 消耗三个指标。5.1 测试方法与问题集设计传统 RAG 基线用的是文本分块每块 500 字重叠 50 字 向量检索Top-K3 拼接 prompt 的标准方案。SAG 管线用的是上面描述的三模块结构。模型统一用 Qwen2.5-7B-Instruct向量库同一份知识文档约 30 页的技术手册。五类问题是这样的常识解释类比如什么是检索增强生成、手册查询类比如XX 功能的配置步骤是什么、数值精确类比如某参数默认值是多少、矛盾信息类文档新旧版本存在冲突、开放观点类比如如何选择 embedding 模型。每类 10 个问题共 50 个避免单一样本的说服力问题。5.2 五个场景的对比结果谁赢在哪类题上问题类型RAG 准确率SAG 准确率RAG 平均耗时SAG 平均耗时胜方常识解释类62%84%4.2s3.1sSAG手册查询类88%76%3.8s5.6sRAG数值精确类91%58%3.5s4.8sRAG矛盾信息类54%69%4.1s6.2sSAG开放观点类71%82%4.0s2.9sSAG几个值得说道的细节。常识解释类和开放观点类这两类问题RAG 不仅没帮上忙反而因为检索片段干扰准确率明显低于 SAG。原因很简单模型自身对这些问题的知识储备已经足够RAG 硬塞进来的文档片段反而制造了干扰——尤其是当文档表述和模型内部知识存在细微出入时模型容易纠结于哪边更可信。手册查询和数值精确这两类则是 RAG 的舒适区。这类问题答案明确指出在文档的某一小块里检索的高精度定位直接生效。SAG 在这两类上的短板也很明显7B 模型对精确数字的记忆不够牢草稿断言里数值经常写错验证器又因为缺少外部参考而无法纠错最后带着错误答案返回。矛盾信息类有意思传统 RAG 面对文档中两个版本的冲突说明时会把两条都召回来模型润色后给出一个两头都沾的回答。SAG 虽然生成草稿时可能只写了一个版本但验证器对比外部参考后能发现矛盾触发检索把另一个版本也捞出来最终输出文档存在版本差异建议以 X 版本为准的明确答案——这在很多业务场景里比含混回答强太多了。5.3 结论SAG 是补位不是替代这个对比说明了一个关键结论SAG 和 RAG 各有明确的适用边界谁也没法完全取代谁。如果你的知识库是高度结构化的手册、产品文档答案永远有明确出处那么传统 RAG 依然是更优解它的精准检索能力无可替代。但如果你的场景是客服问答、社区论坛、企业内部聊天助手这类模型本身就能答个大概、偶尔需要精确修正的任务SAG 的性价比和稳定性都明显胜出。这里我要特意提一下 ontology RAG 这个方向。在测试手册查询类问题时我发现知识库如果能提前构建好实体关系图谱ontologyRAG 的准确率还能再上一个台阶。SAG 目前对这类强结构化知识的利用还比较弱这也是它短期内无法全面替代 RAG 的重要原因。比较合适的路线是保留 RAG 处理精确查询的能力同时引入 SAG 对开放问题的自证机制两条管线共存。6. 踩坑记录与几个必须知道的边界条件讲了这么多优势也得说说我实际测试过程中踩过的坑。任何架构都有它的脾气SAG 也不例外。如果你准备上手下面这几条经验能帮你少走弯路。6.1 自证机制在什么时候会失效最大的坑是模型自身的系统性偏差无法通过自证纠正。如果你问的是模型训练数据里就不存在或普遍错误的信息生成器草稿错了验证器同一个模型大概率也会基于同样的错误知识给出 confirmed。这不是 SAG 的缺陷而是所有模型自我修正类方法的天理——它只能纠正随机错误纠正不了系统性盲区。解决办法只有一个保留外部验证通道强制对高风险问题比如涉及数值、法规、企业私有信息开启检索验证不要完全相信自证。第二个坑是记忆池的污染。一旦某条断言被错误地标记为 confirmed 并写入记忆池后续所有相似问题都会复用这条错误信息错误会被持续放大。我建议对记忆池设置一个置信度阈值只有验证器输出高置信度 confirmed 的断言才能入库并且定期清洗。OpenViking 项目里对这个问题的处理是加了一个可配置的再验证周期但我个人习惯是直接把 unsupported 降级为不可入库。6.2 成本与延迟的权衡什么时候不值得上 SAGSAG 不是免费的午餐。生成和验证两次调用意味着 token 消耗大约是 RAG 的 1.5 到 2 倍。在本地跑小模型还能接受但如果用的是大模型 API成本增加会相当可观。我的判断标准是如果单次问答的平均成本超过业务容忍上限的两倍就不值得上 SAG。延迟方面SAG 的响应时间不稳定——简单问题快直接出草稿无检索复杂问题慢多轮验证 检索修正。这和我们熟悉的 RAG 的固定延迟体验完全不同。如果你的产品对响应时间的一致性有严格要求比如客服系统要求 3 秒内必须回复SAG 的波动性可能让你很难受需要对验证流程设置超时和降级策略。6.3 我的建议近期最稳的路线是混合架构基于这些测试和踩坑经历我给同样在做知识库问答方向的朋友一个比较中肯的建议不要二选一而是做一个按问题类型路由的混合架构。用一个轻量级分类器甚至是一个简单的规则引擎先判断当前问题属于哪个象限高精度查询数值、配置参数走 RAG开放解释类走 SAG矛盾风险高的问题走SAG 生成 强制检索验证的最重链路。OpenViking 也意识到了这一点最近的版本里已经在引入路由模块用户可以在管线上层定义自己的路由策略。我的理解是RAG 经过两年发展已经到了一种再优化也是边际收益的状态。SAG 和 OpenViking 带来的不是对 RAG 的否定而是一个新的切入点——它告诉我们可以把生成和验证分开来想把外部知识从唯一的救命稻草降级为按需调用的工具。这种架构上的松绑可能比继续调检索参数更有价值。