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
希望能帮到你

在 2020 年左右用过一段时间反应式编程,不推荐用来写业务,复杂的页面,跟意大利面条一样,各种 flatmap,一个简单的获取都需要花很大功夫来弄,当时用的是还是 rxjava,就很难受.最后那个项目维护太复杂了.
之后归纳总结,考虑了下适用的场景,反应式编程在前端可能更合适,防止页面或者窗口阻塞,然后流式的传输,中间做桥进行转接也不错,类似楼上说的网关.

早前流行 FP,现在是 OOP+FP,怎么好维护怎么来,因为现实业务没有纯函数,而且 FP 里面好多概念无法理解,比如函子(Functor)、适用函子(Applicative)、单子(Monad),一听名词就觉得好高大上,哈哈哈哈哈

了解一下 AI agent

上网找快乐
找到快乐线下见面
见面后发展下一代
发展完被请去喝茶
喝茶期间聊发展下一代的细节
聊完请去小黑屋坐客
一坐就是一辈子

这是一个悲伤的故事

这年头,学习还得靠自己,多买两本书,多看看视频,找个社区一起讨论,都比找人教强

@webbillion #44 36 楼已经给出了库了,我在我的项目里实验有效,https://readmagic.github.io

@madewocao #9 不常驾车,不懂啥叫索马里道路,平时工作就是金山闵行徐汇跑的

@xuqiccr #8 都有,发货的话,发脆的,软的路上颠簸容易坏