578 篇博文 含有标签「insider」

大多数分布式追踪方案在引入 Agent 之前都运作良好。一旦系统中出现 Agent A 跨微服务边界调用 Agent B——Agent B 调用工具服务器、工具服务器再查询向量数据库——原本连贯的端到端视图就会碎片化为互不相连的片段。追踪后端展示的是一个个孤立的操作，而你失去的是因果链：为什么某件事发生了，哪个用户请求触发了它，以及那 800 毫秒究竟消耗在了哪里。

这不是监控配置问题，而是上下文传播架构问题。它有着特定的技术形态，大多数团队都是在付出代价后才意识到这一点。

你的 RAG 系统运行正常。延迟处于常规水平。错误率为零。但一位询问“加州雇佣法”的用户却不断得到关于房地产的搜索结果 —— 而你的日志显示一切正常。

这就是嵌入漂移（embedding drift）在作祟：这是一种不会抛出异常、不会导致错误率飙升，也不会出现在标准可观测性仪表盘上的检索失效模式。当你的向量数据库积累了在不同条件下生成的嵌入时 —— 比如不同的模型版本、不同的分块规则、不同的预处理流水线 —— 向量开始指向不兼容的方向，这种情况就会发生。系统仍在处理请求，但语义坐标已不再对齐，检索质量在数周或数月内悄然恶化。

一项针对 106 个企业 AI 系统的 appliedAI 研究发现，40% 的系统风险分类不明确。这一数字并不反映监管的复杂性——它反映的是有多少工程团队在交付 AI 功能时，从未追问该功能是否改变了合规层级。欧盟 AI 法案对高风险系统的强制执法日期定为 2026 年 8 月 2 日。届时，处于那 40% 之列不再是管理问题，而是一个架构问题——你将在监管机构注视之下，以四倍于原始成本的代价、在截止日期的压力下修复它。

本文不是法律概述，而是面向工程师的深度解读：哪些产品决策会悄然触发高风险分类，这些分类对应哪些具体交付物，以及为什么事后改造的成本远高于一开始就内置合规的成本。

你花了三周时间精心整理一套高质量的评估集。你编写了测试用例来覆盖产品经理担心的边缘情况，从内测用户中采样了真实查询，并得到了一个团队认可的准确率数字。六个月后，这个数字仍然出现在每周的仪表盘上。你刚刚发布了一次在评估中表现出色的模型更新，用户却在提交工单。

问题不在于模型退步了。问题在于你的评估集几个月前就已经不再代表现实——而没有人注意到。

这种失败模式有个名字：评估集衰退。它几乎发生在每一个生产AI团队身上，而且几乎从不会在用户行为中出现可见损失之前被发现。

企业团队基于基准测试和演示选择LLM供应商，然后在生产环境中才发现SLA实际保障的内容——通常远低于预期。你费力谈下来的99.9%可用性保证并不涵盖延迟。法务团队签署的数据处理协议，除非明确添加了相关条款，否则并不禁止供应商用你的输入数据进行训练。而没有人量化的供应商集中风险，在某次遥测部署级联影响Kubernetes控制平面导致核心产品中断四小时后，会以最惨烈的方式暴露出来。

这不是采购问题，而是采购单独无法解决的工程问题。构建AI系统的工程师需要理解这些合同实际说了什么——以及没说什么。

在 2024 年底，OpenAI 的 o3 系统在 ARC-AGI 基准测试中获得了 75.7% 的分数——这是一个专门为抵抗优化而设计的测试。AI 研究界欢欣鼓舞。但从业者仔细观察后发现：o3 使用了该基准测试 75% 的公开训练集进行训练，且最高算力配置使用的资源是基准线的 172 倍。这并不是伪装成分数的能力突破，而是伪装成能力突破的分数。

这就是评估悖论（Evaluation Paradox）。一旦某个基准测试成为团队优化的目标，它就不再能衡量其最初设计的目的。古德哈特定律（Goodhart's Law）——“当一个衡量指标变成目标时，它就不再是一个好的指标了”——虽然是在 20 世纪 70 年代的经济政策中提出的，但它却极其精准地描述了 AI 基准测试的现状。

当一名律师在联邦备案文件中引用不存在的法庭案例时，这一事件被广泛报道为“ChatGPT 产生了幻觉”。当一家咨询公司的政府报告中包含虚假脚注时，复盘报告写道“AI 伪造引文”。当一个医疗转录工具在医疗笔记中插入暴力语言时，解释仅仅是“模型产生了幻觉”。在每一个案例中，代价昂贵的失败都被归结为一个由三个词组成的根本原因，这使得修复变得不可能。

“模型产生了幻觉”在 AI 领域等同于在堆栈跟踪中写下“未知错误”。它描述了发生了什么，却没告诉你为什么发生或如何修复。每一次幻觉都有一个可诊断的原因——通常属于四个类别之一——且每个类别都需要不同的工程响应。理解这种区别的团队能够交付可以优雅降级的 AI 系统。而不理解的团队则在不断地通过提示词玩“打地鼠”游戏。

这种场景每次都如出一辙。你的智能体正在预订酒店房间，支付API调用返回200后、确认信息存储之前发生了网络超时。智能体框架发起重试，支付再次执行，客户被扣了两次款。支持团队升级处理，某位高管说AI"幻觉出了重复扣款"——这种说法是错的，但听起来有道理，因为没人愿意承认他们的重试逻辑从一开始就是坏的。

这不是AI问题，而是分布式系统问题——被AI层全盘照搬，却没有带来分布式系统工程师几十年苦心钻研出的应对之道。标准的智能体重试逻辑假设操作是幂等的，而大多数工具调用并非如此。

你将昂贵的 LLM 换成了更快、更便宜的蒸馏模型。延迟增加了，成本上升了，质量下降了。你感到困惑并回滚了版本，因为你刚刚花了三周时间做的优化工作反而让一切变得更糟。

这并非假设。这是生产环境 AI 系统中最常见的失败模式之一，它源于一个诱人但错误的心理模型：优化某个组件就能优化整个系统。

周一你的提示词还运行正常。周三，用户开始抱怨响应感觉不对劲——答案变短了，下游的 JSON 解析时不时崩溃，原本准确率 94% 的分类器现在徘徊在 79% 左右。你没有部署任何新代码，配置文件里调用的模型名称还是那个。但某些东西变了。

这就是隐形模型漂移：LLM 供应商在不作任何公告的情况下推送静默的、未记录的行为变更。这是 AI 工程中讨论最少的运营风险之一，它会打击那些"做了所有正确事情"的团队——有评估集、有监控、有稳定的提示词工程。模型就在他们脚下悄悄地变了。

每个事件流系统最终都会将同一条消息投递两次。网络抖动、Broker 重启、偏移量提交失败——至少一次投递不是 Bug，而是契约。传统消费者能够优雅地处理这种情况，因为它们是确定性的：处理同一事件两次，得到相同的结果，写入相同的记录。第二次写入是一个空操作（no-op）。

LLM 不是确定性处理器。相同的提示词加上相同的输入，每次运行都会产生不同的输出。即使设置了 temperature=0，浮点运算、批次组合效应以及硬件调度的差异也会引入方差。针对"确定性" LLM 设置的研究发现，在自然发生的多次运行中，准确率差异高达 15%，最优与最差性能之间的差距甚至达到 70%。至少一次投递加上非确定性处理器，并不会给你带来至多一次的行为，只会带来不可预测的行为——这是一场蓄势待发的生产环境危机。

关于生产环境中的 LLM，大多数讨论都围绕着聊天界面、Copilot 和自主代理。但如果你审计企业 LLM Token 的实际消耗去向，你会发现一个完全不同的景象：绝大多数的使用都发生在批处理数据管道（batch data pipelines）中 —— 从文档中提取字段、对支持工单进行分类、规范化混乱的供应商记录、为原始事件添加语义标签。没有人为这个层级编写会议演讲，也没有人认真地对其进行基准测试。而这种沉默正让团队付出真金白银和准确性的代价。

这是从业者最先构建、最后辩护、且监控最少的 ETL 层级。对于大多数组织来说，这也是 LLM 支出杠杆率最高的一层，同时也是产生隐形失败潜力最高的一层。