702 篇博文 含有标签「llm」

Andrej Karpathy 直言不讳：AI 实验室正在"过拟合"Arena 排行榜。某头部实验室在公开发布前私下评估了 27 个模型变体，只发布了表现最佳的那个。研究人员估计，仅凭选择性提交就可以将排行榜分数人为提高多达 112%。所有人都视为基准真相的众包评估系统已经成为博弈目标——一旦成为目标，它就不再是有效的衡量标准了。

这就是古德哈特定律在发挥作用：当一个指标成为目标时，它就不再是好的指标。这一规律在经济学和政策领域已被充分理解了数十年。在 LLM 工程中，它正在实时摧毁评估套件，而构建这些套件的团队往往浑然不知。

大多数运行 LLM 推理的 GPU 集群正在浪费 30% 到 50% 的可用算力。这并非因为工程师粗心，而是因为调度问题本身极为困难——而大多数团队首先想到的工具根本不是为此设计的。

标准做法是搭建 Kubernetes，为每个 Pod 申请完整的 GPU，然后让调度器自行处理。这对训练任务运行良好。但对于处理异构模型集合的推理场景，这种方式会悄悄摧毁利用率。一个运行三个不同 7B 模型且流量稀疏的集群，每个 GPU 的实际繁忙时间可能不足 15%，同时却处于完全"已分配"状态，拒绝调度任何新任务。

根本原因在于 Kubernetes 理解 GPU 的方式与 LLM 推理实际需求之间的错配。

你的智能体通过了所有单元测试，完美处理了正常路径，然后在某个周二下午，它试图调用 get_user_preferences_v2——一个在你的代码库中从未存在过的函数。这个调用在语法上看起来完全正确。参数也很合理。唯一的问题是，你的智能体凭空捏造了这一切。

这就是幽灵工具调用：一种不表现为错误文本而表现为错误操作的幻觉。与人类可能在审查中发现的事实幻觉不同，幽灵工具调用会直接命中你的运行时，抛出一个晦涩的 ToolNotFoundError，并使原本运行正常的多步骤工作流脱轨。

每个部署 LLM 路由的团队都是同样的起步方式：按价格排列模型，将简单查询发送给便宜的模型，复杂查询发送给昂贵的模型，然后庆祝成本降低了 60%。六周后，有人发现合同分析准确率从 94% 降到了 79%，编码助手开始虚构不存在的 API 端点，复杂支持工单的客户满意度直线下滑——而路由仪表盘上仍然显示"质量保持 95%"。

问题不在于路由本身。问题在于，仅优化成本的路由将所有质量下降视为等同，而实际上你降级的那些查询恰恰是质量最重要的那些。

大多数 AI 功能用自然语言描述需求，也用自然语言进行评估。产品经理写下"助手应当给出有帮助的回复，并避免有害内容"。工程师上线了一个 Prompt，演示时的输出看起来符合要求。团队在站会上达成共识，却在上线时产生分歧——边缘案例浮现，不同工程师对同一输出的评判各异，而"有帮助"这个词，不同评审者的理解竟有七种之多。

这不是工具问题，而是翻译问题。规格说明一直停留在抽象层面，评估标准从未被具体化。Spec-to-Eval 是一门在编写第一个 Prompt 之前，将英文需求转化为可证伪标准的方法论——提前做这件事，将从根本上改变迭代速度。

2024年，加拿大航空的聊天机器人凭空发明了一项并不存在的丧亲票价退款政策。法院裁定该公司须对机器人的言论负责。根本原因并非传统意义上的模型幻觉——而是优先级反转。系统提示写着"乐于助人"，实际政策写着"遵循已记录的规则"。当用户询问赔偿问题时，模型悄悄地将"高效解决问题"置于"升级投诉"之上，而没有人在这一判断影响公司之前对其进行审计。

这就是利益相关者提示冲突问题。每个生产级LLM系统都至少有三个指令来源：平台层（安全约束和基础模型行为）、业务层（运营商定义的规则、合规要求、品牌声音）以及用户层（实际请求）。当这些层相互矛盾时——它们终将矛盾——模型会选出一个胜者。问题在于，这个选择是由你的工程团队有意为之，还是模型在无人察觉的情况下自行决定的。

大多数 AI 产品把单个功能做对了，却把产品整体做错了。搜索返回了合理的结果，摘要表述连贯，对话助手给出了合理建议。但当用户搜索"小团队最佳方案"、在侧边栏看到推荐、向助手追问后续问题，再阅读自动生成的选项摘要——而这四者相互矛盾时——没有一个功能还能让人信任。这就是环境 AI 一致性问题：不是孤立的幻觉，而是产品层面的矛盾。

这种失败模式足够隐蔽，以至于团队往往完全忽视它。单个功能的评估指标看起来还不错。搜索团队衡量召回率和精确率，摘要团队衡量忠实度，对话团队衡量任务完成率。但没有人衡量产品各 AI 功能之间是否在讲述同一个事实的同一个故事。

大多数团队发布第一个 AI 功能时都会使用最好的模型，因为演示（demo）就是在那上面跑的，而且没人有时间深入思考。接着第二个功能也用了同样的模型。然后是第三个。六个月后，每个功能的每次调用都指向了前沿层级（frontier tier）——而账单比实际需要的数额高出五到十倍。

令人不安的事实是，你的生产系统处理的 40%–60% 的请求根本不需要前沿级别的推理。它们只需要称职的文本处理。而购买称职的文本处理服务的成本要低得多。

2021 年，GPT-3 的价格是每百万 token 60 美元。到 2026 年初，同等性能的模型只需 0.06 美元。三年内降价 1000 倍。与此同时，企业 AI 支出增长了 320%——从 115 亿美元攀升至 370 亿美元。而在 AI 上花费最多的那些组织，恰恰正是从价格下降中受益最大的那批人。

这并不矛盾。这就是杰文斯悖论（Jevons Paradox），而它正在侵蚀你的 AI 预算。

几乎每个 AI 产品在达到数十万活跃用户时都会出现一种模式：团队开始增加个性化——在每个 Prompt 中注入用户历史、偏好信号和行为数据——然后看着产品略微变好，而基础设施账单却大幅增加。当他们最终拉取日志并衡量每增加一个 token 带来的质量增量时，曲线的形状几乎总是一样的：早期增益陡峭，随后进入漫长的平台期，最后是你支付全价却只能换来微乎其微的回报。

大多数团队只有在深陷泥潭时才会进行这种分析。这篇文章将探讨为什么这个陷阱会存在，个性化在何处停止产生回报，以及在生产环境中真正有效的架构是什么样的。

你写了一个清晰的系统提示词。在测试环境中验证通过后，你将它部署上线了。三周后，一名用户发现你的安全约束并不能稳定触发——不是因为什么精妙的越狱手段，而是因为你在上个迭代中新增了一个400 token的上下文块，恰好把那条约束顶到了后面。模型就这样……忘了它的存在。

这就是指令位置问题——它不是你提示词里的一个bug，而是基于Transformer的模型处理序列的结构性属性。你提示词中的每一个token，并非获得相同的注意力权重。你放置指令的位置，以一种可量化的方式，决定着模型是否会遵从它。

你的模型写出了一份详细、结构清晰的分析报告。每个句子在语法上无懈可击，内部逻辑自洽。它引用的具体事实也都是准确的。然而结论却是错误的——不是因为模型缺乏得出正确结论所需的信息，而是因为它在开始推理之前就已经决定好了答案。

这不是幻觉。幻觉是模型凭空捏造事实。伪造问题更为隐蔽，在生产系统中也更难被发现：模型先得出结论，再构建一条听起来合理的证据链来支撑它。事实是真实的。综合分析却是谎言。