企业官网建设流程全解析

NanoJev决策输入契约入门：状态、问题与候选三步指南，让0.6B模型直接输出概率

【免费下载链接】NanoJevA nano replica of Jev: parallel decisions, dynamic candidates, and an end-to-end training pipeline.项目地址: https://gitcode.com/gh_mirrors/na/NanoJev

NanoJev 是一个 0.6B 参数的并行决策模型，其核心是一套简洁的"三步决策语言"：状态（State）、问题（Question）、候选（Candidates）。理解这套输入契约，你只需三行概念——模型不生成任何文字答案，而是针对你给定的候选集合，直接返回完整的概率分布。下面用最少的文字讲清楚这套契约的设计、三类问题类型，以及它在迷宫、贪吃蛇和射击游戏中的实际应用。

为什么需要"三步决策语言"

传统大语言模型回答决策问题时，需要生成"向左走"这样的文字 token，再靠解析器还原意图，既慢又容易出错。NanoJev 换了个思路：

每个请求都遵循同一个三段式结构，这正是 NanoJev 的输入契约：

1. 状态（State）：共享的评估上下文，通常是当前游戏局面描述（文本或 JSON）。
2. 问题（Question）：要判断的具体命题或选择，指令必须完整自包含。
3. 候选（Candidates）：该问题的选项集合，模型在其上输出概率分布。

上图展示了三个模型在同一个 50×50 迷宫中按环境步同步探索：每一栏的 "Last decision" 区域就是候选输入契约的直观体现——当前状态下的四个候选方向（↑N / →E / ↓S / ←W），每个候选给出一个独立的安全概率。

三类问题类型：Boolean、Choice 与 Score

NanoJev 的决策头支持三种问题类型，分别对应不同的概率输出方式。完整定义见 docs/TYPESAFE_CONTRACT.md。

Boolean：命题成立概率

给定一个命题（如"向北移动一格是否安全"），模型输出p_true，即命题成立的概率，内部经过 sigmoid 得到。适合判断类问题：这一步会不会撞墙、这个动作会不会失败。

Choice：候选集合上的分布

这是游戏中最常用的类型。你提供2 到 255 个文本候选（例如 4 个移动方向），模型通过共享评分头 + 集合注意力 + softmax，返回每个候选的完整归一化分布。注意两个细节：

• 候选数量是动态的：不同状态可提供的候选数不同，无需凑齐固定动作空间。
• 名称与描述都是语义输入：叶子节点编码为选项名: 描述，重新排序候选不会改变各自的叶子输入。

Score：有序等级的期望值

提供2 到 10 个有序描述等级，每个等级独立评估，返回概率加权的等级指数。例如把"距离目标的远近"分成若干等级，模型直接给出期望值。

上图是一个具体案例：同一个 4×4 小网格状态，NanoJev 用 2 步就到达目标，未微调的 Qwen 则耗尽 32 步上限。区别正来自同一份"状态 + 问题 + 候选"输入，不同模型给出的候选分布质量不同。

一个完整的输入示例

以迷宫任务为例，模型每个状态看到的输入极其克制。参考 docs/ATOMIC_PLANNING.md，输入只包含：

• 以玩家为中心的5×5 ASCII 视野窗口
• 当前位置与目标坐标
• 四个独立的 Boolean 问题：北/东/南/西各一步是否可行

而最短路径动作、路线长度、oracle 标签统统不在输入里。这种"原子判断 + 代码规划"的分工是 NanoJev 的关键设计：模型只做局部几何判断，路径组合交给代码。

在 ViZDoom 射击任务中，输入契约同样成立：状态包含可见物体标签、玩家血量/弹药/朝向和最近 4 帧；候选固定为 4 个动作（left / right / shoot / noop）。每个候选还会被问一个独立的 Boolean 问题——"执行这个动作后任务能成功吗"。这些独立概率不做归一化，用于 Q 值式控制。环境契约细节见 docs/UNIFIED_GAMES.md。

契约的三个关键设计原则

理解契约后，有三条设计原则值得新手记住：

1. 问题彼此独立。同一状态下的多个问题共享状态，但不消费彼此的答案；有依赖的判断需要发起后续请求。前向计算中没有跨问题注意力，这保证了批量并行的正确性。

2. 标识符不进入模型输入。请求的id和qid只用于标识响应，不出现在模型输入 token 里——重命名它们不会改变任何候选路径，也就不会改变输出。

3. 指令必须自包含。完整的判断信息必须在问题指令中写清楚，不能依赖外部描述。Score 的每个等级描述必须独立可读，移动一个等级描述会改变其索引而非叶子输入。

这些契约都有离线测试保障：scripts/test_question_contract.py 覆盖传输 ID 不变性、问题隔离、Boolean 边界条件、Choice 名称/描述、Score 索引排除等场景，且无需加载模型或联网即可运行：

python3 -m unittest discover -s scripts -p test_question_contract.py -v

三步上手：从契约到推理服务

第一步：准备输入。把局面写成文本状态，把要判断的命题写成问题，把选项列为候选。参考数据集结构见 configs/unified_games_v1_cases.jsonl。

第二步：启动推理服务。模型只加载一次，状态/问题批次通过POST /api/evaluate发送：

python scripts/serve_decisions.py \ --checkpoint-dir checkpoints/NanoJev-unified \ --web-root web --port 8765 --disable-native-triton

服务脚本位于 scripts/serve_decisions.py。

第三步：消费概率。拿到完整分布后，按你的策略排序、贪心选择或采样——全程不生成任何答案 token。

小结：一套契约，四种游戏

NanoJev 用一个 Qwen3-0.6B 底座加决策头，用同一套"状态、问题、候选"契约驱动了 4 款游戏、每版本 18,760 条决策问题。对新手来说，掌握这套三步契约只需要记住一句话：把决策问题翻译成"我处于什么状态、我要判断什么、有哪些选项"，剩下的概率交给模型。

更多延伸资料：

• 输入契约审计：docs/TYPESAFE_CONTRACT.md
• 统一游戏环境与观察契约：docs/UNIFIED_GAMES.md
• 原子迷宫判断与代码规划：docs/ATOMIC_PLANNING.md
• 项目主文档：README.md

【免费下载链接】NanoJevA nano replica of Jev: parallel decisions, dynamic candidates, and an end-to-end training pipeline.项目地址: https://gitcode.com/gh_mirrors/na/NanoJev