Andrej Karpathy 的深度学习：交付 AI 的实战经验

为什么深度学习在真实产品中常常显得难以使用

深度学习的演示有时像魔法——模型写出干净的段落、识别对象或回答难题。但当你试图把那个演示变成用户每天点一次的按钮时，问题就显现了。同一个提示会出现不同表现，边缘情况堆积，惊叹点变成了支持工单。

这种差距正是 Andrej Karpathy 的工作为何对实干者有共鸣的原因。他倡导一种心态：把神经网络视为可以设计、测试和维护的系统，而不是神秘的物件。模型本身不是没用，产品只是要求一致性。

当团队说他们想要“实用”的 AI 时，通常意味着四件事：

• 可重复： 在常见输入上表现可预测，而不仅仅是精挑细选的演示。
• 可衡量： 能用一个数字定义“好”，而不是凭感觉。
• 可维护： 可以更新数据、提示或模型而不把一切搞坏。
• 可观测： 发布后能监控失败、成本、延迟和质量。

团队之所以苦恼，是因为深度学习具有概率性和上下文敏感性，而产品以可靠性被评判。一个 80% 回答良好的聊天机器人，如果剩下 20% 自信但错误且难以察觉，仍会让人觉得它坏了。

拿一个客户支持的“自动回复”助手举例。它在几张精选工单上看起来很棒。但在生产环境，客户会用俚语、发截图、混合语言，或询问政策边界问题。此时你需要护栏、明确的拒绝行为，以及衡量草稿是否真正帮助了客服人员的方法。

早期工作：把神经网络当工程而非魔法来对待

许多人最初接触 Karpathy 的工作，是通过实用示例而非抽象数学。即便早期的项目也传达了一个简单观点：当你把神经网络视为可以测试、打断和修复的软件时，它们就变得有用。

重点不再停留在“模型能工作”这句结论上，而是让它在脏乱的真实数据上也能工作。这包括数据管道、因琐碎原因失败的训练运行，以及在修改一点点配置时结果会变化的情况。在这样的世界里，深度学习不再听起来神秘，而更像工程。

Karpathy 风格的方法少是关于秘密技巧，多是关于习惯：

• 从一个你能打败的基线开始，即便它很简单。
• 选一个衡量“更好”与“更差”的指标。
• 每次只改一件事，这样你才能知道变化的原因。
• 检查错误与示例，而不仅仅看最终分数。

这种基础很关键，因为产品化的 AI 本质上是同一场比赛，只是赌注更高。如果你早期不打好工艺（清晰的输入、清晰的输出、可复现的运行），交付 AI 功能就会变成猜测。

让神经网络对工程师更可理解

Karpathy 的影响很大程度上来自于他把神经网络当成可推理的对象。清晰的解释能把工作从“信仰体系”变成工程。

这对团队很重要，因为交付第一个原型的人往往不是维护它的人。如果你无法解释模型在做什么，你很可能无法调试它，也绝对无法在生产中支持它。

以可维护为目标来解释它

一开始就强迫自己讲清楚。在构建功能前，写下模型看到什么、输出什么，以及如何判断它在变好。大多数 AI 项目失败在于基本功，而不是数学。

一份短小的清单，能在后期带来回报：

• 输入与输出的确切定义（格式、限制、脱敏规则）
• 你必须打败的基线（规则、检索、模板或更小的模型）
• “好”的样子是什么（一个数字、一个评分细则或两者）
• 哪些失败是不可接受的（安全、隐私、品牌语调）
• 谁来复查结果，以及复查频率

可复现性也是解释的一部分

清晰的思路会体现在有纪律的实验上：一段可重跑的脚本、固定的评估数据集、版本化的提示和已记录的指标。基线让你保持诚实并使进展可见。

从原型到生产：发布后会发生的变化

原型证明一个想法可行。发布的功能证明它能在杂乱的真实环境和日常使用中稳定工作。这个差距是许多 AI 项目卡住的地方。

研究演示可以慢、昂贵且脆弱，只要它展示了能力就行。生产环境则优先考虑可预测性、可观测性和安全性，即便输入怪异、用户没有耐心、流量激增也要稳。

你会突然关心的约束

在生产中，延迟就是一个功能。如果模型耗时 8 秒，用户会放弃或重复点击，而你要为每次重试付费。成本也变成了产品决策，因为一个小的提示改动就可能让账单翻倍。

监控是不可谈判的。你需要知道服务不仅在线，而且输出在时间维度上保持可接受的质量。数据漂移、新的用户行为和上游变更可能在不抛出错误的情况下悄然破坏性能。

安全与合规检查从“可有可无”变成必要项。你必须以一致且可测试的方式处理有害请求、私密数据和边缘情况。

团队通常要回答一系列同样的问题：

• 单次请求可接受的最大响应时间和成本是多少？
• 当模型失败或超时时的回退方案是什么？
• 哪些指标定义质量，什么阈值触发告警？
• 如何防止不安全或不合规的输出？
• 如果质量下降，如何快速回滚？

需要的不仅仅是模型能力

原型可能由一个人完成。要把它上线，通常需要产品来定义成功、数据团队来验证输入与评估集、基础设施来可靠运行，以及 QA 来测试失败模式。

“在我机器上能跑”不是发布标准。发布意味着在用户负载下也能工作，且配备日志、护栏和衡量其是否有帮助或有害的方法。

工程文化：假设、基线与迭代

Karpathy 的影响是文化性的，而不仅仅是技术性的。他把神经网络当作可以用同样的工程纪律去构建、测试和改进的系统。

这从在写代码前把假设写下来开始。如果你说不出为了让功能生效必须成立的条件，之后你就没法调试它。举例：

• “若建议的答案正确且语气匹配，用户会接受它。”
• “延迟低于 800 毫秒是必要的，否则用户会停止使用。”

这些都是可测试的陈述。

接下来是基线。基线是最简单可能奏效的方案，它是你的现实检查。可能是规则、检索模板，甚至是“什么也不做”但配合良好 UI 的方案。强有力的基线能保护你免于在花哨模型上浪费数周时间，却打不过简单方案。

埋点使得迭代成为可能。如果你只看演示，你就是凭感觉驾驶。对于许多 AI 功能，一小组关键数字就足以告诉你是否在进步：

• 采用率（谁尝试并持续使用）
• 质量（接受率、发送前的编辑次数、点赞/点踩）
• 速度（延迟与首次有用输出时间）
• 成本（tokens、计算、人力复核时间）
• 安全（策略违规、敏感数据泄露、越狱尝试）

然后以紧密的循环迭代。每次只改一件事，与基线比较，并简单记录你尝试了什么以及带来了什么变化。如果进展是真实的，它会在图表上体现出来。

逐步流程：交付 AI 功能的简单工作流

把 AI 当作工程来交付效果最好：明确目标、基线和快速反馈回路。

1. 用一句话说明用户问题。 把它写成你能从真实用户那里听到的抱怨：”客服起草回复花太多时间。“ 如果你一句话都说不清，说明功能可能太大。

2. 选择一个可衡量的结果。 挑一个你每周都能跟踪的数字。好的选项包括每项任务节省的时间、首稿接受率、编辑减少量或工单转移率。在构建前先决定什么是“够好”。

3. 定义必须打败的基线。 与简单模板、基于规则的方法或“仅人工”比较。如果 AI 在你选择的指标上打不过基线，不要上线。

4. 用代表性数据设计小规模测试。 收集符合现实的样本，包括脏数据。保留一个小的评估集，不要每天反复“在脑子里训练”它。写明什么算通过、什么算失败。

5. 在功能开关后发布，收集反馈并迭代。 从小范围内部或小比例用户开始。记录输入、输出以及是否有帮助。先修复最主要的失败模式，然后用同一套测试重新运行，以便看到真实进展。

一个实用的起草工具模式：衡量“发送所需秒数”和“被少量编辑后使用的草稿百分比”。

明确的假设与可衡量的输出（该写下什么）

许多 AI 功能失败并非模型失败，而是“我们从未就成功达成一致”导致的失败。如果你希望深度学习变得实用，在写更多提示或训练更多模型前，先把假设和衡量写下来。

从可能在真实使用中打碎功能的假设开始。常见的涉及数据与人的假设：输入文本是单一语言、用户一次只询问一个意图、界面提供足够上下文、边缘情况罕见、昨天的模式下月仍然成立（漂移）。同时写下暂不处理的内容，比如讽刺、法律建议或长文档。

把每个假设转成可测试的条目。一种有用的格式是：“给定 X，系统应做 Y，我们可以通过 Z 验证。” 保持具体。

值得在一页上写下的五件事：

• 输入： 模型看到什么（字段、限制、脱敏）以及何为“足够干净”
• 输出契约： 必须返回什么（格式、语气、允许的操作）
• 离线评估： 带评分规则的小型标注集（通过/失败加上指标）
• 在线指标： 用户行为（接受率、编辑、节省时间、工单重开）
• 护栏： 何时拒绝、询问澄清或回退到更简单流程

刻意把离线和在线分开。离线指标告诉你系统是否学会了任务；在线指标告诉你该功能是否真的帮助了人。一个模型在离线评估上得分高，仍可能惹恼用户，因为它太慢、过于自信，或在重要场景上出错。

把“够好”定义为阈值和相应后果。例如：”离线：评估集正确率至少 85%；在线：至少 30% 的草稿被少量编辑后使用。“ 如果未达阈值，事先决定后续动作：保持功能开关、降低上线比例、将低置信度情况路由到模板，或暂停并收集更多数据。

团队在把 AI 加入产品时常犯的错误

团队常把 AI 功能当普通 UI 调整来看：先上线，观测后再改。由于模型行为会随提示、漂移和小配置改动而改变，这种做法会很快失败，结果是大量努力却没有明确证明它有帮助。

一个实用规则很简单：如果你说不出基线和衡量方法，你就还没准备好上线。

最常见的失败模式：

• 未提供非 AI 基线，使得改进无法证明。
• 只追求质量而忽视延迟和成本（3% 的提升不值得 5 倍的变慢）。
• 依赖模糊反馈（“用户喜欢”），而不是埋点。
• 在与真实流量不符的小样本或挑选样本上调参。
• 当提示或模型更新产生奇怪输出时没有回滚计划。

举个具体例子：你给支持起草加了 AI。如果你只追踪点赞数，可能会漏掉客服审稿时间变长，或回复虽准确但过长的问题。更好的衡量是“被少量编辑后发送的百分比”和“发送所需时间的中位数”。

发布前的快速检查清单

把发布日当作工程交接，而不是演示。你应该能用简单的话说明功能做什么、如何知道它有效，以及坏了时你会怎么做。

发布前确认：

• 一段话的问题陈述和明确的目标用户。
• 一个有测量的基线（即便很简单）。
• 一个与用户价值挂钩的主要在线指标，以及记录输入、输出和结果的日志。
• 一次安全评审：可能的失败模式、受影响人群，以及界面如何应对（警告、阻止、请求确认）。
• 有负责人且可执行的回滚计划：触发回滚的条件和首小时内要检查的内容。

另外保留一个看起来像真实流量的离线评估集，包含边缘情况，并在数周内保持稳定。当你更改提示、模型或数据清洗时，重跑同一套评估并看哪些指标发生了变化。

示例场景：交付一个客服起草 AI 功能

一个支持团队想要在工单视图内有一个起草助手。该助手不会自动发送消息。它建议草稿、标注它使用的关键信息，并要求客服在发送前审阅和编辑。这个设计把风险降到最低，同时让你可以学习。

先决定“更好”在数字上如何体现。挑选可以从现有日志中立刻测量的结果：

• 平均处理时长（从打开到解决）
• 编辑率（客服在发送前修改草稿的程度）
• 升级率（工单被提升到更高处理层级）
• 重开率（7 天内被重开的工单）
• 客户满意度分数（如果已有追踪）

在引入模型前，先设定一个真实且无趣的基线：模板加简单规则层（检测退款/物流/重置密码，然后填充最佳模板）。如果 AI 打不过这个基线，就还不该上线。

运行小规模试点。让它在少数客服中自愿使用，且初期只限于一个工单类别（例如订单状态）。在每次草稿上加入快速反馈：“有帮助”或“无帮助”，并附简短原因。记录客服改动了什么，而不仅仅是他们是否点击了按钮。

事先定义上线标准，这样你就不会事后猜测。例如：在不提升升级率或重开率的前提下，处理时长提高 10%，且客服在至少 30% 的情况下以少量编辑直接接受草稿。

还要定义回滚触发条件：升级激增、满意度下降或重复的政策错误。

下一步：把这些经验应用到你的下一次 AI 发布

挑一个你能在 2 到 4 周内交付的 AI 点子。把它保持得足够小，以便你能衡量、调试并在出现问题时回滚。目标不是证明模型聪明，而是让用户结果可靠地优于现状。

把想法写成一页计划：功能做什么、不做什么，以及如何知道它在工作。包含基线和你要追踪的确切指标。

如果你想加快实现，Koder.ai (koder.ai) 是围绕通过聊天界面创建 Web、服务器和移动应用构建的，提供如快照/回滚和源码导出等功能，以便在需要更深控制时使用。

要保持的习惯很简单：每次 AI 改动都应该附带一个书面假设和一个可衡量的输出。这样深度学习才会不再像魔法，而成为可以交付的工程工作。