从 0 到 1：构建可审计的大模型调度系统

一、什么是『可审计"

我们对可审计的定义是三个『任何』：任何一次调用可以还原完整上下文；任何一个路由决策可以解释依据；任何一笔计费可以追溯到请求明细。三者缺一，审计就有盲区。

二、设计原则：先想清楚『给谁审"

三、核心设计之一：请求级全链路追踪

每个进入调度系统的请求获得全局唯一trace_id，贯穿以下环节：

1. 接入层：调用方身份、IP、时间戳、请求摘要
2. 风控层：规则命中情况、放行/拦截决策及依据
3. 路由层：候选模型集合、五维评分快照、最终选择及理由
4. 执行层：目标模型、实际Token用量（含重试）、耗时
5. 计费层：计费规则版本、金额计算过程

关键取舍：路由评分快照必须落库。早期版本只记录最终选择，客户质疑『为什么这条请求用了贵模型『时无法回答。补上评分快照后，每个决策都可复现、可解释——这也是ROI归因分析的数据基础。

四、核心设计之二：防篡改的审计日志

审计日志采用仅追加+哈希链设计：每条记录包含前一条哈希，形成链条。后台任务周期性对链做校验点（checkpoint），并把校验点哈希同步到独立的存储介质。即便数据库管理员也无法在不被发现的情况下修改历史记录。

五、核心设计之三：多维归集与明细的一致性

报表层的『部门月度消耗』必须能与明细层的请求级记录逐级加总对上。我们采用同源计算策略：报表不是独立统计，而是从明细层物化生成，任何一方的数字不一致都是bug而非『口径问题』。这与颐科财税科技财务系统『账表同源』的治理原则一脉相承。

六、工程上的三个教训

• 日志量是设计出来的，不是攒出来的：全量请求快照的存储成本最初被低估，后来按"7天全量热存+摘要归档冷存『分层，成本降60%且审计能力无损
• 可审计性要提前设计：事后补日志必然有断点，trace_id必须在系统第一版就贯穿全链路
• 审计体验和审计能力同样重要：给客户安全团队的审计视图，查询效率决定了他们是真用还是摆设——我们把常见审计问题的查询做到了秒级

七、结语

可审计不是合规的应付动作，而是平台信任的底层结构。当客户能自己验证『每一笔账、每一次决策』，商务谈判中的信任成本会大幅下降。这大概是颐元优控从财税行业带过来的最朴素也最有效的经验：先算清楚，再谈其他。