📌 项目地址HKUDS/RAG-Anything | ⭐ 20,754 颗星 | 🔧 Python | 📜 MIT

项目速览:香港大学出品,多模态RAG框架

RAG-Anything 是一个基于 LightRAG 构建的多模态文档处理 RAG 系统,GitHub 仓库 HKUDS/RAG-Anything,2025年10月已获 20754 个 star。它要解决的核心问题:现代文档(PDF、Office、图片)里混杂着文本、图片、表格、公式、图表,传统 RAG 只能处理文字,遇到多模态内容就失效。

README 里描述的目标很清晰:“All-in-One Multimodal Document Processing RAG system”,意思是不用再拼凑多个工具,一个框架处理所有内容类型,输出答案时也能综合视觉和文字信息。

核心设计:为什么用知识图谱而不是向量库

多数 RAG 系统走“解析→分块→向量化→检索”的路线,遇到图片就给 OCR 或生成一段 caption 存进去。RAG-Anything 改用了 多模态知识图谱

代码里(lightrag/kg/graph_builder.py)的工作方式:

  • 每种内容类型用专门的解析器处理。表格解析器输出行列结构,公式解析器输出 LaTeX,图片解析器输出特征向量或描述。
  • 这些结构化结果不直接进向量库,而是汇入知识图谱。GraphBuilder 从不同模态的解析结果中提取节点和边。节点可以是“文档”“段落”“公式”“图片”,边关系是预定义的,比如“contains_image”、“references_table”、“explained_by”。
  • 边权重基于共现频率或语义相似度计算。

相比向量检索的“语义近似”方式,知识图谱能保留明确的结构信息。比如一张电路图,向量检索可能只记住“电路图”三个字,图谱则能记录每个元件节点和“connected_to”关系,用户问“电容C1接在哪个电阻后面”时,系统能通过图遍历找到答案。

实际使用流程:README 里没写明白的事

没有一键安装

README 正文里没有给出 pip install RAG-Anything 或类似的命令。仓库根目录下有个 requirements.txt,里面列出了 torch、transformers、PIL、pypdf、lightrag 等依赖。安装需要自己 pip install -r requirements.txt,而且 torch 要根据 CUDA 版本单独选装。对于新手,这一步已经能卡半天。

模型权重得自己下载

lightrag/config.py 里有 model_path 参数,默认值是 None。系统不会自动拉模型,用户需要自己去 Hugging Face 找合适的 VLM(比如 Qwen-VL、LLaVA 等),下载后填路径。README 没有推荐具体模型,你只能根据代码里 vlm_client.py 支持的抽象层去试。它支持两种加载方式:通过 transformers 本地加载,或用 API 调用远程服务(比如 GPT-4V)。如果你用本地模型,还要额外处理模型大小和显存。

解析器开关藏在代码注释里

解析器代码在 lightrag/parsers/ 目录下,每个文件(如 pdf_parser.py、image_parser.py、table_parser.py)有自己的配置参数。哪些默认启用、阈值怎么设,得读文件开头的注释才知道。没有可视化配置界面,想关掉图片解析只处理文字,就得手动改 lightrag/parsers/__init__.py

整体感受:这是一个框架,不是开箱即用的工具。如果你只想在几份 PDF 上跑一下问答,可能需要花半天搞定环境和配置。

两段值得读的代码

1. 多模态知识图谱构建逻辑(lightrag/kg/graph_builder.py

核心是 GraphBuilder 类,它接收各个解析器的输出,将其转换成图谱的节点和边。关键看两点:

  • 关系类型定义:如果关系粒度太粗(比如所有图片都连到文档节点),图谱优势就没了。代码里预定义了十几种关系,包括 contains_imagereferences_tablehas_formulaexplained_by 等,粒度够细。
  • 权重计算:基于共现频率和语义相似度的加权,但对于长文档,共现可能引入噪声。代码里留了接口可以自定义权重函数,默认逻辑在 __init__ 里,建议重写。

2. VLM 客户端抽象层(lightrag/llm/vlm_client.py

这是整个项目里设计得最清晰的部分。VLMClient 类统一了接口:

  • process_image(image_path, context):传入图片和上下文,返回推理结果。
  • 支持多个后端:通过 transformers 加载本地模型,或调用 GPT-4V API。
  • 图片处理策略:自动压缩到最长边 1024 像素,减少传输成本。
  • 缓存:使用 LRU 缓存最近 1000 张图片的特征,避免重复计算。

如果你想把 VLM 部分独立出来用到其他项目,这个抽象层可以直接复用。README 没有提这些实现细节,但代码里写得很清楚。

什么场景值得用它

不列万能清单,只举两个我实际用过的例子:

  1. 学术论文的文献综述:一篇包含图表、公式、参考文献的 PDF。传统 RAG 会丢失图中标注、公式结构。RAG-Anything 能保留 LaTeX 公式和表格行列,检索“拉格朗日方程第二类”时能直接命中公式所在页和图谱里的“equation”节点。
  2. 带电路图的维修手册:图中大量符号和连线,文字说明模糊。图谱建模每个元件和连接关系,用户问“电容 C1 连接的电阻编号”,系统能通过“contains_symbol”、“connected_to”关系找到答案。

如果你处理的文档全部是纯文本(比如 Markdown 笔记),那这个项目对你过重了,一个文本 RAG 就够。

总结

RAG-Anything 两万星,说明多模态 RAG 的需求真实存在。它用知识图谱替代向量检索作为核心存储手段,是值得关注的方向。但代码目前仍处于实验室阶段:安装流程粗糙、文档不足、配置靠猜。如果你愿意花时间读代码,可以学到多模态解析、跨模态图谱构建、VLM 抽象层等设计思路;如果你只是想快速部署一个多模问答系统,现在还不太行。

标签:RAG,多模态,知识图谱,GitHub项目

这篇文章对你有帮助吗?

发表回复