瓶颈在数据，不在参数
参数决定容量的上限，数据决定这些容量有没有被用上。 同样的参数量，喂什么、按什么顺序喂、怎么筛选，结果可以差出很远。
密度 ↑ · 冗余 ↓- 首页
- 研究
小模型研究
我们只研究一件事：在参数被严格限制的前提下，一个模型究竟能理解到什么程度。 参数变大、分数变高，是全世界都在走的路，不需要我们再走一遍。
研究 · 概览
研究对象小模型
三条路线数据密度 · 结构 · 受限生成
评测以难为尺 · 不刷榜
态度先列开放问题
01 / 我们的判断
三条判断，
写在方法之前。
判断先于实验。下面三句话是我们的出发点，也是我们衡量自己工作的尺子。
能被验证的才算能力
说得流畅不等于答得对，答得对也不等于稳定。 我们优先相信可以核对的东西：事实是否自相矛盾、格律是否成立、引用是否找得到出处。
可验证 · 可复现不刷榜，宁可测难的
一个分数如果只说明题目简单，那它衡量的不是模型。 我们宁愿在一个更小、更难的题集上，把失败的原因一条条写清楚。
少测 · 测难 · 写清失败
02 / 研究路线
三条路线。
一条管喂什么，一条管怎么长，一条管怎么被约束住。
01
数据密度
同样的参数，喂什么、怎么喂、按什么顺序喂。 我们关心的是单位参数承载的有效信息，而不是语料的体积。
同样的参数，喂什么、怎么喂、按什么顺序喂。 我们关心的是单位参数承载的有效信息，而不是语料的体积。
02
结构与训练方法
在固定预算下，哪些结构选择真的换来了能力， 哪些只是为了写进论文。能被消融实验复现的，才算数。
在固定预算下，哪些结构选择真的换来了能力， 哪些只是为了写进论文。能被消融实验复现的，才算数。
03
受限生成与格律约束
面向古体诗的生成：格律、平仄、韵脚与句数作为硬约束， 让模型在能被检查的边界内写，而不是自由发挥。
面向古体诗的生成：格律、平仄、韵脚与句数作为硬约束， 让模型在能被检查的边界内写，而不是自由发挥。
第三条路线是「何意味 HiWhy」的来源。我们把格律写成不可违反的规则， 而不是可以商量的建议：先保证写出来的是一首诗，再讨论它写得好不好。
03 / 评测原则
能被验证的，才有意义。
评测不是给模型发奖，是给自己找错。
评测我们只用两条标准：能不能验证，以及验证出来有没有用。 一个测不出来的指标，写得再漂亮也只是修辞。
所以我们宁可少测，也要测难的。常识问答、单轮指令跟随、模板化写作， 这类任务已经很难区分方法的好坏；我们更愿意把力气花在需要多步约束、 需要承认边界的问题上。
古体诗是我们用过最诚实的评测集之一：格律、平仄、韵脚、句数、字数全是硬约束， 对与错可以逐条核对，没有解释空间。它衡量不了全部能力， 但它很难被一段漂亮的话糊过去。
- 先定约束，再看表现：能自动验证的硬约束优先。
- 宁可少测、测难的，不做只涨名次不涨能力的题。
- 成功与失败一起看，坏例子不藏起来。
- 不为了榜单调格式、调提示词、调提交策略。
小模型是不是就是能力差？
不是同一件事。参数少，意味着单个参数的负担更重、能硬记的原始事实更少——这是限制。
但小模型换来的是速度、成本、可控和可部署。它做不了所有事，
在边界清楚的任务上可以做得足够好；真正的问题从来不是「小不小」，而是「用在哪」。
为什么不直接调 API？
因为我们要研究的是模型本身，不是编排。调 API 更容易得到好结果，
但学不到东西：数据怎么组织、结构怎么改、约束怎么加，这些问题的答案不在别人的接口里。
另外，很多场景并不需要最大的模型，只需要一个跑得动、说得清的模型。
你们怎么定义「小」？
我们没有给「小」划一条参数线。定义它的是使用方式：能在一台普通设备上跑起来、
能被一个人完整理解、能在真实场景里持续迭代，就算小。
按这个标准，有些名义上很小的模型并不小。
凭什么拿古体诗当评测？
因为它有可验证的部分。格律与平仄是形式化规则，可以逐句检查；
用典与意象可以人工核对；「像不像诗」才是主观的那部分。
只要一个任务里有可验证的成分，它就能用来比较方法，而不是比较宣传。
04 / 还没解决
还没解决的问题。
一个研究页面如果只有结论，那它更接近宣传。下面这些是我们目前答不上来的问题。
- 数据密度的上限在哪里？同样的方法换到别的语种、别的体裁， 结论还成立吗，还是只对中文古体诗成立？
- 小模型能不能稳定地承认「不知道」？现在我们只能用提示与后处理去逼近， 没有一个能保证的机制。
- 格律是硬的，诗意是软的。硬约束可以逐条验证， 好诗不能——评测要怎么覆盖后一半？
- 一个只做一件事的模型，和通用模型配合时该怎么分工？ 边界应该划在模型内部，还是划在调用它的系统里？