知识图谱和大语言模型在企业或组织内部应用的一个重要场景就是知识管理，通过技术手段在短时间内以更少的工作量，发现隐藏在企业数据库和业务文档中更深入的洞察，它们分别在不同阶段主导了企业服务项目的建设。

以知识图谱为重心的项目阶段（2017年-2023年）

以知识图谱技术为重心的项目从2017年开始兴起，当年国务院发布的《新一代人工智能发展规划》首次在国家政策文件中提到知识图谱”的概念，这也是很多人第一次听说这个名词，那段时间正好笔者写了几篇干货科普文章，因此第一次感受到流量带来的价值。

因为知识图谱这个概念是由谷歌率先提出，并应用在谷歌的搜索产品中，因此早期大部分的研究和资料都以通用知识图谱为主，从《规划》文件发布后，越来越多的产学研专家和机构开始摸索如何在领域内，比如企业内部的多源异构数据，通过知识图谱技术构建行业知识图谱。

早期项目以可视化分析、语义搜索、智能问答等基础应用为主；后续随着研究深入，涌现了很多符合行业特性的深度解决方案，比如：利用图计算和逻辑推理能力实现的金融营销与风控，结合事理图谱能力实现的金融量化投资与舆情分析，结合GIS和强化学习能力实现的军工领域态势分析与兵棋推演，当然也有一些符合国情的领导驾驶舱大屏可视化、3D图谱可视化方案。

但是行业知识图谱项目落地一个很大的难题在于对非结构化数据的处理，因为图谱属于结构化的知识表示，很容易通过ETL的方式导入结构化数据构建图谱，但是对于非结构化数据内的知识获取，传统的NLP算法在精准度、可移植性方面存在技术的挑战。因此当时最终效果好的项目，前期都要花费大量的人工去构建高质量的行业知识图谱，所以那时的人工智能项目被戏称为“人工的智能”，有多少人工，就会有多少的智能。当然构建好图谱只是第一步，后续进行图谱知识的更新，又是一笔持续高成本的投入。

这时有人会问了，行业数据都具有相似性，我在领域内某一家企业做好项目之后，是否可以以低成本快速覆盖行业内其他客户？至少在图谱项目中，我没有看到走通这条路径的企业。究其原因个人总结有如下几点：

1.知识图谱项目是一个偏工程的技术组合：与NLP、数据清洗、数据仓库存在“你中有我，我中有你”的关系，就算同一领域内相似企业在业务需求、数据分布、内部系统建设情况等方面必然存在着差异，因此图谱项目中最大的成本 -- 构建高质量可用的领域知识图谱 -- 并没有降低，所谓的低成本成为了伪命题；

2.项目增长带来的企业隐形风险：可能利用相关行业案例能够实现“快速覆盖”，拿下不少项目，但是伴随着项目增长带来的交付人员扩张，企业的人效比并没有显著的提高，反而企业隐形风险就像滚雪球一样在增加，一旦甲方预算减少、融资衔接不上，那么公司将会面临如何维系的问题；

3.图谱在数据稀疏环境下的优势不明显：还有一点就是图谱在企业数据关联维度较少、数据稀疏的情况下，难以发挥优势，很多时候与传统关系型数据库的方案相比差距并不大，因此图谱项目在从头部企业向腰尾部覆盖的过程中，无法有绝对的优势让企业换代升级。

就像古希腊哲学家赫拉克利特说的："人不能两次踏进同一条河流"，你也无法在两个项目中构建同一个知识图谱。就在大家还在为图谱项目微薄的毛利挣扎时，大语言模型的时代来临了。

以大语言模型为重心的项目阶段（2023年-至今）

大语言模型的能力和优势这里不再赘述，2022年底ChatGPT发布后，有种说法是大模型将取代传统的AI技术，包括知识图谱，随着对大模型的了解深入，人们发现其在知识的时效性和生成内容的可靠性方面存在缺陷，因此大家就想到了与搜索引擎技术结合，先利用搜索的方式，尝试获取到最新的、具体相关的事实和数据，作为上下文背景知识，结合原始问题和Prompt一并给到大模型，增强模型自身的知识和内容生成，从而缓解内容幻觉和知识及时性的问题。这也就是目前很火的RAG（检索增强生成）。

早期RAG概念还未形成共识的时候，LangChain提供了成熟的大语言模型与外部数据源结合使用的框架，因此当时的RAG也被称为LangChain，它集成了向量数据库等工具，方便开发者快速开发基于大语言模型的应用。除了主流框架纷纷选择向量数据库，对RAG和LLM来说，这确实是一个优先考虑的选择，主要原因有如下几点：

1.语义理解的一致性：大语言模型通常使用向量空间来表示和理解文本的语义，向量数据库存储的向量与大语言模型内部使用的表示方式高度一致，这使得检索到的信息更容易被模型理解和利用。

2.嵌入(Embedding)的直接使用: 大模型常用的嵌入技术（比如OpenAI提供的text-embedding-ada-002嵌入模型）可以直接存储在向量数据库中，这种无缝衔接大大简化了RAG的实现流程。

3.相似度计算的效率: 向量数据库在检索数据时，通常使用近似最近邻（ANN）等算法，可以在大规模数据集上快速找到相似向量，从而快速获取相关上下文。

4.更好的信息溯源：通常我们会在向量数据库中存储原始文本对应的元数据，这使得RAG系统可以提供信息来源，增强输出答案的可信度和可溯源。

5.多模态的支持：向量数据库支持将非结构化多模态数据（文本、图像、音频等）以向量嵌入的方式进行存储和管理，这与最新的多模态LLM非常契合，为更复杂的RAG应用提供了可能。

除此之外还有支持动态知识更新、降低大模型的推理成本等优势，因此2023年有很多人投身到RAG知识库方向进行创业，并获得了融资，同时也出现了很多优秀的RAG知识库开源项目，但是就笔者的观察，传统的RAG产品要让甲方客户买单很难，虽然RAG原理清晰，入门简单，但在实际业务落地过程中存在许多困难。

在深入分析这个问题之前，我们再仔细想下RAG的原理，去掉大模型的光环，你会发现RAG本质上与以前的智能搜索系统有很多相似之处，因此可以从智能搜索的内容理解（Content Understanding）、查询理解（Query Understanding）以及匹配召回（Match & Recall）三个核心环节来进行分析，技术在企业知识服务场景落地过程中存在的问题：

1.内容理解（CU）

CU做的工作是对原始的数据进行内容理解和深度挖掘，以便更好的匹配后续的精确检索。这一环节存在如下的问题：

a.数据获取和处理难题：这是所有企业服务项目的都会面临的难题，数据格式、权限安全、数据清洗等等，这类难题没有因为技术的更新而改变；

b.长文本处理难题：对已有的长文档数据，需要切分成小块进行向量化存储，分块的大小很可能导致上下文信息的丢失，每个文本块是否能保证文本连贯性和语义完整性？同时分块后的向量难以有效捕捉跨越大范围的主题和语义的关联；

c.结构化信息丢失：向量化过程中，往往会丢失原始文档中的结构信息，如标题层级、表格关系等，同时也无法充分利用结构化数据库的内容；

d.语义理解的局限性：在智能搜索的CU环节，往往会给内容打上语义标签，这些语义标签带有行业的业务理解在里面，RAG主要依赖Embedding模型的向量表示，无法有效地处理业务中的歧义、隐喻等语义。

2.查询理解（QU）

在QU环节需要准确理解用户输入查询语句的真实意图，一般会进行查询扩展、意图识别等处理。这一环节存在的问题：

a.查询重写和扩展能力弱：缺乏有效的查询重写机制，难以处理错别字、拼音、同义词等问题，同时查询扩展能力有限，可能导致搜索结果不全；

b.意图识别的局限性：对于多步骤多关联或需要推理的复杂查询，难以理解背后的用户意图，比如：“A与B有什么区别？优缺点分别是什么？”，“XX管理的基金中持仓了哪些股票？”；

c.领域特定查询能力弱：由于RAG需要用Query进行向量匹配检索，Query问法千奇百怪，比如法律领域基于法律条文构建了RAG知识库，用户提问时描述的是具体案件内容，向量查询难以将口语化的场景描述与法律条款进行精准的匹配；

d.短文本embedding效果不佳：Query一般是一句简短的文字，这会限制模型的发挥，从而影响embedding的质量。

3.匹配召回（Match & Recall）

匹配和召回环节致力于从海量数据中快速、准确的找到与查询相关的信息，传统RAG会采用向量相似度的方法，因此存在如下的问题：

a.召回策略单一：如果过度依赖向量相似度，那么很容易忽略其他可能的相关性因素，难以实现多角度、多策略的综合召回；

b.精准匹配能力弱：对需要精准匹配的查询支持不足，难以平衡语义相似和精准匹配的需求。比如用户查询：“特斯拉2022年第四季度的营收是多少？”，就算系统中拥有完全匹配的答案，传统RAG仍旧会返回“第一季度”、“上一季度”、“主营收入”、“2021年”的相关信息；

c.排序机制简单：主要基于向量相似度排序，缺乏考虑其他重要因素（如时效性、权威性等），难以实现个性化或上下文感知的排序；

d.结果多样性不足：传统RAG可能倾向于返回高度相似的结果，缺乏多样性，难以在相关性和多样性之间取得平衡。

以上仅是部分难点问题，目前基于传统RAG的优化方案很多，以上提到的许多问题已经被解决或者正在被解决，我们Feliz AI打造的RAG系统也是站在前人的肩膀上，解决了这一系列的难题。

为什么要结合KG和LLM打造RAG知识库产品

一方面是个人的经历决定，熟悉我的朋友知道我一直在行业知识图谱、企业级搜索以及大语言模型方向深耕，包括技术的布道咨询、产品研发和项目交付；

另一方面结合前面两段的介绍，传统的知识图谱和传统的RAG均面临许多难题，但是KG和LLM都是围绕着知识的操作（Manipulation）和表示（Representation）而设计的技术，两者能力存在互补，（LLM）神经网络模型的有效性与（KG）图系统的结构化关联及可解释性的深度融合，进而打造出来的知识库产品存在天然的优势。这点在很多介绍KG-RAG的文章中都有提到，后续我也会专门写一篇进行详细的介绍，欢迎关注公众号ByteChu及时接收推送。

我看到的KG-RAG知识库产品存在哪些问题？

目前KG-RAG还处于起步阶段，最近微软新发布的GraphRAG带来了一定热度，但是根据笔者的观察，市面上KG-RAG的方案在企业知识管理这一业务场景中，仍旧存在以下问题：

1.图谱构建层面的问题：

a.知识结构化程度不够：很多结合KG的方案主要针对文件之间的引用和关联进行层次图谱的构建，无法充分利用非结构化文档内容中的丰富信息，仅仅作为文件检索的增强，这在某些特定场景中是符合要求的，但是对于知识密集型企业，需要拥有更深入的洞察；

b.知识抽取可用度不高：部分方案提供了对内容的三元组知识抽取，但是属于通用图谱的抽取，这种抽取对其中蕴含的业务场景所关注的背景知识无法感知，最终得到一堆无关的三元组，白白浪费大模型的tokens，当然如果你是OpenAI的金主爸爸咱另当别论；

c.知识的消歧普遍缺失：对于长文本的知识抽取需要采用切块分段的方式，因此前后必然存在冲突和歧义的情况，如何确保知识的一致性进行知识消歧，目前仅在微软的GraphRAG中看到了非破坏性的知识冲突解决（non-destructive entity resolution）概念，但是（Not Enabled by Default）。

2.场景应用层面的问题：

大部分厂商目前主要在场景侧发力，但是前提需要有一个高质量的知识图谱，因此大部分都会选择一些公开的图谱库，但是企业内的数据和知识存在一定的隐私和安全性，因此外部的图谱库并不能解决内部的问题。当前在场景侧存在的问题如下：

a.图谱内知识利用率较低：以图向量检索、Text to GraphQuery为代表的方案，抛开准确性不谈，两者均未能最大化利用辛苦构建的图谱中的知识；

b.图谱与大模型结合生硬：图谱与RAG流程中标准化方法的整合存在多种实现方式，如何充分利用高度凝练的结构化知识是一个难题；

c.无法实现动态图谱调整：同一份数据针对不同业务人员、不同场景，有不同的应用需求，就算同样的场景，随着时间推移，需求存在更新，如何快速的调整适配。

以上是我看到的一些问题，也是我打造Feliz RAG这款产品的动机之一。

我目前在做的KG和LLM结合的RAG知识库产品

当前产品还在不断迭代打磨过程中，这是上周简单录制的一个视频效果，拿了前段时间很火的《玫瑰的故事》小说，可以实现上传一篇小说后，任意提几个你所关心的问题，后台会自动构建《玫瑰的故事》的知识图谱，随后就可以在Feliz基于知识图谱的RAG系统上，准确回答之前提到的问题，系统充分融合了大模型和知识图谱的能力进行回答，不仅能回答“黄玫瑰和关芝芝有什么关系？”这类隐含关联的问题，还能回答“有几个男人追求过黄玫瑰？”这类统计型的问题，当然对于传统RAG的语义问答能力也完全兼容。