实践 001:中文提问分流的评估基线
状态:规则基线已在本地复现;Jev 对照尚未运行。 本期不需要 API 密钥,不发送网络请求。数据、评估脚本和全部输出均可查看。
我们想回答一个具体问题:开发者在社区提问时,如何把问题分到“环境接入”“故障反馈”“概念文档”,并在信息不足时先澄清?在接入模型前,先建立一个可以比较、可以发现错误的小实验。
数据与判定标准
跳转到“数据与判定标准”这 16 条提问由 JevCN 为教学原创编写,不来自聊天记录或私人业务。预期标签由作者按下列规则指定,尚未经过独立多人标注。
| 标签 | 判定标准 |
|---|---|
| 环境接入 | 明确询问安装、凭据或首次接入步骤 |
| 故障反馈 | 明确报告运行异常并寻求排查 |
| 概念文档 | 询问概念含义、机制或文档位置 |
| 需要澄清 | 信息不足、无具体任务,或多个诉求无法确定优先级 |
样例包含直接表达、否定、中英混写、同义表达和多意图。它们是教学挑战集,与规则同时设计,不是独立留出的测试集;结果不能代表真实社区的准确率。
在本地复现
跳转到“在本地复现”准备 Node.js 22.12.0 或更高的 22.x 版本,在 JevCN 仓库根目录执行。脚本只使用 Node 内置模块,无需安装额外依赖。
node examples/chinese-routing/evaluate.mjsnode --test examples/chinese-routing/evaluate.test.mjs第一条命令生成 examples/chinese-routing/baseline-report.json,第二条检查评估器对缺失、失败、重复 ID 和无效标签的处理。报告记录数据版本和 SHA-256,便于确认比较时使用同一份样例。
关键词规则按顺序判断:出现“安装 / API key / 环境”归入环境接入;否则出现“报错 / 错误”归入故障反馈;否则出现“文档 / 概念”归入概念文档;其余需要澄清。
本次实际结果
跳转到“本次实际结果”复现日期:2026-09-21。下表直接读取仓库中生成的报告,避免手写数字与实际输出不一致。
本地规则结果:9 / 16,准确率 56.25%。 请求失败或缺失:0。这是关键词规则的教学样例结果,不是 Jev 成绩。
| ID | 输入 | 预期 | 规则输出 | 结果 |
|---|---|---|---|---|
| 01 | 安装 Node 后怎么启动本地文档? | 环境接入 | 环境接入 | 正确 |
| 02 | API key 要放在哪里? | 环境接入 | 环境接入 | 正确 |
| 03 | 构建报错了,日志提示找不到模块。 | 故障反馈 | 故障反馈 | 正确 |
| 04 | 运行示例时出现错误,应该如何排查? | 故障反馈 | 故障反馈 | 正确 |
| 05 | Choice 的概念是什么? | 概念文档 | 概念文档 | 正确 |
| 06 | 哪里能看到 Noul 的文档? | 概念文档 | 概念文档 | 正确 |
| 07 | 你好,想和大家交流一下。 | 需要澄清 | 需要澄清 | 正确 |
| 08 | 可以帮我看看吗? | 需要澄清 | 需要澄清 | 正确 |
| 09 | 不是安装问题,是运行时一直报错。 | 故障反馈 | 环境接入 | 误判 |
| 10 | 没有报错,我只想了解 Choice 的概念。 | 概念文档 | 故障反馈 | 误判 |
| 11 | Where should I set the API key,本地环境怎么配? | 环境接入 | 环境接入 | 正确 |
| 12 | build failed,提示 module not found。 | 故障反馈 | 需要澄清 | 误判 |
| 13 | 第一次用这个 SDK,怎样把它接进项目? | 环境接入 | 需要澄清 | 误判 |
| 14 | 程序直接退出了,终端什么也没留下。 | 故障反馈 | 需要澄清 | 误判 |
| 15 | 安装与运行报错都想问,先从哪一个说起? | 需要澄清 | 环境接入 | 误判 |
| 16 | What does Choice mean,能解释一下吗? | 概念文档 | 需要澄清 | 误判 |
失败比总分更值得读
跳转到“失败比总分更值得读”- 否定范围: 09 的“不是安装问题”仍命中安装关键词;10 的“没有报错”仍被分到故障反馈。
- 同义与中英混写: 12 的
build failed、14 的“程序直接退出”和 16 的What does Choice mean未被规则理解。 - 首次接入: 13 在问 SDK 接入,但没有使用规则期待的词。
- 多意图: 15 同时提及安装和报错,规则直接选了第一个分支,没有按标注标准澄清。
这说明当前规则遗漏了这些表达。它并不能证明 Jev 一定能处理好,也不能证明模型比规则划算。官方的 Jev 1.13 局限说明同样提醒开发者明确标准并检验边界条件。
接入 Jev 后如何公平比较
跳转到“接入 Jev 后如何公平比较”本期没有提供未经运行验证的 API 封装。完成官方 SDK 接入后,可以将真实模型输出转换为以下文件格式,再交给同一个评估器:
{ "metadata": { "engine": "jev", "model": "填写响应中的实际模型版本", "sdkVersion": "填写实际版本", "runAt": "填写运行日期" }, "predictions": [ { "id": "01", "label": "环境接入" }, { "id": "02", "error": "timeout" } ]}以上仅为格式示意,不是模型返回。完整实验应覆盖全部 16 个 ID;缺失或执行失败仍计入总样本数,另行统计,不能丢掉后只算成功请求。
node examples/chinese-routing/evaluate.mjs /你的路径/predictions.json外部结果写入被 Git 忽略的 report.local.json,不会覆盖已发布的规则报告。先检查脱敏和来源,再通过 PR 分享。模型与规则都使用相同标签标准;模型请求仅包含提问和判定标准,不应包含 expected 答案。实验还应保存完整提示和原始响应,以便核对模型输出到标签的转换。
在这组样例上调好标准后,应另外准备独立样本,再衡量效果、延迟与成本。本页不报告模型延迟或成本,因为尚未调用模型。
代码与下一步
跳转到“代码与下一步”欢迎贡献新的否定、歧义与中英混写样例,并说明预期标签的理由。不同标注意见本身也是改进任务定义的材料。