ej

我构建 ej，是因为我想看看一个非常小的决策模型在不隐藏权衡的前提下能走多远。

通往那里的路并非一帆风顺：

🔀 它最初是用 Rust 写的。第一个版本是 Rust 引擎。在开发过程中，研究迭代的需求渐渐超出了 Rust 的承载能力，ej 由此转向 Python。事实证明，能够快速迭代比我最初选用的语言更重要。

📦 "11 MB" 起初是一个谎言。早期的 11 MB 只是参数的位级计数，实际下载到的文件远比这大得多。所以我编写了自己的压缩打包格式，让这个数字名副其实。如今它就是一个 11,384,312 字节的文件，不含任何 pickle 序列化文件，且每一段都带有 SHA-256 校验。

⚖️ 一次许可证核查让我回到了起点。项目后期，一个训练数据集被证明不可商用。我移除了它，重新训练了编码器并重构了整个模型。一些准确率因此损失了，但这是值得的。

🎯 我设定了目标，却没有达成。我瞄准的是 ej 从未见过的流程上 60% 的准确率，诚实的实测结果大约只有 42%，这也是我向所有人首先指出的数字。

🧪 我最好的想法也没能通过自己的测试。一个同时读取文本和选项的小模型，在全精度下表现亮眼。但量化压缩以适配体积后，其提升幅度跌落到了我预先设定的门槛之下，所以我最终放弃了它。在我对每个想法反复训练多次后发现，几个其他"改进"所带来的提升同样落在逐次运行的噪声范围内，因此也被一并舍弃。

大量真正的工作其实是那些不显眼的环节：模型打包、确定性推理、离线加载、对每个测试套件实测校准度（而不是空口承诺），以及一个可以清晰看到数据污染与不确定性的基准测试。

结果在某些场景下有用，在另一些场景下明显薄弱，尤其是在未见过的流程上。我努力让这些局限易于检查，而不是将其粉饰过去。

我特别想听到两方面的反馈：基准测试的设计，以及当前的体积／精度权衡在实际系统中是否实用。