AI 知识图谱大比拼：DeepSeek-R1 竟然输给了 Mistral 7B？

近年来，DeepSeek 逐渐受到广泛关注。这家中国人工智能初创公司正以迅雷不及掩耳之势席卷全球。他们的 LLM Deepseek-R1 几乎已经广为人知，尽管它仅仅在几周前才发布。Deepseek-R1 的发布在业界引起了广泛关注，也引发了对现有 AI 生态的讨论。该模型也已开源，在短短的时间内，仅其最大的模型在 HuggingFace 上的下载量就超过了 100 万次！

Deepseek-R1 是一种“专家混合”（MoE, Mixture of Experts，一种集成多个模型的架构）模型，采用“强化学习”（Reinforcement Learning，一种通过奖励机制训练模型的算法）进行训练。它是一个庞大的模型，总共有 6710 亿个参数（即 671 billion 参数），但在推理过程中只有 370 亿个参数（37 billion 参数）处于活跃状态。这家初创公司声称，尽管其训练成本仅为后者的一小部分，但他们的模型性能却能与 OpenAI 的 o1 相媲美。此外，他们还通过使用 Deepseek-R1 生成的合成数据对其他一些开源 LLM（如 Llama 3.1 和 Qwen 2.5）进行微调，从而创建了另外六个模型。这些模型被称为“蒸馏”模型，指的是一个更强大的模型使用合成数据来训练一个较小的模型。与 OpenAI 的 o1 系列模型类似，Deepseek-R1 也是一个“推理”模型。与传统模型不同，它并非立即响应，而是拥有一个“思考”时间，旨在提高响应质量。

本文将聚焦于如何在资源受限的机器上部署 Deepseek-R1 蒸馏模型，并利用它来解答特定领域本地文档的相关问题，探索其在实际应用中的潜力。为了提高在特定领域的性能，我们将利用 GraphRAG 的优势（一种利用知识图谱上下文改进响应生成的方法），通过使用从这些文档构建的知识图谱中的上下文，优化响应生成，并有效降低模型的错误率。对于知识图谱的构建，我们将调用 LlamaIndex
（用于自动构建知识图谱）。图谱本身将存储在 Neo4j 上，这是一个生产级的原生图数据库。为了评估 Deepseek-R1 在此场景中的表现，我们将将其图谱构建和响应生成能力与 Mistral 7B 进行对比。

接下来，我们将详细介绍如何在资源受限的环境中部署和测试这一系统。

1.0 技术栈和环境设置

考虑到应用的目标环境是资源受限的设备，我们选择在配备 8GB 内存的 MacBook Air M1（运行 MacOS Ventura）上完成此项工作。使用的 Python 版本是 3.11.5。

首先，让我们创建一个虚拟环境来管理这个项目。要创建和激活环境，请运行以下命令：

python3.11 -m venv kg_qa
source kg_qa/bin/activate

我们系统的框架使用 LlamaIndex
，因为它能够方便地提供数据摄取、索引和查询的工具。它还包含模块 PropertyGraphIndex
，该模块能够在 LLM 的帮助下，从非结构化文本中自动生成知识图谱，同时支持基于实体的查询。

为了便于将 Neo4j 用作知识图谱的存储后端，我们将使用模块 Neo4jPropertyGraphStore
。此外，还需要 Neo4j 的 Python 驱动程序，名为 neo4j
。如果您正在寻找有关此图数据库、其设置、其 Web UI 及其查询语言 Cypher 的入门知识，请随时查看这篇较早的文章：

为了支持本地 LLM，我们将使用带有 Metal 支持的出色的 llama-cpp-python
 库。图 1 显示了 Deepseek-R1 蒸馏模型的列表，如其 HuggingFace 仓库所示，以及用于微调的基础模型。在资源受限的环境下，我们将使用 unsloth 在 HuggingFace 上提供的量化模型，特别是 Deepseek-R1 7B Q2_K 模型。

为了进行性能比较，Deepseek-R1 2-bit 模型将与 2-bit Mistral 7B Instruct v0.3 Q2_K 进行比较。

接下来，我们将简要介绍其实现细节。

2.0 系统实现

此设计基于先前工作中提出的相同方法。首先，让我们导入所有必需的模块，如下所示：

from llama_index.core import (
    PropertyGraphIndex,
    SimpleDirectoryReader,
    StorageContext,
    Settings,
)
from llama_index.llms.llama_cpp import LlamaCPP   # version 0.4.0
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
from llama_index.graph_stores.neo4j import Neo4jPropertyGraphStore

以下代码用于加载 Deepseek-R1 蒸馏模型，并设置相关参数：

llm = LlamaCPP(
    model_path='./models/DeepSeek-R1-Distill-Qwen-7B-Q2_K.gguf',
    temperature=0.6,
    max_new_tokens=2000,
    context_window=4096,
    model_kwargs={"n_gpu_layers": 1},
    verbose=False                                                                                                                                                                                              
)
embed_model = HuggingFaceEmbedding()
Settings.llm = llm
Settings.embed_model = embed_model
Settings.chunk_size = 512

与 Mistral 7B 使用的较小模型温度 0.1 不同，我们将为 DeepSeek-R1 7B 使用 0.6，这是 DeepSeek 作者推荐的。要设置由我们的 Neo4j 数据库支持的图存储，让我们使用默认凭据和数据库名称实例化一个 Neo4jPropertyGraphStore
 对象，如下所示：

url = "bolt://localhost:7687"
username = "neo4j"
password = "password"
database = "neo4j"

graph_store = Neo4jPropertyGraphStore(
    username=username,
    password=password,
    url=url,
    database=database,
)

基于此 graph_store
，我们进一步创建了 StorageContext
 实例。要加载文档，我们将使用 SimpleDirectoryReader
 从目录 ./pdf/ 读取。要从这些文档构建知识图谱，我们使用方法 PropertyGraphIndex.from_documents
。

gstorage_context = StorageContext.from_defaults(graph_store=graph_store)                                                                                                                                       
documents = SimpleDirectoryReader("./pdf/").load_data()
kg_index = PropertyGraphIndex.from_documents(
    documents,
    storage_context=gstorage_context,
    max_triplets_per_chunk=10,
    include_embeddings=True,
    property_graph_store=graph_store,
)

一旦构建了图谱，PropertyGraphIndex
 就会自动将其保存到 Neo4j 数据库。此时，图谱将可用于查询。从图索引创建一个查询引擎。使用推荐的 Deepseek-R1 提示，其中仅建议用户提示，而没有单独的系统提示，模板如下所示 <｜User｜>{query}<｜Assistant｜>
：

kg_keyword_query_engine = kg_index.as_query_engine(
    include_text=True,
    similarity_top_k=2,
)
query = 'When should simplified routing be used on SteelHeads?'
response = kg_keyword_query_engine.query(f'<｜User｜>{query}<｜Assistant｜>')

仅几行代码即可完成基本实现。

3.0 性能比较

3.1 知识图谱构建

在我们运行上述系统之前，需要首先启动 Neo4j DBMS，并且可以在 localhost 上使用。对于此实验，我们将采用两个单独的关于 SteelHead 的知识库 (KB) 文章（一种与 WAN 应用程序加速相关的技术）来代表我们的利基领域。第一个知识库讨论了一个名为“简化路由”的功能，该功能可帮助设备自动学习并将网络数据包转发到适当的下一跳。第二个知识库讨论了如何在 SteelHead 上启用 HTTP/2.0 加速功能。对于跨两个模型的此测试，使用的图谱构建提示是 LlamaIndex 默认值。

图 2 描绘了在使用 Deepseek-R1 摄取第一个知识库时生成的图谱。该图谱基本正确地反映了简化路由的知识，但'is using'关系存在错误，因为简化路由并不直接依赖于静态路由。右侧包含实体“简化路由”的图谱似乎已经很好地捕获了嵌入的知识，除了与实体“静态路由”的关系“正在使用”之外。此 SteelHead 功能并不直接依赖于静态路由的存在。

为了进行比较，图 3 显示了借助 Mistral 7B 生成的图谱。很明显，Mistral 图谱编码的细节要少得多，尽管它确实捕获了简化路由功能的高级机制。

对于第二个测试，我们首先重置 Neo4j 数据库，然后针对 KB #2 进行图谱构建，该知识库讨论了启用 HTTP/2.0 加速。图 4 描绘了 Deepseek-R1 从本文档生成的知识图谱。这里生成了很多有问题的实体和关系，例如前者的“1.2”和“2.0”，以及后者的“协议”和“Http/2.0”。这种编码奇怪地没有捕获它的知识。

相比之下，图 5 显示了使用 Mistral 7B 摄取时生成的图谱。与之前的知识库摄取类似，这些 Mistral 图谱再次比 Deepseek-R1 的简单得多。这些图谱似乎也从此第二个知识库中编码了非常有限的细节。

比较两个模型跨两个知识库构建的图谱，这里没有明显的赢家。Deepseek-R1 在摄取 KB #1 时表现出色，但在 KB #2 方面的表现不佳。Mistral 7B 为两个文档生成了相当简单的图谱，但没有捕获所涉及的细微差别。

现在让我们探索它们在两个知识库中的查询性能。

3.2 响应生成

以下是我们的第一个提示，用于衡量模型与 KB #1 相关的查询性能。

何时应在 SteelHead 上使用简化路由？

现在让我们看看 Deepseek-R1 在此查询方面的表现。以下输出捕获了其完整响应。

<think>
Okay, so I need to figure out when to use simplified routing on a SteelHead appliance. I'm not too familiar with SteelHead, but I remember it's related to networking, probably for routers or firewalls. Simplified routing, from what I recall, is a feature that simplifies the routing process for the device, making it more efficient or easier to manage.

Looking at the context provided, there are several points mentioned. First, it says that simplified routing is gathering IP addresses to their MAC addresses. That means when the device receives a packet, it maps the IP address to a MAC address to determine where the traffic should go. This is important because IP addresses are addressable at the IP level, but devices typically communicate through MAC addresses at the MAC layer.

Another point mentions that simplified routing is responsible for the destination IP and MAC address. So, when the device sends out a packet, it uses this information to route it correctly. Simplified routing is using the destination IP and MAC address to determine the next hop.

The context also talks about when it's responsible for the same address. That might be referring to when the source or destination IP is the same as the MAC address, which can happen when dealing with multi-homed networks or when a router has multiple interfaces.

The context further explains that simplified routing is using the MAC address to send out traffic, which is important because it helps the device know which interface to send the packet out and which to receive it on. This is crucial for layer-2 WANs, which are large networks that require efficient routing across multiple locations.

The context also mentions that if the default gateway doesn't have the right ACLs (Access Control Lists), it might drop traffic that should have gone through another router. So, the user has to add static routes to direct traffic through the other router. But the solution provided by simplified routing is to avoid using those static routes by using the MAC address when sending out packets.

Another important point is about the destination being a new TCP connection. Simplified routing allows the device to insert the next hop interface when sending out a packet, overriding other routing steps if there's no mapping. This is useful because in some cases, especially in complex networks, the default routing might not be sufficient, and the device can dynamically insert the correct next hop based on the MAC address.

The context also warns about when not to use simplified routing. It says that simplified routing can't be used with broadcast support, WCCP (Wide Area Connection Point, which is related to IEEE 802.1Q VLANs), or PBR (Polymorphic Packet Reordering, used in some load balancers). So, if the environment requires those features, simplified routing isn't suitable.

Lastly, the context explains that simplified routing is best for scenarios where the network is being optimized through the SteelHead. It's a simplified version of the routing process, making it easier to manage and less resource-intensive. It's not for every situation, though; it's specifically for certain network topologies and scenarios.

Putting this together, simplified routing on a SteelHead should be used when you have a network that's being optimized, specifically in scenarios where you have multiple subnets or multiple VLANs that need to be optimized. It's especially useful in layer-2 WAN deployments where the network is large and complex. It's best used when you can define one router as the default gateway and have other routes configured via static routes or additional static routes to direct traffic through other routers. This avoids the need for complicated ACLs that might be required without simplified routing.

I think that covers the main points. It's a bit complex, but I think I have a good grasp now.
</think>

Simplified routing on a SteelHead appliance should be used in the following scenarios:

1. **Network Optimization**: When optimizing a network topology, especially in environments with multiple subnets or VLANs that need optimization.

2. **Layer-2 WANs**: For large networks requiring efficient routing across multiple locations.

3. **Multiple Subnets/VLANs**: When multiple subnets or VLANs need to be optimized through the SteelHead.

4. **No Need for Complicated ACLs**: When the default gateway doesn't require complex ACLs to direct traffic through other routers.

5. **Destination IP Handling**: When dealing with destinations that are the same address, as simplified routing handles this efficiently.

6. **Dynamic Next Hop Insertion**: When the destination is a new TCP connection, as simplified routing allows the device to insert the correct next hop interface dynamically.

7. **Avoid broadcast support, WCCP, or PBR**: When the environment doesn't require these features, as simplified routing can't be used with them.

In summary, use simplified routing for optimized large networks, especially in scenarios involving multiple subnets or VLANs, without requiring complex ACLs for traffic routing. It's ideal for scenarios where dynamic next hop insertion is needed and where broadcast support, VLANs, or PBR isn't required.

推理模型的关键行为在此处完全显示。它具有 <think>
 部分，该部分捕获了模型的思维链。在这里，Deepseek-R1 清楚地承认了它对此领域的不熟悉。此外，它立即调用提供的上下文，并一次探索每个点。这种思考过程是正确的。在 <think>
 部分的末尾，模型指出：我认为我现在已经很好地掌握了
。实际的响应随后出现，但它也过于冗长。七个点中有五个是完美的。但是，该模型在第 5 点和第 6 点上出现了幻觉。

现在让我们看看 Mistral 7B 对同一提示的响应：

当流量被重定向回 SteelHead 并且用户不想为其他路由器添加静态路由时，应在 SteelHead 上使用简化路由。简化路由从它收到的每个数据包收集 IP 到下一跳 MAC 地址映射，以用于寻址它自己的流量，这会覆盖所有其他内容。这允许将优化的流量直接发送到下一跳，而无需静态路由。

此响应精确而简洁地描述了简化路由_是什么_，并建议何时应使用此功能。但是，此响应没有捕获其应用程序的细微差别，而这些细微差别存在于 Deepseek-R1 的响应中。因此，在此查询中，Mistral 7B 的响应因更简洁且未出现幻觉而更具优势。

表 1 总结了所有三个问题和响应以及两个模型关于 KB #1 的响应时间。对于所有 Deepseek-R1 的响应，都显示了没有 <think>
 部分的响应，并且必须对响应进行剪辑以限制空间。对于每个查询，最佳响应以绿色突出显示，最短响应时间（以秒为单位）以粗体显示。在一个令人惊讶的发展中，Mistral 7B 对所有三个查询都有简洁而准确的直接答案。Deepseek-R1 的响应细致入微，并详细捕获了不同的场景，但也包括产生幻觉的_事实_。Deepseek-R1 对 Q3 的响应假设 SteelHead 是一种负载平衡解决方案，而实际上它是一种应用程序加速技术。此外，Deepseek-R1 的响应比 Mistral 7B 慢 3.5 倍。甚至它的图谱构建时间也慢了 6 倍以上。

表 2 捕获了查询 KB #2 时两个模型的响应生成性能。在此测试期间，Deepseek-R1 对 Q2 和 Q3 的响应还有很多不足之处。对于 Q2，尽管它的思维链似乎合理（未显示），但 Deepseek-R1 提供了无效命令。这种性能的缺乏直接关系到此模型产生的意外知识图谱，如前面图 4 所示。此外，Deepseek-R1 的响应时间比 Mistral 7B 慢 7.7 倍。

基于这些观察和有限的测试场景，诸如 Deepseek-R1 之类的推理模型似乎在知识图谱构建方面面临一些挑战，并且针对不同内容的表现不一致。此外，它们较慢的响应不会将它们作为问答应用程序的首选模型。

4.0 结论性意见

总而言之，Deepseek-R1 在知识图谱构建和问答方面展现出了一定的潜力，但也存在一些挑战，尤其是在幻觉和响应速度方面。Mistral 7B 则以其简洁和高效性，在某些场景下更具优势。希望本文能够帮助读者更好地了解这两款模型，并在实际应用中做出更明智的选择。欢迎大家尝试复现本文的实验，并分享您的发现和见解。

感谢阅读！

学习资源