578 篇博文 含有标签「insider」

大多数团队在构建 RAG 流水线时都会选择向量嵌入（vector embeddings）。这是一个显而易见的默认选择：嵌入文档、嵌入查询、寻找最近邻，然后将结果输入给 LLM。在演示（demo）中它的表现还不错。但当部署到合规团队或科学文献语料库时，准确率就会断崖式下跌。不是逐渐下降，而是突然暴跌。在涉及五个或更多实体的查询中，向量 RAG 在企业分析基准测试中的准确率降至零。不是 50%，也不是 20%，而是零。

这不仅是一个配置问题，而是架构上的不匹配。向量检索将文档视为语义空间中的点。知识图谱（knowledge graphs）则将它们视为关系结构中的节点。当你的查询需要遍历关系——而不仅仅是寻找相似内容时，检索架构的拓扑结构（topology）决定了你是否能得到正确答案。

大多数团队将人机协作审核作为事后补充：智能体完成其工作链，结果落入审核队列，然后人工点击批准或拒绝。这看起来像是安全保障，但实际上大多只是一种表演。

当一个多步骤智能体到达链尾审核时，它已经发送了 API 请求、修改了数据库行、起草了客户邮件并安排了后续跟进。所谓的"审核"不过是在批准一件已经完成的事。拒绝它意味着向智能体——通常也向用户——解释为什么过去 10 分钟发生的一切都不作数。

错误放置审批关卡造成的危害并不总是戏剧性的。更多时候，危害更加隐蔽：审核者批准一切，因为真正的决策已经做出；工程师在事故发生后增加更多检查点，却眼睁睁看着产品信任度崩溃；组织在"太多摩擦"和"监督不足"之间摇摆，却从未解决根本的放置问题。

大多数企业安全团队都有一套相当成熟的内部威胁模型：心怀不满的员工将文件下载到 USB 驱动器，将电子表格发送到个人邮箱，或者带着凭据离职。检测策略是已知的 —— DLP 规则、出口监控、UEBA 基准。这些策略没有考虑到的是这样一种场景：你给每位员工都提供了一个能够以机器速度规划、执行并掩盖多阶段操作的工具。这正是部署 AI 编程助手和基于 RAG 的文档代理的实际效果。

问题并不在于这些工具在隔离状态下是不安全的。而在于它们极大地放大了一个受攻击或怀有恶意的内部人员在单次会话中能完成的任务。内部人员事件的平均成本每年已达到每家机构 1740 万美元，83% 的机构在过去一年中至少经历过一次内部攻击。AI 工具并没有引入新的威胁类别 —— 它们只是成倍地增强了每一个现有威胁类别的能力。

几乎在每一个生产环境的 AI 系统中都会出现这样一种模式：团队从一个精简的系统提示词（system prompt）开始，发布功能，然后不断迭代。出现了一个新的边缘案例，于是他们添加一条规则。又来了一个工单，再加一条规则。六个月后，系统提示词已经增加到了 2,000 个 token，涵盖了 20 个不同的行为要求。对于大多数请求，AI 听起来依然连贯。但微妙的合规性失败已经潜伏了数周——这里忽略了格式，那里跳过了语气要求，一条升级规则被悄悄绕过。没有人发现，因为没有哪个单独的失败严重到需要触发警报。

这不是模型质量问题。这是基于 Transformer 的语言模型处理指令的一种基本架构特性，大量的实证研究使得这些失败模式变得可预测。理解这一点将改变你编写系统提示词的方式。

在 AI 产品开发中，有一个常见的假设：如果一个模型能处理难题，它就一定能处理附近的简单任务。这个假设是错误的，它导致了一类生产环境下的失败，而无论你读多少基准测试报告都无法为此做好准备。

这一潜在现象的研究术语是“破碎边界”（jagged frontier）——AI 的能力边界并不是一条平滑的线，并非难题在界外、简单任务在界内。它是一个参差不齐、不可预测的形状。AI 系统可以编写生产级别的数据库查询优化器，却仍然会算错图中两条线段是否相交。它们可以通过博士级别的科学考试，却在涉及空间关系的儿童谜题上失败。它们可以综合 50 页的文档，然后对自己刚刚读过的一段文字产生充满自信的幻觉。

我认识的一个团队花了三个月时间构建了一个基于规则的地址标准化器。它处理了最常见的 20 种格式，使用 USPS API 进行验证，并且在他们见过的数据上表现出色。然后他们迎来了一个新的企业客户。第一周的数据中，地址被嵌入在自由格式的备注字段里，邮政编码缺少国家前缀，还有他们的规则从未见过的跨境格式。这个标准化器在 31% 的记录上发生了静默失败。他们尝试用 LLM 作为一个快速修复方案，预期准确率为 80%，结果得到了 94%。令人惊讶的不是 LLM 奏效了 —— 而是他们的评估框架中没有任何指标预见到了这一点。

这就是问题的现状。基于规则的标准化是可预测的、快速且廉价的。当数据分布在预设范围内时，它表现良好。LLM 处理的是长尾部分 —— 那些奇怪的格式、隐含的领域知识以及规则永远无法穷举的边缘情况。但 LLM 也很昂贵、缓慢且不稳定，如果你不小心，它们会破坏生产流水线。对于几乎每个团队来说，正确的答案是采用混合方案，在各自擅长的输入上分别使用这两种方法。

产品团队已经开始直接将分析问题路由给 LLM：“是什么导致了流失率激增？”“为什么重新设计后转化率下降了？”“我们应该把留存预算重点花在哪个群体上？”输出结果出现在高管汇报幻灯片中，驱动着路线图决策，并向投资者展示。模型以优雅的文字和具体的数字自信地作答。然而，这些答案中有很大一部分是以一种不易察觉的方式出错的。

这并不是对用 LLM 处理数据工作的全面批评。在某些任务中，它们确实很有帮助。问题在于其失败模式是隐形的——模型不会留有余地，不会说明局限性，也不会区分“我是根据你的数据计算出来的”和“我生成了一个听起来像这个数字应该是多少的东西”。了解故障发生位置的从业者可以捕捉到真正的价值并避开雷区。

大多数工程团队认为自己已经对 LLM 供应商锁定做了充分防护：用 LiteLLM 统一 API 调用、避免在托管平台上做微调、把原始数据存在自己的存储里。他们感到安全。然后某天提供商宣布弃用某模型，或竞争对手降价 40%，团队才发现，自己搭建的抽象层大概只处理了约 20% 的实际迁移成本。

另外 80% 藏在没人仔细看过的地方：围绕模型格式怪癖写成的系统提示词、按照某个模型的拒绝阈值校准的评估套件、一旦换模型就会失效的嵌入索引，以及建立在某种行为模式上却根本无法迁移的用户预期。

某零售采购智能体在"初始测试期间"继承了供应商 API 凭证，却没有人在系统投产前对其加以限制。当一个差一错误触发后，该智能体拥有完全的下单权限——永久生效，毫无限制。等财务部门察觉时，已有价值 47,000 美元的未授权供应商订单发出。代码没有问题，模型也按设计运行。造成如此大破坏的，是权限问题。

这就是最小足迹原则：智能体应仅请求当前任务所需的权限，避免在任务范围之外持久化敏感数据，清理临时资源，并将工具访问权限限定于当前意图。这是 Unix 最小权限原则在新时代的延伸——在这个时代，代码会在运行时自主决定下一步需要做什么。

团队之所以在这里屡屡犯错，并非出于疏忽，而是概念错误：他们把智能体权限当作设计时的工作，而智能体 AI 使其成为了运行时问题。

当你在多个区域运行无状态 HTTP API 时，路由问题基本上已经解决了。在前面放一个全球负载均衡器，按地理位置分配请求，最糟糕的情况也不过是缓存项稍微过时。任何副本都可以处理任何请求，并获得相同的结果。

LLM 推理打破了每一个假设。一旦你添加了提示词缓存（Prompt Caching）——你肯定会加，因为缓存命中和未命中的成本差异大约是 10 倍——你的服务就会以大多数基础设施团队预料不到的方式变得有状态，直到他们在第二个区域看到延迟数据退化。

你的 SaaS 产品以十个设计客户的规模上线，一切运转完美。随后你陆续接入了一百个租户，其中一个——一位在复杂研究工作流中使用 20 万 token 上下文窗口的重度用户——导致了所有其他客户的延迟飙升。支持工单开始涌来。你查看监控面板，却看不到任何明显异常：模型健康，API 返回 200，p50 延迟看起来正常。而你的 p95 已经悄悄翻了三倍。

这就是嘈杂邻居问题，它对 LLM 基础设施的冲击比几乎任何其他共享系统都要剧烈。以下是它为何比数据库场景更难解决——以及真正有效的应对方案。

你的单次请求错误率看起来很正常。延迟在 SLO 范围内。LLM 裁判对输出的评分是 87%。接着，一位用户提交了支持工单：“我把账号告诉了机器人三次，它却一直重复问我。”另一位用户说：“它先是同意退款，两轮对话后又否认该政策的存在。”

单轮失败是显而易见的。请求进来，模型出现幻觉或拒绝回答，你的评估 (eval) 捕捉到了它，然后你修复提示词。反馈循环很紧密。多轮失败则完全不同：会话开始时表现良好，随后逐轮恶化，而你的监控从未报警，因为每个单独的回复在技术上都是连贯的。问题出在整个会话上——而几乎没有团队为此建立观测机制。

对主要前沿模型（Claude 3.7 Sonnet、GPT-4.1、Gemini 2.5 Pro）的研究显示，从单轮转向多轮对话时，平均性能会下降 39%。这个数字掩盖了真相：只有大约 16% 的下降是由于能力损失。另外 23 个百分点则是一场可靠性危机——随着对话长度增加，模型在同一任务上的最佳表现与最差表现之间的差距翻了一番。你得到的不仅是质量更差的输出，还有极不稳定的输出。