今天是2024年11月06日，星期三，北京，天气晴
最近GraphRAG还是火了一阵，也有一些新的工作，比如KAG以及lightRAG出现，我们前面也讲过很多，今天来看了下，做些对比，也谈谈自己的一些看法，核心点是，当前阶段无论是Graph，还是KG，应该跟RAG浅结合，把收益最大化。
另一个，还是看看RAG的进展，E2E-AFG自适应过滤端到端RAG模型，里面为了做生成、是否包含相关信息的分类模型联合训练做的数据伪标注有些意思，可看看。
抓住问题看本质，抽象总结，总归有很多收获，供大家意思参考并思考。
一、也谈KAG知识增强生成框架
最近《KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation》(https://arxiv.org/pdf/2409.13731,https://github.com/OpenSPG/KAG/blob/master/README_cn.md)受到关注，我来谈谈几点看法，这也是我同作者的一些讨论观点。
先看KAG是什么，根据https://github.com/OpenSPG/KAG/blob/master/README_cn.md中的描述，正式发布的知识增强生成（KAG）的专业领域知识服务框架。KAG 旨在充分利用知识图谱和向量检索的优势，并通过四个方面双向增强大型语言模型和知识图谱，以解决 RAG 挑战：
(1) 对LLM友好的知识表示， 参考了DIKW层次结构，将SPG升级为对LLM友好的版本；
但这一块，是知识图谱构建的一个重要点，就是本体设计，本体设计的表示很多，也可多样，难度在于怎么设计出来针对特定领域的本体，这个专业性很强；
(2) 知识图谱与原文片段之间的互索引
这一步的互索引，实际上就是将文本经过知识图谱抽取的那一套，这块一直是大家所头疼的事情，抽不全、抽不准、通用性差。
也就是这个图，先后要进行semantic chunking、infomation Extraction、Alignment，然后最终才形成一个领域的KG。
知识图谱与原文片段之间的互索引就很自然的就形成了，如微软的GraphRAG中的实体、chunk、Text、Document之间就存在着很自然的联系；
(3) 逻辑形式引导的混合推理引擎
KAG 提出了一种逻辑形式引导的混合求解和推理引擎。该引擎包括三种类型的运算符：规划、推理和检索，将自然语言问题转化为结合语言和符号的问题求解过程。在这个过程中，每一步都可以利用不同的运算符，如精确匹配检索、文本检索、数值计算或语义推理，从而实现四种不同问题求解过程的集成：检索、知识图谱推理、语言推理和数值计算。
推理过程中，关键步骤如下几步：将自然语言问题转换成可执行的逻辑表达式，此处依赖的是项目下的概念建模，可参考黑产挖掘文档；将转换的逻辑表达式提交到 OpenSPG reasoner执行，得到用户的分类结果；将用户的分类结果进行答案生成。
如下图所示：
这个存在一个很难的点，将自然语言问题转换成可执行的逻辑表达式，这其实做的事nl2sql，其中本质是很容易出错的，填槽容易出错。并且如图所示，包括踱步推理的步骤，并且要对应于其设计好的logicalform做推理，pipeline其实很长，有错误传播
(4) 与语义推理的知识对齐
这个知识对齐，其实就是alignment，将不同的实体进行对齐，但这个其实又是KG的老大难问题，同名不同义，同义不同名的case很多，比如issues里提到的。
论文里也有提到，知识间语义关系错位。正确的答案和查询之间通常需要特定的语义关系，如包含、导致和属于等，而检索过程中依赖的相似度是一种弱语义度量，缺乏属性和方向，可能导致内容检索不精确。知识粒度错位。开放信息抽取带来的知识粒度差异、噪声和不相关性问题对知识管理提出了巨大挑战。由于语言表达的多样性，存在大量同义或相似的节点，导致知识元素之间的连接性低，使得检索召回不完整。
所以，在抽取阶段为每个实例、概念或关系添加了描述性文本信息，以增强其可解释性和上下文相关性，但这一块也比较不可控；
所以，整个KAG下来，其本身其实很臃肿，涉及到的东西很多，如下The model capabilities required for KAG，涉及到信息抽取、自然语言推断等多个模型，这个很不自然。
我与作者梁老师有过讨论，总结下我的一些观点：
1、我们来看一个东西，我更倾向于看，核心问题是否解决，集成性的方案没有从根上解决问题：1、应用条件，适合场景是什么？2、ROI是否合适？3、效果如何？性能、效果。除了这些问题，其中抽取模型的精度、速度、构建图谱花费的精力、知识更新所花费的成本，速度这些，其实综合评估起来会更合适。抛开算力、抛开速度、抛开场景讲效果，或者pr一个学术评测集结果，对于工业界来说，不是个好事儿；
2、我对集成性的框架不是很感冒，这是我的一些偏见；核心还是要快、有效、解决实际问题，比如KAG中的一些nl2sql、抽取的model，这些模块化开出去会更有推广意义，大家可以集成到更多的实际落地中；graphrag，也是5月份疯狂pr，我们也试过，业务端是不买帐的，也被证明是技术理想型，技术路线也没问题，逻辑也通，但就是ROI超级低；就是谈构建和查询，用户色变；所以，这也是很多graphrag一类，入场优势很缺的点；有太多用户，都是那种，拿来就要用；这也是我不看好集成型框架开源的一个点；开是开了，但太大，太抽象，用户还是要用到自己的业务里去，还是要熟悉框架的语法，还是有学习成本；比如里面的spg，里面的模块还是需要自己去调，这会带来一个很大的问题，那就是：可以借鉴思想，可以自己写一个，然后就不用了，见过太多这样的，最重要的是，整个KaG的效果，不取决于工程pipeline，取决于每个细分模块算法的性能，并且是特定数据，特定业务的性能，这是算法范畴；
当然，也有人来拿lightRAG(https://github.com/HKUDS/LightRAG，https://lightrag.github.io/，https://arxiv.org/pdf/2410.05779，https://microsoft.github.io/graphrag/)来对比，其来自于nano-graphra(https://github.com/gusye1234/nano-graphrag)，其实就是微软Graph的简化版本，将社区、社区宅摘要这些环节做了去除，这种去除是好的，不会太重，对于知识更新也更快；
如GraphRAG的路线图：
如lightRAG的路线图如下：
应用场景两个都很类似，一个是local search，一个是global search，lightRAG对应的是lowlevelsearch(主要关注检索特定的实体以及它们相关的属性或关系。这个层次的查询以细节为导向，旨在提取图中特定节点或边的精确信息，所以取的是related text_units, topk entities results, related relations), high level search（涉及更广泛的主题和总体概念。这个层次的查询聚合多个相关实体和关系的信息，提供对更高层次概念和总结的洞察，而不是具体细节，所以取的是related text units, topk relations results, related entities reusults）。前者以实体为中心，后者以关系为中心。
也顺便看下为了做GraphRAG，需要做的依赖，其出了考虑环境成本，还需要考虑到抽取所花费的时间、token、对应的抽取不完整、不准确、更新成本以及索引空间成本，还有搜索成本等，微软的GraphRAG明显很重，但KAG其实更重，它把KG的缺点全带进来了，并强行与spg相绑定，会造成有学习成本。虽然在多跳等学术评测集上有提升，但真实场景下，也不见得会有这种多跳，也依赖于图谱本身的正确性，所以ROI不见得会高，其中的目的和意义，我们是需要做思考的。知识图谱或者Graph，其目前来看，最大的意义是，缓解暴力chunk切分导致的语义关联缺失，在针对实体类型的问题类型提供更多元化的召回结果，提升召回率。但增益有多少，还需要多看看。
二、E2E-AFG自适应过滤端到端RAG模型
联合过滤掉不相关上下文，是RAG的一个重点。《E2E-AFG: An End-to-End Model with Adaptive Filtering for Retrieval-Augmented Generation》(https://arxiv.org/pdf/2411.00437，https://github.com/XieZilongAI/E2E-AFG)，将答案存在判断和文本生成集成在一个统一的端到端框架之中，旨在通过集中关注相关的内容，并减少无关信息的影响，来生成更加精确的答案。
一句话概括，这个工作的思路在于联合训练。 因为要将将答案存在判断和文本生成集成在一个统一的端到端框架之中，所以会有两个loss，一个是分类loss，一个是生成loss。在生成任务建模上，对于每个训练样本（𝑄,𝐴,𝑃,𝑆），首先在不同字段之间插入一个特殊字符，以确保它们在通过E2EEncoder编码后能够被区分。然后，将编码后的查询𝑄embs、检索到的段落集合𝑃embs和伪答案𝑆embs输入到E2Egen中，以产生输出答案𝑂𝑂；在分类任务上，共享相同的编码器E2EEncoder。
其中，分类loss（Losscls）的ground-truth就是来自于得到银级(伪标注)分类标签；生成loss(Lossgen)的ground-truth就是真实答案。
问题来了，怎么拿到这个分类标签，也就是数据生成的阶段，分为2步，
首先，生成伪答案。
在知识密集型任务中，模型通常依赖于从数据库检索的段落来生成答案。然而，这些段落往往不完全匹配问题，导致模型缺乏可靠的证据来生成准确的答案。为了减轻这一限制，引入了一种策略，利用预训练的大模型来生成伪答案，这些伪答案作为额外的参考，帮助模型产生更准确的响应。为了探索如何生成高质量的伪答案，设计了几种不同的提示，如图2所示。
第一种直接生成简洁的答案，这可能导致产生幻觉性内容；第二种鼓励模型在不确定时做出最佳猜测以得出正确答案；第三种结构化提示指导模型同时提供得出答案背后的推理。
其次，获取银级(伪标注)分类标签
这个有趣，银级分类标签（Silver Classification Labels）指一种辅助性的、非完全准确的分类标签，用于训练和指导模型识别哪些检索到的段落或生成的伪答案中包含了真实答案。这些标签被称为“银级”，是因为它们虽然不如人工标注的金标准（Gold Standard）那样精确和可靠。
为啥要做这个，是因为在没有足够人工标注数据的情况下，银级标签可以作为一种廉价的替代品，帮助模型学习如何识别和过滤与问题相关的信息。通过银级标签，模型可以判断哪些检索到的段落更有可能包含答案，从而在生成答案时更关注这些段落，减少无关信息的干扰。
因此，也就有了这个，为了确定检索到的段落集𝑃和生成的伪答案𝑆是否包含答案引入了三种上下文过滤方法：
（i）字符串包含（STRINC）：检查上下文是否直接包含真实答案；
（ii）词汇重叠（LEXICAL）：测量上下文和真实答案之间的词汇重叠；
（iii）条件交叉互信息（CXMI）：评估生成器在给定上下文的情况下产生真实答案的可能性。
对于特定任务，选择最合适的过滤方法来获取银级分类标签。例如，在问答任务中，使用StrInc来评估每个段落或伪答案是否包含真实答案。相比之下，在事实提取任务中，真实答案类似于布尔值，无法使用前两种方法进行评估，采用CXMI来计算相应的概率，并设置阈值𝑡0以派生银级分类标签。将获得的标签与真实答案𝐴连接起来，以便于处理。
这么一训练，然后效果还行，如下：
总结
实际上，Graph或者KG跟RAG应该浅融合，不要重度融合。知识图谱包括实体抽取，关系抽取，实体对齐，实体推理，外部还有图算法，社区这些，全部弄进去或者大部分弄进去，那就是重度融合，这就是KAG的很大的问题，本身KG就是老大难，技术漏洞很多，性能上限低，成本高。lightRAG还好一些，轻度一点。
所以知识图谱与RAG结合，还是要适当刹刹车，算算账，把误差和成本考虑进去。
参考文献
1、https://arxiv.org/pdf/2411.01751
2、https://arxiv.org/pdf/2411.00437
3、https://arxiv.org/pdf/2409.13731
关于我们
老刘，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。
对大模型&知识图谱&RAG&文档理解感兴趣，并对每日早报、老刘说NLP历史线上分享、心得交流等感兴趣的，欢迎加入社区，社区持续纳新。
加入会员方式：关注公众号，在后台菜单栏中点击会员社区->会员入群加入
