# 知信图谱 — 可信任验证引擎详解

## 核心思想

知信图谱的"信"不只是一个分数，而是一条**可追溯的验证链**。

对比：
- 传统知识库："这条信息可信度 0.8" → **结论是数字，看不出为什么**
- 知信图谱："张三说的，李四复核过，3人确认，有效期至6月" → **结论是过程，可追溯每一步**

---

## 验证链模型

```
信息源（谁说的？）
  ↓
源可信度（这个人/文档历史上可靠吗？）
  ↓
验证行为（有没有人核实过？）
  ↓
验证方法（怎么核实的？自查/同事复核/外部权威）
  ↓
有效期限（这知识会过期吗？过期要重新验证）
  ↓
团队共识（别人认可还是质疑？）
```

每个环节都有明确的记录，任何时间点都可以回答"为什么相信/不相信这条知识"。

---

## 动态验证状态

一条事实的状态不是固定的，而是随着验证行为**自动演化**：

```
录入 → unverified
  ↓ 录入者自查
self_checked
  ↓ 至少1人标注 confirm
peer_reviewed
  ↓ ≥3人标注 confirm
consensus
```

质疑路径：
```
任何状态 → disputed（有人标注 dispute）
  ↓ 问题解决后
unverified（重置，重新验证）
```

过期路径：
```
任何状态 → outdated（超过 fresh_until 未续）
  ↓ 更新内容 + 延长 fresh_until
unverified（重置，重新验证）
```

---

## 验证方法详解

### unverified（未验证）
- **含义**：刚录入，未经任何核实
- **行动**：仅供参考，不应用于决策
- **触发过渡**：人工录入默认；过期重置后

### self_checked（自查）
- **含义**：录入者自己核实过
- **行动**：可作个人参考；团队场景下仍需复核
- **触发过渡**：`--verify <id> --level self_checked`

### peer_reviewed（同行复核）
- **含义**：至少1位团队成员确认
- **行动**：可用于团队内部决策
- **触发过渡**：任何人的 `--annotate confirm`

### external_confirmed（外部确认）
- **含义**：引用外部权威来源确认（如官方文档、第三方数据）
- **行动**：高度可靠，可对外引用
- **触发过渡**：`--verify <id> --level external_confirmed`

### disputed（存在争议）
- **含义**：有人质疑，待解决
- **行动**：暂停引用，优先解决争议
- **触发过渡**：任何人的 `--annotate dispute`

### consensus（团队共识）
- **含义**：≥3人确认，团队达成共识
- **行动**：可作为团队正式结论
- **触发过渡**：共识计数 ≥3 时自动切换到 consensus

### outdated（已过期）
- **含义**：超过有效期未更新
- **行动**：重新评估是否仍然有效
- **触发过渡**：`--stale` 检测到过期自动切换

---

## 可信任度计算（Verifiability）

当需要量化比较时（如排序、过滤），使用以下公式：

```
Verifiability = 0.30 × SourceReliability + 0.35 × VerificationDepth
             + 0.20 × Freshness + 0.15 × ConsensusRatio
```

### 为什么验证深度权重最高（35%）？

因为 **"有人核实过"比"来源理论上可信"更重要**。

- 一个低可信度来源 → 经过 peer_review → 已经比未经验证的高可信度来源更可靠
- 这体现了"知信"的核心：信来自验证行为，而非先验评分

### 各维度取值

| 维度 | 权重 | 取值 |
|------|------|------|
| SourceReliability | 0.30 | sources.credibility_score（人工评定，默认0.5） |
| VerificationDepth | **0.35** | unverified=0, self_checked=0.3, peer_reviewed=0.7, external_confirmed=1.0, disputed=0.2, consensus=0.9, outdated=0.1 |
| Freshness | 0.20 | 有效期内=1.0, 过期每30天线性衰减, ≥300天=0 |
| ConsensusRatio | 0.15 | confirm/(confirm+dispute), 无标注=0.5 |

### 可信任带

| 分数 | 级别 | 行动指南 |
|------|------|---------|
| 0.8-1.0 | 高度可验证 | 可直接用于决策 |
| 0.5-0.8 | 中度可验证 | 可参考，建议注明验证状态 |
| 0.2-0.5 | 低度可验证 | 需进一步验证 |
| 0-0.2 | 几乎未验证 | 不可引用，优先安排验证 |

---

## 过期机制

### 设置有效期

添加事实时指定 `fresh_until`：
```json
{
  "content": "服务器使用 Ubuntu 22.04",
  "fact_type": "status",
  "fresh_until": "2026-08-01"
}
```

### 过期影响

- 过期事实 → `verification_state` 自动变为 `outdated`
- `verifiability` 大幅下降（freshness_score 趋近 0）
- 出现在 `--stale` 列表中

### 续期

```bash
python3 ~/.zhixin/kg.py --update-fact <id> '{"fresh_until":"2027-01-01","verification_state":"unverified"}'
```

更新后状态重置为 unverified，需要重新验证。

---

## 最佳实践

1. **新知识默认 unverified**：不要一录入就标记为已验证
2. **定期 --stale 检查**：每周检查即将过期的事实
3. **验证升级不可逆**：不能从 peer_reviewed 降回 unverified（除非过期重置）
4. **质疑要附理由**：dispute 时必须写 content，说明质疑什么
5. **源可信度保守评定**：信息源初始 0.5，根据历史表现逐步调整