将RAG与知识图谱相结合可以提高生成式人工智能应用程序的准确性，可以使用现有的数据库来完成。

生成式人工智能依赖于数据来构建对用户查询的响应。而训练大型语言模型(LLM)需要使用大量数据，例如OpenAI公司的GPT-3使用了CommonCrawl数据集进行训练，该数据集拥有570GB字节的数据和4000亿个令牌。虽然这些数据集的规模庞大，但都是时间快照，无法响应围绕当前发生的事件的查询。人工智能的反应也可能包括“幻觉”——提供看似合理但并不真实的信息。根据Vectara公司发布的幻觉排行榜，即使是表现最好的LLM系列 (目前是OpenAI公司开发的产品)，也存在1.5%至1.9%的幻觉率。

因此，单独使用LLM面临两个问题：答案可能过时或者错误。为了克服这些潜在的问题，组织可以使用数据流将新信息获取到他们的数据集中，并部署检索增强生成（RAG）以与生成式人工智能一起使用的方式对业务数据进行编码。

RAG创建了一组数据，可以搜索与用户查询相关的语义匹配，然后将这些匹配与LLM共享，以便包含在响应中。随着时间的推移，向量数据集可以添加新的或额外的数据，因此可以将相关和及时的数据包含在响应中。

RAG面临的挑战

尽管RAG使组织能够将自己的数据与生成式人工智能服务结合使用，但它并不完美。在将RAG部署到生产环境中遇到的一个挑战是，它无法处理包含相似或相同信息的大量文档之间的搜索。当这些文件被分块并转换成向量嵌入时，每个文件都有可供搜索的数据。当这些文件中的每一个都有非常相似的块时，找到与该请求匹配的正确数据会变得更加困难。当查询的答案存在于多个相互交叉引用的文档中时，RAG也会遇到困难。而RAG不知道这些文档之间的关系。

例如，假设组织已经开发了一款聊天机器人服务，它可以调用其产品数据来回答客户的查询。组织已经将小部件目录转换为向量数据，但是这些小部件都非常相似。当客户查询聊天机器人时，即使有RAG，如何确保提供的响应是准确的？如果这些目录包含指向其他具有额外场景的文档的链接怎么办？提出不准确的建议或提供不准确的查询将影响客户互动。

回答这个问题是考虑采用一种不同的知识管理方法，为RAG所擅长的工作提供补充。微软研究院在今年早些时候发布了一份关于将知识图谱和RAG结合使用的研究报告，其中包括一种名为GraphRAG的技术。

知识图谱将数据点表示为“节点”和“边”，而不是将数据存储在传统搜索的行和列中，也不是作为向量搜索的嵌入。节点将是一个独特的事实或特征，并且边将连接与该事实有相关关系的所有节点。在产品目录的示例中，节点可能是单个产品，而边将是每个产品所具有的相似特征，例如尺寸或颜色。

向知识图谱发送查询涉及查找与该搜索相关的所有实体，然后创建一个知识子图，将这些实体汇集在一起。这样可以检索出与查询相关的信息，然后将其返回给LLM并用于构建响应。这意味着可以处理具有多个相似数据源的问题。与其将每个源视为不同的源并多次检索相同的数据，不如只检索一次数据。

在RAG中使用知识图谱

要在RAG应用程序中使用知识图谱，组织可以使用现有的、经过测试且已知事先正确数据的知识图谱，也可以创建自己的知识图谱。当组织使用自己的数据（例如产品目录）时，需要整理数据并检查其准确性。

组织可以使用自己的生成式人工智能方法来帮助实现这一目标。LLM的构建是为了从内容中提取信息，并在需要时对数据进行汇总。对于知识图谱，可以自动地以正确的格式构建数据，并且随着时间的推移添加更多的数据，支持对知识图谱的任何更新或更改。流行的LangChain服务上有多个工具可以查询文件，然后提供知识图谱，包括LLM Graph Transformer和Diffbot，而知识提取工具REBEL是另一种选择。

对于专用的图分析项目，可能需要采用一个完整的图数据库，该数据库可以使用Gremlin和Cipher等图形语言运行完整的查询。然而，为了支持作为RAG应用程序一部分的知识图谱请求，只需要运行同时覆盖两三个节点的小搜索。这意味着请求通常会表示为几轮简单的查询（每步一个）或SQL连接的形式。在更大的数据集中进行搜索不太可能返回正确的响应——事实上，这可能会导致查询失控，这些查询处理时间过长或实际上无法改善整体响应。

因此，可以使用现有的数据库来存储知识图谱数据，而不是部署额外的图数据库。这也简化了数据运营方面的工作，因为可以减少随时间推移而需要更新新数据的数据平台数量。

将知识图谱与RAG相结合可以提高生成式人工智能应用程序在响应用户查询时的准确性。通过将不同的数据管理技术相结合，可以在数据性能和请求中的语义理解方面获得两全其美的效果。