9 篇博文 含有标签「production-ml」

每位产品负责人都听过这个论调：更多用户产生更多数据，更好的数据训练更好的模型，更好的模型吸引更多用户。数据飞轮是复利护城河，这正是AI巨头们能够赢得市场的原因。

这个论调并没有错。但实施几乎总是出了问题。在实践中，大多数数据飞轮都有多个泄漏点——反馈循环看似在运转，实际上却在放大偏差、强化陈旧模式，或者优化一个与真实目标背道而驰的代理指标。构建这些系统的工程师很少知道自己遇到的是哪种泄漏，因为所有泄漏从外部看起来都一样：参与度上升，模型在可测量的指标上持续改进，而系统却在难以归因的方式下变得越来越没用。

这就是数据飞轮陷阱。理解其失败模式，是构建真正有效飞轮的前提。

一家医疗公司每天用 GPT-4 处理 10,000 份文档，年度账单高达 5 万美元。在用前沿模型的输出对一个 270 亿参数的开源模型进行微调后，相同的工作量仅需 5,000 美元——节省了 90%。这个小模型在他们的特定任务上还比前沿模型高出 60%，因为它已经见过数千个完全正确行为的示例。

这就是现代形式的知识蒸馏：你一次性支付前沿模型 API 费用来生成训练数据，然后永远运行一个小型专用模型。这个算法之所以成立，是因为当你拥有权重时推理成本很低，而且在有足够示例的情况下，特定任务的模型能在窄任务上胜过通用模型。

但"收集输出、微调、上线"并不是完整的方案。大多数尝试蒸馏的团队都会遇到三堵隐形墙之一：劣质的合成数据导致学生学到错误行为，缺乏可靠信号来判断学生何时真正就绪，或者生产环境中出现无声的质量崩溃，直到用户抱怨才被发现。本文涵盖决定蒸馏是否成功的流程决策。

这个方案听起来简洁明了：为每种专项技能分别微调轻量级LoRA适配器——一个处理专业语气，一个处理JSON格式化，一个处理医学术语，一个负责安全护栏——然后在推理时将它们组合起来。团队上线了这套设计，开发阶段运行良好，但到了生产环境却频频崩溃：两个适配器开始争夺同一权重区域，输出质量骤降，最终与未经训练的基础模型毫无二致。不是略有下降，而是彻底退化。

本文探讨适配器组合在实际应用中的表现、朴素合并为何屡屡失败，以及哪些策略在生产规模下真正有效。

一个在文档理解数据集上达到 97% 准确率的基准测试结果看起来非常有说服力，直到你针对公司的实际发票存档运行它，才发现它正在静默地搞乱 30% 的行项目。模型不会报错，也不会返回低置信度，它只是产生了一个看起来合情合理但却是错误的输出。

这是生产级文档 AI 的典型失效模式：静默损坏 (silent corruption)。与崩溃或异常不同，静默损坏会发生传播。乱码的单元格流入下游聚合，聚合信息喂给报告，报告驱动决策。当你意识到问题时，追踪根本原因就像是在搞考古。

文档 AI 在基准测试表现与生产环境表现之间的差距是真实存在的、持久的，且被评估这些模型的团队所低估。理解为什么会存在这种差距——以及如何防御它——正是本文要解决的工程问题。

大多数 LLM 推理瓶颈归结于一个令人不安的事实：GPU 在等待内存带宽，而非计算资源。每生成一个 token，都需要从 HBM 加载整个模型权重，这一传输过程主导了运行时间。投机解码正是为了利用这一空隙而设计的——但其收益取决于你的基准测试几乎肯定没有测试过的条件。

将投机解码部署到生产环境的团队，往往发现其实际表现比实验室数据低 40–60%。这不是因为该技术存在缺陷，而是因为工作负载特征以重要的方式发生了变化：更大的批量、更短的输出、更严格的输出约束。理解投机解码何时真正有效、何时会悄然造成伤害，是负责任部署的前提。

你的语义搜索很可能正在悄然恶化，而你的监控面板对此毫无显示。

没有错误日志，没有 p99 毛刺，没有健康检查失败。查询依然返回结果，余弦相似度评分依然看起来正常。但相关性正在一点一点地悄然下滑——每一个被遗漏的新词，都在拉大用户语言与嵌入模型训练语言之间的距离。

这就是嵌入漂移问题。它之所以难以察觉，正是因为它不产生任何可见的失败信号——只有检索质量的缓慢侵蚀。用户会说产品"越来越没用了"，然后悄悄离开。

你的 Sprint 回顾涵盖了那些常见问题：不稳定的测试、某人一直推迟的数据库迁移、用胶带勉强粘合的 API 端点。但如果你正在交付 AI 功能，代码库中最昂贵的债务恰恰是那种没人会写在便利贴上的。

传统技术债务是线性积累的。你走了捷径，之后为此付出利息，等痛苦到了一定程度再重构。AI 技术债务是复合增长的。一个默默退化的提示词会产生污染评估的训练信号，这会误导你下一轮提示词修改，进而进一步侵蚀用户体验的质量。等有人注意到时，三层假设已经在底下腐烂了。

2024 年初，Open LLM 排行榜的榜首几乎被一种从未经过训练的模型全面占领——它们是合并而来的。各团队将两三个基于 Mistral-7B 微调的变体，用一个 YAML 配置文件对权重进行平均，便以极低的计算成本超越了专门训练的模型。从外部看，这项技术简单得近乎可笑：把一些张量加在一起，除以二，就可以发布了。但现实远比这复杂——如果你不理解其背后的原理，那些锋利的故障模式足以让一个生产部署翻车。

这是一份面向希望在生产中使用模型合并的 ML 工程师的实践指南：各方法在数学上到底做了什么、何时有效、何时会悄然降级，以及如何针对给定的候选模型选择正确的工具。

你的 RAG 昨天回答得还很正确。今天它却自相矛盾了。看起来什么都没变 —— 除非你的嵌入模型（Embedding）提供商悄悄更新了模型，导致你的索引现在成了一个混合了不同向量空间的“科学怪人”（Frankenstein）。

嵌入模型是每个检索增强系统（RAG）中不起眼的基石，而且它们的失效方式通常极其难以诊断。与提示词（Prompt）更改或模型参数微调不同，嵌入模型的问题往往出现得非常缓慢，表现为一种无声的质量下降，在用户开始投诉之前，你的评估系统（Evals）甚至都察觉不到。本文涵盖三个方面：如何为你的领域选择合适的嵌入模型（MTEB 评分的误导性往往大于帮助）、升级模型时究竟会发生什么，以及无需从头重建即可更换模型的版本控制模式。