LLM系统中的数据质量税：劣质输入为何带来截然不同的代价

当数据变得嘈杂时，你的梯度提升模型会礼貌地退化。准确率下降，精确率下降，监控告警触发，值班工程师知道该去哪里排查。LLM则不会这样。向LLM输入降级、陈旧或格式错误的数据，它产生的输出流畅、自信、听起来权威——但部分甚至完全是错的——而下游消费该输出的系统根本无从分辨。

这就是数据质量税：当劣质数据进入LLM管道时，你付出的复利代价——不是以低置信度分数的形式，而是以披着事实语法的幻觉来呈现。

行业数据触目惊心，但对于任何在规模上运营过这些系统的人来说并不意外。60%的企业将数据质量差列为AI项目失败的首要原因。针对主要前沿模型的研究发现，幻觉率平均为30%，部分模型每次错误响应会产生四个或更多幻觉。当数据质量问题污染检索管道时，生产准确率可能从95%跌至71%，而没有任何单一故障大到足以触发告警。

传统ML团队知道如何处理数据质量问题。LLM时代需要从头重新学习这些经验，因为故障模式在类型上截然不同。

为何LLM失败更响而传统ML失败更轻

关键洞察是，经典监督模型经过校准，会表达不确定性。逻辑回归输出概率，梯度提升树给你叶子节点覆盖率。当数据质量下降时，模型输出向决策边界偏移——置信度以可度量、可预测的方式降低。

LLM生成自然语言。语言没有内置的置信度分数。当你要求模型总结一份损坏的文档时，它不会说"我对这份摘要置信度很低"。它产生一段读起来就像完全理解了文档的段落。

这个研究术语叫做过度自信幻觉：模型将试探性或有归因的陈述转化为陈述性事实。在一项研究中，模型将一位参议员的观点——明确以此形式呈现——改写成了关于安全风险的无争议陈述。输入因框架而损坏，输出因放大而损坏。研究中观察到的幻觉里，50%被分类为中等严重程度，14%被分类为"令人担忧"，即模型产生了看似有真实证据支撑的事实性错误陈述。

这对系统架构很重要，因为LLM的输出会流向某处。当下游组件收到一个自信错误的事实时，它没有信号来拒绝它。它继续处理，错误传播。

向量库并非你想象中那么中立

RAG架构引入了第二个大多数团队没有足够重视的故障面：向量索引。工程师们倾向于将向量库视为哑索引——在模型进行艰难工作之前获取相关文档的方式。但检索到什么的质量完全由索引了什么的质量决定，而这种质量会随时间悄然降级。

嵌入漂移是最普遍的问题，它以三种方式发生：

模型版本不匹配。 你的文档用嵌入模型v1建了索引。在某个时刻，你的查询路径开始使用v2。两个模型对语义的编码方式不同。查询和文档之间的余弦相似度现在跨越不兼容的向量空间计算，检索质量下降——但没有任何错误触发，因为数学仍然正常运行。

语料库陈旧。 文档不断添加但旧的嵌入不更新。随着领域演进，新术语和变化的概念进入语料库，而原始嵌入仍锚定在过时的语言上。对使用当前术语的查询，检索召回率下降。

分块不一致。 团队随时间更改分块大小、重叠参数或解析逻辑。在不同策略下创建的分块以不同的语义密度编码信息。索引在方式上变得异构，导致不可预测的检索行为。

数字是具体的。稳定的嵌入系统在等效分块之间随时间的余弦距离方差为0.0001–0.005。漂移的系统超过0.05。邻居持久性——同一规范查询是否返回相同的top-k结果——应保持在85%以上。当它降至40%以下时，检索已经有意义地退化。团队通常在用户抱怨答案明显变差之后才发现这一点。

一项基准测试显示，朴素的固定大小分块将忠实度分数从0.79–0.82降至0.47–0.51。这不是小幅下降。这意味着你的RAG系统在使用适当文档结构的情况下，只有一半的声明能得到事实支撑。模型不知道这一点，它填补了空白。

错误如何向下游传播

产生错误答案的单阶段LLM系统只是令人恼火。第一阶段为第二阶段提供输入的多阶段管道，才是让你在输出层面看到莫名其妙的复合故障的原因。

故障模式通常是：低质量或格式错误的输入→部分或错误的提取→该提取被嵌入或存储→后续检索返回损坏的表示→生成在损坏的上下文基础上产生幻觉内容→下游消费者将其视为事实。

使这一问题特别难调试的是，每个单独阶段都可能看起来健康。提取阶段产生有效的JSON。嵌入运行没有错误。检索返回合理的候选。生成产生语法正确、流畅的文本。只有端到端评估才能揭示损坏——而大多数团队没有端到端评估。

RAG特有的版本：在摄取过程中被剥离权限元数据的文档悄然绕过访问控制。同一文档的多个版本共存于索引中，检索根据哪个版本浮出水面而返回矛盾信息。一项投毒研究证明了通过嵌入注入恶意内容的80%成功率，攻击根本不需要访问查询路径——只需要文档语料库。模型自信地将注入内容与合法来源综合在一起。

真正能发现问题的审计模式

好消息是，LLM系统的数据质量监控大量借鉴了经过验证的学科——数据库可靠性、信息检索和传统MLOps。这些模式存在；大多数团队只是还没有在这里应用它们。

金丝雀文档。 将具有特定、可验证特征的已知文档注入你的语料库。定期对它们运行规范查询。如果检索返回了错误的文档，或生成对已知输入产生了错误答案，你就有信号表明管道中某处已经退化。维护一组稳定的30–50个金丝雀问题，覆盖你用例的主要语义簇，目标是Recall@K ≥ 90%。

嵌入漂移监控。 为你的向量索引添加监控，定期运行三项检查：

• 比较稳定参考集和新添加文档之间的余弦距离分布。显著偏移表明模型或预处理变更破坏了兼容性。
• 测量一小组规范查询的邻居持久性。每周运行相同查询，检查top-5结果中有多少比例保持稳定。从90%到60%持久性的下降是有意义的信号。
• 追踪向量范数方差。异常值表明文档使用了不同的归一化逻辑处理。

这些检查可以作为轻量级作业在你现有的索引上运行——不需要单独的基础设施。

带重排序的检索抽查。 将交叉编码器重排序应用于检索结果样本，充当质量门控。双编码器相似度分数和交叉编码器相关性分数显著分歧的地方，就是检索系统排名错误的文档。在查询类别中持续的分歧表明该语义区域的索引已退化。

管道级数据血缘。 追踪索引中每个文档的来源：何时摄取、使用了哪个版本的嵌入模型、应用了哪种分块配置，以及最后一次刷新的时间。当检索质量退化时，血缘数据立即告诉你问题是语料库陈旧、模型漂移还是配置变更。没有血缘，你是在盲目调试。

新鲜度TTL。 并非每种文档类型都有相同的陈旧容忍度。静态参考文档可能几个月内是安全的。定价数据或政策文档可能在几天内就失效。根据文档类别而非单一全局计划，实施特定来源的TTL来触发重新摄取。

高风险领域的放大问题

数据质量故障的后果并非均匀分布。最严重的放大发生在损坏的输入到达部署在用户基线信任度高的领域的模型时。

一项医疗错误信息研究证明，仅用有害内容替换0.001%的训练token就足以产生更有可能向下游传播该内容的模型。中毒的阈值比大多数工程师预期的要低，而放大因子——从微小的损坏比例到有意义的受损模型——比大多数工程师估计的要高。

这不是只关注医疗或法律应用的论点。这是一个认识的论点：每个生产LLM系统服务的用户都会对输出给予一定程度的信任。代码助手中自信的错误答案导致调试时间浪费。合同分析工具中自信的错误答案导致法律风险。故障模式随部署上下文扩展，而非随模型大小扩展。

传统ML团队做对了什么

传统ML从业者之所以在数据管道上投入大量资金，正是因为他们知道模型质量受数据质量的约束。他们在摄取时构建了特征验证、分布漂移检测器和模式强制执行。他们维护了保留集。他们宗教般地追踪数据血缘。

LLM团队经常跳过这些规范，因为这些模型开箱即用就令人印象深刻，而即时故障模式是"输出不太对"而非"模型崩溃了"。但数据质量税无论如何都在积累，只是表现在你的损益表上为：用户困惑、支持负担增加、无法解释的评估失败，以及检索质量逐渐恶化，直到有人终于将其与六个月来没有被审计的索引联系起来。

运营框架很简单：用你对待生产数据库相同的严格程度对待你的文档语料库和向量索引。在摄取时验证模式。在索引时监控分布。持续运行金丝雀查询。按文档追踪血缘。按文档类别强制刷新计划。

LLM不是能让劣质数据变好的魔法系统，它们是能让劣质数据看起来好——直到它不再好看的那一刻，而那时错误已经传播了。

在需要之前构建审计层。否则，你将在生产压力下调试自信的幻觉，而没有血缘数据告诉你损坏从哪里进入。