 ThearchyHelios
|
ccb2b2baa8
|
评测停止、中断、到了上限后的计数照实分开：没跑的题单独计 not_run，stop_reason 写停下的原因
验收：评测停止或中断后，没跑的题计入 errors、done = total、stop_reason 为 null，读起来像全评完了、出了很多错。
原因：runner._counts 把 cancelled、skipped 都算进 done（TASK_DONE），cancelled 又算进 errors；停止、中断走 _close →
_conclude(status, None, error)，原因写进了 error、stop_reason 是 None；服务重启后的整理（startup、reconcile_stale）
和排队中就停掉（cancel_queued）只改了逐项状态，计数还是旧的、stop_reason 也没写。
改法：
- _counts：done 只算真的跑过的（ok、partial、failed）；停止、中断时没评完的（cancelled）和到了上限、止损之后没开评
的（skipped）单独计 not_run；errors 只算 failed；skipped 只算评了、但期望算不出、不评分的（verdict），不再混进没开评
的。done + not_run + running + pending = total。
- 停止、中断是「停下」不是「出错」：_close 把原因记进 stop_reason（STOPPED / INTERRUPTED），error 留空；整体出错照旧
记 error。到了上限、止损本来就写 stop_reason，不变。还没备好几臂就停下的那一支（bare）同样写 stop_reason 并重算计数。
- core/job_runtime 的 close_job、cancel_queued 加一个可选的 finish：状态改好、提交之前在同一个事务里补一步。评测的
startup、reconcile_stale、stop 用它记 stop_reason、按改好的逐项状态重算计数（_closing）。起草、剖析、探查不传，
行为不变（它们的测试全过）。
- stats.summarize 的 not_run 也只算没跑的（cancelled、skipped），出错的另列 errors（以前 not_run 里混着出错的）。
前端：评测页总览「N 项没评（停止、中断，或者到了上限、止损之后没开评）」和「M 项出错」分两行；类型补上 not_run、
errors 的说明。停下的原因本来就照 stop_reason 显示。
测试（test_eval_runner）：停止之后 stop_reason 是「评测已停止」、error 为空，errors 为 0、done 是评完的题数、not_run
是其余，总表的 not_run、errors 同样分开；重启整理成 interrupted 时 stop_reason 是中断的说法、计数重算（not_run 1、
running 0）；新增一条排队中就停掉的：not_run 等于题数、pending 归零；到了金额上限没开评的那题记 not_run、不记跳过。
去掉修复回跑挂 4 条。check-evals 的停止夹具照服务端改，核对停下的原因、不当成出错、没评的单列。评测、起草、剖析、
探查、定时维护相关的测试 548 条全过；tsc、check-copy 通过，check-evals 103 项全过。
|
2026-10-17 09:10:52 +08:00 |
|
|
ThearchyHelios
|
9e33c0f801
|
评测的两个通知事件照实叫「定时评测有退步」「定时评测没有评完」（复核 L3）
eval.regressed、eval.failed 只在定时发起的评测收尾时推（runner._conclude 只认 trigger == "schedule"），手动发起的那次人自己
在看、不推，这和细案 01 做法 15 把这两个事件放在定时一节里一致。可订阅时的叫法却是「评测有退步」「评测失败」，没写「定时」：
有人给全局渠道勾上「评测失败」、再手动发起一次评测并止损停下，渠道里收不到任何消息，界面上也没处说为什么。
- notify/service.EVENTS 和前端 NOTIFY_TEXT.eventLabel 同一句改成「定时评测有退步」「定时评测没有评完」（test_notify_events
逐字对照两边）。eval.failed 不只是失败：到了上限、止损停下（partial）同样推，所以叫「没有评完」，和消息标题本来的说法一致。
- notify_eval 的消息标题也带上「定时」：定时评测「题集名」有退步 / 没有评完。
- 新测试：两个事件的叫法带「定时」；手动发起的评测止损停下，订阅了这两个事件的全局渠道收不到任何消息（去掉 trigger 的判断
这一条就失败）。
- 模块说明、接口说明里引用旧叫法的几处一并改。
|
2026-10-16 18:23:03 +08:00 |
|
|
ThearchyHelios
|
40daf37107
|
评测发起后立刻交给后台再读回；补「复核要重来」的测试
为什么：发起评测时提交之后、交给后台之前还 await 了几次读回，这中间别的请求读到「排队中、却没在这个进程里跑」会把它
当成服务重启留下的、标中断。改成提交之后立刻交给后台，再读回。
- test_eval_runner：复核给了 retry_instruction 时带着这次运行的图、照那句话重来一次，第二次复核（attempt=1）不再要重来，
两次作答运行都记在这一题名下
|
2026-10-16 17:15:17 +08:00 |
|
|
ThearchyHelios
|
a0cdb16617
|
重评时把评分规则版本记进指纹；去掉几处没用的导入
为什么：按新规则重评之后，和别的评测比时「评分规则」那一项要照实标出变了；总表上另记重评的时间。
|
2026-10-16 17:11:09 +08:00 |
|
|
ThearchyHelios
|
88e219eabc
|
评测总表照实列出没开评的题、按评完的题估每题花费；对比测试单独成文件，补超时止损的测试
为什么：总表里「没开评、停下、出错」的题以前只体现在计数里，准确率旁边看不出来；下一次开跑前的估算按每题平均花费算，
把没开评的题也摊进去会估低。
- stats.summarize 加 not_run；per_case_cost_usd 只按评完了的题平均
- test_eval_compare.py：逐题转移与归因、指纹差异、A/B 配对表、选基准（从 test_eval_stats 拆出来，对上细案的测试清单）
- test_eval_runner：最近 10 题里 7 题超时就止损
|
2026-10-16 17:08:29 +08:00 |
|
|
ThearchyHelios
|
df6c3ce10d
|
定时页照实显示非工作流目标；评测停止时几臂一起收尾；工作流题的测试
为什么：这一波后端开始接受评测题集、数据源维护这两种定时目标（总方案 X4），定时页要能把它们照实列出来、点进去
不报错；界面上不能有点了没用的入口。
- 定时页列表：非工作流目标写种类（评测题集 / 数据源维护）和目标名，不标运行类别，「编辑」写成「查看」
- 详情：非工作流目标的设置只读地列出名称、目标、频率、时区、补发宽限，不出工作流那张表单（选工作流、输入模板、
Webhook 对它们不适用）；页头的启用、立即运行、删除和触发历史照常
- 立即运行发起的是一次评测时说「已发起一次评测」（以前会落到「未能发起运行」）；触发历史写评测的编号
- types.ts：Schedule 加 target_kind / target_id / target_label / target_name / target_exists，触发记录加 eval_run_id；
文案进 SCHEDULE_TEXT
- check-schedules 加一段「目标不是工作流的定时任务」
- runner：还没准备好就被停下、出错时，按 pair_id 找全几臂一起收尾
- 测试：工作流题按钉住版本跑探索运行（不发正式运行、不建图）；钉住基线的接口
- 后端几句给人看的话按文案规范改（不用「跑」「钉」）
|
2026-10-16 17:04:05 +08:00 |
|
|
ThearchyHelios
|
e29adf80d0
|
评测执行的测试：执行、评分、统计与对比、清理、定时与通知
为什么：照细案 01 的测试清单把这一波的行为钉住，顺带修了跑测试时撞出来的两处。
- test_eval_runner：后台排队、并发不超过 max_parallel 也不超过全局并发的四分之一、同一题集同时只能一次、停止后只重做
没做完的（评完的不动）、重启标中断不续跑、单次金额上限触顶不再开新题、评测每日账单独记（不占裁判、核查的额度）、
连续 3 题助手调用失败止损、每题超时取消正在跑的运行、停在审批上的作答取消掉（评测不代批）、接口的估算与进度、设置里
eval 一组和 /settings/eval/spend
- test_eval_score：五种结论、写出精度和百分数、维度配对与弱匹配、多行 / 名单 / 没有数据 / 反问、路径和期望先于数字、
dual 两版、允许的相对误差和双盲复算是同一个函数；读封存的答案、逐题 E1 用账本的比对函数；重评只读封存、不调模型
- test_eval_stats：Wilson、精确 McNemar、P50/P90 和手算对照；总表的各项；转移与四种归因；指纹差异；配对表；选基准
- test_eval_cleanup：保留规则；forget 只删一条引用都不剩的文件；清理后总表还在、结果和底下的运行删掉、共用的工件留着
- test_eval_schedule：定时接口收题集（拒工作流、输入模板、Webhook）、到点建一次评测并写 eval_run_id、重叠跳过、错过的按
宽限补；有退步推「评测有退步」、没评完推「评测失败」，消息里没有期望值和答案里的数
- test_eval_e2e 补：开评拍目录快照、记表结构前后；打开裁判时结论裁判走按需裁判那条路、花费记在评测账上，文字要点单列
- 修：期望反问的题在建图、运行失败（含超时）时把原因写全；改非工作流目标的定时任务时提交后不再读过期对象
|
2026-10-16 16:49:47 +08:00 |
|
|
ThearchyHelios
|
2371e75f17
|
评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段）
为什么：第 2 波只有题集和期望答案的来源，评测本身跑不起来。这一段把细案 01 做法 9–12、16、17 的后端接上，
量的是用户在问数据页拿到的同一轮，而不是另抄一份编排。
- eval/answer.py：无头作答，串起 answer_ops → chat/turn 的决定 → launch_run(origin=eval，带目录视图、只读、遮罩)
→ 等终态（停在审批的取消、记「评测不代批」；驳回记路径「被驳回」）→ review_of_run → 按同一规则重来一次；
工作流题按钉住版本的图跑探索运行（不发正式运行，免得被 pick_base 和应用视图取到）。用量按角色记
- eval/runner.py：用 core/job_runtime，一次评测一个任务，题 × 重复 × 臂一项；A/B 几臂共用期望、同一题同时开跑；
开评拍目录快照、记上传表格版本和表结构哈希的前后；并发不超过 max_parallel 和全局并发的四分之一；每题时限；
评测单独一本账（开跑前估算、每题预留后找补、触顶不再开新题）；止损；能停、只重试没做完的、重启标中断不续跑
- eval/score.py：六种期望、五种结论（量纲不同单列）、维度配对与弱匹配、路径不对直接不通过、口径 dual 两版都报；
逐题 E1 用口径账本的 compare_queries（总方案 X2，不另写 signals）；SCORER_VERSION 可重评（eval/rescore.py，只读封存）
- eval/judging.py：结论裁判走按需裁判同一条路（evidence._judge_now），文字要点由裁判判、单列不计准确率；花费经
judge.charged_to 记在评测那本账上（engine/judge.py 只加了一个上下文变量和取账本的一处）
- eval/stats.py、eval/compare.py：准确率与可追溯准确率 + Wilson 区间、各项分布、P50/P90、按角色成本、引用率、逐题 E1；
选基准、逐题转移与归因、指纹差异、A/B 配对表与精确 McNemar；「目录贡献」预设对照（当前 vs 关，可加只用已核实）
- eval/cleanup.py + core/artifact_store.forget：保留最近 N 次 + 钉住的基线 + A/B 另几臂，删结果、明细工件、底下的运行和
引用行，工件文件一条引用都不剩才删；总表永久保留
- engine/tolerance.py：双盲复算的 _agree / _delta_pct 原样搬来共用（dual_check 改 import，行为不变）
- 设置加 eval 一组（builder 读、admin 写）和 GET /api/settings/eval/spend；题集预算在全站缺省上覆盖，每日上限只能往下收
- api/evals.py：发起（单臂 / A/B / 目录贡献预设）、估算、进度、逐题、停止、重试、重评、钉基线、和上一次比、配对表、清理
- main.py 的 lifespan：影子起草和评测的启动整理、关停（评测先于运行停，停时取消自己发起的运行）
- 测试：test_eval_e2e（dual_check_shop + 剧本模型：按支付日 330 通过且 SQL 等价，按下单日 310 不通过、差在 time；
目录对照 1:0；和上一次比找到退步、归因做法变）；通知事件、定时接口形状的老测试按新事件和新字段更新
|
2026-10-16 16:38:09 +08:00 |
|
|
ThearchyHelios
|
91cc150f17
|
下一轮第 3 波的契约骨架：工作流版本加表的结构版本；定时的非工作流目标按种类交给各自的模块（评测题集 app/eval/scheduled、数据源维护 app/data/source_maintenance，先放照实记「还不能发起」的占位）、record_fire 共用；分享链接、数据源变化记录、口径账本按答案出具与对账的路由先登记好权限
|
2026-10-16 15:51:33 +08:00 |
|
|
ThearchyHelios
|
9cd45ca047
|
评测题目返回给界面的说明改成合规文案：check-copy 三项规则恢复全过
check-copy 也扫后端交给界面的报错文案，nr2/c 交付时没跑这一道，有三项没过（复核 C-1）：
- 口语补语：期望 SQL 行数不够时写的「取不到值」「取不到第 N 行」，改成「没有可用的值」「没有第 N 行」；
同一处 where 匹配到多行的「取不准是哪一行」一并改成「无法确定是哪一行」。
- 禁用词「钉住」「改钉」：升版处置的叫法（UPGRADE_LABEL）和 DisposeRefused、升版状态的说明，按全站
「固定版本」的说法改成「固定的…」「改为固定新版本」，和应用、子工作流的升版说明一致。
- 半角标点和英文引号：题目 where 写错时的报错例子原来是一段 JSON，改成全角的「地区：华南」，并写明取值只能是
文字或数字（校验本来就只收这两种）。
只改文案，判断和机读码都不变。代码注释和模块说明里的「钉」不上界面，照全仓库的写法保留。
|
2026-10-16 15:23:44 +08:00 |
|
|
ThearchyHelios
|
7f14313416
|
评测题目的几处收紧：口径题只能固定已发布未退役的版本、处置升版后按新版本再核一遍、试算前结束读事务、影子起草分开记只写出一部分的表
- cases.resolve_case：口径题钉的版本没发布过或已退役的，保存时照实拒收（422，field=gold.version）；以前要等试算跑到
升版判断才说得出。
- 处置升版（recompute / incomparable）改钉新版本之前，按新版本再过一遍 resolve_case（入口字段、指标），说得清是哪一项不行。
- 接口里的试算要等一次运行跑完（最多两分钟）：先结束这个请求的读事务再等，不一直开着它（导入时同样）。
- 影子起草：只写出一部分的表另记（tables_partial），快照照出、状态 partial；一张都没起草出来才算失败、不出快照。以前
只写出一部分的表算成没起草出来，几张表都只写出一部分时整次记失败、写好的部分也丢了。
- 题集里推起草哪些表时，期望 SQL 按题集的时区渲染。
|
2026-10-16 14:05:22 +08:00 |
|
|
ThearchyHelios
|
a7e91b16a1
|
评测接口与题集导出导入、零售样例题集（第 2 波 W2-c）
- api/evals.py（骨架已登记、只给搭建者）：题集、题目的增删改查（改要带读到的 version，对不上 409；有评测记录的题集不能删，
只能归档）。保存题目时试算一次（细案 01 做法 8）：没过只读守卫、用到遮罩列、取不到值、运行失败、超时、口径升版待处置的，
照实回 422（带机器码和 field）、不保存；只改标签、启用的不重新试算。另有只试算不保存、试算已有的题。
- 从运行认定：GET /runs/{id}/queries 列出那次运行的查询（只给 SQL、列名、行数，不给格），POST …/cases/from-run 拷出一条
查询的 SQL 建题，记确认人、时间、出自哪次运行；客户端不能自己写 from_run，要改 SQL 就改成 SQL 题。
- 口径：GET /calibers 和蓝图助手同一份口径清单（能不能复用、为什么）；GET/POST …/upgrade 看、处置口径升版，
recompute / dual / incomparable 三选一、没有缺省；不可比的旧题归档、按新版本另建新题。
- 目录快照：当前目录（当场写好）、影子起草的计划和估算、后台影子起草（202）、查看、停止。
- app/eval/transfer.py：题集导出成 JSON（数据源、工作流按名字；不含期望值、答案、运行，从运行认定只带确认人和时间），导入
按名字对上、逐题过同一套校验和同一道试算关，对不上、没过的跳过并写原因，一道都导不进来就不建题集。
- tests/fixtures/eval/retail_suite.json：零售样例题集，配 tests/fixtures/acceptance/retail.py（数据源名 retail_demo，
retail.SOURCE_NAME）：支付日归属、退款、取消、华南高于华东，一道「华中区」期望没有数据，一道问法含糊期望反问。测试在
按今天生成的零售库上导入，六道题都试算通过、期望和直接查库一样、陷阱按口径算。
|
2026-10-16 13:58:36 +08:00 |
|
|
ThearchyHelios
|
2b9dcc55e3
|
评测题集与期望答案（第 2 波 W2-c）第一步：模型、派生图、期望的三种来源、目录快照与影子起草
- db/models_eval.py：EvalSuite、EvalCase、EvalRun、EvalResult 一次定全（第 3 波的执行、评分直接用），另加
EvalCatalogSnapshot 登记目录快照（谁、何时、来源、影子起草的进度和用量）。EvalResult.job_id 是 eval_run_id 的
别名：后台任务运行时的收尾按 task_model.job_id 认逐项。预算缺省按评测-D9（同时 2 题、每题 900 秒、单次 2 美元、
每日 5 美元），这一波只定字段。
- app/ledger/derive.py：全站唯一的「从钉住版本派生只读图」的生成器（总方案 X3）。这一波实现口径探针：拷出口径卡读
的取数节点（id、配置、图级 defaults 原样）+ caliber_from 固定到那一版的口径卡；只认可复用的源头卡，取数节点只许
引用入口字段，别的照实拒收。对账（这次的取数 + 口径 + 对账卡）、召回（新旧两版带前缀、caliber_from.nodes 改名
映射）的扩展点写在模块说明里，assemble / caliber_block 直接可用。
- app/eval/cases.py、suites.py：题目和题集的形状与校验。数值期望不许人填（评测-D4，写了 value 一类的键一律拒收），
文字要点单列、不计入准确率；只做单轮（评测-D12，history 必须为空）；变量只认定时任务那份 {{ schedule.* }}；
题目指纹去掉确认人、出处运行、升版处置这些记录项。
- app/eval/gold.py：SQL 题、口径题、从运行认定三种期望。每次都以来源 eval、只读 + 遮罩的探索运行重算，期望值取封存的
查询快照（或口径卡的指标集）；只读守卫拒写语句、用到遮罩列的拒收（认法同证据面板的派生遮罩）、取不到值 / 失败 /
超时 / 停在人工确认上各写各的原因。口径升版用和正式运行同一个 unresolved_caliber_upgrades 判、退役按
subgraph_pin_problems 判，待处置就跳过；recompute / dual / incomparable 三选一、没有缺省。作答前后各算一次
（bracket / settle）给第 3 波的执行调。
- app/eval/snapshots.py：目录快照存成 kind=eval_catalog_snapshot 的内容寻址工件（读法即 data/catalog_view.py 定的
那一种）；影子起草是不占数据源队的后台任务，起草写进内存里的目录副本，不调 write_entry、不碰线上目录、不查业务库，
只起草题集用得到的表，开始前估算花费；停止、出错的不出快照。
- data/catalog_draft.py 只加入口 run_shadow_draft（同一个起草引擎，唯一不同是不去业务库数有效行过滤的排除比例）；
data/catalog.py 把写库前的并入抽成纯函数 merge_draft、建起草模型抽成 build_draft_model（行为不变，影子起草和写库
用同一套并入规矩、同一个模型建法）。
|
2026-10-16 13:49:53 +08:00 |
|