基于RAG的to B智能体（Agent）应用实践

本文3095字，预计7分钟读完。

一、前言

上篇文章《一文读懂RAG（检索增强生成）》中，笔者分享了有关RAG技术的看法。

RAG在to B领域一般应用在知识库问答，智能客服等场景，大概流程是：把知识内容进行分块，建立索引后存储于向量数据库中，通过相似度检索的方式，召回与提问匹配度较高的知识片段后输入给大模型，再让大模型基于提问进行针对性的回答。

RAG+大模型构建的机器人相比于传统机器人，有更强的语义理解能力与生成组织能力，在“解决问题”层面上整体表现更加“拟人化”。

除了以上两个场景外，RAG在to B软件领域中仍存在很多值得探索的应用场景。

本篇文章，计划通过笔者在产品工作中落地的一个项目跟大家分享如何基于RAG构建一款to B智能体（Agent）应用。

二、背景

在CRM系统中，“筛选”是一个极其高频的操作，拿“筛选客户”为例子，以下是该操作一天的活跃轨迹量。

▲“筛选客户”活跃轨迹

作为一款CRM（客户关系管理）系统，需要存储的客户信息十分的多，比如：

① 基础信息：客户名称、标签、来源等

② 工商信息：行业、经营范围、公司规模等

③ 跟进信息：通话录音、聊天记录、拜访记录、跟进总结等

④ 订单信息：产品详情、成交数据等

⑤ 其余信息：报价记录、合同收款等

为了支持用户能够灵活筛选出客户，并展开针对性的管理跟进，以往做法是：把客户信息维度拆解出不同的过滤条件供用户进行筛选操作。

举个例子：“筛选本月从百度来源创建但至今仍没联系过的客户”，操作流程大致如下：

（1）客户列表点击【添加过滤条件】，从数百个条件中找到“创建客户时间”、“最后联系时间”、“来源”三个的过滤条件。

▲添加过滤条件

（2）添加条件后，选择条件对应的逻辑关系，这里创建客户时间选择“之间”；最后联系时间选择“为空”；来源选择为“属于”。

▲选择条件关系

（3）确定每个过滤条件的条件参数，这里创建时间选择为“本月”；来源选择与“百度”有关的所有来源。

▲确定条件参数

（4）点击【过滤】，执行筛选操作。

看似简单的四步操作，却存在不少的问题：

• 用户虽然知道自己需要什么，却不知道怎样组合过滤条件。
• 条件逻辑太复杂，不好理解。
• 条件参数太多，每一个条件都要手动选择十分耗时。

虽然团队后期也推出了“基础过滤”模式，有效减少了第二步的操作（条件只有“包含”关系）

▲基础过滤模式

但其余的操作仍然给用户造成不少的操作负担，毕竟让用户在短时间内把筛选需求转化成过滤条件，并搭配形成条件组合是一件相当困难的事情。

三、智能体（Agent）的框架设计

那么，是否可以基于大模型强大的语义理解能力，让用户更便捷查询到客户呢?

比方说：用户只需要把筛选需求描述清楚，至于“查找、组合过滤条件”这些重复且繁琐的操作步骤交给大模型来处理。

经过了可行性分析后，团队立项了【视图助手】Agent项目。

首先，根据对上文的筛选操作进行提炼，“筛选客户”步骤基本是：

“需求识别” -> “条件检索与选择”  ->“选择条件关系” -> “确定条件参数” -> “执行筛选”

基于提炼的这个基本步骤，可以抽象出Agent的主要框架，如下图所示：

▲视图助手的Agent框架

意图识别

根据用户的提问判断当前场景是否为客户筛选，是否需要进入到Agent的逻辑。

任务规划（Planning）

任务规划分为了3个主要子任务，分别是：

• 条件提炼：让大模型识别当前用户的提问和提供的条件列表后，从条件列表中提炼出与提问相匹配的条件信息。

• 条件组装：获取到条件相关参数后，组装条件组，并生成调用筛选API接口所需的入参结构，如：JSON结构。

• 参数判断：判断调用筛选API接口所需的条件参数是否有效，如果无效，需要向用户“反问”获取信息。

动作执行（Tools+Action）

基于上一步确定的条件组合以及参数，调用客户筛选API，执行筛选操作。

简而言之，【视图助手】所需要实现出来的效果是：用户一句话描述筛选需求，Agent应用解析出过滤条件后执行筛选，从而把原本的四步操作缩短为一步。

四、基于RAG的智能体（Agent）

【视图助手】初期的实现思路是：把全量过滤条件罗列在提示词（Prompt）中，让大模型基于用户的提问从Prompt中匹配对应的条件，并结构化返回。业务方解析大模型返回的内容后，与过滤条件进行匹配并执行筛选操作。

▲初期实现思路

但很快就发现了问题，只是简单地把数百个条件名称罗列在Prompt中，不涉及到条件参数的描述。当遇到提问涉及到语义接近的词汇或者需要特定业务含义参数匹配时，大模型会出现幻觉。

打个比方说：“关系一般的新入库客户”。

从业务层面，希望大模型返回的是：

标签="关系一般"
客户进展="新入库"

但由于大模型并不理解“标签”过滤条件具体是指什么，有什么参数；“客户进展”也同理。导致大模型只能按照自己的理解进行匹配，并返回参数。

结果可想而知，返回的条件参数无法映射至业务系统又或者多识别了无效条件。

▲初期效果

后来考虑过，通过长文本（128K）的方式，把条件名称及参数都存储于Prompt中，让大模型自我学习，并做精准匹配。但出于响应时长以及Token消耗成本的考虑，没有采取这种方式。

最终，我们确定通过RAG（检索增强生成）技术解决以上所遇到的问题。流程如下：

建立索引阶段

条件检索区别于知识库问答，并不需要复杂的知识分块规则，一般以单个过滤条件为最小单位进行切分。但直接把条件名称进行向量化存储，会导致相似检索时，产生一定的近似误差从而影响检索准确度。

因此，需要把过滤条件的描述以及具体参数一同向量化建立索引。

检索阶段

通常，RAG检索主要基于“向量检索”，它计算查询与索引数据之间的语义相似度。大概流程是：当用户提问时，问题将通过和过滤条件相同的嵌入模型和转换规则转化成查询向量，与条件向量进行匹配，并召回相似度分值最高的指定条件个数。

由于筛选场景中，用户未必会完整描述需求，更有甚者只有一个关键词或者含糊词组。这个场景下完全依赖于向量检索，会导致用户提问和条件索引不能很好的匹配时，检索质量无法达到预期效果。

因此方案中，采用了“混合检索”的方式，利用“关键词检索”作为补充，对两种检索方式召回的结果经过精排，最终筛选出满足需要的条件。

▲混合检索

生成阶段

在第二步中，召回与用户提问相似度最高的10个过滤条件，把条件名称及参数+用户提问组合成Prompt后，输入给大模型进行处理。要求大模型从用户提问中提取出匹配的过滤条件，并遵循指定的格式进行返回。

为了确保大模型返回的结果可以与业务系统中的条件参数进行匹配，还需要对大模型返回的内容进行二次清洗处理，比方说：通过模糊检索的方式校验参数的有效性。

执行筛选阶段

确保提问中存在有效参数后，再进行如：权限范围、条件查询最大值等逻辑校验。校验无误后，调用客户筛选的API接口，执行筛选操作。

整体方案流程如下图：

▲整体方案示意图

五、Agent实际落地效果

上文只是对【视图助手】主体流程的一个简单分享，落地的过程中仍然存在很多的问题需要逐一克服，比如：为了降低Agent的使用门槛，需要对用户每次的筛选轨迹进行埋点，提炼筛选参数后进行短期存储（Memory），下次使用时再通过“规则算法+大模型”的方式生成推荐提问。

以下是【视图助手】最终呈现的效果：

（1）客户列表新增“AI过滤”功能，当用户激活输入框时，系统会提供3个推荐提问。

▲视图助手演示1

（2）用户只需要在输入框填写筛选需求，Agent应用将会从提问中提炼出过滤条件及参数，并自动组成条件组执行筛选操作。

▲视图助手演示2

六、结语

【视图助手】应用并不局限于筛选客户场景，类似于线索、商机、订单等业务对象的筛选场景均可以接入。可见，RAG技术在基于大模型的Agent构建过程中，主要起到“工具”的作用，能够有效弥补大模型如：知识局限性、幻觉、时效性等问题。

在to B软件领域中，智能体（Agent）方向还有很多的场景值得我们去探索，但一开始可以尝试从优化用户以往重复且繁琐的产品交互作为切入点。

以上是笔者近阶段个人的学习与思考，希望能帮到你。