techcrunch.com

把AI模型故意调弱4个档次,准确率反而飙升——a16z为何砸900万美元押注

AI准确率,AI幻觉防范,Probably AI,验证机制,LLM可靠性,a16z投资商业

Probably Raises $9M to Build a More Reliable Kind of AI

Probably AI Raises $9M to Fix LLM Hallucinations

Investing in LMArena: The Reliability Layer for AI

这家AI创业公司刚拿到900万美元融资,干的第一件事居然是把自己的模型故意调弱。

而且一下子调低了整整4个档次,比顶级前沿模型还弱。

3秒读懂

有标准答案的任务 → 确定性验证机制 → 弱模型也能过关 → 99.99%准确率 → 本地部署省成本

大家都以为"更聪明的AI"才是答案

AI一出错,大家的第一反应通常是等下一代、更大的模型。GPT不行就等下一个GPT,Claude搞不定就等下一个Claude。"模型越做越大越聪明,总有一天就不会犯错了"——这几乎是整个行业心照不宣的假设。

可数字摆在那儿,这个假设站不住脚。2026年对37个模型做的基准测试显示,整体幻觉(胡编乱造)比例落在15%~52%之间,就连公认最准的顶尖模型也有15~17%。法律咨询场景能飙到69~88%,没有防护措施的医疗任务甚至冲到64%。模型明明在不断变强,这个数字却怎么都降不下来。

这可不只是一堆统计数字而已。2024年一年,全球因AI幻觉造成的损失就有670亿美元,2026年第一季度光是错误的金融分析就烧掉了23亿美元。企业平均每位员工每年要花14,200美元、每周要花4.3小时来核实AI给出的答案。47%的高管坦言,自己已经根据带幻觉的AI内容做过重要决策。

就在大家都等着"下一代模型出来就好了"的时候,拿到a16z 900万美元投资的一家创业公司,偏偏反着来。

但Probably偏偏反其道而行

Peter Elias曾在Optimizely负责数据平台,后来出来创办了Probably。他没有把模型做得更大,而是造了一套专门盯着模型的验证机制。Elias把这套机制叫做"数据科学机甲装"——给LLM吐出的每一个答案都套上一个确定性验证器,拿真实数据集去核对,再让模型不断重新训练,直到能通过这套验证器为止。

结果反直觉。验证机制一旦到位,哪怕用的模型比前沿模型整整弱4个档次,也能跑出差不多的可信度。Elias原话是这么说的。

"验证机制这层工程做得越到位,模型就可以做得越弱。只要上下文打磨得足够好,模型根本不需要那么拼。"
— Peter Elias,Probably创始人

他们的目标是99.99%的准确率,这种水平通常只在确定性系统里才见得到。为什么这能赚钱?因为模型可以弱意味着能跑在本地硬件上(目前Beta 0.1版支持M1~M5的Apple Silicon),token成本大幅下降,客户数据留在本地、只把推理结果传到云端。Probably表示这套架构能把基础设施成本压低到25%。

Elias点出的原因也很有意思:"大厂没有动力这么干,因为模型返工重跑的次数越多,他们赚得越多。" a16z最近也提出过类似的投资逻辑——"能把AI做得无聊的公司,才会创造最大的价值",这里的"无聊"不是说没意思,而是说像数据库一样可预测、靠得住。

	传统方式 — 更大的模型	Probably方式 — 验证机制
提升准确率的方法	换成更大、更贵的前沿模型	用确定性验证器过滤掉弱模型的错误答案
成本	token费用、API费用持续攀升	可本地运行,基础设施成本最多降25%
判定标准	由另一个模型来打分(LLM-as-judge)	人定的规则 + 真实数据集比对
局限	连没有标准答案的创意类工作也硬套	专攻有标准答案的工作(数据、财务、医疗)

这里的判定标准值得多说一句。现在流行的LLM-as-judge,说到底还是另一个概率模型在打分,躲不开"偏爱排在前面的答案"的位置偏差,也躲不开"偏爱长答案"的冗长偏差。Probably干脆不把打分这件事交给AI,换成人定的确定性规则。相当于宣布:不再拿"AI答得对不对"这个问题去问另一个AI。

这场博弈,韩国也已经在上演

这不只是硅谷的故事。就在昨天(2026年7月14日),韩国AI企业GenesisCoTechsAI基于同样的问题意识,把'AI Debate Engine'正式商用化了。思路不太一样——Probably靠确定性规则核对答案,这边则是让ChatGPT、Claude、Gemini、Grok在同一个平台上互相辩论,再基于执行结果做验证,走的是"竞争→验证→协作"的框架。但方向是一致的:都不愿意直接相信单一模型给出的概率性答案。

这事儿为什么跟国内企业也息息相关?因为AI越往实际业务里嵌,没被验证过的风险也跟着一起嵌进来。最近韩国国内的一份安全报告把提示词注入(prompt injection)列为企业AI运营环境里最致命的漏洞,还给出一个数据:大企业37%的漏洞已经被搁置超过一年。"AI给的答案到底能信几分",已经不只是技术团队的问题,而是所有把AI工具用到实际业务里的组织都要回答的问题。

方法	核心思路	谁在做
确定性验证机制	拿标准答案数据集和硬编码规则做比对判定	Probably
多模型辩论	让多个LLM相互竞争、辩论,达成共识	GenesisCoTechsAI
LLM-as-judge	由另一个LLM给答案打分	多数通用评估框架

三种方式各有用武之地,但我们自己的团队现在就能照搬的,是确定性验证机制这一条。不需要同时跑多个模型,也不用另外训练一个打分模型,只要把"用代码定义标准答案,再拿AI的回答去对照"这条原则搬过来就行。

怎么把这条原则用到自家的AI工作流里

Probably现在还没法直接买来用(仍是beta版,只支持Apple Silicon)。但这家公司验证的原则——"给有标准答案的工作套上确定性验证"——放到你现在用的任何AI工作流里都适用。

先挑出可验证的工作
优先选数字、代码、数据库查询这类"对/错"很明确的工作。创意写作或开放式问题不适合这套方法。
准备标准答案数据集(ground truth)
需要一个能拿AI答案去比对的基准。已经验证过的历史数据、内部数据库、官方文档都是候选项。
用确定性规则搭验证器
别把打分这件事交给另一个AI。像"满足这个条件就通过,否则打回"这种硬编码规则,得自己写,才能做到不偏不倚的判定。
用失败案例反过来打磨提示词和上下文
把验证器筛出来的错误答案模式收集起来,持续打磨提示词或提供的上下文。就像Elias说的,"上下文打磨得越好,模型就越不需要拼命"。
留下审计记录(citation trail)
把AI答案凭什么通过验证的过程记录下来,以后有人问"当初为什么信这个答案",你才答得上来。信任说到底就是从这些记录里来的。