> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 基于本地LLM的图RAG提取实践
- URL: https://www.hubwiz.com/blog/hands-on-graph-rag-extraction-with-local-llms/
- Published: 2026-02-25T14:14:10.000Z
- Updated: 2026-02-25T14:14:10.000Z
- Description: 图 RAG 中隐藏的瓶颈不是检索，而是提取。
- Author: admin
- Tags: RAG, GRAPH RAG, #Import 2026-10-14 14:41

Graph RAG 已成为构建基于知识的 AI 系统的最有前景的方法之一。通过将文档构建为知识图——由类型化关系连接的实体网络——它能够理解事物如何关联的检索，而不仅仅是词语共现。

但有一个大家谈论得不够多的问题：**提取步骤**。

在查询知识图之前，你需要构建一个。这意味着获取原始文本并提取结构化的实体-关系三元组——诸如 `(Marie Curie, born_in, Warsaw)` 或 `(CRISPR-Cas9, developed_by, Jennifer Doudna)` 之类的东西。大多数图 RAG 论文假设你会用 GPT-4 来解决这个问题，然后继续前进。但如果你在构建生产系统，特别是在数据不能离开基础设施的受监管环境中，你需要本地模型。而本地模型在结构化提取方面的难度远超你的预期。

我构建了一个基准测试，以弄清楚到底有多难。

## 1、为什么图 RAG 要使用本地模型？

使用本地提取模型的理由很简单。在企业环境中——医疗、法律、金融——将文档发送到外部 API 并不总是一个可行的选项。合规要求、延迟约束和规模化成本都推动着本地提取。

问题不在于*是否*使用本地模型。而在于*使用哪些模型*，以及*如何提示它们*。

图 RAG 提取对于小模型来说是一项特别苛刻的任务。你要让一个 7-9B 参数模型同时：识别段落中的所有实体，对它们进行分类，确定它们之间的关系，将这些关系表示为结构化的三元组，并将所有内容输出为有效的 JSON。对于在单个 GPU 上运行的模型来说，这是很大的认知负荷。

## 2、实验

我专门为图 RAG 提取质量设计了一个基准测试。与通用的 NLP 基准测试不同，这个测试专注于图 RAG 管道所需的确切任务：给定一个文本段落，生成带有类型化实体的结构化 `(subject, predicate, object)` 三元组。

**数据集：** 20 个段落，跨越四个复杂度级别——简单（清晰的实体，少量关系）、中等（具有互连关系的多个实体）、复杂（具有嵌套关系的密集段落）和边缘情况（别名、缩写、空段落）。数据集涵盖传记、科学、商业、技术和地缘政治等领域，有 150 个标准实体和 139 个标准三元组。

**模型：**

```
+--------------------------+------------+----------------+
| Model                    | Parameters | Family         |
+--------------------------+------------+----------------+
| Qwen 2.5 7B Instruct     | 7B         | Qwen (Alibaba) |
| Llama 3.1 8B Instruct    | 8B         | Llama (Meta)   |
| Mistral 7B Instruct v0.3 | 7B         | Mistral        |
| Gemma 2 9B IT            | 9B         | Gemma (Google) |
+--------------------------+------------+----------------+

```

所有模型都在单个 NVIDIA RTX 3090 (24GB) 上通过 vLLM 运行，使用相同的设置：最大上下文长度 4096，启用前缀缓存，8 个并发请求。

**提示策略：**

1. **朴素** —— 一条简单指令，要求提取实体和三元组为 JSON
2. **提示词中的模式** —— 同样的指令加上输出应遵循的确切 JSON 模式
3. **少样本** —— 两个示例，显示输入文本和预期的提取输出

**评估：** 具有同义词感知谓词比较的模糊匹配。模型不应因为输出 `was_born_in` 而不是 `born_in` 而受到惩罚——这些对于知识图来说意味着相同的事情。实体匹配使用令牌排序比率，阈值为 75，谓词在回退到模糊字符串匹配之前，会经过同义词规范化层处理，该层包含约 45 个同义词组。

## 3、结果

#### 发现 1：实体识别已解决，关系提取未解决。

![None](https://www.hubwiz.com/blog/content/images/2026/02/1-i9HiyEFWqfvdqlwIowd1Fw.png)

所有四个模型都实现了 0.78 到 0.91 之间的实体 F1 分数——这是可在生产中使用的可接受性能。这些模型擅长在文本中*找到*事物。

但看看三元组 F1：

![None](https://www.hubwiz.com/blog/content/images/2026/02/1-aJHI3yewpNUCtTYwSbDG4A.png)

情况发生了戏剧性的变化。所有模型-策略组合中的最佳结果是 0.732（Llama 3.1 + 少样本），大多数配置的得分在 0.52 到 0.60 之间。实体识别和关系提取之间的差距是核心挑战：模型可以在句子中识别 `Marie Curie` 和 `Warsaw`，但可靠地将 `(Marie Curie, born_in, Warsaw)` 提取为结构化三元组要困难得多。

为什么？关系提取不仅需要理解*什么*实体存在，还需要理解它们*如何*连接。它要求语义理解和结构规范——模型需要将复合陈述分解为原子三元组，选择一致的谓词名称，并在整个过程中保持有效的 JSON。

#### 发现 2：没有最佳模型，只有权衡。

![None](https://www.hubwiz.com/blog/content/images/2026/02/1-RhAt8dZAv962U9Td7e2OAg.png)

这个散点图讲述了真实的故事。x 轴显示模式符合率（模型是否产生有效的、可解析的输出？），y 轴显示三元组 F1（当它产生输出时，有多好？）。右上角——高质量*且*高可靠性——是空的。

**Llama 3.1 8B** 在少样本提示下实现了最高的提取质量（0.732 三元组 F1），但可靠性最低——只有 20% 的少样本输出符合预期的模式。当它工作时，它很出色。80% 的时间里，它不工作。

**Mistral 7B v0.3** 恰恰相反：使用提示词中的模式时，JSON 有效性和模式符合率都是 100%，但提取质量最高只能达到 0.564 三元组 F1。它是一头稳健的工马——可预测、快速（7-14秒平均延迟，比其他模型快约 3 倍），从不崩溃。但它将准确性留在了桌子上。

**Qwen 2.5 7B** 占据了与 Mistral 类似的空间——可靠（使用朴素和模式提示时，模式符合率为 100%），提取质量中等（0.52–0.58 三元组 F1）。

**Gemma 2 9B** 提供了最佳的全面平衡。使用少样本提示时，它达到了 65% 模式符合率下的 0.653 三元组 F1。使用提示词中的模式时，它实现了 95% 可靠性和 0.571 三元组 F1。其更大的参数数量（9B 对比 7-8B）似乎有所帮助，特别是在复杂段落上。

#### 发现 3：少样本提高质量但损害可靠性

在所有四个模型中，少样本提示始终实现了最高的三元组 F1。示例有助于模型理解预期的输出结构、谓词的粒度以及复合关系的分解。

但代价是真实的。少样本提示词长 3-5 倍，这会增加延迟（Qwen 从 10.9 秒增加到 37.0 秒），而且更重要的是——降低了输出可靠性。更长的上下文似乎会让较小的模型感到困惑，导致它们产生格式错误的 JSON、冗长的解释而不是结构化输出，或部分提取。

```
+-----------------+---------------+--------------------------+------------------+
| Model           | Naive Schema% | Schema-in-Prompt Schema% | Few-Shot Schema% |
+-----------------+---------------+--------------------------+------------------+
| Qwen 2.5 7B     | 100%          | 100%                     | 80%              |
| Llama 3.1 8B    | 50%           | 95%                      | 20%              |
| Mistral 7B v0.3 | 20%           | 100%                     | 100%             |
| Gemma 2 9B      | 45%           | 95%                      | 65%              |
+-----------------+---------------+--------------------------+------------------+

```

Mistral 是一个值得注意的例外——它在保持 100% 模式符合率的同时*改善*了少样本的效果。这使它成为唯一一种少样本严格优于其他选项的模型。

#### 发现 4：复杂性对三元组的损害比对实体的损害更大

当段落变得更难——更多的实体、嵌套的关系、时间限定词——实体检测保持相对稳定，但三元组提取急剧下降。对于使用朴素策略的 Qwen，简单段落得到 0.643 三元组 F1，中等段落下降到 0.365，复杂段落下降到 0.438。模型难以将密集文本分解为原子三元组，通常产生复合对象，例如 `"Jennifer Doudna at UC Berkeley and Emmanuelle Charpentier at the Max Planck Institute"` 而不是为每个研究员及其关联创建单独的三元组。

![None](https://www.hubwiz.com/blog/content/images/2026/02/1-bk9EdjOrFLlhsDc63DwhjA.png)

这对图 RAG 具有实际意义：如果你的文档是密集的技术或法律文本，那么提取质量的下降将比简单基准测试所表明的更严重。

## 4、评估问题

构建这个基准测试揭示了一些重要的事情：**评估几乎和提取一样困难**。

我的初步结果显示三元组 F1 分数在 0.36–0.48 左右，这似乎低得惊人。但深入原始输出后发现，模型实际上在产生语义正确的提取——只是使用了不同的词汇。输出 `stands_at` 而不是 `height`，或 `is_also_known_as` 而不是 `also_known_as` 的模型不应受到惩罚。这些在知识图中意味着相同的事情。

我经历了三次评估改进迭代：

1. **谓词同义词组** —— 将约 45 组语义等效的谓词映射为相同的标准形式（例如，`born_in`、`was_born_in`、`birthplace`、`place_of_birth` 都映射到同一标准形式）
2. **辅助动词剥离** —— 在匹配之前自动删除诸如 `is_`、`was_`、`has_been_` 之类的前缀，因此 `is_part_of` 匹配 `part_of`
3. **子字符串实体匹配** —— 接受冗长的模型输出，例如 `"Jennifer Doudna at UC Berkeley"` 作为对三元组评估中标准实体 `"Jennifer Doudna"` 的匹配

这三个变化将测量的三元组 F1 提高了 15-34%，而没有改变任何模型输出。教训是：如果你在构建图 RAG 评估管道，请在匹配逻辑上投入与提取提示词相同的精力。过于严格的评估会让你的模型看起来比实际情况更差。

## 5、实用建议

基于在 4 个模型和 3 种策略上的 2000 次提取运行，以下是我对生产图 RAG 系统的建议：

**如果可靠性是你的首要任务**（例如，没有人工审核的自动化管道）：使用 **Mistral 7B v0.3 + 少样本**。这是唯一实现 100% 模式符合率同时仍能获得合理提取质量（0.564 三元组 F1）的配置。它也是最快的模型，平均每次提取 14 秒。

**如果提取质量最重要**（例如，使用人工验证构建精选知识库）：使用 **Gemma 2 9B + 少样本**。在 65% 模式符合率下达到 0.653 三元组 F1，你需要处理失败，但成功的提取在意义上明显更好。9B 参数数量使它在复杂段落上具有优势。

**如果你两者都需要并且能够承受重试**：使用 **Llama 3.1 8B + 少样本，并带有回退策略**。首先尝试少样本（当它工作时为 0.732 三元组 F1），如果输出未通过模式验证，则使用提示词中的模式重试（95% 符合率）。这可以让你以在失败时约 2 倍延迟的代价获得两全其美。

**对于所有模型**：提示词中的模式是一个安全的默认选项。它在每个测试的模型上提供最佳的可靠性-质量比率。

## 6、这对图 RAG 意味着什么

结构化提取差距——高实体识别但平庸的关系提取——是本地图 RAG 的真正瓶颈。要缩小这一差距，可能需要更好的提示（也许是思维链提取，模型在输出 JSON 之前推理关系）、受限解码（在令牌级别强制有效的 JSON 输出）的组合，以及在提取任务上的专门微调。

好消息是这些模型已经是有用的。0.55–0.65 的三元组 F1 意味着本地模型产生的知识图三元组中有一半以上是正确且有依据的。结合人工审核或基于置信度的过滤，这足以为不将数据发送到外部 API 而构建生产知识图。

完整的基准测试代码、数据集和结果可在 GitHub 上获取。在你自己的硬件上运行它，添加你自己的模型，并帮助社区了解什么对本地图 RAG 提取有效。

*在单个 NVIDIA RTX 3090 上使用 vLLM v0.7.3 和前缀缓存进行了基准测试。所有模型都是开放权重，可在 HuggingFace 上获取。*

---

原文链接：[Local LLMs for Graph RAG Extraction: What Actually Works](https://medium.com/graph-praxis/local-llms-for-graph-rag-extraction-what-actually-works-388233dd9eda?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处