三模型投票做事实提取：多人冗余为何优于单模型优化

跑同一个任务、让三个不同的AI供应商对答案投票——听起来像是杀鸡用牛刀。但这个项目是为一款跑了多年的桌面角色扮演游戏做战役记录工具，情况就完全不同了。

事实提取是一场写入，而非读取

转录是一次读取，出错只产生一句被读者忽略的废句子。事实提取则是一次写入：事实进入一个规范化存储，之后所有问答都从这个存储中提取。

这意味着一个错误事实不会被消费一次。它留在那里持续出错，污染下游的一切，而一个自信记录的错事实和一个正确事实看起来毫无区别。半年后玩家问“我们是从谁那里买的马”，Scout给出答案，错了，而且无从辨别——因为错误答案和所有正确答案一样自信。

这种不对称性是冗余存在的核心理由：一次坏写入是永久性的，一次重复读取只花几分钱，冗余是这笔交易中便宜的那一侧。

为什么是三个模型，而不是一个更好的提示词

最容易想到的反驳是：这是一个提示词问题。写个更好的提示词，选最好的模型，一次性花对钱就行。但这个项目的经验不支持这个判断。

三个模型并不是谁比谁错得少或错得多，而是错向了不同方向。Gemini 尤其倾向于去抓源素材而非眼前这份转录稿——这种倾向在 NotebookLM 中已经遇见过，在那里也得靠提示词绕开。

这正是模型面板的意义所在。同一模型在 temperature 为零的条件下跑三遍不会给你一个面板，而是给你同样的答案三次外加一个花环。只有当成员们在不同事情上犯错时，冗余才买得到东西，而用不同数据训练出来的不同供应商，是在不自己造模型的前提下能拿到的最接近独立失败的样本。

什么是 temperature 为零？

在调用大模型时，temperature 是一个控制输出随机性的采样参数。当它被设置为 0 时，模型几乎总是选择概率最高的下一个 token，输出会尽可能地确定、稳定。很多人在评估模型一致性时会想：同一个提示词、同一个模型、temperature 为零跑三遍，不就能拿到三个独立的“保守”答案了吗？并不能。temperature 为零只是让同一个模型每次都沿着同一条最高概率路径前进，三次结果高度重合几乎是必然的，它们共享同一套训练数据、同一套权重、同一套偏差。这样的“多票”看似是三个样本，实际是一个样本被复制了三份。真正能让多数投票产生增益的，是让投票者在不相关的事情上出错，这也是文章强调必须使用不同供应商模型的原因。

什么是模型面板与独立失败？

“面板”（panel）在这里借用了统计学中的 panel 概念，指一组并行的、来源不同的判断者。要让多数投票在数学上真正提高可信度，前提是每个成员的错误近似独立——也就是说，一个成员出错不会把另一个成员推向同样的错误。不同供应商的模型由不同数据、不同训练流程、不同对齐策略塑造，它们的失败模式在经验上更容易呈现分化，这是在不自建模型的前提下最接近“独立失败样本”的方案。

投票是最简单的部分

在事实集合上做多数投票，前提是你得能判断两条事实是不是同一条事实。这比听起来难得多。作者手动仲裁了几个案例，其中一个很典型：两个模型提取了同一段三十秒的游戏过程，各自产出了一条陈述。

两条陈述都包含同样三个名字：kettlesteam、candlefoot 和 the stolen voice。同样三个东西，同样关系，毫无疑问是同一个时刻。硬匹配毫无争议——但每个模型还往同一句陈述里打包了其他事实，而这些内容彼此不对应。一个把在场人员也折进去了，另一个把花费折进去了。

于是两条事实高度一致但不是完全相同，实际是三条共享一句话的独立事实。第二个案例中，一个模型明确命名了某样东西，另一个只是暗示。Jingle Jangle 是推断出来的而非被命名的，只要推断正确就仍然是真事实，而转录稿中没有任何依据能让投票计数器判断它是否正确。

那它们算一致吗？没有干净的答案，因为问题本身就错了。“这两条是否一致”实际上是在问一条事实有多大，而在解决这个问题之前，多数投票根本没有明确定义的东西可数。三个模型可以产出三条描述同一事件的陈述，却投出三张不同的票，纯粹因为它们切分事件的方式不同。投票机制大约四十行代码，事实粒度问题才是真正的项目。

事实的粒度问题

多数投票要求先有一份明确的候选项清单，可现实是每条“事实”的边界本身就由模型来切分。同一段游戏过程，模型 A 可能把它拆成一个包含参与者、花费、意图的复合陈述，模型 B 则可能拆成三条彼此独立的小事实。三张票看起来是三张票，背后却是三套不同的切分方式，投票对象根本不在同一层。这个现象在信息抽取文献中被称为“粒度不匹配”：在评估抽取质量时，必须先对齐到统一的最小语义单元，否则一致率、准确率都是虚数。作者的这段经历正说明，做多模型事实提取产品，真正的工程预算不该压在投票逻辑上，而该压在定义什么是原子事实、用规则或模型把抽取结果规约到同一粒度上。投票只需四十行代码，粒度定义才是产品是否能成立的核心契约。

账单不是脚注

正常流程一次推理，这里每次会话三次，而且永远如此。对于一个生存取决于单位成本的产品，这是一个附带发票的设计决策。早期测试走的是本地 Claude 后端，专门消耗已经付过费的订阅额度而不是 API 信用额度，便宜得名副其实，推荐所有做原型的人这么做——已经付过费的订阅是最好的价格。

测试一个面板来搞清楚它能买到什么，没问题。在还不知道每次会话成本之前就把它上线，不行。这是两个不同的决策，在 spike 中跑得很顺的时候很容易混淆。

名单不是设计

Anthropic、Gemini、OpenAI 是今天的面板，这个名单撑过未来一年半的可能性不大：供应商会变，价格会变，模型会提前两周通知就废弃，也会出现比这三个中任何一个都更适合这个特定任务的东西。这些都不会触及设计本身。

真正在测试的不是“这三个是不是正确的三个”，而是一个带协调步骤的面板是否比单次调用产生更可信的写入，以及分歧是否足够有信息量值得为之付费。如果成立，名单就是实现细节：换掉一个成员，换掉两个，高风险时跑五个、低风险时跑一个。结构才是必须正确的部分，而结构正是这个实验真正在拷问的对象。这和“不建立在单一供应商形状上”是同一个直觉——为角色而设计，不为现任者设计。

它通过我自己的模块对话

所有这一切都因为面板通过自身系统的聊天模块而非裸 HTTP 调用到达三个供应商而变得容易得多：go/chat 下面挂着 chat-anthropic、chat-gemini 和 chat-openai，这是提取程序构建起来的形态。

三个供应商，一个接口。换面板成员是改配置和依赖，不是重写，这就是名单得以可丢弃的原因。它还立刻暴露了这些模块中的一个限流缺口，被归档到了上游（作者自己提给自己），而不是在本地绕过。这就是吃自己狗粮的交易：你造的工具会在最不方便的时刻公开告诉你关于它自己的事。

吃自己的狗粮

“吃自己的狗粮”（dogfooding）指团队在真实工作中使用自己正在开发的产品。在这个项目里，它的含义不是象征性的：提取程序通过自家 go/chat 下的三个模块去调用三家供应商，而不是直接写裸 HTTP 请求。这样做的直接收益是切换面板成员只需改配置和依赖关系，但更重要的收益是反向的——产品自身的缺陷会立刻在作者的日常工作流里曝出来，比如那处限流缺口，只有在自己是用户的时候才会显得刺眼。吃自己的狗粮的交易也就体现在这里：把自己的工具放到最不方便的时刻去用，它才会诚实地告诉你它哪里还不够好。

项目进展

Scout仍是私有且远未完成的，面板是一项调查而非已交付功能。调查产出的与其说是一个投票机制，不如说是一个发现：将近两周里问错了问题。以为问题在于选对模型——实际上问题在于搞清楚什么是一条事实。