引导黑盒的agent（24年8.19-23 debug总结）

主要内容：

1. PostgreSQL语句的校对
2. Annoy算法的简单学习
3. text2sql的实操（失败案例）
4. text2sql的实操（探索性的案例）
5. text2sql的调研（基于Spider数据集）
6. agent快速提升能力的唯一解？一些其他思考

（一）SQL语句的校对

本身校对SQL语句并不是什么难事，更多是特定场景下如何针对性的修改sql语句

最近在做text2sql场景的业务，那么对于用户的text，你需要有针对性的生成相关的sql语句，将查询结果反馈给用户。那么sql语句呈现的结果就要以用户真实需求为标准来搭建向量库，具体细节上，比如问题要更加全面；精准查询模糊查询的选择；SELCET具体的顺序；字段的特殊需求；甚至包括数据的排序等。

（二）Annoy算法的简单学习

近似最近邻搜索算法 ANNOY：算法原理和使用案例

非常省时间的算法，快速将重点区域找到。查询结果在重点区域内的随机性，在大模型强大（相对而言）的推理能力下，其实可以产生较好的结果（简单场景）。

但是如果我迫切需要一种算法，哪怕慢一些，但是我需要极度的正确性（甚至验证起来都很有难度），那么配合上大模型的不够强大（相对而言）的推理能力，如何产生正确的结果（复杂场景）。

最直观的感受就是：相似度很低的两句话是相同的意思，如何将这样的两句话匹配到一起。

（三）text2sql的实操（失败案例）

这个领域可以去聊一聊具体的业务场景，假设我需要对sql语句进行限制，某些字段我需要在部分场景开放，其他场景屏蔽，那么如何去做呢？有下面几个探索性的尝试：

• 修改initialprompt，在sql生成之前，就告知大模型什么条件下搜索；什么条件下忽略即可；
  效果肯定是有，生产环境肯定是用不了！原因在于输入的内容一多，大模型就“自顾不暇”。
  在保证sql语句的正确前提下，大模型（几十B）无法针对某个关键词（恰恰就是字段）给予太多的权重。
• 修改语料库，尽管RAG能够捕获到对应的sql语句，但是因为大模型本身具备的推理能力，是完全可以把对应的关键字段推理出来的；结合上面阐述到的权重问题，再加上大模型本身的随机性，生产环境完全无法做出确定性回复

（四）text2sql的实操（探索性的案例）

• 针对sql查询结果的处理，将sql语句拿到的数据进行过滤，去除掉某些关键字段的数据
  （prompt放开了，尽量少做限制；更多的是从代码层面处理查询到的结果，既保证大模型专注于任务本身，也能保证最后呈现出的结果可信度高）
• 针对sql本身的处理，很可能我希望大模型在处理完问题后，我希望基于此sql再增加很多字段，亦或是进行一些其他的计算量，那么在生成的sql语句基础上进行增加和修改字段是很好的方式，找到在原sql基础上需要增加（减少）的字段，然后进行操作

（五）text2sql的调研（基于Spider数据集）

调研包括：DAIl-SQL, PETSQL, MCS-SQL

总体来说，更多的侧重于（在告知数据库schema和ddl前提下）提高sql生成的准确性

另外再发一篇文章去详细介绍三种方法

然而现实是，如何将数据库schema和ddl等一系列信息输入大模型（难道微调进去吗）

（六）agent快速提升大模型能力的唯一解？

业务层面，对于很多固定类型的回答，以及某些特殊情况的特殊提问，增加agent语料库是一个很无脑的方法。面对问题过程中有过许多的尝试：修改initialprompt 和 更换RAG的生成方式（都很难用于生产环境）；代码对sql本身和sql查询的结果进行数据清洗（适配性太差了，针对某一个具体场景去做，而且写代码耗时间）。

实际上，将对应的例子，作为语料库的一部分，每次提问如果能找到，那么这一个类型的问题（或者说，提问方式和想要的回答基本能够稳定下来，不敢说百分百，但是生产环境可以放心使用）

（七）多agent，如何正确匹配，如果没有匹配到如何处理？

老办法，相似度匹配：

1. 相似度太低直接进入特定agent；
2. 匹配到agent但是查不到数据返回空，可以返回另外的agent