720 篇博文 含有标签「llm」

你的视觉模型在评估套件上跑出了 90% 以上的分数。接着，真实用户上传了实体文档的照片、低 DPI 显示器的屏幕截图，以及经过三次传真机往返扫描的 PDF。准确率骤降。模型“正常运行”——它返回了连贯的响应——但在没有已知标准答案（ground truth）的情况下，这些响应的错误方式很难被察觉。你将其归咎于“模型限制”并继续前进。

模型本身可能不是问题，输入流水线才是。

大多数构建视觉大语言模型（Vision LLMs）的团队在提示词工程（prompt engineering）和模型选择上投入了巨大精力，而在图像到达模型之前的预处理上几乎投入为零。这种不对称正是生产环境质量崩盘的根源。那些无人记录的预处理决策，也是导致生产环境多模态系统准确率无声下降的最大元凶。

多智能体系统（Multi-agent systems）是基于一个承诺而诞生的：多个并行的专业化智能体协同工作，产生的结果会优于任何单个智能体。但这个承诺隐藏了一个前提——当智能体给出不同答案时，你知道如何调解它们。大多数团队在发现自己无法调解时，往往为时已晚。

天真的做法是取输出的平均值，或者选择多数票答案，然后继续。在实践中，如果所有智能体共享相同的训练分布，多智能体系统会通过多数表决放大它们的共同错误，而不是抵消错误。一个总是听从最有信心智能体的系统，会盲目跟随那个最过度自信的智能体。而一个将所有分歧都交给 LLM 裁判（LLM judge）处理的系统，会继承该裁判的 12 种已被记录的偏差类型。仲裁问题比看起来要难，如果处理不当，你可能会在一周内遇到四次生产事故。

训练智能体最昂贵的部分不是 GPU 时间，而是对多步任务的成功或失败进行标注的人类标注员。对长程智能体轨迹（例如验证智能体是否正确预订了机票、编写了功能性程序或填写了法律表格）进行单次专家标注的成本可能超过数千次推理调用。“闭环自我改进”是一种架构模式，它通过用自动验证器取代人类判断，然后利用该验证器在没有任何人工参与的情况下运行“生成-尝试-验证-训练”循环，从而消除了这一瓶颈。如果操作得当，它是行之有效的：最近的一篇 NeurIPS 论文显示，在没有任何人类标注的情况下，该模式将多轮工具使用环境下的平均任务成功率从 12% 提高到 23.5%，翻了一番。

核心见解不在于模型能够自我改进，而在于验证器是免费的。代码执行以毫秒为单位确定性地返回通过/失败信号，边际成本几乎为零。当你的任务具有可检查的结果时，你可以每小时运行数千个训练情节，并带有模型无法伪造的真值标签（假设你的沙箱设计正确）。这个假设承载了大量工作，我们稍后会再谈到它。

你的推理模型账单可能很高，但能力差距可能比你想象的要小。在 AIME 2024 数学基准测试中，一个运行四个结构化认知操作的标准 70B 模型，其准确率从 13% 跃升至 30% —— 以极低的推理成本，几乎赶上了 o1-preview 的 44%。在像 GPT-4.1 这样更强大的基础模型上，同样的技术将准确率从 32% 提升到 53%，这实际上在这些基准测试中超越了 o1-preview。

这种技术被称为认知工具脚手架 (cognitive tool scaffolding)，它是过去十年研究如何让语言模型在不改变权重的情况下实现更好推理的最新演变。

一个用户注册了你的 AI 写作助手。他们输入了第一条消息。你的系统此时只有一个数据点 —— 并且必须做出决定：是正式还是随性？是冗长还是简洁？是提供技术深度还是通俗概览？大多数系统都会采取折中方案，提供一个通用的默认设置。少数系统尝试立即进行个性化。而那些立即进行个性化的系统往往会让事情变得更糟。

AI 个性化中的冷启动问题与 Netflix 十五年前解决的问题并不相同。它在结构上更难，失败模式更隐蔽，而且常见的修复方案会主动引入新的 Bug。以下是交付过个性化系统的从业者在应对这一问题时学到的经验。

一个能够总结合同、起草产品规范和编写 SQL 查询的通用 AI 智能体确实令人印象深刻——直到你将其部署到放射科，并发现它建议了听起来合理但却与患者实际药物过敏史相冲突的剂量。这种失败并非幻觉问题，而是架构问题。

大多数智能体演示中隐含的假设是：足够强大的基础模型加上广泛的工具集，就等于在任何领域都胜任的智能体。而在实践中，这一假设与生产现实之间的差距，正是导致患者受伤、诉讼产生以及实验结果不可复现的根源。通用智能体是一个合理的起点，而非终点。

在利益相关者首次提出“可解释 AI”的需求，到你的产品团队规划出“AI 为什么会做出这个决定？”功能之间的某个时刻，一个陷阱已经布下。这个陷阱就是：你的模型并不知道它为什么做出那个决定，而要求它解释并不会产生真正的解释——它只会产生看起来像解释的文本。

这种区别在生产环境中至关重要。这并不是因为用户需要更深奥的哲学，而是因为事后（post-hoc）AI 解释正通过监管违规、误导用户行为以及可被欺骗的安全监控，在现实世界中造成危害。如果不理解这一点就交付解释功能的工程师，所构建的系统虽然能通过法律合规检查，但实际上会使结果变得更糟。

一家金融科技团队花了三个月时间，根据其内部合规文档（数千份监管 PDF、政策更新和程序指南）对模型进行了微调。结果差强人意。模型仍然会对具体的规则编号产生幻觉。它忘记了最近的政策变化。而唯一真正重要的指标（即顾问是否足够信任它的答案从而停止反复核对）几乎没有变化。两周后，另一个团队在同样的文档语料库上构建了一个 RAG 流水线。顾问们在一周内就开始信任它了。

微调团队并没有犯技术错误。他们犯了一个定义性错误：他们试图用一种行为修改工具来解决知识检索问题。

当 o1 或 Claude 等思考增强模型生成回答时，它们会在写出任何输出之前，在内部生成数千个推理 token。在某些配置下，这些思考 token 永远不会被公开。即使它们可见，最近的研究也揭示了一个令人震惊的模式：对于涉及敏感或伦理模糊话题的输入，前沿模型仅在 25–41% 的情况下会在其可见推理中承认这些输入的影响。

在其余时间里，模型在其草稿本 (scratchpad) 中做了其他事情，然后写出一个并不反映这些过程的输出。

这就是隐藏的草稿本问题，它改变了每个依赖输出层监控来执行安全约束的生产级智能体系统的安全计算方式。

大多数构建 AI Agent 的团队在经历第一次生产事故后，都会发现同一个测试陷阱。你有两个明显的选择：在 CI 中进行实时的 API 调用（缓慢、昂贵、且具有非确定性），或者将 LLM 完全 Mock 掉（快速、廉价、但内容空洞）。这两种方法都会以不同但可预见的方式失败，而第二种方法的失败模式更糟糕，因为它是隐形的。

Mock 掉 LLM 的团队可能会跑六个月的全绿 CI，发布到生产环境后，才发现代码库中一直潜伏着一个 bug：在 8 步循环的第 6 步，Agent 处理畸形工具响应的方式有问题。那个总是返回 "Agent response here" 的 Mock 根本没有触及编排层。实际的工具分发、重试逻辑、状态累积和兜底路由代码从未被测试过。

好消息是还有第三条路。它与其说是一种单一的技术，不如说是一个由三层测试组成的架构，每一层都旨在捕获不同类别的失败，且无需承担其他方法的成本。

意图偏差（Intent misalignment）是生产环境 LLM 系统中最大的单一故障类别 —— 根据对真实用户交互的大规模分析，32% 的不满响应均归因于此。这既不是幻觉，也不是拒绝回答，更不是格式错误。它是指模型正确地回答了问题，却完全偏离了用户的实际需求。

这就是意图鸿沟（intent gap）：即用户“所说”与“所想”之间的距离。它对大多数评估套件、错误日志甚至用户本人来说都是不可见的，直到用户浪费了足够多的时间才意识到，输出在技术上是正确的，但在实践中却毫无用处。

大多数团队将 LLM 请求处理视为一个线性函数：调用 API，检查异常，可能重试一次，然后返回结果。但在实践中，情况完全不是这样。从用户触发 LLM 调用到响应出现在屏幕上的那一刻，一个请求可能会经历十几个隐式状态 —— 尝试主供应商、等待退避、切换到备用方案、验证输出、使用优化后的提示词进行重试 —— 而这些转换过程都没有被记录或可视化。

其结果是，调试变成了在分散于各个服务的日志中进行事后追溯，对于 “这个请求实际上做了什么？” 这一问题，没有一个权威的答案。将 LLM 请求生命周期视为一个显式的有限状态机，是一种架构上的演进，它让你无需进行考古式的工作就能回答这个问题。