已知弱点
每一条写明哪里会出错、影响有多大，以及能消除它的改法。测量对比的是 Valen 0.8B、2B、4B 与 JevalKit 榜单上其他 7 个 4B 及以下的决策模型（Intern-Decision 0.8B、2B、4B，StartLux v1.1 0.8B、2B、4B，Liquid d1 3B）的中位数，题目相同，2026 年 10 月。
state 里的规则表、长列表和算术
这个尺寸的决策模型（包括 Valen）只有在规则表或列表较短时，才能可靠地套用书面规则或找到某一条记录；规则表和列表一变长，准确率就迅速下降。组合数字在各个尺寸上都偏弱。
| 问题里的任务（ProceduralTypedDecisions） | Valen 0.8B / 2B / 4B | 其他 4B 及以下决策模型中位数 |
|---|---|---|
| 按规则表给工单分流：4–7 条规则，每条一个条件 | 77 / 76 / 97% | 87% |
| 8–13 条规则，每条最多两个条件 | 30 / 34 / 79% | 60% |
| 14–23 条规则，每条最多三个条件 | 15 / 17 / 63% | 36% |
| 36–58 条规则，每条最多四个条件 | 5 / 4 / 29% | 8% |
| 按 ID 找一条记录：列表不到 1,000 字符 | 93 / 92 / 97% | 96% |
| 1,000–4,000 字符 | 47 / 49 / 62% | 55% |
| 4,000–16,000 字符 | 33 / 34 / 40% | 38% |
| 对结构化记录套用书面规则 | 70 / 74 / 74% | 79% |
| 根据次数统计和互相矛盾的报告推断事实 | 59 / 56 / 62% | 69% |
| 组合数字：时长、余额、合计 | 46 / 49 / 57% | 62% |
规则、查找和算术交给代码。 只把代码做不了的判断交给 Valen，一个条件一个问题，再由代码组合答案。在 40 道有 8–13 条规则的分流题上，把规则放进 state、用一个 Choice 在各类别中选，Valen 4B 对 33 道、0.8B 对 8 道；改成每条规则一个 Noul、由代码取成立的那条，两个尺寸都是 40 道全对。
已记录的难点
| 情形 | 现象 | 改法 |
|---|---|---|
| Choice 的候选里没有正确类别 | 概率集中到最接近的候选上；改地址请求曾以 99.3% 被分到物流查询 | 加一个有描述的 none 候选并转人工（未知类别） |
| 结尾附一句通用的话（"请告诉我下一步怎么做。"） | 可能把范围外的消息又拉回某个范围内类别 | 在验证集里加入这类带后缀的变体；对必须人工处理的请求，再单独问一个 Noul（"客户要求修改收货地址"），由代码分流 |
| 只有一个候选的 Choice | 概率和置信度恒为 1 | 改用 Noul |
| Score 遇到两极分化的分布 | 期望下标落在两个峰之间 | 读各等级概率，或把维度拆成多个 Noul |
| 目标只占大图中的几个像素 | 问题通不过人类测试 | 发送前由代码围绕目标裁剪或缩放 |
| 用单帧给整段视频打标签 | 一帧只描述一个时刻 | 采样多帧，每个请求发一帧，在代码里对各候选的概率取平均；人数按单帧判断，不要跨帧相加（短视频标注） |
托管 API 的限制
托管 API 对每个请求的图片、问题、候选项和字符数都有上限（System One、Decisions），超出返回 HTTP 400。每个请求只收一张图，所以一次发多帧视频的集成每段视频都会失败；请每个请求发一帧，在代码里合并答案。
反馈新的情形
如果问题写得清楚、state 也完整，回答却明显错了，而且置信度很高，请在 Valen-Team/Valen 提 issue，附上请求内容、得到的回答和你期望的回答。
下一步：问题写法 · Agent skill