1. 为什么我要给自家 LLM 应用“下毒”第一次听到“Chaos Engineering”这个词很多做 AI 应用的朋友会觉得离自己很远——那是运维和 SRE 团队搞分布式系统才玩的东西跟大模型有什么关系我一开始也这么想。直到去年我们上线了一个基于 LLM 的智能客服系统上线第三天就出了事故上游模型服务返回了一堆格式完全错乱的 JSON我们的解析层直接抛异常整个对话链路雪崩用户端看到的是“服务暂时不可用”。事后复盘发现问题根本不在模型本身而在于我们从来没有测试过“当模型返回垃圾时系统会怎样”。这件事让我彻底改变了对 LLM 应用测试的认知。传统的单元测试和集成测试测的是“正常路径”——输入 A 得到 B断言 B 符合预期。但 LLM 应用最大的特点就是不确定性同一个 prompt模型可能返回完全不同的结构同一个工具调用请求模型可能生成不存在的函数名同一个知识库检索可能召回完全不相关的文档。这些“异常”不是 bug而是 LLM 应用的常态。如果你只测正常路径那你的系统就是纸糊的一戳就破。Chaos Engineering 的核心思想就是主动注入故障观察系统行为找到薄弱点然后加固。在 LLM 应用场景下这意味着我们要故意让模型返回畸形 JSON、故意让工具调用超时、故意让检索结果为空、故意让上下文超长溢出然后看系统能不能扛住。听起来有点自虐但这就是“给 AI 系统下毒才能知道它有多抗造”的真正含义。这篇文章适合所有正在构建 LLM 应用的工程师、技术负责人和测试同学。不管你是用 LangChain、LlamaIndex 还是自己手写调用逻辑不管你是做 RAG、Agent 还是纯对话这套混沌工程实践都能直接套用。我会从设计思路、核心故障类型、实操步骤、排查技巧四个维度展开把我在实际项目中踩过的坑和总结的经验全盘托出。2. LLM 应用混沌工程的整体设计思路2.1 为什么传统混沌工程不够用传统混沌工程主要针对基础设施层杀进程、断网络、加延迟、填满磁盘。这些手段对 LLM 应用当然也有用比如模拟模型 API 超时、模拟向量数据库连接断开。但 LLM 应用的故障面远不止这些。它的特殊性在于输出不确定性模型可能返回语法正确但语义荒谬的内容传统断言无法捕获。多阶段链路一个请求可能经过意图识别、检索、重排、生成、工具调用、结果解析等多个环节每个环节都可能出问题。外部依赖复杂模型 API、向量库、工具函数、缓存、消息队列任何一个抖动都会传导。成本敏感故障注入如果失控可能产生大量无效 token 消耗账单爆炸。所以LLM 应用的混沌工程必须分层设计基础设施层、模型交互层、应用逻辑层、数据层每层都有对应的故障注入策略。2.2 分层故障注入模型我习惯把 LLM 应用的混沌工程分成四层从下到上依次是层级故障类型注入手段观察指标基础设施层网络延迟、连接断开、DNS 失败网络代理、iptables、服务网格请求成功率、P99 延迟模型交互层畸形 JSON、空响应、超长输出、错误码Mock 服务、代理拦截、SDK 钩子解析失败率、重试次数应用逻辑层工具调用超时、检索空结果、上下文溢出依赖注入、AOP 切面、配置开关降级触发率、用户感知错误数据层向量库返回脏数据、缓存击穿、文档缺失数据污染脚本、缓存失效召回准确率、幻觉率这个分层模型的好处是你可以根据当前系统的成熟度选择从哪一层开始注入。新系统建议从模型交互层开始因为这是 LLM 应用最独特的故障面成熟系统可以全层覆盖做联合故障演练。2.3 混沌实验的生命周期一个完整的混沌实验不是“注入一下就完事”而是有严格的生命周期定义稳态假设比如“95% 的请求能在 3 秒内返回有效回答”。这是你的基准线。设计实验选择故障类型、注入范围百分比、持续时间、爆炸半径。执行注入在受控环境中运行最好有实时监控和紧急停止开关。观察差异对比稳态假设看哪些指标偏离了。分析根因找到系统薄弱点记录改进项。修复验证修复后重新注入确认系统韧性提升。注意混沌实验一定要有“紧急停止”机制。我见过团队忘了设开关结果故障注入跑了半小时烧了几百万 token账单出来的时候人都傻了。2.4 工具选型不一定要上重型平台很多团队一提到混沌工程就想到 Chaos Mesh、LitmusChaos 这些重型平台。对于 LLM 应用我的建议是先从轻量级方案开始。原因很简单LLM 应用的故障注入很多是应用层的不需要动 Kubernetes 底层。一个 Python 装饰器、一个代理中间件、一个 Mock 服务就能覆盖 80% 的场景。我常用的轻量级工具组合代理拦截mitmproxy 或自定义 HTTP 代理拦截模型 API 请求篡改响应。Mock 服务FastAPI 写一个假的模型服务按规则返回畸形数据。依赖注入在代码里预留FaultInjector接口通过配置开关控制。流量回放把生产环境的真实请求录下来在测试环境回放并注入故障。等这些轻量级手段不够用了再考虑上重型平台。不要为了“看起来专业”而过度工程化。3. 核心故障类型与注入实操3.1 模型输出畸形最常见的“毒”LLM 最擅长的就是“一本正经地胡说八道”其中最常见的就是输出格式不符合预期。你要求它返回 JSON它给你返回 Markdown 代码块包裹的 JSON你要求它返回数组它给你返回一个对象你要求它只输出函数名它给你加了一段解释。注入方法写一个代理层拦截模型响应按概率篡改import random import json class MalformedResponseInjector: def __init__(self, probability0.1): self.probability probability def inject(self, response_text): if random.random() self.probability: return response_text # 故障模式1包裹 Markdown 代码块 if random.random() 0.3: return fjson\n{response_text}\n # 故障模式2截断 if random.random() 0.3: return response_text[:len(response_text)//2] # 故障模式3添加额外解释 if random.random() 0.3: return f好的以下是结果\n{response_text}\n希望对你有帮助 # 故障模式4返回空 return 观察重点你的解析层能不能处理这些情况有没有 try-catch有没有降级策略有没有重试机制重试时 prompt 有没有调整我实测下来大部分团队的系统在第一次注入时都会挂。最常见的问题是解析层直接json.loads()没有异常处理一挂就整个请求失败。正确的做法是解析失败时先尝试提取 JSON 子串再尝试用 LLM 做二次修复最后才降级到默认回复。3.2 工具调用幻觉Agent 的致命伤如果你在做 Agent 应用工具调用是核心。但模型经常会调用不存在的工具、传错参数、或者该调用工具的时候不调用。这些幻觉在正常测试中很难复现但混沌工程可以主动制造。注入方法在工具注册层做手脚故意让某些工具“消失”或“报错”class ToolFaultInjector: def __init__(self, config): self.config config def wrap_tool(self, tool_func, tool_name): def wrapper(*args, **kwargs): # 故障模式1工具不存在 if self.config.should_remove(tool_name): raise ToolNotFoundError(fTool {tool_name} not found) # 故障模式2工具超时 if self.config.should_timeout(tool_name): time.sleep(30) raise TimeoutError(fTool {tool_name} timed out) # 故障模式3返回脏数据 if self.config.should_corrupt(tool_name): return {error: internal error, data: None} return tool_func(*args, **kwargs) return wrapper观察重点Agent 在工具调用失败后能不能优雅地告诉用户“我暂时无法完成这个操作”还是会陷入无限重试循环还是会编造一个假的结果我见过最离谱的案例是Agent 在工具超时后自己编了一个“查询结果”返回给用户用户完全无法分辨真假。3.3 检索空结果与脏数据RAG 的隐形杀手RAG 应用最怕的就是检索环节出问题。向量库可能返回空结果可能返回完全不相关的文档可能返回过期的文档。这些在正常测试中很难覆盖因为你的测试集通常是“干净”的。注入方法在检索层加一个污染器class RetrievalFaultInjector: def __init__(self, vector_store, probability0.15): self.vector_store vector_store self.probability probability def search(self, query, top_k5): if random.random() self.probability: mode random.choice([empty, irrelevant, stale]) if mode empty: return [] if mode irrelevant: return self.vector_store.random_docs(top_k) if mode stale: return self.vector_store.old_docs(top_k) return self.vector_store.search(query, top_k)观察重点检索为空时模型会不会硬答会不会说“根据我的知识”会不会编造引用检索到不相关文档时模型会不会被带偏这些都是 RAG 系统的核心韧性指标。3.4 上下文溢出与截断长对话的定时炸弹LLM 有上下文窗口限制长对话或多轮工具调用很容易超出。超出后有的框架直接报错有的框架静默截断有的框架丢弃中间消息。每种行为都可能导致不同的问题。注入方法在消息组装层注入超长内容class ContextOverflowInjector: def __init__(self, max_tokens4096): self.max_tokens max_tokens def inject(self, messages): if random.random() 0.2: # 注入一段超长无关内容 long_text 这是一段无关的填充文本。 * 500 messages.insert(1, {role: user, content: long_text}) return messages观察重点系统是报错还是截断截断策略是什么截断后模型还能正确回答吗有没有 token 计数和预警机制3.5 模型 API 故障最容易被忽视的一层很多人觉得模型 API 是云服务商的事自己不用管。但现实是API 会限流、会超时、会返回 5xx、会返回格式错误的响应。你的系统必须能扛住这些。注入方法用代理拦截请求按规则返回错误class APIErrorInjector: def __init__(self, error_rate0.05): self.error_rate error_rate def should_fail(self): return random.random() self.error_rate def get_error_response(self): error_type random.choice([429, 500, 503, timeout]) if error_type 429: return {status: 429, body: {error: rate limit exceeded}} if error_type 500: return {status: 500, body: {error: internal server error}} if error_type 503: return {status: 503, body: {error: service unavailable}} return {status: None, body: None} # 模拟超时观察重点有没有重试重试策略是固定间隔还是指数退避有没有熔断熔断后降级到什么有没有告警4. 完整实操流程从零搭建混沌实验4.1 环境准备与基线采集在注入故障之前你必须先知道“正常”是什么样。这一步很多人跳过结果注入后根本不知道哪些指标异常了。第一步定义稳态指标。对于 LLM 应用我建议至少监控以下指标指标说明正常范围示例请求成功率返回有效响应的比例 99%P95 延迟95% 请求的完成时间 3s解析失败率JSON/结构化解析失败比例 0.1%工具调用成功率工具调用返回有效结果比例 98%降级触发率触发降级策略的比例 1%用户感知错误率用户看到错误提示的比例 0.5%Token 消耗/请求平均每次请求的 token 数稳定波动第二步采集基线。在无故障注入的情况下跑至少 1000 个真实请求记录上述指标的分布。最好用生产环境的真实流量回放而不是构造的测试用例。第三步搭建监控看板。Grafana Prometheus 是标配。每个指标都要有实时曲线和告警阈值。4.2 注入执行与实时观察基线有了就可以开始注入了。我的建议是从低概率、小范围开始逐步加大。第一轮单点注入概率 1%。只注入一种故障比如畸形 JSON概率 1%。观察 10 分钟看指标有没有偏离。第二轮单点注入概率 10%。加大概率观察系统行为变化。这时候应该能看到重试、降级等机制被触发。第三轮多点注入概率 5%。同时注入 2-3 种故障模拟真实世界的“祸不单行”。第四轮全链路注入概率 20%。所有故障类型同时注入概率拉高看系统会不会雪崩。每一轮都要记录哪些指标偏离了基线系统触发了哪些降级/重试/熔断用户侧感知到什么错误有没有产生意外成本实操心得注入时一定要盯着 token 消耗曲线。我有一次做全链路注入重试逻辑没设上限结果 10 分钟烧了 200 万 token。后来我给所有重试都加了“最大 3 次”和“总 token 预算”双重限制。4.3 数据收集与根因分析注入结束后收集所有日志、指标、链路追踪数据做根因分析。我常用的分析框架是“5 Why”为什么请求失败了因为解析 JSON 抛异常了。为什么抛异常没被捕获因为解析层没有 try-catch。为什么没有 try-catch因为开发时假设模型一定返回合法 JSON。为什么会有这个假设因为测试用例都是正常响应。为什么测试用例都是正常响应因为没有混沌测试。找到根因后按优先级修复。我的经验是优先修复“导致雪崩”的问题而不是“导致单个请求失败”的问题。前者影响面大后者可以容忍。4.4 修复验证与回归修复后重新跑一遍混沌实验确认系统韧性提升。然后把这套混沌实验加入 CI/CD 流水线每次发版前自动跑一遍。这样能防止新代码引入新的脆弱点。我现在的做法是在预发环境部署一个“混沌模式”通过环境变量控制。每次发版前自动触发一轮 10 分钟的混沌实验通过则允许上线不通过则阻断。5. 常见问题与排查技巧实录5.1 注入后系统直接雪崩怎么办这是最常见的情况。第一次注入就雪崩说明系统完全没有容错设计。这时候不要慌按以下步骤排查看日志找到第一个抛异常的地方那就是最薄弱的环节。看链路用 Jaeger 或 SkyWalking 看请求在哪个环节断掉。看降级有没有降级策略降级策略有没有生效看重试重试有没有上限重试有没有放大故障修复顺序先加 try-catch 防止雪崩再加降级策略保证可用性最后加重试和熔断提升成功率。5.2 重试导致成本爆炸怎么控制重试是双刃剑。不重试成功率低重试成本高。我的控制策略是三层限制次数限制最多重试 3 次。预算限制单个请求总 token 消耗不超过 10000。时间限制总耗时不超过 10 秒。任何一层触发立即停止重试走降级。5.3 模型输出畸形怎么优雅修复不要直接抛异常。我常用的修复链是提取用正则从文本中提取 JSON 子串。修复用 json_repair 库尝试修复常见语法错误。二次调用把畸形输出发给模型让它修复成合法 JSON。降级以上都失败返回默认值或友好提示。这个修复链能覆盖 95% 以上的畸形输出。5.4 检索为空时模型硬答怎么办这是 RAG 系统的经典问题。解决方案是在 prompt 里加约束如果检索结果为空你必须回答“抱歉我没有找到相关信息”不得使用你自己的知识回答。同时在代码层加一个检查如果检索结果为空直接返回固定话术不调用模型。这样既省钱又避免幻觉。5.5 混沌实验影响生产环境怎么隔离绝对不要在生成环境直接注入。我的做法是预发环境与生产环境配置一致专门用于混沌实验。流量回放把生产流量录下来在预发环境回放。影子流量生产请求复制一份到预发环境不影响真实用户。紧急开关任何注入都可以一键停止。5.6 常见问题速查表问题现象可能原因排查方向修复建议请求全部失败解析层无异常处理看日志第一个异常加 try-catch延迟飙升重试无上限看重试次数加次数和预算限制成本暴涨重试放大看 token 曲线加预算熔断用户看到幻觉检索为空硬答看检索日志加空结果约束工具调用死循环无最大轮次限制看 Agent 轮次加 max_iterations上下文溢出报错无 token 计数看消息长度加截断和预警6. 我在实际项目中的几点体会这套混沌工程实践在我们团队跑了半年多从最初的“一注入就雪崩”到现在“20% 故障注入下系统依然可用”效果非常明显。有几个体会特别深第一混沌工程不是测试是设计。你在设计系统的时候就要考虑“如果这里出问题会怎样”。等你写完代码再补容错成本高十倍。第二故障注入要常态化。不要搞一次就完事要加入 CI/CD每次发版都跑。因为新代码随时可能引入新的脆弱点。第三监控比注入更重要。没有监控你注入了也不知道发生了什么。先把指标、日志、链路追踪做扎实再搞混沌工程。第四从小处着手。不要一上来就搞全链路注入先从单个函数的畸形输入开始。逐步扩大爆炸半径逐步提升系统韧性。最后分享一个实用技巧我写了一个FaultInjector类通过环境变量CHAOS_LEVEL控制注入强度0 表示关闭1-5 表示不同级别。这样一套代码开发、测试、预发、生产都能用只是级别不同。生产环境永远设为 0预发环境设为 3测试环境设为 5。简单、可控、可复现。