1. 这不是模型跑不跑得动的问题，是整套AI工程体系正在悄悄“生锈”

“Generative AI’s Growing Tech Debt: Managing the Ripple Effect”——这个标题乍看像一篇行业评论，但如果你正带着一个LLM应用上线、刚把RAG流程跑通、正为微调后的模型在生产环境里偶发幻觉焦头烂额，那你立刻就懂了：这说的不是远在天边的趋势预测，而是你昨天刚合并进主干的那行prompt engineering代码、你临时加的第三层重排序逻辑、你为了赶Q3交付而跳过的schema校验……它们正以每天0.3%的速度，把你的系统拖向不可维护的临界点。 技术债（Tech Debt） 这个词在传统软件工程里大家耳熟能详，可当它撞上生成式AI——一个高度依赖非确定性输出、数据与代码深度耦合、评估标准模糊、迭代节奏以小时计的全新范式时，它的形态、传播路径和破坏力，已经彻底变了。它不再只是“等我有空再重构”的拖延借口，而是像地下水渗漏一样，在embedding更新滞后、prompt版本失控、评估指标失真、监控盲区扩大、人工反馈闭环断裂这些具体环节里，持续制造微小但累积性的偏差。我去年主导过三个不同规模的生成式AI落地项目：一个面向客服的对话摘要系统，一个金融研报的自动初稿生成平台，还有一个工业设备维修知识库的问答引擎。无一例外，前三个月上线顺利，第六个月开始出现“说不清道不明”的性能滑坡——不是宕机，不是报错，而是回答越来越泛、引用越来越虚、响应延迟波动加大、人工修正率从8%爬升到27%。回溯根因，92%的问题都指向同一类被忽略的细节：我们用写Python脚本的思维在管理一个活的、呼吸的、会随数据流缓慢变异的AI系统。这篇文章不讲大道理，不列宏观趋势图，只拆解我在真实战场中亲手踩过、记录过、修复过的七类生成式AI特有技术债，告诉你它们长什么样、怎么识别、在哪埋雷、如何量化、以及最关键的——用什么最小成本动作去拦截。适合所有正在把大模型从Demo推进Production的工程师、产品经理、AI架构师，尤其适合那些已经听到服务器风扇声变大、看到运维告警频率上升、或者发现每周例会里“为什么效果不如上周”成了固定议题的团队。

2. 生成式AI技术债的本质：它不是代码坏掉了，是“认知对齐”在持续漂移

2.1 传统技术债 vs 生成式AI技术债：一场底层逻辑的迁移

传统软件的技术债，核心是“实现与设计的偏离”。比如该用设计模式的地方硬编码了，该做单元测试的地方留了空，该抽象的接口被写死了——问题出在代码结构本身，修复路径清晰：重构、补测、解耦。而生成式AI的技术债，核心是“系统行为与业务意图的渐进式脱钩”。它不源于某段代码写错了，而源于以下五个动态要素的持续偏移：

• 数据漂移（Data Drift） ：你训练/微调时用的客服对话样本，是去年Q4的；但当前线上流量里，63%的新用户来自Z世代，他们用梗、缩写、表情包提问的方式，让旧embedding空间完全失效。这不是数据量不够，是数据分布的语义重心发生了位移。

• Prompt漂移（Prompt Drift） ：你在v1.2版本里写的那条“请用专业但亲切的口吻，控制在120字内，结尾带emoji”的system prompt，被市场部在v1.5悄悄改成“请体现品牌年轻化，加入网络热词”，结果模型开始滥用“绝绝子”“yyds”，专业度崩塌。Prompt不再是配置项，而是活的API契约，却没人给它做版本管理和兼容性测试。

• 评估漂移（Evaluation Drift） ：你上线时用BLEU+人工抽检双轨评估，效果达标；但三个月后，业务方反馈“回答太保守，不敢给明确建议”，你才发现BLEU高只说明语法顺，不说明决策力强。评估指标本身成了技术债的温床——它没坏，只是不再匹配新阶段的业务目标。

• 依赖漂移（Dependency Drift） ：你依赖的Hugging Face某个LoRA权重，作者在v2.1.3悄悄调整了归一化层参数；你用的LlamaIndex版本升级后，默认chunk size从512变成1024，导致RAG召回精度断崖下跌。外部依赖的微小变更，通过非线性放大，直接击穿你的SLA。

• 认知漂移（Cognitive Drift） ：这是最隐蔽也最致命的。你最初定义“好回答”的标准是“准确引用知识库”，后来变成“能主动追问模糊需求”，再后来变成“能预判用户下一步操作并给出快捷按钮”。团队内部对“什么是好”的共识，每季度都在变，但你的监控大盘、AB测试框架、反馈收集表单，还钉在第一个定义上。

提示：生成式AI技术债的利息不是CPU占用率，而是“人工干预率”和“用户放弃率”的缓慢爬升。它不报警，它只是让你的运营同学越来越忙，让你的客户满意度曲线越来越平。

2.2 技术债的“涟漪效应”：为什么一个小改动会引发三周后的大故障

“Managing the Ripple Effect”中的Ripple，绝非修辞。它精准描述了生成式AI系统中技术债的传播机制——不是链式传导，而是球面扩散。举个我亲身经历的案例：我们在金融研报生成系统里，为提升“风险提示”模块的严谨性，临时加了一条规则：“若检测到‘可能’‘或许’‘预计’等模糊动词，强制追加‘以上预测基于当前公开信息，不构成投资建议’”。看似安全，实则埋下三重涟漪：

• 第一层涟漪（即时，小时级） ：模型开始过度敏感，把“该技术有望降低能耗”里的“有望”也判定为模糊动词，导致所有正面展望都被打上免责声明，研报可信度反降。

• 第二层涟漪（延迟，3-5天） ：运营同学发现异常，手动在后台将“有望”加入白名单。但白名单未同步至离线评估流水线，导致每日自动化回归测试报告里，“风险提示覆盖率”指标虚假飙升，掩盖了真实问题。

• 第三层涟漪（潜伏，2-3周） ：由于白名单只在生产环境生效，新入职的算法同学在本地复现问题时，用的是原始prompt，调试三天无果，最终误判为模型微调失败，重新启动耗时两天的全量微调——而真正的问题，只是一行没同步的配置。

这种涟漪不是bug，是系统复杂度在非线性交互下的必然涌现。它无法靠单点测试捕获，必须用“债图谱（Debt Graph）”来建模：每个组件（prompt、embedding、reranker、post-process rule）都是一个节点，节点间的依赖关系（数据流、控制流、语义约束）是边，而技术债就是边上的“衰减系数”。当系数超过阈值，涟漪就从扰动变成冲击。

2.3 为什么“先上线再优化”在生成式AI里是高危策略

很多团队信奉敏捷哲学，把生成式AI项目也套用MVP（最小可行产品）逻辑：先用一个基础prompt+开源模型跑通流程，再逐步迭代。这在传统Web开发中成立，但在生成式AI中，它等于主动埋设定时炸弹。原因有三：

• 初始Prompt即契约 ：用户第一次体验，就建立了对系统能力的隐性预期。你v1版用GPT-3.5返回简洁答案，v2版切到Llama3后因token限制被迫分段回复，用户感知就是“变卡了”“不连贯了”，哪怕技术上更先进。这种心智契约一旦形成，后续所有优化都要付出额外的用户教育成本。

• 数据冷启动陷阱 ：v1版没有人工反馈闭环，所有用户交互数据都是“噪声”。当你在v3版想用这些数据做偏好微调时，会发现72%的点击是误触，41%的“不满意”反馈没填原因——高质量信号严重不足。你不是在优化，是在清洗垃圾。

• 监控基线失真 ：v1版只监控“响应时间<2s”和“HTTP 200率”，完全没覆盖“事实一致性”“逻辑连贯性”“风格稳定性”。等你意识到要加这些指标时，已失去历史基线，无法判断v4版的“风格稳定性提升15%”是真进步还是统计噪音。

我见过最痛的教训：一个医疗问答bot，v1版为快速上线，直接调用第三方API返回答案，未做任何溯源校验。上线两周后，用户投诉某条关于药物相互作用的回答存在严重错误。团队紧急下线，复盘发现——错误答案来自第三方API的缓存陈旧数据，而我们的系统连“该答案是否来自缓存”这个元信息都没记录。修复花了11人日，但信任重建花了半年。

3. 七类高频生成式AI技术债的现场诊断与量化方法

3.1 Prompt债务：那个没人敢动的“祖传prompt.txt”

典型症状 ：

• 新增一个业务场景，需要复制粘贴整个prompt模板，再手工修改20处变量名；
• A/B测试时发现，两个prompt仅差一个标点，效果差异达37%，但没人知道为什么；
• 运维同学半夜收到告警：“prompt长度超限”，排查发现是某运营同事在后台富文本编辑器里加了空格和换行。

现场诊断法（实操步骤） ：

1. 提取所有活跃prompt ：扫描代码库、配置中心、数据库、甚至Confluence文档，用正则 (?i)system|user|assistant.*?"""(.*?)""" 抓取所有字符串；
2. 构建Prompt指纹 ：对每个prompt做标准化（去空格、换行、统一引号），再计算SHA256哈希，相同哈希=同一份prompt；
3. 关联效果数据 ：将指纹与最近7天的线上AB测试ID、人工评分ID、bad case ID关联，生成“Prompt健康度看板”。

量化指标（必须落地） ：

• 熵值（Entropy） ：用字符级信息熵公式 H = -Σ p(x) * log₂p(x) 计算。熵值>4.2，说明prompt含大量冗余修饰词（如“请务必”“绝对不要”“非常非常重要”），易引发模型困惑；熵值<2.8，说明过于简略，缺乏必要约束。我们团队的黄金区间是3.1~3.9。
• 变量密度（Variable Density） ： 变量占总token数比例 。>15%需警惕——说明业务逻辑过度侵入prompt，应抽离为独立服务。
• 版本碎片率（Version Fragmentation） ： 不同指纹的prompt数量 / 总prompt调用次数 。>0.3意味着管理失控，急需Prompt Registry。

实操心得：我们曾用熵值分析发现，某客服prompt里连续11个“请”字，把熵值拉到4.8。删掉重复敬语，保留3个关键“请”，人工评分反升12%，响应速度加快0.8秒。Prompt不是越长越好，是越“信息密度高”越好。

3.2 Embedding债务：你以为的语义相似，其实是同义词陷阱

典型症状 ：

• RAG召回的文档片段，和用户问题在字面上高度相关，但语义南辕北辙；
• 同一概念（如“碳中和”），在不同部门文档里用词迥异（“净零排放”“气候中性”“碳平衡”），embedding却无法聚类；
• 微调embedding模型后，线上召回率下降，但离线benchmark反而提升——说明测试集和线上分布严重不一致。

现场诊断法（实操步骤） ：

1. 采样线上Bad Case ：随机抽取100个“用户提问→召回top3文档→人工标注相关性（0-5分）”样本；
2. 可视化嵌入空间 ：用UMAP降维，将问题向量、召回文档向量、人工标注高分向量，用不同颜色标记；
3. 定位漂移簇 ：观察高分向量是否形成紧密簇，若分散或与低分向量混杂，即存在embedding债务。

量化指标（必须落地） ：

• 语义一致性得分（SCS） ：对每个问题，计算其召回top3文档向量的两两余弦相似度均值。SCS < 0.45，说明召回结果语义发散；SCS > 0.65，说明过度收敛，可能漏掉合理变体。
• 跨域对齐误差（CAE） ：选取50组业务术语（如“授信额度”vs“信用额度”），计算其在embedding空间中的欧氏距离。CAE > 1.8，说明同义词未对齐。
• 新鲜度衰减率（FDR） ：每周用最新一周的用户query重算SCS，对比上周变化。FDR > 5%/周，需立即触发embedding增量更新。

注意：别迷信“更大模型=更好embedding”。我们实测发现，text-embedding-3-large在金融术语上SCS仅0.38，而微调后的bge-small-zh-v1.5达到0.52。债务不在模型大小，而在领域适配精度。

3.3 评估债务：当BLEU值飙升，用户却在骂街

典型症状 ：

• AB测试报告显示新模型BLEU+12%，但客服后台“用户追问率”上升23%；
• 人工抽检100条回答，92条被评“准确”，但其中67条被用户标记为“没解决我的问题”；
• 每次模型更新，都要重写评估脚本，因为旧指标无法覆盖新能力（如多跳推理、表格生成）。

现场诊断法（实操步骤） ：

1. 构建三层评估矩阵 ：
   • 基础层 ：自动化指标（BLEU, ROUGE, BERTScore）；
   • 语义层 ：LLM-as-a-Judge（用GPT-4o对回答做结构化评分，含事实性、连贯性、有用性3维度）；
   • 业务层 ：埋点真实用户行为（停留时长>30s且无后续提问=有效解决；点击“重新生成”>2次=失败）。
2. 计算指标漂移度（Drift Score） ： |新模型指标 - 基线指标| / 基线指标标准差 。Drift Score > 2.0，说明该指标已失效。

量化指标（必须落地） ：

• 业务对齐度（BAI） ： 业务层指标提升率 / 基础层指标提升率 。BAI < 0.5，说明基础指标严重失真；BAI > 1.5，说明业务指标可能过拟合短期行为。
• 评估噪声比（ENR） ：对同一组回答，用3种不同LLM-as-a-Judge模型评分，计算标准差/均值。ENR > 0.25，说明评估本身不稳定，需增加人工校准。
• 评估覆盖缺口（ECG） ：统计近30天所有bad case，看有多少未被任一评估层捕获。ECG > 40%，证明评估体系存在结构性盲区。

实操心得：我们曾发现，某版模型在ROUGE-L上提升18%，但BAI仅为0.21。深挖发现，它擅长生成冗长、堆砌术语的回答，ROUGE喜欢这种“表面相似”，但用户需要的是“一句话结论”。于是我们新增“结论前置率”指标（回答首句含结论关键词的比例），BAI立刻回升至0.89。

3.4 监控债务：你的Prometheus大盘，可能正在撒谎

典型症状 ：

• Grafana显示P95延迟稳定在1.2s，但用户实际感知卡顿频发；
• “LLM调用成功率”99.99%，但“用户满意率”只有63%；
• 某天凌晨3点，所有监控指标正常，但人工审核发现87%的回答存在事实错误——因为错误发生在post-process环节，而监控只盯API层。

现场诊断法（实操步骤） ：

1. 绘制监控覆盖图谱 ：列出所有关键链路（Input → Prompt注入 → LLM Call → Output Parse → Post-process → Render），对每个环节标注：
   • 是否有延迟监控？
   • 是否有错误码分类？
   • 是否有业务语义监控（如“事实错误率”“风格偏移度”）？
2. 注入可控故障 ：在post-process环节，随机将10%的回答末尾加“[系统自检：此回答未经人工审核]”，观察监控是否告警。未告警=覆盖缺口。

量化指标（必须落地） ：

• 语义监控覆盖率（SMC） ： 有业务语义监控的环节数 / 总环节数 。SMC < 0.6，系统处于高危状态。
• 感知延迟偏差（PLD） ： 用户端实测P95延迟 / 监控大盘P95延迟 。PLD > 1.8，说明前端渲染、网络传输等环节被忽视。
• 静默故障率（SFR） ： 未触发任何监控告警的bad case数 / 总bad case数 。SFR > 15%，证明监控体系与业务风险脱钩。

提示：别只盯着LLM API的status code。我们在线上加了“输出解析健康度”监控：对每个JSON response，实时校验schema合规性、字段必填性、数值范围。这项监控在一次模型升级中提前2小时捕获了“temperature参数溢出导致JSON格式崩溃”的故障，避免了全量服务中断。

3.5 依赖债务：那个在requirements.txt里沉睡三年的包

典型症状 ：

• 升级一个次要依赖（如langchain-core），导致RAG召回逻辑完全失效；
• 某个开源LoRA权重的作者删库跑路，你的生产环境突然无法加载；
• 本地运行完美，CI流水线失败，原因是CI镜像里的torch版本比本地低0.0.1。

现场诊断法（实操步骤） ：

1. 构建依赖影响图 ：用 pipdeptree --reverse --packages your-package 生成依赖树，重点标记：
   • 直接依赖（你代码里import的）；
   • 间接依赖（依赖的依赖）；
   • 已归档/停止维护的包（查PyPI last updated时间）；
2. 执行脆弱性扫描 ：用 safety check -r requirements.txt + pip-audit ，但不止看CVE，更要看“功能废弃警告”（如某包文档明确写“v2.0起弃用Embedding类”）。

量化指标（必须落地） ：

• 间接依赖渗透率（IDR） ： 间接依赖包数 / 总依赖包数 。IDR > 0.65，说明系统过于脆弱，一个底层包变更就能雪崩。
• 维护健康度（MHD） ：对每个依赖包，计算 (近6月commit数 + 近3月issue响应率) / 2 。MHD < 3.0，视为高风险。
• 锁定严格度（LS） ： requirements.txt中精确版本锁（==）占比 。LS < 0.8，意味着你随时可能被上游“静默升级”坑。

实操心得：我们曾因 llama-index 一个patch版本将默认chunk overlap从128改为0，导致RAG召回精度暴跌。根源是requirements.txt里写的是 llama-index>=0.10.0 。改成 llama-index==0.10.32 并加入CI检查后，再未发生类似事故。生成式AI的依赖，必须比金融系统更苛刻。

3.6 反馈债务：你收集的10万条“不满意”，可能全是噪音

典型症状 ：

• 用户点了“不满意”，但没填原因，后台积压12万条空反馈；
• 运营同学每天花2小时人工阅读反馈，但90%是“太长了”“看不懂”这类模糊描述；
• 想用反馈数据做强化学习，却发现标签质量太差，训练出的模型更差。

现场诊断法（实操步骤） ：

1. 反馈质量审计 ：随机抽样500条“不满意”反馈，人工标注：
   • 是否含具体错误点（如“第3段说错利率”）？
   • 是否含期望输出（如“请只给数字，不要解释”）？
   • 是否可归因到具体模块（prompt/LLM/embedding）？
2. 构建反馈价值分（FVS） ： 0.4*具体性 + 0.4*可操作性 + 0.2*归因清晰度 。FVS < 0.3的反馈，直接丢弃。

量化指标（必须落地） ：

• 高价值反馈率（HVFR） ： FVS≥0.5的反馈数 / 总反馈数 。HVFR < 15%，说明反馈机制设计失败。
• 反馈闭环时效（FCT） ：从反馈提交到对应prompt/模型更新上线的平均时长。FCT > 72小时，用户已失去耐心。
• 反馈驱动改进率（FDIR） ： 由反馈直接触发的线上变更数 / 总线上变更数 。FDIR < 20%，证明反馈未进入核心迭代循环。

注意：别让用户填开放式文本框。我们上线后，将“不满意”按钮拆成5个带标签的快捷选项（“事实错误”“逻辑混乱”“太啰嗦”“没回答”“风格不符”），再加一个可选的15字内补充。HVFR从7%飙升至38%，FCT缩短至19小时。

3.7 认知债务：当团队里没人能说清“好”的定义

典型症状 ：

• 产品经理说“要更专业”，算法同学理解为“增加术语密度”，结果用户投诉“看不懂”；
• 每次评审会，大家对同一条bad case有3种不同归因（prompt问题？模型问题？数据问题？）；
• 新成员入职，要花两周时间听各种“口头约定”，才能明白“什么叫合格回答”。

现场诊断法（实操步骤） ：

1. 开展认知对齐工作坊 ：召集产品、算法、运营、客服代表，用KJ法对50条典型回答（含good/bad）进行现场分类，记录分歧点；
2. 构建“好”的原子定义库 ：将共识提炼为可测量的原子规则，如：
   • “事实性” = 回答中所有实体（人名/地名/数字/专有名词）必须能在知识库中找到原文支撑；
   • “简洁性” = 有效信息密度 ≥ 0.65（有效token数/总token数，有效token指非停用词、非重复词、非填充词）。

量化指标（必须落地） ：

• 认知共识度（CCD） ：对同一组20条回答，不同角色独立评分，计算Krippendorff's Alpha系数。CCD < 0.6，说明定义模糊。
• 定义可执行率（DER） ：原子定义中，能被自动化脚本验证的比例。DER < 0.7，说明定义仍停留在主观层面。
• 新人上手时长（NHT） ：新成员首次独立处理bad case并产出有效改进方案的平均时长。NHT > 5天，证明认知未沉淀。

实操心得：我们曾用CCD工作坊发现，产品和算法对“专业性”的理解偏差高达0.41。于是共同制定《专业性原子检查表》：禁用第一人称、禁用口语助词、数字必须带单位、专业术语首次出现需括号注释。DER达0.89，NHT缩短至1.2天。认知债务，必须用可执行的原子规则来固化。

4. 管理涟漪效应：一套可立即落地的生成式AI技术债治理框架

4.1 Debt Radar（债务雷达）：让隐形债变成可视仪表盘

这不是另一个监控大盘，而是一个专为生成式AI设计的“债健康度中枢”。它不替代现有监控，而是叠加一层语义风险视图。我们用4周时间在内部落地，核心是三个轻量级组件：

• Debt Collector（债务采集器） ：一个轻量Python服务，部署在API网关后，实时捕获：

  • 每次请求的prompt指纹、LLM调用参数（model/temperature/top_p）、原始输出、post-process结果、用户反馈（含快捷标签）；
  • 关键中间态：embedding召回的top3文档ID、rerank分数、parse后的JSON schema校验结果。
    所有数据打上时间戳、trace_id、session_id，写入专用ClickHouse表。

• Debt Scorer（债务评分器） ：基于前述七类债务的量化指标，为每次请求计算：

  • 即时债分（Instant Debt Score, IDS） ： 0.3*Prompt熵值 + 0.25*SCS + 0.2*BAI + 0.15*SMC + 0.1*HVFR ，满分10分，>6分标红；
  • 累积债分（Cumulative Debt Score, CDS） ：按session_id聚合过去24小时IDS均值，>4.5触发预警。
    评分逻辑全部开源，算法同学可随时调整权重。

• Debt Dashboard（债务仪表盘） ：Grafana定制面板，核心视图：

  • 债热力图 ：X轴时间（小时），Y轴为七类债务，色块深浅=该时段该类债务平均IDS；
  • 涟漪追踪 ：点击某次高IDS请求，自动展开完整调用链，高亮所有异常环节（如“SCS=0.28（偏低）← embedding召回文档#A772语义偏离”）；
  • 债归因TOP5 ：实时滚动显示当前最高频的债类型及根因（如“Prompt熵值超标：检测到17处重复强调词”）。

提示：Debt Radar不是追求100%准确，而是提供“足够好”的风险感知。我们设定IDS>6即告警，虽有5%误报，但100%捕获了所有重大故障。在生成式AI里，宁可多看10次告警，不可漏掉1次涟漪。

4.2 Debt Sprint（债务冲刺）：把还债变成常规研发节奏

拒绝“专门抽时间还债”的伪命题。我们将技术债治理深度融入双周迭代：

• Debt Backlog（债务待办） ：在Jira中创建专属看板，所有Debt Radar告警、人工巡检发现、用户反馈聚类，自动创建为Issue，标签化： debt-prompt 、 debt-embedding 、 debt-eval 等。每个Issue必须含：

  • 可复现的trace_id；
  • 当前IDS/CDS值；
  • 预期修复后的指标目标（如“Prompt熵值降至3.5”）；
  • 影响范围（影响多少%的请求）。

• Debt Slot（债务槽位） ：每个双周Sprint，强制预留20%工时（非人天）给债务项。由Tech Lead根据Debt Dashboard的“债热力图”分配：

  • 热力图红色区域（IDS>6）的债务，优先级P0，必须本Sprint解决；
  • 黄色区域（IDS 4-6）的债务，P1，可延至下Sprint；
  • 绿色区域（IDS<4）的债务，P2，仅当无更高优任务时处理。

• Debt Review（债务评审） ：Sprint评审会最后30分钟，只做一件事：展示本次修复的3个典型债务项，用数据说话：

  • 修复前：IDS=7.2，HVFR=12%，用户追问率=31%；
  • 修复后：IDS=3.8，HVFR=41%，用户追问率=19%；
  • 关键动作：将“碳中和”等12个术语加入embedding同义词表，重训轻量微调模型。

实操心得：我们曾将“Prompt熵值超标”列为P0债，算法同学用3天时间重构prompt模板，引入变量注入机制，熵值从4.8降至3.4。下个Sprint，该类告警下降92%。债务冲刺的关键，是让每一次修复都可衡量、可感知、可庆祝。

4.3 Debt Contract（债务契约）：用四份轻量文档，固化团队认知

技术债治理不能只靠工具，必须靠契约。我们制定了四份一页纸文档，全员签署，作为入职必读和季度复盘依据：

• 《Prompt契约》 ：明确规定——

  • 所有prompt必须经Prompt Registry发布，禁止硬编码；
  • 每个prompt必须有唯一指纹、版本号、负责人、生效日期；
  • 修改prompt必须提交PR，附带：修改原因、预期影响、验证方案（至少3个测试case）。

• 《Embedding契约》 ：明确规定——

  • embedding模型必须每月至少一次增量更新，使用最新30天用户query重训；
  • 所有业务术语必须维护在 synonym_map.yaml 中，新增术语需经产品+算法双签；
  • RAG召回必须返回 retrieval_score 和 semantic_distance ，供下游监控。

• 《评估契约》 ：明确规定——

  • 上线新能力，必须同步定义3个可自动化验证的业务指标；
  • 所有AB测试，基础层指标（BLEU等）与业务层指标（用户追问率等）必须同时达标；
  • 每季度，由QA牵头，用50条历史bad case重跑所有评估脚本，验证指标有效性。

• 《反馈契约》 ：明确规定——

  • 用户反馈必须含结构化标签（5个快捷选项）和15字内补充；
  • 运营同学每日晨会，通报前24小时HVFR和FCT；
  • 每条FVS≥0.7的反馈，必须在24小时内分配至责任人，并在Jira中更新进展。

注意：契约不是束缚，而是降低协作成本。签署后，当产品提出“加个网络热词”，算法可直接拿出《Prompt契约》说：“按契约，需提交PR并附测试case，预计2人日”。所有人对齐了成本和流程，争论自然消失。

5. 常见问题与实战排障手册：那些深夜告警电话背后的真相

5.1 “为什么模型突然变笨了？我们没动代码！”——真相：Embedding静默漂移

现象 ：某天凌晨2点，Debt Radar告警：CDS飙升至7.8，主要来自 debt-embedding 。查看热力图，SCS从0.52骤降至0.29。团队确认：过去48小时无任何代码发布，LLM模型、prompt、服务配置均未变更。

排查路径 ：

1. 查 Debt Collector 原始日志，筛选SCS<0.3的请求，提取其用户query；
2. 发现高频query为“Z世代消费观”“00后职场痛点”——全部来自新上线的校园招聘频道；
3. 检查embedding更新日志：上次增量更新是5天前，使用的是Q2财报数据，完全不含Z世代语料；
4. 验证：用最新校园招聘query重跑embedding，SCS回升至0.55。

根治方案 ：

• 将embedding增量更新频率，从“每日”改为“按流量分布自动触发”：当新语料（如新频道、新活动）query占比超15%时，自动触发mini-batch重训；
• 在 Debt Scorer 中增加 语料新鲜度 指标： 最新query中，距embedding训练数据时间>7天的占比 ，>20%即告警。

实操心得：我们曾因此故障损失3小时黄金修复窗口。现在，embedding自动更新在15分钟内完成，CDS在10分钟内回落。生成式AI的“静默漂移”，比显性故障更危险，因为它不触发传统监控。

5.2 “A/B测试赢了，但用户在骂！”——真相：评估指标与业务目标错位

现象 ：新prompt版本在AB测试中，BLEU提升22%，ROUGE-L提升18%，但上线后客服后台“用户追问率”从18%飙升至41%，NPS下降27点。

排查路径 ：

1. 查 Debt Dashboard 的“评估漂移”视图，发现BAI=0.13（严重失真）；
2. 抽样分析bad case：新prompt强制要求“每段开头用emoji”，导致模型为凑数，在专业分析段落插入无关emoji，干扰用户阅读；
3. 检查评估脚本：只用了BLEU/ROUGE，未加入“emoji密度”“段落连贯性”等业务指标。

根治方案 ：

• 立即下线该prompt，启用《评估契约》：所有新prompt上线，必须通过“基础指标+业务指标”双门槛；
• 在评估流水线中，新增 视觉干扰度 指标：用OCR识别回答中的emoji位置，计算其打断正文段落的频率；
• 将“用户追问率”设为P0监控，阈值>25%即熔断。

提示：别迷信学术指标。我们后来发现，对客服场景，“用户追问率”与“回答首句含解决方案关键词”的相关性高达0.89，而与BLEU的相关性仅0.12