702 篇博文 含有标签「llm」

在技术领域，LLM 虚构（confabulation）的阴险之处不在于模型会给出明显的错误答案。而在于它会生成结构优美、语气自信、技术上看似合理的答案，但其中的细微错误只有领域专家才能发现——而且往往是在造成损失之后。

一个 Monte Carlo 物理模拟，它初始化正确，但在每一步都从头重新采样粒子位置，而不是进行增量更新。一个符合命名规范但氧化态错误的化学公式。一份引用了正确标准、参考了正确单位，但载荷系数完全错误的设计规范。每个输出看起来都是正确的。每个听起来都极具权威。但每一个都是错误的，且这些错误只有在有人运行实验、对组件进行压力测试或仔细阅读推导过程时才会浮现。

一个团队上线了一个改进的 LLM 提示词。A/B 测试运行了两周。指标上升了 1.2%，p=0.03。他们将其视为胜利并向所有人发布。六个月后，一次客户审计发现，新提示词一直产生细微的错误摘要——这种语义偏移是点击率和会话时长无法察觉的。A/B 测试并没有完全撒谎。它用一种从未针对 LLM 特性设计的评估方法测量了错误的东西。

标准的 A/B 测试是为确定性系统构建的：按钮更改颜色、页面加载变快、推荐算法调整排名。在给定相同输入的情况下，输出是稳定的，方差较小且易于理解，教科书中的样本量计算公式也适用。然而，对于由 LLM 驱动的功能，这些属性都不成立。如果团队不考虑这一点，他们就不是在进行实验——而是在产生带有统计显著性标签的噪声。

2023 年初，大量企业 AI 培训项目带着同一个卖点涌现：我们将教你的工程师提示工程。然而大多数项目完成第一批学员培训时，所教的具体技术已被模型自身自动化淘汰。到 2025 年，曾短暂标价 20 万美元年薪的"提示工程师"职位实际上已走向消亡。而那些培训项目依然在运转。

这就是 AI 课程陷阱。它不是努力或预算的问题。各组织在结构化 AI 培训、认证项目和以工具熟练度为核心的招聘标准上投入了大量资源。但工具的迭代速度快于任何课程所能追赶的速度，结果是一种永久性的结构性滞后：培训项目始终在教 18 个月前的 AI 工程。

一个客服 Agent 在 12% 的工单中生成了幻觉式的故障排查步骤。HTTP 日志全部显示 200 OK。延迟正常。错误率平稳。从每一项传统指标来看，系统都是健康的——但它却在大规模地悄悄捏造答案。

当工程师最终对决策层进行插桩后，根本原因在几分钟内便浮出水面：检索到的文档块相似度得分全部低于 0.4，对上下文的置信度为 0.28，而模型输出的置信度却显示为 0.91。这是一个巨大的不匹配——在传统日志中完全不可见，但在捕获了决策状态的追踪中一目了然。

这就是将传统日志应用于 LLM 系统时的根本问题。I/O 日志告诉你系统运行了。AI 原生日志告诉你它是否推理正确。

一名新工程师加入了一个重度依赖 AI 的团队。入职第三天，他们发现系统指令中有一个措辞别扭的双重否定。看起来像是个 bug。于是他们把它清理了——这是任何合理的人都会做的小小优化。两小时后，一条关键流水线的客户端分类准确率从 91% 跌至 74%。没有人知道原因。

这种情景以某种形式发生在几乎每一个基于 LLM 构建系统的团队中。新工程师并不粗心。那个提示词看起来确实有问题。但那个双重否定在某种意义上是"承重墙"——只有写下它的人才真正理解，而那是在经过数周实验之后才领悟到的。他们从未把这种理解写下来。

这就是 AI 入职差距：AI 代码库表面上的行为与实际行为之间的鸿沟，以及为什么这个鸿沟在有人掉进去之前是不可见的。

你的 AI 流水线昨晚报告了零错误。但输出结果完全是错的。

这不是假设。一份近期的行业报告发现，大约每 20 个生产环境 LLM 请求中，就有 1 个以永远不会触发异常的方式失败——HTTP 200、格式正确的 JSON、流畅的散文，但内容却是错的。可观测性系统保持绿灯，而流水线却在悄悄地欺骗用户。

根本原因是一个从传统服务工程中借来的架构假设：HTTP 状态码和解析错误覆盖了所有故障空间。但事实并非如此。LLM 流水线至少有四种底层基础设施看不到的故障类型——幻觉、拒绝、格式违规和上下文溢出——把它们当作边缘情况而非一等公民错误类型来处理，正是生产 AI 系统如何大规模传播隐性 Bug 的根源。

大多数关于幻觉的研究都集中在单次模型调用的输出上。这种框架忽略了一个更可怕的问题：在四阶段的工作流（pipeline）中，如果每个阶段都无条件地信任前一个阶段的输出，会发生什么。第一阶段中一个虚构的事实不仅会持续存在，还会成为后续每一次推理的承重前提。到第四阶段，工作流会给出一个自信且逻辑自洽的答案，但结果却是完全错误的。

这不是一个可以通过更强大的模型来解决的能力问题。这是一个系统架构问题，需要从系统层面进行修复。

你的智能体在第三轮对话时明确说过"绝对不要使用 eval()"。到了第三十轮，它调用了 eval()。你的保险处理系统规定"未经有效身份验证，不得批准理赔"。经过十五个压缩周期后，它批准了一笔。这些不是模型失败——是压缩失败。智能体的推理本身没有问题，是摘要中间件把那条唯一关键的约束丢掉了。

上下文压缩如今已成为长时运行智能体系统的标准基础设施。当对话历史增长到超出上下文窗口时，你就会进行压缩——把旧的轮次汇总成摘要，进行修剪、分块或精炼。问题在于，现代摘要器并不是随机破坏信息，而是可预测地沿着特定的断裂线破坏信息，而大多数团队只在生产环境中才发现这些断裂线。

每隔六个月，就会有一款配备更大上下文窗口的模型问世。GPT-4.1 达到了 100 万 Token，Gemini 2.5 紧随其后，达到 200 万，而 Llama 4 如今更是号称支持 1000 万 Token。隐含的承诺是：把所有内容都塞进去，不用再纠结该放什么，让模型自己搞定。

这个承诺在生产环境中站不住脚。一项 2024 年针对 18 个主流 LLM 的研究发现，随着输入长度增加，每一个模型的性能都出现下降——不是某些模型，而是每一个。上下文窗口是天花板，而非地板。把它当作地板来用的团队，正在以痛苦的方式发现这一点。

用户与 AI 助手进行了一个小时的长代码会话。他们建立了规范，分享了代码库上下文，并详细描述了一个多文件重构方案。接着，在第 40 条消息左右，AI 开始给出忽略其“已知”一切的建议。它推荐了一个用户二十分钟前已经拒绝的方案。当被追问时，它显得很困惑。

没有显示任何错误。没有出现任何警告。模型只是静默地丢弃了较早的消息，以为新消息腾出空间——而用户得出的结论是，该 AI 不可靠。

这不是模型失败。这是产品设计失败。

在一个生产环境中的 LLM 功能上线半年后，一名工程师提交了一个 bug：模型在上个季度的某个时间点开始给出错误的输出。没人记得改过提示词（Prompt）。Git blame 显示它为了“提高可读性”被清理过。之前的版本已经找不到了。调试工作只能从零开始。

就在这一刻，团队才发现他们的上下文窗口（context window）从未被真正工程化过——它只是被拼凑出来的。

上下文窗口是你的系统与模型之间的契约。进入其中的每一个标记（token）——系统指令、检索到的文档、对话历史、工具架构、用户查询——都是对一个函数调用的输入，这个调用既费钱又耗时，且会产生非确定性的输出。然而，大多数团队将上下文组合视为实现细节，而非 API 表面。提示词被就地编辑，没有版本控制。各部分通过累加增长。没有人负责布局。变化在无声无息中传播。调试体验比 LLM 时代之前的任何东西都要糟糕，因为至少堆栈跟踪（stack traces）会告诉你什么是改变了的。

你的 AI 功能在测试中运行完美。单轮问答，毫无问题。但在生产环境中，当真实用户进行一场 10 轮调试对话时，它却失败了——不是因为模型出了问题，而是因为你的速率限制器是为一个完全不同的世界设计的。

标准 API 速率限制是专为无状态 REST 调用设计的粗糙工具。每个请求被视为一个独立的、大致等量的消耗单元。对于 CRUD 端点而言，这种模型运行良好，因为每次调用确实具有可比性。但对于多轮对话，这种模型就行不通了——每一个后续轮次的成本都在递增，一次用户交互可能触发数十次内部模型调用，而会话中途被切断造成的损害，远比一次失败的单次查询严重得多。