善用知识图谱，问答助手只“解惑”，不“闲聊”

作为聊天工具，机器人越来越多地被应用于群聊中。但是群聊场景中往往存在信息繁杂、消息泛滥等情况。聊天机器人如何应对？

作为一款基于大语言模型的知识问答AI助手，茴香豆（HuixiangDou）可被部署在社交软件群聊中，避免无效的“闲聊”，更高效地帮助用户答疑解惑。开源以来，得益于准确检索、低成本部署等优势，茴香豆受到开发者广泛好评，它的设计规则为：

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

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

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

为了实现拒答，机器人要计算用户输入和知识库的关联度，这需要模型拥有检索能力。

一般地，文本检索方法分以下类型：

• 稠密检索（dense retrieval）：把文本映射到高维空间中，捕捉文本的深层语义

• 多向量检索（multi-vector retrieval）：把文本表示成多个向量，每个向量表达文本的不同方面

• 稀疏检索（sparse retreival）：依赖文本的关键词和索引，表达成稀疏向量。结果简单且高效

茴香豆之前仅使用稠密检索方法（text2vec）实现拒答。并且基于真实业务数据对比了不同方法和参数的结果，最终 F1 score 达到 75.88（text2vec 如何选择 chunksize 和 splitter）。

https://github.com/InternLM/HuixiangDou

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

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

方法	F1 score	备注
BCE+KG混合（本文）	77.57	KG 权重约 20%
BCE	75.88	需配合特定 splitter
BGE	72.23	使用 bge-large-zh-v1.5
BGE-M3	70.62	测试数据 token 不足 8192，无法评估能力
M3 稠密+稀疏混合	63.85	使用 milvus hybrid_search 测试，WeightedRanker 中稀疏占比越大效果越差

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

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

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

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

1. 术语介绍

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

• RAG（Retrieval-Augmented Generation）：检索增强生成技术，通过引用外部知识库的信息来生成答案或内容。

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

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

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

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

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

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

2. 方案阐述

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

想象中 KG 应该：

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

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

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

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

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

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

2.1 建立知识库

本文使用开源千亿参数模型做 NER，为降低成本使用 silicon clould API，使用的知识库仍然是 OpenMMLab 相关的 9 个算法库。

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

python3 -m huixiangdou.service.kg --build

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

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

python3 -m huixiangdou.service.kg --query 如何安装mmpose?

考虑到 API 欠费、网络断开等因素，期间会记录已完成的文件，支持断点续建。

2.2 可视化

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

python3 -m huixiangdou.service.kg --dump-neo4j --neo4j-uri ${URI} --neo4j-user ${USER} --neo4j-passwd ${PWD}
# 30 万节点和关系数据，远程通信预计耗时 4 小时

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

• 红色是属性节点

• 蓝色是 chunk

• 橙色是文档

• 灰色是图片

2.3 直接检索测试

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

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

score = min(100, count(docs)) / 100

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

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

2.4 混合检索测试

然而保守也是一种可靠。

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

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

final_score = dense_score + 0.2 * kg_score

 这样在实现层面，就可以变相改阈值，而不用动稠密检索代码。即：

1. 先计算 kg_score

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

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

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

3. 总结

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

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

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