微信扫码
与创始人交个朋友
我要投稿
今天是2024年6月6日,星期四,北京,天气晴。
我们来看看两个问题,一个是关于RAG中使用Agent模式解决长文本RAG的思路,另一个是关于大模型与知识图谱的结合,UniOQA大模型知识图谱问答框架实现思路,都很干货,感兴趣的可以看看。
有效地处理长文本上下文已成为大型语言模型(LLMs)面临的关键问题。目前出现了两种常见策略:1)减少输入长度,如通过检索增强生成(RAG)检索相关片段;2)扩展LLMs的上下文窗口限制。然而,这两种策略都存在缺点:输入减少无法保证覆盖所需信息的部分,而窗口扩展则难以专注于解决任务所需的相关信息。
为了缓解这些限制,《Chain of Agents: Large Language Models Collaborating on Long-Context Tasks》(https://arxiv.org/abs/2406.02818)提出Chain-of-Agents(CoA)框架,该框架通过自然语言实现多代理协作,以在长文本任务中跨多个LLMs实现信息聚合和上下文推理。
CoA包含两个阶段。在第一阶段,负责不同长文本块的一系列工作代理进行协作,收集回答给定查询所需的证据。
为此,这些工作代理按顺序进行读取和处理,每个工作代理都接收前一个工作代理的消息,并将有用的更新信息传递给下一个工作代理,这块的协作逻辑可以看看如下prompt
这一步的实现思想,可以看看这个伪代码:
在第二阶段,管理代理接收来自最后一个工作代理的完整证据,并生成最终响应。
对应的形式化建模为:
《UniOQA: A Unified Framework for Knowledge Graph Question Answering with Large Language Models》(https://arxiv.org/abs/2406.02110)提出了UniOQA,一个集成了两个互补并行工作流的统一框架。
如上图所示:
包含两个并行工作流的框架:
1、翻译器。用来将query转换成对应的GQL查询语句
该翻译器通过微调大型语言模型(LLM)来生成Cypher查询语言(CQL),并修改CQL中的实体和关系。为了增强表示能力,对LLM进行微调,将问题转换为Cypher查询语言(CQL),解决了与受限语义理解和幻觉相关的问题;
随后,引入了实体和关系替换算法,以确保生成的CQL的可执行性,同时,为了增强问答的整体准确性,进一步将检索增强生成(RAG)过程应用于知识图谱;
其中,微调后的Baichuan2-7B表现较好,用它来生成CQL,LLMs可以在没有正确实体和关系的情况下,将自然语言问题初步转换为CQL,但是有错误。
例如,以图1中的示例为例,微调后的LLM可以生成类似于以下内容的CQL:“match(:ENTITY{name:"Jackie Chan"})-[:Relationship{name:"classic movie"}]->(m) return distinct m.name limit 3”。
然而,知识图谱中的正确实体是“Jackie Chan [Hong Kong actor]”而不是“Jackie Chan”。在没有任何提示的情况下,生成正确的实体是困难的。关系也是如此。仅由模型生成的CQL可能不完全正确,因此需要在下一节中进行实体和关系的替换,也就是ERR算法。
其实ERR算法做的就是实体对齐,本质上是用知识图谱中最语义相似的实体和关系来替换CQL中的实体和关系。例如:
如算法1所示,输入是原始列表{?:??},输出是修正后的列表{?:??}。按顺序遍历每个?和????对,并利用正则表达式进行实体和关系提取,形成实体集?和关系集?;
对于?中的每个实体?,从知识图谱中检索所有相关实体??以形成候选集,然后,利用Baichuan2-7B和手动编写的指令来选择最终实体,最后,获得修正后的实体集?′;
在修正关系集?中的第一个关系?时,获得一个候选关系集,对于关系集合中的每个元素,计算语义相似度,并选择前k个,从而获得修正后的关系集,最后,基于执行准确率选择最佳的正式CQL,并输出修正后的对列表{?:??}。
但这个步骤,存在一个明显的问题,就是错误地选择了最佳的实体或关系。
2、搜索器。该搜索器在知识图内部采用直接搜索方法来检索与所提出问题相关的答案。
这个阶段,采用的是GRAG,它代表将检索增强生成框架应用于知识图谱,以直接检索答案
具体地,采用传统的信息检索方法来检索与主题实体相关的子图作为LLMs的上下文。首先,训练一个实体提取模型来从问题中提取实体(例如,对于问题:“我想知道一些关于中国的信息”,问题中的实体是“中国”);
在获得实体后,为了弥补实体提取中可能存在的潜在不准确性,使用模式匹配查询从Elasticsearch数据库中检索与实体相距一跳的三元组作为上下文信息;
检索到的知识以三元组[头,关系,尾]的形式呈现,其中每个三元组代表一个推理路径的隐式表达。然后,这些聚合的三元组通过使用模板(例如,“头的关系是尾。”)转换为自然语言;
随后,将自然语言格式的知识与问题合并并输入到LLM中。最后,提示LLM基于提供的外部知识生成答案。
最后,通过动态决策算法对两个工作流产生的答案进行优化,得出最终结果,具体地,优先使用Translator的答案,并将Searcher的答案作为补充。
这个公式可以看看:
其中,Q表示自然语言问题,?(·)表示来自Translator的答案,?1(·)表示答案的F1分数,?(·)表示来自Searcher的答案。??????(?,?)表示在?和?之间选择F1分数更高的答案。σ是一个介于0到1之间的决策因子,决定了决策的阈值。
但其中有个问题,?1(·)表示答案的F1分数在推理阶段是没法估计出来的,所以这个很难实施。
可以看看最终的效果:
本文主要讲了两个问题,一个是关于RAG中使用Agent模式解决长文本RAG的思路,另一个是关于大模型与知识图谱的结合,UniOQA大模型知识图谱问答框架实现思路。其中更多的都是流程化的思想,依旧有许多优化空间。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-12-26
GraphRAG和轻量级LightRAG技术及应用案例深度解析
2024-12-26
使用 Markdown 和 Gemini 为 RAG 解锁 PDF
2024-12-26
长文 | RAG的实战指南及探索之路
2024-12-26
2024年,百万上下文依然没有杀死RAG
2024-12-26
在推荐、RAG等业务中,如何完成亿级向量的快速检索?
2024-12-25
RAG 工程实践优化点及方法总结
2024-12-25
强化 RAG 应用:生成式 AI 返回准确率提升的高效策略与实践
2024-12-25
RAG开发中,如何用Milvus 2.5 BM25算法实现混合搜索
2024-07-18
2024-05-05
2024-06-20
2024-09-04
2024-05-19
2024-07-09
2024-07-09
2024-07-07
2024-06-13
2024-07-07
2024-12-26
2024-12-24
2024-12-21
2024-12-14
2024-12-01
2024-11-27
2024-11-25
2024-11-06