NexusRAG：融合知识图谱的多模态混合检索增强生成系统

想象一个场景：你在公司知识库中上传了一份 200 页的 PDF 财报，里面密密麻麻的表格、图表、公式让普通检索系统完全无法理解其结构。而当你向系统提问"对比 2023 和 2024 年毛利率变化趋势"时，系统不仅能精准定位到对应数字，还能告诉你这个数字来自哪一页、属于哪个章节——这就是 NexusRAG 要解决的问题。

背景：从「文本匹配」到「语义理解」的跨越

传统 RAG（检索增强生成）系统的痛点由来已久。常见流程是：把文档切成固定大小的块（chunk）→ 用同一个 embedding 模型向量化 → 存入向量数据库 → 用户提问时检索最相似的若干块 → 拼入 prompt 让 LLM 生成。

这套方案有三个致命缺陷：

1. 结构丢失：PDF 里的表格被切碎、标题层级消失、公式变成乱码。 2. 单模态盲区：图片、图表完全被忽略，"看图说话"类的问答直接失效。 3. 关系断层：文档中"A 公司是 B 公司的子公司"这样的实体关系，在纯向量检索中无法被捕捉。

NexusRAG 正是针对这三个问题给出了系统性的工程解法。它由越南开发者 LeDat98 构建，定位为面向企业知识库的 production-ready 混合 RAG 系统，支持 Gemini（Google）和 Ollama（本地）双模式运行，目前在 GitHub 已有 321 颗星、65 个 fork，16 个技术标签覆盖从向量检索到知识图谱的完整 AI 栈。

核心技术：三层检索管道

NexusRAG 的检索管道分为三个并行阶段，最终通过交叉编码器（Cross-Encoder）重新排序后交给 LLM 生成：

第一层：语义分块（Hybrid Chunking）

NexusRAG 不使用简单的固定窗口切分，而是借助 Docling（默认）或 Marker 两种文档解析器，实现结构感知的混合分块。两种解析器共享同一个输出合约（ParsedDocument），下游处理逻辑无需改动，可以随时切换配置：

• Docling（默认）：基于 heading 层级、段落边界、表格结构进行语义分块，能保留 LaTeX 公式（但已知存在部分渲染问题），需要约 18-20GB VRAM（GPU 加速）。
• Marker：基于 Surya OCR，LaTeX 公式质量更高，GPU 显存需求仅 2-4GB，支持格式更广（PDF、DOCX、PPTX、XLSX、HTML、EPUB），适合显存受限的环境。 两种解析器都会为每个 chunk 注入元数据：页码、所属 heading 路径、图片/表格引用关系。这为后续的"页码感知引用"提供了基础设施。

第二层：双 embedding 向量检索

检索层采用双 embedding 策略，用两个不同的模型分别处理不同维度的语义：

• BAAI/bge-m3：1024 维多语言双向编码器（支持 100+ 语言），负责常规文本 chunk 的向量检索。ChromaDB 作为向量数据库，余弦相似度检索，过fetch top-20 候选。
• KG Embedding：由 LLM（Gemini 3072d / Ollama / sentence-transformers）生成的独立 embedding，专门编码知识图谱中的实体和关系向量，与 ChromaDB 并行检索。 双 embedding 的设计动机是：文本块和图谱实体在各自最适合的向量空间中表达语义，避免用同一个模型既要理解术语又要理解实体关系的"表达能力打架"问题。

第三层：LightRAG 知识图谱

NexusRAG 内置了 LightRAG 组件，负责从文档中提取实体（Entity）和关系（Relationship），构建知识图谱。检索时，用户的自然语言查询会通过关键词匹配（keyword extraction）找到对应的图谱节点，实现多跳推理：

• 节点 = 文档中的实体（公司名、产品名、技术术语等）
• 边 = 实体间的关系（"子公司"、"竞争对手"、"收购"等）
• 多跳遍历 = 从一个实体出发，沿着边探索相关实体，扩展上下文 这使得 NexusRAG 能够回答类似"A 公司和它的竞争对手在 X 领域的毛利率对比"这类需要跨段落推理的复杂问题——传统向量检索只能找到字面相似的片段，而图谱遍历可以沿着语义关系链条逐步扩展。

重新排序（Reranking）

三个检索通路（向量 + 图谱实体 + over-fetch）各自返回候选集后，通过 BAAI/bge-reranker-v2-m3 交叉编码器进行联合评分。Cross-Encoder 与 Bi-Encoder 的核心区别是：它将 (query, chunk) 配对一起编码，能捕捉查询和文档之间的细粒度交互信号。最终按 rerank 分数排序，选取 top 结果送入 LLM 生成。

多模态理解：图片和表格的语义检索

NexusRAG 对多模态的处理分为两步： 视觉 captioning：文档中的图片和表格通过视觉 LLM 生成描述（caption），caption 结果再次做 embedding 后存入 ChromaDB。这意味着用户可以用文字搜索"图片内容"——例如问"哪页有柱状图"时，系统能定位到包含该图表的图片块。 Markdown 表格提取：表格内容以 Markdown 格式结构化存储，保留了行列结构信息，便于 LLM 理解表格语义，而非将表格文本"拍平"成无结构字符串。 这套多模态方案使 NexusRAG 在处理财报、技术文档、学术论文等富媒体内容时，比纯文本 RAG 系统有明显优势。

流式生成与引用标注

回答生成阶段支持 agentic streaming（流式输出），用户可以边看回答边等待，不必等待完整生成再一次性显示。 每个生成的回答块会自动标注来源引用，格式为 4 位字符 ID，附带有页码和 heading 路径。用户点击引用 ID，即可跳转到原文档的对应位置，实现"答案可溯源"。这个设计对于企业合规和知识审计场景尤为重要——任何 AI 生成的内容都必须能追溯到原始文档。

架构与工程实现

NexusRAG 采用前后端分离的微服务架构，通过 Docker Compose 一键部署：

后端 Dockerfile 采用三阶段多阶段构建：

1. deps 阶段：安装 Python 依赖（gcc、libpq、OpenCV 底层库 libgl1、libglib2.0-0）
2. models 阶段：预下载 ML 模型（约 2.5GB，作为 Docker 层缓存）
3. runtime 阶段：最终运行镜像，包含模型权重和业务代码 这种设计的精妙之处在于：模型权重作为 Docker 镜像层被缓存，即使重新构建服务，只要 requirements 不变，模型下载步骤就被跳过，大幅缩短 CI/CD 周期。

部署体验：GPU 需求与选型

NexusRAG 完整部署需要 GPU，但具体规格取决于选择的文档解析模式：

• Docling 模式（默认）：需要 18-20GB VRAM（如 RTX 3090/4090、A100 40GB），优势是 LaTeX 公式支持更好。
• Marker 模式：仅需 2-4GB VRAM（RTX 3060 12GB 足够），适合没有大显存显卡的用户。切换方式：在 .env 中设置 NEXUSRAG_DOCUMENT_PARSER=marker。 Docker Compose 编排了 5 个服务（postgres、chromadb、backend、frontend、mcp-server），启动后前端默认暴露在 http://localhost:5174，健康检查机制完善，后端启动依赖 postgres 就绪后才开始接收请求。

局限性与使用门槛

尽管 NexusRAG 架构设计出色，但仍有几个不可回避的现实问题： GPU 依赖：没有 NVIDIA 显卡的用户无法使用默认的 Docling 模式。虽然 Marker 模式对显存需求较低，但完整功能体验仍需 GPU 加持。 Ollama 模型自行部署：如果选择本地 Ollama 模式，用户需要自行下载和管理 LLM 模型（如 Llama 3、Qwen 等），这部分没有自动化脚本，需要手动处理。 中文语料优化有限：bge-m3 虽然支持中文，但针对中文 PDF 的段落切分策略在嵌套标题较多的场景（如政府文件、学术论文）上可能不稳定，需要根据实际数据调优。 超大规模扩展性：当前架构中 ChromaDB 和 PostgreSQL 都是单实例部署，对于超大规模文档库（>10 万份文档）的水平扩展支持有限，暂无分布式向量检索方案。

行业意义

NexusRAG 代表了 RAG 系统从"能用"到"好用"演进的一个重要方向——多模态融合 + 知识图谱 + 可追溯引用。这三个特性恰好对应了企业 RAG 落地的三个核心诉求：处理复杂文档、推理实体关系、满足合规可审计。 GitHub 上的 16 个 topics 从 citation（引用）到 knowledge-graph（知识图谱）、从 reranking（重排）到 docling（文档解析），完整覆盖了现代 RAG 管线的每个关键环节。对于想构建企业知识库或研究 RAG 进阶技术的开发者来说，这是一个非常完整的学习参考项目。