AI 技术债务：Sprint 回顾中从未出现的四个类别

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

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

对 4,800 个工程团队的 810 万个 Pull Request 的研究分析发现，AI 采用后技术债务增加了 30% 到 41%，而开发者在端到端任务上实际上慢了 19%，尽管他们感觉更快了。这种债务是真实的、可衡量的，其中大部分属于传统工程实践无法捕获的四个类别。

提示词腐化：当昨天的指令破坏了明天的模型

提示词腐化是指随着底层模型的变化，提示词有效性缓慢衰退。你为 GPT-4 编写了一个精心调优的系统提示词。它运行得非常好。然后模型更新了，或者你迁移到了不同的提供商，同样的提示词现在产生了微妙不同的输出——不足以触发告警，但足以让用户感到困惑。

这是因为提示词是与特定模型行为的隐式契约。当你写"用恰好三个要点回答"时，你依赖的是该模型对"恰好"的理解。新版本的模型可能会以不同方式解释同样的指令——在要点前添加前言或将其重新格式化为编号列表。

复合问题在于：团队很少以与版本管理代码相同的严谨度来版本管理提示词。对 LLM 软件项目的研究发现，LLM 系统中技术债务的中位生命周期为 553 天，清除率仅为 49%。超过一半引入的债务永远不会被清理。提示词尤其脆弱，因为它们看起来像配置而非代码，因此逃过了捕获其他问题的审查流程。

提示词腐化的治理方法：

• 将提示词视为代码工件：对其进行版本管理、审查变更，并将其固定到特定模型版本。
• 构建自动化回归测试，在升级前针对新模型版本运行你的提示词套件。
• 维护提示词变更日志，不仅记录变更内容，还记录选择原始措辞的原因——推理比文本衰退得更快。
• 设置输出监控，检测模型响应中的分布偏移，而不仅仅是错误。

评估漂移：当你的测试不再反映现实

评估漂移发生在你的评估数据集和指标悄然偏离系统在生产中实际遇到的情况时。六个月前你从真实查询样本中构建了一个黄金测试集。那时它是有代表性的。此后，你的用户群增长了，使用模式发生了变化，产品增加了新功能——但评估集保持不变。

这比传统软件中的测试腐化更加隐蔽，因为评估仍然通过。一个在基准测试上得分 94% 的分类器，可能在用户今天实际发送的查询上只得 78%。你不会知道，直到有人手动审计一批生产输出并发现差距。

问题在于评估结果驱动决策。如果你的评估显示系统在改善，你就会自信地发布。如果评估测量的是错误的东西，你就是在自信地发布退化。通过对 1,200 个 LLM 部署的生产分析发现这一模式的团队认识到，成功的组织将评估视为基础设施，而非一次性设置任务。

评估已经漂移的信号：

• 你的评估分数在上升，但用户满意度持平或下降。
• 你的测试集超过 90 天没有刷新。
• 新的产品功能或用户细分没有在评估数据中体现。
• 你在衡量中间质量指标（BLEU 分数、余弦相似度），但没有衡量端到端任务完成率。

应对方法：

• 通过定期采样最近的生产流量、对其进行匿名化处理并纳入测试套件，实现持续的评估集刷新。
• 跟踪评估集与生产流量的分布，当它们显著偏离时发出告警。
• 使用 LLM 作为评判者的模式来扩展超出人工审查能力的评估范围，但至少每月将评判者与人工评分进行校准。
• 衡量结果，而非代理指标。如果你的 AI 功能帮助用户完成任务，就衡量任务完成率——而不是孤立地衡量嵌入相似度或响应流畅度。

嵌入锁定：你承担不起的迁移

嵌入锁定发生在你基于某个嵌入模型训练的向量索引变得成本高昂、难以迁移时。你选择了一个嵌入模型，为整个文档语料库生成了向量，构建了索引，调优了检索阈值，并围绕该模型的特性优化了分块策略。一切正常。然后一个明显更好的嵌入模型出现了，或者你的提供商改变了定价，或者你需要支持新语言。

迁移意味着重新嵌入你的整个语料库——可能需要数千美元的计算资源和数天的处理时间。但重新嵌入只是开始：

• 你的分块策略是针对旧模型的上下文窗口优化的。
• 你的相似度阈值是根据旧模型的距离分布校准的。
• 你的检索管道的精确率-召回率权衡是针对旧模型的行为调优的。

加载中…