578 篇博文 含有标签「insider」

模型卡显示代码生成准确率为 89%。你的团队在实际代码库上只得到了 28%。模型卡显示有 100K token 的上下文窗口。而在你的文档工作负载下，性能在 32K 时就大幅下降。模型卡通过了红队安全评估。但在上线后的 72 小时内，针对用户的提示词注入攻击就出现了。

这种差距并不罕见。这已成为常态。在 2025 年对 1,200 个生产部署的分析中，42% 的公司在生产集成阶段放弃了他们的 AI 计划 —— 高于前一年的 17%。他们中的大多数都仔细阅读过模型卡。

问题不在于模型卡撒谎。而在于它们衡量的内容与你需要了解的内容不同。准确理解这一差距 —— 并构建内部基准测试套件来弥补它 —— 是交付可靠 AI 的团队与交付懊悔的团队之间的分水岭。

你接手了一个基于 GPT-4-turbo 构建的 AI 功能。该模型即将被弃用。你的经理希望通过切换到更新、更廉价的模型来降低成本。你快速跑了一遍测试，指标看起来还过得去，于是就上线了——结果一周后，核心用例的准确率下降了 22%。支持工单不断攀升。你现在面对的是一场危机式迁移，而非有计划的操作。

这就是模型可移植性税：每当你将应用逻辑与某个特定基础模型紧耦合时，就会累积的隐性工程成本。每个团队都在为此买单，大多数人直到账单到来时才意识到数字有多大。

2024 年 8 月，安全研究人员发现 Slack AI 在回答查询时会将公开频道和私密频道的内容同时拉入同一个上下文窗口。公开频道中的攻击者可以精心构造一条消息，当 Slack AI 摄取该消息时，就会将指令注入受害者的会话——由于 Slack AI 不引用来源，由此导致的数据外泄几乎无从追踪。这种攻击甚至可以泄露私信中嵌入的 API 密钥。Slack 在负责任披露后修复了这一问题。

这并不是传统意义上的漏洞。它是将上下文视为无用户访问控制的共享可变资源所带来的后果。而这正是大多数正在构建共享 AI 助手的团队现在都在犯的错误，只是更加悄无声息而已。

你的产品路线图写着“进军日本和巴西市场”。你的财务模型显示 LLM API 支出项为每月 $X。这两个数字都是错的，而且你直到国际化推广前几周才会发现这一点。

Tokenization（分词）——将用户文本转换为模型可处理的整数的步骤——对英语有着深刻的偏向。一段日语文本所需的 Token 数量可能是同义英语句子的 2–8 倍。这个倍数直接影响到 API 成本、上下文窗口余量和响应延迟。那些根据英语基准测试来模拟 AI 预算，然后直接切换语言选项的团队，通常会被比预期高出 3–5 倍的账单吓一跳。

演示进行得很顺利。试点运行了六周，展示了清晰的成果，与会的利益相关者印象深刻。然后，什么都没有发生。三个月后，项目悄悄被搁置，构建它的工程师转向了其他事情，公司的AI战略变成了一张写着"探索机会"的幻灯片。

这就是扼杀AI项目的模式。不是技术失败，不是模型能力不足，甚至不是预算问题。技术本身确实有效——研究一再表明，约80%进入生产的AI项目达到或超过了预期目标。问题在于那70-90%从未走到那一步的项目。

当一个多智能体系统开始出现奇怪的行为——给出不一致的答案、丢失任务追踪、做出与早期推理相矛盾的决策——本能反应是责怪模型。调整提示词，换一个更强的模型，添加更多上下文。

真正的原因往往更平凡，也更危险：并发写入导致的共享状态损坏。两个智能体读取同一块内存，都计算出更新，其中一个默默地覆盖了另一个。结果状态在技术上是有效的——没有异常抛出，没有模式违规——但在语义上是错误的。之后读取它的每一个智能体都在对错误信息进行正确的推理。

这种故障模式在单个操作层面是不可见的，在测试环境中难以复现，仅通过查看输出几乎无法与模型错误区分开来。O'Reilly 2025年关于多智能体内存工程的研究发现，36.9%的多智能体系统故障源于智能体间的不对齐——智能体在对共享信息的不一致视图上运行。这不是一个理论上的顾虑。

当团队部署 AI 安全过滤器时，对话几乎总是集中在它拦截了什么。它是否拦截了越狱攻击？它是否标记了仇恨言论？它能检测提示词注入吗？对于召回率（Recall）来说，这些都是正确的问题。但它们几乎从未与另一个同样重要的问题挂钩：它错误地拦截了哪些不该拦截的内容？

答案通常是：很多。由于大多数团队在发布时都使用供应商的默认阈值，并且从未在生产环境中对误报（False Positives）进行监测，他们直到用户开始抱怨时才会发现——或者直到用户停止抱怨，因为他们已经停止使用该产品了。

你的 AI 功能在内部测试中表现出色。工程师拍手叫好，产品经理竖起大拇指，评估套件在基准测试中显示了 94% 的准确率。然后你上线了，两周之内，用户就遇到了你从未见过的故障模式——错误的答案、混乱的输出，以及让模型显得极为糟糕的边缘情况。

这就是生产分布差距（production distribution gap）。这不是一个新问题，但对 AI 系统来说，它比确定性软件严重得多。理解其背后的原因——并制定具体的解决方案——是决定 AI 功能悄然侵蚀用户信任还是随着使用不断改进的关键分水岭。

大多数RAG团队会花数月时间调整分块大小、尝试不同的嵌入模型、争论混合搜索配置。然后他们上线，宣告成功，转身离开。六个月后，用户开始抱怨系统给出错误答案——团队才发现，当初精心构建的索引已经悄然腐化。

索引新鲜度是最后才被解决的问题，通常是在用户投诉事故之后才被重视，而非之前。与检索质量问题会立即在评测中暴露不同，数据陈旧是无声无息的退化：延迟保持平稳，检索看似正常，上下文召回率和忠实度等标准RAG指标评分良好——直到系统自信地返回几个月前就已更新的政策时，才会东窗事发。

你花了数周时间调优嵌入模型。检索精度看起来不错。分块大小、重叠、元数据过滤器——一切都已调整到位。然而用户不断反映，系统"忽略"了它明明能访问的信息。相关段落每次都出现在 top-5 检索结果中，模型就是不用它。

罪魁祸首往往是位置偏差（position bias）：语言模型倾向于过度依赖上下文窗口开头和结尾的信息，而对中间内容的注意力显著不足。在受控实验中，将相关段落从 20 篇文档上下文中的第 1 位移至第 10 位，准确率会下降 30-40 个百分点。你的检索器找到了正确的内容，但排序毁了它。

你的检索器在 94% 的情况下都能返回正确文档。你的 LLM 在给定良好上下文时能正确回答 96% 的问题。可以上线了。能出什么问题？

把这两个数字相乘：0.94 × 0.96 = 0.90。在不考虑任何边缘情况、提示词格式问题、token 截断，以及检索器与正确文档一起返回的干扰文档之前，你就已经损失了 10% 的查询。但更深层的问题不是这个算术——而是你的单元测试永远不会发现这一点。检索器在隔离测试中通过了。生成器在隔离测试中通过了。失败的是两者的组合，而大多数团队对此没有任何测试。

这就是检索-生成接缝：检索器交付内容与生成器实际能够使用的内容之间的接口。它是生产 RAG 系统中测试最不充分的边界，也是大多数故障的根源。

如今，大多数构建 AI agent 的团队都将授权视为事后才考虑的事情。他们接入一个 OAuth 令牌，给 agent 分配与触发它的用户相同的权限范围（scopes），然后就大功告成了。然而，几个月后，他们会发现一段被操纵的提示词导致 agent 窃取了文件，或者一个受损的工作流在连接的服务中悄无声息地提升了权限。

问题不在于 RBAC 不好。而是在于 RBAC 是为具有稳定工作职能的人类设计的，而 AI agent 既不稳定也不是人类。在一个对话回合中，agent 的“角色”可能从只读研究转变为具备写入能力的代码执行。静态角色无法表达这一点，这种不匹配创造了一个可预见的漏洞攻击面。