HuixiangDou 是群聊场景的 LLM 知识助手。群里人多口杂，机器人显然不应该答复所有消息，它的设计规则为：
无关内容不吭声——拒答
明确该答的，直接回复——检索
不能违反核心价值观——可靠
https://github.com/InternLM/HuixiangDou
在上一篇文章中，我们用真实群聊数据测试，对比不同方法和调参，最终拒答 F1 score 达到 75.88。
本文介绍如何混用知识图谱和稠密检索，把 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. 术语介绍
为兼顾不同读者的背景，本文需要介绍涉及的词汇：
知识图谱（Knowledge Graph）：一种结构化的知识库，它通过图的形式存储和组织实体、属性、关系及类型。
命名实体识别（Named Entity Recognition）：提取自然语言中有意义的实体，例如人名、昵称、时间等。
稠密检索（Dense Retrieval）：非结构化方法。先用模型提取文本/图像/语音等的特征，然后计算特征间的距离匹配目标。人脸识别常用此方案。
networkx：一个用 Python 写的开源图论和复杂网络分析库。它提供了丰富的数据结构和算法来创建、操作和研究复杂的网络结构，包括无向图、有向图、多图、无权图和加权图。
neo4j：成熟的图形数据库管理系统，使用图形来存储和查询数据。与传统的关系型数据库不同，它用节点和边来表示数据实体和它们之间的关系，而不是使用表和列。很适合保存知识图谱。
milvus：开源向量数据库，它专门设计用于存储、搜索和分析大量的向量数据。
2. 方案阐述
RAG 为什么需要 KG 。或者说，KG 会给 HuixiangDou 带来什么？
想象中 KG 应该：
能提升系统的可解释性。显然稠密检索使用的高维空间无法调试
能保证术语间的层级关系。例如在杂交水稻领域中，无论稠密、稀疏方法，都不能表达“野败”和“南优2”的亲本关系
是无侵入的。即 KG 不会明显干扰原有服务和精度
本文使用的 KG 以属性为中心连接 chunk。
以 MMDeploy 和 MMPose 项目的 README 为例，二者的交集在 "mmpose" 和 "ncnn" 等术语上。
如果某个名词（如 “ncnn”）能关联到很多文档，说明它很重要或常见。本文假设这种高频词汇，在 RAG 中应该有更大权重。
2.1 建立知识库
本文使用 qwen1.5-110B 做 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 可视化
HuixiangDou 中，存储知识图谱用 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
这样在实现层面，就可以变相改阈值，而不用动稠密检索代码。即：
先计算 kg_score
重置 query 的阈值，即 throttle=throttle_in_config - 0.2*kg_score
继续原有稠密检索过程
这下知识图谱就可以做成开关选项，和老版本特征库完美兼容！
3. 总结
本文基于知识图谱和稠密检索的混合方案，本质是在稠密检索中给高频词加权，能带来不到 2 个点的精度提升。
目前实现比较糙，只支持 markdown 格式和纯文本；速度方面也未做任何优化，KG-LLM 未发挥完整能力。
我们将继续完善代码，在更多领域完成测试。
