HuixiangDou 是群聊场景的 LLM 知识助手。群里人多口杂，机器人显然不应该答复所有消息，它的设计规则为：

• 无关内容不吭声——拒答

• 明确该答的，直接回复——检索

• 不能违反核心价值观——可靠

在上一篇文章中，我们用真实群聊数据测试，对比不同方法和调参，最终拒答 F1 score 达到 75.88。

本文介绍如何混用知识图谱和稠密检索，把 F1 进一步提升到 77.57。

以下是目前所有方法对比：

本文使用的方法，实质是在稠密检索期间给高频词加权：

1. 简单。核心实现仅数百行，且完美兼容旧版本，Pull Request 见 https://github.com/InternLM/HuixiangDou/pull/316

2. 可靠。本文反复测试，只要参数合理，稳定会有提升
   

3. 成本可控。不做多轮 LLM 也有精度提升，本文执行 2 轮 LLM NER 来提取知识库的实体词

为兼顾不同读者的背景，本文需要介绍涉及的词汇：

• 知识图谱（Knowledge Graph）：一种结构化的知识库，它通过图的形式存储和组织实体、属性、关系及类型。

• 命名实体识别（Named Entity Recognition）：提取自然语言中有意义的实体，例如人名、昵称、时间等。

• 稠密检索（Dense Retrieval）：非结构化方法。先用模型提取文本/图像/语音等的特征，然后计算特征间的距离匹配目标。人脸识别常用此方案。

• networkx：一个用 Python 写的开源图论和复杂网络分析库。它提供了丰富的数据结构和算法来创建、操作和研究复杂的网络结构，包括无向图、有向图、多图、无权图和加权图。

• neo4j：成熟的图形数据库管理系统，使用图形来存储和查询数据。与传统的关系型数据库不同，它用节点和边来表示数据实体和它们之间的关系，而不是使用表和列。很适合保存知识图谱。

• milvus：开源向量数据库，它专门设计用于存储、搜索和分析大量的向量数据。

RAG 为什么需要 KG 。或者说，KG 会给 HuixiangDou 带来什么？

想象中 KG 应该：

1. 能提升系统的可解释性。显然稠密检索使用的高维空间无法调试

2. 能保证术语间的层级关系。例如在杂交水稻领域中，无论稠密、稀疏方法，都不能表达“野败”和“南优2”的亲本关系

3. 是无侵入的。即 KG 不会明显干扰原有服务和精度

本文使用的 KG 以属性为中心连接 chunk。

以 MMDeploy 和 MMPose 项目的 README 为例，二者的交集在 "mmpose" 和 "ncnn" 等术语上。

如果某个名词（如 “ncnn”）能关联到很多文档，说明它很重要或常见。本文假设这种高频词汇，在 RAG 中应该有更大权重。

本文使用 qwen1.5-110B 做 NER，为降低成本使用 silicon clould API，使用的知识库仍然是 OpenMMLab 相关的 9 个算法库。

建立知识库，需要 14M token，单并发 12 小时以上，费用约 50 元。

知识库建立成功后，workdir/kg 目录下有 jsonl 格式的节点和关系文件。

此时可体验检索效果，例如问怎么安装 MMPose：

HuixiangDou 中，存储知识图谱用 jsonl ，图相关计算使用 networkx。为了白嫖 neo4j 的可视化工具，我们支持把 jsonl 转到 neo4j。

是部分节点可视化的例子，看起来很像蒲公英：

• 红色是属性节点

• 蓝色是 chunk

• 橙色是文档

• 灰色是图片

检索过程和建库过程类似，先用 LLM 提取实体词，获取匹配的候选文档。

关于 score，本文事先统计所有命中个数的分布，多数问题都关联不了 100 个文档。考虑到后续还要缩放分值，因此拍脑袋直接取：

这里的阈值也是候选文档个数：例如对某条用户输入，检索到 5 个以上候选文档判为 True，机器人继续处理这句话、不拒绝。

测试结果如上图，随着阈值增高，知识图谱检索结果逐渐保守，许多正类样本被错误地分类为负类。

然而保守也是一种可靠。

保守特质适合计算正值 [0, +1] ，叠加到稠密检索结果上，让之前分布的方差更大。

本文使用的混合检索就是简单的“考试加分”，具体来说：

1. 先计算 kg_score

2. 重置 query 的阈值，即 throttle=throttle_in_config - 0.2*kg_score

3. 继续原有稠密检索过程

这下知识图谱就可以做成开关选项，和老版本特征库完美兼容！

本文基于知识图谱和稠密检索的混合方案，本质是在稠密检索中给高频词加权，能带来不到 2 个点的精度提升。

目前实现比较糙，只支持 markdown 格式和纯文本；速度方面也未做任何优化，KG-LLM 未发挥完整能力。

我们将继续完善代码，在更多领域完成测试。