技术深度剖析
核心问题在于LLM的根本架构。与传统软件中函数`f(x)`始终返回`y`不同，LLM是一个随机函数：`f(x, seed, temperature, top_p, ...)`返回一个token上的概率分布。每次推理都从该分布中采样，这意味着相同输入可能产生不同输出。这不是Bug——这是设计使然。Transformer架构及其注意力机制和softmax层，天生产生概率性输出。'temperature'参数显式控制采样的随机性，但即使在temperature为0时，不同GPU和软件栈之间的浮点数非确定性也会引入差异。
这在技术栈的每一层都引发了测量危机。考虑一个典型的RAG（检索增强生成）流水线。检索器可能因嵌入模型差异返回不同文档，LLM可能生成不同答案，而评估指标（如BLEU、ROUGE或LLM-as-judge）本身也是概率性的。结果是噪声的级联。
| 指标 | 确定性系统（如SQL查询） | 基于LLM的系统（如GPT-4o） |
|---|---|---|
| 输出一致性 | 100%（相同输入→相同输出） | 70-95%（因temperature和seed而异） |
| 延迟（p50） | 50ms ± 5ms | 500ms ± 300ms（重尾分布） |
| 每百万token成本 | $0.00（内部部署） | $2.50 - $15.00（API） |
| 错误率 | <0.01%（语法/逻辑错误） | 5-20%（幻觉、事实错误） |
数据要点： 基于LLM系统的方差比确定性系统高出数个数量级。延迟波动可达60%，输出一致性不可靠。当“错误”的定义变得主观时，传统指标如“错误率”便失去了意义。
一个值得关注的开源方案是LangChain Evaluation框架（GitHub: `langchain-ai/langchain`，95k+星）。它提供了运行重复评估并计算均值、中位数和标准差等统计量的工具。然而，它仍然缺乏内置的统计过程控制（SPC）图或置信区间计算。另一个值得注意的仓库是`explosion/spacy-llm`（5k+星），它将LLM集成到NLP流水线中，强调通过严格种子设定和确定性解码实现可复现性。但即使设置seed=42，由于不同硬件上的浮点运算，方差依然存在。
工程界需要采纳制造业中的统计过程控制（SPC）。SPC使用控制图来区分“普通原因变异”（过程固有的）和“特殊原因变异”（真正的变化）。对于LLM输出，团队可以运行基准测试套件100次，计算质量指标（如正确性得分）的均值和标准差，并将每次运行绘制在控制图上。如果新模型版本将均值偏移超过3-sigma，那就是真正的改进或退化。这远比比较单次运行更加稳健。
关键玩家与案例研究
多家公司正在应对这场危机。Anthropic一直公开呼吁需要统计上严谨的“宪法AI”和“评估”。他们对“评估危害”和“模型规范”的研究承认，单点评估是不够的。OpenAI在其API中引入了'seed'参数以提高可复现性，但这并非万能药——方差在不同模型版本和硬件之间依然存在。
LangChain（公司）将其整个业务建立在LLM编排和评估之上。其LangSmith平台提供了可观测性和评估仪表板，但默认指标（如由LLM评判的“正确性”）本身也是概率性的。这产生了一个递归测量问题：如何评估一个评估器？
| 平台 | 评估方法 | 可复现性 | 统计严谨性 |
|---|---|---|---|
| LangSmith | LLM-as-judge，人工反馈 | 低（LLM评判者会变化） | 基础（均值/标准差） |
| Weights & Biases (W&B) Prompts | 自定义指标，版本控制 | 中等（种子设定） | 高级（实验追踪） |
| Arize AI | 可观测性，漂移检测 | 中等 | 高级（统计检验） |
| MLflow | 实验追踪，模型注册 | 高（确定性运行） | 基础（无SPC） |
数据要点： 目前没有主流平台为LLM输出提供内置的SPC或基于置信区间的评估。这是一个巨大的市场空白。Arize AI凭借其漂移检测最为接近，但它聚焦于输入/输出分布，而非指标本身的可靠性。
一个值得注意的案例是GitHub Copilot。其代码建议每次调用都不同，使得微软难以衡量新模型版本是否提升了开发者生产力。像“接受率”这样的内部指标充满噪声，因为开发者可能接受“足够好”但并非最优的建议。据报道，该公司使用数千名用户的A/B测试来平均化这些波动。