最近团队里讨论得最多的话题就是大模型的记性到底靠不靠谱。有人拿着 128K 上下文的模型往里头塞了一整本手册结果问细节照样答非所问有人搭了套 RAG 管线明明知识库资料齐全检索出来的却总是无关片段。说实话Context 和 RAG 这两个词已经被说烂了但真正能讲清楚它们能干什么、不能干什么、该怎么配合的人并不多。这篇文章想聊聊我自己的理解——大模型的记忆到底存在哪里上下文窗口的边界在哪RAG 又是怎么把死知识变成活答案的。不管你是刚接触大模型应用开发还是已经在做知识库问答、文档分析这类项目这篇文章应该都能帮你少踩几个坑。1. 大模型记忆的本质参数记忆与上下文记忆1.1 模型不是记住而是拟合出来很多人以为大模型像个硬盘训练时把知识写进去了用的时候读出来就行。这个类比其实挺误导人的。模型里那些参数比如几百亿权重并不是一份知识库而是一套经过海量文本训练出来的概率分布。你说李白是唐代诗人它能接上不是因为它的参数里有李白唐代诗人这条记录而是因为它见过的所有文本里李白和唐代共现的概率极高它把这个统计规律压进了参数里。这带来的后果很直接模型的内在知识是模糊的、统计性的它擅长的是顺着大概率往下接而不是精确回忆。你问它某 API 的第 3 个参数叫什么名字如果训练数据里这句话出现频率不够高它就给你编一个听起来合理的名字——这就是幻觉的根源之一。所以指望模型靠训练时记住的知识来回答你的私有业务问题从根上就不现实。1.2 上下文记忆一次对话里的工作台既然参数里没有精确知识那模型是怎么做到在对话里记住你说过的话的靠的是上下文窗口Context Window。它可以理解成模型当前摊在桌面上的便签纸上面写了什么它这次回答就能参考什么。你说我叫张三喜欢蓝色后面问我喜欢什么颜色它能答对不是因为它记住了你而是因为你说的这句话还在它的上下文里它看得到。也正因为如此上下文记忆有几个天生的特点第一它是临时的对话一结束或者便签纸被写满了这些信息就没了第二它是平均主义的便签纸上所有的字在注意力计算里都会占位置越往后越容易被稀释第三它是成本敏感的每多塞一个字计算量和费用都会涨。理解这三点后面所有关于 Context 和 RAG 的取舍就都有了依据。1.3 失忆的真相不是忘了是注意力不够分实际使用中大家吐槽最多的就是模型聊着聊着就忘了之前说的话。尤其是长对话场景用户在前面提供了关键背景后面却被模型忽略。这背后的机制我简单解释一下。Transformer 的注意力机制本质上是让每个 token 去关注其他 token但注意力权重是有限的资源。当上下文里有几千、上万 token 时真正与当前问题相关的关键信息可能只占很小一部分。模型并没有在架构上内置重要信息优先的筛选机制它只是计算相关性分数。结果就是离当前问题更近、文本上更相似的片段往往拿到更高的注意力权重而那些虽然重要但已经被淹没在历史里的信息就被忽略了。所以在实际项目中我从来不指望模型自己从一大坨上下文里捞关键信息。我会主动替它做减法——把有用的信息放在最近的位置把无关的东西清掉。这个思路跟后面要讲的 RAG 是一脉相承的。2. Context Window 的硬约束从 Token 到成本2.1 Token 是怎么算的要聊上下文窗口绕不开 Token 的概念。Token 是模型处理文本的基本单位你可以把它粗略理解成模型眼里的一个词块。英文一般一个单词拆成一到两个 Token中文则通常一个字或者一个词算一个 Token。举个例子一句今天天气不错在主流中文模型下大概是 6~8 个 Token同样内容用英文说the weather is nice today大概是 5~6 个 Token。所以同一种语言的不同写法、标点、空格都会影响 Token 消耗。我给项目做预算时有个粗估公式中文场景1 个汉字 ≈ 1~1.5 个 Token 英文场景4 个字符 ≈ 1 个 Token实际数字因模型分词器不同有差异但用这个公式做规划基本够用。有一个我自己踩过的坑某些模型对连续数字和代码片段的 Token 开销远高于普通文本因为分词器会把长串数字切成很多片。如果你的知识库里大量包含代码、编号、JSON预算时至少要多留 30% 的余量。2.2 上下文窗口标称值 vs 实际可用值现在的模型动不动就标称 128K、甚至 1M Token 的上下文。但标称窗口和实际可用窗口之间差别非常大。原因有几个第一超长上下文的性能衰减。业界普遍观察到模型在长上下文后段的检索准确率会明显下降。有研究结论指向一个现象当信息位于长上下文的中后部时模型找到它的概率显著低于放在开头或结尾。简单说你把关键资料塞在 100K Token 的中间位置它可能压根看不见。第二输出 token 也要占用窗口。很多人在计算上下文时只算输入忘了模型回答的内容也在窗口范围内。设置超长输入导致留给输出的空间不足回答到一半被截断这种问题在长文档总结场景特别常见。第三成本是二次增长。注意力机制的计算复杂度大约是 O(n²)输入序列翻倍计算开销可能涨四倍。虽然实际工程上有各种优化但窗口越长单价越贵的趋势不会变。所以我给团队定的一个经验值是除非业务硬性要求否则输入控制在窗口标称值的 1/4 以内。128K 标称窗口实际规划按 32K 算上下文的关键信息尽量放在开头和结尾两个区域。2.3 超长上下文的海市蜃楼位置编码的局限你可能要问厂商都在宣传超长上下文技术上到底卡在哪核心瓶颈之一是位置编码。Transformer 本身不感知顺序需要给每个 token 加一个位置标记。早期的绝对位置编码对长度有限制后来有了相对位置编码、旋转位置编码RoPE等一系列方案把支持长度不断推高。但位置编码只能解决模型认不认得这么长的序列的问题解决不了模型能不能有效利用这么长的序列的问题。注意力矩阵在长序列上的稀疏化以及信息之间的相互干扰会随着长度加剧。我用一个生活化类比给你一张写满 10 万字的小字纸条不是说你不能读而是读到第 8 万字的时候前面写了什么早就模糊了。模型也一样它读得完但用不好。所以对绝大多数业务场景我不建议走把全部资料塞进上下文这条路。它看起来简单短期能跑通但到资料量上涨、问答精度要求提高、成本敏感的时候一定会逼你回头做检索方案。这个方案就是 RAG。3. RAG 实战拆解给大模型装外挂大脑3.1 RAG 的完整链路检索、增强、生成RAG 全称 Retrieval-Augmented Generation核心思想很简单模型不需要记住所有知识你给它提供一个可以查的资料库让它根据当前问题先去检索把检索到的相关片段拼进提示词再基于这些片段生成回答。链路分四步先切分知识库文档再把每个片段做向量化并存入向量数据库用户提问时把问题也向量化去库中做相似度检索取回 Top-K 个相关片段接着把片段内容按一定格式组装进提示词最后交给大模型生成答案并要求它只基于给定片段作答。这套架构最大的价值在于知识更新成本极低。模型参数不需要重训资料库改了、删了、加了重新切分入库就行。对于企业知识库这类高频变动的场景RAG 几乎是唯一实用的方案。3.2 文档切分Chunking第一步就决定成败我刚接触 RAG 时以为检索是重头戏后来才发现切分策略才是真正的隐形杀手。同一个文档切得好不好直接决定后面能不能被正确检索。切分要考虑三个问题。一是切多长太短语义不完整太长噪音多、向量表达被稀释。我的经验是中文按 300~500 个字符切一个块英文按 200~300 个词切同时设 10%~15% 的重叠避免把完整句子拦腰截断。二是按什么边界切优先按章节标题、段落空行切而不是死板地按字数砍。Markdown 文档可以用标题层级做边界PDF 可以用段落边界。三是特殊内容怎么处理表格、代码块、列表项往往需要单独处理——比如把表格的每一行转成字段名值的句子这样向量化才有意义。我之前做一个产品手册问答项目最初按 500 字硬切结果检索出来的片段经常是半句话模型只能瞎猜。改成按章节切分后准确率一下子从 60% 出头提到了 80% 以上。这一步听起来不酷但确实是性价比最高的优化点。3.3 向量检索与 Top-K别迷信相似度分数检索阶段的核心组件是 embedding 模型和向量数据库。Embedding 模型把文本映射成几百到几千维的向量语义相近的文本在向量空间里距离更近。向量数据库负责存这些向量并快速找离问题向量最近的几个。这里有一个常见误区认为相似度分数越高结果越可信。实际上不同 embedding 模型的分数分布天差地别有的模型分数普遍在 0.8 以上有的在 0.5 左右跨模型比较没有意义。你更应该关注的是相对排序——Top-5 里前两名和后三名是否拉开明显差距。如果分数挤成一团说明检索本身就没区分度这时候调 Top-K 意义不大得回头看切分策略或者 embedding 模型选型。关于 Top-K 选择我的建议是从 3~5 起步。K 太小容易漏K 太大噪音太多而且会挤占上下文空间、拉高成本、增加幻觉概率。一个稳当的做法是先跑 50 条真实问题记录统计每次命中答案片段所在位置再据此调整 K 值。没有这个评估过程拍脑袋定的 K 都是玄学。3.4 重排序Rerank检索精度不够时加一道保险向量检索本质是语义粗筛它在词面匹配和精细语义理解上都可能出错。比如用户问退款多久到账知识库原文是资金将在 3~5 个工作日内原路返回向量相似度可能不高但语义确实相关。这种场景只靠向量检索容易漏。解决办法是加一个重排序模型Reranker。流程是先用向量检索取回 Top-50 个候选片段再用 Reranker 对这 50 个片段和问题做精细的交叉编码打分取前 3~5 个进上下文。重排序模型的计算成本高但只对候选集做整体开销完全可以接受。实测里加上 Reranker 之后不少项目的检索命中率能提升 10~20 个百分点。不过需要提醒的是Reranker 并不能解决库里没有答案的问题。它是锦上添花不是雪中送炭。基础切分和 embedding 选型没做好之前别急着上 Reranker。4. 实操案例两个项目的选型与落地记录4.1 案例一客服知识库问答RAG 主导某个电商项目的客服知识库大概有 2000 篇操作手册和售后政策文档用户问题以怎么办、怎么退、多久到为主。我们采用的就是完整 RAG 流程把文档按章节切分成平均 400 字的块标题层级做边界embedding 模型选择了中文表现稳定的通用向量模型向量库用了常见的开源方案检索时先取 Top-20过一个重排序模型再取 Top-3 进提示词提示词里明确要求模型只依据检索片段回答如果片段中没有信息直接说不知道。落地效果90% 以上的常见问题能给出正确步骤或政策条款引用剩余的边缘问题大部分是文档本身信息缺失导致的而不是工程问题。项目成本方面单次问答的向量检索耗时在 100 毫秒以内大模型生成答案的 token 消耗也因为我们严格限制检索片段长度控制在了比较理想的水平。4.2 案例二长合同风险分析Context 主导另一个场景是长文档分析几千页的合同 PDF需要判断里面有没有约定不明的条款。这类任务的难点不是找某个事实而是通读全文并做全局判断。RAG 的片段式检索在这里反而不够用——你要的不是某一片段而是全貌。我们的方案是分段总结再汇总先把全文按章节切块每块单独交给模型生成结构化摘要再把摘要汇总成一份完整的文档风险评估报告最后让模型基于汇总结果回答具体问题。在这种任务里Context 窗口是够用的——因为进入窗口的是摘要而不是原文信息密度被大幅压缩了。这个思路的关键是不是所有任务都适合 RAG也不是所有任务都适合整篇灌上下文。任务类型决定了方案。4.3 选型决策表什么时候用 Context什么时候上 RAG我把自己的判断标准整理成了一张表供你参考场景特征推荐方案原因单次输入信息量可控且与全部上下文强相关直接塞 Context简单直接无需维护检索链路知识库大、更新频繁、问题侧重事实查询RAG更新成本低可溯源性价比高需要全局理解的长文档总结分段摘要 Context 汇总避免检索碎片化保留全局信息既有事实查询又有全局判断的混合需求RAG 分段摘要混合用 RAG 答事实用摘要回答需要全局的问题这张表不是一个严格的公式但能帮你在一开始就避开选错方案、后期返工的坑。我见过不少团队一上来就搭 RAG结果知识库只有几十篇文档直接灌上下文又快又准也见过强行用长上下文死磕百万级知识库的成本高到不敢放开用。先想清楚场景再选工具永远不亏。5. 常见问题与排查技巧实录5.1 检索结果不准优先排查这三处问题检索出来的片段跟问题毫不相关或者看起来相关但用不上。排查顺序我建议固定为先看切分是否破坏了语义边界再看 embedding 模型和知识库语言是否匹配中文文档一定要用中文表现好的模型最后看是不是问题本身太短、太口语化导致向量表达不准。如果问题太短可以做一步问题改写——先让模型把口语化问题改写成适合检索的书面表达再去做向量化。这个技巧在很多项目里都有效。另一个高频坑是检索结果准确但模型答得不对。这种情况九成出在提示词上。如果提示词没有强调只依据给定片段回答模型会忍不住使用自己的内在知识作答而这些知识可能是过时的、虚构的。我建议在提示词里写清楚信息来源于检索片段片段没有覆盖的部分必须明确说明资料中未找到相关内容禁止自行推断。5.2 上下文与成本失控预算的三三制长上下文项目里成本失控是最常见的翻车点。我总结了一个三三制预算方法把一次调用的总 Token 预算分成三份——输入指令和检索片段占三分之一历史对话摘要占三分之一输出留三分之一。这个分配不是绝对比例而是一个提醒要时刻注意输出空间是否被输入挤占。另外历史对话的处理也有技巧。直接把所有历史消息拼进上下文是最蠢的做法。我习惯用滑动窗口只保留最近 2~3 轮完整对话更早的历史压缩成一句用户之前提到过……的摘要。这种摘要 近轮原文的结构既保留关键背景又控制 token 开销实测效果远比全量拼接好。5.3 幻觉能靠 RAG 根治吗清醒一点最后聊一个大家最关心的问题RAG 到底能不能解决幻觉我的结论是能大幅缓解不能根治。缓解在哪如果提示词约束到位模型会把回答锚定在检索片段上不再是纯靠概率外推答错的概率显著下降。不能根治在哪第一检索片段本身可能包含过时、错误、互相矛盾的信息模型无法替你判断真假第二模型为了凑一个完整回答可能在片段之外、在过渡性语言里加入自己的发挥第三如果用户的问题在知识库里没有对应内容而你的提示词约束不够硬模型照样会编。所以RAG 项目上线前一定要做无答案拒答测试。准备一批知识库覆盖不到的问题看模型会不会诚实地说不知道。一个合格的 RAG 系统应当有胆量说不知道而不是为了显得聪明而编造。这个测试应该作为验收标准写进项目里。按我个人经验把上面这些基本功做好一个 RAG 项目从能跑到好用差的其实不是模型选型而是对切分、提示词、评估这三件事的认真程度。上下文窗口再大也装不下一个不思考的工程方案。希望你读完这篇再去审视自己的项目时能清楚地说出我的方案到底是靠 Context 硬记还是靠 RAG 外挂以及它们各自承担的职责是什么。想清楚了这一点你踩过的坑都会变成判断力。
最近团队里讨论得最多的话题就是大模型的记性到底靠不靠谱。有人拿着 128K 上下文的模型往里头塞了一整本手册结果问细节照样答非所问有人搭了套 RAG 管线明明知识库资料齐全检索出来的却总是无关片段。说实话Context 和 RAG 这两个词已经被说烂了但真正能讲清楚它们能干什么、不能干什么、该怎么配合的人并不多。这篇文章想聊聊我自己的理解——大模型的记忆到底存在哪里上下文窗口的边界在哪RAG 又是怎么把死知识变成活答案的。不管你是刚接触大模型应用开发还是已经在做知识库问答、文档分析这类项目这篇文章应该都能帮你少踩几个坑。1. 大模型记忆的本质参数记忆与上下文记忆1.1 模型不是记住而是拟合出来很多人以为大模型像个硬盘训练时把知识写进去了用的时候读出来就行。这个类比其实挺误导人的。模型里那些参数比如几百亿权重并不是一份知识库而是一套经过海量文本训练出来的概率分布。你说李白是唐代诗人它能接上不是因为它的参数里有李白唐代诗人这条记录而是因为它见过的所有文本里李白和唐代共现的概率极高它把这个统计规律压进了参数里。这带来的后果很直接模型的内在知识是模糊的、统计性的它擅长的是顺着大概率往下接而不是精确回忆。你问它某 API 的第 3 个参数叫什么名字如果训练数据里这句话出现频率不够高它就给你编一个听起来合理的名字——这就是幻觉的根源之一。所以指望模型靠训练时记住的知识来回答你的私有业务问题从根上就不现实。1.2 上下文记忆一次对话里的工作台既然参数里没有精确知识那模型是怎么做到在对话里记住你说过的话的靠的是上下文窗口Context Window。它可以理解成模型当前摊在桌面上的便签纸上面写了什么它这次回答就能参考什么。你说我叫张三喜欢蓝色后面问我喜欢什么颜色它能答对不是因为它记住了你而是因为你说的这句话还在它的上下文里它看得到。也正因为如此上下文记忆有几个天生的特点第一它是临时的对话一结束或者便签纸被写满了这些信息就没了第二它是平均主义的便签纸上所有的字在注意力计算里都会占位置越往后越容易被稀释第三它是成本敏感的每多塞一个字计算量和费用都会涨。理解这三点后面所有关于 Context 和 RAG 的取舍就都有了依据。1.3 失忆的真相不是忘了是注意力不够分实际使用中大家吐槽最多的就是模型聊着聊着就忘了之前说的话。尤其是长对话场景用户在前面提供了关键背景后面却被模型忽略。这背后的机制我简单解释一下。Transformer 的注意力机制本质上是让每个 token 去关注其他 token但注意力权重是有限的资源。当上下文里有几千、上万 token 时真正与当前问题相关的关键信息可能只占很小一部分。模型并没有在架构上内置重要信息优先的筛选机制它只是计算相关性分数。结果就是离当前问题更近、文本上更相似的片段往往拿到更高的注意力权重而那些虽然重要但已经被淹没在历史里的信息就被忽略了。所以在实际项目中我从来不指望模型自己从一大坨上下文里捞关键信息。我会主动替它做减法——把有用的信息放在最近的位置把无关的东西清掉。这个思路跟后面要讲的 RAG 是一脉相承的。2. Context Window 的硬约束从 Token 到成本2.1 Token 是怎么算的要聊上下文窗口绕不开 Token 的概念。Token 是模型处理文本的基本单位你可以把它粗略理解成模型眼里的一个词块。英文一般一个单词拆成一到两个 Token中文则通常一个字或者一个词算一个 Token。举个例子一句今天天气不错在主流中文模型下大概是 6~8 个 Token同样内容用英文说the weather is nice today大概是 5~6 个 Token。所以同一种语言的不同写法、标点、空格都会影响 Token 消耗。我给项目做预算时有个粗估公式中文场景1 个汉字 ≈ 1~1.5 个 Token 英文场景4 个字符 ≈ 1 个 Token实际数字因模型分词器不同有差异但用这个公式做规划基本够用。有一个我自己踩过的坑某些模型对连续数字和代码片段的 Token 开销远高于普通文本因为分词器会把长串数字切成很多片。如果你的知识库里大量包含代码、编号、JSON预算时至少要多留 30% 的余量。2.2 上下文窗口标称值 vs 实际可用值现在的模型动不动就标称 128K、甚至 1M Token 的上下文。但标称窗口和实际可用窗口之间差别非常大。原因有几个第一超长上下文的性能衰减。业界普遍观察到模型在长上下文后段的检索准确率会明显下降。有研究结论指向一个现象当信息位于长上下文的中后部时模型找到它的概率显著低于放在开头或结尾。简单说你把关键资料塞在 100K Token 的中间位置它可能压根看不见。第二输出 token 也要占用窗口。很多人在计算上下文时只算输入忘了模型回答的内容也在窗口范围内。设置超长输入导致留给输出的空间不足回答到一半被截断这种问题在长文档总结场景特别常见。第三成本是二次增长。注意力机制的计算复杂度大约是 O(n²)输入序列翻倍计算开销可能涨四倍。虽然实际工程上有各种优化但窗口越长单价越贵的趋势不会变。所以我给团队定的一个经验值是除非业务硬性要求否则输入控制在窗口标称值的 1/4 以内。128K 标称窗口实际规划按 32K 算上下文的关键信息尽量放在开头和结尾两个区域。2.3 超长上下文的海市蜃楼位置编码的局限你可能要问厂商都在宣传超长上下文技术上到底卡在哪核心瓶颈之一是位置编码。Transformer 本身不感知顺序需要给每个 token 加一个位置标记。早期的绝对位置编码对长度有限制后来有了相对位置编码、旋转位置编码RoPE等一系列方案把支持长度不断推高。但位置编码只能解决模型认不认得这么长的序列的问题解决不了模型能不能有效利用这么长的序列的问题。注意力矩阵在长序列上的稀疏化以及信息之间的相互干扰会随着长度加剧。我用一个生活化类比给你一张写满 10 万字的小字纸条不是说你不能读而是读到第 8 万字的时候前面写了什么早就模糊了。模型也一样它读得完但用不好。所以对绝大多数业务场景我不建议走把全部资料塞进上下文这条路。它看起来简单短期能跑通但到资料量上涨、问答精度要求提高、成本敏感的时候一定会逼你回头做检索方案。这个方案就是 RAG。3. RAG 实战拆解给大模型装外挂大脑3.1 RAG 的完整链路检索、增强、生成RAG 全称 Retrieval-Augmented Generation核心思想很简单模型不需要记住所有知识你给它提供一个可以查的资料库让它根据当前问题先去检索把检索到的相关片段拼进提示词再基于这些片段生成回答。链路分四步先切分知识库文档再把每个片段做向量化并存入向量数据库用户提问时把问题也向量化去库中做相似度检索取回 Top-K 个相关片段接着把片段内容按一定格式组装进提示词最后交给大模型生成答案并要求它只基于给定片段作答。这套架构最大的价值在于知识更新成本极低。模型参数不需要重训资料库改了、删了、加了重新切分入库就行。对于企业知识库这类高频变动的场景RAG 几乎是唯一实用的方案。3.2 文档切分Chunking第一步就决定成败我刚接触 RAG 时以为检索是重头戏后来才发现切分策略才是真正的隐形杀手。同一个文档切得好不好直接决定后面能不能被正确检索。切分要考虑三个问题。一是切多长太短语义不完整太长噪音多、向量表达被稀释。我的经验是中文按 300~500 个字符切一个块英文按 200~300 个词切同时设 10%~15% 的重叠避免把完整句子拦腰截断。二是按什么边界切优先按章节标题、段落空行切而不是死板地按字数砍。Markdown 文档可以用标题层级做边界PDF 可以用段落边界。三是特殊内容怎么处理表格、代码块、列表项往往需要单独处理——比如把表格的每一行转成字段名值的句子这样向量化才有意义。我之前做一个产品手册问答项目最初按 500 字硬切结果检索出来的片段经常是半句话模型只能瞎猜。改成按章节切分后准确率一下子从 60% 出头提到了 80% 以上。这一步听起来不酷但确实是性价比最高的优化点。3.3 向量检索与 Top-K别迷信相似度分数检索阶段的核心组件是 embedding 模型和向量数据库。Embedding 模型把文本映射成几百到几千维的向量语义相近的文本在向量空间里距离更近。向量数据库负责存这些向量并快速找离问题向量最近的几个。这里有一个常见误区认为相似度分数越高结果越可信。实际上不同 embedding 模型的分数分布天差地别有的模型分数普遍在 0.8 以上有的在 0.5 左右跨模型比较没有意义。你更应该关注的是相对排序——Top-5 里前两名和后三名是否拉开明显差距。如果分数挤成一团说明检索本身就没区分度这时候调 Top-K 意义不大得回头看切分策略或者 embedding 模型选型。关于 Top-K 选择我的建议是从 3~5 起步。K 太小容易漏K 太大噪音太多而且会挤占上下文空间、拉高成本、增加幻觉概率。一个稳当的做法是先跑 50 条真实问题记录统计每次命中答案片段所在位置再据此调整 K 值。没有这个评估过程拍脑袋定的 K 都是玄学。3.4 重排序Rerank检索精度不够时加一道保险向量检索本质是语义粗筛它在词面匹配和精细语义理解上都可能出错。比如用户问退款多久到账知识库原文是资金将在 3~5 个工作日内原路返回向量相似度可能不高但语义确实相关。这种场景只靠向量检索容易漏。解决办法是加一个重排序模型Reranker。流程是先用向量检索取回 Top-50 个候选片段再用 Reranker 对这 50 个片段和问题做精细的交叉编码打分取前 3~5 个进上下文。重排序模型的计算成本高但只对候选集做整体开销完全可以接受。实测里加上 Reranker 之后不少项目的检索命中率能提升 10~20 个百分点。不过需要提醒的是Reranker 并不能解决库里没有答案的问题。它是锦上添花不是雪中送炭。基础切分和 embedding 选型没做好之前别急着上 Reranker。4. 实操案例两个项目的选型与落地记录4.1 案例一客服知识库问答RAG 主导某个电商项目的客服知识库大概有 2000 篇操作手册和售后政策文档用户问题以怎么办、怎么退、多久到为主。我们采用的就是完整 RAG 流程把文档按章节切分成平均 400 字的块标题层级做边界embedding 模型选择了中文表现稳定的通用向量模型向量库用了常见的开源方案检索时先取 Top-20过一个重排序模型再取 Top-3 进提示词提示词里明确要求模型只依据检索片段回答如果片段中没有信息直接说不知道。落地效果90% 以上的常见问题能给出正确步骤或政策条款引用剩余的边缘问题大部分是文档本身信息缺失导致的而不是工程问题。项目成本方面单次问答的向量检索耗时在 100 毫秒以内大模型生成答案的 token 消耗也因为我们严格限制检索片段长度控制在了比较理想的水平。4.2 案例二长合同风险分析Context 主导另一个场景是长文档分析几千页的合同 PDF需要判断里面有没有约定不明的条款。这类任务的难点不是找某个事实而是通读全文并做全局判断。RAG 的片段式检索在这里反而不够用——你要的不是某一片段而是全貌。我们的方案是分段总结再汇总先把全文按章节切块每块单独交给模型生成结构化摘要再把摘要汇总成一份完整的文档风险评估报告最后让模型基于汇总结果回答具体问题。在这种任务里Context 窗口是够用的——因为进入窗口的是摘要而不是原文信息密度被大幅压缩了。这个思路的关键是不是所有任务都适合 RAG也不是所有任务都适合整篇灌上下文。任务类型决定了方案。4.3 选型决策表什么时候用 Context什么时候上 RAG我把自己的判断标准整理成了一张表供你参考场景特征推荐方案原因单次输入信息量可控且与全部上下文强相关直接塞 Context简单直接无需维护检索链路知识库大、更新频繁、问题侧重事实查询RAG更新成本低可溯源性价比高需要全局理解的长文档总结分段摘要 Context 汇总避免检索碎片化保留全局信息既有事实查询又有全局判断的混合需求RAG 分段摘要混合用 RAG 答事实用摘要回答需要全局的问题这张表不是一个严格的公式但能帮你在一开始就避开选错方案、后期返工的坑。我见过不少团队一上来就搭 RAG结果知识库只有几十篇文档直接灌上下文又快又准也见过强行用长上下文死磕百万级知识库的成本高到不敢放开用。先想清楚场景再选工具永远不亏。5. 常见问题与排查技巧实录5.1 检索结果不准优先排查这三处问题检索出来的片段跟问题毫不相关或者看起来相关但用不上。排查顺序我建议固定为先看切分是否破坏了语义边界再看 embedding 模型和知识库语言是否匹配中文文档一定要用中文表现好的模型最后看是不是问题本身太短、太口语化导致向量表达不准。如果问题太短可以做一步问题改写——先让模型把口语化问题改写成适合检索的书面表达再去做向量化。这个技巧在很多项目里都有效。另一个高频坑是检索结果准确但模型答得不对。这种情况九成出在提示词上。如果提示词没有强调只依据给定片段回答模型会忍不住使用自己的内在知识作答而这些知识可能是过时的、虚构的。我建议在提示词里写清楚信息来源于检索片段片段没有覆盖的部分必须明确说明资料中未找到相关内容禁止自行推断。5.2 上下文与成本失控预算的三三制长上下文项目里成本失控是最常见的翻车点。我总结了一个三三制预算方法把一次调用的总 Token 预算分成三份——输入指令和检索片段占三分之一历史对话摘要占三分之一输出留三分之一。这个分配不是绝对比例而是一个提醒要时刻注意输出空间是否被输入挤占。另外历史对话的处理也有技巧。直接把所有历史消息拼进上下文是最蠢的做法。我习惯用滑动窗口只保留最近 2~3 轮完整对话更早的历史压缩成一句用户之前提到过……的摘要。这种摘要 近轮原文的结构既保留关键背景又控制 token 开销实测效果远比全量拼接好。5.3 幻觉能靠 RAG 根治吗清醒一点最后聊一个大家最关心的问题RAG 到底能不能解决幻觉我的结论是能大幅缓解不能根治。缓解在哪如果提示词约束到位模型会把回答锚定在检索片段上不再是纯靠概率外推答错的概率显著下降。不能根治在哪第一检索片段本身可能包含过时、错误、互相矛盾的信息模型无法替你判断真假第二模型为了凑一个完整回答可能在片段之外、在过渡性语言里加入自己的发挥第三如果用户的问题在知识库里没有对应内容而你的提示词约束不够硬模型照样会编。所以RAG 项目上线前一定要做无答案拒答测试。准备一批知识库覆盖不到的问题看模型会不会诚实地说不知道。一个合格的 RAG 系统应当有胆量说不知道而不是为了显得聪明而编造。这个测试应该作为验收标准写进项目里。按我个人经验把上面这些基本功做好一个 RAG 项目从能跑到好用差的其实不是模型选型而是对切分、提示词、评估这三件事的认真程度。上下文窗口再大也装不下一个不思考的工程方案。希望你读完这篇再去审视自己的项目时能清楚地说出我的方案到底是靠 Context 硬记还是靠 RAG 外挂以及它们各自承担的职责是什么。想清楚了这一点你踩过的坑都会变成判断力。
