概述
本文主要讲述采用LangChain开发RAG和Agent应用的思路，分析AIGC在组件活动业务中的应用案例。
背景
活动组件AI助手落地共经历了三个阶段：
-
快速落地：采用Dify平台，验证AI与业务结合的想法，快速实现第一版；
-
优化性能：采用LangChain开发具备RAG能力的第二版；
-
丰富功能：开发具备Agent能力的第三版；
在上一篇《AIGC在活动业务中的探索与应用》中，介绍了使用Dify平台快速落地活动组件AI助手的第一版，验证了AI与业务结合的可行性。接着我使用LangChain开发了第二版，简化第一版中Dify RAG的流程，提升推荐组件的性能。有了组件推荐能力后，我们继续丰富AI助手的功能，又有了新的想法：能否根据需求，查询历史活动，快速复用同类型组件？为此我们开发了具备Agent能力的第三版，实现根据用户需求，自主规划任务和调用工具，查询所需的活动和组件数据，并实现快速复用历史活动组件的功能。
活动组件AI助手效果展示
RAG实践效果
根据用户需求，推荐合适的活动组件，提供贴合需求的参考方案，降低组件选择成本
Agent实践效果
实现Agent的计划、拆解需求、反思、推理、执行工具的能力。实现AI根据用户需求自行选择工具解决问题的效果
查询符合需求的活动信息：最近一个月最火的3个“x游戏”活动
查询使用过组件的活动列表：最近有哪些活动在使用这个组件xxxx
由于篇幅问题，仅展示部分功能。
活动组件AI助手落地实现
LangChain RAG 实践 ：
LCEL + 云原生数据仓库
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、业务系统解析结构化数据，向用户展现内容
LangChain Agent 实践
实现根据用户需求，自主规划任务和调用工具，查询所需的活动和组件数据。
核心流程：实现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助手。
-
在应用案例分析中，展示了活动组件智能AI助手的推荐组件能力及查询历史活动和组件数据的能力。
在落地过程中，分别讲述了RAG和Agent的核心实现思路。
最后，对比了不同大模型在实际Agent规划中的效果，以及活动组件AI助手的整体流程架构图。
