白泽决策层：把高频判断从主模型里拆出来

项目开源名 Baize（白泽）——面向团队的 AI 工作台运行时（Go 1.25+，MIT） 仓库：https://github.com/rebornace/baize · 码云镜像：https://gitee.com/RebornAce/baize

文中三个名称与界面一致，先对齐一下：

另有 匹配模型（如 bge-m3）：只负责工具检索，不负责上述判断。

一、为什么「判断」值得单独拆一层

把白泽挂在业务系统旁边，接口文档一接上，成百上千个接口就变成成百上千个可调用的工具。一台真实后台接进来，很容易就是几百个工具。

接到一类，每一轮对话之前就堆了很多高频判断：这一轮该给主模型看哪些系统、哪些工具该进候选、值不值得再开一次记忆抽取、该用哪个档位的模型……

这些判断有三个特点：第一是频率高（几乎每轮都要）；第二是答案短（通常只是「选几个」「是或否」）；第三是不该用贵的——如果每次都去推主模型生成长文，省下来的 token 往往比判断本身还贵。

常见做法是把高频判断从生成式调用里拆到一层更便宜的能力上；思路接近 Jev 一类「少写长文、直接出枚举判断」的产品形态。下面按阶段说明白泽怎样把预筛、匹配增强和判定链路串起来。

二、第一阶段：确定性预筛，先把噪声压下去

这层并不需要决策模型。白泽先做一套零成本、可降级的确定性手段：

• 系统路由：用户查询里有区分度的词会强制命中对应连接器；主模型的选择只能补充、不能拆掉强制命中。
• 工具预筛：词项 / 中文 bigram 的 BM25（标准匹配）先把相关工具排进候选，主模型只看这一份短列表。

优点是确定、可解释、断网也能用。但只压噪声：用户说得含糊时，列表里仍可能有无关项。

这里的「筛选」是运行时预筛策略，和判定链路里的 Rules 不是同一段代码——Rules 目前主要管「这轮值不值得做记忆抽取」。

三、第二阶段：匹配增强（向量），失败再回词法

v0.4 在「找得到工具」这一维做了增强。原先预筛是 BM25；加上稠密向量后，用 RRF 融合。可以可选接一个 Embedding 模型（本机 Ollama 的 bge-m3，或兼容 OpenAI 的 Embedding API），给每个工具文档做向量，查询时按相似度排序。

融合规则里向量权重大于 BM25（实现里 dense 权重约为 BM25 的两倍）：中英混用、业务专有名词、用户说法不标准时，往往更稳。增强失败自动回到标准匹配，对话不受影响。

这一步回答的是「能不能帮我找到该用的工具」。它还不负责「要不要抽记忆、工具结果要不要原样保留、路由偏轻还是偏重」——那些是决策层的另一条线。

四、第三阶段：接上决策模型

v0.5.0 把「要判断」接到决策模型，形成今天的判定链路：

决策模型（System One）→ 备用模型（可选）→ Rules

第一层：决策模型（System One）。 本机 Ollama（≥0.35）自动拉取 tev1（纯 CPU 友好），或对接兼容 POST /v1/systemone 的云端 / 自建服务（不是普通 Chat Completions）。高频短答案在本地或专用判定端完成，不占主模型的生成预算。

第二层：备用模型（可选）。 仅在 System One 不可用时，用一个已配置的便宜模型做判断。已经配好决策模型时，这一项应留空；留空不会改用主模型，而是进入下一层。

第三层：Rules。 确定性规则。当前主要覆盖记忆抽取；其它判断点会放弃本层，继续沿用原路径：宁可按装配时写死的失败方向走，也不假装「绝对聪明」。

整条链的原则是 沿用原路径（fail-open）：某一层超时、未配置或放弃判断，不拖垮对话——例如照常下发工具 schema、照常做记忆抽取。宁可多花一次，也不可静默丢掉关键能力。

关于分数：System One 协议可能返回内部排序分；客户端只用来选出枚举结果（例如分数 ≥0.5 取 yes），不把分数暴露给产品逻辑，也不写「p>0.9 就自动执行」。本地常见决策模型给出的数字往往是未校准的排序分，不是业务阈值。真正「报 90% 就大约有 90%」的校准概率，需要专用训练路径；开源默认路径并不假装具备。

时机也简单：决策模型不是 v0.5 凭空造出来的。v0.4 为了工具匹配，已经把本机 Ollama 安装、拉取 bge-m3、模型路径与卸载收进「匹配与决策」页。v0.5 的增量，主要是在同一台已经装好的 Ollama 上再拉一个 tev1，或同一套安装体验，统一走 /v1/systemone。基础设施摊过一次，再接决策模型的边际成本很低。

五、四个容易混淆的点

为什么强调 CPU 友好。 高频判断要短、要常驻。tev1 在产品说明里偏 CPU 友好，普通办公机也能跑，不必为「想一下」再串一次云端生成。

为什么要两道开关。 只配了决策模型，却没有在「运行参数 → 智能提速」打开总开关和对应子功能，不会省主模型 token。总开关打开后，还要再打开需要的项：工具候选收敛、工具结果剪枝、记忆预判、长文选档等。系统必须明确知道「现在要开哪些能力」，而不是「装了模型就全开」。

匹配与决策可以共用一台 Ollama。 匹配用 bge-m3，决策用 tev1，可以挂在同一台 Ollama 上。设置中心的「匹配与决策」页把两条链路放在一起：安装进度、模型路径、自定义目录、清理，都在同一页。

国内安装路径。 Windows 装 Ollama 优先走 ModelScope 社区同步源（跟发版标签同步），失败再试其他镜像。装得上，后面的判定链路才谈得上。

六、这套组合现在的实测水位

先分清两层数字，避免把「换了判定后端」和「主模型 prompt 变短」混成一张表。

6.1 主模型变便宜：工具筛选 + 预筛

基准：37 条真实只读业务请求，横跨 3 个后台（共 390 个工具），主模型 DeepSeek-Flash。相对筛选宽度 32，默认宽度 16 时，turn-0 的 prompt tokens 约降 34%；连跑 5 轮共 185 次，运行成功率 99.5%。若对比「一轮下发全量约 390 个工具」（turn-0 约 8.5 万 prompt tokens → 约 1.4k–3.8k），则是数量级下降，远不止 34%。

这组数字主要反映工具筛选 + 预筛对主模型 prompt 的效果；语料与脚本在仓库 scripts/tool-routing-eval，可复现。它不等于「换上 System One 单独省了 34%」——筛选宽度固定时，判定后端换成 tev1，主模型 prompt 带宽应大致同级。

6.2 哪些过程从主模型改到了决策模型

决策模型单次费用往往远低于主模型（自建 tev1 时接近电费）。真正要看清的是：哪些过程不再（或少）走生成式调用。

省预算的大头通常是：主模型少塞 schema、少吃上下文，以及整段取消的生成调用。判定后端换成更便宜的实现，是第二层账。

6.3 判定后端对比：System One vs 备用模型

同 37 条请求、筛选宽度 16、同一台机器各跑一遍（不是再扫一遍宽度表）：

系统路由出处分别为 systemone 与 remote；主模型 prompt 同级。备用模型墙钟约 1.48 倍——接决策模型不是「多雇一个模型陪聊」，而是把高频判定从生成式调用里拆走。脚本与说明见仓库 scripts/tool-routing-eval。

七、怎么用

环境要求 Go 1.25+，或从 GitHub Releases 下预编译包（当前请用 v0.5.0）。开箱默认仍是零额外组件的标准匹配。要完整判定链路：

全文与仓库同步；细节以仓库文档为准。

八、收束

从确定性预筛，到可选匹配增强，再到决策模型接上一条链——白泽把高频判断从贵的地方挪到便宜的地方；挪不动或不准时，沿用原路径放行。判定可以接专用决策端；准不准、校准到什么程度，是另一笔账。欢迎用后直接反馈。

GitHub：https://github.com/rebornace/baize 码云镜像：https://gitee.com/RebornAce/baize