整理
这是一份围绕"知识层级（L1–L4）"与"系统分层架构（L0–L4）"双视角的知识库工程笔记，梳理了你当前所处位置（L2 结构化文档）、Nexus 所指的目标（L4 编译后知识），以及对应的存储、检索、编译、技能、调度五层调用关系。
一、笔记主题
知识库构建中的知识抽象层级与系统能力分层——从原始字节到可被 Agent 调度的"编译后知识"全景图。
二、视角一：知识抽象层级（What we have）
这一视角描述的是"数据/知识本身"被加工到何种成熟度。每上升一层，语义密度越高、可直接消费性越强。
| 层级 | 名称 | 当前定位 | 关键产物 |
|---|---|---|---|
| L1 | 原始文本 | — | PDF / HTML / Word 原始字节 |
| L2 | 结构化文档 | 你目前所处位置 | Tika 解析 + 标题 / 段落 / 列表树 + Neo4j |
| L3 | 语义化知识 | 部分接近 | 实体、关系、事件抽取，构建知识图谱 |
| L4 | 编译后知识 | Nexus 所指目标 | 预生成 QA 对、摘要簇、推理链、命题库、Embedding 缓存、可执行规则 |
理解要点：
- L1 → L2 解决的是"能不能读"的问题，核心是解析与结构还原（Tika 抽取正文，恢复标题/段落/列表的层级树，并以 Neo4j 表达文档
以下是将这场关于"编译知识与RAG演进"对话整理成的结构化笔记，按概念递进、技术路线、范式转移三个维度组织，便于后续查阅与复用。
一、核心议题:从"切片检索"到"编译知识"再到"基础设施化"
整场对话围绕一个递进的主线展开:RAG 不是死了,而是正在从"端到端的问答产品"退化成"Agent 可调用的基础设施",而知识本身也在从"被检索"升级为"被编译"。
二、知识表示的四层递进模型
理解"编译知识"概念的关键,在于看清文档从原始字节走向模型可直接调用的形态,中间存在四个层级的跃迁。
| 层级 | 名称 | 当前位置 | 做了什么 |
|---|---|---|---|
| L1 | 原始文本 | — | PDF / HTML / Word 原始字节 |
| L2 | 结构化文档 | 现有方案在此 | Tika 解析 + 标题/段落/列表树 + Neo4j 存储 |
| L3 | 语义化知识 | 部分接近 | 实体、关系、事件抽取,构建知识图谱 |
| L4 | 编译后知识 | Nexus 等系统所指 | 预生成 QA 对、摘要簇、推理链、命题库、Embedding 缓存、可执行规则 |
类比来说:L2 像是把书排好版做好目录索引,模型查阅时翻得快;L4 则是把书读懂之后提炼成定理卡片、解题模板和概念图谱,让模型不用再读原文就能直接调用结论。L2 → L4 之间发生的事,就是"编译"。
三、"编译知识"的七类常见产物
不同系统叫法各异,但落地形态大体可分为七类,可按需组合叠加。
命题化(Propositionalization) 把段落拆成独立、自洽、可单独理解的"原子命题",每条带溯源指针。检索命中率更高,幻觉更少。代表工作是 Dense X Retrieval: What Retrieval Granularity Should We Use?。
预生成 QA 对(Synthetic QA) 离线让 LLM 为每个段落生成可能被问到的问题及标准答案。检索从 query→chunk 的语义匹配升级为 query→question 的同构匹配,召回率显著提升。Nexus、RAGFlow、LlamaIndex 的 Question-Answer Index 都用此思路。
多层级摘要(Hierarchical Summarization / RAPTOR) 对树状结构的每个节点(段落→小节→章节→全书)递归生成摘要,形成摘要树,兼顾细节命中与全局视角。Stanford RAPTOR (2024) 是代表。
实体-关系图谱(Knowledge Graph) 用 LLM 或 OpenIE 抽取三元组,与文档树融合。微软 GraphRAG 是典型实现:抽取→社区聚类→社区摘要→按社区命中查询。
推理链缓存(Reasoning Trace Caching) 对常见问题离线跑 CoT,把推理路径存下来,在线复用或微调,省 token 省延迟。
多视图 Embedding(Multi-view Encoding) 同一段内容生成多个语义视图(原文、问题、关键词、HyDE 假设性回答),任一视图命中即可。
可执行规则 / DSL 化 对结构化强的领域(财报、法规、API 文档),把知识编译成 JSON Schema、规则表、函数签名,模型直接当工具调用而非文本读。
四、对"RAG 已死"论的辨析
讨论中出现的几种观点其实并不互相矛盾,关键是要分清楚"哪种 RAG 死了""哪种 RAG 没死"。
"传统 RAG 死了"——对的一半。 单纯 chunk + embedding + top-k + 拼 prompt 的朴素 RAG,在多跳问答上完成率常常只有 30–50%(参考 FRAMES、CRAG benchmark),在严肃企业场景里确实不够用。但"RAG 不如 SOP"是错位对比:SOP 是任务执行框架,RAG 是知识获取手段,一个成功的 SOP 内部仍在调用某种形式的 RAG,只不过从"一次性大召回"降级为"流程里某一步的精准查询"。RAG 不再作为系统主架构,而是退化为 Agent 工具箱里的 function call,这是升级不是死亡。
"上下文够长就不需要 RAG"——长期方向对,短中期不成立。 现实有三道墙:有效注意力长度(名义 1M、有效约 400K,Lost-in-the-middle 现象在 200K 后急剧恶化,参考 NoLiMa、RULER);成本与延迟(百万 token 推理的成本和首 token 延迟不可接受);知识更新(企业知识每天在变,需增量更新、权限隔离、审计追溯)。把 RAG 类比成 OS 文件系统的比喻非常准——容量从来不是文件系统存在的核心理由,组织、检索、权限、版本才是。
"医院这种文本数据不用 RAG 还能用啥"——真问题。 医疗、法律、金融、制造等领域的特征(TB 级数据量、强权限隔离、强溯源、强实时性、强结构化)决定了未来形态是:结构化存储(图谱+关系库+向量库+全文倒排)→ Agent 按需查询 → 模型推理。向量相似度只是召回通道之一,工业界共识是 BM25 + Embedding + Rerank 三件套加 Metadata 过滤。
"主动检索不如被动触发"——最有洞察力的一句。 这点出了下一代 RAG 的关键转向。
五、范式转移之一:检索的主客易位(三代演进)
第一代 Push-based RAG(推送式) 系统先检索后拼 prompt,模型被动接收,吃错了也将错就错。
第二代 Pull-based RAG(拉取式 / Agentic Retrieval) 模型成为主动方:读问题→判断缺什么→生成 query(改写、分解、多跳)→看结果→决定是否再查。代表工作 Self-RAG、CRAG、ReAct、Anthropic Agentic Search。检索从"一次性的前置步骤"变成"推理过程中的一个动作",与调用计算器同类。
第三代 Skill-based / Tool-as-Knowledge 模型面对的不是抽象知识库,而是一组带语义说明的检索技能,如 search_patient_records(patient_id, time_range)、find_similar_cases(symptoms[])。每个 skill 内部封装最合适的检索逻辑,对外暴露语义清晰的能力。
这与 MCP → Skill 的演化是同构的:都是把多个底层工具按任务封装成语义聚焦的技能包,回答同一个问题——如何让模型用自己的判断力精准获取所需,而不是被动接收噪声。
六、范式转移之二:RAG 基础设施化的分层架构
类比数据库从"产品"到"基础设施"的演变,RAG 也正经历同样过程。作为产品的 RAG(独立问答系统)天花板很低;作为基础设施的 RAG 则分层暴露能力。
| 层级 | 提供的原语 | 调用者 |
|---|---|---|
| L0 存储层 | 向量库、倒排索引、图数据库、对象存储 | 上层引擎 |
| L1 检索层 | 语义相似、BM25、混合检索、Rerank、Metadata 过滤 | Skill / Tool |
| L2 编译层 | 命题化、QA 对、层级摘要、实体图谱 | Skill / Tool |
| L3 技能层 | 领域化的检索 skill(带语义描述) | Agent |
| L4 调度层 | Agent / 推理循环 | 用户 / 上层应用 |
L0–L2 是纯基础设施,不存在"RAG 产品"这个东西,只有可被任意 Agent 调用的检索/记忆能力。 现有方案(Tika 解析→树状存储→双切片→Neo4j)正好是 L0–L2 的工程实现,这套东西本身永远不会过时,过时的只是"把它直接当问答系统用"。
七、统一图景:Agent 系统的操作系统类比
把"模型主动检索"与"RAG 基础设施化"叠加起来,可用一个工程上越来越实在的类比概括:
模型 = CPU;上下文 = 寄存器 / L1 缓存;RAG = 内存 / 磁盘;Skill = 系统调用;Agent loop = 操作系统调度器。
在这个图景里:模型决定何时发起检索(调度);Skill 决定如何检索(系统调用的具体实现);RAG 基础设施决定检索的物理执行(IO);上下文窗口承担热数据缓存;长期记忆/知识库承担冷数据存储。"RAG 死不死"的问题就像问"硬盘会不会被内存淘汰"——只要有冷热分层需求,外部存储就一定存在,变化的只是接口形态和调用方式。
八、落地建议:对现有方案的演进路径
针对已经做到 L0–L2 的工程实现,推荐按投入产出比叠加以下动作。
第一步(性价比最高):预生成 QA 对 + 命题化 在已有 Neo4j 节点上跑离线 LLM,给每个段落节点挂 propositions[] 和 synthetic_questions[] 两个属性,一起进向量库,召回率通常涨 10–20 个点,改动极小。
第二步:层级摘要(RAPTOR 式) 树已建好,对每个非叶子节点用 LLM 生成 summary 字段,形成摘要树。回答全局性问题(如"这本书讲了什么")效果立竿见影。
第三步:实体关系抽取 + GraphRAG 构建和维护成本较高,适合知识密度大、跨文档关联多的场景(企业 Wiki、法律库)。
第四步(关键的视角转换):Skill 化重构 不要再暴露统一的 search(query) 接口,而是按文档内容拆分语义清晰的 skill,例如 find_section_by_topic、get_parent_context、get_sibling_sections、summarize_chapter、find_definitions。每个 skill 内部决定用小切片还是大切片、向量还是图遍历、是否带摘要,并配以高质量的语义描述(描述质量决定模型能否选对)。完成这一步后,系统就从"一个 RAG 问答应用"升级为"一个为 Agent 提供文档操作能力的 SDK",生命周期更长,也更容易接入未来任何更强的模型。
九、几个值得记住的金句
"RAG 可以作为记忆层的某一层。"——最贴近未来真实形态的判断。
把 RAG 类比成 OS 文件系统——这个比喻恰恰说明 RAG 不会消失。
主动检索不如被动触发,且基于相似度的检索在高重复、高一致但不精确匹配的文档中任务完成率会大打折扣。
能从"检索算法层"跳到"调用关系层"去看问题,这个视角转换比优化检索本身更有价值。
笔记整理完成,核心脉络是**"知识编译四层模型 → 七类编译产物 → RAG 演进辨析 → 主客易位三代 → 基础设施化五层 → OS 类比 → 落地四步"**,可作为后续技术选型与架构演进的参考底稿。
企业级项目导航：⬅️ 01-关于rag发展的思考 | 02-整理 | ➡️ 01-主流模型选型指南
💬 评论