 ThearchyHelios
|
4aa3e6f01f
|
评测估算和每题平均花费：有估不出金额的调用时不再写成 0 美元
价格目录里没有助手模型时（真实模型验收的接入就是这样），第一次评测估不出、照实写了；第二次起估算按上一次的每题平均
花费算，而每题平均是「估得出的那部分」除以题数 = 0，开跑对话框写「约 $0」、评测总览写「每题约 $0」，像不花钱。
- eval/stats.summarize：每题平均花费一分都没估出来（有估不出的调用、估得出的部分是 0）时为 None，估出了一部分的照给；
- eval/runner.estimate：上一次的调用金额都估不出时照实写估不出（带次数和原因，金额上限只管得住估得出的调用）；估出了一部分
的标 at_least、带上另有几次估不出，说明写「实际至少这么多」；老总表里每题平均记成 0、却有估不出的调用的也按估不出算；
- 按角色用量里裁判那一份（runner.judge_usage）补上估不出的次数：以前只有金额和次数，裁判模型不在价格目录里时写成 $0；
- 评测页：开跑对话框估出一部分时写「至少约 …（每项至少约 …）」，总览的每题平均有估不出的写「每题至少约 …」，一分都没估出来
的不写（金额那一格已是「金额无法估算」）。
providers/usage 的汇总形状不变：cost_usd 是估得出的那部分、unpriced_calls 是估不出的次数，和运行的 usage 是全系统一个口径
（细案 01 做法 3 定的），前端的金额写法（runCostText）一直按这两项一起写「≥」或「金额无法估算」；漏掉的是只读 cost_usd 去算
平均、做估算的这几处。模块说明里把这条写明了。
测试：test_eval_stats.py::test_the_per_case_cost_is_not_zero_when_calls_could_not_be_priced、
test_eval_runner.py::test_the_estimate_says_it_cannot_price_instead_of_zero（全估不出、估出一部分、目录价是 0 的才是真
不花钱）、test_eval_runner.py::test_the_judge_role_keeps_its_unpriced_calls。去掉修复回跑三条都失败。
|
2026-10-17 11:40:27 +08:00 |
|
|
ThearchyHelios
|
3c4dbe0c02
|
没做完的模型调用也计一次：挑表超时被取消的那次不再漏掉
真实模型验收里，挑表（look/pick 的 asyncio.wait_for）超时被取消的那次调用一点都不计：LangChain 的 ainvoke 被取消时
卡在 agenerate 的 gather 上，on_llm_error 根本走不到；astream 被取消时会回调，可一段都没收到的又被当成「请求刚发出去
就被拒了」不计。问数据一轮、评测按角色的调用次数因此少一次。
providers/usage.Meter 现在多记一项 unfinished（汇总里是 unfinished_calls）：被取消、超时（按异常类型认，含各家 SDK 的
…Timeout）、流读到一半被关掉的调用都记一次调用、标未完成，token 只计已经报了的（一段都没收到的记 0、算没报全，
金额也就估不出）；开始了、到汇总（和嵌套并入外层）时还没有结束回调的调用一并算未完成。请求一发出去就被拒的仍不计。
评测汇总相加（eval/answer._add_usage）带上这一项；评测页按角色的用量写「其中 N 次未完成」；问数据页的这一轮用量
相加时也留着它。
测试：test_usage_meter.py::test_a_call_cancelled_before_any_result_still_counts_as_an_unfinished_call（ainvoke 被
wait_for 取消、look/pick._ask 超时、astream 收到一段输入用量后被取消、被拒的不计）；by_model 的形状多了一项，
test_metering_counts_by_model_and_prices_from_the_catalog 和评测同口径那条跟着改。去掉修复回跑失败。
|
2026-10-17 11:36:50 +08:00 |
|
|
ThearchyHelios
|
06c1e8bd25
|
逐题 E1 比产出答案的那条查询：答案没引用、又查了几条时不再硬比第一条
真实模型验收里，答案没有引用查询时逐题 SQL 比对取了第一条相关的查询，取到的往往是探索查询（看看有哪些地区那种），
「差在筛选条件」和答案的数毫无关系。现在 score.sql_match 先定哪条是产出答案的（_answering）：答案引用了查询就比被
引用的那几条；没引用、这次运行（核查用的不算）只查了一条，答案的数只可能来自它，按它比、结果里写明依据
（basis=only_query）；没引用、查了几条的不比，照实写「答案没有引用查询，这次运行执行了 N 条查询，没法对上是哪条
产出了答案」，记「没比对」、不计入 E1。答案引用的只有合并查询时也照实写没法比。
评测页逐题明细在依据是「只查了这一条」时写一句说明（文案在 termsEval 的 sqlMatchBasis，类型加 basis）。
算第 2 版评分规则的一部分：老评测按新规则重新评分时逐题 E1 跟着重比。
测试：test_eval_score.py::test_the_per_case_sql_match_compares_the_query_behind_the_answer（先探地区再查销售额、
答案没引用：不比；只查一条、答案没引用：按它比并写明依据；去掉修复回跑失败——修复前比的正是探地区的那条）。
|
2026-10-17 11:33:35 +08:00 |
|
|
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
|
eb6abffc61
|
评测逐题结果给出这一题实际问的问题，模板原文另放 question_template
验收：评测结果列表里 question 是原始模板（带 {{ schedule.last_week_start }}），作答运行实际收到的问题已经渲染好了。
results 接口直接取的是 EvalCase.question。
改法：api/evals 的 _asked_questions 按执行时同一个算法、同一组输入渲染：题目模板 + 这次评测的截至时间（as_of，
建评测时就定下、重试不变）+ 题集时区 + 定时的 cron（runner._unit 交给 Driver 的就是这个）。题目在这次评测之后
改过（结果记的 case_hash 对不上现在的）时，现在的模板不一定是当时问的：改取作答运行输入里的 question，也没有
（反问、建图失败没有运行）就给 null，不拿现在的模板编一个。模板原文放 question_template。没有加库表的列：
渲染是确定的，不用另存。
前端：评测页逐题表的问法一格写实际问的问题；模板原文和它不同时（带变量，或题目改过）另起一行「题目原文：…」，
文案进 termsEval。类型补上 question_template。
测试：test_eval_runner 新增一条：带变量的题，结果的 question 和作答时 Driver 收到的一字不差、不含 {{，模板原文在
question_template；没有变量的题两者一样；题目改过、没有作答运行可取时 question 为 null、模板照给。去掉修复回跑挂。
check-evals 的夹具给带变量的那一题配上渲染好的 question 和模板原文，核对逐题表写的是实际问的、原文另起一行，
没有变量的题不多这一行。tsc、check-copy 通过，check-evals 102 项全过（漏到服务端的那个偶发问题另一次提交里修）。
|
2026-10-17 09:02:57 +08:00 |
|
|
ThearchyHelios
|
45c1ede402
|
评测前端：顶级导航「评测」、题集与加题、发起评测、评测详情、口径命中与重复度、目录快照；定时页选目标种类；记录页评测来源；设置里评测一组
为什么：前三波评测只有接口，这一波是收口——每样能力都要有界面、能走通（细案 01 第 18 项、第 15 项定时的前端部分，评测-D8）。
界面层不放逻辑：比率、结论、趋势、分档、能不能做都由服务端给（上一次提交在 api/evals.py 补的 latest、trend、actions、
preview、signals、逐题花费），界面只显示。
- 导航：「评测」排在设置前面、⌥0，搭建者以上可见（使用者的页面表在 visiblePages 里收窄，手输地址被送回应用首页）。导航从 9 项
变 10 项，在 600、520、480 像素高的窗口里重新量过：≤520px 那档的导航项从 32px 收到 30px（17px 图标 + 2px + 11px 字），
不然 480 高时遥测点超出视口 12px；App.tsx 的说明跟着改。
- 评测页 pages/evals/*（类型 typesEval.ts、接口 api/evals.ts、文案 lib/termsEval.ts 的 EVAL_TEXT）：题集列表（最近一次、同一
变体的趋势、定时，没有定时给「设定时」带着题集去新建）；新建、导入（先预览）、导出、归档、删除、题集设置（时区、默认变体——
定时评测按它评、预算只填要改的项）；题目表（启用、试算、编辑、删除），口径升版待处置的顶部提示和三选一处置（叫法由服务端给，
没有缺省）；加题四种方式：写 SQL 定期望（选数据源、写 SQL、预览、点选格 / 列 / 配对列、按维度找行、试算，遮罩列拒收的原话
落在 SQL 下面）、选口径（工作流｜口径卡｜指标，不能复用的照列写原因，口径的输入按那一版的入口字段填）、从问数据运行认定
（选运行、选查询、选取哪一列，用到遮罩列的查询不给认定）、期望没有数据或期望反问；可另加文字要点。数值期望不许人填：只点选
取哪一格。
- 发起评测：评一次 / A/B 对照（两到三臂）/ 目录贡献对照（预设，可加「只用已核实和已确认的项」），变体有助手、写作模型、结论
裁判、目录（当前 / 只用已核实的 / 关 / 快照）、重复次数；估算和发起是同一份请求体，项数、按上一次估的花费、生效的预算、今天
已花照服务端写；可点名和哪一次比。
- 评测详情 /evals/runs/:id：进度和每题正在做什么、停止、只重试没做完的、按新规则重评、设为基线（按钮照服务端的 actions 摆）；
总览卡片（准确率和可追溯准确率带区间、花费、逐题 E1）和各项分布（结论、作答路径、出具档位、复核、结论裁判、引用率、查看、
耗时、按角色的用量）；逐题表（结论、期望和答案里的数、弱匹配、SQL 差在哪、查看、耗时、花费，展开看原因、去运行详情；
?case= 定位那道题）；和上一次比（换基准、指纹差异、转移和归因）；A/B 配对表（都对 / 只 A 对 / 只 B 对 / 都错、p 值）。
- 「口径命中与重复度」页签：E1、E3 这一窗口的值和档位、参考线、往前几个窗口的趋势（GET /api/evals/signals），明细直接调口径
账本的 GET /api/ledger/stats（总方案 X2）；成员不少于 3 的问题类能加入题集（带着问法去加题）、提取模板（从最近一次的运行提取，
去画布）。目录快照页签：拍当前目录、影子起草（先估算再开始，能停）。
- 定时页：新建时先选定时什么（工作流 / 评测题集；数据源维护在数据源页建），评测题集的表单（pages/schedules/TargetEditor.tsx：名称、题集、
FreqPicker、补发宽限，建题集目标用 ScheduleTargetCreate），评测题集的定时在详情里能改名称、频率、时区、补发宽限（SchedulePatch，
只交改了的、带版本）；数据源维护的定时只读、链到数据源页，第 3 波「只能查看，不能修改」那句改成说清在数据源页设置；触发历史里
的评测链到评测详情。纯函数 targetFormOf / targetCreateBody / targetPatchBody / targetProblems 放 model.ts。
- 记录页：评测运行旁的「评测」标记写是哪一步（作答、算期望……），点了回到评测里那道题；运行详情页头有键盘到得了的链接
（pages/runs/EvalSource.tsx）。
- 设置：偏好设置里「评测」一节（pages/EvalSettings.tsx，SettingsPage 里加一行）：四项预算缺省、保留几次、缺省开不开结论裁判、
今天已花；自己存、只交 eval 一组，取值范围只在服务端判。
- 问数据用量（评测-D14 的界面一半）：复核慢过问数据页的等待上限时，答案照原样先交出去，复核那一次的用量晚到了照记进这一轮、
再落一次库（以前直接丢掉）；开发期 window.__chatReviewWait 让检查脚本把上限调短。
检查：check-evals.mjs 换成真检查（假接口加夹具，写请求在浏览器层拦下并断言请求体，98 项）；check-shell 导航十项、⌥0、三种窗口高；
check-schedules 目标种类（纯函数和页面）；check-chat 用量那一段加复核晚到。
|
2026-10-16 20:38:07 +08:00 |
|