杀死你的 AI 系统的三种隐藏债务

你的 AI 功能准时上线了。用户正在使用它。一切看起来都很正常 —— 直到一季度后，一张支持工单揭露了系统已经“一本正经地胡说八道”了好几周，你的评估套件（evaluation suite）什么也没抓到，而向量索引正悄无声息地返回过期结果。没有任何环节崩溃。系统全程返回 200 OK。

这就是 AI 技术债务的样子。它不像失败的单元测试或堆栈溢出，而是以一种温和且概率性的方式退化。你不会遇到崩溃 —— 你面对的是微妙的质量侵蚀。主要由三种不同的负债驱动：提示词债务（prompt debt）、评估债务（eval debt）和嵌入债务（embedding debt）。每一项都独立积累，每一项又都在加剧其他的债务。而大多数工程团队正同时背负着这三者。

提示词债务：当你的指令变成遗留代码

提示词债务是那些脆弱、无文档、无归属的指令所积累的混乱，随着时间的推移，它们会悄悄偏离预期行为。它的形成方式与其他技术债务相同 —— 通过走捷径、复制模板，以及比治理速度更快的变更 —— 但它的失败方式与传统代码不同。

带有 Bug 的函数会返回错误的值。而带有债务的提示词会以自信的语气返回微妙的错误答案，通过你所有的现有测试（如果你有的话），并混入正常的输出中。其 Bug 表面（bug surface）是整个开放式的自然语言空间。

这里有一个在生产环境中反复出现的失败模式：一名团队成员复制了一个现有的客户支持提示词来启动一个新的工作流。源提示词包含六个月前过时的取消政策。几周以来，AI 系统正确地减免了按当前政策本应收取的费用。没有触发任何报警。这种漂移是不可见的，直到收入审计发现了它。没有任何东西“坏了” —— 系统完全按照提示词的要求做了。

一项分析 LLM 项目仓库的 2025 年研究发现，提示词债务占所有检测到的技术债务的 6.61%，使其成为最普遍的类别。更令人担忧的是：一旦提示词债务出现，只有 49.1% 会被移除 —— 这是所有债务类型中最低的移除率。积累了问题的提示词往往会一直保持损坏状态。

根本问题在于，大多数团队将提示词视为配置，而不是代码。它们没有版本控制。它们没有负责人。它们堆积在 Notebook、Slack 线程以及散落在代码库各处的硬编码字符串中。当底层模型改变或业务规则更新时，提示词却没有同步更新。

在不重写的情况下解决提示词债务：

目标不是实现完美的提示词 —— 而是停止积累不可见的提示词。三个改变最为关键：

第一，集中存储。将提示词从应用程序代码中移出，进入一个无需部署即可检索、更新和审计的系统。这使提示词的迭代速度与工程发布周期解耦。

第二，建立版本控制。将提示词视为版本控制中跟踪的一等资产。维护一个兼容性矩阵，记录哪些提示词版本适用于哪些模型版本。当你从 GPT-4o 升级到更新的模型时，你需要知道哪些提示词发生了回退（regressed）。

第三，分配所有权。提示词泛滥既是一个技术问题，也是一个所有权问题。每个生产环境的提示词都应该有一个指定的负责人，负责保持其时效性。“所有权比工具更重要” —— 没有它，治理框架就会变成围绕着废弃提示词的官僚主义。

评估债务：你一直想建却没建的测试套件

评估债务（Eval debt）是指你的 AI 系统实际表现与你检测其行为变化的能力之间的差距。当团队优先考虑交付而忽略构建评估基础设施时，它就会积累，并且因为没有适当评估的每一周都是回归（regressions）未被检测到的一周，这种债务会不断复利。

核心问题不在于知道该使用哪种评分技术。而在于构建一个操作闭环，将生产环境的失败转化为可复现的测试用例。大多数团队只拥有三者之一 —— 手动测试过的原型、针对错误率报警的生产监控，或者发布时构建的评估套件。他们很少能将这三者连接起来。

失败模式如下：你的系统在某类边缘案例（edge cases）上发生了回退。客户注意到了。你进行调查，发现问题，修复它。三个月后，一个类似的变更触发了相同的回退。你再次调查。这种模式不断重复，因为没有任何机制将最初的失败捕获为持久的测试用例，以便在第二次事件发生时拦截它。

研究数据非常严峻：67% 大规模使用 AI 的组织报告了至少一个与模型行为失调相关的关键质量问题，且这些问题一个月以上未被察觉。在模型供应商更新后的几天内，模型准确度就可能下降。评估债务使检测延迟成为一种结构性特征，而非意外。

在不重写的情况下解决评估债务：

构建三个相互连接的评估基础设施层。

第一层是黄金数据集（golden dataset） —— 50 到 200 个从真实生产流量中筛选出的输入-输出对。不是合成示例，而是你的系统接收到的实际输入，并标注了正确回答的样式。从最关键的失败模式中选择 25 到 50 个案例开始。包括那些曾经让你吃过亏的边缘案例：非英语输入、对抗性提示词、不完整或模糊的查询。

第二层是一个离线评估套件，在每次部署前针对该数据集运行。评估标准（rubric）应分解为具体的、可衡量的属性 —— 不是一个单一的“质量”分数，而是针对正确性、格式遵循、政策合规以及对你特定系统重要的任何维度的独立标记。使用前沿模型根据标准对输出进行评分的自动化裁判（judge）基础设施既实用且易于扩展。

第三层将生产监控连接回数据集。当生产监控识别到失败时，工作流应以该失败转化为新的测试用例并添加到黄金数据集而结束。每一个没有生成回归测试的事故，都是一个等待再次发生的事故。

将离线评估作为质量闸门（quality gates）集成到 CI/CD 中。如果一次部署导致黄金数据集的回退超过阈值，则不应进入生产环境 —— 就像单元测试失败的部署不能上线一样。

嵌入债务：向量存储在黑暗中逐渐失效

嵌入债务是指当你把嵌入模型（embedding model）的选择当作一次性决策时所积累的负债。针对一个模型计算出的向量与针对另一个模型计算出的向量之间没有实际的可比性。随着模型的演进、供应商弃用旧版本以及你领域词汇语义含义的转变，你的向量存储会默默地与在其上运行的查询发生偏离。

这个问题有三个相互叠加的维度。

模型漂移（Model drift）： 当你升级嵌入模型——或者当供应商在你不知情的情况下更新了底层模型时——之前存储的向量就会变得不匹配。将同一段文本通过两个模型版本运行，可能会产生 0.78 的相似度得分，这意味着你的搜索索引现在返回的结果不再是最相关的。旧的嵌入无法捕捉到当前的语境。

语义漂移（Semantic drift）： 词义是会演变的。2020 年的一个产品描述语料库在钓鱼语境下使用 “reel” 一词，到 2024 年在针对 Instagram Reels（短视频）的查询中就会出错。随着业务语境的变化，领域特定术语的含义也会发生转变。向量编码了数据在某一时间点的含义；而该含义可能不再符合用户的意图。

存储倍增（Storage multiplication）： 跨语言、任务和模型迭代维护多个嵌入版本的组织，对于一个拥有 1000 万条记录的系统，如果考虑到三个任务和两个模型版本，很容易就会达到 6000 万个向量。在这种规模下，重新嵌入（re-embedding）将变成一项耗资 8,000 到 15,000 美元的计算任务，此外 600 GB 的出站流量成本在还没计算任何新向量之前就可能超过 300 美元。

这种成本结构造成了供应商锁定。理解嵌入债务的团队会通过长期坚持使用原始嵌入模型来规避它，即使新模型早已能显著提升检索质量。

在无需重写的情况下解决嵌入债务：

最近关于嵌入空间适配（embedding space adaptation）的研究提供了一条切实可行的路径。漂移适配器（drift-adapter）——一种在旧模型和新模型输出的小型配对样本上训练的轻量级映射函数——可以在不重新编码语料库的情况下桥接两个空间。在查询时，新的嵌入在搜索未更改的索引之前会被转换为遗留空间的格式。这种方法能以极低的成本达到完全重新索引 95% 到 99% 的质量，且延迟开销不到 10 微秒。

对于能够承担迁移成本但需要避免停机的团队，影子索引（shadow indexing）提供了一条更干净的路径：在从旧索引提供查询服务的同时并行预热新索引，待新索引准备就绪后原子化地切换流量。

预防模式是监控。跟踪查询随时间推移的语义分布。当传入查询与存储向量之间的相似度分布开始下降时发出警报——这是在客户察觉之前，嵌入漂移影响检索质量的信号。

三种债务如何相互叠加

这些负债并非孤立累积。它们以相互放大的方式发生作用。

Prompt 债务让评估（eval）债务变得更糟。脆弱、缺乏文档的 Prompt 使得设计保持稳定的评估准则变得更加困难。当 Prompt 在没有版本控制的情况下发生变化时，它会默默地使现有的测试用例失效——你的评估套件现在测试的是旧的行为，而不是当前的行为。

评估债务让嵌入债务得以隐藏。当检索质量因嵌入陈旧而下降时，它很少会触发错误——它只是以人工抽查会遗漏的方式影响回答质量。如果没有系统测量检索准确性的评估流水线，嵌入漂移就会在未被察觉的情况下累积。

嵌入债务驱动了 Prompt 债务。当检索质量下降时，团队的反应是“黑进”（hacking）Prompt——增加指令以补偿糟糕的上下文，增加更多示例以引导模型产生更好的输出。这些“黑客行为”是在技术债务之上叠加了更多的技术债务。

最终结果是系统在所有三个维度上同时退化，而表面上看起来仍在运行。传统的监控——延迟、错误率、吞吐量——在仪表盘上显示为绿色，而用户体验到的质量却在稳步下降。

无需推倒重来的重构路线图

好消息是，这三种类型的债务都可以通过增量方式解决，并与功能交付并行进行。

第 1-3 周 — 清点与基准： 梳理现有的 Prompt，按生产风险对其进行分类。针对你在生产环境中实际遇到的故障审计你的评估覆盖范围。检查你的嵌入模型上次更新的时间，以及你的供应商是否已将其弃用。建立成本和质量基准，以便衡量改进。

第 4-8 周 — 核心治理： 将 Prompt 移至具有版本控制的集中存储中。从生产环境故障中构建初始的黄金数据集（golden dataset）。记录你的嵌入模型版本，并将刷新计划列入日程表。

第 9-16 周 — 运营集成： 将离线评估集成到 CI/CD 中作为质量门禁。建立“生产故障 → 测试用例”的反馈循环。如果嵌入模型更新已过期，则部署影子索引或漂移适配器。

持续进行： 正式分配 Prompt 的所有权。确定谁在生产前审查 Prompt 的更改。每季度进行一次评估覆盖率审查，就像进行容量规划一样。

这些都不需要停止功能开发。这三种债务类型的架构模式是相同的：将脆弱的部分抽象在接口之后，以便能够独立地进行治理、监控和升级。

AI 系统失败的方式与传统软件不同。它们以软性的、概率性的方式失败，并且表现得很自信。没有警报并不代表健康——这证明你的监控并不是为了捕捉质量侵蚀而构建的。Prompt 债务、评估债务和嵌入债务是 AI 系统悄然失效的三个最常见原因。请像对待未迁移的数据库 Schema 或半年没运行过的测试套件一样，紧迫地对待它们。

债务已经存在。问题在于你是否能在用户发现之前找到它。