跨用户一致性问题：当你的 AI 对同一问题给出不同答案时

同一家公司的两位分析师都问了你的 AI 助手同一个问题："我们 Q3 的客户流失率是多少？"一个人得到的是 4.2%，另一个人得到的是 4.8%。两个答案都没有错——他们只是在不同的时间、不同的会话上下文中进行了查询，检索索引对略有不同的数据块进行了排名。AI 自信地回答了两个问题，没有任何保留，没有标记任何差异。两位分析师带着不同的数字走进了同一个会议，而你的工具刚刚变成了一个负担。

这就是跨用户一致性问题，也是企业 AI 部署悄然失去信任最常见的原因之一。这种失败并非经典意义上的幻觉——没有编造任何事实。失败在于：你的系统在规模上是非确定性的，而这种非确定性在两个用户互相对比结果之前是不可见的。

为什么 Temperature=0 救不了你

构建企业 AI 时，标准的直觉是将 temperature 设置为零，然后宣告问题已解决。但这行不通。最近一项研究对五个配置为最大确定性的 LLM 进行了检测，发现在其他条件相同的运行中，准确率差异高达 15%。在某些任务中，最佳与最差观测性能之间的差距达到了 70%。

技术原因比采样层面更深：

浮点非结合性。 GPU 使用浮点运算处理张量操作，而浮点运算不满足结合律——(a + b) + c 与 a + (b + c) 的结果可能不同，这取决于执行顺序。当同一个前向传递在不同的硬件线程或不同的内存布局下运行时，logits 会发生偏移。模型本身在原则上是确定性的；执行它的硬件不是。

批处理污染。 在批量推理中，一个 Prompt 的输出部分取决于同时处理的其他请求。前向传递不是"批次无关"的——同样的输入会根据批次中的其他内容产生不同的结果。两个用户相差几秒钟问同一个问题，会落入不同的批次，得到略有不同的输出。

检索索引漂移。 基于 RAG 的系统会放大这一问题。为某个查询检索到的 top-k 数据块会因索引更新、Embedding 模型补丁或相似度阈值调整而发生变化。你的检索层实际上是一个移动的靶子，数据块排名的细微变化会产生明显不同的上下文，进而产生不同的答案。

专家混合路由（MoE）。 使用 MoE 架构的模型会将 Token 路由到不同的专家子网络。在高负载下，路由决策会随着专家容量的填满而改变——在低流量下路由到专家 A 的 Token，在 A 容量饱和时会路由到专家 B。由此产生的分布偏移。

综合影响是：即使在专门为确定性而设计的生产系统中，来自不同会话中两个用户的同一查询也往往会产生语义上不同的输出。

个性化陷阱

问题就在这里变成了架构性的，而不仅仅是技术性的。许多团队在面对不一致性投诉时，会将个性化作为理由："答案当然不同——它们是针对用户定制的。"

个性化是合理的设计目标。询问风险敞口的合规官员与构建仪表板的分析师应该得到不同的框架。不同的角色、不同的数据访问权限、不同的上下文——不同的答案。这是功能行为，不是缺陷。

陷阱在于将"个性化"作为非预期方差的借口。当两个具有相同角色、相同数据访问权限和相同意图的用户问同一个问题却得到不一致的答案时，问题不是功能丰富——而是未公开的非确定性以个性化的面目出现。这两者并不相同，这种思维模型的区别至关重要。

工程问题是：哪些维度的方差是预期的？基于角色的上下文注入是预期的。基于权限的检索过滤是预期的。会话之间的浮点抖动不是。上午和下午之间的检索索引漂移不是。大多数团队对这个问题没有明确的答案，因为他们从未明确地绘制过这张图。

一个有用的框架是授权方差与环境方差。授权方差是你设计的方差：角色门控、上下文注入、权限过滤。环境方差是你从技术栈中继承的方差：硬件非确定性、批处理效应、索引漂移。问题不在于方差的存在——而在于大多数系统在宣称提供授权方差的同时，实际上输出的是环境方差。

真正有效的一致性机制

在生产环境中降低环境方差需要同时在多个层面采取措施。

在查询层面进行缓存。 最可靠的一致性机制是对重复查询完全绕过模型。语义查询缓存——对用户问题的 Embedding 进行哈希，并对高相似度的匹配返回缓存的答案——完全消除了高频问题的方差。这不是技巧；这是合理的架构选择。对于底层数据没有变化的机构知识查询，返回缓存的答案既更快，也比再次进行推理更一致。

结合确定性选择进行集成。 对于不适合缓存的高风险查询，生成三到五个候选响应，并使用确定性规则选择获胜者：结构化 Schema 检查、关键词存在验证或受约束的评分标准。目标是使用模型的生成能力进行生成，同时将其从选择步骤中移除。基于随机采样的选择是环境方差集中的地方。

加载中…