采用检索增强生成(RAG)是一种有效策略,可以确保大型语言模型(LLM)响应保持最新且不会产生幻觉。
虽然各种检索策略可以改善文档的生成调用,但没有一种通用的方法。检索流程取决于您的数据,从超参数如块大小和返回的文档数量,到检索算法如语义搜索或图形检索等。
检索策略可能有所不同,但在现代 RAG 系统中,越来越常见的做法是在检索系统上添加智能体框架。此框架可以处理对检索到的数据的推理、决策和反射。智能体是一个系统,可以使用大语言模型来推理解决问题,创建解决问题的计划,并借助一组工具执行计划。
例如,众所周知,LLMs 在解决数学问题方面表现不佳。为 LLM 提供一个计算器“工具”,它可以用来执行数学任务,同时它通过计算公司收入的同比增长来推理,这可以说是一种代理工作流。
随着生成式 AI系统开始向能够执行代理任务的实体过渡,我们需要经过训练的强大模型,这些模型能够分解任务、充当中央规划者,并具备模型和系统级安全检查的多步骤推理能力。借助 Llama 3.1 系列,Meta 推出了一套涵盖 8B、70B 和 405B 参数的语言模型,这些参数具有代理工作负载的工具调用功能。NVIDIA 与 Meta 合作,确保可以通过 NVIDIA NIMs优化部署最新的 Llama 模型。
随着 NVIDIA NeMo Retriever NIM 微服务集合的全面推出,企业现在可以访问可扩展的软件,以便定制其依赖数据的 RAG 流程。NeMo Retriever NIM 可以轻松插入现有的 RAG 流程,并与开源 LLM 框架(如 LangChain 或 LlamaIndex)接口,从而轻松地将检索模型集成到生成式 AI 应用中。
LLM 和 NIM:强大的 RAG 组合
在可定制的代理 RAG 中,能够进行函数调用而不是函数识别的 LLM 比生成最终答案的 LLM 发挥着更重要的作用。虽然 NeMo Retriever NIM 为您的检索流程带来了先进的文本嵌入和重新排名功能,但 LLM 可用于对检索数据进行高级别的决策、结构化输出生成和工具调用。
NVIDIA NeMo Retriever NIM
要创建最终工作流,可以使用一组 NeMo Retriever 微服务进行嵌入和重新排序。这些微服务可以在企业内部本地部署,并与 NVIDIA Triton 推理服务器 和 NVIDIA TensorRT 一起打包,以优化文本推理,从而实现嵌入和重新排序。其他企业优势包括:
- 可扩展部署:无论您是满足少量用户还是数百万用户的需求,NeMo Retriever 嵌入和重新排名 NIM 都可以无缝扩展以满足您的需求。
- 灵活集成:借助符合 OpenAI 标准的 API 端点,轻松将 NeMo Retriever 嵌入和重新排序 NIM 融入现有工作流程和应用,并在数据驻留的任何位置进行部署。
- 安全处理:您的数据隐私至关重要。NeMo Retriever 嵌入和重新排序 NIM 可确保所有推理都得到安全处理,并实施严格的数据保护措施。
Meta Llama 3.1 工具调用
新的 Llama 3.1 模型集可以被视为开源模型向重大代理功能的首次重大推动。这些模型现在可以成为更大的自动化系统的一部分,其中 LLM 可以规划和选择正确的工具来解决更大的问题。由于 NVIDIA Llama 3.1 NIM 拥有 OpenAI 风格工具调用的必要支持,现在可以将像 LangChain 这样的库与 NIM 一起使用,以将 LLM 绑定到 Pydantic 类并填充对象/字典。这种组合使开发者更容易从 NIM LLM 中获取结构化输出,而无需采用正则表达式解析。
如下 Langchain 工具调用 代码段所示。
class GradeDocuments(BaseModel):
"""Binary score for relevance check on retrieved documents."""
binary_score: str = Field(
description="Documents are relevant to the question, 'yes' or 'no'"
)
# LLM with function calling capability
llm = ChatOpenAI(
base_url="https://integrate.api.nvidia.com/v1",
model="meta/llama3.1-405b-instruct",
temperature=0
)
structured_llm_grader = llm.with_structured_output(GradeDocuments)
score = structured_llm_grader.invoke(
{"question": question, "document": documents}
grade = score.binary_score
使用代理的 RAG
在未进行进一步验证和自我反省的情况下检索工作流中的段落或文档可能会导致无益的响应和事实不准确。由于模型未经过明确训练,无法遵循段落中的事实,因此必须进行生成后验证,以确保响应的准确性和有用性。
为了解决这个问题,我们提出了几种 RAG 策略,如 self-RAG 和校正 RAG 等,这些策略本质上是在基准 RAG 管道之上构建代理框架。这些框架可以是多代理的,从而提供所需的额外决策能力,以提高检索数据的质量和生成的响应。
架构
借助 LangGraph 等多代理框架,开发者可以将大语言模型应用级逻辑分组到节点和边缘,以更精细地控制代理决策。使用带有 NVIDIA LangChain OSS 连接器的 LangGraph,可以对大语言模型进行嵌入、重新排序和实现必要的代理 RAG 技术 (如前所述)。
为了实现这一点,应用程序开发者必须在其 RAG 工作流之上包含更精细的决策。图 1 显示了路由器节点上的众多渲染之一,具体取决于用例。在这里,路由器在从本地搜索中检索文档或回答“我不知道”之间进行切换。
在图 2 中,我们将默认路由器替换为 Web 搜索工具,该工具会在 Web 上搜索文档,以防问题与本地存储的文档无关。
最后,可以通过在语言模型(LLM)上借助帮助重写查询来决定以不同的方式提问,这可能会更好地从检索器中进行召回,如图 3 所示。
节点规格
一些值得关注的节点和检查器,每个 RAG 工作流都可以从中受益,包括
- 查询分解器:将问题拆分为多个较小的逻辑问题,当需要从多个文档中提取部分信息来回答问题时非常有用。
- 路由器:根据本地存储的文档相关性,决定是否需要从本地检索器检索数据块,以回答给定问题。或者,可以对智能体进行编程,以执行网络搜索,或者只需回答“I don’t know”。
- Retriever:这是 RAG 工作流的内部实现。例如,语义搜索检索器和关键字搜索检索器的混合检索器。
- Grader:检查检索到的段落/块是否与当前问题相关。
- Hallucination checker:检查每个分块生成的语言模型是否与分块相关。 由于未明确训练模型以遵循段落中的事实,因此需要进行后代验证。
根据数据和用例,可以向上述示例多代理工作流程中添加其他节点和工具。例如,金融服务 copilot 可能需要一个计算工具与查询分解工具一起使用,以准确回答有关趋势、百分比增长或同比增长的问题。最终,开发者的图构建最终决定取决于准确性、吞吐量和成本要求。
入门指南
NeMo Retriever 嵌入 和重新排序 NIM 微服务现已推出。 开发者可以下载和部署 docker 容器,并在 ai.nvidia.com 上查找 Llama 3.1 NIM。查看我们的开发者 Jupyter notebook,了解在 GitHub 上逐步实现代理 RAG 的信息。