使用谷歌Gemini系列llm 构建一个人工智能助手

本项目最适合GenAI初学者和Python初学者-中级

这个项目包括哪些内容?在谷歌Cloud Kaggle 5天密集GenAI课程中讨论的几个关键GenAI概念：嵌入，检索增强生成(RAG)，矢量数据库，少量提示，提示缓存等。

项目的目标

我之前开发的一个(假的)植物商店的人工智能助手，名为“种植!”

设置

该项目使用谷歌Gemini系列llm，因此您需要通过AI Studio生成API密钥。您可以在文档中找到详细的说明。

1：智能FAQ (RAG)

项目的这一部分涉及使用检索增强生成(RAG)向LLM提供额外的上下文(内部策略文档)，以帮助准确地回答客户的查询。

1.1数据(生成一些虚拟数据)

我的项目数据包括：

工厂政策

常见问题示例;这让我们可以从FAQ提示缓存开始

1.2创建矢量数据库

启动一个矢量数据库(例如ChromaDB)并分配你的嵌入函数;这基本上是管理和调用嵌入模型(例如，从谷歌Gemini)，当你添加/查询数据库。

1.3在RAG bot中使用vectorDB

下图解释了这个项目中使用的RAG和提示缓存过程;在适当的地方重用类似查询的答案。

1.4图解释道:

首先，用户询问他们的查询，例如：“我可以退款吗?”

然后，该模型检查之前是否问过语义相似的问题

这是通过将查询转换为嵌入来完成的，该嵌入在向量数据库中搜索类似查询(使用它们之间的距离测量)。

这决定了接下来触发哪条路由(或桶)!

桶A：发现非常相似的查询，相似度得分<= 0.75，因此返回答案，无需通过所需的LLM进行任何处理。

桶B：有些类似的查询/查询发现;相似度评分> 0.75 ~ <=0.9;因此，返回前X个类似的问题，并从更大的文档池(前K个相关文档)中检索数据- LLM在答案生成中使用这些(少量)

桶C：没有找到相似的查询(>0.9相似度得分)，然后从更大的文档池(前K个相关文档)检索数据

任何新生成的答案都被添加到提示缓存中

应用安全防护和格式化(例如删除错别字)来避免向提示缓存添加不相关或写得不好的查询

如果在文档中没有找到相关信息，告诉用户我们目前无法回答他们的查询

提示缓存“命中”计数更新时，桶A或B答案的位置;这使得FAQ问题可以根据提示缓存中的“点击”次数进行排序;在聊天机器人界面中，前4名以建议的形式显示。

1.5压力梯度界面

最后，使用Gradio创建一个不错的聊天机器人界面

这提供了一种与工具交互的简单机制!

2：数据库智能查询

该工具包括在本地数据库上调用函数;以获取有关植物及植物产品的资料。

2.1创建sqlite数据库

表的创建:

植物有列：plant_id， plant_name, scientific_name, price, category, light_requirement, water_requirement, humidity_requirement, care_level, description

Plant_products具有列：product_id， product_name, description, application_plants, symptoms_addressing

2.2编写使LLM能够与这些交互的函数

list_tables() -检索数据库中所有表的名称

descripbe_table—查找表模式，返回列和相应数据类型的列表

execute_query—执行SQL语句，返回结果

2.3为LLM提供Tools功能

模型现在可以使用这些函数(工具)来回答用户的查询，例如：

你们卖的最便宜的植物是什么?

ZZ工厂对光和水的要求是什么?

你们有价格低于15英镑的Pothos吗?

描述和平百合及其对光的要求

这个示例“最便宜的植物是什么?”返回以下内容：

总的来说，数据库查询功能非常强大，但是在查看真实场景时需要仔细考虑安全性!

潜在限制(工具1：智能常见问题解答)

数据质量和覆盖范围：不完整或过时的政策可能会限制机器人准确回答更广泛客户查询的能力。

嵌入模型语义理解：虽然有帮助，但嵌入模型对语言的解释并不完美，可能会错过措辞或上下文中的细微差异，从而导致错误的相似性匹配。

固定的相似性阈值：当前用于识别相似查询的硬编码阈值可能过于严格或宽松，可能导致将查询路由到LLM或提示缓存的次优。

RAG检索相关性：从矢量数据库中检索到的顶部文档可能并不总是包含回答用户特定问题所需的最精确信息，即使最初的语义搜索很好。

随着时间的推移，提示缓存准确性：由于策略更改，缓存的答案可能会过时，并且不相关或不正确条目的可能性可能会降低将来对类似查询的响应的质量。

潜在的限制(工具2：数据库查询)

数据依赖性和查询准确性：该工具的准确性在很大程度上依赖于结构良好的数据库信息和LLM将自然语言正确转换为精确的SQL查询的能力。任何一个错误都可能导致不准确的结果。

有限的隐式关系理解：该工具可能难以处理需要理解plant和plant_products表之间的间接连接的用户查询，而不是明确定义的关系。

下一个步骤:

改进智能常见问题解答(附加功能)

在常见问题解答中获取反馈;无用的查询可能会降低“命中”分数

比较长上下文/上下文学习与当前的RAG方法

将工具组合成Agent

代理编排决定如何利用所有可用的工具处理查询

例如，它可以回答关于商店的一般问题(工具一-智能常见问题)，也可以回答与工厂库存产品相关的问题(工具二-智能数据库查询)。

添加第三个工具：植物健康助手

图片上传器：用户上传他们糟糕的植物的图片

植物识别和症状检测：Gemini API可识别植物种类并描述任何可见症状

如果没有可见的症状：提示用户获取更多信息/从谷歌搜索中提供一般潜在问题

(代理扩展)植物健康信息检索：谷歌搜索API检索常见疾病和已识别植物和症状的治疗信息

(代理扩展)天气数据集成：谷歌天气API提供当前的天气条件，这些天气条件被纳入植物健康分析

向用户提供治疗建议和潜在原因解释，并向用户推荐任何相关产品

第四个工具：购物助手(应用集成)

提供购物协助，例如在订货前讨论各种选择，以及创建/管理账户

本文编译自hackster.io