生产环境的 RAG：真实客户开始提问时，究竟什么会崩

一个能跑的检索增强生成（RAG）演示，一个下午就能搭好。把几份文档做成向量、扔进向量库、按余弦相似度取回前五个片段、粘进提示词。它能回答问题。录成屏幕视频，看起来像变魔术。

然后你把它摆到真实客户面前，鸿沟就出现了。

有人用你支持的第三种语言提问。有人问到一条政策，而这条政策在你自己的网站上存在两个互相矛盾的版本。有人问了一件你的内容根本没覆盖的事，系统照样回答——流畅、笃定、错误。重新抓取正在跑，同时二十个人一起提问。一份扫描件而非录入的 PDF 变成检索噪声，悄悄污染它周围的每一条回答。

这些在演示里一个都不会出现，因为演示用的是干净文档、一种语言、一个用户，以及搭建者本人早就知道答案的问题。RAG 里所有昂贵的部分，都住在这两种情形之间的距离里。

这篇文章讲的就是那段距离。它默认你已经知道 RAG 是什么——如果还不知道，先读我们的什么是 RAG 聊天机器人、它如何工作，再回来。接下来要谈的是更上面那一层：决定一个检索系统能否扛住真实用户的工程。

每当上下文窗口变大，就有人宣布 RAG 过时了。这并没有发生，原因是结构性的，而非暂时的。

可用上下文比标称上下文小。 一个能接收 20 万 token 的模型，并不会在全部 20 万 token 上同样地好好推理。这个效应有据可查：Liu 等人 2023 年的《Lost in the Middle》显示，被埋在长输入中段的信息，准确率明显下滑；此后每一代长上下文模型都带着同样意味的提醒发布。质量的衰减比硬上限来得更早。而一家中型公司真实的知识库不是 200 页，而是数万页。

微调改变的是行为，不是知识。 这是这个领域里最昂贵的误解。微调非常适合教模型一种格式、一种语气、一种推理模式；用来教事实则既薄弱又不可靠，而且一旦事实变化就迅速退化——价格、政策、库存这些事实每周都在变。

成本朝错误的方向扩展。 把整个语料塞进每一次请求，意味着每问一句都要为整个语料付费；检索则只为相关的几千 token 付费。在任何真实的消息量下，这个差额就是全部毛利。

可审计性是硬性要求，不是加分项。 在金融、医疗和法律领域，一条无法追溯来源的回答就是不可用的。检索天然产出这条线索，因为系统本来就知道每一段文字出自哪份文档。

所以真正值得问的，早已不是「要不要做检索」，而是「为什么这么多检索系统做得这么差」。

回答质量差，最常见的原因既不是模型，也不是向量表示，更不是向量数据库，而是语料本身。

我们见过一个客户的知识库，大约一半文档是另一半的近似重复：同一条政策以微小的格式差异，分别发布在营销站、帮助中心和一份归档 PDF 上。检索尽职地返回五个片段，但那是同一段话的五份副本；模型看到的是一条狭窄的证据切片，而不是五种视角，top-k 的预算全花在冗余上。修它是毫无光环的手工数据管道活儿，却比那个月做的任何检索调参都更明显地提升了回答质量。

反复出现的惯犯：

• 扫描版 PDF 与 OCR 损伤。 人眼读起来没问题的文字，结构上可能已被撕碎：分栏顺序错乱，表格被压成词汤。破碎文本的向量会以不可预料的方式被检索出来。
• 模板文字与同意横幅。 天真地抓取一个网站，每个页面都会带上同样的 Cookie 提示、同样的导航和页脚。于是所有片段共享一大段完全相同的前缀，毫不相干的页面之间语义相似度反而上升。这正是我们的爬虫在索引任何内容之前，先剥掉同意提示和页面框架的原因。
• 登录墙与空洞页面。 登录页也有文字，天真的流水线照收不误。它什么都不贡献，却稀释了一切。
• 没人注意到的自相矛盾。 两个页面写着不同的退货期限。检索把两个都找出来，模型挑一个。无论挑哪个，都会有人被告知错误的信息。

实践规则：质量闸门要放在索引之前，放在代码里的唯一一个位置，并且所有能添加内容的路径都必须经过它。当入库规则散落在三个地方，它们必然漂移，于是「从引导流程进来的内容」和「重新抓取进来的内容」质量为何不同，就成了没人复现得了的谜。实操版本请看我们的如何搭建干净的知识库。

单次稠密向量检索只是检索的初稿。生产环境里的检索是一条四到五级的流水线，每一级都在修复其他级够不到的失效模式。

查询扩展。 真实用户的查询很短、有错别字，还塞满内部黑话。在做向量化之前，用同义词和展开的缩写扩展查询，可以带来可测量的召回提升——尤其是那些主导真实聊天流量的两三个字的问题。

混合检索：稠密加稀疏。 稠密向量抓语义，却抓不住精确 token：货号、错误码、型号、人名。关键词检索（我们用的是 Postgres tsvector 上的 BM25）恰好命中这些，却抓不住改写表述。两条同时跑，再用倒数排名融合（RRF）合并结果，这是生产环境的默认配置，而不是一项优化。

有一个细节的重要性被严重低估：关键词检索是与语言绑定的。 只有当你告诉 Postgres 这段文本是英文时，它才会把「prices」还原成「price」。土耳其语、德语、西班牙语、法语、意大利语和葡萄牙语各自需要自己的配置；而没有内置词干还原器的语言——日语、韩语、中文——需要的是有意为之的降级策略，而不是碰巧如此。一个把所有查询都按英文做词干还原的多语言 RAG，会在其余每一种语言里悄悄丢失召回。如果你服务多个市场，请把本节和我们的多语言聊天机器人指南一起读。

重排序。 融合之后你会得到二三十个看上去都合理的候选。交叉编码器重排序模型会针对真实查询逐个打分，经常把真正正确的那一段从第 15 名提到前三名。如果你的系统「老是引用一个差不多但不对的页面」，第一个要查的就是缺失的重排序环节。

缓存，但要小心。 完全相同的问题不该把整条流水线再跑一遍。但缓存的应该是检索结果（以查询加 top-k 为键），而不是生成的回答；否则在底层文档更新之后，你会继续端出过期的答案。

任何认真的 RAG 系统都会在生成之前给检索结果打分，并用这个分数告诉模型该多大程度上信任上下文：直接回答、带保留地回答，或者干脆不答、转人工。这是现存最重要的一道防幻觉措施。

它同时也是最可能设错的参数，因为默认值往往是拍脑袋定的，而不是量出来的。

下面是一个值得学习的错误——我们自己的。我们的「高置信度」阈值定在余弦相似度 0.82，这个数字听上去足够严格。后来我们拿真实流量去对照，发现真实回复里跨过这条线的不到 2%。稠密语义匹配即便在取回的段落明显、精确正确时，也很少超过大约 0.80。也就是说，模型在几乎每个问题上都被告知「这段上下文只是部分相关」，于是它开始打太极：正确的答案被包裹在不必要的不确定里。检索本身没问题，出问题的是那把尺子。

修法不是把一切都放宽。我们从模糊区间里抽出真实对话样本逐条阅读：在 0.64 到 0.68 之间，回答具体且正确，能准确引用套餐额度和政策条款；但真正的知识空白——关于我们并不支持的某个集成的问题——分数落在同一区间，并且理应保持谨慎。于是我们把高位阈值下调到真实匹配够得着的水平，把模糊的中间带继续标为「部分」，而底部那道「不得编造」的护栏则原封不动。

可迁移的经验：按你自己的分布校准阈值，而不是凭直觉；亲自去读你正在调的那个区间里的真实对话，因为汇总分数会掩盖「好回答」和「高分错答」之间的区别；以及把每个阈值都做成环境变量，这样一次错误的校准只是一分钟的回滚，而不是一次发布。

切块看起来像个排版决定。它其实是个检索决定，而且「文档里明明写了，机器人却找不到」这类抱怨中，相当高的比例就来自这里。

每 500 个 token 定长切一刀，会把表格拦腰砍断，把标题和它引出的段落分开，把编号步骤切到两个片段里、结果哪一个都单独不可用。结构感知的切分——先尊重标题和段落边界，再向目标大小合并，最后在句子边界切开过长段落——实现成本约一天，回本立竿见影。我们自己的流水线以每块约 800 token、重叠 200 token 为目标，对以行文为主的商业内容而言是个合理起点。

更微妙的问题是：片段一旦被孤立，就失去了让它有意义的上下文。「标准配送需要 3 到 5 个工作日」如果没写清是谁的配送、哪个地区、哪条产品线，作为检索目标毫无价值。被单独取出时，模型完全可能把它套到另一个问题上。

解决办法是在向量化之前，用片段自身的出处去增强它——文档标题、章节标题、来源——让被嵌入的文本携带上人类读者从整页里获得的那份上下文。Anthropic 把这一思路以「contextual retrieval」的名字推广开来，并报告检索失败率大幅下降。而且不必经过一次大模型调用才划算：用文档自身元数据拼出的确定性前缀，就能以零边际成本拿到其中大部分收益——这也是我们在生产中运行的做法。

一条来自经验的警告：一旦改变切块或上下文增强策略，你就同时买下了一次数据迁移。所有既有片段都是按旧方案嵌入的。请规划按文档定点重建索引，绝不要对生产语料做盲目的全量重嵌。

团队争论的是检索质量，真正把系统放倒的却是可靠性。

入库是一个耗时长、多阶段、部分依赖外部服务的过程：抓取、抽取、切块、向量化（一次可能触发限流的付费 API 调用）、写入、标记完成。任何跨网络边界、持续数分钟的流程都会被打断，而这种打断并不罕见。

对我们最有教育意义的一次故障是无声的。一位用户启动了网站抓取，然后离开了页面。处理她请求的无服务器函数在半空中被终止——片段和向量已经写入，但文档还没被标记为已处理。没有异常，监控里也没有报错。留下的只有一份其实已经完整索引、却永远显示「正在索引」的文档，以及一位在十九个小时里把同一个站点重新抓了四遍、只为让一个状态标签变一变、最后离开的用户。

这类缺陷教会我们三条值得照搬的不变量：

• 安排写入顺序，让用户可见的事实最先落地。 内容持久化写入之后立即翻转「已处理」标记；统计、缓存失效和其他记账动作放在后面，每一项都设上限、尽力而为即可。绝不要让一个可选步骤卡在真实工作和记录它的那个标记之间。
• 让每个任务处理器幂等，然后大胆地重新入队。 如果 worker 中途死掉，下一次巡检必须能安全地把整个任务重跑一遍。「先删后插」式的处理器让重试变成免费的。
• 加一个自愈巡检。 一个定期任务，负责找出卡在未完成状态的文档并重新入队，就能把一个永久且用户可见的故障，变成几分钟的延迟。这是 RAG 流水线里投入产出比最高的一项可靠性工作，而几乎没有人会在被烫到之前就把它建好。

在并发压力下，也别忘了那些无聊的基础设施：用真正的队列取代「发完就忘」的 promise；连接池上限要把「向量化调用会长时间占住连接」算进去；以及租户隔离，好让某一个客户 900 页的抓取，不会饿死其他所有人的实时对话。

RAG 的质量没法靠肉眼判断。每个团队都相信自己可以，每个团队都错了——因为糟糕 RAG 的失效形态，是一条流畅、可信、排版整齐、恰好是错的回答。它读起来和好答案一模一样。

最小可用的评估配置比大家担心的要小：

一套黄金集。 三十到一百个有已知正确答案的真实问题，取自你真实的客服历史，而不是凭空编造。每次修改检索、切块、提示词或模型版本之后重新跑一遍。这是回归测试，它应该大声地失败。

把检索评分和回答评分分开。 质量下降时，你需要知道是正确段落没被检索到，还是被检索到却被忽略了。二者的修法完全不同，一个端到端的总分区分不出来。

长期监控置信度分布。 检索得分直方图的漂移是一个早期预警——通常意味着有人批量导入了低质量内容，或者流量转向了语料没有覆盖的话题。

把「我不知道」当作最有价值的遥测数据。 每一条低置信度回答、每一次转人工，都是一个已经打好标签的内容缺口。那些助手在数月里肉眼可见地变好的团队，几乎无一例外，都是每周读这份清单、并把缺失的那一页补写出来的团队。我们的聊天机器人分析指南介绍了值得盯的指标。

还有，请诚实地衡量工单转移率。一段对话不是因为客户停止打字才算解决，而是因为他一小时后没有给你发邮件才算解决。如果你的平台无法把这两个事件连起来，那你优化的只是一个让自己好看的数字。

两套架构完全相同的 RAG 系统，在同一个行业里可以一个成功一个失败。差别通常不在流水线里。

领域语言是实打实的工作量。 医疗缩写、金融产品名称、法律引用格式、货号命名习惯，各自以特有的方式击穿通用检索。金融客户问「三年期的那个」，指的是一款具体产品；通用向量却在想时间。修它靠的是同义词词典、元数据过滤，以及既写给人也写给机器的内容，而不是更大的模型。

范围纪律胜过能力。 摧毁用户对助手信任的最快方式，就是让它回答它其实并不掌握的问题。一条明确的边界——本智能体只回答我们的产品、政策和文档相关问题，其余一律转人工——比任何检索优化都更能减少尴尬回答。这也是我们在看到真实助手漂移到空泛无用的领域之后所做的修正。

落地是上线条件之一。 一个客服团队事先毫不知情的助手，最终会被客服团队架空。必须有人认领内容缺口、阅读转人工记录，并决定这个助手可以承诺什么。

企业信任是有清单的。 基于角色的访问控制，让检索尊重「是谁在问」；审计轨迹，能显示哪条来源产出了哪条回答；明确的数据存放地；留存策略控制；以及一句毫不含糊的声明：客户对话不会被用于训练公开模型。这些不是安全评审之后再补上的功能，它们本身就是评审能否通过的原因。我们的聊天机器人安全与隐私指南逐项说明该向供应商核实什么。

如果你打算自建，诚实的范围不是「一个向量库加一段提示词」，而是：一道内容质量闸门、一条多级检索流水线、经过校准的置信度阈值、一套带幂等处理器和自愈巡检的任务队列、一套评估工装、一条数据分析闭环——再加上这一切的长期运维。当检索质量本身就是你的产品时，这值得做；当检索只是回答客户问题的手段时，把一个小团队的一年投进去并不划算。

如果你打算采购，本文的清单就是你的尽调问题表。问供应商：你们用的是混合检索还是只有稠密检索？有没有重排序环节？「我不知道」的阈值怎么定，我能不能改？入库过程中途中断，文档会怎样？我能不能看到某条回答是由哪份来源生成的？在我的语言里关键词检索会怎么处理？上周助手有哪些问题没能回答？答不上这些问题的供应商，做出来的是演示。

这正是 Chatloom 存在要扛起的那一层。全文描述的这条流水线——带上下文增强的结构感知切块、查询扩展、带语言感知词干还原的稠密加稀疏混合检索、RRF 融合、交叉编码器重排序、带真正「我不知道」的校准置信度、配有自愈巡检的幂等入库任务，以及一块能准确告诉你哪些问题没被回答的看板——就运行在平台上每一个智能体背后，覆盖十种语言，而且你这一侧不需要任何机器学习团队。

今天就拿你自己的内容试一试。 免费注册一个账号，粘贴你的网站地址，看着整条闭环跑完——抓取、质量闸门、切块、向量化、混合检索——所花的时间大约和你读完这篇文章差不多。把客户真正会问的五个问题丢给它。如果回答都扎根在你的内容里，并且不知道时会坦白说不知道，那你的评估就已经完成了。免费套餐无需绑定银行卡。

想先看细节？了解我们的 RAG 引擎如何工作，或阅读实操姊妹篇如何用自己的数据训练助手。