大模型产品经验漫谈

前文

昨天给领导汇报了最近做的一个 txt2sql 技术路线实现的智能助手的项目，总算是告一段落了，做了半年的时间，作为整个项目的技术负责人从头到尾主导项目，肯定是有不少收获和感悟的，趁现在还在脑袋里面热乎着，赶快总结一下，写的比较琐碎，想到哪里写到哪里。

起因

年初， AI 发展迅猛，领导感大有可为，遂立军令状誓要作一番事业，恰逢已有地下市政系统，WEB 需求已定，刚好在此基础上小试牛刀，于手机钉钉终端做一地下市政智能助手，耗时半年，终有小成。

团队配置

经理 1 名，主要负责手机需求，设计交互，协调追踪各方进度
后端 1 名，在钉钉实现后端业务
数据生产兼测试 2 名，负责生产和测试相关样本
算法 2 名，主要负责使用大模型实现项目目标

需求

要注意以下几点：

是否真的有必要做成智能终端助手，不能盲目跟风，为了智能而智能，为了大模型而大模型，这是不对的，必须是要求充分必要的需求才行
终端智能助手在定需求的思维方式上要和传统定开发需求的思维有明显区分，WEB 开发只需要按照需求展示出来固定的功能效果即可，相对比较死板，需求边界清楚。智能助手上面的问题灵活、抽象，我们既要明确限定需求边界，又需要适配此类需求，比如用户会问一些某些数据的分布概况。
明确交互方式，这对于 UI 设计相对比较重要，什么样的交互方式更友好，更舒服，尤其是使用大模型本身在内容输出的形式比较单一，生成的结果速度比较慢
明确最终的应用场景，什么人在用智能助手，什么时候用智能助手，怎么用智能助手，有没有特殊需求，等等都需要关注
在收集需求，需求评审等阶段，一定要花大力气去做。
还有一些特殊的需求，比如甲方能不能接受大模型的理念，甲方的环境可以部署大模型相关的应用吗，甲方的数据安全有保证吗，等等，哪一项都有可能把项目可行性干翻。

数据

要注意以下几点，一切以目标为导向，我们最终是要生成准确的 sql ，所以必须要朝这个方向使劲：

可以根据需求精简表字段，感觉有些用不到的字段可以删除，减少最终的 prompt 长度，既能提升大模型的推理速度，又能提升其准确程度
数据库中可以根据需求按照统一的单位预处理数据，方便后期写 sql 更加简洁，比如长度、面积等
字段定义可以更加有区分度，清晰，便于大模型的准确理解和使用
数据层面的优化，可以提升 sql 查询或者统计速度
单表大规模数据如何进行优化，提升 sql 查询或者统计速度
表之间区分度要高，如地铁站和地铁区间在用的时候容易错
要在需求的基础上，跟团队信息协调一致，尤其是在前期制作样本的过程中，因为需求反复在变，信息一定要同步到位，否则样本质量堪忧
在数据制作方面确实需要花费大精力去做，不能草草应付

解决方案

问题感知

因为涉及到多轮问答，所以问题感知是必须要做的一步，而且只能用大模型来做，我们用的是通义千问的接口。

问题路由

因为解决不同的问题需要不同的工具，所以如何正确选择出能解决问题的工具是个比较重要的课题，这肯定还是靠大模型去做，同时需要一定的策略，因为工具太多了，不可能一次都塞到 prompt 里面让大模型去分辨，这样影响速度和准确率。

生成 sql

这里结合了两种技术路线，主要的是 txt2api ，其次是 txt2sql，前者稳定性较好，可以解决大部分的需求，后者能够解决复杂类的需求，生成的 sql 稳定性较差。

另外 txt2sql 不可以用最简单的开源框架去做，存入向量数据库的数据如何存储，中间的核心部分 RAG 如何精准召回相关的业务要求，数据库表、字段信息、sql 书写方式等等，如何重排等等问题，都需要自己去调整。

使用这两种技术路线只能说解决大部分问题，但是仍然是有疑难问题存在，如下：

超出现有表、字段的范围，或者强行“无中生有”，例如：项目的负责人，问项目表中没有的负责人信息。
可能由于问题语义模糊不清、问题表述省略、字段定义不清楚、字段定义有冲突等等原因无法准处理，如：原西湖区xx小区。
由于技术路线限制无法解决某些问题，如：建设单位和施工单位相同的项目
复杂的逻辑、范围查询，如：大于等于、小于等于、非等，如：不是虾龙圩社区的地下停车场
跨表查询
问题描述中性介于统计和查询之间，无法区分到底如何解决，或者说用查询或者统计都对，但是影响测试指标，如：查询xx人防工程的防护单元数量、查询xx管线平均埋深

测试

测试这块工作是同样的重头戏，因为靠大模型来生成的 sql 是很乱的，当然我们从技术层面已经规避了这个问题，但是如何和基准的 sql 比较仍然是个耗时耗力的工程，而且需要反复测试，这方面耗费的调用大模型的接口成本也会很高
测试的指标要求一定要定清楚，我们这边只考虑准确率和速度
测试出来的结果要标注合适的标签或者备注来便于反馈问题，一定要详细，开发会基于这些内容来修改问题，不断提升性能
需求可能会持续变动，所以测试时候的各个层面的消息也要同步

大模型原生问题

这基本是大模型的原罪，和大模型本身的技术原理有关，很难规避。

限流：通义千问 qwen-max 接口限制，每分钟只有 60 次，每分钟 token 不能超过 10 万，目前访问一次请求需要用通义千问的接口 5 次，tokens 消耗在 6000-8000 个
并发：目前的并发应该不高，就算开发层面有，也会受限于第一条
问题模糊导致理解不清楚，如：原西湖区xx小区，统计2023年全市管线项目的完成率，用工程类型统计
不稳定：有时候能提出来有时候提不出来，原因不详，这种比较少见，但是出现过，怀疑是内部服务在更新
泛化：对于问题中的本没有的参数会强行往某一个定义好的参数上靠，如：竣工时间与运管时间
无中生有：在工作前期会自己生成没有规定的字段 distance

经验之谈

将传统的需求搜集和评审的思路要转变为终端智能助手这种新形式
不是所有项目都适合用大模型
大模型不是万能的，不要什么都用大模型，可能传统的规则、深度学习效果比大模型更好更快，不能盲目跟风
大模型的最大用处就是理解，但是就当下的大模型能力，理解能力也是效果有限的，不能盲目崇拜
目前人工智能的定位就是辅助，切记
需求在一直变动的情况下如何在开发和测试方面跟上进度是很考验能力的
在选用 txt2sql 的技术架构的时候，细节都需要调整，不能拿来开源的就用，否则效果极差
项目团队内部的信息同步极其重要，要以目标为导向，同步所有关键信息
时间把控，如果是有经验的团队，两三个月打磨出一个关键的产品是很有希望的。但是像我们是第一次做只能摸石头过河，所以耗费了半年的时间。当然了就现阶段基本上大家都是在摸石头过河，市面上也没出现很多此类产品，可借鉴参考的内容不多。
未来只要是查询类业务都可以做成智能助手，不一定高大上一步到位成为完全理想化的人工智能助手，只需要能辅助人们能够提升工作效率，交互更加简洁，解决实际的痛点，就是一个很好的智能助手，做到这个程度已经很难。
多关注市面上的主流技术实现路线，产品形态等

在这里插入图片描述

如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述