frandy

BzNWqv 感谢大佬

??

我能想到的训练流程应该包括哪些方面的成本:
1 、硬件成本（ GPU ）
2 、人力成本（虽然有很多数据，但是喂给模型的数据需要进行整理）
3 、维护成本（肯定要迭代更新吧）
都预算不限了，那就看在这个垂类行业效果了，一开始训练一个参数集小的垂类模型，试试水，根据具体业务情况进行调整，觉得不错了，再扩大数据集。

我们公司就是一体机，最便宜的那种，模型能力就是幼儿园水平。没什么好让领导打消的，要做好模型的选型，比如你百炼用的满血的，自己部署，用的量化的，出来效果不好，那是你的问题，所以前期做好自己运维大模型的能力。换个角度想想，自己的技能数有多点亮了几个，外加现在招聘市场对 AI 这种渴求度，自己的不满也就打消了。

巧了，仅一个月就在弄这样的产品，首先罗列下相关的开源项目
https://github.com/tencentmusic/supersonic 腾讯音乐出的 chatbi,结合 llm 和 bi 能力，看完源码，你会发现，是先通过传统的 bi 进行语义匹配，然后仍给 llm 做处理，减少模型的幻觉产生
https://github.com/eosphoros-ai/DB-GPT 核心是它的提示词，核心是它的提示词，核心是它的提示词，可以得到图表
https://github.com/CodePhiliaX/Chat2DB 开源版就是挂羊头卖狗肉，广告做的好
好了，说了那么多，就是 Text2Sql 的本质就是大模型自身的能力，
我们能做的是
1 、在喂给大模型之前，做一些语义处理，然后大模型生成 sql 之后，对 sql 进行校正，这一块，又可以让大模型来校正，反复迭代
2 、表结构不要有歧义性，关联的 id 等需要明确表明是哪个表的哪个字段，这样处理之后，32b 参数量的模型，至少能准确生成 2-3 张表关联的 sql 语句
3 、引入 rag,可以把 ddl 的信息做成 rag ，然后先进行相似度匹配，然后得到对应的相关表结构信息，最后生成 sql.
4 、切分场景，不要一把梭把所有表结构信息都仍给大模型，大模型也扛不住，尽量切分场景，场景的识别也可以依靠大模型，专业术语叫意图识别
5 、指令型的大模型比推理型的速度要高，但是出的结果不一定准确，可以结合使用。
至于 mcp,emm,别太神话。追根到对应的某个 mcp 服务器的相关源码，其实还是上面那些
以上就是我近一个月开发此类产品的最大体会。
ps：这种类型的需求，领导是最喜欢的，但是，mmp 的这种需求，你必须得知道你的数据库里有哪些信息的数据，所以就等于领导要有提问的艺术，而这，是领导缺乏的。so,做此类需求，只能尽人事，听天命，懂甩锅，会报命。

Talk is cheap, Show me the code.

这周会很忙，毕竟 ds 天天开源，哈哈哈哈

@frandy #21 迅雷没问题

之前因为这个问题写了个脚本，集成 aria2 还有点问题，没问题
https://github.com/readmagic/hx
希望能帮到你