把一次性大推理算完存成库：1PB 结果的查询工程｜洹拓科技
一、分界线不是成本，是结论会不会变
据公开报道，某研究机构发布了一套面向领域研究的预测数据库：用自家模型把对约九十亿项枚举输入的预测一次性算完，做成约 1PB 量级的公开数据集，使用者直接查询而不用自行推理。这些量级数字只作背景，不是本篇的判据。真正值得抄的是这个动作本身：把重推理从在线链路上摘下来，固化成一份可查询的数据资产。
行业里习惯用成本画分界线，高频查询就预计算，低频就现算。这条线不成立。要命的分界线是结论会不会变。模型换版、口径调整、输入依据更新，任何一条发生，整库预测结果就从资产变成待处理物。如果入库时没记录每条结论算于哪一版模型、哪一批输入，换代之后你甚至没法说旧结论是错的，只能说不知道它依据什么。预计算工程的重量不在存储侧，在版本侧。对做云服务交付的团队，这条路线还有一层含义：推理成本从按调用计费的变动开销，变成按容量规划的固定投入，报价结构、可用性承诺和故障责任划分都要跟着重排。
二、哪些任务适合预计算，哪些必须留在推理侧
适合预计算的任务要同时满足四个条件，缺一个都要重新评估。
| 判断维度 | 适合预计算 | 必须留在推理侧 |
|---|---|---|
| 输入空间 | 可穷举，条目边界清楚 | 含用户上下文，组合无法枚举 |
| 输入分布 | 稳定，短期内不漂移 | 结论与时间强相关，查得即变 |
| 下游消费方式 | 查询与批量筛选，不要求交互生成 | 对话式、生成式，答案每次不同 |
| 更新粒度 | 结果可按条目独立更新 | 一处口径变化需要全库连锁重算 |
第三条常被忽略：下游若是查询，答案允许带着口径说明返回；下游若是交互生成，用户期待的是当场组装的答复，预计算给不了。第四条是维护成本的分水岭，能按条目重算的库可以慢慢修，牵一发动全身的库每次上游变化都是一场发布。
右列还有两个坑各自要单独说。结论与时间强相关的任务，实时推理成本确实高，但硬做进预计算库，就会制造“今天查昨天结论”的事故，这类需求正确的解法是缩短重算周期而不是加缓存。单条计算成本低于存储摊销的任务，账要算全链：存储、索引、重算、对账人力、口径评审会议都在摊销里，多数低估的项目只算了磁盘单价这一项，得出反过来的结论。
三、从跑一次到给别人查，要补的六件事
跑通推理脚本只是开始，把它变成别人敢用的库，要补齐六项。
- 标识体系与主键稳定性：给每个条目一个与计算过程无关的业务标识。主键一变，下游所有引用同时失效，主键变更要当作整库变更来评审。
- 按条目可追溯的来源：每条结果至少记三项——模型版本、输入快照、计算批次。缺任何一项，事后都无法解释两条相近结果为何不同。
- 结果口径字段：置信度、适用范围、失效条件各占一个字段，与结论同一条记录返回，不允许只存在文档里。
- 冷热分层与索引选择：按主键点查、按范围扫描、按相似性检索是三种访问形态，索引方案各自不同，先统计真实查询构成再建索引，别用一套索引硬扛。
- 版本并存与切换策略：新旧两版模型的结果要能并行可读，切换按条目或按命名空间灰度，一次性整库替换等于把回归风险全部押在发布日。
- 查询配额与滥用防护：可查询的库必然招来批量爬取与全库拖取，按调用方分配额、对导出类查询单独限速，这些要在开放查询入口之前设好。
四、有效期字段与“缓存当事实”的防线
结果库最大的隐性成本是有效期语义。“某条目在什么条件下不再可信”必须有字段承载，否则使用者会拿旧结论做新决策，而且理直气壮，因为库里查出来的东西看起来就是事实。
防线有三条。查询返回里显式带出口径版本与生成批次，界面层不得为省事省略这两个字段，前端可以把它们收进次级展示，但不能不展示。审计要能反查：给一个历史结论，能查到它出自哪一版模型、哪一批输入，查不到就说明留证设计有洞。失效条件命中时，条目状态要主动变更，而不是等下一次全量重算顺手刷新——“已过期”本身是一种正确答案。
典型事故链是这样的：口径上游修订，旧结论仍可查且不带警示，新加入的使用者直接引用，等到对账时才发现一批决策建立在不再生效的预测上。链条里缺的从来不是存储技术，是一个“本条目在什么条件下不再可信”的字段，以及界面必须展示它的纪律。字段设计时把失效条件写成可判定的形式——绑定输入依据的版本、绑定覆盖范围、绑定复查日期三型，避免只填一句自由文本。
五、增量更新与全量重算的取舍
取舍看四个判据：可独立重算的条目比例，比例高就倾向增量；上游模型换代频率，换代频繁时增量补丁会堆成无人敢碰的层；单次全量重算的机时成本，超过可接受窗口就不得不拆分段的增量；是否需要双版本并行读，需要就意味着存储与索引都要按两版容量规划。
我们的经验是按季度做一次体检：抽一批高频查询条目重跑当前模型，对比库中结果，偏移率超过阈值就启动分域重算，而不是等用户投诉。重算完成的条目带着新批次号回写，未重算的条目保持原批次号可见，两种批次在查询结果里同等诚实。分域重算的前提是第三节第 2 项的来源记录足够完整：能按模型版本、输入批次、条目区间任意组合圈出重算范围，否则“增量”两个字只能靠删库重跑兑现。
六、把库当产品，把口径当交付物
洹拓给客户搭预计算层时，我们坚持三条治理动作。把结果库当产品对待：它要有自己的变更日志、字段评审和退役流程，字段增删走评审而不是写脚本的人自己定。把计算批次当台账：每一批的起止时间、模型版本、输入快照标识、覆盖条目数逐批登记，出了范围错误的结论先查台账圈定影响面。把口径说明当文档交付物：置信度怎么来的、适用范围怎么划的、失效条件有哪些，随库发布，与库版本绑定。
这套做法对 AI 应用团队同样成立。把慢推理链路里高频且答案稳定的那部分查询挑出来做成预计算层：从查询日志按命中次数选出前若干档，进层前先确认它们在第二节那张表的“适合”一侧，再配好失效与回填策略——命中过期条目时是回源现算还是明确告知待更新，要在入口层写死，不能落到默认空结果。回填策略还要防一种偷懒：把“未命中缓存”直接回源现算并把结果悄悄写回库，等于让在线流量决定数据资产的口径，写入必须走批次流程并带上第三节要求的来源三件套。慢模型不该每次都被请教同一句话；快模型也不该替一库旧答案背书。客户侧验收这份资产时，我们坚持只问三个问题：任意一条结论怎么查到它的口径版本，一次口径修订怎么圈出受影响的条目，旧版本按什么流程下线。三问都有字段和流程可答，这个库才算交付完成，否则只是把推理账单换成了存储账单。