前言
目前各种Agent遍地开花,每一种都有各自的特点.但是用到的技术通常大同小异.下面简单介绍一种推荐Agent的实现方案.
场景
ai自动的定期为用户推荐水果. 我开一个水果店.有很多的会员用户.想通过ai定期的为用户推荐水果.促进水果销售.
实现介绍
先从最容易的方式实现. 我们可以对接一个大模型.然后提供简单的prompt.
提示词:
你是一个健康饮食规划师,当用户与你对话的时候,你要咨询用户对水果的爱好.
需要用户明确提出几种自己喜好的水果.然后根据用户喜好的水果,选择相关的水果信息返回给用户.
包括水果的主要食用季节和营养成分.
对话内容
人: 你好
chatGPT:你好！我是你的健康饮食规划师。为了更好地为你提供健康饮食建议，我需要了解你对水果的喜好。请问你最喜欢吃哪些水果呢？
人:我喜欢苹果、桃子、香蕉
chatGPT:
根据你提到的喜好水果，我将为你提供苹果、桃子和香蕉的相关信息。
### 苹果
- **主要食用季节**：苹果通常在秋季（9月至11月）成熟并上市。
- - **营养成分**：
- - 富含维生素C、膳食纤维和抗氧化物质。
- - - 含有少量的钾、铁和多种B族维生素。
- - - - 有助于促进消化、降低胆固醇和增强免疫力。
### 桃子
- **主要食用季节**：桃子一般在夏季（6月至8月）成熟。
- - **营养成分**：
- - - 含有丰富的维生素C、维生素A和膳食纤维。
- - - - 含有少量的钾、镁和抗氧化物质。
- - - - - 有助于改善皮肤健康、促进消化和增强免疫系统。
### 香蕉
- **主要食用季节**：香蕉一年四季都可食用，但最佳季节是夏季（6月至8月）。
- - **营养成分**：
- - - 富含钾、维生素C、维生素B6和膳食纤维。
- - - - 含有少量的镁和抗氧化物质。
- - - - - 有助于维持心脏健康、调节血压和促进消化。
-
希望这些信息对你有所帮助！如果你有其他问题或需要进一步的建议，请随时告诉我。`
感觉也不错.满足的我们的基本需求
但是作为商家,目的是希望提高水果店的销售额度. 简单想想如何增加水果店的销售额度呢? 增加客户、增加客单价、让用户买利润高的水果 我们这次重点关注推销高利润水果 如何让模型帮助我们呢?
根据上面和模型的对话我思考一下如何结合模型返回客户提到的水果的介绍.是否可以增加我们店里的水果的介绍呢? 修改一下提示词:
你是一个健康饮食规划师,当用户与你对话的时候,你要咨询用户对水果的爱好.
需要用户明确提出几种自己喜好的水果.然后根据用户喜好的水果,选择相关的水果信息返回给用户,
包括水果的主要食用季节和营养成分.同时增加几种与客户喜欢的水果相似的水果介绍
对话内容
人:
我喜欢苹果、桃子、香蕉
GPT:
### 苹果
- **主要食用季节**：秋季（9月至11月）
- **营养成分**：
- 富含维生素C、膳食纤维、抗氧化物等。
- 含有少量的钾、镁和B族维生素。
- **相似水果推荐**：
- 梨：同样富含膳食纤维，口感清甜多汁。
- 石榴：含有丰富的抗氧化物，味道独特。
- 柿子：甜味浓郁，含有丰富的维生素A和C。
### 桃子
- **主要食用季节**：夏季（6月至8月）
- **营养成分**：
- 富含维生素C、维生素A、钾和膳食纤维。
- 含有少量的B族维生素和抗氧化物。
- **相似水果推荐**：
- 杏：口感类似桃子，富含维生素A和膳食纤维。
- 樱桃：酸甜可口，含有丰富的抗氧化物。
- 李子：味道清新，富含维生素C和膳食纤维。
### 香蕉
- **主要食用季节**：全年都可以买到，但最佳食用季节为夏季
- **营养成分**：
- 富含钾、维生素C、维生素B6和膳食纤维。
- 含有少量的镁和叶酸。
- **相似水果推荐**：
- 猕猴桃：富含维生素C和膳食纤维，口感独特。
- 芒果：甜味浓郁，含有丰富的维生素A和C。
- 椰子：富含电解质，适合运动后补充能量。
我们发现除了介绍用户喜欢的水果之外,又增加了相似的水果.是不是给用户返回的水果更多了.我们就有了更多的发挥空间.我们整理一下上面的输出:
苹果、梨、石榴、柿子、桃子、杏、樱桃、李子、猕猴桃、芒果、椰子
我们下一步就从这些水果里面分析一下: 假如店里没有芒果和椰子.如果给用户推荐了.用户想买却没有.如何让模型推荐店里有的水果呢? 如果我们提供一个接口时时查询店里有哪些水果,让模型提供店里有的水果是不是就好了.这个很简单.可以通过RAG、funtionCall、MCP很容易就可以实现. 如果仅仅是水果,种类几百个.可以把店里所有的水果一次都查出来发送给模型.实现起来好像很简单.对于一个水果店来说也许够了. 如果我们想做大做强.规模很大用户遍布全国.每个区域、每个店的水果可能不一样.每次筛选哪些水果给模型呢?这就涉及一个筛选的问题. 作为一个水果店老板首先想想筛选有哪些条件: 客户位置信息、客户爱好等.这里条件可能很多甚至无限增加.条件越多筛选的也许就越精准.注意我说的是也许,不是一定.其实在实际产品中可能需要不断的调节优化筛选条件和每个条件的比重.
我们先不发散思维.考虑简单情况. 如何根据位置信息、用户爱好筛选水果呢?
第一个想法肯定是提供一个水果查询接口.查询条件有位置信息和用户爱好.然后模型通过FC或者MCP调用就可以了.
但是当我们具体实现的时候会发现问题好像比较复杂. 如何得到位置信息呢?
最简单的方案就是读取客户的当前位置,好像很简单.但是如果用户说.我明天去海南旅游,请帮我推荐水果.那用户的当前位置信息就不准确了.这个时候我们需要模型帮助我们分析出来用户的目的地和时间. 由于海南太大了.用户既然旅游总有一个比较明确的地址和时间.我们可以编写一个提示词:
如果用户的对话里面包括出行的信息,请引导用户说出具体的出行时间.具体时间精确到天.例如8月1日或者下周一.请引导用户说出具体的地理位置.精确到市或者直辖市.例如:北京市、天津市、南京市等.
这个时候用户在与模型对话的时候就会请用户说出具体位置和时间.然后将用户反馈的位置和时间信息再发给模型,让模型帮助我们分析出对话里面包括的位置信息和时间信息.具体的提示词就不说了.大家可以自己思考调试.实际开发过程中需要消耗大量时间思考编写提示词
我们拿到了位置信息和时间信息之后调用水果查询接口就可以得到结果了.
这里还有一个问题.如果我们采用MCP.模型解析自动分析函数入参的位置信息和时间信息,我们只要给出函数参数的明确描述就可以了.但是这样通常会有误差,尤其当入参比较复杂的时候会出现,不可预测的情况概率会比价高.而且mcp调用不是很稳定.我测试过一些主要的开源mcp接口.效果不是很好.希望mcp通信协议可以不断完善.目前对于产品研发我不建议使用mcp. 我建议使用RAG或者functionCall.
下面我简单说一下实现FC遇到的一些问题.首先入参的标准化.用户说的时间地点、模型返回的时间和地点可能不是标准化的.或者模型的标准化和我们自身的数据标准化不一致.时间还好.可以通过提示词明确格式尽量让模型返回标准的时间格式.其他条件不好说了.例如地理位置信息.简单的例子:北京市、北平、北京、首都、国都这些词都是表达的一个地理位置.目前解决的方案主要是两个:分词进行模糊匹配和向量语义近似度比较.具体实现方法这里简单说一下.分词可以通过分词工具.通过ES存储来实现.语义可以通过模型向量化,然后通过向量数据库进行存储和查找.一般是先通过语义近似度查抄,然后通过分词查找.这样可以比较精确的标准化.这里涉及一个自然语言处理(NLP).大模型善于这方面工作.在实际处理过程中可以尽量让模型帮助完成语言分析.
实际开发过程中问题会比较复杂.例子里面是地理位置信息.这个数据相对比较固定.我们可以建立固定的位置信息表.一般数据不变.但是有些条件可能会经常变化.而且不太容易标准化.例如用户的爱好.每个用户的爱好可能千差万别.当然开始的时候可以建立标准爱好数据库.固定标准的爱好数据.在用户使用的过程中逐步优化完善.慢慢实现开放的爱好收集系统.这是一个比较复杂并且需要时间积累的过程.大多数产品的好坏就在于筛选条件是否精确好用.
好了通过上面方法基本上可以满足反馈给用户的水果信息是店里有的了.但是如何实现利润最大化呢?尽量将利润高的水果推荐给客户.这就涉及到另一个问题.排序.
其实排序属于查找的一部分.通常查找根据基本条件返回一个比较大的数据集.然后通过排序算法返回前面的几个数据. 排序和查找一样都需要条件.例如:根据用户的爱好排序.根据水果的销售量、销售额排序.总之我们需要建立一个根据不同的条件和权重进行排序的功能.这个可以通过大模型实现.最简单的方案就是本地部署一个大模型,然后将条件和查询结果作为输入发送给模型,模型会帮我们进行排序.也有很多开源的算法.由于本人这个方面接触的很少所以不深入说明.
上面的介绍查找和排序过程中我们会发现.执行了几个主要的过程:用户输入信息的标准化、本地数据查询、查询数据排序等.好像是一个流程.是不是可以通过工作流实现.答案是肯定的.目前很多大的平台都提供了流程编排的能力.但是我个人不太愿意使用工作流.倾向于通过手动编码的形式实现.当然我不是说工作流不好用.工作流确实有些问题.相信工作流会不断完善.这个属于个人倾向.
通过上面的查找和排序我们可以将店里的水果发送给模型了.让模型反馈用户信息的时候根据店里的水果进行反馈.我们还可以给用户提供水果组合餐.水果食用流程.这些都可以通过提供不同的接口帮助模型实现.当然大多数接口都离不开查找和排序.
我们把场景再复杂一点.我们给出每一种水果的介绍.但是水果与水果之间是否有些好的搭配或者一些冲突呢?
假如:西瓜和香蕉不适合一起吃.这些水果与水果之间有冲突的我们可以交给大模型帮助我们分析.但是我们自己也有些冲突策略.我们可以将模型返回的数据再次发送给模型帮助我们分析,也可以调用本地接口对水果进行分析.这在实际应用过程中很常用.对模型的返回进行检查验证.
最简单的就是根据本地策略规则进行过滤.多个模型比较筛选等.方案很多.例如电商平台模型推荐商品之后.对商品库存验证、商品间冲突验证(例如优惠券只能使用一次)等.
上面说了几个过程.可以通过多个模型并发完成.当然一个模型配置不同的角色同时做事情也可以.这个就是多agent并行干活.
下面我们再说一些实现的方法:
由于是抽象的说了一个水果的例子.没有具体的代码.就说一下实现的工具:
spring ai实现模型的对话.es实现数据的存储(高版本的es也有向量存储)、milvus实现向量存储、向量计算通过本地部署模型、查找排序规则验证是模型通过FC调用本地的http接口实现.基本的结构化数据存入mysql、对话数据存入redis,定期持久化,对话数据也可以存储在es、milvus、mysql里面.
其实实现一个简单的水果推荐系统很简单.但是我们扩散一下思路呢?
如果要实现一个商城产品的推荐呢?实现一个吃喝玩乐旅游服务的推荐呢?我们会遇到很多问题.但是基本思路是一样的.当然其中涉及大量的编码工作.
总结一下一个系统需要几步:
- 提示词的设计.通常实现过程中我们需要对接多个模型.包括本地模型.即使一个模型大多数情况需要并发执行多个对话(这里多个对话不是用户的多次请求.是用户的一次请求,系统内部与模型的多次交互).需要整理多个提示词.
- 接受用户对话 (这个感觉好像没什么,其实这个通常会有一个独立的服务对对话进行管理.因为用户的输入反馈是系统未来发展的宝贵资源,如果能利用好用户的输入建立客户画像可以更好的提供服务)
- 分析用户信息(例如位置信息、爱好信息等)
- 信息标准化,调用外部接口(包括地理位置坐标、天气、时间等接口,这些基本信息通过mcp调用三方,例如高德)
- 调用内部接口(查询本地数据、筛选排序,可以模型调用也可以本地代码调用)
- 返回内容规则校验
- 每一步流程都涉及数据的持久化
- 对接外部接口(通常会调用三方接口或者企业内部接口.一般会包装一个调用的入口.我倾向于使用http接口.实际开发过程中接口参数几百个的情况下最好定义完善的api.rpc和http都可以这里不详细说明)
- 返回数据格式化(这个通常模型完成,我们也需要对模型的返回做大量的工作.这个根据具体业务分析)
- 后期完善:用户信息收集分析、系统数据优化改进.提示词优化等
以上的很多过程都可以通过模型实现.当然也可以本地方法实现.有时候模型配合本地方法使得结果更加精确.
好了,上面简单介绍了实现一个水果店推荐水果的功能.就是一个agent.起个名字:水果推荐agent
