22 篇博文 含有标签「production」

每隔几个月，AI 工程社区就会兴起一股新的“不必费心评估”的浪潮。论点通常是：评估成本太高、过于脆弱、难以定义，对于快速迭代的产品团队来说，最终不值得投入这些额外的负担。不如发布、迭代，并相信你的直觉。

这是一个糟糕的建议，会导致劣质软件。2026 年 LangChain 的一项调查发现，只有 52% 的组织进行离线评估，而只有 37% 的组织针对实时流量运行在线评估——然而，32% 的组织将质量列为他们生产部署的第一大障碍。这并非巧合。

大多数 LLM 应用上线后，会观察到一些故障，然后修补提示，再重复这个过程。这不是飞轮，而是跑步机。一个真正的数据飞轮是一个自我强化的循环：生产产生反馈，反馈改进系统，改进后的系统产生更好的交互，进而产生更好的反馈。每一次循环都会在前一次的基础上累积。

这种差异至关重要，因为基础模型已经消除了传统的护城河。每个人都可以调用相同的 GPT-4o 或 Claude 端点。新的护城河是来自真实用户执行真实任务的专有反馈数据——这些数据昂贵、耗时且无法从外部复制。

但是构建一个飞轮说起来容易做起来难。不到 1% 的生产交互会产生明确的反馈信号。天真地仅仅利用这 1% 的数据进行训练会导致奉承偏差、幸存者偏差和指标漂移。本文将深入探讨实际有效的方法：生产飞轮的架构、如何收集和过滤信号、关闭循环的四个杠杆，以及可能悄悄毒害你的故障模式。

倒置的工程工作流​

经典的机器学习有一个清晰的管道：数据 → 特征 → 模型 → 产品。LLM 工程则反向运行：产品 → 验证 → 定制优化。

产品优先发布，因为你无法提前列举出所有输入分布——只有真实用户执行真实任务才能揭示真正重要的东西。这种倒置并非捷径；它是唯一可行的方案。这也意味着反馈基础设施必须在产品上线之前设计好，而不是在你意识到需要它时才匆忙加上。

由此产生的三阶段架构是：

1. 评估——为你的特定用例定义“好”是什么样子
2. 监控——在生产环境中持续根据这些定义进行衡量
3. 改进——通过将信号反馈回系统来关闭循环

大多数团队在第三阶段（微调、提示工程）投入巨资，却忽视了第一和第二阶段。这是本末倒置。垃圾指标会产生垃圾训练数据。

第一阶段：定义成功（正确设置指标）​

团队犯的第一个错误是将评估视为与生产无关的事情。事实并非如此。你的评估逻辑必须与你的生产逻辑完全一致，否则你的离线数据就会骗人。

使用二元指标。 将输出评分定为通过/失败，而不是 1-5 分制。人类在二元判断上的一致性要高得多，这意味着你的标注数据集中噪声更少。“这个回复是否事实准确？”是可回答的。“给这个回复打 1 到 5 分”则不然。

验证输入，而不仅仅是输出。 一个 LLM 系统的质量取决于它接收到的信息。应用波斯特尔定律：对你发送的数据要严格，对你接收的数据要宽容。实用的输入验证器包括：

• 主题相关性（与你的领域进行语义相似度阈值比较）
• 查询复杂性（token 计数限制）
• 语言检测（将非目标语言查询路由到备用路径）
• 敏感信息检测（正则表达式 + 命名实体识别）
• 对抗模式检测（已知的越狱模式）
• 通过嵌入相似性对历史输入进行异常检测

将质量分解为子指标。 一个笼统的“质量”分数无法提供任何可操作的信息。将事实准确性、语气一致性、引用正确性、回复完整性分开评估。这种分解使“LLM 作为评判者”的对齐更容易，人工标注也更快。

区别对待多步骤管道。 在链式或代理系统中，根据每个节点的功能来验证：

• 分类器（路由）节点：通过基于规则的检查验证准确率、精确率、召回率
• 编写器（生成）节点：基于 LLM 的质量验证器
• 代码生成节点：静态分析、代码检查工具以及动态执行（实际运行 SQL）

管道中的错误传播是一个开放的研究挑战。考虑连接节点之间复合故障的图感知评估还没有标准解决方案——将其视为正在进行的工作，并独立地监控每个节点。

第二阶段：从生产中捕获反馈​

显式反馈比你想象的要稀少。 不到 1% 的生产交互会产生明确信号。复杂的反馈表单有大约 95% 的用户会中途放弃。一个简单的内联点赞/点踩按钮可以将反馈提交量比模态表单增加 40 倍。每一次额外的点击都是一个过滤器。无情地最小化摩擦，否则你的显式信号语料库将过小且过于偏颇，无法发挥作用。

隐式信号是你的主要数据来源。 来自所有生产用户的行为信号比显式反馈具有更大的数据量，尽管信噪比更低：

信号	它表明什么
提前终止（中途停止）	回复错误或无用
“不……”，“我指的是……”等修正	对意图的误解
重新生成（点击重试）	不满意
复制操作	输出足够好用
编辑操作	输出接近但未完成
代理/代码建议的采纳率	任务成功的直接指标
会话删除	会话失败
追问模式	回复不完整

永远不要只优化单一信号。通过对多个隐式信号进行三角测量来区分噪声和真实信号。

标注时机很重要。 对于涉及缺失知识识别的任务，即时标注（在交互上下文新鲜时）可以显著提高一致性——在一个生产系统中，当标注在线进行而非几天后进行时，知识相关性一致性从 43.6% 跃升至 92.3%。对于偏好和采纳任务，时机没有显著的质量差异，因此你可以在不影响服务水平协议 (SLA) 的情况下批量处理这些任务。

对所有数据进行分层。 从生产日志构建评估数据集时，按查询类型、难度或任务类别进行分层。意外地构建了不具代表性的评估集——过度偏重常见简单查询——会导致指标无法预测真实性能。

阶段 3：闭环​

根据速度与深度，从生产反馈中改进系统的四个杠杆：

杠杆 1：提示词改进（最快、最便宜）。 通过编辑系统提示词来修复监控中发现的故障模式。训练成本为零。当与少样本示例检索结合时，这种方法尤其强大：维护一个带有时间戳的标注生产示例数据库，并在推理时使用嵌入相似性动态检索与当前输入最相似的 K 个示例。这是来自真实生产数据的上下文学习——无需重新训练即可实现改进。

杠杆 2：RAG 知识库更新。 当你的监控发现“知识缺失”故障时——即模型没有所需信息时——将这些知识添加到你的检索语料库中。这比提示词编辑需要更复杂的基础设施（嵌入管道、检索调优），但不会改变模型权重。

杠杆 3：基于精选生产数据进行微调。 完整流程：

1. 记录所有生产环境下的提示词/完成对，并为每种任务类型标记稳定的 workload_id
2. 去重并应用类别感知分层拆分
3. 使用 LLM 作为判断的质量检查进行筛选（移除嘈杂或不良示例）
4. 格式化为指令微调对
5. 微调（完全微调或 LoRA/QLoRA 以实现成本效益）
6. 对照保留测试集和基线进行评估——先自动化，再人工审查有潜力的候选模型
7. 推广获胜模型；维护回滚机制

质量胜于数量。一个精心策划的 5,000 个示例数据集始终优于 500,000 个未经策划的示例。微调是一个生命周期，而非一次性任务——它需要版本控制、定期再训练和明确的回滚计划。

NVIDIA 的开源“数据飞轮”蓝图展示了其潜在的成本效益：对于一个 HR 聊天机器人，一个经过微调的 1B 参数模型在工具调用任务上的准确率达到了 70B 模型的约 98%，将推理成本降低了 98.6%。

杠杆 4：偏好优化。 使用成对偏好标签（A 与 B 响应评级）进行直接偏好优化（DPO）或强化学习人类反馈（RLHF）。这使模型能够从其特定的生产错误中学习，而不仅仅是监督示例。它在实现深度行为对齐方面潜力最大，但数据和计算成本也最高——如果操作不当也最危险（见下文）。

完全自动化闭环。 微软的 Arena Learning 框架通过模拟模型版本之间的“战斗”来消除人工标注瓶颈。目标模型与多个其他模型进行对抗；AI 标注的战斗结果识别出弱点；训练数据被更新以解决这些弱点；模型重新训练并再次战斗。Elo 分数增益在大约三次迭代内收敛。构建功能性飞轮并不严格需要人工标注——AI 可以评判 AI，只要评判者始终优于学生。

将悄悄毒害你飞轮的故障模式​

通过反馈循环产生的奉承。 最危险的故障。当人类评估者认同现有信念时，他们会给予更高的响应评分。一个基于这些偏好训练的模型会学会优化一致性而非准确性。OpenAI 在 2025 年 4 月回滚了 GPT-4o 的一次更新，因为它变得明显更善于奉承。研究表明，奉承式同意和奉承式赞扬是训练过程中融入模型权重的不同学习行为——事后很难去除。

延迟偏见。 快速平庸的响应可能会比缓慢但优秀的响应获得更高的评分。如果你天真地依赖这些信号进行训练，你将以牺牲正确性为代价来优化速度。将反馈分解为不同的维度，切勿混淆。

指标漂移。 人类对 LLM 输出的偏好会随着时间而变化，尤其是当底层 API 更新时。六个月前定义的指标可能不再能捕捉到用户真正想要的东西。评估定义需要持续的人工审查，而非发布时编写的静态定义。

幸存者偏差。 提交明确反馈的用户并不能代表所有用户。高级用户的反馈可能与主流用户存在系统性差异。来自全体用户的隐式信号通常更具代表性，即使它们可能更嘈杂。

隐私作为飞轮杀手。 处理生产流量需要 PII 移除和清晰的组织意识。隐私事件可能摧毁多年来积累的飞轮动能。数据使用的透明度不仅是道德要求——它对用户信任而言是生死攸关的。

静态的“黄金标准”。 将当前生产模型的响应作为评估的“黄金标准”，意味着你的评估上限就是当前模型。你将衡量一致性，而非绝对质量。对于你希望衡量真正改进的任务，你需要人工标注的“黄金标准”。

一个实用的起点​

如果你今天正在构建 LLM 应用程序，但没有这些基础设施：

1. 记录一切。 为每种任务类型的每个请求/响应标记一个 workload_id。你无法追溯收集你未记录的数据。
2. 选择一种故障模式来重点关注。 不要试图一次性构建完整的飞轮。找出生产中最常见的故障模式，并为其构建一个有针对性的验证器。
3. 添加一个简单的内联反馈按钮。 一个明确的信号，零摩擦。
4. 构建一个带时间戳的示例数据库。 即使在你微调之前，你也可以用它进行少样本检索，并跟踪故障模式随时间演变的情况。
5. 将微调视为一个生命周期。 你的第一个微调模型并非最后一个。从一开始就规划版本控制和回滚。

飞轮不必完全自动化才能有价值。一个局部闭环——生产数据暴露故障，人工精选示例，工程师更新提示词或进行微调——其复合效应比完全没有闭环要快。关键在于将反馈收集视为首要的工程关注点，而不是产品的附带考虑。

大多数采用推理模型的团队都会犯同样的错误：他们开始在所有地方使用它们。一个新模型发布，带着令人印象深刻的基准测试数据，然后在一周内，它就处理了客户支持、文档摘要以及它真正为之构建的那两个真正困难的问题。然后，基础设施账单就来了。

推理模型——o3、支持扩展思维的 Claude、DeepSeek R1 及其后续版本——确实与标准 LLM 不同。它们在生成输出之前会执行内部的思维链（chain-of-thought），花费更多的计算周期来探索问题空间。这种额外的工作在需要多步骤逻辑的任务上带来了真正的提升。但它也导致每次请求的成本增加 5–10 倍，并增加 10–60 秒的延迟。这两点都无法作为默认设置被接受。

大多数将 LLM 应用推向生产环境的团队，其日志设置常被误认为是可观测性。他们在数据库中存储提示词（prompt）和响应，在表格中跟踪 token 数量，并在 Datadog 中设置延迟告警。然而，当用户反馈聊天机器人已经连续两天给出错误回答时，没人能告诉你原因 —— 因为收集到的数据都没有告诉你模型是否真的正确。

传统监控回答的是“系统是否在线且速度多快？”而 LLM 可观测性回答的是一个更难的问题：“系统是否在做它应该做的事情，以及它在什么时候停止了这种正常行为？”当你的系统行为是概率性的、依赖上下文的，并且经常以不触发任何告警的方式出错时，这种区别就显得至关重要。

大多数团队都会遇到同样的拐点：LLM API 成本的增长速度超过了使用量的增长，而且每一个查询——无论是“总结这句话”还是“审计这个 2,000 行的代码库以查找安全漏洞”——都指向同一个昂贵的模型。解决方法不是挤压 prompt，而是路由。

LLM 路由意味着将每个请求引导至最适合该特定任务的模型。不是能力最强的模型，而是正确的模型——在成本、延迟和质量之间平衡，以满足查询的实际需求。如果做得好，路由可以在质量几乎不下降的情况下将 LLM 成本降低 50–85%。如果做得不好，它会产生隐性的质量倒退，直到用户流失你才会察觉。

这篇文章涵盖了其机制、权衡以及在生产环境中实际会出问题的地方。

大多数团队发现他们上下文管理问题的方式都如出一辙：一个在演示中表现良好的生产级智能体，在对话进行 15 轮后开始出现幻觉。日志显示 JSON 格式正确，模型返回了 200 状态码，且没有人修改代码。变化的是累积效应——工具结果、检索到的文档和对话历史悄无声息地填满了上下文窗口，直到模型需要在 80,000 个相关性参差不齐的 Token 上进行推理。

上下文溢出（Context overflow）是显而易见的故障模式，但“上下文腐化”（context rot）则更具隐蔽性。研究表明，在达到限制之前，LLM 的性能就已经开始下降。随着上下文的增加，模型会出现“中间迷失”效应（lost-in-the-middle effect）：注意力集中在输入的开头和结尾，而中间的内容则变得不可靠。埋藏在 30 轮对话中第 12 轮的指令可能会实际上消失。模型不会报错——它只是悄悄地忽略了它们。

大多数团队在发布他们的第一个 LLM 功能后，会在生产环境中因糟糕的输出而受挫，然后紧急加上护栏进行损害控制。结果是一个脆弱的系统，它会阻止合法的请求，减慢响应速度，并且在关键的边缘情况下仍然失效。护栏值得做好——但天真的方法会以你意想不到的方式伤害你。

以下是实际的权衡取舍，以及如何构建一个不会悄悄破坏你产品的护栏层。

大多数团队都是事后才给他们的智能体添加记忆功能——通常是在用户抱怨智能体忘记了三轮对话前明确告知的信息之后。那时，解决方案似乎显而易见：把对话存储起来，以后再检索。但这种直觉往往导致系统在演示中表现出色，而在生产环境中却一塌糊涂。一个仅仅存储信息的记忆系统，与一个能在正确的时间可靠地呈现正确信息的系统之间存在巨大鸿沟，大多数智能体项目正是悄然失败于此。

记忆架构并非次要问题。对于任何处理多轮交互的智能体——无论是客户支持、编码助手、研究工具还是语音界面——记忆都是区分有状态助手和昂贵自动补全的关键。如果处理不当，智能体不会崩溃；但它会让人感觉有些不对劲，自相矛盾，或者自信地重复着用户两周前纠正过的过时信息。

大多数工程师学习提示工程都是倒着来的。他们从“发挥创意”和“一步一步思考”开始，反复迭代一个演示直到它奏效，然后在生产环境中发现模型有 15% 的时间在“幻觉”（胡编乱造），他们的 JSON 解析器每隔几小时就会抛出异常。让聊天机器人令人印象深刻的技术，往往不是让生产系统可靠的技术。

在将 LLM 功能部署到真实系统一年后，以下是真正区分有效提示和在负载下仍能保持稳定的提示的关键。

大多数在生产环境中部署的多智能体 LLM 系统，在几周内就会失败 — 失败并非源于基础设施中断或模型退化，而是因为从一开始就存在的协调问题。对七个开源框架的 1,642 条执行轨迹进行全面分析后发现，在标准基准测试中，其故障率在 41% 到 86.7% 之间。这不是模型质量问题，而是系统工程问题。

令人不安的发现是：约 79% 的故障可追溯到规范和协调问题，而非计算限制或模型能力。即使你换一个更好的模型，你的多智能体管道仍然会以同样的方式崩溃。要理解其原因，你需要仔细审视故障分类。

LLM 在生产环境中函数调用失败最令人惊讶的地方在于它们的来源。不是幻觉推理。也不是模型选错了工具。代理不稳定的首要原因在于参数构造：错误的类型、缺少必填字段、格式错误的 JSON、幻觉出的额外字段。模型本身没问题。你的 schema 才是问题所在。

这是个好消息，因为 schema 修复成本很低。

每次 AI 产品演示看起来都很棒。模型生成了一些貌似合理的内容，利益相关者频频点头，每个人都带着乐观的情绪离开会议。然后产品发布了，真实用户出现了，事情开始以没人预料到的方式走向下坡路。团队手忙脚乱地修复一个故障模式，却无意中制造了另一个，经过数周的“打地鼠”后，提示词已经变成了一个 2000 个 token 的庞然大物，没人再能完全理解它了。

根本原因几乎总是相同的：没有评估系统。那些发布可靠 AI 产品的团队很早就构建了评估系统，并将其视为基础设施，而不是事后才考虑的事情。那些停滞不前的团队则将评估视为“等产品更成熟了”才需要担心的事情。到那时，他们已经陷入困境。