我们的人工智能存在结构性问题。虽然 LLM 和人工智能系统越来越好，但有一个问题仍然特别突出，那就是上下文注入。

上下文可以来自：

• 文档（静态数字化知识库）
• 专家反馈（动态和当前的非数字化隐含知识）

如今，纯矢量 RAG 系统的实施是一条 “单行道”。常见的实施模式是在矢量数据库的基础上建立一个多代理系统，这样自然语言查询就能检索到正确的信息，供 LLM 构建答案。这些数据通常来自文档和数据库，可以告诉我们数据是什么，但不能告诉我们应该如何使用这些数据。例如，如果我们发现知识库中包含一个过时的事实，即 “该手册只能用于亚洲的客户”，那么矢量 RAG 系统就无法像人类那样轻松地考虑这些信息或专家知识。

这种围绕专家知识基础的问题空间正是我们正在构建的。RAG 只是 KG 的起点。模式的意义在于，它在 LLM 和人类专家如何解释数据之间架起了桥梁。这样，我们就可以创建 “双向 ”RAG 系统，让你的企业能够捕捉和存储专家关于如何解释和使用信息的反馈。

KG RAG 系统可以是双向的，人类可以使用自然语言直接为 KG 记忆做出贡献，而矢量 RAG 系统则无法做到这一点，因为矢量 RAG 系统可以被视为单向检索系统。矢量系统中的 “记忆 ”只是为检索添加额外的嵌入，而不会以任何方式影响现有嵌入的意义和状态。图的可读性也是一个额外的好处。

我们希望映射隐含知识，而不是任意映射，而是将专家反馈与现有知识库联系起来。换句话说，专家反馈总是与你正在使用的上下文和知识库联系在一起。因此，只有当你能够轻松获取专家反馈，并系统地将其与上下文联系起来，而不是简单地将其扔到知识库中，使其无法在适当的时候可靠地检索出来，专家反馈的价值才会得以体现。

为了确保我们能够将专家反馈系统地与知识库联系起来，我们需要确保专家使用的语言能够系统地与 LLM 在内存中解释和存储数据的方式联系起来。

模式作为一种结构媒介，可以让 LLM 和专家 “说 ”同一种精确的语言，因此非常重要。模式是精确的表征，有助于将反馈信息导向应存储反馈信息的特定知识。

例如，在围绕制造手册的 RAG 系统中，我们可以想象，从静态文档中存储的数字知识与物理系统的实际工作情况之间可能存在脱节。能够通过人为反馈实时捕捉这种差异非常重要。模式有助于确定模式应如何影响知识库。

因此，这些 RAG 系统不仅本身有价值，还可以作为与员工互动的途径，收集最新信息和员工对如何利用这些信息的启发式意见。

上面的示例展示了如何从多个维度向知识图谱 RAG 系统提供反馈：

• 能够修改现有图表，添加流程中缺失的步骤
• 能够删除文档图表中的关系，该关系映射了文档与特定场景的相关性
• 能够创建和修改反映特定用户背景的个性化图表

虽然我们有办法通过微调来改变和调整嵌入，但依赖 RAG 的应用场景对知识库的实时性非常敏感。当我们在构建一个 RAG 系统而不是一个模型时，我们就已经做出了这样的决定：根据动态数据集进行微调不值得付出努力/回报。

因此，与其在静态知识库（前 LLM）和微调模型（针对动态数据集既昂贵又困难）之间采用二元方法，不如采用第三种方案，即在专家、矢量嵌入和 LLM 之间创建一个中间语义层，让专家反馈能够智能地修正位于矢量嵌入和 LLM 之间的知识图谱表示。

这不是一件只能从头开始做的事情。我们并不是说每个系统都必须有一个图，或者说我们需要一个在引入反馈之前就必须完全定义的模式（尽管这是最理想的设置）。这种模式可以通过多种方式反复建立。例如，我们可以从矢量数据库和稀疏模式（即文档图）开始，然后根据需要建立更精细的模式。我们还可以根据问题、答案和反馈反复建立模式。这个过程包括使用 LLM 来构建模式，以存储相关问题、答案和反馈，初始信息来自向量 RAG。