【免费下载链接】jevjevos: an open-source alternative to Jev and Microsoft-Decision-1. Yes/no decisions, choices and scores with probabilities, on your laptops CPU.项目地址https://gitcode.com/gh_mirrors/je/jev点击查看免费下载jevos 是一个跑在笔记本 CPU 上的开源 yes/no 判断模型28–130 ms 就能返回每个答案的概率。本文带你用 jevos 搭建一套自己的 LLM 评测体系从测试集构建、指标选择到把回归测试接进 CI 流水线的完整实战全程本地运行、无需 GPU、不产生任何按 token 计费的调用。为什么公开基准替代不了你自己的测试集现成的公开 benchmark 回答不了你真正关心的问题它们不是你的文本工单、邮件、日志也不是你的问题训练数据可能已经见过它们benchmark contamination分数会虚高即使自己拆数据如果拆出的部分和调参用的数据来自同一批结论同样失真。jev 团队自己的测量里held-out 基准给出 0.855而全新问题只有 0.757。所以正确姿势是用约一百条自己业务的真实用例构建一个永不用于调参的测试集。这正是 building a yes/no test set 给出的方法。把 jevos 当作免费的本地 LLM 评委评测需要一个评委模型。传统做法是调付费 API 上的大模型当 judgejevOS 的做法是把评委也放到本地一次请求可针对同一段文本问多个 yes/no 问题最多 1,024 个共享的 state 只读一次每个问题返回P(yes) 概率而不只是一个标签——概率让阈值、警告带、校准分析成为可能jev decide可以不起服务直接回答一个请求文件--output写结果文件且从不覆盖已有文件测试结果不会被悄悄替换非法请求打印错误并以退出码 1 结束天然适合脚本和 CI。上图是 jevos 的 Dino 游戏演示每一帧把游戏状态作为 JSON state 发给模型两个 yes/no 问题各拿到一个 P(yes)25% 和 28%恐龙据此跳或蹲——每步 136 ms纯 CPU。评委的身份也可以验证GET /health会返回模型文件的 SHA-256 和指纹仓库自带的 tests/check.py 就包含这一步check_health确保 CI 里跑的评委和你以为的是同一个。构建 LLM 测试集一百条真实用例怎么来用例来源随机采样 刻意刁难从日志、工单、邮件里随机抽样本——别挑你印象深刻的案例那些恰好是例外手工补充一批硬用例依赖否定词的输入、缺少关键信息的输入、依赖数字/日期的输入、混合两个主题的输入两类用例分开打标随机样本代表生产真实分布硬用例暴露模型的薄弱点。⚠️ 注意分享前先抹掉个人数据。模型可以本地但测试集最终总会进仓库和工单系统。一条测试用例的标准格式每条用例一个问题、一个人工确定的答案、一个推理类型标签另附一个note记录当时为什么这么判{id: t042-q3, state: {customer_message: The box arrived empty. This is the second time!}, question: Does the customer say an item was missing?, answer: yes, kind: paraphrase, source: random, note: empty box counts as missing}同一个文本可以挂多个问题——本地模型一次读完 state多问几个几乎不增加成本。平衡、标注与 kind 标签正负平衡约一半 yes、一半 no。平衡集能公平暴露模型偏向 yes的倾向jev 团队 999 条手写问题里错判的 yes 有 152 个、no 只有 91 个如果你的业务里 yes 只有 3%再用真实比例折算精确率。两人独立标注先标 30–50 条逐条看分歧——分歧多半是问题本身有歧义要改问题而不只是改标签拿不准的样本允许cannot tell直接从 yes/no 测试中剔除。每个用例打 kind 标签stated fact、paraphrase、tone、intent、negation、not stated、rule、number、date、arithmetic 共 10 类每类都有一行判据见 accuracy by kind of question。一个需要两步推理的问题按最难的那一步打标签。用代码批量生成测试问题人工标注最弱的地方恰恰是代码最擅长的地方数字、日期、阈值。思路很简单——写一个小程序用模板生成文本同时记录塞进去的数值答案由代码从同一批数值算出天然没有标注错误。生成器还有三个关键技巧完整做法见 generating test questions with code刻意制造边界用例总额恰好等于阈值、离阈值 1 欧元之内的样本看错误是否聚集在边界加干扰项塞入与问题无关的费用、日期、第二个客户的订单别让文中唯一的数字总是相关数字固定随机种子并把生成器版本、种子、模型文件哈希一起记录保证结果可复现。要诚实面对生成集的偏差模板文本比真实邮件干净。jev 的测量里数字对阈值类问题在生成集上 0.85、在手写集上只有 0.654——所以生成集用来撑规模和保证答案正确人工集用来保证真实覆盖两者分列报告不要平均。评测指标别只看一个准确率在 jev 团队的 999 条手写问题上第一代 jevos 整体准确率 0.757但拆开看stated fact 0.954arithmetic 只有 0.584jevos-v4 整体 78.9%。一个数字掩盖了全部失败模式。建议每次评测至少报告四样东西你想知道的问题报告的指标整体答对多少accuracy模型说 yes 时能否直接行动precision阈值处该抓的 case 抓到了多少recall阈值处哪类问题能信、哪类不能信按 kind 拆分的 accuracy它错的方向wrong yes vs wrong no 计数0.8 能不能读作约八成把握校准误差 / 置信度上面是官方发布时给出的基准同一批问题、同一个 HTTP 客户端左图是短/长请求的中位延迟右图是 6 个任务上的准确率——其中 5 个任务参与过 checkpoint 选择1 个完全 held-out这正是测试集永不用于调参的范例。还有一个常被忽略的指标模型知不知道自己不知道。对文本缺少关键事实这类不可回答的问题jevOS 用置信度区分可回答/不可回答的 AUROC 如下最后提醒100 条用例的准确率大约带 ±8 个点的误差30 条的 kind 只能读出高/低读不出第二位小数。小集合上的数字记得带误差区间。指标定义与推导见 evaluation metrics for yes/no classifiers。CI 回归测试实战让构建在回归时变红测试集告诉你系统现在好不好CI 回归测试告诉你它是不是变坏了。jevos 让这件事可以在普通 CPU runner 上完成。文件布局request expect 分离每个 case 两个文件。请求文件就是标准的POST /v1/systemone请求体{ model: jev-latest, state: { customer_message: My parcel never arrived and the tracking has not moved in a week., reply: Sorry about that. Could you send me your order number so I can check with the courier? }, questions: { asks_order_number: {type: noul, instructions: Does the reply ask the customer for their order number?}, promises_refund: {type: noul, instructions: Does the reply promise the customer a refund?}, polite: {type: noul, instructions: Is the tone of the reply polite?} } }期望值放在独立的 sidecar 文件里.expect.json{asks_order_number: yes, promises_refund: no, polite: yes}用 jev decide 批量运行判断CI 步骤一对每个请求文件跑一次jev decide结果写入answers/mkdir -p answers for f in cases/*.request.json; do name$(basename $f .request.json) ./jev decide --threads 4 $f --output answers/$name.json done--output只创建不覆盖重复运行安全非法请求会退出码 1 直接失败该步骤。几十个文件用decide足够上百个文件建议起一个jev serve模型只加载一次短请求 28 ms、长请求 130 ms约 1 GB 内存。带边界的断言pass / fail / warn 三档硬断言p 0.5是最容易失去信用的写法一个 0.52 的 case 会在任何无辜改动后翻红。改用三段区间PASS, FAIL 0.7, 0.3 # 用你标注过的 case 调这两个数 bad p FAIL if want yes else p PASS # 明确错 → 构建失败 warn not bad and not (p PASS if want yes else p FAIL) # 中间 → 只告警明确对pass什么都不做明确错fail退出码 1构建变红中间地带warn打印到 job 摘要由人看一眼——这里也正是评委自己最不可靠的区域。阈值不要拍脑袋先用你标注过的 case 选方法见 how to choose a threshold for P(yes)。固定评委版本避免分数漂移回归测试比较的是今天和昨天前提是评委没变按版本名固定模型文件二进制 model/文件夹用发布包的SHA256SUMS.txt校验下载缓存命中时同样校验缓存文件会被静默复用用GET /health的 SHA-256 指纹打进 job 日志升级评委单独开一个 commit重跑全量并审阅分数变化——就像审查依赖升级一样。CI 工作流要点GitHub Actions 示例仓库 wiki 给了一份可直接改造的 workflow 草案注意官方标注为 untested sketch先在分支上跑actions/checkout只拉你自己的仓库actions/cache缓存jev/目录key 里带上发布名、模型格式、平台如jevos-v4-openvino-int8-linux-x64未命中缓存时用gh release download下载二进制与模型两个发布资产并解压jev/model就是默认模型目录decide步骤按上一条的循环跑判断Assert步骤跑断言脚本非零退出即失败。公开仓库 runner 是 4 CPU--threads 4正好匹配私有仓库 2 CPU 就降到 2。防止 CI 测试抖动的检查清单✅固定被测系统的采样生成端 temperature 非零时同一输入会有不同输出测试期把它锁死✅拆开复合检查回复礼貌且询问了订单号是两个检查失败时你说不清是哪个✅优先读类问题模型在算术类上只有 0.584总额是否正确这种检查交给普通单元测试比数字✅先报告后阻断新检查先跑成非阻塞看概率分布把稳定的再升级为阻断项❌ 别把发布级最终评测放进 CI——CI 只负责抓回归好坏由正经测试集回答❌ 别在共享 runner 上做延迟基准——机器是共享的一次计时说明不了什么。相关文件导航wiki/llm-regression-tests-in-ci.md — CI 回归测试的完整方法wiki/github-actions-llm-checks.md — GitHub Actions 工作流草案wiki/building-a-yes-no-test-set.md — 测试集构建wiki/evaluation-metrics-for-yes-no-classifiers.md — 指标速查表wiki/accuracy-by-kind-of-question.md — kind 标签与按类评测tests/check.py — 仓库自带的 CI 检查脚本parity、decide行为、健康指纹等tests/golden/ — 黄金响应文件--exact零容差对比的参照src/main.cpp — 所有命令行选项说明小结用 jevos 搭评测体系的完整闭环是真实用例 生成用例构建测试集 → 按 kind、错误方向、阈值精度四维报告指标 → 把稳定的检查以 request/expect 文件 jev decide接入 CI用 pass/fail/warn 三档断言防抖动并用 SHA-256 指纹固定评委。全程 CPU、零外部调用100 条用例的构建成本是一个下午两个人——而它能在第一次回归发生时就让你知道。赞分享【免费下载链接】jevjevos: an open-source alternative to Jev and Microsoft-Decision-1. Yes/no decisions, choices and scores with probabilities, on your laptops CPU.项目地址https://gitcode.com/gh_mirrors/je/jev点击查看免费下载相关推荐Miller 回归测试框架实战指南用 mlr regtest 构建跨平台自动化测试体系Miller 回归测试框架实战指南用 mlr regtest 构建跨平台自动化测试体系 导读 本文面向 Miller 的开发者与贡献者系统讲解该项目内置的回CLI数据分析构建WhisperKit测试环境单元测试与回归测试实践构建WhisperKit测试环境单元测试与回归测试实践 你是否在为语音识别模型的测试环境搭建而烦恼作为适用于Apple Silicon的设备端语音识别框架语音音频AI 应用DeepEval用 pytest 风格单元测试为 LLM 应用构建自动化评测与 CI/CD 集成DeepEval用 pytest 风格单元测试为 LLM 应用构建自动化评测与 CI/CD 集成 DeepEval 是一个开源 LLM 评测框架它把 AI文档教程知识库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考