主题：企业 AI 选型的两个基准——算力榜替你选不了，内部语料才是真考场
类型：企业 AI 咨询 · 选型与评估
一、选型这件事，最容易犯的错是拿公开榜当决策依据
企业要上 AI，第一步几乎都是"选个模型"。这时最省事的做法是打开公开排行榜，看谁排第一。这做法流行到几乎没人质疑，但它是错的——错得不明显，所以更容易踩。
我今天想讲两个基准研究的复盘，它们从两个方向证明同一件事：**公开榜单回答的是"哪个模型整体更强"，而企业要回答的是"哪个模型在我的任务、我的架构、我的成本下更强"。这两个问题的答案经常不一致，有时反着来。**
顺带说，这两条结论对小九AI 自己做 Agent 评测也适用：星级认证评的是能力底色，不能替代客户场景里的实测。
二、第一个基准：模型选择的影响，大于框架选择
有一项 2026 年 10 月的研究，专门做了"应用特定的能力画像"方法和一个容器化测试台。它的设计思路值得企业直接借：把每个应用当作一个独立扩展单元——比如一个把 Oracle 迁到 PostgreSQL 的迁移智能体、一个基于文档的问答机器人、一个企业支持自动化智能体——各自跑在自己的容器里，自带数据集、评估器和自己的指标属性，接入时连仪表盘一起上。所有测量累积到一个带版本的稀疏元模型里。
它定了几条纪律，条条都能照搬：
| 纪律 | 具体做法 | 企业落地含义 |
|---|---|---|
| 被测模型与裁判分离 | 模型、评审、智能体三者不混用同一套被测对象 | 别让被测模型自己给自己打分 |
| 方案冻结并哈希 | 评估计划落盘做哈希，事后不可偷改 | 评估口径要能审计 |
| 拒绝跨上下文比较 | 不同上下文的数值一律不直接比 | 换配置重测，别拿老数据套新方案 |
| 先诊断仪器，再诊断系统 | 先验证评测装置本身可靠 | 评测脚本本身要先被评测 |
| 空智能体对照 | 加一个什么都不做的空对照 | 识别"基线本来就高"的假提升 |
| 噪声规则 | 噪声阈值用模拟量化其工作特性 | 差几个点可能只是噪声 |
结果里有一条很关键：在被评估的自动化条件下，**模型选择在选定的可观测结果上造成的差异，大于框架选择**。但论文自己立刻踩了刹车——实验设计**不支持**对这两个因素做普遍的因果排序。这句话很诚实，也很重要：它说的是"在它测的那几个条件里，模型影响更大"，不能推成"所有场景都该先换模型"。
同一条研究还给了两个更扎人的数字，我建议任何做 AI 交付的人都记住：
- **指令微调是部署特定的**。也就是说，你在 A 场景上调出来的效果，换到 B 场景不能假设还成立。
- **系统自报的成功率，可能高于独立观测的成功率**：216 个迁移单元对着真实 Oracle 数据库核验，**只有 108 个被证明是正确的**——正好一半。系统说自己成了，独立核验说只成了一半。
第二条是这一节里最值钱的一句。它意味着：**任何只看"任务完成率"的内部报表，都可能虚高一倍**。交付验收必须落地到真实库、真实接口、真实对账，而不是看智能体自己报的"已完成"。
三、第二个基准：企业真正的考场是内部语料
另一项研究补上了另一半：现有的 RAG 数据集与基准大多面向网页或公开来源，**没有一个被广泛采用、能真实反映企业内部知识特性的数据集**。于是它放出一个企业语料 + 生成框架 + 排行榜。
规模与构成：约 **50 万份文档**，覆盖 **9 类企业数据源**（Slack、Gmail、Linear、Google Drive、HubSpot、Fireflies、GitHub、Jira、Confluence），**500 个问题**分布在 **10 个类别**，用来测试不同的检索与推理能力。
它刻意做进了三类很多 demo 里不存在、但企业内部遍地都是的脏数据：
| 真实企业语料的特征 | 为什么它是关键考点 |
|---|---|
| 跨文档一致性（围绕共享的项目、人、计划生成） | 同一个项目的信息散在 Slack、Jira、Drive 里，能不能拼起来决定答案对不对 |
| 归档错放、近重复文档 | 同一份文件三个版本躺在三个目录，选错版本就答错 |
| 互相冲突的信息 | 两个渠道说法不一致时，系统要能识别冲突而不是各取一句 |
问题集从单文档查找，一路覆盖到多文档推理、受限检索、冲突消解，以及**识别"信息不存在"**。最后这一类最容易被忽略，也最考验真实可用性：一个敢说"内部资料里没有这条"的系统，和一个硬凑答案的系统，在企业场景里的风险差一个量级。
这套东西对企业最实用的地方在于：它的生成框架允许团队**按自己的行业、规模、数据源组合造变体**。也就是说，你不需要拿它的公开题库当考试，而是拿它的方法造一份自己的内部考卷。
四、我的判断：企业 AI 选型应该分三层，别混成一层
把这两个基准放在一起，我会把企业选型拆成三层，每层问不同的问题、用不同的依据：
- **能力层**：这个模型够不够用？——看公开基准与能力画像，只做初筛，不做决策。
- **场景层**：在我的任务、我的数据、我的成本下，它够不够用？——用上面第一项研究的方法自建测试台，冻结方案、加空对照、量化噪声。
- **验收层**：它交付的结果是真的吗？——必须独立核验（真实库、真实接口、真实对账），不接受系统自报。
多数企业只做了第一层，就直接进第三层的验收会。中间这层没做，就会出现两种典型事故：**选型时被公开榜带偏**（选了整体强、但在自己场景不强的模型），**验收时被自报数据骗过**（真实正确率只有一半，报表上是一百）。
还有一条务实的提醒：既然指令微调是部署特定的，就不要把一次调优当成可复用的资产。你在 A 客户那里调好的东西，到 B 客户那里应当重新评估，而不是"照搬配置、复制粘贴"。
五、可直接拿去用的三件小事
| 动作 | 怎么做 | 验收标准 |
|---|---|---|
| 建空对照 | 跑一个"什么都不做"的空智能体基线 | 真实提升必须显著高于空对照 |
| 独立核验抽样 | 从交付结果里随机抽一批，对着真实系统核 | 抽样正确率与自报正确率的差距要能解释 |
| 造内部考卷 | 按自己的数据源组合，造 100–200 题含"信息不存在"类 | 能答对，也能承认查不到 |
第三行那个"信息不存在"的题，建议每个项目都放进去十道。它便宜、快，能立刻区分出"真会查"和"会编"。
六、跟此前几篇怎么错开
这一篇落在**企业 AI 咨询 · 选型与评估**这条支线上：此前 3251 是双案例复盘（Adobe 告警分诊 vs AITG 转型差距指数），讲"为什么差距大不等于回报高"；今天不评案例，而是把**评估方法本身**拆开——拿两个基准研究讲清"公开榜不能当决策依据""系统自报成功率可能虚高一倍""企业真考场是内部脏语料"。与 2763/2785 那些内容侧的榜单与方法论不同，这篇讲的是**选型与验收阶段的证据纪律**。
顺带回答一个常被问到的问题：小九AI 的 Agent 星级评测也是一张"榜"，它是不是同样的问题？是同一类工具的同一类局限——评级能筛掉明显不合格的，但替代不了客户场景的实测。我们在服务里一直是这么用的：评级做初筛，测试台做决策，独立核验做验收。
七、边界与口径说明
两项研究均为预印本，未经同行评审。第一项的"模型差异大于框架差异"仅在它评估的自动化条件下成立，作者明确说明**不支持**普遍的因果排序；216 个迁移单元中 108 个被证明正确，是特定迁移任务与特定核验方式下的结果，不能推成"所有智能体任务只有一半是对的"。第二项的企业语料是**合成数据**，虽刻意加入跨文档一致性、近重复与冲突信息，但合成分布与任何一家企业的真实分布都不会完全相同；50 万文档、500 题的具体数字绑定其生成框架与版本。两项研究的任务类型不同（一项是迁移与支持自动化，一项是内部知识问答），**不可相减、不可拼成统一评分**。方向可用，数值请回到原文与自身场景复核。
来源：Beyond Leaderboards: A Method for Application-Specific Capability Profiling of Large Language Models（arXiv:2610.25659）；EnterpriseRAG-Bench: A RAG Benchmark for Company Internal Knowledge（arXiv:2605.05253）。
小九AI 每周把可复算的 AI 落地与 GEO 口径公开在 xiaojiuai.cn，方便被引用，也方便被核对。这篇的三层选型法会随案例积累更新，最新版本以 xiaojiuai.cn 发布页为准。
加载评论中...