RAG与agent

为了更好地展示结构化数据来RAG的方法的实际效果，我们以餐饮生活助手为例，给出用户提问和回复的示例，以及餐饮生活助手RAG的代码实战。餐饮生活助手是一个基于结构化数据RAG的方法的应用，它的目的是根据用户的需求，从一个大规模的餐饮数据集中检索出最合适的餐厅，并提供相关的信息和服务。餐饮数据集是一个结构化的数据集，它包含了各种各样的餐厅的信息，例如名称、类型、地址、电话、价格、评分、评论等。餐饮生活助手的核心是一个LLM，它能够根据用户的问题，提取出核心的信息和条件，并形成标准的查询语句，然后用这个查询语句去检索餐饮数据集，得到相关的数据记录，再根据这些数据记录，生成最合适的答案，输出给用户。为了实现餐饮生活助手RAG的Langchain代码实战，我们需要完成以下几个步骤：定义餐饮数据源。我们需要将餐饮数据集转化为Langchain可以识别和操作的数据源，例如数据库、文件、API等，注册到Langchain中，并提供统一的接口和方法，让LLM的代理可以方便地访问和查询数据源。例如，我们可以将餐饮数据封装为一个API后，并结构化描述该接口的调用方式，并通过以下的代码，将其注册到Langchain中：定义LLM的代理。我们需要定义一个LLM的代理，它可以根据用户的问题，提取出核心的信息和条件，并形成标准的查询语句，然后用这个查询语句去检索餐饮数据源，得到相关的数据记录，再根据这些数据记录，生成最合适的答案，输出给用户。这可以通过Langchain的代理（Agent）来实现。代理管理器可以让开发者通过简单的编程，定义不同的LLM的代理，以及它们的功能和逻辑，并提供统一的接口和方法，让用户可以方便地与LLM的代理进行交互。

其实只要看过官方文档的应该都能知道，大模型请求中，最大的两个变量：Messages和Tools。Messages里面放的是sys prompt，memory，user query；Tools里面放的是一些能力的Json Scheme；而这两者组合在一起，就形成整个完全的Prompt。所以Agent应用开发的本质是什么？动态Prompt拼接。通过工程化的手段，不断把业务需求转述成新的prompt。短期记忆：messages里的历史QA对；长期记忆：summary之后的本文，再塞回system prompt；RAG是啥？向量相似性检索，然后放在system prompt里或者通过tools触发检索Action：触发tool_calls标记，进入请求循环，拿模型生成的请求参数进行API request，再把结果返回给大模型进行交互；没有tool_calls标记了，循环结束。对应页面上就是对话一轮对话结束。Multi Agents是啥？把system prompt和tools换一换，A就变成B了。还有啥？没了呀，本质就是这些东西。当然，这也就是最基本的原理，想做深，做好，肯定还有很多坑需要踩。

agent算是从年前到现在，比较火的一个概念了，也被很多人认为是大模型的未来的一个主要发展方向。首先我们看这个很经典的一张图看起来还是蛮复杂的，然后市面上的很多描述agent的文章写的也比较复杂，说智能体是啥智能的最小单元，相较于copilot，是可以给他设定一个目标后主动完成任务的等等。当然这些说法都没错，但是我觉得还是有些不好理解的。所以我们依然先从原理着手去理解下，agent是个什么东西。首先这张图里，中间的“智能体”，其实就是llm，或者说大模型。四个箭头，分别是我们为llm增加的四个能力。工具、记忆、行动、规划。那么这个是怎么新增的呢？目前行业里主要用到的是一个叫langchain的框架，这个框架可以简单理解为，他把llm和llm之间，以及llm和工具之间，通过代码或prompt的形式，进行了串接。这个其实也像是在rag的基础上再进了一步。因为我们知道rag其实是给了大模型一个浏览器工具来使用嘛，那agent，其实就是给了大模型更多的工具。比如像是长期记忆，其实就是给了大模型一个数据库工具让其往里记录重要信息。规划和行动，其实就是在大模型的prompt层做的些逻辑，比如让其将目标进行每一步的拆解，拆解完成后，每一步去输出不同的固定格式action指令，给到工具作为输入。当然langchain或者说agent还不止这些，也会有很多其他的代码逻辑体现在其中，不过其主要的主干逻辑，其实还是在prompt层和工具层，完成的设计。