分支② 扎根知识
这条分支补主干的哪块缺口: 原始模型「只知道训练时见过的、和你这次塞进去的那点文字」。这条分支(RAG / 上下文工程)在模型回答前,先去外部资料里检索相关片段、拼进上下文,让答案扎根在真实材料而非模型的模糊记忆上。
1. 这条分支是什么(第一性原理)
模型的知识是「训练时冻结的 + 你这次塞进上下文的」。你公司的文档、此刻的网页、那份 PDF,它都不知道。直接问 → 它要么说不知道,要么编一个。
RAG(检索增强生成)的思路极简单:先检索,再生成。
文档/网页/PDF/视频 用户问题
│ │
▼ (离线:切块 → 嵌入 → 存索引) ▼ (在线)
┌─────────────┐ ┌──────────────┐
│ 知识索引 │◄──────检索────│ 把问题向量化 │
│ (向量/图/KV) │──相关片段──┐ └──────────────┘
└─────────────┘ ▼
┌────────────────────────┐
│ 把「相关片段 + 问题」一起 │──► 模型基于真材料作答
│ 拼进上下文喂给模型 │
└────────────────────────┘
分支里的库,差别在三件事:怎么切块/解析、索引建成什么结构(向量?图?)、检索和拼装的流程怎么组织。
2. 分支内有哪几种做法(流派)
扎根知识 (RAG)
│
┌────────────────┼─────────────────┬──────────────────┐
▼ ▼ ▼ ▼
通用 RAG 框架 图增强 RAG 多模态 RAG 长文研究型
「向量检索为主」 「实体/关系图」 「PDF/表/图/视频」 「拆成研究流程」
langchain hkuds-lightrag hkuds-rag-anything storm
llamaindex hkuds-videorag
haystack
- 通用 RAG 框架:以向量检索为主, 提供切块/加载/检索/合成的通用积木,生态最广。
- 图增强 RAG:不止切块嵌入,还从文档抽实体和关系建图,按局部实体 / 全局主题双层检索。
- 多模态 RAG:把 PDF、表格、公式、图片、视频当一等检索单元处理。
- 长文研究型:把「写一篇有引用的长文」拆成「多视角检索 → 提纲 → 成文」的研究流程。
3. 对比矩阵(子库区别,逐格接地)
| 库 | 索引/检索结构 | 组织方式 | 一句话差异 | 代码锚点 |
|---|---|---|---|---|
| langchain | 向量检索 + 最广的检索器/加载器/切块器抽象 | 链(LCEL)+ 海量 provider 集成 | 生态最广的「积木总店」;现推荐 agent 面用 create_agent / 底层 LangGraph | (TODO: 待 langchain 子库 doc;libs/core、libs/partners) |
| llamaindex | 索引 + 查询引擎(node 解析 → 检索 → 响应合成) | 路由 + 子问题分解 | 主打「文档 QA / 文档 agent」,索引/查询引擎抽象最完整 | (TODO: 待 llamaindex 子库 doc;llama-index-core/) |
| haystack | 检索器/阅读器/生成器分解 | 显式 DAG 流水线,组件类型化连接 | 流水线显式、可序列化、偏生产;「显式而啰嗦」是特性不是缺点 | (TODO: 待 haystack 子库 doc;haystack/core/pipeline/pipeline.py) |
| hkuds-lightrag | 实体/关系图 + 向量 + KV 多后端 | naive/local/global/hybrid/mix 多查询模式 | 比微软 GraphRAG 更轻更快的图 RAG;查询模式差异极大,引用要点名模式 | (TODO: 待 hkuds-lightrag 子库 doc;lightrag/) |
| hkuds-rag-anything | 在 LightRAG 图索引之上 + 多模态解析 | 解析(MinerU/Docling)→ 模态感知切块 → 图+向量索引 | 把表格/公式/图片当一等检索单元,端到端多模态文档管线 | (TODO: 待 hkuds-rag-anything 子库 doc;raganything/) |
| hkuds-videorag | 视频的图+向量索引 | 融合转写/视觉字幕/音频信号 → 检索单元 | 把数百小时长视频索引成可查结构;查询时跨模态路由 | (TODO: 待 hkuds-videorag 子库 doc;monorepo 包在 VideoRAG-algorithm/videorag/) |
| storm | 在 DSPy 上的研究流水线 | 多视角发现 → 模拟访谈 → 提纲 → 成文,全程引用接地 | 不是「查一段答一句」,而是把长文写作拆成研究循环(Co-STORM 加人协作) | (TODO: 待 storm 子库 doc;knowledge_storm/) |
4. 模式与权衡
- 向量检索 vs 图检索:纯向量简单、覆盖广,但答不好「跨多个实体的全局问题」;图 RAG(lightrag)抽实体关系能答全局,但建图有抽取成本、schema 易变。这正是 RAG 与分支③记忆(graphiti 也用图)在「图」上的交汇点。
- 显式 vs 隐式流水线:haystack 的 DAG 显式啰嗦但可序列化、可部署、易调试;langchain/llamaindex 更高层省事但「魔法」多,排错更难。
- 解析质量决定上限:多模态 RAG 里,解析器选择(MinerU vs Docling)直接决定抽取质量——卡片明确要求记录用了哪个。
- 「检索 → 生成」只是最简形态:storm 证明,长文任务需要把检索拆进一个多阶段研究流程,而非一次检索。
5. 趋势
- 从「切块+向量」走向「图 + 多模态 + 多阶段」:HKUDS 系(lightrag → rag-anything → videorag)是这条演进线的清晰样本。
- RAG 与 agent 循环融合:llamaindex 的「文档 agent」、langchain 的 create_agent 表明 RAG 正从「静态管线」变成「agent 在循环里主动决定检索什么」——回到分支①。
- 评测成刚需:RAG 质量难肉眼判断,催生了分支⑥的 ragas(忠实度/相关性指标)。
6. 代表作 + 深入
- 入门通用 RAG / 要最广生态 → langchain;要文档 QA 的索引/查询引擎 → llamaindex。
- 要可部署、可序列化的显式管线 → haystack。
- 要图增强、能答全局问题 → hkuds-lightrag(并连到分支③的 graphiti 看「图」的另一面)。
- 要吃 PDF/表/图/视频 → hkuds-rag-anything / hkuds-videorag。
- 要写长篇有引用的研究文 → storm。