LLM应用实战：当KBQA集成LLM(二)

1. 背景

又两周过去了，本qiang~依然奋斗在上周提到的项目KBQA集成LLM，感兴趣的可通过传送门查阅先前的文章《LLM应用实战：当KBQA集成LLM》。

本次又有什么更新呢？主要是针对上次提到的缺点进行优化改进。主要包含如下方面：

1. 数据落库

上次文章提到，KBQA服务会将图谱的概念、属性、实体、属性值全部加载到内存，所有的查询均在内存中进行，随之而来的问题就是如果图谱的体量很大呢，那内存不爆了么…

2. 支持基于属性值查实体

上篇文章不支持属性值查找实体，比如”最会照顾宝宝的是什么龙”，”什么龙是大龙和大龙生活，小龙和小龙生活”。本次已经此问题优化。

此篇文章是对这两周工作的一个整体总结，其中包含部分工程层面的优化。

2. 整体框架

整体框架和上篇大致相同，不同之处在于：

1. 对齐模块：先前是基于SIM筛选候选实体，本次基于ES进行候选实体召回

2. 解析模块：先前是基于hugegraph和内存中的实体信息进行解析，本次优化为基于hugegraph和elasticsearch

3. 核心功能

3.1 数据库选型

由于需要支撑语义相似度检索，因此数据库选型为Milvus与Elasticsearch。

二者之间的比对如下：

		Milvus	Elastic
扩展性层面	存储和计算分离	✅	❌
	查询和插入分类	组件级别支持	服务器层面支持
	多副本	✅	✅
	动态分段 vs 静态分片	动态分段	静态分片
	云原生	✅	✅
	十亿级规模向量支持	✅	❌
功能性层面	权限控制	✅	✅
	磁盘索引支撑	✅	❌
	混合搜索	✅	✅
	分区/命名空间/逻辑组