大模型上下文选择机制需引入排除记录

上下文包为何需要解释“排除了什么”

AI系统的上下文包（context packet）通常被看作控制模型输出的有效手段——给模型看什么，它就更可能说什么。但一个被忽略的问题是：在生成回复之前，系统选择不把哪些信息放进上下文，同样是一个重大设计决策。

据技术博客分享的“上下文感知接待案例”（context-aware reception case），其核心设计是在生成前引入一个解析器（resolver）。解析器读取运营上下文，选定一条已批准的业务指令，然后将更小的包传递给响应代理。模型不会收到所有营销线索、历史消息和响应规则的无差别集合。

这一模式的价值显而易见：更小的上下文包让回复更可控。但文章指出了一个容易被忽略的盲区——当回复出错时，审查最终提示词只能解释模型看到了什么，却无法解释前端的解析器丢弃了什么。

选择行为制造了第二层解释难题

来源之间的冲突让这一问题更加突出。营销归因可能指向某个产品系列，而当前对话却指向另一个方向；CRM中的历史字段可能仍然有值，但其含义已经过时；一条已批准的指令可能存在，但并不适用于当前交互场景。

解析器在生成前需要一套选择策略，而审查者则需要区分三种状态：不可用、可用但过期、可用但被有意排除。这三种状态对应完全不同的修复工作——缺失的来源可能需要排查集成问题，过期的数据可能需要刷新规则，而在错误策略下被排除的有效来源则可能暴露解析器本身的缺陷。简单地往提示词里塞进更多材料，并不能修复上述任何一个问题。

一个虚构示例：替换配件场景

设想一个虚构的交互场景：用户询问替换配件。系统手头有完整产品的营销信号、一个旧的CRM分类、以及一条已批准的配件支持指令。

解析器的输出可以标明：配件支持指令被选中；营销信号不足以确立当前请求；旧分类需要新鲜度审查。它保留经过脱敏的来源引用，而不是把对话内容复制到另一个日志中。响应代理会收到相关指令和剩余的不确定性，审查者则可以单独查看排除原因。

需要强调，这只是一个提议的契约设计，并非真实客户交互或已观察到的结果。

上下文包与审查记录必须分离

一个自然的反方案是把所有被排除的来源重新塞回代理的上下文——但这恰恰会重新制造解析器本要消除的歧义。

更合理的结构是：响应包只包含选定的上下文、适用的指令以及安全回答所需的不确定性信息；审查记录则单独捕获考虑过的来源类别、选择策略版本和简洁的排除原因。两者都受访问规则约束——追踪引用不应成为绕过文档权限的通道，原因代码也不应意外泄露敏感来源内容。

排除记录还需要一个有边界的词汇表。“优先级较低”是弱证据，因为没人能解释是哪条规则确立了优先级。有用的原因应该描述一项检查：超出当前请求范围、版本已被取代、冲突未解决、归因不足、来源不可用。

脱敏引用（sanitized reference）是指用不包含原始敏感内容的指针或摘要来代替完整数据，例如只记录来源文档的ID、版本号和类别标签，而不复制其中的具体文本。这样做的目的是让审查者能够追溯“解析器曾考虑过哪些来源”，同时不违反原始文档的访问控制。如果审查记录直接复制对话内容或CRM字段，那么任何能读取日志的人就绕过了业务系统的权限边界。脱敏引用通常配合访问控制列表（ACL）继承机制：引用本身不携带敏感数据，审查者需要凭原有权限才能解析引用背后的内容。这也是文中强调“追踪引用不应成为绕过文档权限的通道”的技术含义。

原因代码的受控词汇表（bounded vocabulary）是指一组预先定义、数量有限且语义明确的排除原因标签，而不是自由文本。受控词汇表的好处是排除记录可以被聚合分析、跨案例比较，并避免审查者用模糊措辞掩盖规则缺失。文中给出的“超出当前请求范围”“版本已被取代”“冲突未解决”等都属于此类。与之相对，“优先级较低”之所以是弱证据，是因为它没有指向任何可检查的规则。受控词汇表需要与选择策略版本绑定，这样当策略变更时，历史排除记录仍然可以按当时的规则集来解释。

采纳前的实用审查清单

在引入排除记录之前，建议逐项核对：

• 审查者能否区分输入缺失与有意排除？
• 每条排除原因是否对应一条显式规则？
• 被选中的指令能否追溯到已批准的版本？
• 未解决的冲突是否对响应路径保持可见？
• 引用是否经过脱敏并受原始访问边界约束？
• 审查者能否在不扩大模型提示词的前提下重建解析器决策？

这些检查建立的是一个可审查的设计，而非证明解析器选择正确。后者需要经过审查的案例、分歧分析以及错误上下文回复的基线度量。

回到文首的问题：当你审查一条AI回复时，你能否同时解释它接收了哪些上下文，以及系统选择遗漏了哪些相关上下文？