改进 RAG 中的“R”并在 Azure SQL 中采用 Agentic RAG
Posted: Sat Jan 25, 2025 9:12 am
如今人们普遍讨论的 RAG（检索增强生成）模式基于这样一个基本思想：检索部分使用向量搜索完成。这确保返回所有与回答给定问题最相关的信息，然后将其输入到 LLM 以生成最终答案。
虽然向量搜索非常适合其特定用例——语义搜索，其本质上是近似的——但在搜索精确的问题时它会失败，比如“向我显示最新的 10 个代码示例”，因为该请求可以——也应该——在不需要向量搜索的情况下得到精确的回答。
用户越来越习惯于每天与人工智能打交道。他们也开始期望人工智能能够“理解”什么时候语义答案最合适，或者什么时候精确搜索才是正确的方法。为了实现这一点，RAG 需要改进。让我们看看一个可以立即实施的选项。
混合（或 Agentic）RAG
这个想法是为了改进检索部分，使其不仅限于向量搜索。我一直将这种技术称为“混合 RAG”，但由于 AI 代理正变得越来越流行和普遍，您可能只想将其放入“Agentic RAG”存储桶中，正如您将在下一段中了解到的那样。除了名称之外，为了展示该技术，我将使用我创建的示例演示，该演示允许您使用我们去年创建的 SQL 和 AI 搜索示例。立即尝试一下，要求我整理的网站向您展示我们迄今为止创建的与 Agentic RAG 相关的所有示例。您可以要求需要语义搜索的内容：
或者像“显示最近创建的 5 个样本”这样精确的问题，AI 模型就会找出最佳的回答方式。然后，它会返回一个示例列表以及返回这些示例的原因说明。
制定最佳方案
需要进行的第一个改进是让 RAG 模式确定问题是否需要语义搜索，或者常规 SQL 查询是否就足够了。为此，需要像 GPT 这样的 LLM 模型，因为它将充当整个模式的协调器。必须向它提供有关数据库模式是什么以及其中有哪些类型的数据的信息，以便它能够确定这是否足以回答问题，或者它是否需要运行语义搜索。这是我为上述网站使用的提示：
如果无法使用给定的模式提供答案，则初始 AI 调 人力资源总监电子邮件列表 用的结果要么是 SQL 查询，要么什么都没有。模式被刻意限制，以确保只能生成非常精确、完全符合给定模式的问题。如果问题需要查看示例描述、注释或属性，则不应使用 SQL 查询来回答，而应使用语义搜索来回答，以提供更好的搜索体验。
为了便于理解结果是否是 SQL 查询，我使用了可以返回 结构化输出的ai AI 模型，这样结果就是众所周知且定义明确的 JSON，可以轻松解析要执行的 SQL 查询。请求的 JSON 具有以下模式和说明：
样本描述、注释和详细信息的嵌入分别存储在各自的表中，然后使用least运算符获取最接近的匹配。结果现在可以再次发送到 GPT 模型，用于 RAG 模式的“增强生成”部分。
...或使用生成的 SQL 查询进行检索
如果编排器返回了 SQL 查询，则只需执行它并以 JSON 格式返回结果，以便可以轻松地将其传递给 LLM，LLM 将负责 RAG 模式的“Augemented-Generation”部分。
当然，为了安全起见，最好确保生成的查询 只包含一个 select 语句而不包含其他任何内容。为了获得更好的安全性，可以使用非常有限的用户执行生成的 SQL 查询，这样即使查询文本中包含恶意内容，也不会造成任何损害。请务必检查以下安全功能：
提示中引用的样本以 JSON 格式附加，LLM 现在可以很好地理解它。为了更轻松地使用代码处理 LLM 响应，再次需要结构化输出，以便结果可以与数据库中的数据重新连接并生成最终结果集：
为了避免超支，添加了一层语义缓存，这样就可以回答类似的问题而无需进行 LLM 调用。最终的工作流程如下：
图像混合抹布完成
尝试一下！。此外，完整的源代码也可用。请记住，整个示例几乎对所有内容都使用免费套餐，因此如果并发请求过多，您可能会受到限制。您将收到 500 错误。只需重试，或在您的订阅中部署所有内容，这样您就不必与任何其他人共享资源，您受到限制的可能性就会大大降低。
未来的改进
可以对示例进行一些明显的改进。我们有意将其保持简单，以作为起点，而不是全面的、可用于生产的解决方案。我们的目标是为您提供快速入门，让您可以将相同的概念应用于您自己的数据。
第一个改进是使用 Semantic Kernel 之类的编排框架，这样您就不必在 T-SQL 中完成所有操作。这将为您提供更多选项和灵活性，但也会使您的解决方案变得更加复杂，并且不太容易应用于现有应用程序。“Ultimate Chabot”示例中描述并展示了您可以获得的示例（请务必阅读生成的描述以找到博客文章和相关视频的链接！）
第二个改进是尝试教 LLM 模型如何生成嵌入并使用新的向量函数，这样理论上所有问题都可以使用 NL2SQL 来回答。通过这种方法，LLM 模型将自主使用以 AI 为中心的功能，例如新的 VECTOR_DISTANCE 函数来执行相似性搜索 并同时应用谓词。这将使解决方案能够回答诸如“返回 2025 年已发布的混合 RAG 上的所有样本”之类的问题，而这些问题今天可以通过类似这样的查询来解决
如今，您可以使用 Semantic Kernel 之类的框架轻松获得这样的结果；如果 T-SQL 中提供所有功能，那就太好了。这将大大简化解决方案和架构。
结论
总之，RAG 模式演变为我们现在所说的“混合 RAG”或“Agentic RAG”，代表了我们处理信息检索和生成方式的重大进步。通过集成向量搜索和精确 SQL 查询，我们可以确保用户收到最准确、最相关的查询答案。这种方法不仅增强了用户体验，还为 AI 驱动的搜索和检索系统树立了新标准。
实施 GPT 模型等编排器来确定适当的检索方法是一项关键创新。它允许系统智能地决定是否需要语义搜索或精确的 SQL 查询，从而优化检索过程。此外，结构化输出和语义缓存的使用进一步提高了系统的效率和可靠性。
随着人工智能的不断发展，RAG 模式进一步改进的潜力巨大。通过利用语义内核等框架并探索生成嵌入的新方法，我们可以突破人工智能驱动的搜索和检索的极限。增强 RAG 的旅程才刚刚开始，未来充满令人兴奋的可能性，让人工智能变得更加直观和强大。
虽然向量搜索非常适合其特定用例——语义搜索，其本质上是近似的——但在搜索精确的问题时它会失败，比如“向我显示最新的 10 个代码示例”，因为该请求可以——也应该——在不需要向量搜索的情况下得到精确的回答。
用户越来越习惯于每天与人工智能打交道。他们也开始期望人工智能能够“理解”什么时候语义答案最合适，或者什么时候精确搜索才是正确的方法。为了实现这一点，RAG 需要改进。让我们看看一个可以立即实施的选项。
混合（或 Agentic）RAG
这个想法是为了改进检索部分，使其不仅限于向量搜索。我一直将这种技术称为“混合 RAG”，但由于 AI 代理正变得越来越流行和普遍，您可能只想将其放入“Agentic RAG”存储桶中，正如您将在下一段中了解到的那样。除了名称之外，为了展示该技术，我将使用我创建的示例演示，该演示允许您使用我们去年创建的 SQL 和 AI 搜索示例。立即尝试一下，要求我整理的网站向您展示我们迄今为止创建的与 Agentic RAG 相关的所有示例。您可以要求需要语义搜索的内容：
或者像“显示最近创建的 5 个样本”这样精确的问题，AI 模型就会找出最佳的回答方式。然后，它会返回一个示例列表以及返回这些示例的原因说明。
制定最佳方案
需要进行的第一个改进是让 RAG 模式确定问题是否需要语义搜索，或者常规 SQL 查询是否就足够了。为此，需要像 GPT 这样的 LLM 模型，因为它将充当整个模式的协调器。必须向它提供有关数据库模式是什么以及其中有哪些类型的数据的信息，以便它能够确定这是否足以回答问题，或者它是否需要运行语义搜索。这是我为上述网站使用的提示：
如果无法使用给定的模式提供答案，则初始 AI 调 人力资源总监电子邮件列表 用的结果要么是 SQL 查询，要么什么都没有。模式被刻意限制，以确保只能生成非常精确、完全符合给定模式的问题。如果问题需要查看示例描述、注释或属性，则不应使用 SQL 查询来回答，而应使用语义搜索来回答，以提供更好的搜索体验。
为了便于理解结果是否是 SQL 查询，我使用了可以返回 结构化输出的ai AI 模型，这样结果就是众所周知且定义明确的 JSON，可以轻松解析要执行的 SQL 查询。请求的 JSON 具有以下模式和说明：
样本描述、注释和详细信息的嵌入分别存储在各自的表中，然后使用least运算符获取最接近的匹配。结果现在可以再次发送到 GPT 模型，用于 RAG 模式的“增强生成”部分。
...或使用生成的 SQL 查询进行检索
如果编排器返回了 SQL 查询，则只需执行它并以 JSON 格式返回结果，以便可以轻松地将其传递给 LLM，LLM 将负责 RAG 模式的“Augemented-Generation”部分。
当然，为了安全起见，最好确保生成的查询 只包含一个 select 语句而不包含其他任何内容。为了获得更好的安全性，可以使用非常有限的用户执行生成的 SQL 查询，这样即使查询文本中包含恶意内容，也不会造成任何损害。请务必检查以下安全功能：
提示中引用的样本以 JSON 格式附加，LLM 现在可以很好地理解它。为了更轻松地使用代码处理 LLM 响应，再次需要结构化输出，以便结果可以与数据库中的数据重新连接并生成最终结果集：
为了避免超支，添加了一层语义缓存，这样就可以回答类似的问题而无需进行 LLM 调用。最终的工作流程如下：
图像混合抹布完成
尝试一下！。此外，完整的源代码也可用。请记住，整个示例几乎对所有内容都使用免费套餐，因此如果并发请求过多，您可能会受到限制。您将收到 500 错误。只需重试，或在您的订阅中部署所有内容，这样您就不必与任何其他人共享资源，您受到限制的可能性就会大大降低。
未来的改进
可以对示例进行一些明显的改进。我们有意将其保持简单，以作为起点，而不是全面的、可用于生产的解决方案。我们的目标是为您提供快速入门，让您可以将相同的概念应用于您自己的数据。
第一个改进是使用 Semantic Kernel 之类的编排框架，这样您就不必在 T-SQL 中完成所有操作。这将为您提供更多选项和灵活性，但也会使您的解决方案变得更加复杂，并且不太容易应用于现有应用程序。“Ultimate Chabot”示例中描述并展示了您可以获得的示例（请务必阅读生成的描述以找到博客文章和相关视频的链接！）
第二个改进是尝试教 LLM 模型如何生成嵌入并使用新的向量函数，这样理论上所有问题都可以使用 NL2SQL 来回答。通过这种方法，LLM 模型将自主使用以 AI 为中心的功能，例如新的 VECTOR_DISTANCE 函数来执行相似性搜索 并同时应用谓词。这将使解决方案能够回答诸如“返回 2025 年已发布的混合 RAG 上的所有样本”之类的问题，而这些问题今天可以通过类似这样的查询来解决
如今，您可以使用 Semantic Kernel 之类的框架轻松获得这样的结果；如果 T-SQL 中提供所有功能，那就太好了。这将大大简化解决方案和架构。
结论
总之，RAG 模式演变为我们现在所说的“混合 RAG”或“Agentic RAG”，代表了我们处理信息检索和生成方式的重大进步。通过集成向量搜索和精确 SQL 查询，我们可以确保用户收到最准确、最相关的查询答案。这种方法不仅增强了用户体验，还为 AI 驱动的搜索和检索系统树立了新标准。
实施 GPT 模型等编排器来确定适当的检索方法是一项关键创新。它允许系统智能地决定是否需要语义搜索或精确的 SQL 查询，从而优化检索过程。此外，结构化输出和语义缓存的使用进一步提高了系统的效率和可靠性。
随着人工智能的不断发展，RAG 模式进一步改进的潜力巨大。通过利用语义内核等框架并探索生成嵌入的新方法，我们可以突破人工智能驱动的搜索和检索的极限。增强 RAG 的旅程才刚刚开始，未来充满令人兴奋的可能性，让人工智能变得更加直观和强大。