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

相关推荐
大模型momo28 分钟前
Spring AI 实战:多 Agent 协作实战 —— 分工拆解复杂旅游行程任务
人工智能·spring·ai·agent·旅游
冬奇Lab1 小时前
开源项目第176期:Better Harness — 不审查 diff,审查工作流本身,给 AI 编程 Agent 的五维评估框架
人工智能·开源·agent
用户469368483205 小时前
kimi-code 深度掌握系列文章-关键架构决策(三)
agent
Loveyourself5 小时前
你知道吗?详细揭秘cc中api层微压缩-microcompact
面试·agent
云原生melo荣5 小时前
Multi-Agent 系统(一):问题域与架构选型——为什么这次"固定流程"编排不动
agent·ai编程
码农胖大海6 小时前
AI 响应慢自查清单
agent·ai编程
苏灿烤鱼7 小时前
GitHub Trending 日报|Agent 记忆登顶,老牌项目集体返场
安全·agent·资讯
苏灿烤鱼7 小时前
GitHub Trending 榜首|腾讯 Agent 记忆库技术拆解:分层记忆 vs 向量堆,让 AI 不再反复问
typescript·开源·agent
孙启超7 小时前
【AI应用开发】ReAct 原理是什么?和普通直接提问 LLM 差别在哪?
前端·人工智能·llm·agent·react·rag·ai应用开发
小七-七牛开发者9 小时前
“打透” Harness:用 GitHub Copilot 跑通从原型、规划到实现与评审的 AI Coding 工作流
ai·大模型·agent·token·工作流·claudecode·ai coding