Repository navigation
[Design] 审计记账可信性——降本结论的前置检查表 #317
Description
背景
审计 7 天窗口 235 条后台 LLM 调用，input/output/total_tokens 非零行数 = 0。根因：宿主 dsh-llm 的流式协议把用量嵌在 chunk.usage（TokenUsage）内，记账却从 chunk 顶层取字段 → 恒 undefined → 全落 0。修复见 #242 / #248（改读 chunk.usage ?? chunk，补真实协议形状用例）。
它长得像「成本很低」，实际是「没统计过」。
原则
- 记账可信是降本结论的前置条件：任何「降本」结论，先校准尺子。
- 零值必发：用量类列出现 0 不允许静默；长期为 0 的计数器，最可能的解释不是「从没发生过」，而是「从来没统计过」。
- 缺失值 ≠ 正常值：「真没用量」与「没记账」在账上必须是两个不同的格子。
设计要点（EigenFlux 网络多 agent 对拍收敛）
| # | 要点 | 内容 |
|---|---|---|
| 1 | usage_source_layer + usage_read_path |
「从哪读的」是一列数据不是注释（stream chunk / final response / 独立 usage API） |
| 2 | samples_n + nonzero_n 双列 |
全 0 与「真没用量」在表上是两个不同格子 |
| 3 | sample_set_digest |
数量对上但集合不同时，零值仍可能来自错的那批——计数线会显示一切正常 |
| 4 | readback_verified_by + readback_epoch + readback_layer |
计量写库后回读；回读人与写入人不同源；回读层 ≠ 写入层（同层回读 = 同一副本读两遍） |
| 5 | zero_since + zero_last_nonzero_at 同行 |
区分「一直为零」与「从未观测到非零」——两者处置相反（结论 vs 告警） |
| 6 | 无 usage chunk 的边界 | 巩固照常成功、审计落 0——未知≠错误，不崩也不编数（#248 已锁用例） |
| 7 | 计数类字段必带签发方 | (count_issuer, count_computed_at)，issuer 不得属于被观测方故障域（不能自证） |
对齐证据
- 同构：
unknown ≠ zero显式报告、unknown_since_epoch（bounded-drain 侧）；UNENFORCED vs NOT_COMPARABLE 同形；ratio_change_event口径变更独立回执。 - 应用侧：OpenAI 兼容流式
stream_options.include_usage未设时 usage 缺省 null，错误层读取者静默记零。
落地
- 挂本 issue 前置检查表：降本结论前置 = 记账可信。
- 审计 schema 演进时按要点 1-7 补列。
Activity
modusensus commentedon Sep 26, 2026
关联 #239（成本感知级联）：本设计稿作为其「记账可信性」前置检查表——任何降本结论的验收都先过记账可信这一关（对应 #239 验收清单『日志可见 skip 原因统计』的度量链前提）。
modusensus commentedon Oct 11, 2026
对着现列核过一遍（
src/store.js:190-206：id / timestamp / trigger_source / operation_type / model_id / input_tokens / output_tokens / total_tokens / cost_usd / duration_ms / status / error_message / related_memory_ids / metadata / session_key）。7 条要点转成可核对的检查表：usage_source_layer+usage_read_pathsamples_n+nonzero_n.../semantic/llm-audit/stats（按 source/status），不区分「真零」与「未观测」sample_set_digestreadback_verified_by/epoch/layerzero_since+zero_last_nonzero_attest/llm-audit.test.js:318「no usage chunk at all still writes 0 tokens and never crashes」，另有 :299 / :336 两条协议形状锁count_issuer+count_computed_at关本 issue 的理由：要点 6 已被测试锁死，1–5/7 全部是「等
llm_audit_logs下次演进按此表补列」，本身不产生独立可执行的代码任务。最近一次演进锚点是 #254 加的session_key。三条原则（记账可信是降本前置 / 零值必发 / 缺失值≠正常值）不动，继续作为降本结论的口径要求。