利用大模型进行知识图谱问答的交互式系统LinkQ：兼看中文OCR代表方案、Benchmark及数据合成工具

 

今天是2024年6月15日，星期六，北京，天气晴。

6月份转眼已经过去一半，因此，乘着周末，老刘说NLP技术社区将于今晚迎来社区第21讲，做《2024年6月份半月度大模型&KG&RAG&文档智能相关进展》汇报，同时，跟第20讲一样，第二个panel也邀请了行业朋友做文档领域技术实践分享，欢迎大家一同参加。

近期看到一个很有趣的观点，来自图灵奖得主hinton的观点，很有启发，推荐看看：我们的大脑以权重的形式储存知识，它们使用这些权重来重构事件。如果事件是最近的，那么重构通常相当准确。如果事件是旧的，我们通常会在很多细节上出错（除非我们频繁地复习）。也就是记忆不是存储，而且是重构。

在技术内容上，我们今天来看看两个问题，一个是中文OCR代表方案、Benchmark及数据合成工具，用来解决中文OCR的基本认知；一个是关于利用大模型进行知识图谱问答的交互式系统LinkQ，其中的一些交互式思路值得借鉴。

对了，

问题1：中文OCR代表方案、Benchmark及数据合成工具

OCR问题在整个文档理解中扮演着十分重要的角色，尤其是在中文文档领域，因此，我们来看看关于中文OCR领域的Benchmark内容。

前几年的一个工作 《Benchmarking Chinese Text Recognition: Datasets, Baselines, and an Empirical Study》(https://arxiv.org/abs/2112.15093)，地址：https://github.com/FudanVI/benchmarking-chinese-text-recognition

其手动收集了来自公开竞赛、项目和论文的CTR数据集，并根据应用场景将数据集分为四类：场景（scene）、网络（web）、文档（document）和手写（handwriting）数据集。具体样例如下：

因为我们关注文档场景，所以主要看3个内容：

1、关于document datasets的数据合成

关于文档场景的OCR识别数据，可以进行合成，例如使用text_render，地址在：https://github.com/Sanster/text_renderer,https://github.com/oh-my-ocr/text_renderer

2、一些ocr的bad case

一个是Failure cases in the scene dataset

一个是Failure cases in the document dataset

一个是Failure cases in the handwriting dataset.

3、一些方案的表现水准

可看看一些模型在不同场景下的水准，指标是acc/ned：

对应的代码在：

CRNN: https://github.com/meijieru/crnn.pytorch;

ASTER: https://github.com/ayumiymk/aster.pytorch;

MORAN: https://github.com/Canjie-Luo/MORAN_v2;

SEED: https://github.com/Pay20Y/SEED;

SRN: https://github.com/PaddlePaddle/PaddleOCR;

SAR: https://github.com/liuch37/sar-pytorch;

TransOCR: https://github.com/FudanVI/benchmarking-chinese-text-recognition/tree/main/model

问题2：利用大模型进行知识图谱问答的交互式系统LinkQ

作为第二个问题，我们来看看关于知识图谱与大模型进展。也是最近的一个工作《LinkQ: An LLM-Assisted Visual Interface for Knowledge Graph Question-Answering》(https://arxiv.org/pdf/2406.06621)，利用大型语言模型（LLM）辅助知识图谱（KG）查询的构建，通过自然语言问答简化传统复杂的图查询语言需求，其本质上就是一个利用大型语言模型（LLM）来精细化自然语言问题并将其转换为知识图谱（KG）查询的系统。

代码放在：https://github.com/mit-ll/linkq，也可以体验其demo:https://mit-ll.github.io/linkq/

有几个点可看看：

1、为什么要干这个事儿

其设定目标有些启发，例如：

其一，支持来回对话(back-and-forth)，将自然语言问题细化为精确查询。 用户可能对知识图谱中的数据提出开放式或针对性的问题。当问题是开放式时，LLM应该帮助用户细化搜索。重要的是，在保持用户问题语义意图的同时，生成一个结构良好、精确的KG查询。

其二，减少LLM生成错误信息的倾向。使用LLM生成KG查询可能导致错误的数据ID或错误的查询结果。应该采取措施减少这些情况的发生频率。

其三，预览LLM生成的查询信息以评估其准确性。 KG查询可能在计算上很昂贵。应该向用户展示查询的预览，包括相关信息，以帮助他们评估数据和查询的准确性。

其四，提供来自LLM和KG的多模态查询结果。 用户出于多种目的与KG进行问答。因此，查询结果应该以文本形式（供消费）和表格形式（供进一步分析）显示。尽可能地，LLM的结果摘要应该基于KG数据。

2、怎么干的这事儿？

整个流程如下所示，展示了LinkQ系统的示例工作流程，

可以看到，架构由以下几个主要部分组成：

A. Chat Panel（聊天面板）：用户可以通过这个面板与LLM进行交互，提出特定或开放式问题；

B1.Query Editor（查询编辑器）：查询预览面板的一部分，支持交互式编辑查询；

B2.Entity-Relation Table（实体-关系表）：提供从知识图谱映射过来的数据ID，帮助用户评估LLM生成的查询的正确性；

B3.Query Graph（查询图）：通过可视化查询的结构来展示知识图谱的底层架构；

C.Results Panel（结果面板）：提供高一个清洁、可导出的表格以及基于查询结果的 LLM生成的摘要。

当然，从给出的例子中可以看到，其中的知识图谱使用的是SPARQL，具体的内部实现流程可以看下图：

其中，做知识图谱检索(text2cypher)最重要的是将数据映射到知识图谱，也就是做实体链接。因为使用各种LLMs生成KG查询时会经常生成错误的额实体和关系ID。

但是，微调一个LLM以记住KG中所有可能的实体、关系和属性ID在计算上是不切实际的。例如，WikidataKG拥有超过一亿个实体。即使KG的规模较小，任何对ID的维护更新都可能导致需要重新训练LLM。

因此，这个匹配的过程，更具备实操性的工作，实际上是做模糊匹配。

例如，该工作所采用的方法：

在实体链接方面，基于名称和上下文的模糊搜索实体。 具体地，利用模糊搜索，这样LLM就不必依赖于确切的实体名称来识别ID，而是根据用户问题的上下文从语义相似性中识别ID。系统指示LLM选择与用户问题上下文最匹配的实体ID，这种方法有助于处理重复和模糊的实体。例如，如果用户询问关于《教父》的票房总收入，LLM应该选择匹配电影的实体ID，而不是书籍系列。但是，这个的重点在于怎么来衡量这个相似性。

在实体关系和属性方面，给定实体，查找其关系和属性。 具体地，LLM采用类似的方法，在语义上搜索所有与用户原始问题紧密匹配的属性和关系。但这个搜索确保属性和关系实际上属于KG中的那个实体。例如，如果用户询问关于《教父》的票房总收入，LLM将寻找任何属于《教父》的属性或关系，这些属性或关系与票房名称相似。这个其实就会用到schema来进行约束搜索；

针对多跳查询问题。 需要具体遍历图以识别多跳关系，具体地，LLM从头部实体遍历到尾部实体，以识别多跳数据。例如，在映射问题“Google的创始人是谁，他们的出生日期是什么”的数据时，LLM需要从Google实体跳转到其创始人实体，以识别他们的出生日期属性。

综合来说，这个工作，做的更多的是一个工程的可视化。

总结

今天我们主要看了两个问题，一个是中文OCR代表方案、Benchmark及数据合成工具，用来解决中文OCR的基本认知；一个是关于利用大模型进行知识图谱问答的交互式系统LinkQ，其中的一些交互式思路值得借鉴。

看到一个有趣的生物学观点，复杂情感和自我意识是右脑前部的功能，而左脑前部负责复杂决策的制定。脑前叶是发育最晚的脑组织，大约在25岁左右，这很可能是内向孩子“大器晚成”的原因。大脑前叶主要帮助我们在事前作详细的计划。因此，25-31岁似乎是很值得去自律坚持实施的一个阶段，大家可以试试看。

参考文献

1、https://arxiv.org/abs/2112.15093

2、https://github.com/mit-ll/linkq

关于我们

老刘，刘焕勇，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。

老刘说NLP，将定期发布语言资源、工程实践、技术总结等内容，欢迎关注。

对于想加入更优质的知识图谱、事件图谱、大模型AIGC实践、相关分享的，可关注公众号，在后台菜单栏中点击会员社区->会员入群加入。