0x00 简介
HuixiangDou 是群聊场景的 LLM 知识助手。群里人多口杂,机器人显然不应该答复所有消息,它的设计规则为:
无关内容不吭声——拒答
明确该答的,直接回复——检索
不能违反核心价值观——可靠
https://github.com/InternLM/HuixiangDou
(觉得好用,欢迎点亮 star)
在上一篇文章中,我们用真实群聊数据测试,对比不同方法和调参,最终拒答 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 来提取知识库的实体词
0x01 术语介绍
为兼顾不同读者的背景,本文需要介绍涉及的词汇:
知识图谱(Knowledge Graph):一种结构化的知识库,它通过图的形式存储和组织实体、属性、关系及类型。
命名实体识别(Named Entity Recognition):提取自然语言中有意义的实体,例如人名、昵称、时间等。
稠密检索(Dense Retrieval):非结构化方法。先用模型提取文本/图像/语音等的特征,然后计算特征间的距离匹配目标。人脸识别常用此方案。
networkx:一个用 Python 写的开源图论和复杂网络分析库。它提供了丰富的数据结构和算法来创建、操作和研究复杂的网络结构,包括无向图、有向图、多图、无权图和加权图。
neo4j:成熟的图形数据库管理系统,使用图形来存储和查询数据。与传统的关系型数据库不同,它用节点和边来表示数据实体和它们之间的关系,而不是使用表和列。很适合保存知识图谱。
milvus:开源向量数据库,它专门设计用于存储、搜索和分析大量的向量数据。
0x02 方案阐述
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
继续原有稠密检索过程
这下知识图谱就可以做成开关选项,和老版本特征库完美兼容!
0x04 总结
本文基于知识图谱和稠密检索的混合方案,本质是在稠密检索中给高频词加权,能带来不到 2 个点的精度提升。
目前实现比较糙,只支持 markdown
格式和纯文本;速度方面也未做任何优化,KG-LLM 未发挥完整能力。
作者将继续完善代码,在更多领域完成测试。