记忆、评估、护栏

我做的第一件事，是拒绝把记忆当成一件东西。「记忆」其实是四个不同的问题被安上了同一个名字，它们的存储方式不同、生命周期不同、失败模式也不同。

第一，我们刚刚说了什么——最近几轮对话。第二，整个会话里发生了什么，这部分必须能扛住服务器重启。第三，关于这个用户或这个实体，我们知道哪些应当比会话活得更久的事实。第四，哪些内容我们此前已经答过，好让我们不必为同一次计算付两次钱。

所以我把每一类分开设计，并且对每一类都写清三件事：存在哪里、活多久、记错了会怎样。最后一条最重要。错误的记忆比没有记忆更糟，因为系统会带着十足的自信把它说出来。

我按内容的产出者来划分。检索读的是别人拥有的事实来源——在我的项目里就是公开发布的年报。记忆读的是我自己的系统产生或推断出来的东西。

这条线之所以重要，是因为信任级别不同。来自年报的一个数字是我可以带着页码引用的事实。来自我自己此前答案的一个数字只是一项主张，而且它当初就可能是错的。

所以检索到的内容可以直接进入答案并附上引用。记住的内容则必须打上标签，而且我得随时愿意把它扔掉、重新检索一次。

所谓 上下文窗口（context window） ，是模型一次调用中能读取的文本上限——对现代模型来说大约相当于几百页，但它是一道硬天花板，而且你放进去的每一样东西都要花钱、都要加延迟。

最朴素的做法是把一切都发过去：完整对话历史、全部检索到的文档、全部记忆。这会以两种方式失败。它会撞到天花板；而且远在撞到之前，质量就已经下滑了，因为那句关键的话被埋在成千上万句无关内容之中。

所以我把上下文拼装当成一份显式、有序的预算，而不是一次拼接。优先级最高的是当前问题。然后是我确实为它检索到的证据。再然后是较早对话的一段简短摘要。记忆提示放在最后，空间不够时它们最先被丢掉。

关键在于，这个排序是一个我能辩护、也能测试的设计决策——而不是代码碰巧最后拼上去的顺序。

最简单的办法是滑动窗口：只留最近 N 条消息，其余丢掉。它只要一行代码，但对我们这个场景是错的，因为用户会说「把那个和 Rio 比一下」，而被比较的那个东西已经被丢掉了。

我用的是摘要缓冲区。当历史超过阈值时，我把除最近几条之外的全部内容交给模型，让它压成两三句话，删掉原始消息，再把摘要插回它们的位置。

这样最近几轮保持逐字原样，因为代词和追问指向的正是那里。较早的轮次则以压缩痕迹的形式留存，而不是凭空消失。

一条重要的安全规则：如果摘要调用失败，我什么都不做，保留原始消息。一次失败的压缩绝不能删掉历史。

普通缓存匹配的是完全相同的字符串。这对自然语言毫无用处，因为「BHP revenue in FY2024」和「How much did BHP earn in FY2024?」是两个不同的字符串，问的却是同一件事。

而 语义缓存（semantic cache） 通过比较含义来解决这个问题。我把问题转成一个 向量（embedding） ——一串代表其含义的数字——再拿它和历史问题的向量比较。相似度足够高，我就复用旧答案。

在这种领域里它帮助很大，因为少数几个问题就覆盖了大部分流量，而每一次未命中都要付出好几次模型调用外加一次检索的代价。

它害你的地方在「差一点」。「BHP revenue FY2024」和「BHP revenue FY2023」作为句子几乎一模一样，作为问题却完全不同。阈值调得太松的缓存，会自信满满地给出错的年份。这就是我不用一个阈值、而用两个阈值的原因。

这就是 指代（coreference） ——这句话指向的是之前提到过的东西，而不是把它说出来。如果你原样送去检索，你就是在没有公司、没有年份的情况下搜「dividends」这个词，结果拿回五家公司的噪声。

有两种修法。你可以让模型结合历史把问题重写一遍，它什么情况都能处理，但要多一次调用，而且可能幻觉出一家从没被提过的公司。或者你把你关心的那些具体实体往下带，这很便宜也可预测，但只覆盖你列出来的实体。

我选了便宜的那个，因为在这个领域里，歧义几乎永远落在同样两个槽位上：哪家公司、哪个财年。我扫描最近的消息找股票代码和年份，如果当前问题缺了其中之一，就把找到的补上去。

它是刻意做窄的，而且我会为此辩护：它是确定性的、可测试的、不增加延迟，而且如果什么都没找到，它就什么都不改。

四层，而且每个请求在任何检索发生之前，都会按固定顺序穿过它们。

第一层，持久会话状态。整个图状态在每一步之后都会以线程 id 为键检查点写入 PostgreSQL。所以一次对话能扛住服务器重启，而且我可以精确重放系统在每一步看到了什么——这既是记忆能力，也同样是一项审计能力。

第二层，上下文压缩。一旦历史超过十条消息，较早的那些会被摘要成一条笔记，最近四条逐字保留。

第三层，实体延续。我从最近的消息里抽出公司股票代码和财年，如果当前问题缺，就补上去。

第四层，语义答案缓存。过往的问答对存在它们自己的向量集合里，和年报切块分开。相似度高于 0.95 时我直接返回存下来的答案、完全跳过检索。在 0.80 到 0.95 之间，我跑完整条流水线，但把旧答案作为上下文喂进去。

因为查找的时候我手上只有一个问题。如果存下来的向量代表的是一个答案，那我就是在拿问题去比对答案，而这两段文本即便本就配对，看起来也很不一样。

问题短、是疑问句；答案长、满是数字和限定语。它们的向量落在不同区域，所以相似度分数会变得嘈杂、不可靠。

所以我把问题存为可检索内容，把答案和它的来源作为元数据挂在旁边。这样就变成了问题对问题的匹配，而这正是我真正想要的那次比较。

写入是有闸门的，不是自动的。只有同时满足两个条件，答案才会被保存：质量评分器判它通过，并且有据性（groundedness）检查没有返回「no」。

有据性的意思是，答案里的每一个事实都能在实际检索到的文档中找到。如果这项检查失败，答案仍然会发给用户——带一条可见的警告——但它绝不会被写进记忆。

还有一个我挺得意的细节。警告文本是在保存 之后 才追加的，所以缓存下来的是干净的答案。否则，未来的用户会收到一条陈旧的告诫，而那条告诫和他的问题毫无关系。

总的原则是：读路径乐观，写路径悲观。缓存未命中很便宜。缓存被投毒可不便宜。

第一步是别再问「这个答案对不对」，改成问「这个系统在一组固定情境下的行为是什么样」。单次运行几乎什么都说明不了，因为同样的输入可以产出不同的输出。

所以我把能固定的都固定住。一组期望已知的固定用例。凡是检查能做成确定性的，就做成确定性的。而在我必须判断某些主观内容时，我评的是答案的某个属性，而不是去匹配文本。

第二步是先评组件，再评整体。如果我只做端到端测试，一次失败只告诉我系统错了，却不告诉我错在哪。在我的项目里，我可以单独测路由、单独测检索、单独测评分器，这样一次回归就能指向某一个组件。

然后是两个阶段，不是一个。离线评估是发布前跑一组固定测试集——它能挡住已知的回归，但没法告诉你真实用户的情况。线上评估是发布后在真实流量上测量——现实是在那里到场的。两者都需要，而且离线集应当由线上发现的问题来喂养。

我把流水线拆成若干阶段，每个阶段按它自己的标准来测，因为「答案质量」根本不是一个单一属性。

路由：系统有没有正确决定是该检索、该搜网、该反问一个澄清问题，还是直接作答。这是一个有干净标签的分类问题，所以又便宜又精确。

检索：给定一个已知正确数字的问题，包含那个数字的文档有没有到达作答那一步，以及排在第几位。这项测量全程不需要模型参与。

有据性：答案里的每一项主张是不是都被检索到的文档所支持。这就是幻觉指标，也是在受监管场景里我最在意的一项。

边界行为：面对一个系统本就不该回答的问题，它有没有恰当地拒答，而不是编一个出来。除此之外还有每次查询的延迟和成本，因为一个没人愿意等的准确答案不是产品。

三件事：隔离这次改动、在同一批用例上做对比、并且对样本量能支撑多少结论保持诚实。

先隔离。如果我改的是检索，我就把模型完全从链路里拿掉，直接给检索打分。否则模型自身的方差会比我想看到的效应还大。

然后做配对比较，而不是比平均值。同一批用例，两种配置，我看的是逐个用例的变化——多少个变好了，多少个变差了，多少个是以前漏掉、现在找到的。均值可以上升，而个别用例在回归，而事件（incident）恰恰就是由这些回归造成的。

然后我把界限明说出来。大约十几个用例，我能看出方向，看不出显著性。我会把它称作「可以继续推进的证据」，而不是「证明」——而且如果这个决策代价很高，我会先去标注更多用例再上线。

离线指的是一组带预期结果的固定用例，按需运行。它可复现、便宜、安全，所以最适合用来卡发布门禁。它的弱点是里面只包含你已经想到过的失败。

线上指的是在真实流量上测量系统。通常就是一次 A/B 测试（A/B test）：一部分请求走新版本，其余走当前版本，然后比较结果。它的强项是能发现你从没设想过的问题；它的弱点是在你学习的过程中，会有一部分用户拿到更差的版本。

这两者连成一个闭环，而这个闭环才是真正的方法论。线上发现一个新失败，这个失败变成一条离线用例，离线套件因此更强。如果你的测试集只在工程师灵光一现时才增长，它就会逐渐偏离用户真正在做的事。

在真正做 A/B 之前，我会先跑影子模式（shadow mode）——新版本处理真实流量，但它的输出只写日志、不展示给用户。你能拿到真实的分布，同时对客户零风险。

这正是 LLM 评判（LLM-as-judge）老老实实讲的薄弱点，而答案是：评判者和其他任何组件一样，它自己也需要被评估。

具体做法是：我抽一批用例，自己标注一遍，然后测量评判者和我意见一致的比例。如果一致性很差，那评判者的结论就不构成证据，我也不该拿它去发版。

然后我把评判者的活儿做得尽可能窄。它从不在一个量表上给「质量」打分。它拿到的是问题、检索到的文档和答案草稿，返回的是一个严格的结构——通过或不通过，外加一份它无法核实的主张清单。受约束的输出比自由文本的意见稳定得多。

还有两点很重要。我会明确告诉它哪些差异不算「无依据」——单位不同、四舍五入、会计记法——否则一个本来完全有据的答案会被不停地标红。而且我会刻意设定它的严格程度：在通过/不通过这一档我让它宽松一些，因为那道闸门存在的意义只是拦住内容空洞的答案。

按成本把它分层，每一层按它负担得起的频率来跑。

最便宜的一层完全不调用任何外部服务。它把合成输出喂进真实的评估器代码。这并不能证明系统能工作——它证明的是我的用例格式正确、我的打分逻辑正确。它免费又快，所以每次提交都能跑。

中间那一层跑真实组件，但只跑少量用例，而且只走仍然有意义的最便宜路径。对路由，我只跑路由相关的节点，而不是整张图。这是 pull request 上的冒烟测试。

最贵的一层是对着真实服务和真实索引跑完整套件。它按计划任务跑，不是每次 push 都跑，而且结果会和一份存下来的基线比对，一旦下滑就能看见。

我会立成标准的一条规则是：发布门禁必须是确定性的。如果一次构建可能因为模型今天心情不同而失败，工程师就会学会一直重跑到变绿，这道门禁也就不再有任何意义了。

四个套件，外加一个独立的检索测评框架。路由、检索、计算和边界行为，一共大约四十条用例，存成按行分隔的 JSON 文件。

每条用例都有 id、查询、期望结果，以及一行 why_it_matters 说明它能抓住什么回归。加载器拒绝运行任何缺少其中一项的用例，所以这个套件不会悄悄塞满没人看得懂的用例。

一条命令行背后有两种运行模式。Mock 模式不调用任何外部服务，只检查我的用例和评估器是否正确。Real 模式跑真实节点，而且我可以把范围收窄到单个套件、限定用例数量，或者指定某一条用例 id，这正是在调试时把 real 模式成本控制住的关键。

有一个设计取舍我想特别提一下：real 模式跑的是仍然有意义的最便宜路径。路由类用例直接执行路由节点和查询改写节点，而不是整张图，这样路由回归能被抓住，却不用为检索和合成付钱。

我的关键词检索器是按字面匹配的，所以大写 R 的「Revenue」和「revenue」是两个毫不相干的词，而带逗号的「revenue,」是第三个。我写了一个正经的分词器把它们归一化。

在读这个库的源码时，我发现了一件我没料到的事。 BM25 本应自动处理常见词：一个出现在大多数文档里的词会拿到很低的权重，所以「the」应该几乎一文不值。这个公式对这类词能算出负权重，而这个库拒绝负权重——它会把它们抬到一个下限值。

结果和本意完全反了。「The」出现在我 84% 的切块里，它的真实权重是负的，而那个下限把它抬到了 1.81——比真正有信息量的「Group」的 1.54 还高。受影响的只有八个词，但这八个词几乎出现在每一个自然语言问题里。

我实测过。对于问题「what was the revenue of the group in 2024」，排名第一的文档得分中有 59% 来自 what、was、the、of、in 这几个词。把这些词去掉之后，新的前五名文档与原来的前五名零重叠。这不是排序上的微调——结果原本是由填充词决定的。

我从中得到的教训，也是我会带进团队的：教科书的说法在算法层面是对的，在实现层面是错的，而只有读源码、实测真实得分，才能看出这个差别。

我搭了一个小的 A/B 测试台，直接调用检索节点，完全不碰语言模型，所以两次运行之间唯一的变量就是检索配置。

标准答案（ground truth）是我确认过确实存在于已入库文本中的精确数字串——例如 BHP FY2024 营收的 55,658，以及它基础 EBITDA 的 29,016。只要返回的文档里包含这个数字，该用例就算命中，同时我记录它第一次出现的排名。

我会报告最终截断范围内的命中数、前五名内的命中数，以及命中项的平均排名。然后逐个用例打印它是改善、退化、新命中还是新丢失——因为整体指标可以变好，而个别用例反而变差，而退化的那些才是我真正想看到的。

两组配置分别是旧的——候选池八篇、不做重排——对比新的：候选池二十篇，再接一层 cross-encoder 重排（rerank）压回八篇。

一个实际细节：重排器是带每分钟 token 限额的付费 API，所以测试台在用例之间固定停顿来自我限速。没有这一步，比较会因为限流而失败，看上去却像是质量结果。

做成边界上的分层，而不是末端的一道过滤。出答案之前放一道检查，是大多数人最先想到的设计，但那太晚了——到那时你已经把全部算力都花完了，能做的只剩下拦截。

我在请求经过的每一个边界上放一道检查。输入端：这个问题在服务范围内吗，清晰到值得一试吗。检索端：返回的东西真的相关吗，用户问到的每一项我都找到了吗。生成端：草稿里的每一条陈述都有证据支撑吗。输出端：这里到底有没有实质性的答案，引用能不能解析出来。

有两条规则我在每一层上都坚持。便宜且确定的检查排在昂贵且带概率的前面——如果一个长度检查或一次查表就能拦住，就别花一次模型调用。以及，每一层都把自己的判定写进运行状态，这样决策是被记录下来的，而不是靠代码走了哪条分支去隐含推断。那条被记录下来的轨迹（trajectory），正是让系统可审计的东西。

这取决于是哪一层，而重点在于这是我按层逐个刻意决定的，而不是让异常处理器替我决定。

我的规则是这样。如果这一层是精确率上的改进——它让一个好答案变得更好——那就 fail open，因为失去它只是质量下降，而卡在它上面会让整个服务不可用。如果这一层是正确性的底线——没有它，一个错误或空的答案就会到达用户——那就 fail closed。

所以在我的项目里，两个基于模型的评判器都是 fail open。如果相关性评分器出错，我把全部检索到的文档都放过去，而不是一篇都不放。如果有据性评分器出错，我把答案标记为通过，而不是拦下它。两者都是叠在本来就能工作的检索之上的、可选的精确率层。

最后那道检查不一样。它是确定性的，不发任何网络调用，所以本质上没什么可失败的——而且它在构造上就是 fail closed：没有实质内容，就一定走兜底路径。

在银行里我会补上的一点是：fail open 必须是响的。悄无声息地降级，正是一个系统带着关掉的安全层跑了整整一周的原因。每一处 fail open 都需要一个指标和一条告警。

我会把三件常被混为一谈的事分开：用户能不能看到为什么、工程师能不能还原发生了什么、以及审阅者能不能在几个月后拿出证据。

对用户来说，解释必须在答案本身里。每一个来自报告的数字都带一个引用标记，能解析到具体的公司、财年和页码——这样这条陈述可以对着原文核对。而当验证步骤无法确认某件事时，答案里会直接写出来，不是写在日志里。

对工程师来说，每一个决策都写进运行状态，而状态在每一步都做检查点。所以我能还原的不只是最终答案，还包括选了哪条路由、哪些文档通过了评分、评判器说了什么。可还原比可记日志更强，因为日志是散文，而状态是结构化的。

对审阅者来说，我项目里的缺口在于：这条轨迹是运维存储，不是审计留痕。它不是不可变的，也没有留存策略。在受监管的环境里，我会把决策轨迹写到只追加（append-only）的存储里，设定明确的留存期，并把它当成与会话状态完全不同的一份产物。

我会温和地对「阻止」这个词提出异议。语言模型预测的是看起来合理的文本；自信地给出一个错误数字，不是一个你能打补丁修掉的 bug。所以目标不是防止，而是检测与遏制。

检测之所以可行，是因为在检索系统里我有东西可以对照。我把草稿答案连同它当时拿到的那些确切文档一起交给验证步骤，问一个很窄的问题：这个答案里的哪些陈述在这些文档里找不到。

接下来的遏制有三档。如果无支撑的内容很多，我就针对失败的那些具体陈述重新做定向检索。如果只有一点点无支撑，答案照常发出，但用户会看到哪些陈述未经核实。如果什么都没有无支撑，就干净地发出去。

还有一点值得提：验证器还会分类「为什么这条陈述无支撑」。它是由文中确实存在的数字算出来的？是从趋势里估出来的？还是跟文档毫无关系？第一种往往是合理的，只需要把推导过程展示出来。最后一种才是真正的幻觉。把这三种一视同仁，会丢掉用户需要的信息。

这是三种不同的情形，把它们搞混是产品失败，而不是技术失败。

当请求超出系统的用途时，拒答。有人向一个财报助手要一首诗，应该得到一条清楚的边界说明，以及它究竟覆盖什么——而不是一首诗，也不是含糊其辞。

当请求在范围内但没说清楚时，追问。「去年的数字是多少」是个合理的问题，只是缺了主语。猜测会产出一个关于错误公司的自信答案；问一句短问题只花掉一个回合，却能答对。

当我有真实证据但无法全部核实时，带提示作答。这时拒答等于扔掉一个大体有用的答案；隐瞒缺口则是不诚实。把答案给出来、同时点名哪些部分未经核实，才是把用户当成一个能自己判断的人。

而且提示必须具体才有用。每个答案上都挂一句「本内容可能不准确」是噪音。在真正失败的那一条陈述上写「该数字无法与检索到的文档核对上」，才是信息。

三条约束。一个硬上限、一个变化了的输入，以及重试耗尽时一个明确的结局。

上限是最简单的部分——状态里放一个计数器，最多重试两次。因为状态就是整张图共读的同一个对象，所以只有一个计数器，而不是每条分支各有一个。

第二条是大家常漏的。用同样的输入重试，只会得到同样的答案，白花钱。所以每次重试都必须改变点什么。在我这里重试是定向的：验证失败的那些陈述变成新的检索词，而这些陈述所属的公司会被标记为「尚未找到」，好让下一轮专门去找它们。

第三条是：重试用尽是一个有明确路径的正常结局，不是错误。它会走到兜底回复，说明系统覆盖什么。无界循环和未处理的耗尽，是同一个 bug 的两端。

六个检查点，按请求遇到它们的顺序。

第一，范围。路由步骤对问题分类，任何与这五家公司无关的问题都会得到一条固定回复，说明系统覆盖什么。第二，清晰度。如果问题模糊到无法据以检索，图会去问一个澄清问题，而不是猜。

第三，文档相关性。检索到的切块会被评分，像治理样板文字或审计师报告这类内容会被丢掉，除非问题本来就是问它们的。这一步还会修正每家公司「找到与否」的标记，因为只有当一家公司有文档通过了评分，才算真的找到了。

第四，有据性。草稿答案会逐条陈述对照它拿到的文档做检查，产出无支撑清单和重试信号。

第五，最终闸门。一道确定性检查，看看究竟有没有实质内容——它坐在通往答案的每一条路径上，包括那条从未碰过检索的直答路径。失败则路由到兜底回复，说明覆盖范围。

第六，输出整形。移除未被引用的来源并重排标记编号，并附上一个由有据性判定推导出的置信度等级；等级不高时，带上一句具名的提示。

当验证器报出一条无支撑陈述时，它被要求写一个不超过八个词的短标签，指明指标和上下文——例如「RIO FY2025 revenue」——并且明确要求不要复述那句话或那个数字。

原因是这个标签会作为警告展示给用户。如果验证器回显了完整陈述，那么这条本来是为了标记「可能是编造的数字」而存在的警告，就会把那个数字又一次以文字形式打印在答案里。安全提示反而成了错误数字出现的又一个地方。

一个略读的用户可能只看到数字，而错过它的语境。所以这条警告只说该怀疑哪一条陈述，而不重述那个他们本不该依赖的数值。

这是件小事，也正是我会去找的那类东西：不是这道检查管不管用，而是这道检查自己的输出到达人类时会做什么。

三个地方，而且每一个都是决定，不是意外。

相关性评分器 fail open：如果那次模型调用出错，我把所有检索到的文档都放过去，而不是一篇都不放。失去这道过滤意味着上下文更嘈杂。而 fail closed 则意味着完全没有上下文，那是把一个降级的答案变成没有答案。

有据性评分器同样 fail open：出错时答案被标记为通过。这是我最不放心的一处，因为它就是幻觉检查，而它的失败是无声的。让它勉强站得住的是确定性的最终闸门仍然会跑；而要让它在生产环境可以接受，需要一条针对错误率的告警——这个我还没有。

重排器也是 fail open：遇到网络错误或限流时，结果保留融合步骤给出的排序。它是叠在一个本来就存在的排序上的精确率改进，所以降级回上一个排序恰恰是对的。

还有一个是刻意 fail closed 的：最终内容闸门是确定性的、不依赖网络，所以空答案永远路由到兜底。底线这一层不能有可用性上的失败模式，而这正是它什么都不调用的原因。