RAG进阶：混合稠密检索和知识图谱来提升精度

最新推荐文章于 2024-07-20 06:19:20 发布

InternLM

最新推荐文章于 2024-07-20 06:19:20 发布

阅读量376

点赞数 14

文章标签：人工智能 ai RAG 知识图谱

本文链接：https://blog.csdn.net/2402_82411485/article/details/140548681

版权

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 未发挥完整能力。

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