LangChain RAG&Agent实践-活动组件AI助手的实现

本文主要讲述采用LangChain开发RAG和Agent应用的思路，分析AIGC在组件活动业务中的应用案例。

活动组件AI助手落地共经历了三个阶段：

在上一篇《AIGC在活动业务中的探索与应用》中，介绍了使用Dify平台快速落地活动组件AI助手的第一版，验证了AI与业务结合的可行性。接着我使用LangChain开发了第二版，简化第一版中Dify RAG的流程，提升推荐组件的性能。有了组件推荐能力后，我们继续丰富AI助手的功能，又有了新的想法：能否根据需求，查询历史活动，快速复用同类型组件？为此我们开发了具备Agent能力的第三版，实现根据用户需求，自主规划任务和调用工具，查询所需的活动和组件数据，并实现快速复用历史活动组件的功能。

根据用户需求，推荐合适的活动组件，提供贴合需求的参考方案，降低组件选择成本

实现Agent的计划、拆解需求、反思、推理、执行工具的能力。实现AI根据用户需求自行选择工具解决问题的效果

查询符合需求的活动信息：最近一个月最火的3个“x游戏”活动

查询使用过组件的活动列表：最近有哪些活动在使用这个组件xxxx

由于篇幅问题，仅展示部分功能。

LangChain Expression Language（LCEL）是一种声明式方法，可以轻松地将链组合在一起。LCEL 从设计之初就支持将原型投入生产，从最简单的 “prompt + LLM ”链到最复杂的链（我们已经看到有人在生产中成功运行了包含 100 多个步骤的 LCEL 链），无需修改代码。

再利用云原生数据仓库的向量检索能力，实现RAG检索服务。

RAG核心流程：LLM润色用户需求 -> 得到结构化数据进行知识库召回 -> 得到知识上下文，结合用户需求交给LLM -> 得到推荐组件

1、数据转换细节：

    1.1、自然语言 -> 结构化数据；

    1.2、符合知识库数据结构，并具备可筛选的分类信息；

2、匹配知识库的细节：

    2.1、知识库分类匹配；

    2.2、召回relevant_size个top k结果；

    2.3、召回数据根据score做二次筛选；

3、最终得到结构化业务数据：

4、业务系统解析结构化数据，向用户展现内容

实现根据用户需求，自主规划任务和调用工具，查询所需的活动和组件数据。

核心流程：实现Agent的计划、拆解需求、反思、推理、执行工具的能力。实现AI根据用户需求自行选择工具解决问题的效果。

手撕ReAct Agent：Agent run 核心流程：

通过以上流程实现了一个业务专属的ReAct Agent。（LangChain中也有自带的Agent能力，但是过于通用且简单，无法满足实际的复杂业务需求，因此我自己手撕了一个）

下面对比一下不同模型在实现Agent时的表现，理解能力较强的大模型比较适合实现复杂的Agent。

打印了ReAct Agent 规划过程：

[大模型1] AI反思过程。用户需求：最近一周访问量最高的3个“x游戏”活动

第一轮思考：

第二轮思考：

大模型1总结：1.耗时较长（50-70s）2.准确性不够高，理解能力稍差（查询pv最少的x个活动，理解为按pv降序，应该是按pv升序）

[大模型2] AI反思过程。用户需求：最近一周访问量最高的3个“x游戏”活动

大模型2总结：1.性能高（10-20s）2.准确性高，理解能力强；

对比不同大模型的规划过程可以看出[大模型2]做了tool_call方面的微调，对调用工具的需求比较敏感，比较适合实现复杂Agent的需求。

最后把RAG和Agent的能力通过前置AI路由统一起来：实现AI服务统一入口。

本文讲述了采用LangChain开发RAG和Agent应用的思路，分析AIGC在组件活动业务中的应用案例：活动组件AI助手。