LLM Wiki 实践：从 Karpathy 设想到两个真实领域的落地

把 PDF 编译成可增量维护的知识图谱，而非每次 RAG 检索的临时拼接。本文记录我们在两个领域（汽车企业标准、汽车合规法规）的实施过程，包括关键设计、5 类失败教训、24 个测试用例的验证结果，以及人机协作中"不确定责任归属"的反思。

关键词：LLM Wiki, RAG, 知识图谱, 半自动化抽取, 人机协作

关于本文的匿名化声明

本文涉及两份真实工业文档作为案例输入，已对来源公司和具体文档编号做匿名化处理：

"OEM 甲方 A" 指某中国整车厂的技术中心。
"Supplier B" 指某德国 Tier-1 汽车零部件供应商。
标准前缀 "ESA"、"ESP" 为虚构占位符（替代真实企业标准前缀）。
标准号中保留的数字部分（如 3 720 002-2013）仅作示意，不代表任何真实标准的完整编号。

匿名化的目的是避免对原文档版权方造成困扰，不影响本文方法学和实验结论。如需基于本工作复现，建议读者使用自有可访问的 PDF 输入。

摘要

我们用 LLM 实现了 Karpathy 在 2024 年提出的 "LLM Wiki" 设想——把 PDF 文档编译成结构化、可增量维护的知识图谱，而非每次 RAG 检索的临时拼接。在两个领域（汽车企业标准、汽车合规法规）共摄入 3 份 PDF，产生 326 个 wiki 页面、288 部法规/标准的交叉引用网络、56 个产品类目映射。通过 24 个测试用例验证查询正确率 92%、0 幻觉。

本文的贡献是真实的实施记录，包括：(1) 三层架构（raw / extracted / wiki）的设计动机；(2) 不同领域如何决定实体类型；(3) 5 类典型失误（容器编号误判、抽取假设错、跨页表错位、数据副本未识、复核责任错配）；(4) "LLM 可解决 vs 需外部资料 vs 设计就该如此"的待复核三分类法。

核心发现：LLM Wiki 在合规索引这类结构化但非数据库的领域比传统 RAG 价值高；最大的隐患不是抽取错误，而是 LLM 过度把自己能解决的不确定推给人类。

1. 背景与动机

1.1 RAG 的局限

传统 RAG（Retrieval-Augmented Generation）的工作流是：用户提问 → 向量检索 → 把相关片段拼接 → 让 LLM 拼答案。它的根本特性是无状态：同样的问题问 10 次，每次都从原始文档重新检索拼接，从来不变聪明。

这种模式有几个明显成本：

价值密度低：用户问一次，LLM 算一次。问 100 次的成本是问 1 次的 100 倍。
不积累：第 100 次问"GB 8410 的燃烧速率限值"，和第 1 次问的延迟、精度、可解释性几乎一样。
不揭示关系：RAG 擅长"这段话写了什么"，不擅长"这部法规和另一部法规什么关系"。
难审计：每次答案的拼接方式不稳定，无法追溯。

对事实层稳定但知识网络复杂的领域（法规、标准、规章），RAG 是个糟糕的匹配。

1.2 Karpathy 的 LLM Wiki 设想

2024 年 Karpathy 在一篇 gist ¹ 中提出：

The tedious part of maintaining a knowledge base is not the reading or thinking — it's the bookkeeping. LLMs excel at the maintenance burden humans abandon. The human curates sources and directs analysis; the LLM handles everything else.

核心论点：把 LLM 当成知识库的维护者，而不是检索器。架构是三层：

Raw Sources：不可变的原始 PDF / 文档
The Wiki：LLM 生成和维护的 markdown 知识页，含交叉引用
The Schema：描述 wiki 如何组织、如何维护的配置

工作流是三阶段：

Ingest：来了一份新文档，LLM 通读后同时更新 10-15 个相关页面（不是塞进一个角落），打交叉引用
Query：基于编译好的 wiki 答问题；高价值分析回灌进 wiki
Lint：定期巡检矛盾、孤立页、过期声明

Karpathy 原帖下评论数百条，但真的有人完整跑过这个流程吗？我们没找到。所以决定自己做。

1.3 本文贡献

我们在两个真实工业场景实施了 LLM Wiki：

案例 A：汽车企业标准 wiki（automotive-standard-wiki），起点是两份 OEM 甲方 A 的内部企业标准 PDF
案例 B：汽车合规法规 wiki（regulation-wiki），起点是一份 Supplier B 的 SUP-CL-001 合规索引文档（85 页）

本文记录：

三层架构的设计动机与适应（§2）
两个案例如何决定实体类型（§3-4）
关键设计模式：阈值规则、反向引用、全局适用分层（§5）
5 类典型失败及修复过程（§6）
24 个测试用例的验证结果（§7）
讨论：LLM Wiki vs RAG 的适用边界、人机协作中的不确定分配（§8）

2. 系统设计

2.1 三层架构

raw/             原始 PDF（只读，不可修改）
extracted/       PDF → 文本的机器抽取（pdftotext -layout）
wiki/            LLM 维护的 markdown 知识图谱
  INDEX.md       总入口
  sources/       一份索引文档一页（元数据）
  <entities>/    按领域定义的实体聚合页

三层分工严格：

raw 层：版本控制的真理。即使 LLM 摄入出错，事实层永远可回查。
extracted 层：机械工序（pdftotext 等）。不让 LLM 解读，只把文本落地为可 grep 的形式。
wiki 层：LLM 唯一可写的层。所有交叉引用、关系、推导都在这里。

关键原则：raw 永远只读。这是事故防火墙——任何 LLM 错误都不会污染原始数据。

2.2 实体类型按领域适应

不同领域的实体类型不同。这是设计中最重要也最容易拍脑袋错的决策。

案例 A（企业标准）：

实体	含义
`sources/`	一份标准 PDF 一页（1:1 镜像）
`components/`	零部件聚合（如"汽车开关"）
`requirements/`	技术专题聚合（如"操作力与手感"）
`tests/`	测试方法聚合

案例 B（合规法规）：

实体	含义
`sources/`	一份索引文档一页
`regulations/`	一部外部法规一页（事实层核心）
`topics/`	跨法规主题（EMC、燃烧性等）
`products/`	产品类目聚合
`regions/`	地理/法域聚合

两套实体类型结构同构但语义不同：

A 的 components（零部件）对应 B 的 products（产品类目）—— 都是"物理对象"
A 的 requirements（技术专题）对应 B 的 topics（合规主题）—— 都是"概念维度"
B 多一个 regions 维度——因为法规天然按地理边界划分，标准不需要

2.3 INGEST / QUERY / REVIEW 三大流程

这是项目沉淀出的核心治理文档：

文档	内容
`CLAUDE.md`	项目原则（如"raw 只读"、"数值人工复核"）
`INGEST.md`	摄入新 PDF 的 8 步流程（含分批策略）
`QUERY.md`	查询的"三层退化"路径（INDEX → wiki → extracted）
`REVIEW_TRIAGE.md`	待复核项的三分类（详见 §6.5）

关键流程：QUERY 的三层退化

第一层：INDEX.md（地图）        定位归类
   ↓ 找到候选页面
第二层：wiki/*.md（编译层）      用 grep 找关键词
   ↓ 答不全/不放心
第三层：extracted/*.txt（原文）   回查 PDF 抽取文本
   ↓ 还不够（极少）
       告诉用户"待人工复核"

核心原则：能在上层解决就不下沉。每多下沉一层，速度慢一倍、上下文占用多一倍。

3. 案例 A：汽车企业标准 wiki

3.1 输入

两份 OEM 甲方 A（某中国整车厂技术中心）的企业标准 PDF：

ESA-X1 开关操作力及手感评价规范（12 页）
ESA-X2 产品图样的格式和要求（85 页含附录）

（标准号已匿名化，X1/X2 为占位符）

3.2 实体类型设计

最初基于 CLAUDE.md 里用户预先写的 4 类目录骨架（sources / components / requirements / tests）。第一份 PDF 摄入很顺——它讲汽车开关，组件清晰、专题清晰、测试方法清晰。

但第二份 PDF（产品图样格式）摄入时立刻发现问题：它不针对任何零部件，是一份"过程/规约类"标准。强行往 components/ 里塞会非常别扭。

决策：

接受 components: []（显式声明无关联，不假装有）
在 INGEST.md 加判断："零部件类标准" vs "过程/规约类标准" vs "测试方法类标准"分别走不同路径

这是项目第一次让流程文档承载分类判断，而不是套用一刀切的模板。

3.3 关键设计决策

source 页 frontmatter 的诞生：

---
doc_id: ESA_X1_V3
standard_no: ESA-X1(V3)
title: 开关操作力及手感评价规范
type: 企业标准
organization: OEM 甲方 A 技术中心
issue_date: 2013-12-16
implementation_date: 2013-12-17
replaces: ESA-X1(V2)
confidentiality: 秘密文件
review_status: 初稿，待人工复核
---

frontmatter 的设计原则是结构化元数据放 frontmatter，自由文本放正文。但实际执行中这条原则被反复违反：数值（限值、版本号）有时在正文表格、有时在 frontmatter——这是后期 §7 测试时暴露的隐患。

附录 A-D 的"等用户问到才补"：

最初的 ESA-X2 source 页只覆盖正文，附录 A-D（更改栏/明细栏/索引栏/KCDS 栏的填写细则）一直留作"待人工复核"。直到用户问"明细栏需要哪些信息"——我们才意识到这是个真实查询需求，立即把附录 A-D 补进 wiki。这是 Karpathy 说的 "Wiki improves the more it is queried" 第一次真实发生。

4. 案例 B：汽车合规法规 wiki

4.1 输入

一份 Supplier B（某德国 Tier-1 汽车零部件供应商）的内部合规索引文档：

SUP-CL-001 Issue 16 (2023-07) — "Table of Laws, Decrees and Technical Standards"，85 页

关键认知：这不是一部法规，而是一份"合规索引"——列出 Supplier B 各类汽车产品需遵守的所有外部法规（ECE/EU/US/CN/KR/IN/JP/CA/AU/DE）。

这种"索引型"文档的特点是结构高度规整：

<区域代码>  <法规编号 + 标题>
            <条款号>  <条款摘要>
            <条款号>  <条款摘要>
            ...

例：

ECE   ECE-R 10
      Electromagnetic Compatibility, vehicles and components
      No. 3.2.1   Application for approval also by manufacturer of subassembly
      No. 5.2.2   Mark of approval on subassembly
      ...

这种规整结构让半自动化抽取成为可能，是案例 B 与案例 A 最大的工程差异。

4.2 新增维度：region 和 product

法规天然按地理边界划分。我们引入两个新实体类型：

regions/ — 一个区域一页（AU/CA/CN/DE/ECE/EU/IN/JP/KR/US + 特殊代码 GEN）
products/ — 56 个产品类目（LK §6 列出的）

特殊代码 GEN：LK §5.5 Functional Safety 引入了 "GEN" 标签代表"多国共用的国际标准"（如 ISO 26262）。它不是地理区域，是 LK 文档惯例。脚本最初不识别 GEN，导致 5.5 节摄入失败（详见 §6.2）。

4.3 新增关系：contains / member_of

LK §5.6 网络安全里有"容器条目"模式：

CN  201 Vehicle Equipment Network Security
    (Guidelines for the Construction of Internet of Vehicles ... 2022)
    7) Automotive gateway information security technical requirements and test methods
       GB/T 40857
    8) Information Security Technical Requirements ...
       GB/T 40856

201 不是一部法规的编号，而是工信部《车联网网络安全标准体系建设指南 2022》中的类别号。真正的法规是嵌套在内的 GB/T 40857、GB/T 40856。

这种"容器→成员"关系是法规体系特有的结构，常规的 related_regulations 关系类型（equivalent_to / similar_to / has_part 等）不够用。我们扩展了关系类型表：

关系	含义	反向
`contains`	容器条目包含的成员标准	`member_of`
`member_of`	隶属于某个容器条目	`contains`

4.4 半自动化：脚本 + LLM 后处理

案例 B 规模太大（57 部法规仅 §5、加 §6 后 245 部、加 §10.1 版本表后 245 部含版本信息 129 部）——纯 LLM 逐条摄入不现实。

我们开发了 7 个脚本：

脚本	功能
`extract_ch5_stubs.py`	§5 主题章节解析为 JSON stubs
`extract_ch6_stubs.py`	§6 产品章节解析
`extract_section_10_1_version_table.py`	§10.1 版本号大表解析（257 条记录）
`generate_wiki_stubs.py`	从 stubs 生成 wiki 骨架
`generate_products.py`	生成产品页 + 反向更新法规页
`apply_version_info.py`	版本号信息批量回填
`rename_reg_ids.py`	reg_id 命名统一（30 个重命名）

分工：

脚本做：正则解析、批量生成 markdown 骨架、字段批量更新、文件重命名
LLM 做：语义清洗、关系判断、容器条目识别、冲突处理、自然语言段落撰写

这种"脚本骨架 + LLM 加工"的模式是案例 B 能处理规模的关键。但它也引入了新的失败模式——脚本的假设错误（如不识别 GEN）会导致 LLM 完全错过该数据，下游修复成本远高于 LLM 直接读 PDF。

5. 关键设计模式

5.1 阈值规则：何时建独立页 vs 占位页

LK 文档里许多法规只列了名称，没有条款。给每部都建独立页会产生大量"只有 30 字符内容"的稀薄页面，污染查询。

我们用信息密度阈值：

信息密度	处理
条款 + follow_up ≥ 2 行	建独立完整页
< 2 行	折叠到主题页"其他相关法规"段
仅在产品页被引用、无独立条款	建占位页（仅 frontmatter + 来源）

占位页是个折中：保持链接完整性（产品页 → 法规页不破），但不假装有内容。它在 review_status 里显式标 占位页面（信息密度低），待人工复核。

最终案例 B 有 46 个占位页，占总数 19%。

5.2 反向引用：applies_to_products

LK 文档的原始组织是 "产品 → 引用了哪些法规"。但工程师查询的真实方向常常是反过来——"REACH 适用于哪些产品"。

我们写了一个反向更新脚本：扫所有 products/*.md 的 related_regulations → 反向映射成 reg_id → [products] → 写回 regulations/*.md 的 applies_to_products 字段。

结果：

124/217 部法规 applies_to_products 非空（57%）
93/217 部法规 applies_to_products: []

第二行有意思：93 部"空"的法规并非 bug——它们是主题层（Materials/Functional Safety/Cyber Security）的全局法规，本来就不绑定具体产品。REACH 是个典型：它是化学品源头层规则，对所有零件适用，不该被列在任何具体产品页。

把这条当作"已知无解 / 设计就该如此"记录在案，避免后续反复追问"为什么 REACH 的 applies_to_products 是空？"

5.3 全局适用法规：Tier 1/2/3 分层

测试用例 B1（"Light Switch 在中国需要满足什么法规"）暴露一个真问题：LK §6.15 没单独列 CN 法规，但 EMC 主题（§5.1）的 ECE-R 10 实际上对所有电子产品适用。wiki 没有把"主题层全局适用"传播到产品页。

我们设计了三级全局适用规则：

Tier	范围	处理
Tier 1	EMC 全局（4 部法规，所有电子产品）	脚本自动加到所有产品页
Tier 2	内饰 / 燃烧性 / 材料等条件全局	产品页只加提示，需人工判断
Tier 3	功能安全 / 网络安全等功能条件	同上

执行后 54/56 产品页加了"全局适用法规（按主题推导）"段，2 个跳过（Clockspring_Cassette 纯机械、_general 通用兜底）。

5.4 待复核三分类

最初设计中，凡是 LLM 不确定的都标 待人工复核。这本质上是把不确定责任全部推给用户。

实际情况是用户也未必能解决——比如 "GB 8410 燃烧速率限值"，用户既不一定有 GB 标准全文，也不在汽车合规岗位。这种推卸让 wiki 进入死循环：标了等于没标。

第二次重新设计后引入三分类：

类别	谁来做	行动
第一类 LLM 可解决	LLM 自己	WebSearch / 重新推理 / 从 extracted 整理
第二类需外部资料	用户	LLM 明确告知"需要做什么、去哪做"
第三类已知无解 / 设计就该如此	无需追问	记录原因，停止反复出现

实际执行结果（案例 B）：

✅ LLM 已消化 6 项（含 KPC/PQC/AQC、SAE J369 关系、GB 8410 限值、JP JIS D 1201 等）
🟡 部分解决 1 项
🔴 需外部资料 7 项（含 GB/T 34590、KS R / GOST R 等需要 PDF 的）
⚪ 已知无解 2 项（REACH 不绑产品、ISO 26262 版本差异业务影响）

6. 失败教训（5 类典型失误）

6.1 容器编号误判：CN 201/202/603

症状：脚本把 LK §5.6 网络安全章中的 CN 条目 "201 Vehicle Equipment Network Security"、"202 Vehicle Network Security"、"603 Security capability assessment" 标记为 type: 行业指南（编号片段，疑被截断）。

LLM 的错误判断：看到 reg_no 是数字字符串 "201/202/603"，主观认为这是被截断的标准号片段。

真实原因：这些是 LK 文档自有的容器条目编号，来自工信部《车联网网络安全标准体系建设指南 2022》的类别号。真正的国标是其成员（GB/T 40857、GB/T 40856 等）。

修复：

扩展关系类型加 contains / member_of
修正 3 个容器条目页（CN 201/202/603）
新建 4 部嵌套国标页（GBT_40857/40856/38628/40861）
新建 2 部国际标准页（ISO_SAE_21434、ISO_PAS_5112）

教训：永远先看上下文再判断。看到不寻常 reg_no 时应该先看它的 follow_up 文本（"Guidelines for the Construction of Internet of Vehicles..."），就能识破容器条目模式。

6.2 抽取器假设错误：GEN 区域代码

症状：LK §5.5 Functional Safety 章节，脚本仅识别出 1 部法规（US ISO 26262）但有 27 行 follow_up。

真实原因：LK §5.5 引入了一个全新的区域代码 "GEN"（General，代表多国共用国际标准）。脚本的 REGION_CODES = {"AU", "CA", "CN", "DE", "ECE", "EU", "IN", "JP", "KR", "US"} 没收录 GEN，所以 12 部 ISO 26262 Part 全被错归类成 follow_up。

修复：

给 REGION_CODES 加 GEN
修正 slugify_reg_id 支持 ISO_26262-N 子编号（之前 bug 把 12 个 Part 全归到 ISO_26262，互相覆盖）
新建 ISO 26262 Part 1-12 独立页面（12 个）
新建 GEN 区域页
重写 Functional_Safety 主题页

教训：脚本的 REGION_CODES 集合应该是开放式的，发现新代码时即时扩充。或者改用更宽松的正则（任何 2-4 位大写字母+多空格），代价是会有误识。

6.3 跨页表格错位：§10.1 误识为 §8

症状：长期标记"§8 Applicable Documents 未摄入"。实际尝试时发现 §8 在正文里几乎是空的（只有标题），真正的版本号表在 §10.1 Tables of Laws, Decrees and Technical Standards。

真实原因：LK 文档的目录章节名（PDF 第 65 页"§8 Applicable Documents"）和正文位置不对应。PDF 抽取时 §8 标题被错位排版打散了。真正的版本表在 §10.1，从 PDF 第 70 页起跨多页。

修复：

写 extract_section_10_1_version_table.py 专用脚本
抽取 257 条版本记录
回填到 119 个现有页 + 新建 10 个法规页

教训：目录页的章节名 ≠ 正文位置。摄入前应该在正文里 grep 确认章节标题真实位置，不要信任目录。

6.4 数据副本未识别：EU 2008/653 三副本

症状：reg_id 命名统一时发现 3 个相似名字的文件：

EU_2008653EC_HMI
EU_2008653EC_HMIFehler_Verweisquelle_konnte
EU_2008653EC_HMI_Fehler_Verweisquelle_konnt

真实原因：这是同一部欧盟法规 2008/653/EC 的三个 PDF 抽取副本。LK 原始 Word 文档里此处的 reg_no 字段含 Word 交叉引用，PDF 转换时出现德语错误信息 "Fehler! Verweisquelle konnte nicht gefunden werden."（交叉引用失败）。这个错误信息被脚本误当成 reg_no 的一部分。三个副本各被一个产品页引用（Passive Displays / Touch Displays / Roof Module）。

修复：合并三副本到 EU_Recommendation_2008_653.md，applies_to_products = ["Passive Displays", "Roof Module", "Touch Displays"]。

教训：摄入流程应主动检测 reg_no 高度相似的条目（编辑距离/前缀）作为重复嫌疑。同时 LK 这种"Word 转 PDF"的源文件特有的"交叉引用失败"应当被识别为噪声并过滤。

6.5 复核责任错配（最重要）

症状：最初设计中，凡是 LLM 不确定的都标 待人工复核。用户多次说"标了我也不知道怎么补，我的知识跟你无法对齐"。

真实原因：LLM 把"我不确定" = "用户能解决"，但实际情况是：

LLM 标的"待人工复核"	实际情况
"GB 8410 燃烧速率限值待复核"	用户没工具查 GB 标准全文
"KPC/PQC/AQC 三者定义待复核"	OEM 甲方 A 内部知识，用户也未必有
"ESP-X 流程文件现行版本号"	用户不在 OEM 甲方 A 工作
"5.6 编号是否被截断"	用户也不知道中国汽车信安标准号长什么样

很多时候 LLM 完全能自己解决（WebSearch 公开标准、用 extracted 文本重新核对）。

修复：

引入"待复核三分类"（见 §5.4）
制定原则：LLM 应先问自己三个问题——能自己查吗？之前判断错了吗？真的只有用户能解决吗？
实际执行：消化 6 项 LLM 可解决的项（含 KPC/PQC/AQC、GB 8410 限值、UL 94 Method A/B 等）

这是项目最重要的一次反思。它揭示一个反直觉的事实：LLM 知识库系统的最大隐患不是答错，而是过度把自己能解决的不确定推给人类。

7. 实验

7.1 测试用例设计

我们设计了 24 个测试用例，覆盖 6 类查询模式：

类别	数量	难度
A 单维度元数据	4	easy
B 跨维度交叉	4	medium
C 含细节核对	5	hard
D 陷阱与边界	4	hard
E 聚合统计	4	medium
F 流程理解	3	medium

每个测试用例标注：问题 / 期望要素 / 不该出现的内容 / 预期搜索路径 / 难度。

关键设计原则：必须有"该出现什么"和"不该出现什么"两栏，才能客观区分 ✓ vs ✗（含幻觉）。

7.2 结果

等级	数量
✓ 答对	22 / 24（92%）
⚠ 部分对	2 / 24
✗ 答错	0 / 24

0 幻觉是关键发现。即使在 D 类陷阱用例（如"2024 年最新 ECE-R 10 是哪版"——超出 wiki 数据范围）下，LLM 也能正确响应"wiki 数据截止 2023-07，无法回答 2024 年信息"。

7.3 测试如何反哺 wiki 改进

测试用例 B1（"Light Switch 在中国需要满足什么法规"）首次评分 ⚠——产品页 related_regulations 不含 CN 法规，回答应明示"LK §6.15 未列 CN，但 EMC 主题全局适用 ECE-R 10 等"。

我们随即设计 Tier 1/2/3 全局适用规则（见 §5.3），给 54 个产品页批量添加"全局适用法规"段。修改后重新询问 B1：

Light Switch 进入中国市场，LK 文档明示要求 = 0 部。但根据全局适用推导，实际很可能需符合 3-5 部 CN 法规：

GB/T 4094.2（车辆开关符号，§5.2 内饰主题 CN）

GB 8410-2006（塑料燃烧性，§5.3 主题 CN）

SAMR Order No. 2（China ELV，6 种禁用物质）

MEE Order No. 12（China REACH，含新化学物质时）

评分升 ✓。

这是 Karpathy "Wiki improves the more it is queried" 的真实落地：

查询暴露问题
测试用例固化问题
实施改进（54 页批量添加）
重新查询验证

8. 讨论

8.1 LLM Wiki vs RAG 的适用边界

不是所有领域都该用 LLM Wiki。我们的判断：

维度	LLM Wiki 占优	RAG 占优
事实层稳定性	高（法规多年不变）	低（新闻、社交）
知识网络复杂度	高（法规间引用、产品对应）	低（孤立文档）
查询重复性	高（同一问题被反复问）	低（一次性探索）
单次查询成本敏感度	高（要审计、要稳定）	低（探索性）
元数据重要性	高（版本/日期/类型）	低

合规、法规、技术标准、企业 SOP、医学指南都是 LLM Wiki 占优的领域。社交媒体内容、即时新闻、个人笔记则适合 RAG。

8.2 半自动化的甜蜜点

案例 B 的关键启示是：纯 LLM 摄入做不了规模、纯脚本摄入做不了语义。半自动化的甜蜜点是：

脚本：正则解析 + 批量生成骨架 + 字段填充 + 文件改名
  ↓
LLM：语义清洗 + 关系判断 + 冲突处理 + 自然语言段落

但半自动化的代价是脚本的假设错误会被放大——脚本不识别 GEN 代码，导致 LLM 完全错过 12 部 ISO 26262 子标准。修复成本远高于"让 LLM 直接读 PDF"。

建议：先用 LLM 读一小段样本（如 5 页）摸清结构，再写脚本批量处理剩下的。这就是我们案例 B 实际走的路。

8.3 人机协作中"不确定的分配"

§6.5 教训值得展开。LLM 知识库系统中最大的隐患不是答错，而是复核责任错配。

LLM 默认会把"我不确定"映射到"用户能解决"。这个映射在大多数情况是错的：

用户不一定有更多知识（互联网公开信息是 LLM 与用户共享的）
用户不一定有外部数据访问权（内部文档、付费标准）
用户不一定理解 LLM 标记的不确定项的技术含义

**正确的"不确定分配"**应该是：

LLM 不确定 →
  ├─ 能 WebSearch 解决 → LLM 自己做
  ├─ 能从 extracted 重新核对 → LLM 自己做
  ├─ 是 LLM 之前误判 → LLM 修正
  ├─ 用户能查内部资源 → 明确告知"去哪做什么"
  ├─ 用户也无法获取 → 标"已知无解"
  └─ 设计就该如此 → 标"非 bug"

这套分配的关键不是 LLM 是否努力，而是LLM 是否对自己能做的事有清醒认知。

8.4 局限性

诚实列出本工作的局限：

未做 RAG baseline 对比。本文报告的 92% 正确率没有与"同 PDF 建 RAG 跑同 24 题"的对比。理论上 LLM Wiki 在事实查询上应该明显胜过 RAG（因为答案已经被预编译），但缺少实测数据。
单一 LLM。所有摄入和查询都由 Claude（Sonnet/Opus 级别）完成。不同模型表现可能差异显著。
测试用例规模小（24 题）。统计意义有限。
领域偏窄。两个案例都是汽车行业。其他领域（医学、金融、法律）的适用性需要进一步验证。
维护成本未量化。"LLM Wiki 越用越准"的前提是有人持续维护。如果一年没人查询，wiki 是否会因外部世界变化（法规更新、标准修订）而过期，未在本工作时间窗内观察到。

9. 结论与未来工作

主要结论

LLM Wiki 是可行的。我们在两个真实工业场景实施了 Karpathy 的设想，产出 326 个 wiki 页面，查询正确率 92%、0 幻觉。
三层架构（raw/extracted/wiki）+ 半自动化（脚本+LLM）+ 三大流程（INGEST/QUERY/REVIEW）+ 三分类（LLM 可解决/需外部资料/已知无解） 构成可复用的实施模板。
最大的隐患不是抽取错误而是复核责任错配。修复方式是让 LLM 对自己的能力范围有清醒认知。
测试驱动 wiki 改进：B1 案例完整展示"查询暴露 → 测试固化 → 实施改进 → 重测验证"的闭环。

未来工作

方向	内容
RAG baseline 对比	同 PDF 同问题集，量化两种范式的差异
多 LLM 验证	用 GPT/Gemini 重复实验，看模板适用性
多领域验证	医学指南、法律法规、金融监管的 LLM Wiki 实现
Lint 流程	Karpathy 提到但本工作未实施的"定期巡检矛盾、孤立页、过期声明"
多源摄入	当前每个 wiki 只有 1-2 份 source。多源时的去重、冲突、版本合并是新问题
维护成本研究	长期观察 wiki 在外部世界变化下的衰减速度

致谢

本工作由人类用户与 Claude（Sonnet/Opus）协作完成。所有 wiki 内容、脚本、流程文档均由 LLM 生成或编辑，关键设计决策由用户拍板。两份案例的输入 PDF 已做匿名化处理（详见篇首"匿名化声明"）。

引用

附录：项目数据总览

维度	automotive-standard-wiki	regulation-wiki
输入 PDF 数	2	1
Wiki 文件总数	7	319
事实层实体数	7（2 sources + 1 component + 2 requirements + 1 test + 1 INDEX）	245 regulations + 56 products + 11 regions + 6 topics + 1 source + 1 INDEX = 320
抽取脚本数	0（纯 LLM 摄入）	7
流程文档数	3（CLAUDE/INGEST/QUERY）	5（+ REVIEW_TRIAGE + TEST_CASES + TEST_RESULTS）
测试用例数	0	24
待复核项数	多（未三分类）	已分类（6/1/7/2 = ✅/🟡/🔴/⚪）

Andrej Karpathy. "LLM Wiki: A Pattern for Persistent Knowledge Compilation." GitHub Gist, 2024. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f ↩