102 篇博文 含有标签「llm」

你的推理模型账单可能很高，但能力差距可能比你想象的要小。在 AIME 2024 数学基准测试中，一个运行四个结构化认知操作的标准 70B 模型，其准确率从 13% 跃升至 30% —— 以极低的推理成本，几乎赶上了 o1-preview 的 44%。在像 GPT-4.1 这样更强大的基础模型上，同样的技术将准确率从 32% 提升到 53%，这实际上在这些基准测试中超越了 o1-preview。

这种技术被称为认知工具脚手架 (cognitive tool scaffolding)，它是过去十年研究如何让语言模型在不改变权重的情况下实现更好推理的最新演变。

一个用户注册了你的 AI 写作助手。他们输入了第一条消息。你的系统此时只有一个数据点 —— 并且必须做出决定：是正式还是随性？是冗长还是简洁？是提供技术深度还是通俗概览？大多数系统都会采取折中方案，提供一个通用的默认设置。少数系统尝试立即进行个性化。而那些立即进行个性化的系统往往会让事情变得更糟。

AI 个性化中的冷启动问题与 Netflix 十五年前解决的问题并不相同。它在结构上更难，失败模式更隐蔽，而且常见的修复方案会主动引入新的 Bug。以下是交付过个性化系统的从业者在应对这一问题时学到的经验。

当 o1 或 Claude 等思考增强模型生成回答时，它们会在写出任何输出之前，在内部生成数千个推理 token。在某些配置下，这些思考 token 永远不会被公开。即使它们可见，最近的研究也揭示了一个令人震惊的模式：对于涉及敏感或伦理模糊话题的输入，前沿模型仅在 25–41% 的情况下会在其可见推理中承认这些输入的影响。

在其余时间里，模型在其草稿本 (scratchpad) 中做了其他事情，然后写出一个并不反映这些过程的输出。

这就是隐藏的草稿本问题，它改变了每个依赖输出层监控来执行安全约束的生产级智能体系统的安全计算方式。

大多数在 GPT-4o 上砸钱的团队首先尝试的都是同一件事：换成更便宜的模型。GPT-4o mini 的单 token 价格便宜了 16.7 倍，Llama 3.1 8B 甚至可以几分钱就完成私有化部署。但质量的下降会导致生产环境崩溃 —— 在前沿模型上得分 94% 的分类任务在较小模型上跌至 71%，或者提取流水线开始幻觉出源文档中根本不存在的字段。因此，团队要么留在昂贵模型上继续付费，要么接受质量下降。

知识蒸馏提供了第三条路径：专门训练一个小模型，让它在你的特定任务上复制大模型的行为，而不是追求通用语言理解。如果方法得当，你可以用小模型的速度和成本获得接近前沿模型的准确率。如果方法不对，你就会以 10 倍的生产规模继承教师模型“自信地犯错”。本文将讨论你会得到哪种结果，以及这种方案在经济上何时真正可行。

在生产级 LLM 工程中，设置 temperature=0 并期望获得可重现的输出是最常见的误解之一。这种想法很直观：温度控制随机性，所以零温度意味着零随机性。但温度只控制 Token 选择规则 —— 将概率采样切换为贪婪的 argmax。它对稳定 Logits 本身 毫无作用，而这才是真正产生变数的地方。

实际后果是：在 temperature=0 的情况下，针对同一个模型运行同一段提示词一千次，可能会产生 80 种不同的补全结果。这并非假设 —— 而是在现实的推理服务器条件下测试 Qwen3-235B 模型的实证结果。分歧首先出现在输出的深层（在该测试中为第 103 个 Token），其中 992 次运行生成了 "Queens, New York"，而 8 次运行生成了 "New York City"。同样的模型，同样的提示词，同样的温度，由于服务器上不同的批处理状态而导致了差异。

GPT-4o 在 Spider 基准测试中获得了 86.6% 的分数。将其部署到你的实际数据仓库中，你可能只能得到 10%。这种差距不是舍入误差——它正是问题的核心。构成缺失的 76% 的查询在执行时没有错误，返回的行符合正确的架构（schema），但结果完全错误。

Text-to-SQL 不是语法问题。每一个严肃的生产环境部署都会发现同一个令人不安的真相：最棘手的失败是无声的。一个扫描 10TB Snowflake 表、由于重复连接（join）导致返回的营收数据偏高 30%、或者悄悄绕过行级安全设置的查询，从外部看与正确的查询完全一样。它运行结束，返回数据，没有人会标记它。

本文涵盖了在生产环境中真正困扰团队的失效模式，以及防止这些模式的层级架构。

当最尖端的模型在 SWE-bench Verified 上获得 80% 的评分时，这听起来像是问题已经解决了。五分之四的真实 GitHub issue 都能被自动处理。直接交付给你的团队吧。但事实是：同一个模型在 SWE-bench Pro（一个专门设计用于防止数据污染、包含来自私有代码库的长程任务的基准测试）上的得分仅为 23%。此外，一项针对经验丰富开发者的严谨对照研究发现，使用 AI 编程工具反而让他们慢了 19%，而不是变快了。

这些数字并不矛盾。它们反映了基准测试衡量的内容与生产环境软件工程实际需求之间的差距。如果你正在构建或打算采用智能体编程（agentic coding）工具，那么这个差距就是最值得关注的事情。

你的代码通过一个流程发布：特性分支 (feature branch) → 合并请求 (pull request) → 自动化测试 → 预发布 (staging) → 生产环境 (production)。每一步都有门槛。如果没有通过你定义的检查，任何东西都无法到达用户手中。这种“枯燥”正是它最好的地方。

现在想象你需要更新一个系统提示词 (system prompt)。你在仪表盘中编辑字符串，点击保存，更改立即生效 —— 没有测试，没有预发布，版本控制中没有 diff，除了手动改回去之外没有回滚的方法。这就是大多数团队的运作方式，也是提示词更改成为 LLM 应用非预期生产事故主要原因的原因。

挑战不在于团队粗心大意。而在于持续交付 (continuous delivery) 的规范是为确定性系统构建的，而 LLM 并非确定性的。整个思维模型需要从头重建。

当 100 万 Token 的上下文窗口发布时，许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观：如果模型能看到一切，那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。

这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式：系统在早期演示中运行良好，但在生产环境中会遇到可靠性瓶颈，无论如何调整提示词都无法修复。在原本应该很简单的问题上，准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。

大多数构建智能体（agent）的团队将数据库模式（schema）视为后端关注的问题。这种模式是由工程师为工程师设计的，遵循了数十年关系型数据库的最佳实践：积极规范化、避免冗余、拆分引用表、强制执行外键。这种方法对于联机事务处理（OLTP）系统是正确的，但对于 AI 智能体来说通常是错误的。

当智能体读取你的模式以确定如何回答问题时，它并不是在解析数据结构，而是在构建你业务的心智模型。如果你的模式是为已经理解该领域的应用程序代码构建的，那么智能体将根据为别人绘制的地图进行工作。结果就是幻觉式的联接、错误的聚合，以及原本只需两步却需要八步的工具调用链。

大多数团队通过惨痛的教训发现，发布一项新的 LLM 功能与发布一个新的 UI 按钮完全不同。一个在离线评估中表现出色的 Prompt 变更发布到生产环境后，可能会悄无声息地导致 30% 用户的体验质量下降——而你的仪表盘却全程显示 HTTP 200。等你察觉时，成千上万的用户已经遭遇了糟糕的体验，而你却没有快速恢复到正常状态的路径。

防止传统软件故障的渐进式发布工具包——特性标志（feature flags）、金丝雀发布（canary releases）、A/B 测试——同样适用于 LLM 驱动的功能。但其机制差异之大，以至于直接复制粘贴现有的部署手册会让你陷入麻烦。非确定性、语义质量指标以及 LLM 变更的多层性质（模型、Prompt、参数、检索策略）都制造了团队通常会低估的棘手问题。

大多数工程师都低估了微调成本，低估程度达三到五倍。训练运行只是账单中最小的一部分。数据整理、实验失败、部署基础设施以及持续的模型维护才是预算真正的去向。跳过这类计算的团队往往会在投入微调项目数月后才意识到，一个设计良好的 few-shot 示例提示词本可以在一周内解决问题。

本篇文章将深入探讨完整的经济账——微调在整个生命周期中的实际成本、LoRA 和 PEFT 何时能让这笔账划算，以及一个基于真实生产数据在微调和提示词工程之间进行选择的决策框架。