LLM管线两个隐藏Bug：数据串扰与输出截断的复盘与防护

先说结论这两个 Bug 都不在模型侧而在管线侧——而且最讽刺的是它们藏身的两段代码恰好是单测覆盖率报表上最干净的两段。我做的一条客服对话日志结构化抽取管线单测全绿、代码评审通过、覆盖率报表显示 98%上线第三天业务方就甩过来一批“串台”数据A 对话的订单号出现在了 B 对话的抽取结果里一周之后又出现大量 JSONDecodeError任务重试队列直接被打爆。这两个问题单元测试一个都测不出来但它们不是玄学触发条件非常具体修复路径也完全可以沉淀成自动化防线。这篇就是完整复盘。1. 单元测试为什么放走了这两个运行时问题在拆两个具体 Bug 之前我想先聊聊一个更扎心的问题为什么单测全绿线上还是会出这种事Unit test 这套东西设计初衷是验证“一个函数在给定输入下是否产生期望输出”。这句话成立的前提有三个输入足够可控、执行环境足够简单、依赖可以被替换得足够干净。LLM 数据管线恰好把这三个前提全破坏了。1.1 单测验证的是“理想输入下的逻辑”不是“真实负载下的状态”大多数 LLM 应用团队写单测时测的都是下面这类逻辑给一个格式化干净的 prompt 模板喂一个精心挑选的小样本断言 LLM 输出被正确解析成了 dict字段齐全、类型正确。这种测试当然要写但它只证明了一件事在理想输入下代码逻辑是对的。真实运行时是另一套环境维度单元测试环境真实运行环境输入分布手工精选样例格式干净海量真实数据脏、乱、有截断、有缺失执行方式串行、单线程线程池、多 worker、批量并发依赖mock 或 stub真实模型服务、真实数据库、共享缓存资源边界假定无限上下文窗口有限、max_tokens 有限、超时有限状态残留每次调用都是全新的共享对象、全局缓存、模块级状态看到这张对照表你就能明白单测默认世界是“干净、串行、无限”的而线上世界是“脏、并发、有限”的。绝大多数 LLM 管线事故都是在这两个维度上反生出来的。1.2 两个问题的共同元凶状态与规模的断层这次复盘的两个缺陷正好各占一个维度缺陷一是状态维度模块级共享上下文对象被线程池并发读写产生了批次间数据串扰缺陷二是资源维度max_tokens 写死输入上下文变长后模型输出被截断成半截 JSON。两个缺陷都发生在“单测覆盖率报表里最干净”的两段代码上一段是 prompt 组装函数一段是输出解析函数。为什么会这样因为这些函数在单测里被当作纯函数验证——喂干净输入、断言干净输出。但它们在管线里其实是有状态的、受资源约束的过程环节。单测通过只能说明输入输出契约在理想情况下成立测不出共享状态被并发破坏测不出资源耗尽导致的输出截断。所以先别急着怪“单测写少了”。更准确的说法是单测的验证模型和 LLM 管线的故障模型本来就错位了。2. 缺陷一共享上下文导致的批次串扰——一张脏样本揪出的“串台”Bug先看第一个缺陷的完整经过。2.1 事故现场A 对话的订单号跑进了 B 对话的结果这条管线做的是客服对话摘要抽取输入是一段客服与用户的对话文本输出是一个 JSON包含客户诉求、订单号、情绪标签、处理建议等字段。版本上线第三天业务方反馈说“有一部分抽取结果不太对但不能说全部错了因为字段格式都合法客户名也是真实人名只是和原始对话对不上。”他们随手甩过来两个例子样本 A原始对话用户咨询订单 202406120001 的物流状态 抽取结果{ order_id: 202406120001, intent: 查物流, sentiment: negative } 样本 B原始对话用户投诉商品外观破损未提及任何订单号 抽取结果{ order_id: 202406120001, intent: 查物流, sentiment: negative }样本 B 的原始对话里根本没有订单号结果里却出现了样本 A 的订单号连 intent 和 sentiment 都一模一样。这显然不是模型幻觉幻觉不可能完整复制另一条样本的字段组合。这是典型的“串台”——A 的上下文污染了 B 的执行环境。2.2 排查链路从脏样本到共享对象的完整追踪过程一开始我按老思路走先看是不是 prompt 构造时数据切分出了问题。检查了清洗和分段逻辑发现两条样本的文本本身没有问题没有混入对方内容。接着怀疑模型侧参数比如 temperature 太高导致随机性但回看了重试日志发现“串台”样本总是成对出现并且时间戳几乎重合——这就不像是随机采样的问题更像是并发执行时的资源竞争。于是我在 prompt 组装函数入口和出口各加了一行日志把当前线程 ID、样本 ID、上下文对象的 hash 值打出来def assemble_prompt(conv, ctx): log.debug(enter: thread%s sample%s ctx_hash%s, threading.get_ident(), conv[id], hash(ctx)) ...跑了一批 1000 条样本后日志暴露了问题同一个 hash 值在不同线程、不同样本之间反复出现。也就是说所有线程拿到的上下文对象其实是同一个实例。确认是共享对象之后再往代码深处一看根因就浮出来了class BatchExtractor: _cache {} # 类级共享变量所有线程可见、可写 def extract(self, batch): pool ThreadPoolExecutor(16) return list(pool.map(self._run_one, batch)) def _run_one(self, conv): ctx self._cache # 拿到的永远是同一个 dict ctx[current_order_id] extract_order_id(conv) prompt build_prompt(conv, ctx) raw llm_completion(prompt) return json.loads(raw)问题链路很清晰模块级_cache是共享的_run_one执行时读它、写它。线程 A 写入了样本 A 的订单号线程 B 恰好在这个窗口期读取上下文拼 prompt就把样本 A 的数据拼进了样本 B 的 prompt。模型拿到的是被污染后的 prompt自然输出串台结果。这跟我之前踩过的很多 Python 并发坑类似list、dict是线程不安全的两个线程一边读一边写轻则数据错乱重则直接抛RuntimeError。但 LLM 管线里这个坑更隐蔽因为模型不会告诉你“你的 prompt 被并发写坏了”它只会老老实实基于脏 prompt 输出一个格式合法的 JSON。2.3 修复方案为每个任务建立独立的上下文实例修复本身不复杂核心就一条消除共享可变状态让每个任务持有独立的上下文实例。def process_one(conv): ctx ContextBuilder(configservice_config).build() # 每次新建 ctx[current_order_id] extract_order_id(conv) prompt build_prompt(conv, ctx) raw llm_completion(prompt) return parse_and_validate(raw)同时我顺手把BatchExtractor里的类变量改成了实例局部变量线程池入口不再复用任何长生命周期对象。改完之后做了并发回归用 1000 条真实样本、16 线程、连续跑 10 轮逐一比对抽取结果里的订单号是否存在于对应样本的原始对话中错位率从 3.2% 降到了 0。2.4 为什么这个 Bug 在单测里活不过一行断言却跑了一天这是最让我警醒的地方。这个类当时是有单测的而且测的还不少单条样本的 prompt 格式断言、输出 JSON 结构断言、字段类型断言全都通过了。因为单测是串行调用一个方法的每次调用之间_cache虽然共享但上一次的写入立刻被下一次的写入覆盖不会出现并发交错。单测样本之间互相对照也发现不了问题——每个断言都是独立执行的根本没有“两个线程并发写同一份上下文”这种时序。更讽刺的是如果当时单测里用了 pytest 的 fixture 去重置_cache反而会让问题更难暴露——因为每次重置都掩盖了“类变量跨样本残留”这个事实。后来我才意识到这类 Bug 的检测关键不是“断言输出对不对”而是“在并发执行下两个任务的中间状态是否互相干扰”。这已经超出了传统单元测试的能力边界。3. 缺陷二写死的 max_tokens 与半截 JSON——长上下文的“交卷截断”第一个缺陷修完之后我以为管线安全了结果一周后第二颗雷炸了。3.1 事故现场JSONDecodeError 在功能开关打开后集中爆发运营团队在管线上线一周后打开了一个“知识库检索增强”开关系统会先检索与当前对话相关的知识库片段拼进 prompt 再送给模型。功能开关一开监控面板上的parse_failure_rate半小时内从 0.2% 涨到了 9%错误日志里全是同一种异常2024-06-12 15:31:42.182 ERROR JSONDecodeError: Expecting property name enclosed in double quotes: line 7 column 1 (char 892) 2024-06-12 15:31:42.305 ERROR JSONDecodeError: Expecting , delimiter: line 8 column 9 (char 1023)把出错样本的原始模型输出捞出来一看每一段都是明显的“半截 JSON”——字符串在某个字段中间被硬生生切断了缺右括号、缺字段值、甚至缺引号。模型不是不会写 JSON是写到一半被迫交卷了。3.2 定位过程截断率与输入长度的关系浮出水面我先检查了是不是模型服务端出了问题但同期其他管线的错误率没有变化说明模型服务本身是稳定的。于是我把喂给模型的输入 token 长度按分桶统计跟截断率放在一起看输入 token 数区间样本数截断率800 - 150032000.3%1500 - 250021001.7%2500 - 35009004.6%3500 - 45004008.2%趋势非常明显输入越长截断越严重。打开检索增强开关后知识库片段平均给每条 prompt 增加了 2000~3000 token直接把输出空间挤没了。根因在调用代码里写得很直白response llm_completion( promptprompt, modelgpt-4o-mini, max_tokens200, # 上线初期拍脑袋写死的 temperature0.2, )max_tokens200是项目初期输入很短时装上去的当初单测里所有样本输出 JSON 都不超过 150 token预留 200 绰绰有余。但 prompt 里多出来两千多 token 的检索内容后模型需要在有限的 200 token 预算内完成输出——它当然优先写前面几个字段写到一半就把预算耗尽了于是产出半截 JSON。3.3 修复方案动态 Token 预留、JSON 容错修复器与字段校验修这个问题的第一步是把写死的max_tokens改成动态计算def alloc_output_tokens(input_token_count, model_ctx8192, task_max512, reserve256): return max(128, min(model_ctx - input_token_count - reserve, task_max))逻辑很简单模型的最大上下文减去输入占用再减去一个安全余量得到可用输出空间如果这个空间大于任务需要的最大值task_max就按task_max分配防止单个请求吃太多资源。计算完以后还要在调用前把输入 token 数至少要预算一次——如果输入已经超过模型上下文窗口那就不该继续调模型而是直接走“上下文超限”的降级通道。第二步是给解析层加 JSON 容错修复器。因为即使动态计算了 max_tokens极端情况下仍可能截断解析函数必须能识别出“输出不完整”并做出显式处理而不是抛一个光秃秃的JSONDecodeError:def parse_llm_json(raw: str) - dict: raw raw.strip() try: return json.loads(raw) except json.JSONDecodeError as e: fixed try_repair_json(raw) # 补全缺失的右括号/引号 if fixed is not None: return fixed raise OutputTruncatedError( originalraw, positione.pos, hintmodel_output_truncated_or_malformed )第三步是写入前的字段级校验。解析出一个 dict 不意味着它是完整的抽查输出发现有些截断 JSON 能被容错修复器勉强补成一个“语法合法”的 dict但尾部字段其实是空的。所以入库前必须做 required fields 检查比如订单号、客户诉求、处理建议这几个核心字段任一缺失就拒绝入库走重试或人工复核队列。3.4 完美 mock 输出掩盖了解析函数的“畸形分支”零覆盖回头复盘这个缺陷单测的锅在于所有 mock 模型输出都是“完整且合法”的 JSON。解析函数的正常分支被反复执行行覆盖率高达 100%但“JSON 被截断”“字段缺失”“多一个逗号”这些畸形分支一行都没跑到。这也是 LLM 管线测试和传统后端测试最大的区别传统接口的 mock 响应是稳定的输出格式由契约保证而 LLM 的输出在长尾场景下就是会产生截断、重复、幻觉字段。如果测试样本里永远只有“理想输出”那么解析函数里的防御逻辑就只是在代码评审时感动自己线上一次都没执行过。当时我还犯了一个错误把max_tokens200写在了配置文件里但配置文件没有对应的注释和告警机制。后来团队定了一条规矩凡是涉及上下文长度的常量都必须配套一个运行时指标监控比如“当前输入 token 数 / 模型上下文窗口的占比”。当占比超过 60% 时就自动报警而不是等截断率涨到 8% 才被业务发现。4. 把运行时风险搬进自动化防线最小复现用例、哨兵指标与防御式校验修完这两个缺陷我做的一件事是把它们沉淀成可执行的测试用例和监控规则避免下个版本重蹈覆辙。这一章全是可直接抄走的实操干货。4.1 给测试换上“带毒样本”两个最小复现用例怎么写第一个缺陷的最小复现核心是并发隔离回归测试。不需要真的调 LLM只需要验证多个任务并发执行时每个任务拿到的上下文互不影响。def test_concurrent_tasks_do_not_share_context(): extractor BatchExtractor() batch [gen_sample(i) for i in range(200)] # 用和线上一致的并发度去跑 results extractor.extract(batch, max_workers16) # 校验每个结果里的 order_id 必须存在于该样本自己的原文里 for sample, result in zip(batch, results): assert result[order_id] in sample[raw_text]这个测试的关键在于不是跑一次就完而是连续跑多轮。并发问题往往有概率性一轮跑不出来不代表没问题。我会在 CI 里让它循环跑 10 轮虽然增加了 20 秒执行时间但换来的是对共享状态问题的持续压制。第二个缺陷的最小复现写起来更简单但容易被忽略——直接造一段“被截断到一半的 JSON”灌给解析函数def test_parse_llm_json_handles_truncated_output(): raw {order_id: 202406120001, intent: 查物流, sentiment: neg with pytest.raises(OutputTruncatedError): parse_llm_json(raw) def test_parse_llm_json_rejects_missing_required_field(): raw {order_id: 202406120001} # 缺 intent、sentiment assert validate_required_fields(raw, [order_id, intent, sentiment]) is False这类测试的价值不是“证明解析函数能处理畸形输入”而是防止未来某个新同事把解析函数改成静默吞错。见过太多次了为了快速解决报错在except里加一句return {}结果所有业务字段静默丢失下游报表显示空白却没有任何异常报警。带毒样本测试就是用来卡住这种“看似省事实则埋雷”的改动的。4.2 哨兵指标让脏数据在发生时报警而非月底复盘测试再全也不可能覆盖线上所有长尾场景。所以我给管线加了一层运行时防线核心指标就五个parse_failure_rate输出解析失败率超过 1% 报警truncation_rate输出截断率超过 2% 报警field_missing_rate入库前必填字段缺失率超过 0.5% 报警cross_sample_correlation相邻样本输出的字段相似度超过阈值报警这是针对“串台”缺陷的监控防止输出出现批量复制同一个值的情况input_token_ratio输入 token 数占模型上下文窗口的比率超过 60% 预警、超过 75% 报警。前三个指标大家可能都在做后两个是这次事故沉淀出来的。特别是cross_sample_correlation实现不复杂在每个样本输出写入前把关键字段订单号、客户名、诉求摘要做 hash统计同一批次内不同样本间 hash 完全相同的比例。如果一批 100 条样本里有超过 3 条的订单号 hash 完全相同而它们的原始对话里并没有相同订单号基本可以断定发生了上下文串扰。这个指标对“脏数据批量污染”特别灵敏。4.3 防御式校验不信任任何一层的输出最后一道防线是给管线的“写库”动作加一个强制校验。做法是引入一个轻量的输出 schema 模型每个样本在入库前先过一遍from pydantic import BaseModel, Field class ExtractionResult(BaseModel): order_id: str Field(min_length6, patternr^\d{6,}$) intent: str sentiment: Literal[positive, neutral, negative] processing_score: float Field(ge0.0, le1.0) # 入库前 result ExtractionResult(**parsed_data)这里有一个容易被忽略的细节校验不通过时一定要有明确的失败出口——要么重试带上原始输入和 prompt要么进入人工复核队列要么丢弃并记录完整样本。最怕的就是“except 之后假装无事发生”。我曾经见过一个团队为了不让批量任务中断把解析异常全部吞掉、输出一个空表结果运营看了一个月的空白报表还以为“最近没有新数据”。5. 两类 Bug 背后的共同根因LLM 管线的“测试断层”把两个缺陷放在一起复盘我能看到同一条主线单元测试验证的是函数逻辑而 LLM 管线是一个有状态、有并发、有资源上限的系统。这两者的错位就是“测试断层”。5.1 单测验证的是函数逻辑管线故障出在系统状态传统单元测试的理想状态是“无副作用、无状态残留”一个函数进去一个结果出来测完就完事。但 LLM 管线是链条式的清洗 → 切分 → prompt 组装 → 模型调用 → 解析 → 校验 → 入库。任何一个环节的共享状态、残留缓存、资源耗尽都会传导到下游。缺陷一的_cache串扰单测里你把它当“输入”测但它在真实环境下是被所有线程共享的“系统状态”。缺陷二的max_tokens200单测里它是常量的一部分但在运行时它是“资源分配策略”。一句话单测只验证了每个环节的输入输出契约没有验证环节之间的状态隔离和资源分配。5.2 LLM 的概率输出在测试里被 mock 成了一台打印机这可能是 LLM 管线测试和传统系统测试最大的分水岭。传统后端测试里你 mock 一个 HTTP 接口的响应它返回什么就是什么因为接口契约是稳定的。但 LLM 不是契约稳定的接口它在不同 prompt 长度、不同解码参数、不同上下文内容下输出分布会剧烈变化。你在单测里 mock 出来的“完美 JSON”只是一万种可能输出中的一种而且是概率最低的那一种。所以要专门给测试集加“扰动样本”半截 JSON、多余逗号、字段缺失、重复字段、幻觉实体输出里出现了输入里没有的电话号码、订单号等。这些样本看起来“脏”但它们是线上真实会出现的形态。把这类样本纳入回归集解析函数和校验逻辑的健壮性才是真实可验证的。5.3 这次排错沉淀下来的几条具体经验如果只让我记三条我会记这三条第一LLM 管线的单测通过率不能作为发布依据。真正能拦住线上事故的是带并发压力的集成测试加上带毒样本的回归测试。我们内部后来把发布前检查从“单测通过”改成了“单测通过 1000 条真实样本回放 16 线程并发隔离测试”发现问题的时间提前了很多。第二排查数据质量问题时不要只盯着“输出长什么样”要把输出和输入放在一起做字段归属校验。这次“串台”数据如果只看每一个样本的抽取结果它们都是合法 JSON字段格式全对只有把结果里的订单号拿回原始对话里比对才发现是别的样本的。第三每个线上事故样本都值得脱敏后加入回归集。把这次半截 JSON 的真实样本去掉客户隐私信息之后直接塞进解析函数的测试数据里以后任何改动导致解析层回退CI 都会立刻报警。我个人做完这次复盘后最深的体会是LLM 应用开发里测试的复杂度不在“怎么断言模型的输出”而在“怎么保证管线在真实约束下的状态安全”。单测覆盖率 98% 并不代表管线抗造它只代表你在干净的假设下把每条分支走了一遍。真正的可靠性是在脏数据、并发、资源上限这些不那么体面的前提下系统依然能把它该处理的数据处理完、该报警的事报出来。这也是我写下这篇实录的原因——希望后来者少踩一次一模一样的坑。