Agentic-GraphRAG应用开发实战
Agentic-GraphRAG应用开发实战
垂直领域 Agentic-GraphRAG 开发实战
本节公开课,我们将带大家深入理解垂直领域智能问答系统的核心技术,从 RAG 痛点分析到 GraphRAG 解决方案,再到 Agentic-GraphRAG 的完整实现路径。通过理论讲解与实战演练相结合的方式,帮助大家掌握构建企业级智能问答系统的核心技能。
一、垂直领域 RAG 痛点与 GraphRAG 落地产品
RAG,Retrieval-Augmented Generation,也被称作检索增强生成技术,最早在 Facebook AI(Meta AI)在 2020 年发表的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》( https://arxiv.org/abs/2005.11401 )中正式提出,这种方法的核心思想是借助一些文本检索策略,让大模型每次问答前都带入相关文本,以此来改善大模型回答时的准确性。这项技术刚发布时并未引发太大关注,而伴随2022年大模型技术大爆发,RAG技术才逐渐进入人们视野,并且由于早期大模型技术应用均已“知识库问答”为主,而RAG技术是最易上手、并且上限极高的技术,因此很快就成为了大模型技术人必备的技术之一。

Naive RAG最简单的RAG技术实现流程:需要围绕给定的文档(往往是非常长的文档)先进行切分,然后将切分的文档转化为计算机能识别的形式,也就是将其转化为一个数值型向量(也被称为词向量),然后当用户询问问题的时候,我们再将用户的问题转化为词向量,并和段落文档的词向量进行相似度匹配,借此找出和当前用户问题最相关的原始文档片段,然后将用户的问题和匹配的到的原文片段都带入大模型,进行最终的问答。由此便可实现一次完整的文档检索增强执行流程。

Naive RAG存在两个主要不足:其一,它难以捕捉跨文档的碎片化信息关联。当答案涉及多个文档的知识点时,纯粹基于语义相似度的检索往往无法将零散信息串联起来,导致答案不够全面。其二,随着数据规模增长,朴素 RAG 的性能和检索质量容易下降,可能出现无关内容干扰答案的情况。这在行业中被称为"上下文中毒",即检索到的片段中混入了不相关的信息,导致模型生成的答案看似有道理却牛头不对马嘴。以上痛点在医疗、法律等垂直领域尤为突出——这些领域的问题往往要求结合多个证据点,多跳推理才能得出正确结论。
设想一个医疗研究员提出一个复杂问题,需要从多份医学报告中提取关联信息才能回答。如果仅靠传统搜索或单轮问答,很可能出现答案片面或遗漏关键细节的情况。在垂直领域(如医疗、金融),企业内部有大量专有知识,但直接让大模型了解这些专业资料往往困难重重。这就引出了检索增强生成(Retrieval-Augmented Generation,简称 RAG)技术的应用:通过检索外部知识来增强大模型的回答。然而很多团队发现,在垂直场景中直接采用朴素 RAG存在明显痛点,需要我们寻找更有效的改进方案。

针对上述挑战,GraphRAG 应运而生。GraphRAG 是将知识图谱引入 RAG 检索的一种新型技术路线,即 Graph + RAG。它通过从文本中提取实体及其关系,构建成图谱形式,以图结构来增强检索和推理能力。简单来说,GraphRAG 不再把文档视作孤立的句子向量集合,而是将其中蕴含的人物、事件、概念等实体"节点"挖掘出来,并根据关联构建"边",形成一个语义网络。用户提问时,GraphRAG 可以识别问题涉及的实体并沿图谱关系寻找相关联的知识。这种方式能帮助模型获取更广阔而有结构的上下文视图,把分散在不同文件里的相关信息串联起来,特别适合需要多跳推理的复杂问答场景。
从通俗的角度来理解一下GraphRAG 和 传统RAG 的区别。如下图所示:

-
GraphRAG 的运行机制
我们深入来看 GraphRAG 的运作机制。在索引阶段,GraphRAG 会对原始文档进行文本分析和图谱构建:利用大型模型或特定算法抽取出文中的实体(如人名、术语、数值等)及它们之间的关系(例如因果关系、组织结构、时间顺序等)。这些实体被作为图谱中的节点,关系作为边,可能还会附带权重或类型信息。接下来对大量节点进行语义聚类,将紧密相关的一组节点归入同一个"社区",形成层次化的簇。这一过程可以看作对知识图谱的分块,方便后续快速锁定相关区域。
到了查询阶段,用户问题首先会通过自然语言处理识别其中的关键词或实体,然后 GraphRAG 算法会匹配图谱中相应的社区或子图。系统提取该子图的相关信息,通常包括社区内若干节点及它们的连接路径,并对这些内容进行局部摘要提炼。为了确保答案既准确又不遗漏全局背景,GraphRAG 常常采用分层汇总:先生成各相关社区的局部答案,再将它们合成为全局答案。微软研究提出的 GraphRAG 方案中,就结合了本地与全局两级摘要,并给每个答案片段打分筛选,最后通过多阶段递归(Map-Reduce)生成最终解答。这种图谱增强的流程显著提升了复杂查询时的表现:实验表明 GraphRAG 对复杂问答的准确性和响应质量相比传统 RAG 有大幅提升,某些场景下答案综合性能提升可达3倍以上。

GraphRAG 整个Indexing过程可以通过以下简单的方式来理解:
- 类似于 Baseline RAG,将源文档分块为较小的子文档;
- 执行两个并行提取:实体提取用于识别人名、地名、组织名等实体,关系提取:查找不同数据块中实体之间的关系,比如朋友、同事,员工等;
- 创建知识图谱,其中节点表示实体,边表示它们之间的关系,比如张三是李四的朋友, 张三是王五的同事;
- 通过识别密切相关的实体来构建社区;
- 生成不同社区级别的分层摘要;
- 使用 reduce-map 方法通过逐步组合块来创建摘要,直到实现整体概览;
需要说明的是:GraphRAG 是一种技术范式,其目的是将知识图谱与大语言模型结合起来,以增强信息检索和生成能力。在这一技术范式下,衍生出非常多的开源项目、框架或工具会去实现这一流程。比较受欢迎的工具和项目主要如下:
热门GraphRAG项目
| 项目名称 | 描述 | GitHub链接 | 论文链接 |
|---|---|---|---|
| Microsoft GraphRAG | 一个能够将知识图谱和 RAG 结合起来的数据工作流和转换工具,可以提供数据处理,检索问答能力 | GitHub | 论文 |
| LightRAG | 一个轻量级的RAG框架,支持图增强文本索引、增量更新算法等,比 Microsoft GraphRAG 更适合个人使用,成本相对较低 | GitHub | 论文 |
| Fast-GraphRAG | 更低延迟的GraphRAG实现,动态数据生成和增量更新等,成本约为Microsoft GraphRAG的1/6 | GitHub | - |
| RAGFlow | 基于深度文档理解构建的开源 RAG(Retrieval-Augmented Generation)引擎 | GitHub | - |
| kotaemon | 集成 GraphRAG 及混合检索等方法的具备本地知识库问答的项目 | GitHub | - |
GraphRAG 的优势固然突出,但我们也要看到其实现成本和局限性。
-
成本非常高
由于要构建和维护知识图谱,GraphRAG 在计算开销上远高于朴素 RAG:需要额外的LLM调用来抽取实体关系,并执行多轮查询和摘要,处理长文本时费用惊人(有报告称处理一本3.2万字的书用 GPT-4 构建图谱约耗费$6-$7 美元)。
-
运行时间过长
此外,GraphRAG 当前的流程偏离线批处理:如果我们添加新的知识文件,往往需要重新构建或更新整张知识图谱,无法像向量库那样即时增量更新。检索速度方面,由于涉及图数据库查询和复杂过滤,也会比直接向量近邻搜索更慢。
-
中间过程不可控
在学习成本上,GraphRAG 方案涉及 NLP 信息抽取、图数据库、检索算法等多方面知识,开发和调优难度较高。这些因素使得直接落地 GraphRAG 对很多企业来说门槛较高。为此,业界也在探索改进方案,例如 2024 年香港大学发布了LightRAG 项目,专注于通过轻量化的图谱简化提升效率。LightRAG 依然提取实体和关系但采用键值结构存储,增加去冗余合并节点的步骤,使知识图谱更紧凑。在检索阶段引入双层检索机制:既关注实体邻域精细答案,又考虑全局关系获取主题背景。得益于这些优化,LightRAG 号称将 GraphRAG 所需的 API 调用次数减少了约90%,整体 Token 开销缩减为 GraphRAG 的六千分之一!更重要的是,LightRAG 支持图谱的增量更新。从评测看,在大多数任务上LightRAG 的回答质量可媲美甚至略优于GraphRAG。总的来说,GraphRAG 和 LightRAG 的出现,表明通过知识图谱增强RAG是提升垂直领域问答质量的有效路径,但实现时需要权衡性能与成本。
二、Agentic-GraphRAG 技术方案
考虑到GraphRAG方案的复杂性,我们在垂直领域应用中可以采用更务实的实现方式。一个思路是借助大语言模型的Agent能力,结合知识图谱思路,实现Agentic-GraphRAG的效果。这也是本课程的核心内容:不是手动构建庞大的图数据库和复杂检索算法,而是利用 LangChain 等框架中现有组件,把知识检索、关系推理融合在智能 Agent 的决策过程中。

如上所示的技术架构就是本节课程我们会给大家详细讲解的技术实现思路。先通过OCR和信息抽取把文档转成结构化知识,然后把这些知识作为查询工具接入Agent。在问答时,Agent会自主选择是查询向量语义库还是查询构建的知识图谱,甚至调用计算工具,对结果进行验证。这种方案下,Agent相当于一个灵活的指挥官,可以根据问题难度自动规划多步检索。例如,对于简单直问,Agent直接语义检索获取答案;但若问题涉及推理整合,Agent 会先提取相关实体,再多步挖掘它们之间的关联,最后综合得到答案。我们将在后续章节通过实际代码演示如何组装这样的 Agent 管理流程。在进入技术细节前,请牢记:无论实现方式如何,RAG 思想始终是大模型应用的基石。即使是在 Agent 场景下,可靠的检索仍然是回答准确性的保障。因此理清 RAG 的原理和增强方法(如 GraphRAG)对我们开发任何垂直智能问答系统都至关重要。
从工程角度看,要实现Agentic-GraphRAG,我们需要解决几项关键技术:
其一,定义Agent可用的工具集,其中必然包括我们自建的垂直领域知识库检索接口(例如基于向量数据库或图数据库的查询函数)。
其二,设计Agent的Prompt模板,指导大模型何时该用哪个工具、如何解析工具返回结果。这通常采用ReAct(先思考再行动)或Plan-and-Execute等提示策略,使模型先输出思考步骤,再逐步调用动作。LangChain 1.1 提供了全新的 create_agent 接口,能够让开发者以更简洁的方式注册自定义工具并生成Agent,大大降低实现难度。我们可以在 Prompt 中列出如"SearchKnowledge"和"QueryGraph"等命令,模型就会在回答时尝试这些操作。本课程稍后会通过代码演示如何使用 LangChain 1.1 和 LangGraph 来打造这样一个能自主推理的 Agent。
其三,Agent得到最终答案后,我们还需关注来源溯源(Source Grounding):确保回答中的每个关键事实都有据可查。这可以通过让Agent在输出答案时附上引用链接或文本片段来实现,也是验证Agent决策正确性的关键一环。总而言之,Agentic-GraphRAG 技术的优势在于融合了GraphRAG的深度检索与Agent的自主规划,使系统既"聪明"又"勤奋"。这为复杂业务场景下的大模型应用提供了一种可行方案,能够更有效地处理那些需要多步思考、多数据源整合的问题。
三、非结构化数据清洗:OCR 与 LangExtract 技术方案拆解
在一个医疗问答系统中,如果我们想让AI回答复杂的临床问题,就必须让它读懂海量的病历、检测报告;在一个金融分析应用里,AI需要消化各种财报、法规文件。然而,这些珍贵的信息往往以非结构化形式存在:扫描版PDF、图像表格、手写签字等等,直接输入给大模型显然不现实。如果我们不加处理就把这些内容喂给RAG系统,效果可想而知——OCR识别错误、文本杂乱无章,模型无法抓住重点。这一切凸显了数据清洗的重要性:只有将非结构化数据转化为结构化、可检索的知识,我们的Agentic-GraphRAG系统才能有效运转。
接下来,我们就需要首先从OCR识别和信息抽取两方面,拆解如何构建一个工业级的垂直领域文本清洗流水线。
3.1 OCR 数据解析
OCR(Optical Character Recognition,光学字符识别)技术用于将图像中的文字转化为数字文本,是非结构化数据清洗的第一步。如果把扫描文件比作埋在矿石中的金子,OCR 就是一台挖掘机,先将文字信息"挖掘"出来。但传统OCR往往只能产出"纯文本",大量格式、表格结构和语义信息在这一过程中丢失。幸运的是,近年来出现了针对长文档和复杂版面的OCR新方案,例如 DeepSeek-OCR 等多模态模型。这些新OCR模型引入了视觉大模型,将整页图像编码为紧凑的视觉Token,再由轻量级的解码器输出文字。相比传统逐字识别,这种方法对版面理解更好、可以在更小模型上处理超长文档。简单来说,新一代OCR能更高效地将复杂版面压缩成可供大模型直接利用的文本语料。

现代文档不仅仅是文本。它们包含多列布局、数学公式、半扫描表格、多语言文本以及分辨率奇数的图表。像 GPT-4o 或 Qwen-VL 这样的端到端模型可以解析它们,但它们速度慢、布局混乱,并且耗费 GPU 内存。所以企业环境下往往会选择更小、更紧凑的视觉模型来为解析工作提供支持。主流的企业级OCR项目应用如下:
-
MinerU:点击进入
MinerU 是由 OpenDataLab(上海人工智能实验室下属团队)发起的一个开源工具,目标是将 PDF(含扫描件、复杂版式、多栏、多表格、多公式)转换为可机读的结构化格式(如 Markdown、JSON)以便进一步下游使用。项目的定位更偏「文档内容抽取/结构化」而不仅仅是传统 OCR。其取向是“将 PDF → Markdown/JSON”这一流程,而不仅“图片 → 文字”。

MinerU的主要工作流程分为以下几个阶段:
-
输入:接收
PDF格式文本,可以是简单的纯文本,也可以是包含双列文本、公式、表格或图等多模态PDF文件; -
文档预处理(Document Preprocessing):检查语言、页面大小、文件是否被扫描以及加密状态;
-
内容解析(Content Parsing):
- 局分析:区分文本、表格和图像。
- 公式检测和识别:识别公式类型(内联、显示或忽略)并将其转换为
LaTeX格式。 - 表格识别:以
HTML/LaTeX格式输出表格。 - OCR:对扫描的
PDF执行文本识别。
-
内容后处理(Content Post-processing):修复文档解析后可能出现的问题。比如解决文本、图像、表格和公式块之间的重叠,并根据人类阅读模式重新排序内容,确保最终输出遵循自然的阅读顺序。
-
格式转换(Format Conversion):以
Markdown或JSON格式生成输出。 -
输出(Output):高质量、结构良好的解析文档。
如下是MinerU项目官方给出的配置参考:


而VLM-Sglang后端则是利用sglang高性能推理引擎,优化了GPU加速及分布式部署的基础上同时支持实时流式输出,其流程如下:

MinerU 项目非常适用于:
-
需要从大量 PDF 文档中抽取结构化内容(例如学术文献、技术白皮书、报告)用于知识库或训练语料。
-
对版式结构(如章节、列表、表格、公式)要求较高,而不只是 OCR 文本识别。
-
希望输出 Markdown/JSON 供后续自动化流水线使用。
-
PaddleOCR:点击进入
PaddleOCR 是由 Baidu (及其生态) 基于其深度学习框架 PaddlePaddle 提供的开源 OCR 工具箱。支持从 PDF 或图像文档转为结构化数据(适配 AI 场景),支持 100+ 语言。最新版本 3.0 在其技术报告中提出:PP-OCRv5、PP-StructureV3、PP-ChatOCRv4 三大解决方案,覆盖文字识别、多版式文档解析、关键 信息提取。

在早期版本(如 PP-OCRv3)中,其结构可概括为:“检测 (Detection) → 分类 (Classification of orientation) → 识别 (Recognition)”。使用多种模型,例如检测模型(DBNet 等)、识别模型(如 SVTR),在 3.0 版本中,其“PP-StructureV3”整合了布局分析、表格识别、结构抽取。同时还最新推出了还推出了PaddleOCR-VL 的 Vision-Language 模型版本(0.9B 参数的 VLM),用于多语种文档解析。
PaddleOCR-VL 是推出的一个专注于“文档解析/视觉-语言模型 (Vision-Language Model, VLM)”功能的新模块,采用了视觉-语言模型架构以应对更高阶的需求。在解析多模态数据方面,PaddleOCR将这项工作分为两部分:
- 首先检测并排序布局元素。
- 使用紧凑的视觉语言模型精确识别每个元素。
该系统分为两个明确的阶段运行。
第一阶段是执行布局分析(PP-DocLayoutV2),此部分标识文本块、表格、公式和图表。它使用:
-
RT-DETR 用于物体检测(基本上是边界框 + 类标签)。
-
指针网络 (6 个转换器层)可确定元素的读取顺序 ,从上到下、从左到右等。
最终输出统一模式的图片标注数据,如下图所示:

第二阶段则是元素识别(PaddleOCR-VL-0.9B),这就是视觉语言模型发挥作用的地方。它使用:
-
NaViT 风格编码器 (来自 Keye-VL),可处理动态图像分辨率。无平铺,无拉伸。
-
一个简单的 2 层 MLP, 用于将视觉特征与语言空间对齐。
-
ERNIE-4.5–0.3B 作为语言模型,该模型规模虽小但速度很快,并且采用 3D-RoPE 进行位置编码
最终模型输出结构化 Markdown 或 JSON 格式的文件用于后续的处理。

这个小小的设计决策, 将布局和识别分离,使得 PaddleOCR-VL 比通常的一体化系统更快、更稳定。同时根据实际的测试,其运行和解析速度也更快。在 A100 GPU 上, 吞吐量为 1.22 页/秒,。比 MinerU2.5 快 15.8%, VRAM 比 dots.ocr 少约 40%。
-
DeepSeek-OCR:点击进入
DeepSeek 于 2025年10月21日发布了 DeepSeek-OCR 模型,仅需7G的显存,就能完成高精度的表格、公式识别,图片语义识别,并且在多项评测指标中一举拿下SOTA成绩。其 Github 相较于其他项目相对比较"简陋",仅仅提供了
Transformers和vLLM启动DeepSeek-OCR的服务示例代码文件:

-
dots.ocr:点击进入
dots.ocr 是由 rednote‑hilab(HiLab团队)开源的多语种文档布局解析工具。官方介绍中强调:“一个统一的 Vision-Language 模型(≈1.7 B 参数)即可完成布局检测 + 内容识别 +阅读顺序排序”。支持文本、表格、公式、以及多语言输入。

dots.ocr 的特点是用一个 VLM(1.7 B 参数)来统一布局解析+内容识别,而不是传统将检测、识别、结构分开。用户可通过不同 prompt 来切换任务(如“请输出版式元素的 bbox、类别、文本”)→ 即说明模型采用 prompt + VLM 的方式。

非常适合需要快速处理多语种、混版式文档,且希望用一个统一模型/prompt 来搞定。虽然表现不错,但对于极复杂的表格(如跨页表、合并单元格)或特殊版式效果并不是很理想。
关于主流的MinerU、PaddleOCR-VL、DeepSeek-OCR等解析方案,均有本地部署版本,链接: https://pan.baidu.com/s/1k_4w-NB2f8dUJMdh4lVXzg?pwd=e2i6 提取码: e2i6
更多爆款体系课程信息,欢迎扫描下方二维码,助教老师会为你详细解答:


当然,无论OCR技术多先进,输出的文本仍然是非结构化的:段落杂糅、缺少标注。这就需要下一步的信息抽取来赋予其结构。
3.2 LangExtract信息抽取
信息抽取(Information Extraction)是将非结构化文本转化为结构化数据的过程。在传统NLP中,这通常包括命名实体识别(NER)、关系抽取(RE)、事件抽取等任务。然而,以往这些任务需要训练复杂模型、编写规则,对于垂直领域还面临着大量人工标注成本。
假设你是一家大型医院的数据分析师,每天医生会产生数千份病历记录。这些记录都是自由文本形式:
"患者张某,男,45岁,主诉胸痛3天。既往有高血压病史10年,目前服用缬沙坦80mg每日一次。体格检查:血压150/95mmHg..."
现在医院想要统计所有患者的用药情况、剂量分布、疾病共病模式,怎么做?
-
人工标注? 数千份病历,至少需要数周时间,且容易疲劳出错
-
正则表达式? 药物名称、剂量的表述千变万化,"每日一次"、"qd"、"1次/天"都是同一个意思
-
训练专用模型? 需要大量标注数据、算力资源,还要针对不同科室分别训练
这就是非结构化文本处理的核心痛点——信息价值高,但提取成本更高。
传统信息提取方法对比
| 方法类型 | 优点 | 局限性 | 适用场景 |
|---|---|---|---|
| 正则表达式/规则 | 精准、可控 | 规则复杂、维护困难、泛化能力差 | 格式固定的简单文本 |
| 传统NER模型 | 自动学习模式 | 需要大量标注数据、跨领域迁移差 | 有训练数据的特定领域 |
| 通用NLP工具 | 开箱即用 | 准确率低、无法定制 | 通用场景的粗粒度提取 |
| 人工标注 | 最准确 | 成本高、速度慢、无法规模化 | 小规模高价值数据 |
当然,除了 Microsoft GraphRAG 等项目,还有更轻量的工具推荐使用 - LangExtract。

LangExtract 是 Google 开源的一个 Python 库,它的核心使命可以用一句话概括:利用大型语言模型,将非结构化文本转换为结构化数据,并确保每个提取结果都精确对应回原文位置。
-
能力一:零代码定义提取任务(Prompt-Driven)
在传统方法中,提取药物信息可能需要编写数百行正则表达式或训练一个NER模型。而在
LangExtract中,只需用自然语言描述任务:
# 示例:定义提取任务的 Prompt
extraction_prompt = """
从临床笔记中提取以下信息:
1. 药物名称(medication)
2. 剂量(dosage)
3. 给药频率(frequency)
4. 持续时间(duration)
请确保提取的内容与原文完全一致。
"""
# 这就是全部!无需编写任何解析逻辑
-
能力二:少样本学习(Few-Shot Learning)
仅有 prompt 还不够,
LangExtract支持提供少量示例来"教会"模型输出的具体格式:
import langextract as lx
# 定义一个示例:告诉模型"什么样的输入应该产生什么样的输出"
example = lx.data.ExampleData(
text="患者目前服用缬沙坦80mg每日一次,已持续3个月。",
extractions=[
lx.data.Extraction(
text="缬沙坦",
class_name="medication"
),
lx.data.Extraction(
text="80mg",
class_name="dosage"
),
lx.data.Extraction(
text="每日一次",
class_name="frequency"
),
lx.data.Extraction(
text="3个月",
class_name="duration"
)
]
)
# 提供1-3个这样的示例,模型就能学会输出格式!
-
能力三:精确的来源定位(Source Grounding)
这是
LangExtract最突出的特性之一。每个提取结果都会自动标注其在原文中的字符偏移位置。

这主要可以用于审查场景,例如:
-
医疗审计:监管部门需要核查AI提取的诊断结论是否真的出现在病历中
-
法律合规:合规审查时必须能追溯每条规定来自合同的哪一页哪一行
-
知识管理:构建企业知识库时,需要链接回原始文档以供查证
-
能力四:结构化输出保证(Schema Enforcement)
直接使用大模型的最大的痛点之一是输出格式不可控。同一个任务,模型可能这次返回 JSON,下次返回表格,再下次又变成了自然语言描述。
LangExtract通过两种机制保证输出的结构化:1. 基于示例的格式约束
通过 Few-Shot 示例,模型会学习并模仿示例的结构。这在所有模型上都有效。
2. 受控生成(Controlled Generation)
对于支持的模型(如
Google Gemini),LangExtract会利用模型原生的 schema 约束功能,强制要求输出必须符合预定义的 JSON Schema。在实际应用中,可以批量处理成千上万份文档,无需担心某一份的输出格式突然出错导致整个流程崩溃。 -
能力五:长文档多轮提取(Multi-Pass Extraction)
大模型都有上下文长度限制。即使是支持 100K tokens 的模型,面对一份 500 页的法律合同也会捉襟见肘。更重要的是,长文档中的信息密度高,单次扫描很容易遗漏细节。
LangExtract采用了智能的处理策略:1. 自动分块(Automatic Chunking)
-
将长文档切分为适合模型处理的小块
-
保留块与块之间的上下文重叠,避免信息断层
-
并行处理多个分块,提高速度
2. 多轮提取(Multi-Pass)
-
第一轮:全面扫描,提取明显的信息
-
第二轮:针对第一轮可能遗漏的内容,调整 prompt 再次扫描
-
第三轮及以后:可以针对特定类型的信息进行深度挖掘
这种策略在合规审查、法律分析等不允许遗漏任何细节的场景中至关重要。
四、【实战】Prompt Engineering 对比 LangExtract
上面我们已经了解了 LangExtract 的基本原理和核心能力。但在实际项目中,可能大部分同学都会有疑问:"我直接用提示词让大模型提取不就行了吗?为什么还要用 LangExtract?"所以,我们就先通过一个真实的新闻信息提取场景,先运行纯提示词方式,看到它的提取结果,再运行 LangExtract 方式,看到它的提取结果,最后进行深度对比分析(重复实体、完整性、原文对齐能力)。
首先需要安装langextract库:
%pip install langextract
Looking in indexes: https://pypi.tuna.tsinghua.edu.cn/simple
Requirement already satisfied: langextract in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (1.1.1)
Requirement already satisfied: absl-py>=1.0.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (2.3.1)
Requirement already satisfied: aiohttp>=3.8.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (3.13.2)
Requirement already satisfied: async_timeout>=4.0.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (5.0.1)
Requirement already satisfied: exceptiongroup>=1.1.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (1.3.1)
Requirement already satisfied: google-genai>=1.39.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (1.56.0)
Requirement already satisfied: google-cloud-storage>=2.14.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (3.7.0)
Requirement already satisfied: ml-collections>=0.1.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (1.1.0)
Requirement already satisfied: more-itertools>=8.0.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (10.8.0)
Requirement already satisfied: numpy>=1.20.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (2.4.0)
Requirement already satisfied: pandas>=1.3.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (2.3.3)
Requirement already satisfied: pydantic>=1.8.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (2.12.5)
Requirement already satisfied: python-dotenv>=0.19.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (1.2.1)
Requirement already satisfied: PyYAML>=6.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (6.0.3)
Requirement already satisfied: regex>=2023.0.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (2025.11.3)
Requirement already satisfied: requests>=2.25.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (2.32.5)
Requirement already satisfied: tqdm>=4.64.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (4.67.1)
Requirement already satisfied: typing-extensions>=4.0.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from langextract) (4.15.0)
Requirement already satisfied: aiohappyeyeballs>=2.5.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from aiohttp>=3.8.0->langextract) (2.6.1)
Requirement already satisfied: aiosignal>=1.4.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from aiohttp>=3.8.0->langextract) (1.4.0)
Requirement already satisfied: attrs>=17.3.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from aiohttp>=3.8.0->langextract) (25.4.0)
Requirement already satisfied: frozenlist>=1.1.1 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from aiohttp>=3.8.0->langextract) (1.8.0)
Requirement already satisfied: multidict<7.0,>=4.5 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from aiohttp>=3.8.0->langextract) (6.7.0)
Requirement already satisfied: propcache>=0.2.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from aiohttp>=3.8.0->langextract) (0.4.1)
Requirement already satisfied: yarl<2.0,>=1.17.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from aiohttp>=3.8.0->langextract) (1.22.0)
Requirement already satisfied: idna>=2.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from yarl<2.0,>=1.17.0->aiohttp>=3.8.0->langextract) (3.11)
Requirement already satisfied: google-auth<3.0.0,>=2.26.1 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-cloud-storage>=2.14.0->langextract) (2.45.0)
Requirement already satisfied: google-api-core<3.0.0,>=2.27.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-cloud-storage>=2.14.0->langextract) (2.28.1)
Requirement already satisfied: google-cloud-core<3.0.0,>=2.4.2 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-cloud-storage>=2.14.0->langextract) (2.5.0)
Requirement already satisfied: google-resumable-media<3.0.0,>=2.7.2 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-cloud-storage>=2.14.0->langextract) (2.8.0)
Requirement already satisfied: google-crc32c<2.0.0,>=1.1.3 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-cloud-storage>=2.14.0->langextract) (1.8.0)
Requirement already satisfied: googleapis-common-protos<2.0.0,>=1.56.2 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-api-core<3.0.0,>=2.27.0->google-cloud-storage>=2.14.0->langextract) (1.72.0)
Requirement already satisfied: protobuf!=3.20.0,!=3.20.1,!=4.21.0,!=4.21.1,!=4.21.2,!=4.21.3,!=4.21.4,!=4.21.5,<7.0.0,>=3.19.5 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-api-core<3.0.0,>=2.27.0->google-cloud-storage>=2.14.0->langextract) (6.33.2)
Requirement already satisfied: proto-plus<2.0.0,>=1.22.3 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-api-core<3.0.0,>=2.27.0->google-cloud-storage>=2.14.0->langextract) (1.27.0)
Requirement already satisfied: cachetools<7.0,>=2.0.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-auth<3.0.0,>=2.26.1->google-cloud-storage>=2.14.0->langextract) (6.2.4)
Requirement already satisfied: pyasn1-modules>=0.2.1 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-auth<3.0.0,>=2.26.1->google-cloud-storage>=2.14.0->langextract) (0.4.2)
Requirement already satisfied: rsa<5,>=3.1.4 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-auth<3.0.0,>=2.26.1->google-cloud-storage>=2.14.0->langextract) (4.9.1)
Requirement already satisfied: charset_normalizer<4,>=2 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from requests>=2.25.0->langextract) (3.4.4)
Requirement already satisfied: urllib3<3,>=1.21.1 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from requests>=2.25.0->langextract) (2.6.2)
Requirement already satisfied: certifi>=2017.4.17 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from requests>=2.25.0->langextract) (2025.11.12)
Requirement already satisfied: pyasn1>=0.1.3 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from rsa<5,>=3.1.4->google-auth<3.0.0,>=2.26.1->google-cloud-storage>=2.14.0->langextract) (0.6.1)
Requirement already satisfied: anyio<5.0.0,>=4.8.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-genai>=1.39.0->langextract) (4.12.0)
Requirement already satisfied: httpx<1.0.0,>=0.28.1 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-genai>=1.39.0->langextract) (0.28.1)
Requirement already satisfied: tenacity<9.2.0,>=8.2.3 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-genai>=1.39.0->langextract) (9.1.2)
Requirement already satisfied: websockets<15.1.0,>=13.0.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-genai>=1.39.0->langextract) (15.0.1)
Requirement already satisfied: distro<2,>=1.7.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-genai>=1.39.0->langextract) (1.9.0)
Requirement already satisfied: sniffio in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from google-genai>=1.39.0->langextract) (1.3.1)
Requirement already satisfied: httpcore==1.* in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from httpx<1.0.0,>=0.28.1->google-genai>=1.39.0->langextract) (1.0.9)
Requirement already satisfied: h11>=0.16 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from httpcore==1.*->httpx<1.0.0,>=0.28.1->google-genai>=1.39.0->langextract) (0.16.0)
Requirement already satisfied: annotated-types>=0.6.0 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from pydantic>=1.8.0->langextract) (0.7.0)
Requirement already satisfied: pydantic-core==2.41.5 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from pydantic>=1.8.0->langextract) (2.41.5)
Requirement already satisfied: typing-inspection>=0.4.2 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from pydantic>=1.8.0->langextract) (0.4.2)
Requirement already satisfied: python-dateutil>=2.8.2 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from pandas>=1.3.0->langextract) (2.9.0.post0)
Requirement already satisfied: pytz>=2020.1 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from pandas>=1.3.0->langextract) (2025.2)
Requirement already satisfied: tzdata>=2022.7 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from pandas>=1.3.0->langextract) (2025.3)
Requirement already satisfied: six>=1.5 in /root/anaconda3/envs/langextractAgent/lib/python3.12/site-packages (from python-dateutil>=2.8.2->pandas>=1.3.0->langextract) (1.17.0)