跳到主要内容

先删默认值,再谈换大模型

原石
原石

· 阅读约 4 分钟

先贴表。

                    设置解析   窗口标注   会议召回   冷启动    内存    GPU占比
gemma4:e4b           9/10      97%       7/7      5.8s    3.3GB   100%
gemma4:26b          10/10      97%       7/7     64.7s   18.3GB    51%
qwen3.6:35b         10/10      92%       7/7     25.7s   23.3GB    41%

Break Buddy 作者自己跑的。Windows 桌面小工具,到点弹个像素小人,提醒你喝水、站起来、眼睛离开屏幕。三个模型,提示词、schema、规则层都是同一套。

4B 只错一条:“每 90 分钟走一走”,漏了。窗口标注 97%,跟 26B 打平。文案作者说持平或更好。会议召回三家全 7/7。

代价:3.3GB 对 18.3GB。5.8 秒冷启动对 64.7 秒。

别急着说“小模型真香”。这话说了等于没说。让 4B 够用的不是模型,是模型外面那一圈东西。那圈东西比模型选型重要十倍,大部分人根本不写。

第一个 bug 在 schema 里

用户写 sarcastic friend,存进去的是 friendly。

作者第一批代码大概长这样:

class Settings(BaseModel):
    water_minutes: int
    eye_minutes: int
    stretch_minutes: int
    tone: str = "friendly"      # 就是这一行

原因很朴素:这字段有默认值。小模型看见默认值,就照抄默认值,把那行自然语言指令当成可选的补充说明。

改成:

class Settings(BaseModel):
    water_minutes: int
    eye_minutes: int
    stretch_minutes: int
    tone: str                   # 必填,无默认值

再补一条 pirate voice → pirate 的示例。之后每次都对了。

大多数人调 LLM 的流程是:不对,改提示词;还不对,加“请务必”“你必须仔细分析”;还不对,换更大的模型。绕一圈回来,真正的问题在你的数据结构里——你亲手给它留了一条合法的偷懒路径。

提示词是软约束,schema 是硬约束。能上硬约束的,别用软约束。字段设成必填,比在提示词里写十行“请认真理解用户意图”管用。那十行还占 context window。

我在这上面栽过。话说得难听点:凡是你的输出契约允许模型不填某个字段,它就总有一天不填。

规则先跑,模型兜尾巴

会议检测那边,作者最早直接问模型:这个窗口标题是不是会议。

他拿一个叫 Zoom meeting.txt 的文件测过,模型正确地说不是。这事本来挺漂亮,结果他想明白——方向反了。

漏判一个真会议,代价是你在跟客户开会时屏幕角上蹦出个像素小人喊你喝水。多判一个假会议,代价是少提醒一次。这两个代价差一个数量级。

顺序倒过来:

标题命中 Zoom / Meet / Teams / Webex 固定规则
    → 判定为会议,不问模型
否则
    → 交给模型兜底

规则先跑。它确定,零延迟,不会因为显存不够或者温度抽风。模型只处理规则漏掉的那部分。日志里确实抓到过规则漏的:一个标题里带人名的 Zoom 窗口,匹配不到 Zoom Meeting 这串字,模型认出来了。

这才叫分层。便宜、确定的在前。贵、不确定的在后,只负责前面那层的尾巴。不是“用 AI 替代规则”,是“用 AI 补规则的洞”。反过来干的人我见太多了,写一堆正则嫌烦,直接上模型,然后开始给误报写补丁——那些补丁最后长得就像正则。

这方案也没全修干净。作者自己写了两个漏:Zoom Workplace 首页会被当成会议,整个首页期间都不提醒;通话刚开始那几秒的 Connecting… 窗口可能漏一条提醒。第二个是竞态,窗口标题在那几秒里还没稳下来。这段我没想出干净解法,作者也没有。

35B 那两条错,比它的准确率有意思

回来看表。

qwen3.6:35b:
  Copilot 窗口        → coding            (标错了)
  讽刺文案            → "I suppose someone has to remind you to stay alive today"
                                            (跟喝水没关系)

23.3GB 内存、25 秒冷启动,换来一条跑题的文案和一次窗口标错。

大模型的问题不是不准,是不稳定地准。它在 10 条设置里多救回来一条,然后在别的地方给你来一下,而且你没法预测是哪一下。对一个每 20 分钟弹一次、一天跑几十次的东西,“偶尔抽风”比“一直差一点”难处理得多。差一点你能靠重试和规则兜住;抽风你得猜。

还有那个 GPU 占比:100%、51%、41%。35B 只有四成塞进显存,剩下六成在内存和 CPU 之间来回搬。对一个开机自启、全天常驻的托盘应用,这个数字比准确率更致命。而你在任何闭源 API 上永远看不到这个数字。

说句题外话,这 3.3GB 花在哪了

设定解析可以不用模型,写个配置文件就行。窗口分类大部分被规则覆盖了。

原石
原石

把代码当文章写的系统工程师,以源码立论、单线程式拒绝复杂度。

查看主页 →