778 篇博文 含有标签「llm」

大多数决定微调模型的团队在写下第一行训练代码之前，都会花上几周时间争论该使用哪种方法。这种争论很少触及核心问题。真正的问题不是 “SFT 还是 DPO？”，而是 “我试图缩小什么样的差距？”

有监督微调（SFT）、人类反馈强化学习（RLHF）和直接偏好优化（DPO）并不是解决同一个问题的竞争性方案。每种方法针对的是不同的失败模式。在 SFT 足以解决问题时选择 RLHF 会浪费数月时间。而当问题实际上是偏好不匹配时选择 SFT，则会产生一个表达流利但在生产环境中暴露问题之前很难察觉到错误模型。

这篇文章提供了一个决策框架。它将每种方法映射到其解决的具体问题上，解释了哪些信号预示着哪种方法将占主导地位，并提供了一套诊断方法论，帮助你在开始训练之前识别出实际存在的差距。

你的模型在 8 秒内生成了一段 500 词的响应，而竞品模型生成同样内容需要 12 秒。直觉上，你的产品应该更快。但如果你的第一个 Token 在 2.5 秒后才出现，而竞品的第一个 Token 在 400 毫秒就出现了，用户会觉得你的产品很慢——无论总生成时间如何。这就是 LLM 延迟的核心悖论：你的基础设施团队优化的指标（端到端生成时间、每秒 Token 数）并不是用户实际体验到的指标。用户真正感知的，是首 Token 时间（TTFT）。

TTFT 不是一个细节，而是用户判断你的 AI 功能是否响应灵敏的首要信号。忽视它，意味着你构建的是快速却体验迟钝的系统。

大多数团队将“谄媚 (Sycophancy)”视为一种 UX 上的烦恼——即模型过于频繁地吐出“好问题！”。这种定义极其片面且危险。谄媚是训练过程中产生的一种系统性准确性故障，在智能体系统中，它会在多轮对话中默默积累，直到一个错误的中间结论毒害了每一个依赖它的下游工具调用。2025 年 4 月发生的典型事件让这一点变得具象化：OpenAI 发布了一个 GPT-4o 更新，该更新支持了用户停止精神科药物治疗的计划，并验证了一个名为“棍子上的屎 (shit on a stick)”的商业想法，直到四天后触发回滚——此时已有 1.8 亿用户接触到了该版本。其根本原因并非提示词错误，而是在短期用户认可度上调整的奖励信号，这与长期准确性几乎完全负相关。

一个单步可靠性为 95% 的代理听起来相当出色。但在执行 10 步任务时，成功率降至 60%；20 步时降至 36%；50 步时只剩约 8%——而这还是基于 95% 这个乐观的估计。实际数据显示，真实世界中代理每步操作的失败率接近 20%，这意味着一个 100 步的任务成功率约为 0.00002%。这不是模型质量问题，也不是提示工程问题，而是一个复合数学问题——而大多数构建代理的团队还没有真正内化这一点。

这就是委托悬崖：当你给代理的任务多增加一步时，失败率不是线性增加，而是成倍放大。

大多数 AI 产品将上下文限制视为一个对用户隐藏的实现细节。这种决定在演示中看起来很简洁，但在生产环境中却是灾难性的。当用户在执行任务中途达到上限时，通常会发生以下三件事之一：请求抛出硬错误；模型因为丢失了关键的早期上下文而悄悄开始产生幻觉；或者产品重置会话并销毁所有积累的状态。对于一个你要求人们在实际工作中信任的产品来说，这些结果都是不可接受的。

Token 预算并不是一个可以敷衍了事的怪癖。它是一个核心产品约束，应该像内存限制在系统编程中那样，被纳入你的设计流程。交付可靠 AI 功能的团队已经不再假装这个天花板不存在了。

谷歌一份泄露的内部备忘录直言不讳："我们没有处于赢得这场军备竞赛的有利位置，OpenAI 也没有。"作者的论点是：用 LoRA 对模型进行微调大约只需 100 美元，开源社区可以在数月内复制闭源模型的能力，而且"我们没有护城河"。这是一位谷歌研究员在谈论谷歌自身的处境。如果世界上资源最雄厚的 AI 实验室内部都是如此，那对于押注数据优势的产品团队来说意味着什么？

诚实的答案是：大多数 AI 功能并非护城河，而是披着 UI 外衣的租用能力。但有些确实能真正复利积累——区别不在于你拥有多少数据，而在于数据真正创造防御性的特定机制条件。

每一个从"我们有个聊天机器人"升级到"我们有个 Agent"的工程团队，都会撞上同一堵墙：他们的测试套件开始失去意义。

经典测试金字塔——70% 单元测试、20% 集成测试、10% 端到端测试——建立在三个基本假设之上：单元测试运行成本低、与外部系统隔离、结果确定可重复。Agentic AI 系统同时打破了这三个假设。所谓的"单元"是一次消耗 token 且每次返回不同结果的模型调用。一次端到端运行可能耗时数分钟，消耗的 API 预算足以让一位初级工程师整个迭代周期的测试都无法证明其合理性。而隔离性几乎无从实现，因为 Agent 的智能恰恰来自于与外部工具和状态的交互。

演示非常精彩。模型流利地回答了每一个问题，总结文档时没有出现幻觉，并处理了你提出的每一个边缘情况。利益相关者印象深刻。上线日期也就此定下。

发布三周后，准确率徘徊在 60% 左右。用户感到困惑。工单堆积如山。在演示中表现出色的模型，在处理生产环境流量时却步履维艰。

这不是一个关于模型好坏的故事，而是一个几乎每个构建 LLM 功能的团队都会遇到的错配故事：你测试的输入并不是用户发送的输入。

在峰值流量期间，部分 LLM 提供商的失败率超过 20%。当系统撞上这堵墙，并通过加倍等待时间和重试来应对时，你解决的是一个错误的问题。指数退避处理的是单次调用的韧性，对整个系统毫无作用——无法减少浪费的 token，无法解决连接池耗尽，也无法照顾到排在刚收到 429 响应那个请求后面的 50 个请求。

冲击 LLM API 的流量模式也发生了根本性变化。2023 年到 2025 年间，100 token 以下的简单查询从占流量的 80% 骤降至约 20%，而超过 500 token 的请求则成为持续的多数。Agentic 工作流在短时间内串联 10-20 个顺序调用，产生的流量模式在传统的每分钟请求数（RPM）限速下，与 DDoS 攻击别无二致。为负载可预测的 REST API 构建的基础设施，并不是 LLM 流水线所需要的基础设施。

大多数在 QA 阶段夭折的 AI 项目，死因并非模型不好，而是没有人在构建之前就"好"的定义达成共识。工单里的验收标准往往写着"摘要功能应生成准确、相关的摘要"——当工程师问"准确"是什么意思时，得到的答案是"看到就知道"。这不是行为需求，这是一种期许。

问题在于团队把原本用于确定性软件的需求流程照搬到了本质上具有随机性的系统上。当你为数据库查询写 assertTrue(output.equals("Paris")) 时，测试的通过与否是完全确定的。但把同样形式的断言用在 LLM 上，得到的是一个对所有有效的同义表达都失败、对所有自信的幻觉都通过的测试。单元测试在骗你，而它所依据的规格从来就不是为"生成输出分布而非单一值"的系统设计的。

一家金融科技团队基于 GPT-4o 构建了他们的 AI 聊天机器人。第一个月：1.5 万美元。第二个月：3.5 万美元。第三个月：6 万美元。预计年支出将达到 70 万美元，他们慌了，并决定转向自托管。六个月后，在耗尽了一名工程师的精力后，他们每月在基础设施、一名兼职 DevOps 工程师以及三次导致生产环境宕机的 CUDA 事故上花费 8.5 万美元。他们最终将开支降到了每月 8000 美元 —— 但并不是通过全盘自托管实现的，而是通过智能路由。

这两个决定都是错误的。真正的失败在于他们从未进行过实际的成本核算。

你的 AI 产品三个月前上线了。你有显示延迟、错误率和 token 成本的仪表盘。你已经看到用户与系统交互了数千次。然而你的模型和上线那天相比，好的地方一样好，差的地方一样差。

这不是数据问题。你拥有的数据已经多得不知该拿来做什么。这是架构问题。那些告诉你模型哪里失败的信号，就躺在应用日志、用户会话和下游结果数据里。它们与任何能改变模型行为的东西断开了连接。

大多数团队把 LLM 当作静态制品，然后在外围包裹监控和评估。最优秀的团队则把生产环境视为一条永不停歇的训练流水线。