HKUDS051: HKUDS RAG 系列专题总结 - LightRAG / RAG-Anything / MiniRAG / VideoRAG 对比

这是 PENGYI_HKUDS_STUDYMAP 的 HKUDS051。

原来在 HKUDS050 里，HKUDS051 曾经预告为 OpenCity。 但现在我们先把编号调整一下：

HKUDS051 -> HKUDS RAG 系列专题总结

原因很直接：

RAG 是我们 Research OS / Quant OS / Agent Harness 的知识入口和记忆底座。

我们已经看过很多 HKUDS 里的 RAG 项目，但之前是分散看的。 现在需要做一次横向总结：

LightRAG
RAG-Anything
MiniRAG
VideoRAG

以及若干 RAG-adjacent 项目：

Paper2Slides
VideoAgent
FastCode
AutoAgent
AnyTool / FastAgent Smart Tool RAG
CatchMe
SepLLM
MGP

这篇的目标不是重复每个 repo 的细节。 目标是回答：

HKUDS 的 RAG 版图到底是什么？
每个 RAG 项目解决哪个环节？
它们有什么区别？
它们如何组合成 Pengyi Research OS 的知识系统？

一句话总览

我现在对 HKUDS RAG 系列的判断是：

HKUDS RAG stack = multimodal ingestion + graph memory + lightweight local memory + video memory + agent/product integration + memory governance.

中文：

HKUDS 的 RAG 不是单一“向量库问答”。
它是一套从多格式资料进入系统，到图谱索引、轻量检索、视频记忆、agent 使用、产品输出、长期治理的知识基础设施。

如果压成一张图：

PDF / paper / report / table / formula / image
  -> RAG-Anything

video / lecture / interview / meeting
  -> VideoRAG

notes / markdown / docs / research artifacts
  -> LightRAG / MiniRAG

agent / tool / report / slides / video workflow
  -> AutoAgent / FastAgent / Paper2Slides / VideoAgent

persistent memory governance
  -> MGP / CatchMe / SepLLM

普通 RAG 的基线

普通 RAG 通常是：

document
  -> chunks
  -> embeddings
  -> vector search
  -> retrieved chunks
  -> LLM answer

它的优点：

简单
容易实现
成本低
适合文本 QA

但它有几个硬问题：

1. 复杂文档不是纯文本。
2. PDF、表格、图片、公式、布局很难直接变成干净 chunk。
3. 长文档里 entity / relation / global structure 容易丢。
4. 视频、讲座、会议不是普通文本。
5. 检索结果缺少清晰 provenance 和结构化证据。
6. 小模型和端侧环境承受不了重型 RAG。
7. 长期 memory 需要治理、压缩、审计，而不是无限堆上下文。

HKUDS RAG 系列就是围绕这些问题展开。

核心四件套

核心 RAG 四件套：

编号	项目	一句话定位	解决的问题
HKUDS001	LightRAG	graph-based RAG / research memory	文本知识如何进入图谱化、source-grounded 记忆
HKUDS007	RAG-Anything	multimodal document ingestion	PDF、表格、公式、图片、Office 文档如何进入 RAG
HKUDS018	MiniRAG	lightweight graph RAG / on-device memory	小模型、低资源、本地化场景如何做结构化检索
HKUDS021	VideoRAG	long-context video memory	视频、访谈、课程、讲座如何变成 timestamped evidence

这四个不是互相替代。 它们是分层互补。

RAG-Anything = complex document entrance
VideoRAG     = video entrance
LightRAG     = graph-based research memory
MiniRAG      = lightweight local memory

LightRAG

LightRAG 是我们最早拆的 RAG 核心项目。

一句话：

LightRAG = graph-based RAG infrastructure for source-grounded research memory.

它和普通向量 RAG 的区别在于：

普通 RAG:
  document -> chunks -> vector search -> answer

LightRAG:
  document -> parse -> chunk -> entity/relation extraction
           -> graph storage + vector storage + KV storage
           -> local/global/hybrid/mix query
           -> source-grounded answer

LightRAG 最重要的结构：

Document pipeline
Chunking strategy
Entity extraction
Relation extraction
Graph storage
Vector storage
KV storage
Doc status storage
Query modes
API server / WebUI

它对我们的意义：

Research OS 的长期知识记忆层。

适合存：

paper
technical report
project note
README
CV / PS / RP material
quant research memo
agent logs after summarization

LightRAG 的强项：

graph structure
source grounding
multiple query modes
storage backend abstraction
API / WebUI productization

LightRAG 的风险：

entity extraction quality matters
graph quality matters
chunking still matters
source verification still required
not every document deserves heavy graph indexing

RAG-Anything

RAG-Anything 的定位：

RAG-Anything = Multimodal Document Ingestion + All-in-One RAG Layer.

它解决的是一个更前端的问题：

真实文档不是纯文本。

真实研究资料通常是：

text
table
image
formula
chart
layout
page context
Office file
PDF structure

RAG-Anything 的路径：

complex document
  -> parser
  -> multimodal content_list
  -> text insertion + modal processing
  -> LightRAG storage / KG / retrieval
  -> text or multimodal query

它的关键组件：

parser
processor
modal processors
batch processing
callbacks
resilience
query
LightRAG dependency
MinerU / Docling / PaddleOCR parser options

它对我们的意义：

Research OS 的多模态文档入口层。

适合处理：

academic paper PDF
financial report
FICC document
company annual report
table-heavy document
chart-heavy document
contract
slides
screenshots

RAG-Anything 的强项：

multi-format ingestion
multimodal element handling
document parsing abstraction
batch and cache mindset
RAG pipeline robustness

RAG-Anything 的风险：

parser quality决定上游质量
OCR / table extraction / formula extraction 容易有噪声
复杂文档需要 human spot check
多模态结果进入 KG 时可能产生错误关系

MiniRAG

MiniRAG 的定位：

MiniRAG = Lightweight Graph RAG + On-Device Knowledge Layer.

它和 LightRAG 的关系：

LightRAG 关注完整 graph RAG 能力。
MiniRAG 关注小模型、低存储、低复杂度、端侧 RAG。

它的核心判断：

不要把理解压力全部放在小模型上。
把更多结构信息提前放进 index 和 retrieval。

MiniRAG 的思路：

text chunks
  + named entities
  + relationships
  -> heterogeneous graph
  -> answer type / query entities
  -> 2-hop graph neighborhood
  -> edge voting / chunk scoring
  -> small high-value context

它对我们的意义：

Research OS 的 lightweight local memory tier。

适合：

本地 notes
小规模项目记忆
低成本 agent memory
端侧或私有环境
低资源 notebook / laptop workflow
小模型辅助检索

MiniRAG 的强项：

lightweight
local-first
small model friendly
graph topology enhanced retrieval
less dependence on long context

MiniRAG 的风险：

适合轻量场景，不一定承接复杂大规模知识库
graph schema 和 retrieval heuristic 要调
小模型生成能力仍有限

VideoRAG

VideoRAG 的定位：

VideoRAG = Extreme Long-Context Video Memory + Multimodal Knowledge Ingestion.

它不是简单：

video -> transcript -> text RAG

它更接近：

video
  -> segment
  -> transcript
  -> caption
  -> visual embedding
  -> text chunk
  -> entity graph
  -> text retrieval + graph retrieval + visual retrieval
  -> timestamped answer

它的核心价值：

把长视频变成可查询、可引用、可回到原时间戳的 evidence object。

适合：

访谈
课程
讲座
seminar
podcast
公司分享
research talk
demo video
会议录像

它对我们的意义：

Research OS 的 video evidence ingestion layer。

我们经常看：

硅谷101
田渊栋访谈
AI researcher interview
quant seminar
technical talk
course video

如果只是看过，知识会消失。 进入 VideoRAG 后，可以变成：

timestamped notes
quoteable evidence
topic summary
QA memory
follow-up tasks
research idea source

VideoRAG 的强项：

video-specific segmentation
visual + transcript + graph integration
timestamp provenance
long-context video benchmark
product surface through Vimo

VideoRAG 的风险：

视频处理成本高
视觉 embedding / caption quality matters
长视频索引耗时
license / model dependency 要注意
不是所有视频都值得重处理

四者横向对比

维度	LightRAG	RAG-Anything	MiniRAG	VideoRAG
核心输入	文本、文档、notes、reports	PDF、Office、图、表、公式、图片	小规模文本/知识库	视频、transcript、caption、visual segments
核心目标	graph-based research memory	multimodal document ingestion	lightweight / on-device RAG	long-context video memory
核心索引	KG + vector + KV	content list + modal processors + LightRAG	heterogeneous graph + lightweight retrieval	segment graph + text/visual retrieval
典型用户	research OS / knowledge base	document-heavy research workflow	local agent / small model	video research / meeting intelligence
适合资料	论文、notes、README、报告	PDF、研报、表格、公式、合同	本地摘要、轻量知识	访谈、课程、讲座、会议
强项	source-grounded graph memory	复杂文档入口	低成本、本地、小模型友好	时间戳、多模态视频证据
风险	graph extraction 噪声	parser / OCR 噪声	能力上限较轻	成本和处理复杂度高
Pengyi 位置	主知识记忆层	多模态文档入口	轻量本地记忆层	视频知识入口层

不同 RAG 该怎么选

如果是：

markdown notes / research reports / project docs

优先：

LightRAG

如果是：

PDF / 研报 / 表格 / 公式 / 图表 / Office 文档

优先：

RAG-Anything -> LightRAG

如果是：

本地小知识库 / 低成本 / 小模型 / personal memory

优先：

MiniRAG

如果是：

访谈 / 课程 / 视频 / seminar / meeting

优先：

VideoRAG

如果是：

论文转 slides / report artifact

考虑：

RAG-Anything + LightRAG + Paper2Slides

如果是：

视频进入 workflow / 剪辑 / QA / meeting summary

考虑：

VideoRAG + VideoAgent

RAG-adjacent 项目

HKUDS 里很多项目不是 RAG 本身，但和 RAG 系列强相关。

项目	关系
Paper2Slides	把 RAG 结果变成 slides/poster artifact
VideoAgent	复用 VideoRAG 作为 video memory backend，做 video workflow frontend
FastCode	code intelligence / repo-level retrieval，可看作 code RAG adjacent
AutoAgent	内置 RAG tools 和 MultiHopRAG evaluation，展示 agentic RAG use case
AnyTool / FastAgent	Smart Tool RAG，把工具描述和能力做检索路由
CatchMe	个人数字足迹捕获，是 personal context source
SepLLM	long-context / KV cache compression，解决 memory budget
MGP	memory governance protocol，解决持久记忆的 policy / audit / lifecycle
AgentSpace / OpenSpace	agent workspace 需要知识层接入

这些项目说明：

RAG 不只是 answer generation。
RAG 是 agent workspace 的 knowledge substrate。

RAG 和 Agent 的关系

RAG 在 agent 系统里不是一个单独功能按钮。

它应该进入：

planning
tool selection
memory recall
evidence gathering
report writing
debugging
evaluation
human review

例如：

Research Agent
  -> query LightRAG for prior notes
  -> use RAG-Anything to parse new PDF
  -> use VideoRAG for seminar evidence
  -> use MiniRAG for local fast recall
  -> write report
  -> store summary back into memory
  -> MGP governs persistent memory

这就是 agent-native RAG。

不是：

用户问一句，系统查几段文本，然后回答一句。

而是：

RAG becomes part of an iterative research loop.

RAG 和 Quant Research OS

对量化研究来说，RAG 可以分层使用。

Document ingestion:
  RAG-Anything
  -> financial reports, filings, strategy papers, FICC docs, contracts

Knowledge memory:
  LightRAG
  -> factor notes, strategy docs, research papers, project memory

Lightweight recall:
  MiniRAG
  -> local notebook memory, sanitized factor examples, small domain KB

Video evidence:
  VideoRAG
  -> quant talks, PM interviews, macro seminars, educational courses

Governance:
  MGP
  -> what can be stored, recalled, exported, deleted, audited

一个 Quant R&D Agent 可以这样使用：

new research question
  -> retrieve prior factor notes from LightRAG
  -> parse new paper with RAG-Anything
  -> retrieve talk evidence from VideoRAG
  -> generate hypothesis
  -> implement and backtest
  -> write diagnosis
  -> store distilled result
  -> govern memory through MGP

这就是我们的方向。

Pengyi RAG Stack v0

我建议我们的 RAG stack 这样设计：

Layer 0: Raw Sources
  paper
  PDF
  markdown
  code
  video
  slides
  reports
  screenshots
  web pages

Layer 1: Ingestion
  RAG-Anything for documents
  VideoRAG for videos
  simple markdown parser for notes
  code parser / FastCode-style retrieval for repos

Layer 2: Normalization
  text chunks
  entities
  relations
  metadata
  timestamps
  source links
  artifact ids

Layer 3: Memory Stores
  LightRAG for graph research memory
  MiniRAG for lightweight local memory
  vector store for semantic recall
  file/object store for artifacts

Layer 4: Query Modes
  local
  global
  hybrid
  multimodal
  video timestamp query
  tool / code / artifact query

Layer 5: Agent Use
  research planning
  report writing
  code implementation
  quant hypothesis generation
  backtest diagnosis
  human PM review

Layer 6: Governance
  MGP-style policy
  audit log
  expiry
  delete / revoke
  source verification

这就是 Pengyi Research OS RAG Layer。

RAG 系列的共同启发

第一，RAG 的上限取决于入口质量。

垃圾解析 -> 垃圾 chunk -> 垃圾检索 -> 垃圾回答。

所以 RAG-Anything 很重要。

第二，RAG 的可靠性取决于 provenance。

能回到原文、原页、原视频时间戳，才有研究价值。

所以 LightRAG / VideoRAG 的 source grounding 很重要。

第三，RAG 需要结构，不只是 embedding。

entity / relation / graph / timestamp / metadata

都在帮助系统理解材料。

第四，RAG 要分层。

heavy memory
light memory
temporary memory
video memory
tool memory
personal context memory

不能一个向量库打天下。

第五，RAG 要治理。

什么能记？
什么不能记？
什么时候过期？
谁能调用？
调用后如何审计？

这就是 MGP 的意义。

对比普通 RAG、Graph RAG、多模态 RAG

类型	输入	检索结构	优点	缺点
普通 Vector RAG	text chunks	vector similarity	简单、快、低成本	结构弱、全局关系弱、source grounding 需要额外做
Graph RAG	chunks + entities + relations	graph + vector	关系强、全局结构强	抽取质量和图维护复杂
Multimodal RAG	text + image + table + formula	modal processors + text/visual retrieval	能处理真实复杂文档	parser/OCR/VLM 噪声高
Video RAG	video segments + transcript + visual	timestamped multimodal graph	适合长视频和会议	成本高、处理链长
Lightweight RAG	small KB + graph heuristic	small graph + focused retrieval	本地、低成本、小模型友好	覆盖和上限有限

HKUDS 系列的价值是：

它没有停留在一种 RAG。
它把不同 RAG 形态都给出了工程参照。

失败模式

RAG 系统最常见失败：

1. Ingestion failure
   文档解析错、表格丢、公式错、OCR 错。

2. Chunking failure
   chunk 太碎、太长、语义边界错。

3. Entity failure
   抽错实体、漏关系、关系方向错。

4. Retrieval failure
   问题没有召回正确证据。

5. Context failure
   召回了证据，但上下文组织不好。

6. Generation failure
   LLM 忽略证据、幻觉、过度总结。

7. Provenance failure
   答案无法回到原文或时间戳。

8. Memory failure
   旧知识污染新任务，或长期记忆不可治理。

对应防线：

parser check
chunk preview
entity graph inspection
retrieval trace
source citation
human review
audit log
memory policy

如果要做我们自己的 RAG demo

最小可行路线：

RAGDEMO000:
  markdown notes -> LightRAG-style graph memory -> query with citations

RAGDEMO001:
  PDF / report -> RAG-Anything-style parsing -> structured extraction -> query

RAGDEMO002:
  video transcript + timestamps -> VideoRAG-lite -> timestamped QA

RAGDEMO003:
  MiniRAG-style local memory -> small model / low-cost retrieval

RAGDEMO004:
  RAG + Agent loop -> research question -> evidence -> report -> next plan

我们不应该一上来复制完整 HKUDS 工程。 应该先做：

小而完整的 RAG loop。

面试可用表达

如果被问“你理解 RAG 吗”，不能只说：

RAG = retrieval augmented generation.

应该说：

I view RAG as a full knowledge pipeline, not just vector search.
It includes ingestion, parsing, chunking, metadata, indexing, retrieval, context construction, generation, provenance, evaluation, and memory governance.

Different RAG systems solve different bottlenecks.
LightRAG focuses on graph-based source-grounded research memory.
RAG-Anything focuses on multimodal document ingestion.
MiniRAG focuses on lightweight and on-device graph retrieval.
VideoRAG focuses on timestamped multimodal video memory.

For an agentic Research OS, RAG should be part of the research loop:
retrieve prior knowledge, ingest new evidence, support planning, ground reports, store distilled results, and govern memory over time.

这段可以直接用于 AI / RAG / Agent / Quant Research Engineer 面试。

当前结论

HKUDS051 的核心结论：

HKUDS RAG 系列已经覆盖了 Research OS 知识层的四个关键入口：
document, graph memory, lightweight local memory, video memory.

它们不是替代关系，而是组合关系：

RAG-Anything brings complex documents in.
VideoRAG brings videos in.
LightRAG organizes source-grounded graph memory.
MiniRAG provides lightweight local recall.
MGP / SepLLM / CatchMe govern, compress, and extend memory over time.

对我们来说，下一步应该不是继续泛泛地说“做 RAG”。

下一步应该是做：

Pengyi Research OS RAG Layer v0

也就是：

多源资料进入系统
结构化索引
可引用检索
agent 可调用
human 可审计
结果可沉淀
记忆可治理

这就是 HKUDS RAG 系列对我们的真正价值。