1. 长假期间AI项目连环故障的现场还原国庆长假对大部分人是休息对做AI应用落地的团队却往往是最紧张的时间窗口。流量高峰、值班人手减半、上游服务商轮休任何一个环节出问题都会被放大。今年这7天里我所在的几个技术交流群里接连出现了三次比较典型的AI项目故障圈内人戏称三连翻。这三次故障分别指向三个不同的技术层面模型服务层的接口变更、应用层的上下文管理失控、数据层的向量检索质量塌方。它们看起来是三个独立事件但底层逻辑高度一致——都是看起来能跑一上量就崩的典型症状。先把这三次故障的轮廓勾勒出来方便你对号入座。第一次是某团队调用的大模型接口在假期第一天悄悄调整了返回格式原本稳定的JSON结构里多了一层嵌套导致下游解析代码直接抛异常整个对话功能全线不可用。第二次是另一个做智能客服的项目长假咨询量翻了三倍结果对话历史越堆越长上下文窗口被塞爆模型开始胡言乱语用户投诉激增。第三次最隐蔽一个做知识库问答的系统向量库里的文档在假期前刚做过一次批量更新但embedding模型没跟着换新旧向量混在一起检索出来的答案驴唇不对马嘴而且因为召回率指标看着还行问题拖了三天才被发现。这三个案例我之所以拿出来讲不是因为它们多罕见恰恰相反它们太常见了常见到每个做过AI应用落地的人大概率都踩过其中至少一个。标题里说你还没被割韭菜代码已先崩盘话糙理不糙。很多人把精力花在追新模型、追新框架上却忽略了工程层面那些最基础、最要命的稳定性问题。这篇内容就是想把这三个坑掰开揉碎讲清楚它们为什么会发生、怎么快速定位、以及怎么在架构层面提前防住。不管你是刚入门的AI应用开发者还是带团队的技术负责人这些经验都能直接拿去用。2. 第一次翻车模型接口变更引发的解析雪崩2.1 故障现象与第一反应故障发生在一个做内容生成工具的项目上。这个工具的核心逻辑不复杂用户输入一段需求描述后端拼装成prompt发给大模型拿到返回结果后解析出正文、标题、标签三个字段再存库返回给前端。假期第一天上午值班同事发现所有生成请求都返回500错误日志里清一色是KeyError: content。第一反应是模型服务挂了但手动用curl测试接口发现服务是通的返回也有内容。问题出在解析环节。把原始返回打印出来一看原本的response[choices][0][message][content]路径变了新返回里message对象下多了一个reasoning_content字段而content字段在某些情况下会变成空字符串真正的正文被放到了新字段里。这就是典型的接口静默变更——服务商没有提前公告或者公告了但没被注意到返回结构发生了向后不兼容的调整。对于依赖固定JSON路径解析的代码来说这就是致命打击。2.2 为什么这类问题总在假期爆发这里有个很多人忽略的规律上游服务的变更窗口往往选在流量低谷期而长假恰好是很多To B类AI应用的流量低谷。服务商想着趁这时候发版影响最小但对于那些7×24小时运行的应用来说低谷不等于停服。更麻烦的是假期值班的人往往不是最熟悉这块代码的人排查链路会变长。我后来复盘时算了一笔账从故障发生到定位到具体字段变更花了将近两个小时。这两个小时里如果有一个完善的接口契约测试在跑问题在变更发生后的第一次定时检测中就能被发现而不是等真实用户请求撞上来。接口契约测试说白了就是定时用固定输入去调接口断言返回结构的关键字段存在且类型正确。这个成本极低但很多团队就是不做。2.3 防御性解析的实操写法针对这类问题最直接的防御手段是解析层做兼容和降级。不要用硬编码的路径去取字段而是写一个带默认值和类型检查的提取函数。下面是我在实际项目中用的一个Python示例你可以直接参考def extract_content(response): 从模型返回中提取正文内容兼容多种可能的返回结构。 返回 (content, error_msg) 元组。 if not isinstance(response, dict): return None, response is not a dict choices response.get(choices) if not choices or not isinstance(choices, list): return None, choices missing or invalid first choices[0] if not isinstance(first, dict): return None, choice item is not a dict message first.get(message, {}) if not isinstance(message, dict): return None, message is not a dict # 按优先级尝试多个可能的字段 for key in (content, reasoning_content, text): val message.get(key) if isinstance(val, str) and val.strip(): return val.strip(), None return None, no valid content field found这个函数的核心思路是永远不假设返回结构是稳定的。它按优先级尝试多个字段名任何一个拿到非空字符串就返回。同时每一步都做类型检查避免因为某一层变成None而抛异常。配合上层的重试和告警逻辑即使接口变了也能保证服务不直接崩同时留下足够的日志供排查。注意兼容解析只是止血不是治本。真正要做的是建立接口变更的监控机制一旦发现返回结构和基线不一致立即告警。兼容代码是给排查争取时间的不是让你永远不去管接口变化。2.4 接口监控的最小可行方案监控方案不需要多复杂一个定时任务加一个基线快照就够了。具体做法是每天固定时间用一组标准输入调用接口把返回的结构骨架不是具体内容而是字段名和类型的树形结构存下来和前一天做diff。如果结构发生变化发通知。这个方案我用下来能覆盖90%以上的静默变更场景。结构骨架的提取可以用递归函数实现把JSON的每个key和对应的value类型记录下来忽略具体的字符串值。这样即使模型回答的内容每天不同结构骨架也是稳定的只有真正的结构变更才会触发告警。这个思路同样适用于其他第三方API的监控不限于大模型接口。3. 第二次翻车上下文窗口被撑爆的连锁反应3.1 从答非所问到胡言乱语的演变第二个故障发生在智能客服场景。这个项目的对话逻辑是每次用户发消息把历史对话全部拼进prompt一起发给模型。平时咨询量不大单次对话轮数也少跑了大半年没出过问题。长假期间咨询量涨了三倍同时单个用户的对话轮数也变多了因为活动期间用户问题更复杂来回追问的次数明显增加。问题在第二天下午开始显现。用户反馈客服答非所问明明问的是退货流程回答的却是产品参数。再往后模型开始输出一些完全不相关的内容甚至出现重复上一轮回答的情况。值班同事一开始以为是模型服务的问题换了模型还是一样这才意识到是上下文管理出了岔子。3.2 上下文窗口的硬限制与软限制这里需要区分两个概念硬限制是模型本身支持的最大token数超过就直接报错或截断软限制是实际使用中为了保证效果而设定的更小的阈值。很多人只关注硬限制觉得没超就行但实际上接近硬限制时模型的表现会明显下降。原因有两个一是长上下文里噪声信息占比高模型注意力被稀释二是很多模型在长上下文下的推理质量本身就会衰减。我一般建议把软限制设在硬限制的60%到70%。比如模型支持8K token那实际拼装的prompt控制在5K左右。留出的空间一是给模型输出二是给上下文质量留余量。这个比例不是拍脑袋定的是实测出来的超过70%之后回答准确率的下降曲线会明显变陡。3.3 上下文压缩的三种策略对比解决上下文膨胀核心思路是压缩。我试过三种策略各有适用场景下面用表格对比一下策略做法优点缺点适用场景滑动窗口只保留最近N轮对话实现简单延迟低丢失早期关键信息短对话、信息密度低的场景摘要压缩用模型把早期对话总结成一段话保留关键信息压缩率高增加一次模型调用有信息损耗长对话、需要记忆的场景关键信息抽取抽取实体、意图等结构化信息信息最精准可控性强实现复杂需要设计抽取逻辑业务逻辑明确的场景实际项目中我通常把滑动窗口和摘要压缩结合使用最近3到5轮保留原文更早的对话用摘要替代。摘要的prompt要设计好明确要求保留用户身份、已确认的需求、未解决的问题这三类信息。这样既控制了token量又不至于把关键上下文丢掉。3.4 一个可直接复用的上下文管理实现下面这个类是我在多个项目中复用过的上下文管理器核心逻辑是分层保留加自动摘要class ContextManager: def __init__(self, max_tokens4000, recent_rounds4, summarizerNone): self.max_tokens max_tokens self.recent_rounds recent_rounds self.summarizer summarizer # 一个可调用的摘要函数 self.history [] # 完整历史 self.summary # 早期对话摘要 def add_message(self, role, content): self.history.append({role: role, content: content}) self._maybe_compress() def _maybe_compress(self): # 估算当前token数粗略按字符数/2估算中文 total_chars sum(len(m[content]) for m in self.history) estimated_tokens total_chars // 2 len(self.summary) // 2 if estimated_tokens self.max_tokens: return # 需要压缩把最老的几轮对话合并进摘要 keep_count self.recent_rounds * 2 # 每轮包含user和assistant if len(self.history) keep_count: return to_compress self.history[:-keep_count] self.history self.history[-keep_count:] if self.summarizer: old_summary self.summary new_text \n.join( f{m[role]}: {m[content]} for m in to_compress ) self.summary self.summarizer(old_summary, new_text) def build_prompt(self, system_prompt): parts [system_prompt] if self.summary: parts.append(f【历史对话摘要】\n{self.summary}) for m in self.history: parts.append(f{m[role]}: {m[content]}) return \n\n.join(parts)这个实现的关键点在于压缩是增量的每次只把最老的一批对话合并进摘要而不是每次重新摘要全部历史。这样既控制了计算成本又保证了摘要的连续性。summarizer函数可以接一个便宜的小模型来做成本可控。实操心得摘要的prompt里一定要明确要求保留用户明确表达的需求和约束否则模型很容易把关键信息摘掉。我踩过这个坑用户说了三次要发票摘要里没体现后面模型就完全忘了这回事。4. 第三次翻车向量检索的隐性质量塌方4.1 最隐蔽的一次故障第三次故障是最难发现的。这是一个企业知识库问答系统用户提问后系统把问题向量化去向量库里检索最相似的文档片段拼进prompt让模型回答。假期前运营团队做了一次文档批量更新替换了一批旧文档新增了一批新文档。更新流程走的是标准流程文档入库、切分、调用embedding接口生成向量、写入向量库。假期第三天有用户反馈回答的内容像是从别的文档里拼出来的。排查发现检索出来的片段确实和问题相关但相关性不够精准经常差那么一点。更麻烦的是系统的召回率指标看起来正常因为检索确实返回了结果只是结果的质量下降了。这种指标正常但体验下降的问题排查起来最费劲。4.2 新旧向量混用的根因分析根因最后定位到embedding模型在更新过程中被换过。运营团队在批量更新时发现原来的embedding接口调用有点慢就顺手换了一个更快的版本。但向量库里还存着大量用旧模型生成的向量新旧向量在同一个向量空间里做相似度计算结果自然不可靠。这里涉及一个关键概念不同embedding模型生成的向量即使维度相同也不在同一个语义空间里。把它们混在一起检索相当于拿中文词典去查英文单词表面上都是词但对应关系完全错乱。这个问题之所以隐蔽是因为向量检索本身不会报错它只是默默地返回错误的结果。4.3 向量库版本管理的实操规范避免这类问题核心是向量库和embedding模型必须版本绑定。我的做法是在向量库里为每条记录存一个model_version字段检索时只查当前版本的数据。模型升级时走完整的重建流程而不是增量更新。下面是一个简化的版本管理方案EMBEDDING_MODEL_VERSION v2.1 # 当前使用的模型版本 def search(query, top_k5): query_vec embed(query, model_versionEMBEDDING_MODEL_VERSION) # 只检索当前版本的数据 results vector_db.search( vectorquery_vec, top_ktop_k, filter{model_version: EMBEDDING_MODEL_VERSION} ) return results def rebuild_index(documents): 全量重建清空旧版本数据用新模型重新生成 new_version get_next_version() for doc in documents: chunks split_document(doc) for chunk in chunks: vec embed(chunk, model_versionnew_version) vector_db.insert( vectorvec, metadata{ model_version: new_version, doc_id: doc.id, chunk_text: chunk } ) # 重建完成后再切换当前版本 set_current_version(new_version)这个方案的关键是先建后切新版本的向量全部写入完成后再切换EMBEDDING_MODEL_VERSION检索层自动指向新数据。旧版本数据保留一段时间作为回滚备份确认新版本稳定后再清理。这样即使新模型效果不好也能快速回退。4.4 检索质量的监控指标光有版本管理还不够还需要能发现检索质量下降。传统的召回率指标在这里不够用因为它只关心有没有返回结果不关心结果对不对。我补充了两个指标一是检索结果与问题的语义相似度均值低于阈值就告警二是用户追问率如果用户频繁追问你没回答我的问题说明检索质量可能出了问题。语义相似度均值可以用一个独立的轻量模型来算不依赖检索用的embedding模型避免自己评自己的偏差。追问率则需要在前端埋点统计同一会话中用户表达不满的频次。这两个指标结合起来基本能覆盖检索质量的主要异常场景。5. 三次翻车背后的共性工程问题5.1 为什么能跑和稳定跑是两回事把三次故障放在一起看会发现一个共同点它们在低负载、短周期、小数据量的测试环境下都不会暴露。接口变更在测试时可能恰好没赶上上下文膨胀在几轮对话内看不出来向量混用在数据量小时影响也不明显。这就是能跑和稳定跑的差距。很多AI项目的开发节奏是调通接口、跑通流程、上线。中间缺少了一个稳定性验证的环节。这个环节不需要多复杂但必须包含接口契约测试、长对话压力测试、数据版本一致性检查。这三项做下来上面三次故障至少能提前发现两次。5.2 假期值班的排查效率问题假期故障还有一个特殊难点排查链路长。平时出问题喊一声相关同事就能拉群定位。假期里写代码的人可能在老家运维可能在路上沟通成本成倍增加。我经历过一次从发现问题到找到能改代码的人花了40分钟。应对这个问题我的建议是提前准备排查手册。手册里不需要写多详细但至少要包含常见故障现象对应的排查命令、关键日志的位置、各模块负责人的联系方式、回滚操作的具体步骤。这个手册平时就要维护假期前更新一遍。真出事的时候值班的人照着手册走能省下大量沟通时间。5.3 从救火到防火的架构调整三次故障之后我推动做了一轮架构调整核心是把稳定性检查前置到CI流程里。具体包括每次代码合并前跑接口契约测试每次数据更新前跑向量一致性检查每次prompt模板变更前跑长对话回归测试。这些检查单次跑起来也就几分钟但能拦住大部分低级问题。另一个调整是引入降级开关。对于模型调用、向量检索这些外部依赖都加上可配置的降级逻辑。比如模型接口异常时自动切换到备用模型或返回缓存结果向量检索质量低于阈值时降级到关键词检索。降级不追求效果完美只求服务不中断给排查争取时间。6. 常见问题速查与避坑清单6.1 故障排查速查表故障现象可能原因快速排查方法应急处理接口返回解析报错返回结构变更打印原始返回对比基线结构启用兼容解析联系服务商确认模型答非所问上下文超限或噪声过多统计prompt token数检查历史长度启用上下文压缩清理冗余历史检索结果不精准向量版本混用或模型变更检查向量库model_version字段按版本过滤检索重建索引响应变慢上下文过长或检索量过大分段计时定位耗时环节压缩上下文限制检索top_k偶发超时上游服务波动或并发过高查看上游服务状态和自身并发数增加重试和超时控制限流6.2 我踩过的几个具体坑第一个坑是过度信任上游服务的稳定性。早期我总觉得大厂接口不会随便变结果被打脸多次。现在的做法是任何外部依赖都假设它会变解析层一律做兼容关键接口一律加监控。第二个坑是用平均值掩盖问题。上下文长度、检索相似度这些指标看平均值往往没问题但分布的长尾才是故障源头。现在我都会看P95和P99这两个指标才能反映最差情况下的表现。第三个坑是数据更新没有回滚方案。向量库重建时如果新模型效果不好没有旧数据可回退只能硬着头皮往前修。现在我的做法是任何批量数据操作都保留旧版本至少一周确认稳定后再清理。6.3 给不同阶段团队的建议如果你刚起步做AI应用我的建议是先把接口兼容和上下文管理做扎实这两块是最高频的故障源投入产出比最高。向量检索可以先用简单的方案等数据量上来了再优化。如果你已经有了一定规模建议建立稳定性指标体系把接口成功率、上下文超限率、检索质量分这些指标纳入日常监控。同时把故障排查手册维护起来定期演练。如果你是技术负责人建议把稳定性检查纳入发布流程宁可发布慢一点也不要带着已知风险上线。AI应用的故障往往不是完全不能用而是用起来不对劲这种问题对用户信任的伤害更大。最后分享一个我一直在用的小技巧每次长假前做一次全链路压测用模拟的高峰流量跑一遍核心流程重点观察接口解析、上下文长度、检索质量这三个环节。压测不需要多大规模能覆盖日常峰值的1.5倍就行。这个习惯帮我提前发现过好几次潜在问题比出事后再救火划算得多。 
长河君 · 2026/10/22 10:37:43 · 阅读 1.2k AI项目长假三连翻：接口变更、上下文超限与向量检索塌方
1. 长假期间AI项目连环故障的现场还原国庆长假对大部分人是休息对做AI应用落地的团队却往往是最紧张的时间窗口。流量高峰、值班人手减半、上游服务商轮休任何一个环节出问题都会被放大。今年这7天里我所在的几个技术交流群里接连出现了三次比较典型的AI项目故障圈内人戏称三连翻。这三次故障分别指向三个不同的技术层面模型服务层的接口变更、应用层的上下文管理失控、数据层的向量检索质量塌方。它们看起来是三个独立事件但底层逻辑高度一致——都是看起来能跑一上量就崩的典型症状。先把这三次故障的轮廓勾勒出来方便你对号入座。第一次是某团队调用的大模型接口在假期第一天悄悄调整了返回格式原本稳定的JSON结构里多了一层嵌套导致下游解析代码直接抛异常整个对话功能全线不可用。第二次是另一个做智能客服的项目长假咨询量翻了三倍结果对话历史越堆越长上下文窗口被塞爆模型开始胡言乱语用户投诉激增。第三次最隐蔽一个做知识库问答的系统向量库里的文档在假期前刚做过一次批量更新但embedding模型没跟着换新旧向量混在一起检索出来的答案驴唇不对马嘴而且因为召回率指标看着还行问题拖了三天才被发现。这三个案例我之所以拿出来讲不是因为它们多罕见恰恰相反它们太常见了常见到每个做过AI应用落地的人大概率都踩过其中至少一个。标题里说你还没被割韭菜代码已先崩盘话糙理不糙。很多人把精力花在追新模型、追新框架上却忽略了工程层面那些最基础、最要命的稳定性问题。这篇内容就是想把这三个坑掰开揉碎讲清楚它们为什么会发生、怎么快速定位、以及怎么在架构层面提前防住。不管你是刚入门的AI应用开发者还是带团队的技术负责人这些经验都能直接拿去用。2. 第一次翻车模型接口变更引发的解析雪崩2.1 故障现象与第一反应故障发生在一个做内容生成工具的项目上。这个工具的核心逻辑不复杂用户输入一段需求描述后端拼装成prompt发给大模型拿到返回结果后解析出正文、标题、标签三个字段再存库返回给前端。假期第一天上午值班同事发现所有生成请求都返回500错误日志里清一色是KeyError: content。第一反应是模型服务挂了但手动用curl测试接口发现服务是通的返回也有内容。问题出在解析环节。把原始返回打印出来一看原本的response[choices][0][message][content]路径变了新返回里message对象下多了一个reasoning_content字段而content字段在某些情况下会变成空字符串真正的正文被放到了新字段里。这就是典型的接口静默变更——服务商没有提前公告或者公告了但没被注意到返回结构发生了向后不兼容的调整。对于依赖固定JSON路径解析的代码来说这就是致命打击。2.2 为什么这类问题总在假期爆发这里有个很多人忽略的规律上游服务的变更窗口往往选在流量低谷期而长假恰好是很多To B类AI应用的流量低谷。服务商想着趁这时候发版影响最小但对于那些7×24小时运行的应用来说低谷不等于停服。更麻烦的是假期值班的人往往不是最熟悉这块代码的人排查链路会变长。我后来复盘时算了一笔账从故障发生到定位到具体字段变更花了将近两个小时。这两个小时里如果有一个完善的接口契约测试在跑问题在变更发生后的第一次定时检测中就能被发现而不是等真实用户请求撞上来。接口契约测试说白了就是定时用固定输入去调接口断言返回结构的关键字段存在且类型正确。这个成本极低但很多团队就是不做。2.3 防御性解析的实操写法针对这类问题最直接的防御手段是解析层做兼容和降级。不要用硬编码的路径去取字段而是写一个带默认值和类型检查的提取函数。下面是我在实际项目中用的一个Python示例你可以直接参考def extract_content(response): 从模型返回中提取正文内容兼容多种可能的返回结构。 返回 (content, error_msg) 元组。 if not isinstance(response, dict): return None, response is not a dict choices response.get(choices) if not choices or not isinstance(choices, list): return None, choices missing or invalid first choices[0] if not isinstance(first, dict): return None, choice item is not a dict message first.get(message, {}) if not isinstance(message, dict): return None, message is not a dict # 按优先级尝试多个可能的字段 for key in (content, reasoning_content, text): val message.get(key) if isinstance(val, str) and val.strip(): return val.strip(), None return None, no valid content field found这个函数的核心思路是永远不假设返回结构是稳定的。它按优先级尝试多个字段名任何一个拿到非空字符串就返回。同时每一步都做类型检查避免因为某一层变成None而抛异常。配合上层的重试和告警逻辑即使接口变了也能保证服务不直接崩同时留下足够的日志供排查。注意兼容解析只是止血不是治本。真正要做的是建立接口变更的监控机制一旦发现返回结构和基线不一致立即告警。兼容代码是给排查争取时间的不是让你永远不去管接口变化。2.4 接口监控的最小可行方案监控方案不需要多复杂一个定时任务加一个基线快照就够了。具体做法是每天固定时间用一组标准输入调用接口把返回的结构骨架不是具体内容而是字段名和类型的树形结构存下来和前一天做diff。如果结构发生变化发通知。这个方案我用下来能覆盖90%以上的静默变更场景。结构骨架的提取可以用递归函数实现把JSON的每个key和对应的value类型记录下来忽略具体的字符串值。这样即使模型回答的内容每天不同结构骨架也是稳定的只有真正的结构变更才会触发告警。这个思路同样适用于其他第三方API的监控不限于大模型接口。3. 第二次翻车上下文窗口被撑爆的连锁反应3.1 从答非所问到胡言乱语的演变第二个故障发生在智能客服场景。这个项目的对话逻辑是每次用户发消息把历史对话全部拼进prompt一起发给模型。平时咨询量不大单次对话轮数也少跑了大半年没出过问题。长假期间咨询量涨了三倍同时单个用户的对话轮数也变多了因为活动期间用户问题更复杂来回追问的次数明显增加。问题在第二天下午开始显现。用户反馈客服答非所问明明问的是退货流程回答的却是产品参数。再往后模型开始输出一些完全不相关的内容甚至出现重复上一轮回答的情况。值班同事一开始以为是模型服务的问题换了模型还是一样这才意识到是上下文管理出了岔子。3.2 上下文窗口的硬限制与软限制这里需要区分两个概念硬限制是模型本身支持的最大token数超过就直接报错或截断软限制是实际使用中为了保证效果而设定的更小的阈值。很多人只关注硬限制觉得没超就行但实际上接近硬限制时模型的表现会明显下降。原因有两个一是长上下文里噪声信息占比高模型注意力被稀释二是很多模型在长上下文下的推理质量本身就会衰减。我一般建议把软限制设在硬限制的60%到70%。比如模型支持8K token那实际拼装的prompt控制在5K左右。留出的空间一是给模型输出二是给上下文质量留余量。这个比例不是拍脑袋定的是实测出来的超过70%之后回答准确率的下降曲线会明显变陡。3.3 上下文压缩的三种策略对比解决上下文膨胀核心思路是压缩。我试过三种策略各有适用场景下面用表格对比一下策略做法优点缺点适用场景滑动窗口只保留最近N轮对话实现简单延迟低丢失早期关键信息短对话、信息密度低的场景摘要压缩用模型把早期对话总结成一段话保留关键信息压缩率高增加一次模型调用有信息损耗长对话、需要记忆的场景关键信息抽取抽取实体、意图等结构化信息信息最精准可控性强实现复杂需要设计抽取逻辑业务逻辑明确的场景实际项目中我通常把滑动窗口和摘要压缩结合使用最近3到5轮保留原文更早的对话用摘要替代。摘要的prompt要设计好明确要求保留用户身份、已确认的需求、未解决的问题这三类信息。这样既控制了token量又不至于把关键上下文丢掉。3.4 一个可直接复用的上下文管理实现下面这个类是我在多个项目中复用过的上下文管理器核心逻辑是分层保留加自动摘要class ContextManager: def __init__(self, max_tokens4000, recent_rounds4, summarizerNone): self.max_tokens max_tokens self.recent_rounds recent_rounds self.summarizer summarizer # 一个可调用的摘要函数 self.history [] # 完整历史 self.summary # 早期对话摘要 def add_message(self, role, content): self.history.append({role: role, content: content}) self._maybe_compress() def _maybe_compress(self): # 估算当前token数粗略按字符数/2估算中文 total_chars sum(len(m[content]) for m in self.history) estimated_tokens total_chars // 2 len(self.summary) // 2 if estimated_tokens self.max_tokens: return # 需要压缩把最老的几轮对话合并进摘要 keep_count self.recent_rounds * 2 # 每轮包含user和assistant if len(self.history) keep_count: return to_compress self.history[:-keep_count] self.history self.history[-keep_count:] if self.summarizer: old_summary self.summary new_text \n.join( f{m[role]}: {m[content]} for m in to_compress ) self.summary self.summarizer(old_summary, new_text) def build_prompt(self, system_prompt): parts [system_prompt] if self.summary: parts.append(f【历史对话摘要】\n{self.summary}) for m in self.history: parts.append(f{m[role]}: {m[content]}) return \n\n.join(parts)这个实现的关键点在于压缩是增量的每次只把最老的一批对话合并进摘要而不是每次重新摘要全部历史。这样既控制了计算成本又保证了摘要的连续性。summarizer函数可以接一个便宜的小模型来做成本可控。实操心得摘要的prompt里一定要明确要求保留用户明确表达的需求和约束否则模型很容易把关键信息摘掉。我踩过这个坑用户说了三次要发票摘要里没体现后面模型就完全忘了这回事。4. 第三次翻车向量检索的隐性质量塌方4.1 最隐蔽的一次故障第三次故障是最难发现的。这是一个企业知识库问答系统用户提问后系统把问题向量化去向量库里检索最相似的文档片段拼进prompt让模型回答。假期前运营团队做了一次文档批量更新替换了一批旧文档新增了一批新文档。更新流程走的是标准流程文档入库、切分、调用embedding接口生成向量、写入向量库。假期第三天有用户反馈回答的内容像是从别的文档里拼出来的。排查发现检索出来的片段确实和问题相关但相关性不够精准经常差那么一点。更麻烦的是系统的召回率指标看起来正常因为检索确实返回了结果只是结果的质量下降了。这种指标正常但体验下降的问题排查起来最费劲。4.2 新旧向量混用的根因分析根因最后定位到embedding模型在更新过程中被换过。运营团队在批量更新时发现原来的embedding接口调用有点慢就顺手换了一个更快的版本。但向量库里还存着大量用旧模型生成的向量新旧向量在同一个向量空间里做相似度计算结果自然不可靠。这里涉及一个关键概念不同embedding模型生成的向量即使维度相同也不在同一个语义空间里。把它们混在一起检索相当于拿中文词典去查英文单词表面上都是词但对应关系完全错乱。这个问题之所以隐蔽是因为向量检索本身不会报错它只是默默地返回错误的结果。4.3 向量库版本管理的实操规范避免这类问题核心是向量库和embedding模型必须版本绑定。我的做法是在向量库里为每条记录存一个model_version字段检索时只查当前版本的数据。模型升级时走完整的重建流程而不是增量更新。下面是一个简化的版本管理方案EMBEDDING_MODEL_VERSION v2.1 # 当前使用的模型版本 def search(query, top_k5): query_vec embed(query, model_versionEMBEDDING_MODEL_VERSION) # 只检索当前版本的数据 results vector_db.search( vectorquery_vec, top_ktop_k, filter{model_version: EMBEDDING_MODEL_VERSION} ) return results def rebuild_index(documents): 全量重建清空旧版本数据用新模型重新生成 new_version get_next_version() for doc in documents: chunks split_document(doc) for chunk in chunks: vec embed(chunk, model_versionnew_version) vector_db.insert( vectorvec, metadata{ model_version: new_version, doc_id: doc.id, chunk_text: chunk } ) # 重建完成后再切换当前版本 set_current_version(new_version)这个方案的关键是先建后切新版本的向量全部写入完成后再切换EMBEDDING_MODEL_VERSION检索层自动指向新数据。旧版本数据保留一段时间作为回滚备份确认新版本稳定后再清理。这样即使新模型效果不好也能快速回退。4.4 检索质量的监控指标光有版本管理还不够还需要能发现检索质量下降。传统的召回率指标在这里不够用因为它只关心有没有返回结果不关心结果对不对。我补充了两个指标一是检索结果与问题的语义相似度均值低于阈值就告警二是用户追问率如果用户频繁追问你没回答我的问题说明检索质量可能出了问题。语义相似度均值可以用一个独立的轻量模型来算不依赖检索用的embedding模型避免自己评自己的偏差。追问率则需要在前端埋点统计同一会话中用户表达不满的频次。这两个指标结合起来基本能覆盖检索质量的主要异常场景。5. 三次翻车背后的共性工程问题5.1 为什么能跑和稳定跑是两回事把三次故障放在一起看会发现一个共同点它们在低负载、短周期、小数据量的测试环境下都不会暴露。接口变更在测试时可能恰好没赶上上下文膨胀在几轮对话内看不出来向量混用在数据量小时影响也不明显。这就是能跑和稳定跑的差距。很多AI项目的开发节奏是调通接口、跑通流程、上线。中间缺少了一个稳定性验证的环节。这个环节不需要多复杂但必须包含接口契约测试、长对话压力测试、数据版本一致性检查。这三项做下来上面三次故障至少能提前发现两次。5.2 假期值班的排查效率问题假期故障还有一个特殊难点排查链路长。平时出问题喊一声相关同事就能拉群定位。假期里写代码的人可能在老家运维可能在路上沟通成本成倍增加。我经历过一次从发现问题到找到能改代码的人花了40分钟。应对这个问题我的建议是提前准备排查手册。手册里不需要写多详细但至少要包含常见故障现象对应的排查命令、关键日志的位置、各模块负责人的联系方式、回滚操作的具体步骤。这个手册平时就要维护假期前更新一遍。真出事的时候值班的人照着手册走能省下大量沟通时间。5.3 从救火到防火的架构调整三次故障之后我推动做了一轮架构调整核心是把稳定性检查前置到CI流程里。具体包括每次代码合并前跑接口契约测试每次数据更新前跑向量一致性检查每次prompt模板变更前跑长对话回归测试。这些检查单次跑起来也就几分钟但能拦住大部分低级问题。另一个调整是引入降级开关。对于模型调用、向量检索这些外部依赖都加上可配置的降级逻辑。比如模型接口异常时自动切换到备用模型或返回缓存结果向量检索质量低于阈值时降级到关键词检索。降级不追求效果完美只求服务不中断给排查争取时间。6. 常见问题速查与避坑清单6.1 故障排查速查表故障现象可能原因快速排查方法应急处理接口返回解析报错返回结构变更打印原始返回对比基线结构启用兼容解析联系服务商确认模型答非所问上下文超限或噪声过多统计prompt token数检查历史长度启用上下文压缩清理冗余历史检索结果不精准向量版本混用或模型变更检查向量库model_version字段按版本过滤检索重建索引响应变慢上下文过长或检索量过大分段计时定位耗时环节压缩上下文限制检索top_k偶发超时上游服务波动或并发过高查看上游服务状态和自身并发数增加重试和超时控制限流6.2 我踩过的几个具体坑第一个坑是过度信任上游服务的稳定性。早期我总觉得大厂接口不会随便变结果被打脸多次。现在的做法是任何外部依赖都假设它会变解析层一律做兼容关键接口一律加监控。第二个坑是用平均值掩盖问题。上下文长度、检索相似度这些指标看平均值往往没问题但分布的长尾才是故障源头。现在我都会看P95和P99这两个指标才能反映最差情况下的表现。第三个坑是数据更新没有回滚方案。向量库重建时如果新模型效果不好没有旧数据可回退只能硬着头皮往前修。现在我的做法是任何批量数据操作都保留旧版本至少一周确认稳定后再清理。6.3 给不同阶段团队的建议如果你刚起步做AI应用我的建议是先把接口兼容和上下文管理做扎实这两块是最高频的故障源投入产出比最高。向量检索可以先用简单的方案等数据量上来了再优化。如果你已经有了一定规模建议建立稳定性指标体系把接口成功率、上下文超限率、检索质量分这些指标纳入日常监控。同时把故障排查手册维护起来定期演练。如果你是技术负责人建议把稳定性检查纳入发布流程宁可发布慢一点也不要带着已知风险上线。AI应用的故障往往不是完全不能用而是用起来不对劲这种问题对用户信任的伤害更大。最后分享一个我一直在用的小技巧每次长假前做一次全链路压测用模拟的高峰流量跑一遍核心流程重点观察接口解析、上下文长度、检索质量这三个环节。压测不需要多大规模能覆盖日常峰值的1.5倍就行。这个习惯帮我提前发现过好几次潜在问题比出事后再救火划算得多。