merge origin/staging into the beta safety net branch

The fix brief is already on staging. BUG-1354 on this branch collided with an earlier answer-effort record, so the safety-net entries move to BUG-1355 through BUG-1357. Co-Authored-By: Grok (agent loop)
2026-10-15 16:04:45 +08:00
parent 53d8df257d 2d41338897
commit 6ba63470a9
35 changed files with 2074 additions and 91 deletions
@@ -0,0 +1,43 @@
+# 答题步推理强度（2026-10-15）
+
+没有模型钥匙。下面只是本机拦截到的请求体，不是供应商的接受度，也不是耗时和质量。A/B 未跑。
+
+命令：在 `frontend` 目录执行 `node node_modules/tsx/dist/cli.mjs tests/answer-effort-probe.mts --dry-run`。假请求不离开这台机器。模型对象与产品相同：`providerId: deepseek`，`modelId: deepseek-flash`，带 `url` 和假的 `apiKey`。2026-10-15 起脚本在 `frontend/tests/`，不再放在 `frontend/scripts/research/`。
+
+## 请求体里实际有什么
+
+| 形状 | thinking | reasoning_effort | max_tokens |
+| --- | --- | --- | --- |
+| 今天的答题设置，第 0 步和第 1 步 | `{ type: enabled }` | 无 | 24576 |
+| 旧的低强度设置（没有产品调用方） | `{ type: enabled, reasoningEffort: low }` | 无 | 10240 |
+| 新开关 `low` / `medium` / `high` / `max`（只在答题步） | `{ type: enabled }` | 与开关相同 | 24576 |
+| 续写 | `{ type: disabled }` | 无 | 16384 |
+
+旧的低强度写在 `thinking` 里面，请求体没有 `reasoning_effort`。这证实了任务书 §2.3。记为 BUG-1354，状态 investigating。原先写成 BUG-1351，该号已被数据层占用。线上不用这处设置。
+
+新开关写在供应商选项的最外层。兼容通道把它写成 `reasoning_effort`。开关不设时，两步请求体与改前逐字节一致，样本在 `frontend/tests/fixtures/answer-effort-switch-20261013.json`。
+
+## 供应商接受度
+
+未跑。没有 `DS_KEY` / `BACKTEST_MODEL_KEY`。`low`、`medium`、`high`、`max` 哪几档能用，要等验收时用临时钥匙跑探针的后半段。
+
+## 固定 10 题
+
+脚本已能按 `--cases` 跑下面这 10 题，并能按 `--efforts unset,low,medium` 把同一题的几档挨着跑。多档同时跑时并发降为 1，因为强度读的是进程里的环境变量，并行会串档。本机没有钥匙，这 10 题没有跑。
+
+| # | 盘 | 领域 |
+| --- | --- | --- |
+| 1 | steve_jobs | career |
+| 2 | barack_obama | parents |
+| 3 | elizabeth_taylor | marriage |
+| 4 | marilyn_monroe | parents |
+| 5 | judy_garland | health |
+| 6 | edith_piaf | marriage |
+| 7 | frida_kahlo | health |
+| 8 | george_w_bush | career |
+| 9 | zinedine_zidane | career |
+| 10 | marilyn_monroe | marriage |
+
+## 耗时与质量
+
+没有数。空答、截断、rubric、人工四项都没做。默认值维持不设。
@@ -0,0 +1,53 @@
+{
+  "charts": {
+    "serial_seconds_median": 8.0596,
+    "concurrent_skip_seconds_median": 0.0166,
+    "serial_subprocesses_median": 2,
+    "concurrent_skip_subprocesses_median": 0,
+    "summary_bytes_match": true
+  },
+  "report_forced_subprocess": {
+    "seconds_median": 16.5322,
+    "subprocesses_median": 7
+  },
+  "report_short_circuit": {
+    "seconds_median": 15.3235,
+    "subprocesses_median": 1
+  },
+  "report_bytes_match": true,
+  "schemes": [
+    {
+      "scheme": "O1",
+      "consult_429": "0.40",
+      "report_429": "0.00",
+      "score_429": "0.17",
+      "peak": 2,
+      "touches_bug_717": false
+    },
+    {
+      "scheme": "O2",
+      "consult_429": "0.00",
+      "report_429": "0.00",
+      "score_429": "0.17",
+      "peak": 3,
+      "touches_bug_717": true
+    },
+    {
+      "scheme": "O3",
+      "consult_429": "0.30",
+      "report_429": "0.00",
+      "score_429": "0.33",
+      "peak": 2,
+      "touches_bug_717": false
+    },
+    {
+      "scheme": "O4",
+      "consult_429": "0.00",
+      "report_429": "0.00",
+      "score_429": "0.67",
+      "peak": 2,
+      "touches_bug_717": false
+    }
+  ],
+  "jhora_installed": false
+}
@@ -0,0 +1,40 @@
+# 合盘排盘与报告子进程 A/B（2026-10-15）
+
+Windows 本机，工作树 `.venv` 的 `python.exe`。`importlib.util.find_spec("jhora")` 是 `None`。`python3` 指向 Windows 应用商店占位程序，`python3.14` 不存在。Docker 守护进程在，本机没有 `jyotisha-api` 镜像，所以没有进镜像再探一次。本机没有 VedAstro SDK，外网关闭（`VEDASTRO_ENABLE_NETWORK=0`）。没有「真 SDK」一组。
+
+脚本：`scripts/research/api_chart_subprocess_ab.py`。每组 3 次，取中位数。盘是任务书里的虚构盘（1990-01-01 12:00 与 1992-01-02 12:00，新德里）。星盘缓存 TTL 设为 0。易变字段在比对前丢掉：`generated_at`、`created_at`、`timestamp`、`elapsed_seconds`、`elapsed_ms`、`duration_ms`、`request_id`。原始数字在同目录 `api-chart-subprocess-gate-ab-20261013.json`。
+
+对照不是另一次 `git show` 出 staging 再导入。星盘对照是本分支的 `_compute_chart_sync`：不带 skip、两张盘串行。报告对照是本分支把「参照引擎已安装」强制打开，从而仍会起子进程；静态校验缓存和解释器查找缓存两边都开着。所以报告耗时差只含那 6 个注定失败的回放进程，不含静态校验少跑的那一次。静态校验「连调两次只跑一次」由单测覆盖。
+
+## 合盘两张盘
+
+| | 中位耗时 | 中位 `subprocess.run` 次数 | 盘面摘要 |
+| --- | --- | --- | --- |
+| 对照：不带 skip，串行 | 8.0596 秒 | 2 | — |
+| 本单：带 skip，并发 | 0.0166 秒 | 0 | 与对照逐字节一致 |
+
+0.0166 / 8.0596 ≈ 0.2%，低于「不超过对照 10%」的线。子进程从 2 降到 0。任务书写的「4 → 0」是按每张盘 2 个子进程、两张合计 4 个来估的。这台机器上两张盘合计只数到 2 次 `subprocess.run`。不带 skip 的 8 秒里，大部分是没装 SDK 时子进程空等，不是盘面计算本身。
+
+## 个人长报告（完整数据版，中英，带事实表）
+
+| | 中位耗时 | 中位 `subprocess.run` 次数 | 中英正文与事实表 |
+| --- | --- | --- | --- |
+| 对照：强制仍起回放子进程 | 16.5322 秒 | 7 | — |
+| 本单：没装参照引擎就不起 | 15.3235 秒 | 1 | 去掉易变字段后逐字节一致 |
+
+少 6 次，对应年度回放 3 次和 Tajika 3 次。剩下的 1 次两边都有，短路没有把它去掉。子进程数 1，低于「模拟生产不超过 3」的线。耗时 15.32 秒，不比对照的 16.53 秒差。本机没装 PyJHora，没有再跑「装了参照引擎」的一组；那种环境仍必须走子进程，单测用桩覆盖。
+
+生产上的收益仍按任务书：大约每份报告 0.5 到 0.9 秒，不是装了参照引擎的机器上看到的约 5 秒。
+
+## 名额方案模拟（没改规则）
+
+固定一分钟：2 份报告（每次 13 秒）、20 次咨询（每次 0.2 秒）、6 次校正打分（每次 8 秒）。随机种子 64。并发上限按现状 2。O2、O3、O4 只在脚本里模拟。
+
+| 方案 | 咨询被拒 | 报告被拒 | 校正被拒 | 同时在跑的最高个数 | 是否碰到「不得加池、不得提高并发」 |
+| --- | --- | --- | --- | --- | --- |
+| O1 现状 | 40% | 0% | 17% | 2 | 否 |
+| O2 咨询单独小池 | 0% | 0% | 17% | 3 | 是，本单不实现 |
+| O3 咨询最多再等 1.5 秒 | 30% | 0% | 33% | 2 | 否，本单不实现 |
+| O4 重任务最多占 1 个名额 | 0% | 0% | 67% | 2 | 否，本单不实现 |
+
+这是一分钟的草图，不是 staging 上的真实频率。咨询少被拒的时候，校正会多被拒（O3、O4）。O2 咨询不再被拒，但同时在跑的个数到了 3，越过了现在的上限。