678 篇博文 含有标签「ai-engineering」

大多数防御提示词注入 (Prompt Injection) 的团队都会联想到一个攻击者：一个精心设计特定字符串以覆盖 AI 指令的人。这种思维定式是错误的，并让他们付出了代价。这个问题更难的版本根本不需要攻击者。

每当你的 AI 应用摄取用户生成的内容时 —— 无论是产品评论、工单、上传的文档还是 CRM 笔记 —— 它都面临着同样的结构性漏洞。无需恶意企图。普通用户出于普通原因生成的普通文本，在规模化的情况下，其表现可能与蓄意的注入攻击完全一致。如果你的应用仅针对对抗性案例进行防御，那么你防御的只是少数情况。

每一个交付过 LLM 驱动的智能体（Agent）的工程师都曾被一个简单的思维模型所诱惑：工具就是一个函数。增加一个工具意味着智能体多了一项功能。其成本仅仅是系统提示词（System Prompt）中的几行文档，或许是一个 Schema 定义，又或者是工具注册表中的一个新条目。这给人的感觉是累加的——线性增长。

事实并非如此。每一个新工具并不只是孤立地扩展智能体的能力；它扩展的是该工具与已有所有工具组合后能产生的能力。这种区别是一类生产环境故障的根源，这类故障在事后无论如何调整提示词都无法修复，因为问题出在架构层面。“提示词表面积”（Prompt Surface Area）问题是真实存在的，它会迅速复合增长，而大多数团队直到深陷其中时才察觉。

你的 RAG 系统很可能正在把自己的输出编入索引。只是你还不知道而已。

一切往往从一件看似无害的事开始：有人把一份季度总结文档添加到了知识库。而这份总结，正是由查询该知识库的同一个 LLM 生成的。六个月后，开发者又加入了 AI 生成的版本说明，随后是自动生成的支持 FAQ，再然后是合成的入职指南。这些文档没有任何一份被标注为 AI 生成。对于检索系统而言，它们与人工撰写的一手资料看起来别无二致。于是，当你的模型检索上下文来回答问题时，其中相当一部分上下文是之前某次模型运行所输出的压缩版、甚至可能已经失真的结果——而你的准确率指标依然绿灯常亮。

这就是溯源债务：在检索语料库中，AI 生成的内容在没有来源标记的情况下不断累积，形成一个反馈循环——每一代模型的输出，都成为下一代模型的原始素材。

凌晨 2 点，一个定时报告生成任务向共享的 API 密钥并行发出五十个 LLM 请求。等到早上 9 点的产品演示开始时，每一个实时对话补全都在悄无声息地超时。错误仪表板一片绿色，日志里没有 429 错误。模型确实在返回响应——只是慢了十秒，而这个功能的 SLA 是两秒。

这就是配额饥饿。它不像故障，它看起来只是"今天 AI 有点慢"。

每个 AI 产品团队的某个角落都有一个安全仪表板，显示着被拒绝的请求。触发了哪些过滤器，拦截了哪些越狱尝试，抓住了哪些违反政策的行为。运营团队通过它来确保防护栏（guardrails）稳固，而其他人都对其视而不见。

这是一个错误。AI 拒绝的请求是你所能接触到的最集中、最真实的用户调研信号。如果一个用户尝试了三种不同的措辞，想让你的产品去做它不愿做的事情，他是在以极其清晰的方式告诉你，他到底想要什么以及无法得到什么。将这一信号视为安全产物而非产品产物，是在浪费你所能收集到的最宝贵的反馈。

你的 AI 功能顺利发布。评估集准确率：91%。延迟：可接受。团队深感自豪。六个月后，用户开始抱怨该功能感觉“很笨”，支持工单不断增加，而你的综合指标悄然比发布当天下降了 8%。没有人更改过模型。底层数据流水线完好无损。发生了什么？

这就是逆行准确率问题（The retrograde accuracy problem）。随着产品的增长——新功能、新用户细分、新边缘情况、新流程——你的 AI 在生产环境中看到的输入分布会悄然偏离其训练时的分布。模型没有更新，数据流水线没有故障，而是产品本身的增长超出了模型的能力范围。

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段，他们精心设计了边界场景用例，记录预期输出，经过评审后发布。六个月后，套件仍然通过。然而，模型在实际生产流量上已经悄然退步，而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案，而非用户真正在问的问题。

这就是"博物馆问题"：一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景，却无法覆盖真正让它崩溃的场景。

你的仪表板显示全绿。延迟处于正常水平。错误率为 0.2%。本月正常运行时间为 99.97%。然而，你的 AI 助手正自信地向用户提供错误的信息，格式不对，长度是预期的两倍——而且这种情况已经持续了 11 天。

这就是 SLA 幻觉：基础设施合同保障的是管道，而不是其中流过的水。对于 AI 驱动的功能，“它是否有响应？”与“它的响应是否准确？”之间的差距，正是产品质量悄然崩塌的地方。

大多数关于AI延迟的讨论都搞错了方向。团队痴迷于GPU利用率、模型量化和批处理大小。与此同时，真正让用户感到烦躁的延迟——AI开口说话前的那段停顿——几乎完全由推理开始前发生的事情决定。瓶颈在于上下文，而非算力。

首Token时间（TTFT）是决定AI功能感觉灵敏还是迟钝的关键指标。而TTFT主要由预填充阶段主导：在生成任何输出Token之前，处理完整输入上下文所需的时间。对于128K Token的上下文，预填充可能耗时数秒。GPU在努力工作，但用户什么也看不到。

解决方案不是更好的GPU，而是在用户提问之前就预先加载好上下文。

这是一个大多数 AI 团队都不愿面对的发现：在一项生成了超过 150,000 个评估实例、涵盖 22 个任务的大规模研究中，大约 40% 的 LLM 作为裁判（LLM-as-judge）的对比显示出可衡量的偏见。这种偏见并非随机噪声，而是系统性的、可复现的，并且与模型的训练方式相关。当你使用一个模型来生成评估集，然后使用同一个模型（或其近亲）来对其进行评分时，你测量的并不是质量，而是一个系统与其自身的一致程度。

合成评估数据之所以成为标准实践，是有充分理由的。人工标注速度慢、成本高且难以规模化。LLM 生成的测试用例让团队能够在夜之间生成数千个示例。问题出现在生成器和裁判拥有共同祖先时——在 2025 年，这几乎是常态。结果是一个评估流水线在自信地报告高分的同时，却隐藏了你构建它原本想要捕捉的失败模式。

一对 LangChain 分析/验证智能体连续运行了 264 小时，产生了 47,000 美元的 API 费用，却没有任何有用的产出。验证智能体持续拒绝分析智能体的输出，但从未说明原因；分析智能体则默认再次尝试。没有人写过停止条件，循环一直运行，直到有人注意到账单。

这是架构图中从不出现的失败模式：知道如何调用工具，却不知道何时停止的智能体。经典的智能体循环是一个不断询问模型"我应该调用工具吗？"的 while True——但这个问题对"我已经看到足够的信息了"没有内置答案。没有收敛逻辑，你构建的不是智能体，而是一个昂贵的轮询函数。

AI 编程工具的 ROI 宣传在纸面上看起来无懈可击：在受控实验中，开发者完成任务的速度提升了 55%，合并的 Pull Request 数量增加了 98%，每周据称节省 3.6 小时。但当组织审视真实的交付指标——Bug 率、发布周期、故障频率——时，数字几乎没有任何变化。某些东西吸走了所有增益的时间，而它并不难找。

AI 数秒生成代码。工程师的审查速度，却和以前一样慢。