从PDF到智能问答：我用多模态GraphRAG搭建知识库问答系统，效果惊艳！

本文介绍了如何搭建一个完整的多模态知识库问答系统，解决传统RAG在文档解析和检索质量上的痛点。通过MinerU解析文档、LangExtract抽取信息、构建Neo4j知识图谱和Milvus向量索引，结合LangChain Agent实现多跳推理，最终通过FastAPI和React呈现结果。该系统支持多格式文档解析、知识图谱构建、向量检索和混合问答，前端注重交互体验，后端保证可扩展性与可观测性，数据层同时支撑语义检索与关系推理。

在做知识库问答被以下问题卡了很久。

文档解析：扫描 PDF、表格、图文混排都容易出错，OCR 后的数据依然不稳定。

检索质量：复杂对比问题经常召回偏题内容，关键信息缺失，回答自然不可靠。

我意识到，传统 RAG 更像“语义匹配”，缺少“关系理解”。所以我搭了这套多模态 GraphRAG：MinerU 负责解析，知识图谱建关系，Agentic-RAG 做多跳推理。

需求是什么？

• 一个完整的多模态知识库问答系统。
• 支持多格式文档解析、知识图谱构建、向量检索、混合问答。

多模态 GraphRAG 系统演示截图，见文章末尾。

系统设计的核心目标是：

• 前端保证交互体验
• 后端保证可扩展与可观测
• 数据层同时支撑语义检索与关系推理。

下面进入具体架构。

架构设计

系统架构

数据输入（PDF、CSV、Docx 等多格式）

索引构建（MinerU/OCR 解析 → LangExtract 抽取 → Chunk 切分 + KG 建图 → VectorStore 与 Neo4j 双存）

问答（Agent 并行查向量与图，检索片段与问题拼成 Prompt，大模型生成回答）。

数据流：多源文档 → MinerU解析 → LangExtract抽取 → Neo4j/Milvus/MinIO存储 → 混合检索 → LangChain Agent → FastAPI → React。

控制流：Claude Code 贯穿编排 · Figma Make驱动前端 · Celery调度异步 · Redis缓存加速 · 可观测性全链路覆盖。

要点：双索引（语义向量 + 图结构）与 RAG 拼接，兼顾多模态解析与 Graph RAG。

分层架构

多模态 GraphRAG 系统架构图从下至上分为五层：

各层技术栈及功能如下：

• 数据管道层（最底层）— 多源数据入口，支持 PDF、HTML、Doc、Image 等多格式；MinerU 负责文档解析与 OCR 处理；LangExtract 进行实体、关系、事件、属性抽取，最终将数据写入存储层
• 存储层— Neo4j 构建知识图谱，支持路径推理；Milvus / pgvector 提供向量索引与语义召回能力；MinIO / S3 用于文件分片管理；Redis 用于缓存与会话管理
• 编排层— LangChain Agent 实现工具调用与推理链路编排，采用 ReAct 策略；混合检索引擎融合 Keyword、Vector、Graph 三种检索方式；Celery + Redis 负责任务调度、异步队列与失败重试
• 服务层— FastAPI 提供路由与中间件支持，遵循 OpenAPI Spec 规范；Auth & 鉴权基于 Token 实现 RBAC 权限控制；核心功能包括上传、解析、抽取、检索、问答 API
• 前端层（最顶层）— Figma Make 用于原型生成与交互基线定义；React SPA 负责页面渲染与状态管理；支持 Mock → 真实 API 过渡

端到端数据流向

多模态 GraphRAG 的端到端数据流向，从原始文档输入到最终前端展示的完整链路。

经历以下步骤：

① 多源文档输入

来源：支持 PDF、Word、图片、网页等多种格式的文档，作为系统的数据入口。

② MinerU 多模态解析

功能：对输入的文档进行深度解析。

细节：包括版面分析（Layout Analysis）、表格识别、公式识别以及图片提取。

③ LangExtract 智能提取

功能：从解析后的内容中提取关键信息。

细节：识别实体（Entity）、关系（Relation）、属性（Attribute），并将数据结构化。

④ 图谱 + 向量双路存储

数据在此处分为两路并行存储，构建混合索引。

左路（结构化语义）存入 Neo4j 知识图谱，重点在于实体、关系以及图遍历能力。

右路（语义向量）存入 Milvus 向量库，重点在于嵌入（Embedding）和近似最近邻（ANN）搜索。

⑤ LangChain 混合检索 + QA

结合了"图谱遍历"与"向量召回"，最后进行重排（Rerank），生成高质量的问答结果。

⑥ FastAPI 服务输出

处理路由、鉴权、中间件逻辑以及异步任务处理，将处理好的数据封装为 API 接口。

⑦ React 前端渲染

利用组件化代码进行最终的页面渲染。

为什么这样设计：先画图，再填坑

搭系统之前，我做了个初稿：文档进来 → OCR 解析 → 向量检索 → LLM 回答。跟市面上大多数 RAG 系统没区别。

后来踩了坑才明白：这套架构解决不了问答质量问题——向量检索本质上还是"找最像的文本片段"，不懂实体，不懂关系。

所以我重新设计了架构，加入了知识图谱这一层：

文档输入 → MinerU 多模态解析 → LangExtract 实体抽取 → Neo4j（图数据库）+ Milvus（向量库）双存储 → LangChain Agent 混合检索 → FastAPI → React 前端

三层存储的设计思路：

一开始想过只搭 Neo4j，后来发现实体抽取的文本片段也需要做语义检索，单靠图数据库不够用。加了 Milvus 之后问答召回质量明显提升。

编排层用 LangChain Agent：最开始手写过一轮检索逻辑，后来切到 LangChain 是因为工具调用链太长——查实体、查邻居、查路径、合并结果，手写容易出 bug，换工具调试成本太高。LangChain 的 ReAct 策略天然适合这种多工具协作的场景。

为什么不直接用现成框架？LangChain/LangGraph 搭过，效果一般，主要卡在文档解析和图谱构建这两个环节没有现成方案，必须自己接 MinerU 和 LangExtract。与其绕远路，不如直接从底层接。

与传统 RAG 区别？

有朋友问：这套方案跟普通 RAG 相比，核心区别在哪？

直观对比：

最典型的例子是这个问题：

❝

“这份技术方案里，A 公司的产品相比 B 公司有什么优势？”

传统 RAG 召回的可能是两个产品各自的描述片段，LLM 硬比出一段话，不一定准确。

但 GraphRAG 的做法是：先找到 A 公司产品实体 → 找它的性能指标节点 → 再找 B 公司产品的对应指标 → 做节点级别的比较，回答有据可查。

这也是为什么我在实体抽取阶段要把关系类型抽准确——图谱里如果关系是"性能优于"还是"价格低于"，直接决定回答方向。

核心实现：从 PDF 到智能问答的完整 pipeline

整个系统分为三个串联的模块，数据依次流经：

PDF 文件 ↓MinerU 云端解析 → content_list.json ↓text_assembler 格式转换 → 每页纯文本 .txt ↓LangExtract + DeepSeek 实体抽取 → 实体 + 共现边 ↓kg_builder 图谱构建 → KGNode + KGEdge（Neo4j / NetworkX） ↓LangChain ReAct Agent 多跳问答 → 最终回答

1. 文档解析：MinerU 打通多模态

解析是整个链路的第一个瓶颈。之前试过 pdfminer、PyMuPDF，扫描件和表格都是硬伤。后来换成 MinerU，云端 API 调用，版面分析 + 表格识别 + OCR 一套带走，解析质量直接上一个台阶。(MinerU 也支持私有化部署)

MinerU 的解析结果不能直拼喂给 LLM，还需要一步 text_assembler 做格式转换。

MinerU 云端 API 解析完成后，会生成content_list.json，描述文档每一页的每一个 block：

{ "content_list": [ { "page_number": 0, "blocks": [ { "type": "title", "content": "GraphRAG: Graph-based Retrieval Augmented Generation" }, { "type": "text", "content": "Large language models excel at natural language tasks..." }, { "type": "table", "content": "| Method | R@10 | MRR@10 |\n| -- | -- | -- |", "rows": 3, "cols": 3 }, { "type": "image", "content": "", "bbox": [0.1, 0.2, 0.5, 0.6] } ] } ]}

type区分 title / text / table / image 四类 block，text_assembler 据此做内容过滤和格式还原，最终输出每页一个.txt文件，供下游 LangExtract 使用：

def assemble_from_content_list(content_list_path: str, output_dir: str) -> list[str]: with open(content_list_path, "r", encoding="utf-8") as f: data = json.load(f) output_files = [] for page in data["content_list"]: page_text = "" for block in page["blocks"]: if block["type"] == "text": page_text += block["content"].strip() + "\n\n" elif block["type"] == "table": # 表格转扁平文本，保留行列结构 page_text += flatten_table(block) + "\n\n" elif block["type"] == "title": # 标题加特殊标记，便于下游识别文档结构 page_text += f"[TITLE] {block['content']} [/TITLE]\n\n" output_path = os.path.join(output_dir, f"page_{page['page_number']:04d}.txt") with open(output_path, "w", encoding="utf-8") as out: out.write(page_text.strip()) output_files.append(output_path) return output_files

两个关键参数：

language指定文档主语言（默认zh），影响 OCR 准确率；

model选v2支持更多格式。实测中文文档解析速度约 3-5 秒/页，OCR 识别率在 95% 以上。

MinerU 支持的原始输入文件格式:

• 支持格式清单

• 输入限制

• OCR 语言支持

MinerU 内置 OCR 引擎支持109 种语言，可通过language参数指定文档主语言（默认zh中文）。

常用语言代码：

2. 实体抽取：LangExtract + DeepSeek

LangExtract 是一个面向 LLM 的结构化信息抽取框架：你给它原文和抽取 schema，它返回可直接落库的结构化结果（实体、关系、属性）。

这里不用纯 prompt + 正则，是因为格式漂移后正则很容易失效；schema 化输出在稳定性和可落库性上更可靠。

text_assembler 输出的每页纯文本，再送进 LangExtract + DeepSeekdeepseek-v3-flash做实体抽取，逐步转换成知识图谱。

实体类型体系是踩过坑才定下来的。

最开始只分了人名/机构名/地名三类，技术文档一跑就傻眼了——“GraphRAG”、“Transformer” 这样的词全被归进地名，明显不对。后来扩到五类：

加了之后图谱密度从 0.3 升到 1.8，问答召回也好多了。

Prompt 设计也是反复调出来的。

第一个版本只说"抽取实体"，输出格式乱七八糟——同一个词在相邻两段里被标注成不同类型。后来加了 few-shot examples 才好：

Example:Input: "GraphRAG uses knowledge graphs to enhance retrieval."Output: [{"text":"GraphRAG","type":"TECHNOLOGY"},{"text":"knowledge graphs","type":"CONCEPT"}]Example:Input: "Retrieval-augmented generation combines retrieval with generation."Output: [{"text":"Retrieval-augmented generation","type":"CONCEPT"}]

关系边的生成策略也换过一次。

最初想让 LLM 输出一对一对的关系，但不稳定——LLM 要么漏掉关系，要么自己编不存在的关系。

后来换了个思路：只抽实体，不抽关系，同一页出现的任意两个实体自动生成一条CO_OCCURS_IN（共现）边。

这是一个简化策略，但足够实用——共现本身就隐含语义关联，下游图检索可以通过共现边发现相关实体。

extract_prompt = """从以下文本中抽取实体和关系，输出 JSON 格式：文本：{chunk_text}要求：- 实体包含：名称、类型（TECHNOLOGY/CONCEPT/PERSON/ORGANIZATION/LOCATION）、置信度- 关系包含：源实体、目标实体、关系类型、证据文本- 只抽取高置信度内容，低置信度忽略"""response = deepseek.chat.completions.create( model="deepseek-v4-flash", messages=[{"role": "user", "content": extract_prompt}])

3. Agentic-RAG 问答：LangChain Agent 做多跳推理

这是最复杂的一块。问答不是「问一句答一句」那么简单，实际问题是多跳的——比如"这个方案为什么比竞品好"，需要：

① 先找到方案实体 → ② 找它的技术指标 → ③ 再找竞品对应指标 → ④ 做比较。

LangChain Agent 在这里做检索编排，ReAct 策略让 Agent 自己决定下一步该用什么工具：

# 核心工具集tools = [ search_entities, # 按名称搜索实体，返回匹配节点及其类型、页面信息 get_neighbors, # 获取节点的邻居节点，hops 参数控制扩展度数 get_entities_by_type, # 按类型筛选所有实体（TECHNOLOGY/CONCEPT/PERSON/ORGANIZATION/LOCATION） describe_graph, # 获取图谱概览：节点数、边数、类型分布]agent = create_react_agent(llm, tools)result = agent.invoke({"question": question})

以问题“GraphRAG 和传统 RAG 的核心区别是什么？”为例，Agent 的推理过程：

Step 1: search_entities("GraphRAG") → [GraphRAG: TECHNOLOGY, page=0, degree=39]Step 2: get_neighbors("graphrag-node-id", hops=2) → [knowledge graphs: CONCEPT, retrieval-augmented generation: CONCEPT, Neo4j: TECHNOLOGY, Milvus: TECHNOLOGY]Step 3: get_entities_by_type("CONCEPT") → [retrieval-augmented generation, knowledge graphs, ...]Step 4: describe_graph() → "Graph has 142 nodes, 780 edges, types: TECHNOLOGY(40), CONCEPT(68), ..."综合以上信息，Agent 推理生成回答。

每轮问答平均调用 4-6 次工具，实测延迟 8-15 秒（取决于图谱规模和模型响应速度）。

回答质量比纯向量 RAG 高很多，尤其在需要关系推理的问题上。

效果：跑起来什么样

系统跑起来之后，我用deepseek-v4.pdf（58 页）做了完整测试：

索引阶段：

• 文档解析：约 4 分钟（58 页，含表格和图片）
• 实体抽取：约 8 分钟（2256 个节点，132096 条边）
• 图谱规模：TECHNOLOGY 269 个、CONCEPT 969 个、PERSON 940 个……

问答阶段：

• 简单问题（直接召回）：3-5 秒
• 复杂多跳问题：10-20 秒
• 工具调用次数：平均 4-6 次/问答

效果最明显的是这类问题：

❝

“列出文档里所有涉及 DeepSeek V4 的方案介绍，并说明它们之间的关系”

之前用传统 RAG 搜出来的是零散段落，现在 GraphRAG 直接给你一张关系网络图，实体类型、关联路径一目了然。

系统展示

首页

文档管理

上传文档后进入索引流程，Dashboard 右下角会实时显示索引进度（parsing → extracting → indexing），等待完成即可。

知识图谱

索引完成后，进入知识图谱页面，可以看到文档中抽取的实体以力导向图形式展示，点击节点可查看详情和邻居关系。

智能问答

在智能问答页面输入问题，系统会调用 LangChain Agent 做多跳推理，返回回答、工具调用链路和引用的实体节点。

搜索

支持按实体名称或类型搜索，快速定位文档中的关键信息。

实战步骤：10 步搭完整系统

这套系统从零到一落地，全过程在 Claude Code 中完成。以下是每一步的核心产出和目标：

Step 1 · 确定知识图谱框架

选定 LangExtract 作为实体抽取后端，克隆源码并详细分析其输入输出规范，生成langextract_specification.md，明确 LangExtract 与文本模型、多模态模型、向量库/图数据库的交互方式。

Step 2 · 确定解析模块

选定 MinerU 作为文档解析引擎，详细阅读官方 API 文档确认支持的输入格式和输出规范，生成mineru_specification.md，明确 MVP 测试所需配置和 API Token 获取方式。

Step 3 · 建立 MinerU MVP 测试流程

在mineru_mvp/下创建独立测试项目，使用uv做环境隔离，编写本地文件上传 → MinerU 云端解析 → 解析结果本地存储的完整 Pipeline，验证端到端可用性。

Step 4 · 构建 LangExtract MVP 流程

在langextract_src/下创建独立测试项目，同样使用uv隔离环境，接入 DeepSeek API（deepseek-v4-flash），验证从模拟文本输入到结构化信息输出的完整链路，生成langextract_specification-v1.0.md。

Step 5 · MinerU 与 LangExtract 对接— 将 MinerU 的解析输出（content_list.json）接入 LangExtract 的文本输入，打通"本地 PDF → MinerU 解析 → LangExtract 抽取 → 知识图谱结构化数据"的完整 Bridge Pipeline，生成bridge_pipeline_specification-v1.0.md。

Step 6 · 前端可视化

基于 Bridge Pipeline 的输出数据规范，设计并实现一个可交互的 Web 单页面，支持上传 PDF、自动解析、查看抽取的实体数据，以及知识图谱的 D3.js 力导向图展示。

Step 7 · 构建 Agentic-RAG 问答流程

接入 LangChain MCP 获取最新版本规范，基于 Bridge Pipeline 的数据格式构建 LangChain Agent，接入 LangChain 的 ReAct 策略和 4 个工具（search_entities、get_neighbors、get_entities_by_type、describe_graph），完成"提问 → 多跳推理 → 生成回答"的完整 MVP，生成agentic_rag_specification-v1.0.md。

Step 8 · 设计后端架构与产品原型

通过 Plan 模式基于已生成的规范文档设计 FastAPI 后端架构（25 个 API 端点），同时规划 React 前端产品原型（5 个页面），生成backend_service_specification-v1.0.md和frontend_design_specification-v1.0.md，最终输出标准 PRD 文档。

Step 9 · 开始构建项目

搭建项目规范（CLAUDE.md），将前后端代码分别放入frontend/和backend/目录，.env文件管理所有外部配置并加入.gitignore，后端使用uv创建独立虚拟环境，基于规范文档生成完整的后端服务代码并完成接口测试。

Step 10 · 前后端集成和联调

编写各层 CLAUDE.md 说明启动命令，将前端所有 Mock API 替换为真实后端接口，逐个进行集成测试；如遇接口未开发情形，不自主扩展后端，仅在前端页面打上"未开发"标识。

❝

完整的 Claude Code 提示词和源码，有需要的可以私信我获取。

技术选型

开发与辅助工具：Claude Code + Cursor，模型：Minimax-M2.7

核心架构：

• 前端：React（Figma Make）
• 后端：FastAPI + LangChain
• 解析：MinerU + LangExtract
• 存储：Neo4j + Milvus

最后

对于正在迷茫择业、想转行提升，或是刚入门的程序员、编程小白来说，有一个问题几乎人人都在问：未来10年，什么领域的职业发展潜力最大？

答案只有一个：人工智能（尤其是大模型方向）

当下，人工智能行业正处于爆发式增长期，其中大模型相关岗位更是供不应求，薪资待遇直接拉满——字节跳动作为AI领域的头部玩家，给硕士毕业的优质AI人才（含大模型相关方向）开出的月基础工资高达5万—6万元；即便是非“人才计划”的普通应聘者，月基础工资也能稳定在4万元左右。

再看阿里、腾讯两大互联网大厂，非“人才计划”的AI相关岗位应聘者，月基础工资也约有3万元，远超其他行业同资历岗位的薪资水平，对于程序员、小白来说，无疑是绝佳的转型和提升赛道。

如果你还不知道从何开始，我自己整理一套全网最全最细的大模型零基础教程，我也是一路自学走过来的，很清楚小白前期学习的痛楚，你要是没有方向还没有好的资源，根本学不到东西！

下面是我整理的大模型学习资源，希望能帮到你。

👇👇扫码免费领取全部内容👇👇

最后

1、大模型学习路线

2、从0到进阶大模型学习视频教程

从入门到进阶这里都有，跟着老师学习事半功倍。

3、 入门必看大模型学习书籍&文档.pdf（书面上的技术书籍确实太多了，这些是我精选出来的，还有很多不在图里）

4、AI大模型最新行业报告

2026最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

5、面试试题/经验

【大厂 AI 岗位面经分享（107 道）】

【AI 大模型面试真题（102 道）】

【LLMs 面试真题（97 道）】

6、大模型项目实战&配套源码

适用人群

四阶段学习规划（共90天，可落地执行）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型

• 带你了解全球大模型

• 使用国产大模型服务

• 搭建 OpenAI 代理

• 热身：基于阿里云 PAI 部署 Stable Diffusion

• 在本地计算机运行大模型

• 大模型的私有化部署

• 基于 vLLM 部署大模型

• 案例：如何优雅地在阿里云私有部署开源大模型

• 部署一套开源 LLM 项目

• 内容安全

• 互联网信息服务算法备案

• …

  👇👇扫码免费领取全部内容👇👇

3、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】