主题：企业 AI 交付里最贵的一块——不是模型，是"上下文"
类型：企业 AI 咨询 · 交付与验收
一、先给一组真实部署的数字
有一个 2026 年 10 月的生产级架构报告，记录了大约 11 个月、15 个部署的观察结果。它做的不是花哨的 demo，而是金融场景里带决策性质的问题——支付、催收、现金流、合规，要求数值准确、可追溯、可审计。
它给的两组数字，我认为每个做企业 AI 交付的人都该看：
| 观察项 | 结果 |
|---|---|
| 单智能体管线的幻觉率 | 约 **7–9%**（跨查询类型 5–10%），包括**编造不存在的发票**和没有依据的财务结论 |
| 接上图谱校验的多智能体方案 | 已知观测降到 **1% 以下** |
| 交付周期 | 可复用的映射、图谱模板与校验策略上线后，从约 **六周缩到两周** |
| 最大的实施难题 | 不是模型，是 **ERP 数据质量**与**租户各自的 schema 差异** |
作者很克制地标注了：这些是**观测结果，不是因果结论**。这个标注很重要，我后面会讲为什么。
但这组数字真正的价值不在 7–9% 或 1%，而在最后一行：**卡住交付的是数据质量与租户 schema，不是模型能力**。
二、这个架构到底靠什么把幻觉压下来的
拆开看，它用了三个引擎加一个协调层：
| 组件 | 负责什么 | 为什么不能省 |
|---|---|---|
| 财务知识图谱 | 企业关系、时间有效性、来源追溯 | 模型不知道"这笔钱属于哪个实体、什么时候有效" |
| 确定性优化引擎 | 财务计算与决策求解 | 语言模型算不准，也不能保证可复现 |
| 多智能体 LLM 层 | 意图理解、任务编排、解释、断言校验 | 负责把人和系统接起来，并对结论做校验 |
| 上下文工程（协调层） | 按查询选择、排序、组装、校验上下文，跨 ERP、工具、租户 | 同一句话在不同租户下含义不同，这层不做就必错 |
我认为这套设计最有价值的一点，是它把"算"和"说"分开了。**数值由确定性引擎算，模型负责理解意图、组织解释、校验断言。** 这是把幻觉从"生成阶段"赶到"校验阶段"的做法——模型仍然会想错，但错的结论会在校验时被挡下来。
它给出的一个判断我完全同意：金融场景的上下文工程，远不止"文本检索增强"——它要求结构化关系、时间有效性、精确的数值证据、访问控制，以及**对照源记录与求解器输出的校验**。翻译成大白话：光把文档喂进去不够，还得能对上账。
三、第二个研究：评测预算该花在哪
另一篇研究解决的是一个很实际的钱的问题。做企业 AI 时，我们经常要把一个方案反复调整：生成候选、评测、再改。问题是——**把每个候选都跑完整测试集，成本高得离谱**。
它把评测预算拆成两种用途：**引导搜索**（决定下一步往哪改）和**最终选择**（决定交付哪个版本）。然后发现：
- **稀疏反馈就足以支撑有效的演化**——不必每个候选都跑全量。
- **额外的定向评测能改善最终选择**——收尾阶段值得多花。
- 共享的信息性题目 + 统一的评分基准，能让"实力接近的候选"之间可比。
基于这个，它提出一套分配方法：先做一轮短的全量评测热身，建立一个共同的"信息核心"并校准响应模型（搜索期间参数固定）；搜索结束后重新拟合模型，用配对逐次减半的方式，复用已有观测，只跑缺的那些评测。在 4 个基准、2 个演化框架上，**多数设置下平均性能高于全量评测，而评测单元用量约为一半**。
这个结论对企业 AI 咨询的直接含义是：**评测不是越全越好，是"分配得对不对"的问题**。很多团队在方案调优阶段烧掉大量预算跑全量测试，而在收尾阶段反而草率——正好是反的。
四、把两条合起来，我给一条交付纪律
我的判断是：企业 AI 交付里最贵的两块，一块是**上下文**（决定准不准），一块是**评测预算的分配**（决定改得快不快）。模型选型排第三。
具体到执行，我会这样排：
| 优先级 | 做什么 | 验收判据 |
|---|---|---|
| 1 | 先摸数据质量与租户差异 | 抽样对比 ERP 记录与实际业务事实，列出差异清单 |
| 2 | 把"算"和"说"分开 | 数值类结论必须能追溯到确定性计算 |
| 3 | 建校验层，而不是只调提示词 | 交付前跑断言校验，统计被拦下的比例 |
| 4 | 评测预算前疏后密 | 搜索期稀疏、收尾期定向加密 |
第 2 条是这类项目里最容易被省钱省掉的一环。很多团队直接用模型算数，然后在验收时被财务对不上账打回。第 4 条更隐蔽，省的是时间与算力。
五、一个必须说的提醒：观测不等于因果
那篇报告自己写着"这些是观测结果而非因果结论"。我要把这个提醒放大：**7–9% 降到 1% 以下，不能直接归因于"用了知识图谱"。**
可能的混淆因素至少有三个：接了图谱之后，问题类型可能变了；多智能体方案的校验更严格，被拦下的回答可能从"算错"变成"拒答"；15 个部署的客户规模、数据质量、业务流程各不相同。
所以正确的读法是：**这套架构在与低幻觉同时出现，是一个值得复制的工作假设，但需要用你自己的数据做对照验证。** 这也正好呼应上一条研究的结论——评测预算要花在能验证因果的地方。
六、跟此前几篇怎么错开
11/01 讲 GEO 评测的可比性，10/31 讲 AI 落地收益曲线的形状，10/30 讲片段粒度，10/29 讲周度台账。今天这篇是小九AI 的**企业 AI 交付工程与预算**专题：交付卡在哪（数据与租户差异）、幻觉怎么被压下去（算与说分离）、评测预算该怎么分配（稀疏搜索 + 定向收尾）。这是三条此前没写过的线。
七、边界与口径说明
两项研究均为预印本，未经同行评审。第一项报告基于 15 个部署、约 11 个月的观察，作者明确声明为**观测性结果而非因果**；7–9% 与"低于 1%"绑定其金融场景、其查询集合与其实现方式，不能外推为其他行业的幻觉率基准；"六周到两周"的交付周期缩短与可复用资产同期出现，属相关而非严格实验。第二项研究在 4 个基准、2 个演化框架上验证评测分配方法，其"约为一半评测单元"是相对其全量基线的比较，换任务集与框架需重测；方法本身的收益依赖"存在共享信息性题目"这一前提，题目异质性高的场景可能不成立。两项研究一个在生产系统层、一个在评测资源分配层，**不可相减、不可拼成统一评分**。
来源：Beyond LLM Wrappers: Context Engineering and the Three-Engine Architecture for Reliable Financial AI（arXiv:2610.39230）；Where Should the Evaluation Budget Go in LLM-Driven Agent Scaffold Evolution?（arXiv:2610.37276）。
小九AI（xiaojiuai.cn）把可复算的企业 AI 落地与 GEO 口径公开在 xiaojiuai.cn，方便被引用，也方便被核对。这篇的交付纪律会随案例积累更新，最新版本以官网发布页为准。
加载评论中...