原文：Knowledge Graphs & LLMs: Multi-Hop Question Answering
在之前的文章中，我们学习了检索增强方法来克服大型语言模型(Large Language Models, llm)的局限性，比如幻觉和有限的知识。检索增强方法背后的思想是在提问时引用外部数据，并将其提供给LLM，以增强其生成准确和相关答案的能力。
当用户提出问题时，智能搜索工具会在提供的知识库中查找相关信息。例如，您可能遇到过在pdf文件或公司文档中搜索相关信息的情况。这些例子中的大多数使用向量相似性搜索来识别哪些文本块可能包含准确回答用户问题的相关数据。实现相对简单。
pdf文件或文档首先被分割成多个文本块。一些不同的策略包括文本块应该有多大，以及它们之间是否应该有重叠。在下一步中，使用任何可用的文本Embedding模型生成文本块的向量表示。这就是在查询时执行向量相似性搜索所需的所有预处理。剩下的唯一步骤是在查询时将用户输入编码为向量，并使用余弦或任何其他相似性来比较用户输入和嵌入文本块之间的距离。最常见的是，您将看到返回前三个最相似的文档，为LLM提供上下文，以增强其生成准确答案的能力。当向量搜索可以产生相关的文本块时，这种方法非常有效。
然而，当LLM需要来自多个文档甚至多个块的信息来生成答案时，简单的向量相似性搜索可能是不够的。
例如，考虑以下问题:
OpenAI的前员工中有谁创办了自己的公司吗?
如果你仔细想想，这个问题可以分为两个问题。
谁是OpenAI的前雇员?
他们中有人开了自己的公司吗?
回答这些类型的问题是一个多跳问答（可在文末查看什么是多跳问题）任务，其中单个问题可以分解为多个子问题，并且可能需要向LLM提供大量文档以生成准确的答案。
上述简单地将文档分块和Embeddings到数据库中，然后使用纯向量相似度搜索的工作流程可能会遇到多跳问题，原因如下:
前N个文档中的重复信息:所提供的文档不保证包含回答问题所需的补充和完整信息。例如，排名前三的类似文件可能都提到shaariq曾在OpenAI工作，并可能成立了一家公司，而完全忽略了所有其他成为创始人的前员工
缺少引用信息:根据块大小，您可能会丢失对文档中实体的引用。这可以通过块重叠部分解决。但是，也有引用指向另一个文档的例子，因此需要某种形式的共同引用解析或其他预处理。
很难定义理想的检索文档数量:有些问题需要向LLM提供更多的文档才能准确地回答问题，而在其他情况下，大量提供文档只会增加噪音(和成本)。
因此，简单的向量相似性搜索可能会遇到多跳问题。然而，我们可以采用多种策略来尝试回答需要来自不同文档的信息的多跳问题。
作为压缩信息存储的知识图谱
如果您非常关注LLM空间，那么您可能会想到使用各种技术来压缩信息，以便在查询期间更容易地访问信息。例如，您可以使用LLM提供文档摘要，然后嵌入并存储摘要而不是实际文档。使用这种方法，您可以消除大量噪声，获得更好的结果，并且不必担心prompttoken空间。
有趣的是，您可以在摄取时执行上下文摘要，也可以在查询时执行上下文摘要。查询期间的上下文压缩很有趣，因为它选择了与所提供的问题相关的上下文，因此它更具有指导性。但是，查询期间的工作负载越重，预期的用户延迟就越差。因此，建议将尽可能多的工作负载移动到摄取时间，以改善延迟并避免其他运行时问题。
同样的方法也可以应用于总结会话历史，以避免遇到token限制问题。
我还没有看到任何关于将多个文档合并和汇总为单个记录的文章。问题可能是我们需要合并和总结的文档组合太多了。因此，在摄取时处理所有文档组合的成本可能太高。
然而，知识图谱在这里也可以提供帮助。
从非结构化文本中提取实体和关系形式的结构化信息的过程已经存在了一段时间，更广为人知的是信息提取管道。将信息提取管道与知识图相结合的好处在于，您可以单独处理每个文档，并且当构建或丰富知识图时，来自不同记录的信息可以连接起来。
知识图使用节点和关系来表示数据。在这个例子中，第一份文件提供了Dario和Daniela曾经在OpenAI工作的信息，而第二份文件提供了他们的Anthropic创业公司的信息。每条记录都是单独处理的，但知识图表示将数据连接起来，并使回答跨多个文档的问题变得容易。
大多数使用大语言模型来回答我们遇到的多跳问题的新方法都侧重于在查询时解决任务。然而，我们相信许多多跳问答问题可以通过在摄取数据之前对其进行预处理并将其连接到知识图中来解决。信息提取管道可以使用大语言模型或自定义文本域模型来执行。
为了在查询时从知识图中检索信息，我们必须构造一个适当的Cypher语句。幸运的是，大语言模型非常擅长将自然语言转换为Cypher图查询语言。
在本例中，智能搜索使用LLM生成适当的Cypher语句，以便从知识图中检索相关信息。然后将相关信息传递给另一个LLM调用，该调用使用原始问题和提供的信息生成答案。在实践中，您可以使用不同的大语言模型来生成Cypher语句和答案，或者在单个LLM上使用各种prompts。
结合图形和文本数据
有时，您可能希望结合文本和图形数据来查找相关信息。例如，考虑以下问题:
关于Prosper Robotics创始人的最新消息是什么?
在本例中，您可能希望使用知识图结构识别Prosper Robotics创始人，并检索提到他们的最新文章。
要回答关于Prosper Robotics创始人的最新消息的问题，您可以从Prosper Robotics节点开始，遍历到其创始人，然后检索提到他们的最新文章。
知识图可用于表示关于实体及其关系的结构化信息，以及作为节点属性的非结构化文本。此外，您可以使用自然语言技术，如命名实体识别，将非结构化信息连接到知识图中的相关实体，如提及关系所示。
我们相信，检索增强生成应用的未来是利用结构化和非结构化信息来生成准确的答案。因此，知识图是一个完美的解决方案，因为您可以存储结构化和非结构化数据，并将它们与明确的关系连接起来，从而使信息更易于访问和查找。
当知识图谱中包含结构化和非结构化数据时，智能搜索工具可以利用Cypher查询或向量相似度搜索来检索相关信息。在某些情况下，您也可以使用两者的组合。例如，可以从Cypher查询开始识别相关文档，然后使用向量相似性搜索在这些文档中查找特定信息。
在思维链流中使用知识图谱
围绕大语言模型的另一个非常令人兴奋的发展是所谓的思维链问答，特别是LLM代理。LLM代理背后的思想是，它们可以将问题分解为多个步骤，定义计划，并使用所提供的任何工具。在大多数情况下，代理工具是api或知识库，代理可以访问它们来检索其他信息。让我们再考虑一下这个问题:
关于Prosper Robotics创始人的最新消息是什么?
假设在它们提到的文章和实体之间没有明确的联系。文章和实体甚至可以在不同的数据库中。在这种情况下，使用思维链流的LLM代理将非常有帮助。首先，agent将问题分解为子问题。
- Prosper Robotics的创始人是谁?
- 关于他们的最新消息是什么?
现在，代理可以决定使用哪个工具。假设我们为它提供一个知识图访问，它可以使用它来检索结构化信息。因此，代理可以选择从知识图谱中检索Prosper Robotics公司创始人的信息。正如我们所知，Prosper Robotics的创始人是shaariq Hashme。现在第一个问题已经回答了，代理可以将第二个子问题重写为:
- 关于Shariq Hashme的最新消息是什么?
代理可以使用任何可用的工具来回答随后的问题。这些工具的范围包括知识图、文档或矢量数据库、各种api等等。对结构化信息的访问允许LLM应用程序在需要聚合、过滤或排序的情况下执行各种分析工作流。考虑以下问题:
- 哪一家创始人一人的公司估值最高?
- 谁创办的公司最多?
纯向量相似性搜索可能难以解决这些类型的分析问题，因为它搜索的是非结构化文本数据，因此很难对数据进行排序或聚合。因此，结构化和非结构化数据的组合可能是检索增强LLM应用程序的未来。此外，正如我们所看到的，知识图也非常适合表示连接的信息，因此也适合多跳查询。
虽然思维链是大语言模型的一个引人入胜的发展，因为它显示了LLM如何进行推理，但它并不是最用户友好的，因为由于多个LLM调用，响应延迟可能很高。然而，我们仍然非常兴奋地了解更多关于将知识图合并到各种用例的思维链流中的知识。
总结
检索增强生成应用程序通常需要从多个源检索信息以生成准确的答案。虽然文本摘要可能具有挑战性，但以图形格式表示信息可以提供几个优点。
通过单独处理每个文档并将它们连接到知识图中，我们可以构建信息的结构化表示。这种方法允许更容易地遍历和导航相互连接的文档，支持多跳推理来回答复杂的查询。此外，在摄取阶段构造知识图减少了查询期间的工作负载，从而改善了延迟。
使用知识图的另一个优点是它能够存储结构化和非结构化信息。这种灵活性使其适用于广泛的语言模型(LLM)应用程序，因为它可以处理各种数据类型和实体之间的关系。图结构提供了知识的可视化表示，促进了开发人员和用户的透明性和可解释性。
总的来说，在检索增强生成应用程序中利用知识图提供了一些好处，比如提高查询效率、多跳推理能力以及对结构化和非结构化信息的支持。
附加
多跳问题（来源于《一文带你入门知识图谱多跳问答》）
通俗来说，多跳问题 (Multi-hop Questions) 指的是那些需要知识图谱 「多跳推理」 才能回答的问题。例如，若要回答 ”成龙主演电影的导演是哪些人？“ 这一问题，则需要多个三元组所形成的多跳推理路径 <成龙，主演，新警察故事>, <新警察故事，导演，陈木胜> 才能够回答。
这种类型的问题在实际应用中十分普遍，但想要构建出一个高准确率的知识图谱多跳问答系统却并非易事。下图展示了一个谷歌搜索中的 Bad Case。
