AI 技术债的三座无声时钟

传统的技术债务往往会自我显现。构建缓慢、测试失败、或是被抑制了六个月的 lint 警告——这些都是你可以通过 grep 搜索、转化为工单并排入冲刺（sprint）的症状。AI 特有的债务则不同。它在部署的间隙中悄然累积，在任何人意识到数据波动之前，它就已经降低了系统的性能。

大多数生产环境中的 AI 系统现在都有三个正在滴答作响的“债务时钟”。第一个是当特定模型版本流行时才有意义的提示词（prompt）。第二个是在构建时能代表用户行为，但现在已经过时的评估集（evaluation set）。第三个是仍在支撑检索层的嵌入（embeddings）索引，它们是由早已被弃用的模型生成的。每个时钟独立运行。三者共同叠加。

AI 债务的问题在于，它表现得如同系统依然可靠

经典的技术债务是一种有意识的权衡：为了更快交付而偷工减料，记录下来，并放入积压工作（backlog）中。你知道它的存在。

AI 特有的债务并非如此。一个旅游预订助手的任务成功率可以从 92% 下降到 83%，而代码库没有任何变化。提示词完全相同。底层业务逻辑未被触及。改变的是模型在 API 端点的行为——可能是来自供应商的静默更新、用户请求分布的变化，或者是与流水线中下游提示词的微妙交互。日志看起来很正常，因为“代码或提示词都没有改变；系统的行为只是开始发生漂移。”

这是 AI 债务的特征：在衡量正确的指标之前，这种退化表现得如同系统依然可靠。

软件工程文献中描述了一个机器学习特有的原则，称为 CACE —— 牵一发而动全身（Changing Anything Changes Everything）。在传统软件中，你可以更改一个函数而不影响无关的函数。在 LLM 流水线中，更改一个提示词会改变每一个下游提示词的输入。更新嵌入模型会使索引中的每个向量失效。这种互联性使得债务以打破常规思维模型的方式级联发生。

债务时钟之一：提示词漂移

提示词漂移是指提示词最初的设计目标与模型当前实际执行效果之间的逐渐失配。

模型供应商会向 API 端点推送行为更新，且并不总是公之于众。即使是固定在 gpt-4o-2024-08-06 的版本也无法幸免——即使是名义上锁定的版本，在不同时段之间也会表现出意想不到的行为偏移。一项跟踪 15 个提示词类别、共 2,250 条模型响应的研究发现，GPT-4 的响应长度随时间产生了 23% 的偏差，而某供应商的旗舰模型在同一个六个月窗口内，指令遵循的一致性下降了 31%。

更隐蔽的触发因素是输入分布偏移。你的客户群在增长、变化，或者找到了新的表达方式，而这些是你的提示词在编写时并未考虑到的。从大多数定义来看，提示词仍然“有效”——它能解析，也能返回结果——但它在实际生产查询中的有效性已经下降。如果没有在正确的粒度上进行监控，这是不可见的。

多步流水线会放大这一点。当你串联四五个 LLM 调用时，第一步的提示词漂移会改变第二步看到的输入。第二步的提示词可能是针对第一步的特定输出进行微调的。现在它接收到了不同的输入，其自身的行为也会随之改变——不是因为它的提示词变了，而是因为它的上下文变了。

待监控指标：

• 明确固定模型版本。永远不要在生产环境中使用自动更新的别名。
• 跟踪输出长度、格式合规性以及连续时间段之间的语义相似度。这些信号中的任何突然波动都预示着在用户察觉失败之前发生了漂移。
• 每周针对生产流量的固定样本运行以 LLM 作为裁判（LLM-as-judge）的评估。对指令遵循、语气和事实性进行评分。如果相对下降超过 10%，则应触发调查。
• 使用真实的生产案例而非合成案例来构建回归测试套件。合成测试无法捕捉到实际用户行为中积累的边缘案例。

实施结构化提示词监控的团队报告称，LLM 相关问题的调试时间减少了 50%，提示词迭代速度提高了三倍。这些监控设施很快就能收回成本。

债务时钟之二：评估集侵蚀

评估集是构建时所关注内容的快照。它反映了你的团队当时想到的边缘案例、当时出现的故障模式，以及当时的视角下的用户行为分布。如果你是六个月前构建的，且之后从未触及，那么它可能正在衡量错误的东西。

评估集侵蚀是指当你的测试集偏离生产现实，而模型保持不变时发生的情况。你运行评估，数据看起来没问题，但你的用户却在经历测试套件根本没有覆盖的质量下降。

这种失败模式非常微妙。由用户数据构建的评估集往往“过于干净”——它反映了在你的产品找到真正受众之前，或者在某个特定功能驱动新类型流量之前的查询。当这种新流量到来时，它会触发你的评估从未测试过的模型行为。一项比较分布偏移数据集微调的研究发现，F1 性能下降了 63 个百分点——这是一种灾难性的退化，而在原始评估集上进行拆分测试（split-test）的方法将完全忽略这一点。

更深层次的问题是组织架构上的。评估集往往是在发布或重大模型升级期间通过突击努力构建的，然后就被闲置了。它们没有负责人。没有人负责更新它们。随着产品演进，它们只能积满灰尘。

待构建项：

• 将评估集视为具有负责人和审核周期的动态资产。
• 每周抽取新鲜的生产查询，并按比例路由到评估流水线中。对抽样查询进行聚类，并将聚类分布与现有评估集进行比较——偏差会告诉你覆盖范围在哪里退化。
• 使用群体稳定性指数（PSI）来衡量评估集与生产流量之间的特征分布偏移。在任何关键维度上，PSI 超过 0.2 都意味着评估集需要在该区域补充新案例。
• 建立季度评估审计机制：提取 200 个近期的生产案例，让模型进行评分，并与历史评估基准进行比较。明显的下降意味着你的评估集不再具有代表性。

目标不是每季度从头开始重建评估。而是在生产环境已经发生变化而测试集尚未跟进的领域增加覆盖范围。

债务时钟之三：Embedding 过时

Embedding 过时是生产系统中存在最久的 AI 技术债务时钟，而且它往往最难被察觉，因为 RAG 检索的退化是平滑的 —— 它只是开始返回稍差的结果，频率也只是稍微降低，直到用户完全不再信任该系统。

过时问题有两个截然不同的诱因。第一个是语料库过时：索引中的文档已被更新、取代或仅仅是陈旧了，但它们仍被检索并展示给用户。第二个是模型对齐失效：生成索引的 Embedding 模型已更新或弃用，但你的向量从未重新生成。现在的查询是由与生成文档向量时不同的模型进行 Embedding 的，这引入了系统性的不匹配，导致检索质量全面下降。

生产环境中的 RAG 系统通常只有在尝试添加新文档并注意到混合查询的检索质量下降时，才会发现模型对齐失效的问题。到那时，语料库已经提供了数周或数月陈旧的表示。

基础设施的现实情况使这一问题更加恶化。对一个拥有 1000 万文档的语料库进行 Embedding，仅初始运行的计算成本就达 300 到 650 美元。团队为了避免这项支出而理性地推迟重新生成 Embedding，这意味着过时窗口在不断扩大。由于检索质量是逐渐退化而非灾难性崩溃，很少有一个明显的时刻能触发修复。

实施建议：

• 跟踪每个文档 Embedding 的来源和生成日期。建立自动化的新鲜度检查，标记超过预设年龄阈值的文档。
• 进行每周质量评估：选取 50 到 100 个固定的测试查询，并将检索结果与一个月前的基准进行对比。这组固定查询的召回率和准确率能告诉你检索层是否正在退化。
• 更新 Embedding 模型时，在弃用旧模型之前先制定迁移计划。采取增量方式重新生成 Embedding，从流量最高的文档片段开始。
• 考虑混合检索 —— 将稠密向量搜索与稀疏关键词匹配相结合 —— 作为对抗 Embedding 过时的对冲手段。稀疏组件不会以同样的方式退化，可以在向量质量下降时进行补偿。

分布式系统增加了另一个维度：如果你的 Worker 持有内存索引，它们看不到其他 Worker 写入的更新。这不是一个理论上的担忧 —— 这是一个常见的生产环境陷阱，会导致同一服务的不同实例对同一查询返回不同的结果。

季度审计规程

这三个债务时钟并不需要通过完全重新架构来管理。它们需要的是一个按可预测节奏运行的维护规程。

每季度一次是一个合理的默认选择。审计包含五个部分：

Prompt 审查。 提取过去 90 天的 Prompt 性能指标。对于每个生产环境的 Prompt，将当前得分分布与上季度的基准进行对比。标记任何显示相对退化超过 15% 的 Prompt。检查被标记的 Prompt，重点关注指令清晰度、模型版本固定和测试覆盖率。

评估覆盖率检查。 抽取 200 到 300 个近期生产环境的查询，并按意图和主题进行聚类。将聚类分布与你现有的评估集进行对比。增加代表性不足的聚类示例。剔除不再反映真实流量的聚类示例。

Embedding 新鲜度扫描。 运行 Embedding 来源检查。在高检索量的语料库片段中，任何早于新鲜度阈值的文档都应排队重新生成 Embedding。如果 Embedding 模型在上一季度进行了更新，请评估影响并安排迁移。

漂移指标审查。 提取过去 90 天的 PSI、输出方差和检索准确率趋势，并将它们整合到一个视图中。任何相对于基准变动超过 20% 的指标都应落实负责人和修复时间表。

可观测性差距评估。 识别 AI 流水线中哪些环节没有监控手段，并安排覆盖。未被监控的流水线阶段是静默债务累积最快的地方。

总的时间投入是每季度几个工程师日。这并非微不足道，但远低于在债务复利导致用户可见的质量退化后再去应对的成本。

潜在的转变

传统的技术债务假设环境是静态的：代码本身不会改变行为。AI 系统则不然。提供商的模型会更新，用户与产品的交互方式会改变，语料库中的文档会老化，评估分布会漂移 —— 这一切都在持续发生，而且大部分发生时你的代码库没有任何变化。

这意味着 AI 系统需要以传统软件不需要的方式进行持续的管理。这不像是一个你每隔几年重构一次的代码库，它更接近于生产数据库：你持续监控它，定期运行维护任务，并将退化视为调查信号，而不是一个只能默默忍受的谜团。

三个债务时钟正在滴答作响。运行季度审计规程是你准确掌握时间的办法。