Jeva：System One Models 的第一性原理拆解

接到这个项目的时候，我心里第一反应是：又一个要把“快思考”做进系统里的尝试。但你真正从第一性原理去推演“System One Models”该长什么样，而不是直接套一个大模型做蒸馏、做加速推理的时候，你会发现整个思路完全不一样。Jeva 这个项目，本质上就是回答一个问题：如果抛开所有现成的预训练权重、抛开庞大的 Transformer 架构，我们能不能用最朴素的数学工具，从零构建一个具备“System One”行为特征的推理内核？

这篇文章会把我的完整设计思路、核心模块拆解、实操过程、踩坑记录全部写出来。如果你正在做轻量级模型、边缘端推理，或者对认知科学与工程实现的交叉点感兴趣，这篇内容应该能给你一些不一样的参考。

1. 项目定位与整体设计思路拆解

1.1 为什么选择从第一性原理构建 System One

“System One”这个概念借自认知科学，指的是人脑中快速、直觉、几乎无意识的那套判断系统。对应到产品场景里，就是那种不需要长时间思考、看到输入立刻给出响应的能力——比如对话系统里的快速前置判断、智能客服的路径推荐、IDE 里的代码补全首选项。它与 System Two（慢思考、深度推理）最大的区别在于：快、省、高并发，但也要求模式匹配能力强。

一开始团队讨论过两种路线。一种是直接拿开源大模型做量化蒸馏，剪枝到能在边缘设备上跑；另一种就是 Jeva 现在走的路——根本不依赖 Transformer。为什么？因为“蒸馏出来的小模型”本质上是别人思考结果的压缩，你无法逐行解释它为什么在这个输入下给出这个输出，这种黑盒特征在“System One”这种要高频介入业务决策的场景下是致命的。你没法向客户解释为什么某个问法会被误判，更没法在线上快速修复某个特定分支的错误。

从第一性原理推导，一个真正的 System One 内核只需要满足三个约束：计算路径短、决策可解释、状态可回滚。这三条约束直接排除了基于深度学习的方案——倒不是因为精度不够，而是因为工程上无法满足“状态可回滚”。你不可能让一个 Transformer 在线上回滚到某个用户某个时刻的某个决策状态。但如果你用显式的概率模型、索引结构和规则策略组合来实现，这个目标就完全可行。

1.2 我选择的系统架构与技术路线

Jeva 的整体架构最终被拆成了四个相对独立却紧密配合的模块：感知接口、决策单元、联想记忆索引、置信度仲裁器。这个拆分不是拍脑袋设计的，它是从约束条件倒推出来的。

感知接口负责把不可控的原始输入变成可控的特征向量。决策单元负责在特征空间内给出候选决策及置信度。联想记忆索引让系统具备“见过的场景快速命中”的能力，这部分对应认知科学里 System One 的模式匹配直觉。置信度仲裁器像一位旁观者，它盯住决策单元的输出，一旦置信度低于阈值，就把控制权交还给上层的 System Two（通常是一个更重型的模型或人工客服）。

这套架构最大的特点是模块之间没有深度耦合。你可以用最简单的逻辑回归作为决策单元，也可以用带核函数的在线学习器；记忆索引可以是一个局部敏感哈希表，也可以是 Redis 里的一个有序集合。每一块都能独立替换、独立测试、独立上线。这种设计带来的维护成本优势在项目后面两个月会越来越明显，坏一个模块不影响全局，升级一个模块不需要停机。

技术路线上，Jeva 拒绝引入超过一万行代码的第三方依赖。核心决策代码加起来不到两千行，所有依赖项加起来只有六个轻量级库。这不是为了炫技，而是为了保证“任何一个人在一个下午内可以把整个系统读透”——这本身就是第一性原理的一部分：系统的复杂度必须与团队的理解能力匹配。

2. 核心模块设计与关键参数解析

2.1 感知接口：从不可控文本到稀疏特征

感知接口是整条链路的起点，也是最容易被低估的一个环节。很多人觉得特征工程是上个时代的东西，但当你面对海量、嘈杂、不断演化的输入文本时，特征工程依然是最稳的立足点。

我在 Jeva 里采用的方案是混合特征管道：先做文本清洗（大小写归一、特殊符号剥离、简繁体映射），然后同时提取三种特征——N-gram 字面特征、语义角色特征（手工定义的几十种意图模板）、统计特征（长度、标点密度、关键词覆盖度）。三类特征拼接成稀疏向量后，再经过一个随机投影层降维到固定维度。这里有个参数值得注意：N-gram 范围我选了 1-gram 到 3-gram，没有 4-gram。原因是 4-gram 的特征空间膨胀速度太快，而它对短文本分类的边际收益几乎为零。实测数据表明，3-gram 到 4-gram 的准确率提升不到 0.5%，但特征维度从 20 万涨到 180 万，存储和计算成本却翻了四倍以上——这个性价比完全不合算。

随机投影层的维度我通过实验确定为 256 维。太低（64 维）会导致不同语义的向量碰撞严重，太高（1024 维）则没有额外收益。投影矩阵一经初始化就不再改变，这样可以保证同一输入在任何时刻得到的特征向量完全一致。

2.2 决策单元：上下文多臂老虎机的玩法

决策单元是 System One 内核的“脑干”。Jeva 没有选用传统分类模型，而是把它设计成一个上下文多臂老虎机（Contextual Bandit）的变体。通俗讲，就是系统把每一次决策当作一次“选择哪个动作能获得最大回报”的博弈。

具体实现是：每个候选动作对应一个线性收益函数，输入特征向量通过内积计算每个动作的预估收益，然后通过 Softmax 选择最终动作——但注意，这个 Softmax 的温度参数直接控制系统的“探索”和“利用”平衡。温度高，系统更愿意尝试不常选的动作；温度低，系统更倾向于选收益预估最高的动作。在 Jeva 里，我把它设置为 1.5。这个数值跑下来是最平衡的：既有足够的探索能力去发现新输入模式，又不会因为过度随机让用户感觉到系统“不稳定”。

但好处不止于此。在线学习场景下，每个动作的收益函数会收到来自反馈回路的梯度信号，通过在线梯度上升来更新参数。这意味着 Jeva 可以在不重新训练、不卸载服务的情况下，实时学习用户的反馈模式。我保留了每个动作的收益函数参数快照，一旦某个动作的表现断崖式下跌，可以立即进行参数回滚到某个历史版本。

2.3 联想记忆索引：用 LSH 做快速命中

如果决策单元是脑干，那么联想记忆索引就是 System One 的“长期记忆”。认知科学里，System One 的最大特征就是能快速联想到“这个场景我见过”，然后直接调用旧结论——Jeva 用局部敏感哈希（LSH）实现这个机制。

LSH 的核心思想是：相近的向量经过哈希后大概率落入同一个桶。Jeva 在感知接口得到 256 维特征向量之后，会同时走两条路——一条直接送进决策单元做在线推理，另一条送进 LSH 索引做前向查找。如果索引命中了一个历史场景（通常是一个带标签的经验记录），这个经验会作为一个强先验加入到决策单元的收益预估里。

LSH 的桶数量我设置为 64 个，每个桶内保留最近的 128 条经验记录。这样设计的好处是内存占用极低（总共 8192 条记录上限），同时命中率在实际业务数据上达到 68% 以上。没命中的场景会走回普通推理路径，并把该场景的信息异步写入索引。

这个索引的更新不是即时的。如果要保证强一致性，每条经验写入都需要加锁，高并发下会成为瓶颈。Jeva 的做法是写入先到内存队列，由后台线程每 200 毫秒批量刷新一次。这意味着索引最终一致性延迟为 200 毫秒——在 System One 这种高频响应场景下完全够用。

2.4 置信度评估与 System Two 仲裁机制

置信度评估模块在所有组件中地位最特殊——它决定了一套轻量级系统如何在一个重型生态里找到自己的位置。

Jeva 使用一个三层置信度评估方案。第一层是收益函数的间隔，即最高收益与次高收益的差值；第二层是历史命中反馈，即过去 20 次选择同一动作的平均回报率；第三层是特征覆盖度，即当前输入特征在历史样本空间中的密度。三个信号加权合成最终的置信度分数。

这个置信度分数的意义不是给用户看的，而是给系统自己看的。一旦置信度低于 0.55，Jeva 就会把请求转交到 System Two（上游的一个重型对话平台或人工客服系统），并且附上自己在当前输入上提取到的特征和推理过程摘要。这个设计让 System Two 的介入不是“黑盒转黑盒”，而是有上下文、有线索的智能升级。

3. 从零实现 Jeva 的实操过程

3.1 依赖选择与项目骨架搭建

依赖选择上，Jeva 只用了六个库：NumPy 做矩阵运算、scikit-learn 仅用它的 LSH 实现、Flask 做轻量级推理服务接口、Redis 做经验记录持久化和缓存、gunicorn 做服务部署、pytest 做测试。没有引入任何深度学习框架，也没有引入消息队列和重型注册中心。

理由很简单：对于两千行核心代码的规模，引入重型框架就是纯粹的负担。你花在部署、配置、调参上的时间会超过写核心逻辑的时间。更重要的是，团队里的新成员在一周内就能完全看懂整个代码库，这在“System One 模型要鼓励高频迭代”这个前提下，比任何花哨的技术栈都有价值。

项目骨架我按功能模块分包：

• percept/：感知接口与特征工程
• decision/：决策单元与在线学习器
• memory/：联想记忆索引与经验存储
• confidence/：置信度评估与仲裁
• server/：Flask 推理服务
• tests/：单元与集成测试

每个模块的对外接口保持简洁——感知模块只暴露featurize(text) -> np.ndarray，决策模块只暴露predict(feature_vector) -> action，记忆模块只暴露save_experience(exp)和query_experience(feature_vector) -> optional[exp]。这样模块之间可以完全独立测试和替换，整个系统的依赖方向是单向的：server 依赖其余全部，置信度依赖决策和感知，决策依赖感知和记忆。

3.2 决策单元的训练与上线流程

决策单元的训练比较直白：先离线收集一批带标注样本，做特征提取，初始化每个动作的收益函数参数为零向量，然后用离线样本跑 20 轮在线学习预训练，让参数收敛到一个合理的初始状态。这里我个人强烈建议不要直接随机初始化然后上线，除非你的系统有极强的探索能力。否则冷启动阶段用户会体验到大量无意义的随机行为。

预训练结束后的上线流程分为三步。第一步，把预训练参数写入 Redis 的模型参数表；第二步，启动一个 shadow 实例，复制线上流量但只记录输出而不影响线上行为；第三步，shadow 实例的离线评估指标（准确率、置信度分布、转交率）达到线上实例的 95% 以上后，通过蓝绿部署切换流量。整个过程不需要停机，也不需要同步训练资源。

核心推理流程的伪代码如下：

def system_one_handle(text: str) -> dict: # 1. 感知模块 feature_vec = percept.featurize(text) # 2. 联想记忆查询（快速命中） memory_hit = memory.query_experience(feature_vec) # 3. 决策单元计算收益 scores = decision.evaluate(feature_vec, memory_hit) # 4. 置信度评估 conf = confidence.compute(feature_vec, scores, memory_hit) if conf < CONFIDENCE_THRESHOLD: # 低于阈值转交 System Two return escalate_to_system_two(text, feature_vec, scores) return finalize_action(decision.select_action(scores))

调用一次完整推理的实测延迟平均为 3.2 毫秒，其中特征提取占到 1.8 毫秒，决策单元耗时约 1.1 毫秒，记忆查询和置信度计算不到 0.3 毫秒。单核 CPU 上可以稳定支撑到 1200 QPS，四核实例跑到 4000 QPS 以上。

3.3 性能实测数据与效果调优

Jeva 在一批模拟业务数据（约 5 万条弹层对话场景）上做了离线评估。准确率 91.4%，Top-3 召回率达到 98.2%，平均置信度 0.74，低于阈值的转交率为 11.6%。这个转交率不算低，但在 System One 的设计语境下完全合理——把不确定的输出去交给更重的系统处理，本来就是设计目标之一。

实际调优过程中，有三个参数值得反复调试。第一个是 Softmax 温度。温度从 0.5 调到 3.0，冷启动期的用户满意率会显著不同——温度太低时，新场景没有探索机会，用户会感受到系统“固执”；温度太高时，用户会发现系统时灵时不灵。第二个是置信度阈值。阈值设在 0.5 时转交率高达 28%，设为 0.7 时降低到 8%，但准确率只有 86%。最终通过网格搜索确定 0.55 是兼顾准确率和在端率的最佳点。第三个是 LSH 经验记录的保留数量。128 条每桶看起来不多，但加上桶内最近命中替换策略后，系统对高频会话模式的响应速度最快能提升 40%。

4. 常见问题与排查技巧实录

4.1 问题速查表：直接看这一版

这里把我在 Jeva 项目里遇到的高频问题整理成表格，每条都是实际操作中踩过验证过的。

4.2 三个最隐蔽的坑

第一个坑是稀疏特征向量的缩放问题。这个问题不暴露在准确率上，而是藏在你的 LSH 索引命中率里。N-gram 特征稀疏度非常高，不同文本的特征向量模长差异可能达到一个数量级。直接拿原始特征向量做内积或 LSH 距离计算，会让高模长的向量主导相似度判断，从而让有些明明语义高度相似的文本被判为完全不同的模式。解决方式是特征向量在做内积前统一做 L2 归一化，LSH 哈希使用的是归一化后的向量。这个改动让 Jeva 的 LSH 命中率直接从 55% 拉到了 68%。

第二个坑是线上反馈回路导致决策单元参数发散。在线学习场景下，系统根据用户反馈更新收益函数参数，但用户的反馈本身带有滞后性和噪声。如果你不加约束，某些动作的参数会漂移到极端值，导致该动作被永久性过度选择。我在决策单元里加了一个参数范数上限，每个动作的参数向量一旦超过预设范数就做等比缩放，实测下来系统稳定性提升非常明显。

第三个坑是联调测试时忽略的时序问题。LSH 索引的异步写入机制意味着刚发生的一条经验不会立刻对下一次推理生效。我一开始在测试用例里模拟了这个延迟，结果发现线上偶尔出现“上一个用户的行为影响不到当下这个用户”的体验落差。后来把经验写入解耦成一个独立事件流，并在每条经验打上时间戳，让置信度模块可以感知到经验是“刚刚”还是“一分钟前”的，促进更合理的先验加权。

5. 测试策略与后续扩展方向

5.1 测试策略：用特性矩阵做回归守护

Jeva 因为是模块化架构，测试策略也做了分层设计。单元测试覆盖每个模块的边界条件和极端输入——空字符串、全标点、超长文本、混合语言文本；集成测试则重点验证模块之间的交互流程，比如感知模块输出的向量能正确进入决策单元，记忆查询结果能被正确注入收益计算。

最重要的一层是回归测试。我建立了一张“特性矩阵”表，每个特性（某种特定语气的 query、某种特定长度范围的输入、某种特定业务领域的问法）对应一组输入样本和一个期望行为。每次代码变更后，这组回归测试会全量跑一遍。因为 Jeva 的决策路径是可解释的，所以回归测试不仅能验证“最终的输出对不对”，还能验证“中间特征是否符合预期”——比如某个模板文本应该产生哪个特征组合、LSH 命中的应该是哪个桶，这些都能被显式断言。

这套测试体系让 Jeva 在后期每两周一次迭代的情况下，线上回归事故为零。对于 System One 这种高频介入业务决策的系统来说，测试守护不是质量保障，是生存底线。

5.2 算力消耗与未来可插拔方向

Jeva 的算力消耗极其克制。离线预训练在普通 CPU 实例上 30 分钟内完成，在线推理单请求平均 3.2 毫秒，内存占用稳定在 500MB 以内。即便在最廉价的边缘实例上也能流畅运行，这让它可以直接被嵌入到对话网关、边缘计算节点甚至嵌入式设备里做第一道过滤。

从扩展方向看，Jeva 的模块化设计预留了丰富的可能性。比如决策单元可以从线性模型替换成带核方法的在线学习器，用于捕捉非线性决策边界；联想记忆索引可以对接外部知识库，实现记忆不再是用户经验而是“领域知识”；置信度模块也可以增加一个元学习器，让转交给 System Two 的决策更智能，甚至可以给 System Two 返回一个带排序的候选集。因为所有模块接口都足够干净，这些升级不会伤筋动骨。

在做 Jeva 的过程中，我体会最深的一点是：构建一个可解释的 System One 模型，最重要的不是算法有多高级，而是你能不能把“快思考”这件事拆成一个个可以独立理解、独立验证、独立维护的组件。第一性原理在这里的意义，是逼着你把“系统应该怎么做”重新推导一遍，而不是被现成的模型框架绑架。

Jeva 的完整代码和设计文档已经整理好放在项目库里，如果你想把它用到自己的生产环境或者改造它来适配业务，最稳妥的路径是按照我上面说的测试策略先跑通一套回归基线。这个项目的全部价值就在于——你改得动它，你修得好它，你解释得清它。