大規模理論論文群的自我校正代理系統

從 Claim Extraction、Conflict Audit 到 Canonical Closure

版本：v0.1
類型：技術方法論／AI-native Research Infrastructure／知識治理
前篇：《大規模理論論文群的可演化知識治理：從論文版本維護到 Canonical–Supersession Claim Graph》

作者： Neo.K
機構： EveMissLab／一言諾科技有限公司
日期： 2026-10-07（整理日期；原稿未標註日期）

摘要

前篇提出：

\text{Paper Corpus} \rightarrow \text{Claim Graph} \rightarrow \text{Canonical Layer}

但這仍然只是一個知識治理框架。真正面對數千篇以上的研究語料時，下一個問題是：

如何讓 AI Agent 對整個論文群進行基本檢查、建立主張圖、發現衝突、提出取代關係，並逐步收斂到可驗證的 Canonical State？

本文提出一套大規模理論論文群的自我校正代理架構。其目的不是讓 AI 自動宣布某篇論文「正確」或「錯誤」，而是將原本需要大量人工記憶與追蹤的工作拆成可計算流程：

\text{Ingest} \rightarrow \text{Normalize} \rightarrow \text{Claim Extraction} \rightarrow \text{Dependency Graph} \rightarrow \text{Conflict Audit} \rightarrow \text{Supersession Proposal} \rightarrow \text{Canonical Review} \rightarrow \text{Closure}

其中最重要的設計原則是：

AI 只提出候選，不直接篡改知識狀態。
基本檢查優先於深度重寫。
先處理高中心度、高依賴、高曝光的核心節點。
文件層、主張層、理論層必須分開。
自我校正的真正目標不是「零錯誤」，而是讓錯誤可定位、可追蹤、可取代。

本文最後提出一個可直接落地的 Phase 0 基本檢查協議，作為數千篇論文群第一次全域盤點的最低成本入口。

1. 為什麼第一步不是「全部重驗」

面對數千篇論文時，最直覺的想法通常是：

全部重新看一遍。

但這並不合理。

因為真正需要回答的第一層問題不是：

「每篇內容是否完全正確？」

而是：

「目前整個 corpus 的結構狀態是什麼？」

因此第一階段應先回答：

哪些是核心理論；
哪些是探索文；
哪些是版本分叉；
哪些文章彼此高度重複；
哪些文章顯然已被後作取代；
哪些文章被大量後續內容依賴；
哪些符號或定義發生漂移；
哪些文章對外曝光最高；
哪些文章應優先進入人工或 AI 深度檢查。

這種第一層工作可以稱為：

Structural Audit

也就是先檢查「知識結構」，再檢查「知識真假」。

2. 三層檢查架構

整個自我校正系統可以拆成三層。

Layer A：Document Layer

檢查論文本身的基本狀態：

ID；
標題；
日期；
主題；
系列；
版本；
是否公開；
是否被後作替代；
是否有明顯重複；
是否缺少來源；
是否缺少依賴說明。

Layer B：Claim Layer

抽取每篇文章中的：

定義；
主張；
猜想；
定理；
方法；
證據；
反例；
限制條件。

並形成：

\text{Paper} \rightarrow \{C_1,C_2,\ldots,C_n\}

Layer C：Theory Layer

將跨文章主張聚合為：

當前正式定義；
當前核心定理；
當前方法；
歷史版本；
已棄用分支；
尚未決定分支。

因此：

\text{Document Audit} \neq \text{Claim Audit} \neq \text{Theory Audit}

三者不能混成一個任務。

3. Phase 0：基本檢查

如果目前目標只是先對數千篇論文做「基本檢查」，不應立即啟動完整 Claim Graph。

第一階段只需要產生每篇文章的最低限度紀錄。

建議欄位：

paper_id: P-000001
title: "..."
created_at: 2026-01-01

series: "..."
topic: "..."

version_hint: "v0.3"

status_candidate:
  - active
  - superseded
  - exploratory
  - historical
  - unknown

possible_successor: null
possible_predecessor: null

core_score: 0.0
dependency_score: 0.0
conflict_risk: 0.0
public_exposure: 0.0

needs_review: false
review_reason: []

Phase 0 的目的只有一個：

把數千篇不可見的「文件堆」，轉換成可以排序與篩選的研究地圖。

4. 第一輪 Agent 不應做什麼

基本檢查 Agent 不應：

宣布某篇證明成立；
判定某篇一定錯誤；
自動刪除文章；
自動修改舊文；
自動覆蓋原始理論；
因為兩篇語義不同就直接判成衝突；
因為較新就自動認定較新版本正確。

第一輪 Agent 的角色是：

索引器、分類器、風險探測器。

不是終審者。

5. Ingest：先把論文群變成可計算資料

第一步需要建立統一 ingestion layer。

來源可以是：

Markdown；
HTML；
PDF；
DOCX；
JSON；
Git repository；
網站文章；
資料庫。

每篇文件轉換成統一記錄：

{
  "paper_id": "P-000001",
  "source_uri": "...",
  "title": "...",
  "created_at": "...",
  "modified_at": "...",
  "content_hash": "...",
  "text": "...",
  "metadata": {}
}

其中：

content_hash

非常重要。

因為它可以先解決：

完全重複；
不同檔名但同內容；
網站與本地副本；
舊備份；
多次搬站。

6. Normalize：先解決最便宜的混亂

在進入 AI 語義分析之前，先做非語義正規化。

例如：

統一日期格式；
統一作者名；
統一系列名；
統一標題空格；
抽取版本號；
解析論文 ID；
去除 HTML boilerplate；
去除重複 footer；
建立 hash；
找 exact duplicate。

這一層成本極低，但可以先消掉大量「假複雜度」。

7. 系列與主題聚類

數千篇論文若全部互相比較，成本會很高。

理論上兩兩比較需要：

O(N^2)

若 $N=4000$ ：

\frac{4000\times3999}{2} \approx 8,000,000

這不是理想起點。

因此應先做：

\text{Corpus} \rightarrow \text{Series Clusters} \rightarrow \text{Topic Clusters}

例如：

自主數學
 ├─ BSD
 ├─ RH
 ├─ NS
 └─ Collatz

AI 理論
 ├─ 記憶
 ├─ 主體性
 ├─ 世界模型
 └─ Agent

計算理論
 ├─ P/NP
 ├─ 域計算
 └─ 語言計算

之後優先在群內比較，再處理跨群連結。

8. Claim Extraction

當 Phase 0 完成後，才進 Phase 1。

每篇論文抽取：

{
  "claims": [
    {
      "claim_id": "C-P0001-001",
      "type": "definition",
      "text": "...",
      "scope": "...",
      "confidence": 0.91
    }
  ]
}

建議至少區分：

definition
claim
theorem
conjecture
method
evidence
counterexample
limitation

這樣後續才能知道：

兩篇文章到底是在「定義衝突」，還是只是在「解釋方式不同」。

9. Dependency Detection

下一步建立：

C_i \rightarrow C_j

表示：

$C_i$ 依賴 $C_j$ 。

依賴可以分為：

明確引用依賴；
定義依賴；
數學推導依賴；
方法依賴；
語義依賴；
資料依賴。

例如：

{
  "from": "C-P0200-008",
  "to": "C-P0101-002",
  "relation": "depends_on",
  "confidence": 0.84
}

10. Conflict Audit

衝突檢查不是單純語義相似。

真正應檢查：

定義衝突

同一術語在不同文章中被不同定義。

結論衝突

C_i \Rightarrow X

而：

C_j \Rightarrow \neg X

前提衝突

兩篇文章使用不同假設，但沒有標明。

範圍衝突

一篇只在局部成立，另一篇卻把它泛化到全域。

版本衝突

舊文已被新文修正，但檢索仍可能同時返回。

11. Supersession Proposal

當系統發現：

同主題；
後文日期較新；
後文引用前文；
後文明確修正某定義；
後文覆蓋前文核心主張；

就可以提出：

{
  "relation": "supersedes",
  "old": "P-0102",
  "new": "P-2481",
  "confidence": 0.88,
  "reasons": [
    "same theory family",
    "new definition introduced",
    "explicit correction of previous assumption"
  ]
}

注意：

這只是 proposal。

真正狀態改動應由人工或高可信 Agent review 確認。

12. Risk Scoring

數千篇論文不可能同時深度檢查。

因此可先給每篇一個：

R_i

例如：

R_i = 0.30C_i + 0.25D_i + 0.20X_i + 0.15P_i + 0.10U_i

其中：

$C_i$ ：中心度；
$D_i$ ：下游依賴；
$X_i$ ：衝突風險；
$P_i$ ：公開曝光；
$U_i$ ：版本不確定性。

然後：

Top 50
↓
人工／高階 Agent 深查

Top 200
↓
第二輪

其餘
↓
暫時只保留狀態

13. Canonical Candidate

當一個主題下存在：

v0.1
v0.2
v0.3
v1.0
revision
new framework

Agent 不應只看版本號。

應綜合：

時間；
明確取代語句；
依賴關係；
後續引用；
作者標記；
定義完整度；
驗證狀態。

再提出：

{
  "topic": "Theory X",
  "canonical_candidate": "P-3012",
  "confidence": 0.93,
  "alternatives": [
    "P-2880"
  ]
}

14. Canonical Closure

真正的 Canonical Layer 不是「選最新一篇」。

它是對一個主題建立：

topic: Theory-X

canonical:
  definition: C-3012-001
  theorem: C-3012-008
  method: C-3180-003

active_support:
  - P-3012
  - P-3180
  - P-3291

superseded:
  - P-1200
  - P-2108

open_questions:
  - Q-009
  - Q-014

這可以稱為：

Canonical Closure

它不要求理論永遠完備。

只要求：

在目前時間點，系統知道哪一組節點構成當前可用理論狀態。

15. 自我校正 Agent 架構

可以使用多 Agent：

                 ┌──────────────┐
                 │ Corpus Index │
                 └──────┬───────┘
                        ↓
              ┌─────────────────┐
              │ Metadata Agent  │
              └──────┬──────────┘
                     ↓
              ┌─────────────────┐
              │ Claim Extractor │
              └──────┬──────────┘
                     ↓
        ┌────────────┴────────────┐
        ↓                         ↓
┌───────────────┐        ┌────────────────┐
│ Dependency    │        │ Conflict Agent │
│ Agent         │        │                │
└──────┬────────┘        └───────┬────────┘
       └────────────┬─────────────┘
                    ↓
          ┌──────────────────┐
          │ Supersession     │
          │ Proposal Agent   │
          └────────┬─────────┘
                   ↓
          ┌──────────────────┐
          │ Canonical Review │
          └────────┬─────────┘
                   ↓
          ┌──────────────────┐
          │ Canonical State  │
          └──────────────────┘

16. 單 Agent 也可以先做

在 MVP 階段，不必真的拆成很多 Agent。

可以先用單一 pipeline：

for paper in corpus:
    metadata = inspect_metadata(paper)
    claims = extract_claims(paper)
    links = find_relations(paper, corpus_index)
    risks = score_risks(paper, claims, links)
    save_audit(paper, metadata, claims, links, risks)

真正多 Agent 化可以晚一點。

17. 第一輪基本檢查輸出

如果現在只要「先基本檢查」，建議每篇只輸出：

{
  "paper_id": "P-1001",
  "status_candidate": "unknown",
  "series": "BSD",
  "topic": "period relation",
  "possible_duplicate": false,
  "possible_successor": "P-1902",
  "possible_conflicts": 2,
  "core_score": 0.78,
  "review_priority": "high"
}

這樣就已經足以建立：

高優先列表；
舊版本列表；
重複列表；
未知狀態列表；
核心理論列表。

18. 人工確認不應成為瓶頸

數千篇全部人工確認仍然不可行。

因此確認應分層：

Level 0

AI 自動標記，無需人工。

例如：

hash duplicate；
metadata；
明顯版本號。

Level 1

AI 高可信確認。

例如：

明確寫著「本篇取代前版」。

Level 2

人工／高階 Agent review。

例如：

理論衝突；
定義修正；
證明有效性。

Level 3

正式 Canonical 決策。

只針對核心理論。

19. 最小資料庫設計

MVP 不需要大型 graph database。

SQLite 就可以先做。

最小表：

papers
claims
relations
audit_results
canonical_topics

例如：

papers(
  paper_id TEXT PRIMARY KEY,
  title TEXT,
  created_at TEXT,
  status TEXT,
  content_hash TEXT
)

relations(
  from_id TEXT,
  to_id TEXT,
  relation_type TEXT,
  confidence REAL
)

後續再轉：

Neo4j；
PostgreSQL；
graph DB；
vector DB；
自訂圖引擎。

20. 基本檢查的真正成果

第一輪不應期待：

「4000 篇全部驗證完成。」

第一輪成功標準應是：

我們第一次知道這 4000 篇到底長什麼樣。

也就是得到：

corpus map；
series map；
high-centrality list；
likely superseded list；
conflict candidate list；
duplicate list；
unresolved list；
canonical candidate list。

這已經會讓後續工作量下降很多。

21. 一個重要原則：先全域，再局部

如果直接從第一篇開始逐篇修，很容易陷入：

Local Repair Trap

因為你不知道：

這篇是不是早就被後文取代；
這篇是否其實不重要；
這篇是否只是一個歷史分支；
這篇是否有十篇後續修正版。

因此應先：

\text{Global Scan} \rightarrow \text{Priority Map} \rightarrow \text{Local Deep Review}

而不是：

\text{Local Review} \rightarrow \text{Local Review} \rightarrow \text{Local Review} \rightarrow \cdots

22. 對數千篇論文群的實際第一步

若現在真的開始做，第一輪只需要：

Step A

掃描所有論文 metadata。

Step B

建立唯一 paper_id 與 content_hash。

Step C

做系列／主題聚類。

Step D

找：

exact duplicate；
near duplicate；
version family；
obvious successor。

Step E

計算：

citation/dependency proxy；
public exposure proxy；
centrality proxy。

Step F

產生：

Top 100 Priority Review List

這就足以開始第二階段。

23. 從「論文庫」到「可自我修正的研究系統」

如果這套方法持續發展，最終研究平台不只是儲存文件。

它會形成：

\text{Research Corpus} + \text{State Graph} + \text{Audit Engine} + \text{Canonical Resolver}

於是每當新增一篇論文：

New Paper
   ↓
Extract Claims
   ↓
Compare Canonical State
   ↓
Detect Conflict / Extension
   ↓
Update Candidate Graph
   ↓
Request Review if Necessary

這代表：

論文不是被動存進資料庫，而是進入一個會重新計算自身知識狀態的系統。

24. 結論

面對數千篇理論論文，第一步不是全部重寫，也不是全部重新驗證。

第一步應是：

\boxed{ \text{先建立可見性} }

也就是先知道：

有哪些論文；
它們屬於哪些系列；
哪些互相重複；
哪些可能被取代；
哪些高度依賴；
哪些值得優先檢查。

之後才逐步進入：

\text{Claim Extraction} \rightarrow \text{Conflict Audit} \rightarrow \text{Supersession} \rightarrow \text{Canonical Closure}

真正的自我校正系統不是一個會自動「改論文」的 AI。

而是一個能持續回答：

「目前哪些知識仍然成立？哪些已經被修正？哪些需要重新檢查？」

的研究基礎設施。

核心命題

數千篇論文的第一個問題不是正誤，而是可見性。

先全域盤點，再局部深查；先建立狀態，再進行修訂。

AI 自我校正的本質不是自動改寫，而是自動維護知識狀態。