the-mindscape-of-bro-tsong/knowledge_assets/09_数据治理与模型调用机制说明.md

数据治理与模型调用机制说明

version: 0.1

last_updated: 2026-06-17

status: stable explanatory asset

source_basis:

• C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\CCRA_数据治理与模型调用机制说明_v0.1.md
• current repository contracts, selector rules, regression files, validation scripts, and review-bundle workflow

1. 文档定位

本文档是 model_library_mvp 阶段的数据治理与模型调用机制说明。

它不是某一轮评审的 PASS / FAIL 记录，也不是对 Owner 质疑的逐条回复。它沉淀的是长期可复用的项目机制：

• 为什么模型库不等于普通知识库；
• 文章、模型卡、selector、regression、validation、review bundle 分别承担什么治理职责；
• QPI 和思想考古学未来如何被调用；
• 哪些文件是长期源头，哪些只是过程证据；
• 后续新增模型应按什么最低资产结构进入系统。

具体模型内容的 source of truth 仍在：

• models/*.model.json
• cards/*.md
• sources/*.json
• tests/*.regression.json
• selector/*.json

本文档只解释机制，不替代上述文件。

2. 项目当前性质

the-mindscape-of-bro-tsong 当前处于 model_library_mvp 阶段。

它不是：

• 完整产品；
• 聊天机器人；
• 前端平台；
• 后端服务；
• RAG 系统；
• 知识图谱；
• 数据库应用；
• 商业交付系统。

它当前验证的是：

少量核心认知模型
能否被整理成 file-first 的模型资产，
并具备可读、可追溯、可调用、可拒绝调用、可测试、可路由的最低能力。

第一批样板模型是：

• QPI：前置问题定性和路由模型；
• 思想考古学：中重型问题的深度建模模型。

QPI 的价值不只在于它本身，而在于它能压力测试一整套模型治理机制：调用条件、拒绝条件、输出契约、误用边界、selector 校准、regression 防退化、Owner / CCRA 审核。

3. 为什么不是直接把文章喂给 AI

如果只是让 AI 读取文章并回答问题，确实不需要模型库结构。

但这种做法不满足模型资产化要求：

• 不可追溯：很难回查系统用了哪篇文章、哪段证据、哪条人工判断；
• 不可稳定调用：同一输入可能每次触发不同判断和输出结构；
• 不可拒绝调用：模型容易被滥用，例如所有复杂问题都套 QPI 或思想考古；
• 不可回归：改规则后无法知道旧边界是否被破坏；
• 不可交接 Codex：Codex 不能只凭一篇文章稳定构造 schema、selector、validator 和测试；
• 不可产品化：文章是内容资产，模型库需要可组合、可运行、可验证的认知工具资产。

因此本项目做的是：

原始文章 / 人工素材
-> 来源记录
-> 证据片段
-> 人读模型卡
-> 机器可读模型卡
-> 输出契约
-> 调用规则
-> 负向触发条件
-> selector
-> calibration input
-> regression cases
-> validation scripts
-> review bundle
-> Owner / CCRA 审核意见

这些文件不是平行内容，而是不同治理层。

4. 数据治理的六个目标

4.1 来源治理

每个模型必须知道它从哪里来：

• 来源文章是什么；
• 代表性文本是什么；
• 哪些字段由原文直接支持；
• 哪些字段是从原文推导；
• 哪些字段是产品化决策；
• 哪些字段是 Owner / CCRA 人工判断；
• 哪些证据仍是 placeholder 或需要复核。

目标是防止模型后来变成“像作者思想，但已经无法回到原文”的漂移资产。

4.2 结构治理

模型不能只是一段定义。

每个模型至少要被拆成：

• model_id
• model_type
• pipeline_position
• 核心问题
• 核心机制
• 输入类型
• 输出类型
• 适用场景
• 不适用场景
• 负向触发条件
• 常见误用
• 失败信号
• 稳固性等级
• 输出契约

结构治理让模型既能被人审，也能被机器读取。

4.3 调用治理

模型进入系统后，不能默认“能用就用”。

每个模型都必须回答：

• 什么输入应该调用它；
• 什么输入不该调用它；
• 是否必须先经过其他模型；
• 是否只能在某个流程阶段使用；
• 是否需要重型分析门槛；
• 是否存在 hard no-call 条件；
• 是否存在 explicit analysis override。

这就是 selector 的职责。

4.4 输出治理

模型输出不能随意发挥。

以 QPI 为例，它不是简单输出“这是 Question / Problem / Issue”，而是必须围绕主体、场景、责任范围、期望现实落差、主导稀缺物、分类置信度、证据缺口、误分类风险、下一步候选模型等字段工作。

以思想考古学为例，它不能无限哲学化，而是必须说明是否应该调用、为什么调用、最多下潜到哪层、哪些层需要分析、什么时候停止。

4.5 边界治理

解释力强的模型更容易被滥用。

典型误用包括：

• 暴力降维：把复杂 Issue 当成简单 Problem；
• 恶意升维：把简单执行任务夸大成复杂课题；
• 手段错配：本该查资料，却启动深度模型；本该组织协商，却只做文档润色；
• 认知重工业化：一个轻量问题被多模型、多智能体、深层考古压爆。

边界治理不是削弱模型，而是让模型该用时有力，不该用时安静。

4.6 生命周期治理

模型不能因为 JSON 能解析、schema 通过、demo 能跑，就升级为 stable。

升级至少需要经过：

• evidence review；
• content review；
• regression review；
• selector review；
• Owner / CCRA review。

当前 QPI 和思想考古学仍保持：

status: draft
stability_level: B
regression_status: pending

draft-callable 只能作为评审报告语言，不能替代模型生命周期字段。

5. 文件身份治理

项目中的文件应按身份区分，而不是都视为同等资产。

文件身份	是否长期保留	典型路径	作用
Canonical source of truth	是	models/*.model.json, cards/*.md, sources/*.json, tests/*.regression.json, selector/*.json	模型本体、来源、测试、调用规则
Stable governance docs	是	docs/*.md, knowledge_assets/*.md	长期规则、协议、解释层
Generated / derived artifacts	可重建，但可保留报告	models/model_index.json, cards/card_index.md, reports/*_report*.md	检查、导航、验证结果
Round / review artifacts	阶段归档	ccra_review_bundle/round-*, reports/Codex*.md	交接和审核证据
Temporary / cache files	不应提交	__pycache__/, *.pyc, 临时 zip 展开目录	本地运行产物

判断标准：

回答“以后一直怎么做”的文档，可以进入 docs/ 或 knowledge_assets/。
回答“这轮做了什么、哪些 PASS/FAIL”的文档，应留在 reports/ 或 ccra_review_bundle/。

6. 主要文件层

6.1 来源层

用途：回答“模型从哪里来”。

典型文件：

• sources/source_articles.json
• sources/source_excerpts.json
• sources/evidence_coverage.matrix.json

6.2 人读模型层

用途：让 Owner、CCRA 和协作者读懂模型。

典型文件：

• cards/qpi.md
• cards/intellectual_archaeology.md
• cards/card_index.md

6.3 机器模型层

用途：让 selector、validator、未来运行时读取模型。

典型文件：

• models/qpi.model.json
• models/intellectual_archaeology.model.json
• models/model_index.json

6.4 契约与规则层

用途：约束模型卡、输出字段、数据结构和调用规则。

典型文件：

• schemas/model_card.schema.json
• docs/DATA_CONTRACT.md
• docs/QPI_CONTEXTUAL_ROUTING_RULES.md
• docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md
• docs/DECISIONS.md

6.5 Selector 层

用途：决定当前输入该调用哪些模型，以及不该调用哪些模型。

典型文件：

• selector/selector_rules.json
• selector/selector_examples.json
• selector/selector_calibration_inputs.json
• selector/qpi_case_digests.json
• scripts/run_selector_demo.py
• scripts/run_selector_regression.py
• scripts/run_selector_calibration_smoke.py

6.6 Regression 层

用途：保护模型边界，避免以后修改规则时把模型改坏。

典型文件：

• tests/qpi.regression.json
• tests/intellectual_archaeology.regression.json
• tests/regression_cases.json

6.7 Validation 层

用途：机械检查文件是否一致、字段是否完整、index 是否漂移、模型卡是否同步。

典型文件：

• scripts/validate_model_library.py
• scripts/check_card_contract.py
• scripts/check_model_card_sync.py
• scripts/rebuild_indexes.py
• reports/validation_report.md
• reports/index_rebuild_report.md
• reports/model_card_sync_report_v0.2.md

6.8 Review Bundle 层

用途：每轮把 Codex 工作打包给 CCRA / GPT 审核，避免散文件上传。

典型文件：

• ccra_review_bundle/round-XX_YYYY-MM-DD_topic/00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
• ccra_review_bundle/round-XX_YYYY-MM-DD_topic/BUNDLE_FILE_MANIFEST.md
• ccra_review_bundle/round-XX_YYYY-MM-DD_topic/optional_raw_changed_files.zip

Review bundle 是交接层，不是长期核心资产。

7. Selector 机制

Selector 是模型库的入口调度器和误召回防火墙。

它不负责回答问题。它负责判断：

• 当前输入是否需要模型加工；
• 如果需要，优先调用哪些模型；
• 哪些模型应该被拒绝；
• 拒绝理由是什么；
• 是否命中 no-call；
• 每个模型的分数、触发信号、惩罚项是什么。

当前 selector 仍然是 rule-based，不是 LLM selector。

基本流程：

输入
-> 检查 hard no-call
-> 检查 explicit analysis override
-> 检查模型触发词
-> 检查复杂度信号
-> 检查模型特定 gate
-> 计算 score
-> 输出 selected / rejected models

7.1 为什么当前不用 LLM selector

当前阶段最重要的是可审计。

LLM selector 可能更灵活，但会带来：

• 为什么选这个模型说不清；
• 为什么拒绝另一个模型说不清；
• 修改后是否破坏边界不好测；
• 容易把所有复杂问题交给重型模型；
• 不利于 Codex 本地测试和回归。

规则 selector 更保守，但更可控。

7.2 Selector 的核心价值

Selector 保护三件事：

1. 防止不该调用时调用：明确事实查询、轻量改写、直接执行任务不应启动 QPI 或思想考古。
2. 防止重型模型过早进入：思想考古学不应仅因出现“底层”“模型”“哲学”等词就被召回。
3. 让模型组合可解释：未来不是一个模型回答所有问题，而是多个模型按流程协作。

8. Regression 机制

Regression 在本项目中不是普通单元测试，而是模型边界保护机制。

它要回答：

• 该调用模型时是否调用；
• 不该调用模型时是否拒绝；
• Q / P / I / mixed / no-call 是否被误判；
• mixed 输入是否暴露证据缺口；
• 是否出现暴力降维；
• 是否出现恶意升维；
• 是否把轻量问题过度重型化；
• 是否把深度模型误召回；
• 修改 selector 后，过去关键边界是否被破坏。

Regression case 是“防止系统退化的钉子”，不是普通示例。

至少覆盖：

• positive
• boundary
• misuse
• no_call
• selector_gate
• pipeline

9. Digest、Calibration、Regression 的区别

以 QPI 为例，Owner 提供人工素材后，Codex 将材料拆为 .cases.md、digest、calibration、regression 四层。

9.1 .cases.md

人读的案例审阅稿。

作用：

• 保留原始案例；
• 保留 Owner / GPT 审查判断；
• 保留人能看懂的推理；
• 便于后续人工复核。

9.2 Case Digest

压缩后的结构化案例摘要。

作用：

• 让案例变得可检索、可审计；
• 保留核心分类、主导稀缺、误用风险、边界说明；
• 作为 selector / regression 的候选素材池。

Digest 是案例资产层，不是最终测试层。

9.3 Calibration Input

给 selector 调参和校准用的输入。

作用：

• 告诉 selector 哪些输入应该选 QPI；
• 哪些输入应该 no-call；
• 哪些输入应该低优先级；
• 哪些输入需要先 QPI 再进入思想考古；
• 哪些输入容易误召回。

Calibration 是“调方向”。

9.4 Regression Case

高价值边界测试。

作用：

• 以后每次改规则都要检查；
• 防止关键边界被破坏；
• 不要求覆盖所有案例；
• 只保留最容易出错、最值得保护的判断。

Regression 是“守底线”。

10. QPI 调用机制

QPI 不是最终答案模型，而是入口路由模型。

它处理的不是“怎么解决问题”，而是：

当前输入到底是什么性质的问题？

运行方式：

用户输入
-> selector 判断是否需要 QPI
-> QPI 分析主体、场景、责任范围、期望—现实落差
-> 判断主导稀缺物
-> 输出 Q / P / I / mixed / no-call
-> 给出证据缺口、误分类风险、下一步模型候选
-> 进入后续模型或直接行动

QPI 的五种结果：

QPI 输出	含义	系统下一步
Question	数据不足	搜索、查证、补信息
Problem	路径、方法或资源不足	做方案、流程、SOP、资源约束分析
Issue	共识、秩序、确定性或治理结构不足	做多视角分析、动态权衡、思想考古或冲突处理
mixed	多类稀缺同时存在	拆分问题，分别路由
no-call	不需要问题定性	直接执行、改写、翻译、查事实、整理格式

QPI 不应直接输出组织、人事、法律、财务、运营解决方案。

它最多回答：

• 这是什么类型的问题；
• 为什么这样分类；
• 证据是否足够；
• 误判风险是什么；
• 下一步应该进入哪类处理。

11. 思想考古学调用机制

思想考古学不是默认分析流程，而是深度建模模型。

适合使用的条件：

• 问题表层现象很多，但底层假设不清；
• 需要识别概念、模型或判断背后的深层机制；
• QPI 已判断这是中重型 Problem / Issue；
• 继续下潜会改变判断、路径、验证方式或行动边界。

不适合：

• 明确事实查询；
• 低风险轻量改写；
• 用户只需要直接执行；
• 材料不足，无法区分真实假设和空泛哲学化表达。

关键原则：

最小充分下潜。
如果继续下潜不再改变判断、路径、验证方式或行动边界，就应停止。

未来系统不是“QPI 一调用就自动思想考古”，而是：

QPI 先判断问题性质
-> selector 判断是否满足思想考古 depth gate
-> 思想考古只分析必要层级
-> 达到充分深度就停止

12. 未来新增模型的最低资产结构

每个未来模型都不应只是一个概念。

最低需要七类资产：

1. 人读解释：cards/*.md
2. 机器可读定义：models/*.model.json
3. 来源证据：sources/source_articles.json、sources/source_excerpts.json
4. 调用规则：selector/selector_rules.json、selector/selector_calibration_inputs.json
5. 输出契约：模型 JSON 中的 structured_output_contract
6. 回归案例：tests/*.regression.json
7. 审核与版本状态：reports、review bundle、model/card index

新增模型不得用来绕过当前模型边界未稳定的问题。

13. 未来运行时调用流程

未来真正运行时，系统可按以下流程工作：

1. 用户输入问题 / 话题 / 文本 / 任务

2. 输入预处理
   - 识别语言
   - 判断是否是直接执行任务
   - 判断是否需要认知加工
   - 抽取显性任务目标

3. Selector 路由
   - 先检查 hard no-call
   - 再检查 explicit analysis override
   - 再根据模型触发条件打分
   - 输出 selected / rejected models、分数和理由

4. 前置模型
   - 常见情况下先调用 QPI
   - QPI 判断 Q / P / I / mixed / no-call
   - 输出下一步模型候选

5. 深度或专项模型
   - 如果是中重型 Problem / Issue，可能进入思想考古
   - 不满足 gate 的模型不得调用

6. 多模型结果汇总
   - 比较不同模型输出
   - 标记冲突
   - 标记证据缺口
   - 标记适用边界

7. 输出给用户
   - 包含判断路径、模型调用理由、边界、下一步动作

8. 记录反馈
   - 用户纠正分类或边界
   - 重要反馈进入 calibration 或 regression

14. Codex 运作原则

后续 Codex 应遵守：

1. 不把 GPT 规划直接当本地规则，必须先本地化为 schema、workflow、validator、index。
2. 不把文章摘要当模型抽取。
3. 不把模型卡完整当成模型稳定。
4. 不把 selector demo pass 当成内容稳定。
5. 不把 validation pass 当成 Owner 审核通过。
6. 不因为素材增多就无限扩展 regression。
7. 不把 calibration 全部升级成 regression。
8. 不新增模型来解决当前模型边界没稳定的问题。
9. 每个新增文件必须说明身份：canonical / generated / report / temporary。
10. 每轮交接必须用 review bundle，不让 Owner / CCRA 面对散乱文件。

15. 与 GPT 知识库同步的关系

knowledge_assets/ 是长期解释层。

Owner 可以手动将其中稳定文档同步到 GPT 知识库。评审包不应重复打包 knowledge_assets/，除非某轮评审明确要求审核长期资产本身。

当前规则：

• 长期机制说明放在 knowledge_assets/；
• 当前执行资产放在 models/、cards/、selector/、tests/、scripts/；
• 每轮评审资料放在 ccra_review_bundle/round-*；
• optional_raw_changed_files.zip 应保留源路径，避免扁平化覆盖；
• knowledge_assets/ 默认不放入评审 zip，由 Owner 自行同步到 GPT 知识库。

16. 结论

本项目不是把少量文章堆进知识库。

它在做的是：

把文章形式存在的个人认知模型
转化为可被 AI 软件稳定调用的模型资产库；
同时建立调用门、拒绝门、输出契约、边界测试和人机交接机制。

QPI 是第一个压力测试样板。

思想考古学是第二个深度模型样板。

Selector 是模型调用的守门员。

Regression 是模型边界的质检夹具。

Model card 是人和机器之间的共同契约。

Source / evidence 是模型不漂移的锚点。

Review bundle 是 Codex、CCRA、Owner 之间的交接机制。