RAG 与 LLM Wiki

LLM Wiki

素材:Karpathy 的 LLM Wiki 构想

传统 RAG 通常先对原始资料进行切块并建立索引。索引不一定是向量索引,也可以采用关键词、BM25 或混合检索。用户提问时,检索器通过索引找出相关片段,再把这些片段交给 LLM 理解和生成答案。

因此,RAG 不是每次加载整个资料库,而是在每次查询时重新检索相关内容。模型对知识的理解只存在于当前上下文中,下次查询通常还要重新检索和整理。

LLM Wiki 采用不同的处理方式:智能体提前读取原始资料,将其中的知识整理成结构化、可持续维护的 Wiki 页面。它类似于一套由 LLM 整理的学习笔记,下次查询时可以优先使用已经归纳好的知识。

LLM Wiki 不依赖 RAG 才能建立,但二者可以结合使用。


一、LLM Wiki 的三层结构

1. raw/:原始资料层

raw/ 保存只读的原始资料,是整个知识库的证据来源。智能体可以读取这些资料,但不应随意修改。

原始资料不一定是 Markdown,也可以是网页、论文、PDF、邮件或代码。

2. wiki/:整理后的知识层

wiki/ 是主要查询对象,通常由一组 Markdown 页面组成,可以包含:

  • 入口索引和知识概述;
  • 概念与名词解释;
  • 人物、组织等实体页面;
  • 对比、总结和综合分析;
  • LLM 建立的交叉链接。

其中常见的导航文件有:

  • index.md:面向内容的入口索引,用于定位相关页面;
  • log.md:面向时间的操作记录,按顺序记录 IngestQueryLint,用于追踪知识库的演化。

3. 规则层

规则层规定原始资料如何处理、页面如何组织,以及智能体应当怎样工作。

AGENTS.md 可以看作写给智能体的操作手册,主要包括:

  • 项目和目录说明;
  • 允许与禁止的操作;
  • IngestQueryLint 的基本流程;
  • 其他规则文件的入口。

CLAUDE.mdClaude Code 自动读取的项目规则文件。Claude Code 不会直接读取 AGENTS.md,但可以在 CLAUDE.md 中导入:

markdown 复制代码
@AGENTS.md

规则较多时,可以继续拆分:

  • wiki-agent.md:定义智能体怎样读取资料、执行操作、写回知识,以及哪些修改需要人类确认;
  • wiki-schema.md:定义目录结构、页面类型、命名方式、引用格式和输入输出规则。

这两个文件不是必需的,名称也不是统一标准。规则较少时,可以全部写在 AGENTS.md 中;拆分后,只需在入口规则中写清楚文件路径。


二、三个核心操作

1. Ingest:增加知识

Ingestraw/ 读取新增资料,提取重点,生成或更新相关的 Wiki 页面、索引与交叉链接。

2. Query:查询知识

查询时通常优先读取 Wiki。如果现有知识足够,就直接回答,不必更新知识库。

如果 Wiki 信息不足、缺少证据或存在矛盾,再回到 raw/ 检索和核验。

只有发现具有长期复用价值的新知识时,才通过 Ingest 更新 Wiki;一次性问题可以只回答,不写回。

重大矛盾或大范围修改应交给人确认。

3. Lint:维护知识

Lint 用于检查重复内容、过时结论、相互矛盾的页面、孤立页面、缺失链接和知识空白。

Lint 默认负责检测和报告问题。只有规则明确允许时,才能自动修复安全且确定的问题;涉及重大矛盾或语义变化时,应由人决定。


三、传统 RAGLLM Wiki 的分工

Wiki 适合归纳、比较和建立知识之间的联系。由于摘要和交叉关系已经提前整理,查询时不必每次都从零拼接原始片段。

RAG 适合从大量资料中定位逐字证据、精确数值、实时状态或责任记录。遇到这些场景时,可以通过 RAG 检索 raw/,但最终仍应回到原始资料或实时系统核验。

小型知识库可以直接通过 index.md 导航和查询 Wiki,不一定需要 RAG

text 复制代码
raw/ → Ingest → Wiki → index.md 导航 → Agent

当原始资料特别多、难以逐份处理时,可以先为 raw/ 建立RAG检索索引,帮助 Ingest 定位相关资料。不过,如果目标是建立完整的 Wiki,仍要记录并处理全部原始资料,不能只处理检索到的部分。

同样,当 Wiki 页面越来越多时,可以为 Wiki 建立检索索引。业务智能体先通过 RAG 找到相关页面,再读取这些页面并生成回答。

因此,RAGLLM Wiki 不是互斥的,它们可以相互协作:

text 复制代码
大量 raw/
    ↓ 第一层 RAG:定位相关原始资料
Ingest 整理
    ↓
Wiki
    ↓ 第二层 RAG:检索 Wiki
业务 Agent 查询和回答

简单来说就是:

  • raw/ 太多:为原始资料建立索引,用第一层 RAG 辅助 Ingest
  • wiki/ 太多:为知识页面建立索引,用第二层 RAG 查询 Wiki
  • 回答证据不足:通过 RAG 检索 raw/,再核验原始资料。

这种方式可以称为分层检索。如果两层都包含检索、补充上下文和生成,也可以称为双层 RAG

此外,WikiLLM 根据原始资料二次加工得到的知识,不能保证内容始终真实、准确和及时。因此,建议在页面中记录资料来源、更新时间和人工审核状态,重要结论仍要回到原始资料核验。

LLM Wiki 的初始规则可以参考优秀的开源模板,但需要根据实际业务调整目录、页面类型、引用方式、权限边界和人工确认规则,不能原样照搬。

相关推荐
codingWhat2 小时前
从“模型会说话”到“Agent 可管理”:一套 AI 资产平台的前端工程实践分享
agent
花千树_0102 小时前
插件加载方式选不好,迟早被同事吐槽——四种姿势全解析
langchain·agent
疯狂学习GIS2 小时前
AI Agent 操作 QGIS 实测:Codex 与 Claude Code 能自己出图吗
人工智能·ai·大模型·gis·agent·qgis·codex
大模型真好玩4 小时前
LangChain DeepAgents 速通指南(十一)—— DeepAgents Code 记忆与状态管理
人工智能·langchain·agent
名不经传的养虾人5 小时前
从0到1:企业级AI项目迭代日记 Vol.67|能运行,和能商用
人工智能·agent·ai编程·企业ai·多agent协作
杠杠的blog6 小时前
企业级提示词管理
python·agent·提示词·生产级实践
武子康6 小时前
LingBot 四线全拆:Video / World / VLA / VA 按最终输出选型 + 开源许可证避坑表
人工智能·llm·agent
为你学会写情书7 小时前
RAG 性能总卡在检索?先搞懂 Milvus 向量数据库再说
llm·agent
TrisighT7 小时前
Agent 并行工具调用快了 0.8 秒——200 组实测发现,多花的那 3100 token 全打了水漂
aigc·agent·ai编程