8.0
热点
AI SCORE
开源项目2026-09-15 18:06
LLM Wiki 两步思维链摄取：增量缓存 + 溯源替代传统 RAG
dev.to · AI#RAG#开源#知识库
Editor brief · 编辑速览
区别于传统 RAG 每次查询重新检索，LLM Wiki 将文档处理分为 Analyze 和 Generate 两阶段，增量更新成本极低，且每个 wiki 页面可回溯原始文档来源。
大多数 RAG 流水线每次都会对文档分块、嵌入，然后在查询时从头检索。LLM Wiki 则走了另一条路：将摄取拆分为两个明确的阶段：
分析（Analyze）：从源文档中提取结构、实体和关系。
生成（Generate）：撰写一个融合了分析的 wiki 页面，链接到其他页面，并保留对原始来源的引用。
这一分离带来了三个好处：
增量缓存：当文档发生变化时，只重建受影响的页面。分析步骤会缓存中间表示，因此每个文档只需支付一次 LLM 调用费用，而不是每次查询都付一次。
来源可追溯：每个 wiki 页面都链接回原始 PDF、图片或网页剪藏。更新或删除会自动在图中传播。
持久化知识：wiki 是一等公民（first-class artifact）。你可以导出它、对它进行版本管理，或者从现有页面重建索引，而无需重新摄取源文档。
传统 RAG 将知识库视为隐藏的索引。LLM Wiki 则将其视为产品本身。
摄取队列是一个支持崩溃恢复的串行处理器。每个文档进入队列后，先被分析，然后生成一个或多个 wiki 页面。队列持久化到磁盘，因此如果应用在摄取过程中崩溃，它会从最后一个检查点恢复。
┌─────────────┐
│ Raw Source │ (PDF, Office, EPUB, image, URL)
└──────┬──────┘
│
v
┌─────────────┐
│ Parse │ (MinerU, built-in, or cloud PDF processor)
└──────┬──────┘
│
v
┌─────────────┐
│ Analyze │ (LLM extracts entities, structure, relationships)
└──────┬──────┘
│
v
┌─────────────┐
│ Cache │ (Store intermediate representation)
└──────┬──────┘
│
v
┌─────────────┐
│ Generate │ (LLM writes wiki page with source links)
└──────┬──────┘
│
v
┌─────────────┐
│ Index │ (Update knowledge graph, vector store)
└─────────────┘
分析步骤运行一个链式思维提示（chain-of-thought prompt），识别关键概念、关系和元数据。缓存将分析结果存储为 JSON。生成步骤读取缓存并写入带有 frontmatter 的 Markdown，其中包含来源引用、创建日期和实体标签。
当源文档发生变化时，系统会将新分析与缓存版本进行比较。如果结构相同，则跳过生成。如果实体或关系发生了变化，则只重新生成受影响的 wiki 页面，并更新知识图的边。
这比重新嵌入整个语料库要便宜。一份 100 页的 PDF 可能需要 0.50 美元来分析一次，然后每次增量更新只需 0.02 美元。传统 RAG 每次都会重新嵌入全部 100 页。
每个 wiki 页面的 frontmatter 中都包含一个 sources 数组：
---
title: "Kubernetes Scheduler Internals"
sources:
- type: pdf
path: raw/sources/k8s-design-docs/scheduler.pdf
page: 12
- type: image
path: raw/sources/diagrams/scheduler-flow.png
---
raw/sources/ 目录处于自动监听状态。当你向子文件夹中放入新的 PDF 时，摄取队列会自动处理。当删除一个文件时，系统会将对应的 wiki 页面标记为孤立页面（orphaned），并可选择将其移除。
这解决了一个常见的 RAG 问题：过期数据。如果你删除了一个源文档，传统 RAG 会继续提供来自它的分块，直到你手动重建索引。LLM Wiki 会立即传播删除操作。
知识图谱使用四个信号来计算 wiki 页面之间的相关性：
图谱运行 Louvain 社区检测算法，将页面聚类到不同主题中。每个聚类都有一个基于内部边密度的内聚力分数。界面会展示"意外连接"（高 Ad距离集群之间的高 Adamic-Adar 分数）和"知识空白"（内部链接较少的低内聚力集群）。
这对于需要在没有手动标记的情况下探索知识库的 Agent 非常有用。该图谱提供了一个导航层，而 RAG 的平面向量空间无法做到这一点。
LLM Wiki 从 PDF 中提取图片，并将其通过视觉 LLM 运行以生成事实性 caption。这些 caption 与文本一起被索引，因此支持图片的搜索会同时返回文本片段和相关图片。
灯箱预览会显示图片、caption 和一个"跳转到来源"按钮，点击后会在正确的页码处打开原始 PDF。这比听起来要困难：你需要在 PDF 中跟踪图片坐标，将它们映射到页码，并在整个摄取流水线中保留该元数据。
视觉 LLM 的提示词经过调整，专注于事实性描述而非创意性标题。它避免使用"美丽的日落"这样的短语，而专注于"按地区显示 Q3 营收的柱状图"这样的描述。
LLM Wiki 通过 LanceDB 提供可选的向量搜索。你可以配置任何 OpenAI 兼容的嵌入端点。向量存储索引的是 wiki 页面内容，而非原始源分块。
这是与传统 RAG 的关键区别。嵌入表示的是综合知识，而非原始文本。当搜索"Kubernetes scheduler latency"时，你检索到的是总结 scheduler 行为的 wiki 页面，而非单个 PDF 段落。
该系统支持混合搜索：将向量相似性与知识图谱遍历相结合，以找到语义相近且结构相连的页面。
摄取队列是磁盘上的一个 JSON 文件。每个条目包含：
当前步骤（parse、analyze、generate、index）
如果应用崩溃，它会在重启时读取队列文件，并从最后一个检查点恢复。你可以从界面取消或重试单个条目。
这对于长时间运行的摄取至关重要。一个包含 500 个 PDF 的文件夹可能需要数小时来处理。如果没有崩溃恢复，单次失败就会迫使你从头开始。
文件夹导入会保留目录结构。如果你导入 raw/sources/projects/alpha/，wiki 会创建一个 projects/alpha/ 命名空间，页面按文件夹分组。
文件夹名称会成为 LLM 的分类提示。放在 raw/sources/legal/contracts/ 中的文件会在分析时使用提及"法律合同上下文"的提示词。这改善了实体提取，而无需手动添加元数据。
LLM Wiki 允许你按项目配置模型。你可以将 Chat 和 Ingest 路由到不同的端点：
你可以添加自定义请求头用于 API 密钥、设置流式响应偏好，以及配置重试逻辑。该系统支持任何 OpenAI 兼容端点，包括通过 Ollama 或 vLLM 运行的本地模型。
此模式限制 LLM 仅从导入的来源回答。它禁用了通用知识，强制模型引用 wiki 页面或源文档。
这对于需要证明每个答案都来自经批准材料的合规敏感型工作流非常有用。系统会记录每个来源引用，因此你可以审计检索路径。
你可以将完整项目导出为 .llmwiki 归档文件。该归档包含：
在另一台设备上导入归档后，wiki 会从导出的页面重建索引。这比重新摄取源文档更快，因为分析缓存已包含在内。
常见故障模式：
PDF 解析错误：MinerU 或内置解析器在扫描图片或复杂布局上失败。系统会记录错误并将该文档标记为失败。你可以重试使用不同的解析器，或手动 OCR 该文件。
LLM 速率限制：摄取队列遵守速率限制并以指数退避进行重试。你可以配置最大重试次数和退避乘数。
内存溢出：大型 PDF（1000+ 页）在解析过程中可能会耗尽内存。系统会将大文件分块为 100 页一段，并按顺序处理。
过期缓存：如果你更改了分析提示词，缓存就会失效。系统会检测提示词变更并使受影响的缓存条目失效。
可观测性目前较为基础。界面显示摄取进度和错误日志，但没有结构化的遥测或分布式追踪。对于生产部署，你需要添加 OpenTelemetry 插桩。
适合使用 LLM Wiki 的场景：
不适合使用 LLM Wiki 的场景：
LLM Wiki 将成本从查询时间转移到了摄取时间。如果你反复查询同一个知识库，这种权衡是值得的。如果你只摄取一次然后查询一次，传统 RAG 更简单。
主要来源：GitHub 上 nashsu/llm_wiki
GitHub Trending：TypeScript 排名第 10，19,536 stars，2,207 forks