知识表格——多文档检索与提取（提取和记忆）

多文档提取和检索确实很难。将信息以结构化方式映射以便检索比听起来更难。构建针对多文档的RAG系统很困难，尤其是当你希望LLM能提供细节丰富的答案而不是仅仅一个总体摘要时。我们希望开源一个内部使用的基于表格的多文档提取和图创建工具，它可以帮助更好地处理和展示信息。

在这里，我们要推出以下内容：

1. 知识表的开源仓库
2. 有限演示，基于WhyHow平台，增加了额外的查询和记忆特性（这可以看作是托管版本知识表的产品路线图）

你应该使用知识表格，如果你对高效地从大量文档中提取、存储和查询信息感兴趣，不论是作为业务用户还是RAG开发者。我们发现，对于开发者来说，在你的后端RAG系统中插入一个用于构建图的表格中间步骤，能够显著提高所生成图的准确性。我们提供的是知识表格和WhyHow平台。

1. 多文档准确性提升：在浏览器环境下，多文档检索的准确性是ChatGPT 4o的2.5倍，比Text2Cypher高出两倍，并且优于GraphRAG。
2. 基于规则的提取保障：通过提取规则和类型，实现对开源多文档提取过程的精细控制。
3. 基于本体的查询引擎：一个直观的查询引擎，允许用户直接在查询时调用特定工具和列，从而实现结构化和非结构化检索的无缝结合。

表格有几个用处：

1. 对于企业用户，这是一种从大量文档中轻松提取结构化信息的方法。
2. 对于开发人员，在知识图谱RAG系统中的一个中间环节，解析一系列规则和本体控制的实体类型值，这些值可以被转换成图，形成图谱。

将代理与表格结合使用的做法并不新鲜，这种做法至少已经有一年的时间了，我们大多数人肯定都尝试过将LLM与表格结合使用。然而，新的地方在于将多文档RAG流程中的基于表格的提取，不仅用于前端体验，还作为后端流程的一部分，帮助创建可以在RAG系统中轻松查询的结构化表示形式。

你使用的词语和数据结构之间应该存在直接关系。表格中的这些术语也充当了可以直接在查询界面互动的字段——看看查询中的“平均”、“剂量”和“病症”这些字段是如何明确地供用户选择的。

控制提取的内容很重要，因为你知道文档中某些信息的情况，希望能提供更多上下文以优化提取过程。

我们目前的规则及即将添加的规则如下：

必须归还的:

• 这里的答案必须与用户提供的值列表相匹配。
• 例如，在医疗应用场景示例中，你可能已经有了一个罕见疾病名称的清单，希望加载并从中提取信息。给定的列表是完整的，包含所有内容，返回的内容应仅限于列表中的项目。

可以退货:

• 这里你可以提供一些例子来帮助LLM更好地从少量样本中提取信息。给出的列表并不全面，LLM也可能找到列表之外的例子。

允许回复次数:

• 这里是指你预期会收到的回答数量。比如，一个人被分配的ID数量。限制回答的数量会更方便，有助于减少可能出现的错误。

因为这个包是开源的，您可以提供其他类型的提取规则并将其加入仓库，或者在您自己的系统中运行时，调整提取过程以适应您的数据和流程，。

你可以选择将提取过程串联起来，使得前一列的输出值定义并影响后续列的提取过程。例如，首先从文档中提取所有提到的疾病，然后在后续的列中将所需的药物进行匹配。为了在问题字段中引用另一列，你只需标记需要引用的列名，如 @diseases，即 @疾病。

如果你选择“文本列表项”或“数字列表项”，你就可以将包含多个值的单元格拆分成多行，每行只有一个值，这样你就可以更轻松地进行连续提取操作。

在RAG流程中，能够追踪提取的信息到最初的向量信息块是至关重要。对于每个单元，可以查看答案来源的那些信息块。这提供了可审计性保障，并且可以快速参考以在必要时帮助验证LLM的响应。

这也是RAG系统中的一个关键步骤，需要访问底层片段来帮助构建用户最终收到的答案。

向量片段与生成的答案挂钩，确保全程可追溯。

每个提取的答案还可以存储在内存中作为进一步的元数据过滤器，用于未来文档的选择。例如，假设一列中的一个问题为“这份文档是否提到我的名字？”，实体类型为“人名提及”。现在，“人名提及”可以作为筛选文档的过滤器。

通过这种方式，知识表的过程不仅是为了回答问题，还为了生成元数据。因为你现在可以将提取的数据链接到向量片段或文档，这些元数据有助于筛选合适的文档来回答请求。

记忆功能和CSV文件下载：

你可以将你的信息以CSV格式或图三元组（每个三元组都链接到了相应的片段）的形式提取。图三元组就像对事实的结构化描述。这样你就可以合并这些三元组，并进行查询。

相较于CSV，以图数据三元组的形式导出的优势在于能够自动整合和查询您的信息。

为了能够查询知识表格，我们将表格中的信息转换成结构化的三元组。这使我们可以轻松地对表格进行自然语言查询，并能够进行的不仅仅是SQL查询的简单翻译，而是直接在每个单元格的基础上执行向量搜索操作，并能保持该单元格与其邻近单元格间的语义联系。

您可以将 CSV 和 Graph Triples 导出到您自己的平台处理，或者将其无缝集成至 WhyHow 平台。对于我们的 Beta 用户，如果您能访问我们的平台，请查阅相关文档，以允许您从 Knowledge Table 无缝导入和查询三元组至 WhyHow 平台。

更多详情请参阅此链接，了解如何将知识表导出的数据点转换成WhyHow平台上的图表。

我们发现，在多个文档上进行并行提取，并通过多次LLM调用，可以显著提高多文档提取的准确性。当这些提取操作以表格形式运行并在内存中以图的形式保存时，输出的准确性有了显著提高。为了证明这一点，我们对以下流程进行了基准测试，以证明知识表格可以显著提高提取和查询的准确性。在这个测试中，我们上传了大约20篇医疗学术论文，并对这些论文提出了几个基于提取的问题。

• X来源的疗法主要针对哪些类型的疾病？
• X来源的疗法中提取了哪些蛋白质？
• X公司是否资助了这些研究项目？

我们对RAGAS进行了以下几种不同的操作：

• 模块化图表及知识表的为什么和如何
• Microsoft 图表 RAG
• 向量 RAG 检索
• ChatGPT 4.0（浏览器内）
• Langchain LLMGraphTransformer 与 WhyHow 的查询引擎
• Langchain LLMGraphTransformer 与 Text2Cypher（文本到 Cypher 查询语言转换）

总体而言，我们发现性能上有很大的差异。令人惊讶的是，通过网络浏览器访问的ChatGPT 4未能处理这么多的上下文，尽管它的系统内置了多代理框架。它只对部分文档进行了详细回复，这表明它可能只检索了部分文档。向量检索也同样难以给出精确的答案，更倾向于给出宽泛的答复。

Langchain的图创建包LLMGraphTransformer表现得更好，因为图创建步骤必然将实体提取作为中间步骤。因此，相关疾病和蛋白质在搜索空间中更加突出。然而，图构建创建了一个庞大且不聚焦的图结构，难以从中检索信息。结果是，虽然相比纯向量搜索有所改进，但仍显不足之处。

从这些数据中有一个有趣的地方是我们比较了同一个Langchain图谱放入WhyHow中，然后利用WhyHow的查询引擎进行对比，与使用Text2Cypher的效果相比。尽管使用了相同的图，WhyHow的查询引擎在检索过程中的表现更佳，这可能是因为自然语言查询转换为结构化查询语言时存在结构上的挑战。Text2SQL同样遇到了类似的问题（据称，Text2SQL的初始准确率为20%），这说明这不仅仅是Cypher的问题。

这种准确性提升的原因是我们通过知识表格实现了提取过程的并行化。大语言模型能够更专注于每个文档的具体内容，我们能够确保更准确和全面的提取过程。

在WhyHow平台上查询时，若想引用特定实体类型，系统将帮助您自动填充并高亮显示与系统内部本体相匹配的术语，这些术语是由您在知识表或图中定义的实体类型所对应的。

这允许用户提高查询的准确性，并保持提取的一致性和相关性。例如，在查询中输入自动补全的“疾病”，这会指引大语言模型将它视作“疾病”这一实体类型/列。可以使用“@”来调用特定的实体类型/列，使用“#”来调用特定的工具，比如计算器等工具，以帮助生成答案。我们计划在路线图上逐步增加一系列结构化的比较和匹配工具——例如“比较”或“计算关系”等。

通过这种独特组合可以回答的一些特定问题包括，而这些问题使用像Text2SQL这样的系统很难轻易回答。

• “那个文档包含了与'Bout'押韵的@disease吗？”
• “与'Petformen'押韵的@disease的平均#剂量是多少？”

查询和记忆不包含在开源包中，而上面的视频演示了它如何与WhyHow的记忆和检索平台结合使用，以融入RAG工作流。

WhyHow.AI的知识图谱工作室平台（KG Studio）（目前处于测试版（Beta））是构建模块化、代理型知识图谱的最简单方法，该平台结合大型语言模型（LLM）、开发人员和非技术领域专家的工作流程。

如果你正在考虑、进行中或已经将知识图谱纳入到RAG中以增强准确性、记忆和可预测性，欢迎通过团队邮箱team@whyhow.ai与我们交流，或者在WhyHow.AI订阅我们的邮件通讯。你也可以加入我们的Discord社区讨论，讨论规则、可预测性和RAG中的知识图谱。