大型语言模型的检索插桩生成（RIG）：它是啥，又是如何工作的？

检索交织生成技术（RIG）是一种技术，旨在让大型语言模型（LLMs）“知道何时查询”通过将结构化的外部数据整合到其回应中。与仅依赖其内部知识的标准大型语言模型（LLM）不同，RIG动态地将从一个受信任的存储库（如Data Commons）检索到的数据交织在一起。这使RIG能够使用实时信息提高答案的准确性，而不是仅仅依赖于其参数中的存储内容。

来源链接: https://docs.datacommons.org/papers/DataGemma-FullPaper.pdf

RIG通过一系列相互关联的步骤运作，这些步骤优化数据检索并实现无缝集成。

确认外部数据的需求

• 过程始于训练大语言模型（LLM）以识别需要超出其内部知识的查询。这一步确保了LLM能够区分出哪些查询只需要一般对话知识，哪些查询则需要精确的数据支持。

提出一个自然语言询问

• 一旦识别了对外部数据的需求，模型会生成一个自然语言查询，表达它想要找到的具体信息（例如，“2020年加州的失业率是多少？”）。该自然语言查询旨在与_数据commons_交互——这是一个包含来自联合国和CDC等公共来源的数十亿个结构化数据点的全面存储库。

从数据 commons 平台获取并整合数据

• 生成的查询通过标准API调用传递给数据公共，以检索相关数据。这种做法借鉴了使用通用API的概念，该API可以适应各种查询类型，使大语言模型（LLM）在处理各种数据集时无需了解每个数据源的详细信息。
• 例如，如果模型被问到“2020年加州的人口是多少？”，模型将查询发送到数据公共，找到准确的答案，然后将其整合到回答中，例如：
  “根据数据公共，2020年加州的人口约为3900万。”

提供一个确认的答案

• 大型语言模型（LLM）随后将检索到的数据整合到其自然语言回复中，提供一个无缝且由实时数据支持的答案。这一过程减少了幻觉，并通过基于事实来增强了模型输出的可信度。

为了启用RIG将外部数据交织进其响应中的独特能力，底层的大型语言模型需要通过一个专门的微调过程来进行微调。这个微调过程使用指令-响应对和合成数据来训练模型，何时以及如何触发检索请求。《DataGemma》论文中描述了微调过程的三个关键组成部分。

创建一个包含指令和响应的数据集

过程始于一个包含各种统计问题的用户查询数据集。这些查询被用来通过基础模型生成包含统计信息的响应。然后将这些响应传递给一个更高级的LLM，即Gemini 1.5 Pro，通过一系列提示来在相关统计数据点周围插入自然语言的Data Commons查询。每个提示都包含一些示范示例来展示格式，确保仅对数值及其适用的单位进行Data Commons引用标注。

以下是示例提示，用于生成这种带注释的问题回答对，以进行精细化调整，来自 Google 的 DataGemma 论文：

在提示一个示例响应时：
问题：“告诉我关于加州、旧金山、阿拉巴马州和美国的一个统计数据。”
回答：“加州是全美人口最多的州，人口约为 [DC(‘2020年加州的人口是多少？’) → ‘约3900万’]。”
在这个示例中，使用了占位符 __DC__ 来标注应插入自然语言查询以检索事实的位置。

错误的回答会被手动标记或修改，以查询Data Commons中的所需事实信息。

将自然语言查询加入到模型的响应中

这个注释过的数据集然后用来微调LLM，来识别数据缺口，并用结构化的查询回应，而不是生成不支持的说法。

例如，模型被训练生成这样的短语：“2019年法国的GDP是_DC_ → ‘2.8万亿美元’”，其中问题与答案交织在一起。这使模型能够在不打断文本流畅性的前提下，自然地表达需要外部数据。

查询转换及实现

• 生成自然语言查询后，RIG 微调管道流程将其转换为可以对 Data Commons API 执行的结构化查询。此转换涉及将自然语言请求分解成关键组件（例如变量名称、位置和日期），并将它们对应到 Data Commons 中的相应 ID。
• 结构化查询随后由 Data Commons API 完成，返回一个与 LLM 最终输出无缝结合的相关统计。这种方法使得 LLM 可以处理数百万个变量和属性，而无需对每个特定的数据模式有直接了解。

这种微调策略使RIG能够针对具体的问题提供精准的数据回答，同时保持与标准语言模型一样的流畅和连贯。最终结果是一个语言模型，能够有效地将内部语言生成与外部数据检索结合起来，提供既自然又基于事实的回复。

Google已在HuggingFace上发布了其微调的模型。

链接:https://huggingface.co/collections/google/datagemma-release-66df7636084d2b150a4e6643

RIG的优点 ：

• 能够非常适合进行有针对性的事实查询，提供精确的统计响应。
• 生成简洁、自然语言的查询，便于与数据 commons 集成。
• 与 RAG 相比，由于结构更简单，运行速度更快且资源消耗更少，因此更适合使用。

RIG 的弱点：

• 由于数据可用性限制以及复杂的多步推理查询带来的困难。
• 由于统计范围狭窄，数据覆盖面较窄。

数据集成机制：

• RIG：直接将检索到的统计信息交织到生成的响应中。
• RAG：获取大量相关数据，并用它来增强模型的输入，从而影响整个生成过程。

效率:

• RIG ：在处理目标查询（如单一统计或特定事实）时非常高效。
• RAG ：更适合复杂的多步骤查询（如多文档总结或跨多个维度的比较）。

准确性和可靠性:

• RIG ：通过将生成的数据直接与结构化的信息库对齐来提高准确性。
• RAG ：如果检索的数据不相关或过于广泛，就更容易出错。

复杂程度：

• RIG ：由于它处理的是简单的数据检索，因此更容易实现和调整。
• RAG ：需要更复杂的查询解析和更长的上下文范围来处理大量输入数据。

来自 DataGemma 论文的 RIG 与 RAG 的性能对比

一. 事实的准确性

• RIG ：在7B模型上达到57.7%，在27B模型上达到58.8%的事实准确性，显著提高了与基线准确率4.9%和16.7%相比的表现
• RAG ：统计声明的高准确率（9B模型为98.6%，27B模型为98.9%），但在复杂推理上的准确率则分别下降到71.9%和76.4%

2. 数据覆盖范围:

• RIG：由于数据不完整和查询范围较局限，覆盖率只能达到23–24%。
• RAG：稍微好一点，覆盖率为24–29%，但仍受到Data Commons中数据的缺口的影响。

三. 用户喜好

• RIG：相比于基线模型，在62%（针对7B模型）和76%（针对27B模型）的情况下更受欢迎。
• RAG：当成功集成了统计表时，显示出极强的偏好（92–100%）。

何时用RIG

• 适用于事实核查和特定数值查询，比如“2019年法国的GDP是多少？”。
• 在LLM需要提供基于可靠数据点的精确答案的情境下。
• 对于输入大小有限制且延迟要求极低的应用场景，其中快速事实检索显得尤为重要。

使用RAG的场景：

• 对于需要整合多个来源的广泛的查询，例如“比较欧盟各国的卫生统计数据。”
• 当大语言模型需要应对多文档处理或复杂推理时。

• 数据可用性：RIG 严重依赖于像 Data Commons 这样稳健、结构化的数据源。如果所需的数据显示不可用或不及时，RIG 的有效性会降低。
• 上下文限制：由于 RIG 处理数据时一次处理一个查询，它在处理复杂的多跳推理方面可能会遇到困难，而 RAG 在这方面更擅长。
• 训练复杂性：尽管 RIG 的执行比 RAG 更简单，但将模型调整到能识别何时触发数据查询仍然是一项正在进行中的挑战。

混合方法： 结合RIG和RAG的优势，可以创建一个更强大的模型，使用RIG用来进行精确的数据注入和RAG用来进行复杂且富含上下文的检索，既保证了准确性，又提供了全面的覆盖范围。

增强用户界面：未来的改进应专注于设计能够清楚地区分模型生成内容和已验证数据的界面，确保更透明、更可信的人机交互。

检索交错生成（RIG）和检索增强生成（RAG）各自在通过整合现实世界的数据使语言模型更加可靠方面提供了独特的优势。虽然RIG在提供针对特定查询的精确、经过事实核查的回复方面更为出色，但RAG更适合处理复杂且多方面的问題，这些问題需要全面的背景信息。因此，结合这两种方法可能为混合模型铺平道路，这些模型既能保证准确性又能提供深度的内容，最终改变AI系统如何与数据互动的方式。随着这些技术的发展和进步，构建透明的接口，区分由模型生成的内容和数据驱动的内容将对建立AI应用程序的信任和易用性至关重要。

1. https://docs.datacommons.org/papers/DataGemma-FullPaper.pdf
2. https://research.google/blog/grounding-ai-in-reality-with-a-little-help-from-data-commons/
3. https://blog.google/technology/ai/google-data-commons-ai/