639 篇博文 含有标签「llm」

你最优秀的 AI 工程师能凭记忆背诵 Claude 的 XML 格式偏好。他们知道 Claude Opus 拒绝泛化隐式指令，知道少样本示例（few-shot examples）实际上会损害 o1 系列模型的性能，还知道在某些地区，Azure OpenAI 相比直接 API 会增加额外的 8 到 12 秒延迟。这种专业知识花了数月时间积累。它也代表了当今 AI 工程中最被低估的风险之一。

当供应商弃用某个模型或悄然改变行为时，这些知识并不会随之迁移。它会消失。那些围绕单一模型系列构建系统以及组织能力的团队，往往会以惨痛的方式发现这一点。

当你编写系统提示时，脑海中有一个预设的用户形象。也许是一位用简洁英语提出有针对性问题的专业人士，也许是发送简短、范围明确、完全符合提示假设的请求的人。你针对看似具有代表性的示例进行测试，调整直到输出效果令人满意，然后上线。

然后你看到了生产流量。

你的系统提示必须处理的真实查询群体，并非你所设计的中位情形，而是一个分布——有些查询范围狭窄，更多的漫无边际——还有一条长尾，暴露出你指令中每一个隐藏假设。对大多数生产系统而言，15%到30%的真实查询落入提示处理欠佳的类别。令人不安的是：这些失败大多是静默的。系统返回200状态码，用户得到一个看似合理的答案，失败永远不会浮现在你的日志中。

当两个微服务在API假设上出现偏差时，集成测试会在上线前捕获问题。当两个智能体在提示词假设上出现偏差时，你只会在客户收到自相矛盾的答案——或者整条流水线因级联故障崩溃——时才会发现。多智能体AI系统在生产环境中的失败率高达41%–87%。这些失败中超过三分之一并非模型质量问题，而是协调故障：某个智能体改变了输出格式，另一个智能体仍然期望旧的数据结构，而没有人为此写过测试。

根本问题在于，智能体之间通过隐式契约进行通信。一个研究型智能体——在某人的心智模型中——约定返回带有 sources 数组的JSON对象。编排型智能体依赖这个结构。没有人把它写下来，没有人测试它。六周后，研究型智能体的提示词被优化为返回排名列表而非 sources 数组，编排型智能体就悄无声息地丢失了一半输入。

大多数团队发现他们的系统提示词存在冗余问题的方式都如出一辙——一次成本审查、一次延迟激增，或者某位工程师终于从头到尾读了一遍。他们通常会发现一个在六个月内有机增长的 2,000 token 的文档，其中散落着三个不同版本的“保持简洁”，还有指向二月份就已弃用的产品工作流的指令，以及模型在每次运行时都明显忽略的十几条规则。提示词规模庞大，但大部分内容其实毫无用处。

这就是 Prompt 信用分配问题 (Prompt Credit Assignment Problem)：弄清楚一个数千 token 的系统提示词中，哪些指令真正驱动了模型行为，哪些只是消耗 token 并分散注意力的冗余负重。坏消息是，大多数团队完全跳过了这一步——他们在行为出错时添加指令，却从未减少过。好消息是，这有一套可重复的工程准则。

在 2023 年，“提示词工程师”（prompt engineer）是科技领域搜索频率最高的职位名称之一。LinkedIn 上到处都是重新包装个人简介的工程师。招聘信息许诺给那些懂得如何诱导 GPT-4 表现的人六位数的薪水。但职位描述中没有提到的是，其中列出的许多技能已经处于“借来的时间”中——到 2026 年，那些能够分辨出持久技能与衰减技能区别的工程师，最终的境遇将大不相同。

提示词工程的职业陷阱并不在于这个领域消失了，而在于它变化太快，以至于在 12 个月内建立的技能到第 18 个月就变成了负资产。那些在错误的层面过度投入而忽视了正确层面的工程师发现，随着下一个模型版本的发布，他们所掌握的专业知识变得毫无意义。

有一种特定的工程债（Engineering debt）永远不会出现在你的指标中。每当有人在系统提示词（System prompt）中添加一个句子来修复一个偶发的投诉——比如 “绝不讨论竞争对手的产品” 或 “始终以正式的口吻回复” ——而随后又没有人验证模型是否真的执行了它，这种债务就会累积。几个月后，提示词增加到 800 个 Token。它听起来很有权威感，包含的内容包罗万象。但也许其中三分之一根本没起作用。

提示词变异测试（Prompt mutation testing）就是找出那三分之一无效指令的实践。该技术借鉴了软件工程中经典的变异测试：系统地在代码中引入微小、刻意的错误，以确定你的测试套件是否真的能捕获它们。在这里，你向系统提示词中引入刻意的扰动——删除一个分句、抵触一条规则、用近义词替换关键关键词——并衡量模型的输出实际发生了多大变化。那些在扰动下幸存且不影响行为的指令是装饰性的。而那些一旦被触碰就会导致出错的指令则是承重的（Load-bearing）。

某家产品公司的团队为市场部门构建了一款头脑风暴助手。他们在文档语料库——营销简报、品牌指南、竞品分析——上添加了 RAG，认为更丰富的上下文会产出更好的创意。三周后，使用率下降了。定性反馈如下：输出"太安全"、"太可预测"、"感觉只是在重混我们现有的东西"。他们从头脑风暴功能中移除了检索。创意改善了，参与度也恢复了。

这种模式在实践中出现的频率远比人们承认的要高。检索增强生成已成为将 LLM 输出锚定到事实的默认架构，对于事实性任务，它当之无愧。但对于生成类任务——创意构思、创意写作、新颖方案生成——添加检索层可能会悄然压低模型产出的上限。这不是因为检索坏了，而恰恰是因为它按照设计在正常运转。

当法务团队问"AI 为什么拒绝了这笔贷款申请？"时，你的思维链追踪并不是正确答案。就算你有 1200 个 token 的逐步推理过程也没用。他们需要的是一句能在庭审中站得住脚的话——而现在，大多数工程团队根本不知道如何生成这样的解释。

这就是利益相关者解释鸿沟：工程师对模型行为的理解，与监管机构、高管和法律团队完成工作所需的信息之间的距离。弥合这一鸿沟需要一个独立的架构层——而大多数生产 AI 系统从未构建过这一层。

大多数团队对待系统提示词的方式，就像早期 Web 开发者对待 CSS：粘贴一段能跑的代码，小心翼翼地修改以免破坏什么，提交到配置文件，然后祈祷没人动它。接着某位新成员"顺手整理"了一下，模型升级后行为悄然改变，三周后用户提了一个 bug，而没人能复现——因为没人知道上周二那个提示词究竟写的是什么。

这不是工作流问题，而是概念分类的错误。系统提示词不是配置，而是软件接口。只要工程团队还没有如此对待它们，他们构建的 LLM 功能就将持续脆弱、难以调试、无从扩展。

令人惊讶的是，许多 AI 团队一旦获得 o3 级别或 Claude 扩展思考模型的访问权限，就会默认对所有查询启用扩展思考。这背后的逻辑看似显而易见：更智能的推理等于更好的输出，何不始终开启？问题在于，这种逻辑没有考虑到测试时计算扩展在实践中如何运作的基本事实。扩展思考能显著提升特定类型任务的性能，在另一些任务上则会降低质量，并可能将全局推理成本推高 5-30 倍。那些从这些模型中获取最大价值的团队，将推理预算作为一个明确的决策来对待——其重要性不亚于模型选择或提示词工程。

本文阐述了任务分类体系、成本结构，以及将战略性使用思考预算的团队与仅仅为质量幻觉溢价买单的团队区分开来的路由决策框架。

一个团队发布了一款面向用户的 AI 助手。他们将其定价为每席位每月 49 美元，根据一份假设“每次查询平均 500 个 token”的电子表格，目标毛利率为 70%。三个月后，财务部门指出，他们的重度用户在每个会话中消耗了 15,000 个 token。定价模型之所以崩溃，并不是因为功能失败，而是因为产品团队为他们尚不了解的东西定了价。

这并非预测失败。这是一个结构性问题：大模型驱动产品的成本基准与传统 SaaS 定价所设计的处理方式根本不同。每一次 API 调用都有不可预测且实质性的 token 成本。输入因用户、任务和时间段而异。输出以各种方式复合增长，而这些影响直到几周后才会出现在你的云账单上。一旦你引入了智能体模式 (Agentic patterns) —— 工具调用、多轮推理、子智能体编排 —— 单次用户交互的成本可能是 0.02 美元，也可能是 20 美元，这完全取决于模型的决定。

大多数构建 AI 智能体的团队，都会在第五个迭代周期发现同一个问题：智能体再也无法可靠地选对工具了。十个工具时，基本还能用。二十个时，准确率开始下滑。五十个时，你会亲眼看着智能体在应该调用 update_record 的时候调用了 search_documents，而日志毫无解释。常见的反应是调整工具描述——加更多上下文、写得更明确、重写示例。这偶尔有效，但它绕开了根本原因：平面嵌入检索在大型工具库中架构上就是错的，更好的描述无法修复一个架构问题。

工具选择本质上是检索，而检索有已知的扩展上限。理解这些上限——以及绕过它们的结构化元数据模式——是让智能体系统在生产中稳定运行与需要持续人工维护之间的分水岭。