kev 初体验：决策模型和聊天大模型不是一回事
最近 TypeSafe 把 System One / Jev 推出来之后，决策模型这块突然热了一下。我也跟着把兼容同一套接口的 kev 跑通了，仓库在这：imyzt/kev-docker。
这是基于 Qwen 小模型的本地 demo，用来摸接口、看概率。和 TypeSafe 的 Jev 不是一个量级，属于玩一玩。
它解决什么问题
平时让大模型做「决策」，常见写法是：写 prompt → 让它吐 JSON → 自己 parse → 再分支。能跑，但有几个难受的点：
- 慢、贵，按 token 生成
- 字段可能编，JSON 还得兜底校验
- 真正想要的「每个选项的概率 / 置信度」，从大模型里拿得很别扭
System One 这类模型换了思路：不生成文本，只回答你预先定义好的题。输入是事实（state）和问题（questions），输出是选项和概率。代码里直接 if，不用先当散文读。
所以它和大模型不是替代关系。人要读内容，继续用大模型；代码要分支、路由、要不要升级，决策模型更合适。很多场景是先决策、再决定要不要打贵模型。
和 TypeSafe 的关系
TypeSafe 的 Jev 是托管产品，面向真实决策，还强调概率校准。
我这边的 kev：
- 接口兼容
POST /v1/systemone - 题型也是
choice/noul（是否）/score（量表） - 底座是 Qwen + LoRA，本地 CPU 就能玩
用途很明确：自己点点模板，理解这套请求长什么样、概率怎么变。要线上稳不稳、置信度能不能卡阈值，还是看 TypeSafe。
怎么玩
打开演示页后，左边选模板，中间改请求，右边看结果。
核心就两块：
- state：事实。一段话或 JSON 都行，尽量写可核对的信息，别写「用户可能挺着急」这种空话
- questions：一次可以问多个。比如工单该派哪个部门、要不要人工升级、客户有多生气
建议先点 in-domain 模板（银行意图、客服工单、点评这类），更接近训练分布。楼盘意向那些 experimental 的，当沙盒玩就行。
页面上有句话挺准：kev 是按 state 里的事实做一次决策，不会自己脑补。事实写清楚，大问题拆成几个小问题，结果会靠谱一些。
改 state 再跑一次，看概率怎么漂，比空想「模型懂不懂业务」直观得多。
总结
这次热的不是又一个小模型，而是「业务决策还要不要硬走聊天模型」这件事。
TypeSafe / Jev 是正经方向；我这个 Qwen kev 只是本地 demo，方便自己上手这套 API。