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

Most RAG 的实现都以同样的方式失败：向量搜索检索到了看起来合理但并非用户真正需要的内容，LLM 用自信的辞令对其进行包装，最终用户得到一个大体正确但细节错误的答案。令人沮丧的是，这种失败模式是隐形的 —— 余弦相似度分数看起来很正常，检索到的片段也提到了正确的主题，但答案仍然是错的，因为问题需要跨关系进行推理，而不仅仅是语义上的接近。

向量嵌入 (Vector embeddings) 擅长一件事：找到听起来 像 你查询内容的文本。这是一种强大的能力，涵盖了极广的生产用例。但当问题取决于实体之间如何 连接（而非它们的描述有多匹配）时，这种方式就会出现可预见的失效。对于这类查询，知识图谱 —— 一种你可以通过 Cypher 或 SPARQL 遍历的属性图 —— 不仅仅是一种优化。它是一种从根本上不同的检索方式，解决的是另一类问题。

我尊重的一位资深分析师这样描述她的团队在使用大语言模型 (LLM) 驱动的分拣代理的前六个月：“它让简单的告警消失了，却让复杂的告警变得更难信任。”这句话一直让我记忆犹新，因为它捕捉到了这项权衡的本质。安全运营中心 (SOC) 中的 AI 并不是一个关于效率提升的故事。它是一个关于信心校准的故事，而大多数团队都在朝着同一个错误的方向进行校准。

诱人的版本是：在告警队列前放置一个模型，让它聚类重复项、总结原始事件并自动关闭明显的噪音。MTTR（平均响应时间）图表下降了。寻呼机安静了。一级告警积压蒸发了。而真正导致你被入侵的版本是：模型自信地将一次真实的入侵误判为无害的备份作业，而一名疲惫的分析师——被告知“AI 已经分拣过了，没问题”——甚至从未打开过这个案例。第一个版本是真实的，第二个版本也是。它们是同一个系统在不同信心水平下的表现。

一个团队花了三周时间集成一个基础模型，将收到的支持工单分类到不同的路由类别中。该模型在测试中达到了 87% 的准确率。他们发布了。六个月后，一名工程师注意到 70% 的工单在主题行中包含产品名称，而一个简单的查找表就能以 99% 的准确率处理这些工单。LLM 正在处理那困难的 30%，而在其余时间里则在胡言乱语。

这并非一个少见的故事。之所以会发生这种情况，是因为团队将“使用 LLM”作为首选的实现方案，而不是最后的手段。解决方法是设立一个强制性的关卡：在被允许构建 AI 版本之前，你的 AI 功能必须先输给一个笨规则。

你的摘要步骤判断出客户投诉是关于账单的。你的提取步骤提取出了“订阅层级：Pro”。你的生成步骤写了一封跟进邮件，提到了他们的“Enterprise 方案”。三次 LLM 调用，一个流水线，一个完全错误的输出 —— 而且整个过程中没有触发任何错误。

这就是多模型一致性失效：复合 AI 系统的无声杀手。它看起来不像是一个异常。它不会触发你的错误率 SLO。它只是自信地向用户发布错误的内容。

你的 AI 功能在上线时通过了所有评估。六周后，与其交流最频繁的用户群体的流失率翻了一倍，而你的 CSAT 仪表板却显示出一条无人能解释的平线。提示词（Prompts）没有变，模型没有更换，检索索引增长了，但没人觉得它坏了。上线时的表现第一轮（turn one）很好。真正变质的是在第 400 轮、第 17 次会话、注册三周后发生的事情。

大多数团队的评估套件无法察觉到这种失败。他们测试的是固定数据集上的单轮准确性，如果有追求的话，可能会测试单次会话中的多轮对话，然后就宣布该功能可以上线。真正重要的失败模式——即随着系统积累用户状态而质量下降——存在于评估工具从未设计去覆盖的时间维度中。在记忆研究文献中，研究人员称之为“自我退化”（self-degradation）：在初始阶段之后，受记忆膨胀（memory inflation）和错误记忆累积的驱动，性能出现明显且持续的下降。生产工程师则将其称为留存用户群无声流失的原因。

每篇智能体教程都从单个用户、单个会话和单个上下文窗口开始。智能体读取状态、推理、行动、写回。清晰、确定。对于团队实际使用的场景来说，这种假设完全错误。

真实的协作产品——共享规划看板、多用户支持队列、文档协作副驾驶、团队项目助手——需要多个用户同时与同一个智能体交互。当两个人在同一秒内向智能体发出相互矛盾的指令时，其中一个人的修改就会消失。智能体不会告诉他们，甚至自己都不知道发生了什么。

这就是多用户共享智能体状态问题，它是一个披着AI外衣的分布式系统问题。

大多数 LLM 工程经验 —— 缓存提示词、调整温度、控制 token 预算 —— 都假设输入是文本、输出也是文本。一旦加入图像、PDF 或音频，这些经验几乎全部失效。预处理方式不同，故障模式不同，成本模型也不同。而你为文本流水线构建的评估套件，根本发现不了新出现的问题。

企业知识中约有 50% 存储在非文本格式中：PDF、幻灯片、扫描表单、产品图像。当团队尝试处理这些数据时，他们会发现，引入多模态不仅仅是增加一种模态 —— 而是增加了一个全新的工程复杂度层面。

告警在凌晨 2:47 响起。面向客户的聊天助手正为一半的付费用户返回 429 错误。工程师们在仪表板中忙乱寻找，试图找到那天下午发布的 Bug。他们一无所获 —— 代码没问题。真正的罪魁祸首是另一个团队在当晚启动的批量摘要任务，它共享了同一个供应商 API 密钥，耗尽了该账户接下来四小时的每分钟 Token 预算。没有人拥有这个共享密钥，也没有人负责这个限制。

这就是“喧闹邻居”（noisy-neighbor）问题。与经典的 API 配额事故不同，它在 LLM 系统中表现出一种独特的残酷性。一个达到速率上限的 REST 端点会迅速失败并进行重试；而 LLM 的“每分钟 Token”（TPM）桶是根据请求内容非对称消耗的。因此，一个生成 8K Token 的功能可能会使一个进行低成本 200 Token 分类调用的功能陷入饥饿，而这一切在请求计数图表中甚至都不会显现。流量在你所测量的维度上并不“喧闹”。

大多数团队发现这一点的方式正如上文提到的团队：一个无关团队的任务与付费用户的会话发生冲突，而两者唯一的共同点只是环境变量中的一个字符串。

你的组织有一份隐私政策。它用合理的措辞描述了用户数据的谨慎处理、保留限制以及对 GDPR 和 HIPAA 的合规。但它几乎肯定没有说明：在任何策略控制生效之前，用户的姓名、电子邮件地址或病史是否以明文形式传输给了托管的 LLM API。

这个缺口——你能指出的隐私政策与你实际能证明的隐私保证之间的距离——正是大多数生产 LLM 系统悄然失守的地方。研究显示，提交给 ChatGPT 和 Copilot 等工具的提示词中，约有 8.5% 包含敏感信息，包括 PII、凭据和内部文件引用。在企业环境中，用户将邮件、客户数据和支持工单粘贴到 AI 辅助工作流程中，这一比例几乎肯定更高。

问题不在于开发者粗心大意。而在于 LLM 提示层从未被设计为数据处理边界。它从上游系统——用户输入、RAG 检索、智能体上下文——继承内容，却不执行治理整个技术栈其他部分的数据分类规则。

几乎所有关于构建 AI Agent 的教程都以同样的方式开场：用户输入消息，Agent 进行推理，Agent 返回响应。这个模型对聊天机器人和副驾驶（Copilot）来说运行良好，却无法描述各组织正在大规模部署的大多数生产 AI 工作。

在企业环境中默默发挥最大价值的 Agent，并不等待消息。它们在数据库行发生变更时唤醒，在队列深度超过阈值时唤醒，在凌晨 3 点的定时任务触发时唤醒，或在监控检测到指标漂移超出范围时唤醒。它们在没有用户在场的情况下行动。一旦失败，没有人会察觉，直到损失已经累积到难以挽回。

构建这类主动型 Agent 需要一套与构建被动式助手截然不同的设计语汇。适用于对话型 AI 的会话（Session）思维模型，在 Agent 循环运行、在后台重试、没有人类兜底的场景下会彻底失效。

上个季度，一家中型AI初创公司的系统提示词中落地了一个单行变更。这个差异看起来无害：一位工程师收紧了关于响应长度的指令。审查者在两分钟内批准了它，就像批准一个变量重命名一样。48小时内，支持工单激增。模型开始在复杂查询的句子中间截断答案，而旧措辞几个月来默默处理的边界情况现在都失败了。原来的指令不仅控制着长度——它隐式地锚定了模型关于何时一个主题已经完成的判断。没有人捕捉到这一点，没有人去寻找它。

这就是当今提示词审查的核心问题：我们正在将代码审查的直觉应用于一个这些直觉大多数是错误的媒介。代码审查之所以有效，是因为被审查的工件是确定性的，语义可以从语法中恢复。提示词两者都不是。它的含义分布在模型的权重、训练数据以及推理时运行的随机采样中。你在屏幕上看到的差异只是你正在批准的变更的一小部分。

大多数团队在采用推理模型时都会做同一件事：把现有的系统提示词复制过去，指向 o1 或带扩展思考的 Claude Sonnet，然后期待模型升级完成剩余工作。基准测试分数上去了，生产准确率却原地踏步——甚至下滑。问题不在模型，而在于提示词的思维模型从未改变。

推理模型的工作方式与指令跟随模型截然不同。那些能从 GPT-4o 榨取性能的策略——精心设计的系统提示词、精选的 few-shot 示例、明确的"逐步思考"指令——都是为另一种推理架构设计的。把这些策略用在推理模型上，恰恰会限制那些让这类模型具有价值的核心能力。

本文是一份实用指南，聚焦于真正重要的差异以及切实有效的调整方法。