【免费下载链接】deepopen非自回归System 1决策引擎专为结构化类型决策场景设计 DeepOpen Multilingual, non-autoregressive System 1 decision engine.项目地址https://gitcode.com/gh_mirrors/de/deepopen点击查看免费下载本篇指南以 research/README.md 为主线完整讲解 DeepOpen 项目中 Laya 检查点基准测试的构建方式、评测脚本用法、原始结果文件结构以及六条被主 README 引用的核心结论路由收益、置信度失效、过度自信校准、zero-shot 表现、延迟与 Jev 第三方对比口径。读者读完可独立复现 51 语言 MASSIVE 意图扫描、T4 全量 head-to-head、应用工作流与路由开销测量并正确区分项目实测与第三方公开发表数字的证据边界。目录为什么需要独立的 benchmark 分支脚本总览六条评测管线各自的职责环境前提为什么必须设置 USE_TF0原始结果文件结构与读取方式六大核心结论及其源码证据与 Jev 对比的证据边界在 T4 上复现全量评测Colab 指南在 CPU 上复现 51 语言扫描与延迟测量应用工作流评测六个真实业务场景校准修复实验温度重拟合的完整做法结论与进一步阅读为什么需要独立的 benchmark 分支DeepOpen 是一个非自回归的 System 1 决策引擎核心能力由deepopen包提供deepopen/agent.py、deepopen/router.py、deepopen/common.py 等。research/目录是这套引擎的证据库它只负责产出、存放 Laya 检查点的基准测试脚本与原始结果不参与任何运行时导入。README 第一段即明确说明Benchmark harnesses and raw results for the Laya checkpoints. This branch is the evidence behind the numbers quoted in the main README — nothing here is imported by thelayapackage.这意味着两件事一是仓库主 README 中引用的每一个性能数字都可以在本目录找到对应的可复现脚本与原始 JSON二是这些脚本对生产运行零侵入你删除research/也不会影响deepopen包本身的导入链路。从仓库结构看research/下只有三类实体scripts/六个评测脚本 一个笔记本生成器 一个已生成的可直接运行的 Colab 笔记本results/两个已完成的原始结果 JSONT4 全量评测、CPU 51 语言扫描README.md证据口径、脚本职责表、核心结论摘要与对比声明。脚本总览六条评测管线各自的职责README 用一张表概括了scripts/下每个脚本的用途逐条整理并补充仓库源码细节如下文件职责产出scripts/laya_benchmark_colab.ipynbColab T4 上的全量 head-to-headtyped-decisions、MASSIVE intent scenario14 种语言、XNLI15 种语言、英文套件、延迟、选项顺序鲁棒性、校准修复一个laya_benchmark_results.jsonscripts/build_benchmark_nb.py上述笔记本的生成器源码在 py 文件里改这里而不是直接改.ipynb重新生成laya_benchmark_colab.ipynbscripts/bench_local.pyCPU 扫描MASSIVE intent全部 51 种语言 typed-decisions 三个检查点全测local_benchmark_results.jsonscripts/bench_apps.py六个应用工作流 存在公开 Jev 数字的数据集app_benchmark_results.jsonscripts/bench_latency.py推理速度含路由成本检测开销、热路径、冷切换、混合语言吞吐多档max_loadedlatency_benchmark_results.jsonscripts/make_plots.py从结果 JSON 渲染 assets/laya_benchmark.png一张四象限汇总图build_benchmark_nb.py的存在是仓库刻意做的一次工程权衡Colab 笔记本内容完全由 Python 源码拼接生成md()/code()两个辅助函数因此版本可控、可 diff、可审查。如果你要调整评测内容正确的做法是修改这个生成器再重新生成笔记本而不是直接在.ipynb里改单元格。环境前提为什么必须设置 USE_TF0README 给出了一个对 macOS/Python 3.9 开发者尤为重要的环境约定Everything runs withUSE_TF0—transformersprobes for TensorFlow at import, and when TF is installed its abseil runtime can deadlock model construction on macOS/Python 3.9.即transformers在 import 时会探测 TensorFlow若环境里装了 TF其 abseil 运行时在 macOS Python 3.9 下可能让模型构建直接死锁。所有评测脚本在文件头部统一通过os.environ.setdefault(USE_TF, 0)强制关闭 TF 探测可参见 bench_local.py、bench_latency.py、bench_apps.py。同时脚本还设置了USE_TORCH1与TOKENIZERS_PARALLELISMfalse后者用于避免多进程 tokenizer 的并行警告干扰日志。所有脚本的实际运行形态均为命令行方式例如USE_TF0 python3 research/scripts/bench_local.py [--langs N] [--per-lang N] [--skip-a] [--skip-b] USE_TF0 python3 research/scripts/bench_latency.py USE_TF0 python3 research/scripts/bench_apps.py注意bench_local.py的三个可选参数--langs N限制参与 A 部分扫描的语言数量0 表示全部约 51 种--per-lang N每种语言采样的 case 数默认 120--skip-a/--skip-b分别跳过 MASSIVE 部分或 typed-decisions 部分便于分时运行、断点续测脚本启动时会先尝试从输出 JSON 恢复已有结果再增量写入。原始结果文件结构与读取方式results/下两个 JSON 是 README 全部结论的原始出处文件内容results/t4_colab_benchmark.json17,416 个问题在单张 T4 上跑完两个检查点每个模型面对完全相同的题目results/cpu_51_language_sweep.json51 种语言 × 2 个检查点MASSIVE intent20 个选项以cpu_51_language_sweep.json为例其顶层结构为meta运行时间、devicecpu、torch 2.8.0、laya 0.2.0、线程数part_a配置与分模型结果。配置段记录了languages51 种含 af/am/ar/…/zh-CN/zh-TW 全列表、per_lang: 100、n_options: 20、seed: 13——固定种子保证了同一批题目、两种模型分别作答的对照口径。每个语言条目包含accuracy、macro_f1、ece、brier、nll、mean_confidence、acc_at_50_coverage、seconds、dropped等字段可直接用于画单语言分布。t4_colab_benchmark.json的结构更丰富meta.models记录了两种检查点的参数规模与配置见下节suites下按套件typed_decisions、massive_intent.、xnli.、en.* 等分模型给出calibrated与raw两套指标另含typed_decisions_matched_512等上下文预算对照、latency、option_order_robustness、calibration_repair、caveats与summary聚合块。README 中引用的数字全部可以在这份 JSON 里逐条对上。六大核心结论及其源码证据结论一路由把 Laya 可读语言从 23 种提升到 45 种README 原文Routing takes Laya from 23 to 45 of 51 languages.On MASSIVE intent (20 options, random 0.050) the English checkpoint macro-averages 0.227 and clears 3x random on 23 of 51 languages; the multilingual checkpoint reaches 0.366 and clears it on 45.在 cpu_51_language_sweep.json 中可直接核验english 检查点macro_accuracy 0.2269、languages_above_random 23、macro_ece 0.7331multilingual 检查点macro_accuracy 0.3661、languages_above_random 45、macro_ece 0.3869。随机基线为3.0 / 20 0.050超过 3 倍随机即语言被判定为可读的判据实现在 bench_local.pylanguages_above_random的统计逻辑。这条结论的直接工程含义是多语言部署不应只加载一个检查点而应让 router.py 按语言路由。路由的具体成本与max_loaded参数行为见下文延迟章节。结论二英文检查点的置信度在读不懂时毫无预警README 原文The English checkpoints confidence gives no warning when it cannot read the input.Khmer: 0.000 accuracy at 0.952 mean confidence. Macro ECE 0.733 across 51 languages, with mean confidence never dropping below 0.885 at any accuracy level.这一条在 cpu_51_language_sweep.json 的km语言条目中得到精确验证accuracy 0.0、mean_confidence 0.9515、ece 0.9515、nll 23.21。也就是说面对高棉语时模型全错但平均置信度高达 0.952。这正是 README 强调路由必须发生在前向传播之前的原因置信度门控confidence gating无法捕获这种系统性失灵因为输出分布本身是过度自信的。从架构角度看这与 deepopen/agent.py 中system_one的前向-后处理分离设计一致——语言检测纯 Python无模型应当先行。结论三两个检查点出厂即过度自信温度重拟合可大幅修复README 原文Both checkpoints ship over-confident.Refitting one temperature per (question type, option count) on held-out data moves mean ECE 0.466 - 0.081 (laya) and 0.314 - 0.106 (laya-multilingual, which ships with no fitted temperatures at all).两个数字分别来自 T4 全量评测的calibration_repair聚合laya均值 ECE 从出厂 0.466 降至重拟合后 0.081laya-multilingual从 0.314 降至 0.106。两者的差异根源在配置层面暴露得很清楚——t4_colab_benchmark.json的meta.models显示laya英文检查点temperature: [1.6369, 1.2514, 1.9834]并带temperature_by_options桶choice:3-5、choice:6-10、choice:11、choice:2、score:3-5、noul:2即出厂已按问题类型选项数拟合过温度laya-multilingual多语言检查点temperature: [1.0, 1.0, 1.0]temperature_by_options: {}——一个温度桶都没有出厂完全未校准。温度桶的键名格式如choice:3-5来自laya.common.temp_bucket的分桶逻辑评测引擎 bench_local.py 中的temp_for函数实现优先查桶、无桶回退到类型级温度的取值策略。校准修复的具体复现步骤见下文专门章节。结论四基础检查点在 typed-decisions 上近乎随机README 原文The base checkpoints are near chance on typed-decisions zero-shot— 0.362 and 0.352 against a 0.318 random baseline and a 0.461 majority-class baseline. The published 0.766 belongs to the checkpoint fine-tuned on that benchmarks own training split.t4_colab_benchmark.json的summary.typed_decisions显示laya零样本准确率 0.362、laya-multilingual0.3515。作为参照随机基线 0.318、多数类基线 0.461这些参照值在 bench_local.py 的reference_points中有明确标注来源例如random_guess: 0.3175、per_question_majority_class: 0.4610。而主 README 引用的 0.766 属于在该基准自身训练集上微调过的专用检查点——两个基础检查点并未训练过 typed-decisions见caveats.training_overlap因此 0.766 与 0.362 之间不存在可比性矛盾只是口径不同。结论五T4 上的速度表现README 原文Speed.32.8 ms for one question and 7.2 ms/question at batch 10 on a T4; 103–332 questions/s batched.逐条对应t4_colab_benchmark.json的latency块单问题 32.8 mslaya-multilingual的1_questions.p50_ms 32.8batch 10 下 7.2 ms/问题laya-multilingual的10_questions.p50_ms 72.3即 72.3 / 10 ≈ 7.23 ms/q批量化 103–332 问题/秒对应questions_per_second字段区间如 typed_decisions 套件为 55.2 q/smassive_intent 各语言约数百 q/s视序列长度与模型不同而浮动。顺带补充英文检查点的对照laya的1_questions.p50_ms 39.550_questions.p50_ms 771.3。README 表述的 32.8 ms 与 7.2 ms 均指向多语言检查点这一点在引用时应保持一致口径。与 Jev 对比的证据边界README 明确声明了对比口径的诚实性边界There is no TypeSafe API credential in this project, soJev was never run here. Every Jev figure quoted is third-party published, with different sample sizes and prompts.即本项目从未实际运行过 Jev因为仓库里没有 TypeSafe API 凭证所有 Jev 数字都是第三方公开发表的结果且样本量与 prompt 各不相同。README 引用两个第三方来源来源引用数据AbdelStark/jev-benchmarksAG News 0.910、Banking77 0.870、DAIR Emotion 0.480Brier 0.846、NLL 5.588、16% 样本对真实标签给出零概率nibzard/decision-model-benchmarkECE 0.246该研究中最差、banking77 0.763、选项顺序翻转率 13%、延迟 264–276 ms p50这些第三方数字同时以结构化的JEV_PUBLISHED常量嵌入 bench_apps.py并在bench_local.py的reference_points中复述typed-decisions 维度Jev 1.13.0 公布 acc 0.727 / soft_acc 0.580 / Brier 0.148 / ECE 0.144 / MAE 0.391 / 710 ms per case。README 的最终立场是Treat those as indicative, not a controlled head-to-head.因此任何引用本仓库 Jev 对比数据的文章都应保留第三方公布、非本项目实测这一限定语这既是事实准确的要求也是 make_plots.py 中图表注解Jev figures are third-party published, not measured here的一致口径。在 T4 上复现全量评测Colab 指南laya_benchmark_colab.ipynb是 README 所述the full head-to-head的直接载体覆盖 typed-decisions、MASSIVE intent scenario14 语言、XNLI15 语言、英文套件、延迟、选项顺序鲁棒性与校准修复最终写出一个laya_benchmark_results.json。README 给出了运行前提Setup:Runtime → Change runtime type →T4 GPU. Then Run All (~25–40 min).build_benchmark_nb.py的源码把整个流程组织为十个步骤可按需拆解执行GPU 与环境检查nvidia-smi输出 GPU 型号torch.cuda.is_available()断言 T4 就绪依赖安装laya0.1.6、transformers4.45、datasets3.0、safetensors、huggingface_hub下载两个检查点convaiinnovations/laya与convaiinnovations/laya-multilingual并对laya-multilingual的 tokenizer 配置做兼容性修补其extra_special_tokens以列表形式存在而 transformers 期望 dict不修补则laya.load()直接失败补丁逻辑见生成器源码的patch_tokenizer_config。随后记录两模型的参数规模——英文检查点共 421.3M 参数394.8M 编码器 26.5M 决策头多语言检查点 321.9M306.9M 15.0M——并强制关闭reference_compiletorch.compile 在 T4 这类少 SM 小批量场景反而是负担评测引擎score_cases把每个 (state, question) 构造成一条序列按长度排序后以 token 预算打包分批max_tokens、max_seqs可调返回未校准 logits——温度在校准阶段统一施加保证 raw/calibrated 两套指标来自同一次前向任务套件构建所有套件用固定种子SEED13构建一次、两模型复用同一批题目多数标签任务采用gold N-1 个干扰项的选项抽样N_OPTS20与训练配方中 5–20 个选项的采样方式对齐全量评测每个套件在两个模型上各跑一遍输出calibrated按出厂温度与raw温度1.0两套硬指标外加 soft_acc、Brier、TV、KL 等教师软标签指标typed_decisions 还按 4 个工作流和 3 种问题类型choice / score / noul分别聚合等上下文预算对照两模型出厂上下文窗口不同英文 512多语言 1024为避免多语言检查点看到的输入更长这一混淆因素6b 小节把两模型max_len都压到 512 重跑 typed_decisions得到typed_decisions_matched_512延迟测量p50/p95 在每轮 1 / 5 / 10 / 50 个问题上采样并同步torch.cuda.synchronize()保证计时包含 GPU 执行选项顺序鲁棒性同一问题打乱选项顺序重测统计答案翻转率independent Jev 基准测得 Jev 翻转率 13%、最差 LLM 37%实测laya在 massive_intent.en / en.emotion / xnli.en 上翻转率 0.15 / 0.04 / 0.00laya-multilingual为 0.23 / 0.09 / 0.015校准修复详见后文 聚合保存最后可用files.download(laya_benchmark_results.json)取回结果。笔记本开头还记录了两模型的关键配置对比表可在生成器源码build_benchmark_nb.py中直接查看上下文 512 vs 1024、hidden 1024 vs 768、层数 28 vs 22、vocab 50368 vs 256000、出厂温度已拟合 vs 全 1.0。这些字段与t4_colab_benchmark.json的meta.models完全一致。在 CPU 上复现 51 语言扫描与延迟测量51 语言 MASSIVE 扫描bench_local.pybench_local.py是 README 结论一、二的主要复现路径结构上分两大部分Part AMASSIVE intent 全部语言扫描。语言清单通过HfApi().dataset_info(mteb/amazon_massive_intent)从数据集的test/lang.json文件实时解析bench_local.py所以51 种语言来自数据集发行版而非硬编码。每种语言采样--per-lang个 case把意图标签映射为choice问题20 个选项 gold 19 个干扰项干扰项按种子 13 采样后打乱逐模型逐语言跑score_cases输出 accuracy / macro_f1 / ECE / Brier / NLL / mean_confidence / acc_at_50_coverage 等指标Part Btyped-decisions400 个 case / 2,000 个决策在三个检查点english、multilingual、typed-decisions上全测目的是把微调过的laya-typed-decisions与 Jev 公布的 0.727 放在同一基准上比较。B 部分额外输出 soft_accuracy、brier_vs_soft、score_mae、within_1_level、ms_per_case并按工作流与问题类型二次聚合。运行后脚本把结果写入仓库根目录的local_benchmark_results.json注意输出路径OUT位于仓库根即REPO/local_benchmark_results.json与results/下已交付的 JSON 不同。断点续跑是刻意设计的main()先尝试从既有 JSON 加载再增量写入。延迟与路由开销bench_latency.pybench_latency.py的核心洞见是路由改变延迟画像的两个方面——每次调用都要支付纯 Python 的语言检测无模型以及冷切换时支付模型加载真实混合语言负载的数字介于热/冷两态之间由max_loaded决定。脚本分五个部分测量语言检测开销对英文、印地语、短英文、200 行大 JSON 四种输入测laya.lang.analyse的 p50/p95纯 Python无模型前向各模型原始延迟三个检查点分别测 1/5/10/50 个问题的agent.system_one延迟并记录冷加载耗时路由热路径Router(models..., max_loaded3)下目标模型已驻留时predict相对原始system_one的额外开销对 10 问英文调用以routing_overhead_hot_ms量化路由冷路径max_loaded1强制每次语言切换都换模型记录 swap 中位数混合语言负载100 次调用、每次 5 问在非英语占比 0%/10%/30%/50% 与max_loaded1/3 的交叉网格下测calls_per_s与平均每调用毫秒数——这是判断该配多少驻留槽位的最直接依据。实际运行前请确保模型目录存在脚本硬编码~/laya_models/laya、laya-multilingual、laya-typed-decisions并注意它是 CPU 测量README 已注明 GPUT4参照在 Colab 运行结果中。应用工作流评测六个真实业务场景bench_apps.py把 README 所述的six application workflows落地为可复现套件每个场景都使用真实标注数据编号工作流数据集与设置1客服工单分流support triageTobi-Bueck/customer-support-tickets10 个队列的choice路由含 subject body ≤ 3000 字符2邮件 钓鱼检测SetFit/enron_spam 的 spam 判定 zefang-liu/phishing-email-dataset 的 phishing 判定均为noul二值问题3LLM 护栏guardrailslmsys/toxic-chat 的 jailbreaking 标记训练集外4RAG 段落过滤microsoft/ms_marco v1.1 的段落相关性noul判定正负样本交替采样5内容审核moderationlmsys/toxic-chat 的 toxicity 标记训练集外6模型路由domaingsm8k / mbpp / ag_news 混合样本做领域分类code / math / writing / factual / data / chitchat 六类脚本同时注册了三组Jev 可对比任务ag_news、banking77 全标签集、DAIR emotion其JEV_PUBLISHED常量与 README 引用的第三方数字一一对应。三个检查点english、multilingual、typed-decisions对全部套件逐一评分每行输出 accuracy / f1 / ECE / ms per case并在存在 Jev 公布数字时打印vs Jev ±delta。套件规模可用环境变量BENCH_N控制默认每任务 400 例例如BENCH_N200 USE_TF0 python3 research/scripts/bench_apps.py可做快速冒烟测试。注意护栏与审核两个任务刻意选择了训练集外数据in_trainingFalse衡量的是零样本泛化工单分流、邮件、RAG 等任务在训练分布内in_trainingTrue衡量的是保持能力——阅读结果时务必区分这两类语义。校准修复实验温度重拟合的完整做法这是 README 结论三的完整复现路径实现在 Colab 笔记本的第 9 步源码在 build_benchmark_nb.py 的 9. Calibration repair 单元格。关键设计是样本外评估对每个套件把 (logits, gold) 对按时间顺序对半切分前半用于拟合温度、后半用于评估 ECE避免用测试集调参再在测试集上报数的泄漏。拟合算法是朴素的网格搜索无需 autograddef fit_temperature(pairs, lo0.2, hi10.0, steps160): # pairs: [(logits, gold_idx)] - 单个最小化 NLL 的温度 best_t, best 1.0, float(inf) for t in np.geomspace(lo, hi, steps): tot 0.0 for z, g in pairs: zz z / t zz zz - zz.max() tot -(zz[g] - math.log(np.exp(zz).sum())) if tot best: best, best_t tot, float(t) return round(float(best_t), 4)分桶规则复用laya.common.temp_bucket(qt, k)按问题类型 选项数分桶如choice:11、noul:2每个桶独立拟合、不足 25 个样本的桶回退到类型级温度。结果汇总为每模型的mean_ece_shipped与mean_ece_refit。实测数值README 引用口径为laya0.466 → 0.081、laya-multilingual0.314 → 0.106。从t4_colab_benchmark.json的calibration_repair明细看单语言套件的修复幅度更为直观——例如massive_intent.hi印地语从出厂 ECE 0.855 降至重拟合 0.038拟合温度 8.84massive_intent.ar阿拉伯语从 0.783 降至 0.043拟合温度 5.41。这说明多语言检查点的大部分校准缺口来自缺失的后处理步骤而非模型本身的属性——这是部署前花 5 分钟拟合温度最有力的论据。结论与进一步阅读本目录给出的是一套可复现、可核对、口径诚实的基准测试体系51 语言扫描与 T4 全量 head-to-head 的原始 JSON 就放在 results/ 下六个脚本覆盖应用工作流、路由开销、校准修复与可视化全部统一在USE_TF0环境下运行。六条核心结论——路由提升可读语言 23→45、过度自信掩盖失效高棉语 0.000 准确率配 0.952 置信度、出厂温度缺失导致 ECE 0.466/0.314、零样本 typed-decisions 近随机0.362/0.352 vs 0.318 随机基线、T4 单问 32.8 ms 与 batch10 下 7.2 ms/q、以及 Jev 数字一律以第三方公布口径引用——均可在上述脚本与 JSON 中逐条追溯。后续想深入本文涉及的底层实现可继续阅读deepopen/router.py路由器的max_loaded驻留策略与语言检测接入点deepopen/agent.pysystem_one前向流程与配置max_len、head_max_len的取值来源deepopen/common.pytemp_bucket、QTYPES、build_sequence等评测引擎依赖的基础设施tests/test_router.py 与 tests/test_local_e2e.py与路由、端到端行为相关的测试口径assets/laya_benchmark.png由 scripts/make_plots.py 渲染的汇总图直观展示多语言哑铃图、T4 延迟、Jev 对比与校准修复四象限。赞分享【免费下载链接】deepopen非自回归System 1决策引擎专为结构化类型决策场景设计 DeepOpen Multilingual, non-autoregressive System 1 decision engine.项目地址https://gitcode.com/gh_mirrors/de/deepopen点击查看免费下载相关推荐DeepOpen Laya 基准测试全景51 语言、六大应用工作流、延迟与校准的完整实测解读DeepOpen Laya 基准测试全景51 语言、六大应用工作流、延迟与校准的完整实测解读 本指南以仓库根目录的 BENCHMARKS.md https:/Laya基准测试全解读51种语言横评它比TypeSafe Jev强在哪里Laya基准测试全解读51种语言横评它比TypeSafe Jev强在哪里 Laya 是一个多语言、非自回归的 System 1 决策引擎 ——它不生成文本人工智能NLP强化学习pyrefly PyTorch 基准测试指南基于 15k 文件真实代码库的 LSP 延迟与全量检查吞吐评测pyrefly PyTorch 基准测试指南基于 15k 文件真实代码库的 LSP 延迟与全量检查吞吐评测 本文以 pyrefly 仓库自带的 PyTorc开发工具静态分析IDE代码质量创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考