Tealium：为什么 RAG 质量取决于实时数据

Tealium应用人工智能部门首席产品经理弗雷迪·贝尔兰蒂（Freddy Berlanti）深入探讨了检索增强生成（RAG）技术。图片来源：Getty Images

Tealium应用人工智能首席产品经理弗雷迪·贝尔兰蒂，剖析了真正创造价值的RAG系统与那些悄然破坏用户信任的RAG系统之间的关键分水岭

大多数企业级检索增强生成（RAG）系统仅能获取客户的“快照”：上周二索引的向量存储、夜间同步的知识库，或是反映用户12小时前状态的用户画像。正是这一差距，将真正有效的RAG系统与那些悄无声息地侵蚀用户信任的系统区分开来。

周四晚上8点47分。一位客户将另一件商品加入购物车，使总金额超过了免运费门槛，随后打开客服聊天窗口询问是否包含运费。

客服代表在几毫秒内就做出了回应。回答流畅、礼貌、引用充分——但却是错误的——因为系统检索到的用户画像是在购物车内容发生变化之前生成的。等到批量索引的数据更新完毕时，本应提供信息的那一刻早已过去。

这场交互由两个截然不同的指标主导，但大多数生产系统只衡量其中一个。响应延迟是指提问与回答之间的时间间隔，团队们对此进行着近乎痴迷的追踪。而“信息时效”——这一由 Kaul、Yates 和 Gruteser 正式提出的指标——则衡量系统根据某项事实采取行动时，该事实的过时程度。 简而言之：你在使用该上下文时，它已经过时多久了？

在这个例子中，响应延迟不到一秒，但信息却已有数小时之久。系统虽然响应迅速，却未能保持信息的新鲜度。而仪表盘上只显示了其中一个数值。

这一区别至关重要，因为基于过时客户数据给出的快速回答，终究是错误的答案。对于面向客户的RAG而言，速度和时效性是两个不同的问题，优化其中一个并不能保证另一个。

二者相互独立，在高负载下甚至可能背道而驰。更新频率更高并不总是意味着信息更新鲜。超过一定阈值后，更新会积压，导致可用的最新事实反而变得更旧，而非更新。夜间批处理不过是极端案例：系统基于一天前的世界视图进行运作。 解决之道并非在同一时间表上传输更多数据，而是要在变化发生时实时传输关键变更——这需要一种不同的架构，而不仅仅是更快的架构。

RAG之所以能脱颖而出，正是因为它解决了“闭卷”问题。系统不再仅凭记忆作答，而是先检索相关资料，再根据检索结果作答。这些资料就是语料库。只要语料库构建得当，模型就不会再“即兴发挥”。

对于内部知识助手而言，一个在夜间同步的语料库已足够。但客户在交互过程中的需求则是另一个问题。购物车金额刚超过阈值，客服人员必须当即决定是提供免运费还是暂缓处理。 黎明前捕获的快照并非日后可通过调优解决的限制；这本身就是错误的架构，因为等到批量索引的数据跟上时，本应由其提供决策依据的时机早已错过。

批量 RAG 检索的是记忆；实时 RAG 检索的是客户

这些故障虽小，却合乎情理且具有侵蚀性。它们极少触发警报或引发错误报告；用户只是逐渐学会不信任该系统，并停止使用它。等到这些情况在仪表盘上显现时，看起来就像是缺乏明显原因的系统采用率问题。

解决之道始于任何工具决策之前。它是一份针对每个用例制定的服务级别协议（SLA），旨在回答三个问题：上下文信息必须有多及时？答案必须多快到达？系统应在何时停止并把对话交由人工处理？

购物车状态需要秒级更新。产品内容可容忍分钟级更新。政策更新则可以每天一次。这些数值不再是个人偏好，而是变成了设计约束：它们决定了架构，也决定了成本。常见的错误是将数据时效性视为一个单一的全局设置，并将其均匀地应用于所有场景。 时效性就是一笔预算。将其投入到能影响决策的地方，而在无法影响决策的地方则停止为此买单。

对于面向客户的客服人员而言，数据集就是客户本身。

这意味着身份信息在不同设备和渠道间得到统一识别，因此所有接触点都被视为同一个人。这意味着同意权与个人资料本身绑定，因此每个下游查询都由系统结构本身授权，而不是依赖于某人希望用户已阅读的政策文档。

这也意味着放弃夜间重建。变更数据捕获（即仅流式传输变更内容而非重新加载全部数据）的做法，能在数秒内重新嵌入单个用户档案，而非重新处理数百万个档案。 随后，检索采用混合模式：通过稠密向量搜索提取语义，通过关键词搜索定位关键的精确字符串（如 SKU 和订单号），两者根据排名融合，并对最终候选结果进行重新排序。 热层和冷层确保成本合理，因此您只需为真正影响决策的少数几个属性购买二级时效性，而其他所有内容则保持每日更新。

始终保持最新的技术栈（从左到右阅读），下方是度量循环

手动将每个代理连接到每个数据源会形成一张集成网络，其中每个集成都涉及独立的身份验证、模式变更和故障点。正是这种复杂性，导致许多前景良好的试点项目难以实现规模化。

模型上下文协议（MCP）作为连接代理、工具和数据的开放标准，将这一接缝转变为接口。 只需将数据源连接一次，任何符合标准的代理都能自动发现它，并附带相应的数据模型和权限。数据源前方设有一个网关：验证传入调用、根据同意进行信息屏蔽，并记录审计日志。正是这看似不起眼的一半，才让你得以投入生产环境。

若无衡量标准，这一切都将无从谈起，而仅凭一个数字也远远不够。一个满意度评分能告诉你出了问题，而三个独立的仪表盘则能指出具体问题所在。

检索质量考察的是你是否获取了正确的上下文：上下文精确度、上下文召回率、过时延迟。回答这些问题无需任何模型。生成质量考察的是模型是否忠实地利用了所接收的内容：答案相关性和引用覆盖率，由参照人工评审标准进行校准的评委进行评分。 业务成果则考察上述环节是否真正产生了实际影响：解决时间、问题遏制率、成本、客户满意度（CSAT）。将这些指标独立追踪，当某项指标下滑时，就能直接锁定需要改进的层级——无论是数据、模型还是工作流。

三个仪表盘：指标下滑会告诉你该修复哪个层级

接下来，小范围发布。针对真实流量测试一个受限用例，不断调优直至满足你设定的SLA（服务水平协议），并在启用升级处理机制的前提下提供服务，只有在此之后才进行扩展。停滞模式则恰恰相反，而这正是当前业内最常见的项目形态：先有工具，后有数据，指标则永远缺失。

模型的改进对所有人而言都是同步生效的。无论本季度前沿版本为你带来了多少竞争优势，你的竞争对手下个季度就能按市价买到同样的优势。但他们无法买到的，是你的代理在响应瞬间所获取的上下文中的“货币”、治理机制以及身份。

模型是大脑，上下文是记忆。其中只有一样属于你。请阅读完整的电子书。