将知识图与检索增强生成相结合可以提高生成式人工智能应用程序的准确性，通常可以使用现有的数据库来完成。
生成式人工智能依赖于数据来构建对用户查询的响应。训练大型语言模型(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结合使用的研究报告，并使用了一种名为GraphRAG的技术。
知识图不是将数据存储在传统搜索的行和列中，也不是将数据存储在向量搜索的嵌入中，而是将数据点表示为节点和边。节点将是一个明显的事实或特征，并且边将连接与该事实有相关关系的所有节点。在产品目录的示例中，节点可能是单个产品，而边缘将是每个产品所具有的相似特征，如大小或颜色。
向知识图发送查询需要查找与该搜索相关的所有实体，然后创建一个知识子图，将所有这些实体集合在一起。这将检索查询的相关信息，然后将这些信息返回给LLM并用于构建响应。这意味着可以处理具有多个类似数据源的问题。而不是将每个数据源视为不同的并多次检索相同的数据，而是只检索一次数据。
在RAG中使用知识图谱
要在的RAG应用程序中使用知识图谱，既可以使用现有的知识图谱，其中包含经过测试并事先知道是正确的数据，也可以创建自己的知识图谱。当您使用自己的数据(如产品目录)时，您将需要整理数据并检查其准确性。
企业可以使用自己的生成人工智能方法来帮助实现这一目标。大型语言模型(LLM)旨在从内容中提取信息，并在需要时对数据进行总结。对于知识图谱，可以自动地以正确的格式构建数据，并且随着时间的推移，随着您添加更多的数据，可以支持对图谱的任何更新或更改。流行的LangChain服务上有多个工具可以查询文件，然后提供知识图，包括LLMGraphTransformer和Diffbot，而知识提取工具REBEL是另一个选择。
对于专门的图形分析项目，企业可能希望采用可以使用图形语言(如Gremlin和Cipher)运行完整查询的完整图形数据库。然而，为了支持知识图请求作为RAG应用程序的一部分，您将只需要运行一次覆盖两个或三个节点的小型搜索。这意味着您的请求通常表示为几轮简单查询(每一步一个)或一个SQL连接。在较大的数据集上执行搜索不太可能返回正确的响应—实际上，它可能导致失控的查询，这些查询需要很长时间才能处理，或者实际上不能改善您的总体响应。
因此，可以使用现有的数据库来存储知识图数据，而不是使用额外的图数据库部署。这也简化了数据的操作方面，因为您可以减少数据平台的数量，必须随着时间的推移与新数据保持同步。
将知识图与RAG相结合可以提高生成式人工智能应用程序在响应用户查询时的准确性。通过组合不同的数据管理技术，可以在请求中的数据性能和语义理解方面获得两全其美的效果。
