今天有个朋友问我，有没有本地运行过 AI 模型，他想做一个 text2sql 工具，自动分析数据库，然后就能自然语言查询，并进一步做智能分析，乃至逻辑推演。我分享了一些知识、理解给他。我发现，虽然我一直觉得自己懂得少，没啥可分享的；但是总有朋友比我懂得更少，需要学习和纠正。所以写一篇小科普，希望帮到大家。
text2sql 产品的问题
类似的产品比较多见，比如早期的明星作品 ChatExcel.com，现在 TiDB、Supabase 也都提供了 AI 生成 sql 的功能。不过我觉得都不好用，原因如下：
- 控制不住幻想。
- 没法很好的理解数据库结构，无法根据我的那些可能并不准确的字段名推断表之间的关系，并合理的输出 SQL。
- 没有根据环境微调，输出的代码可能没法直接跑。比如 TiDB 也会输出 PG SQL。反之亦然。
“幻想”是目前 LLM 最常见的问题。我们可以把 LLMs 理解成小学生，他们迫切地想满足用户（老师、家长）的要求（或者说他们被造出来就是这个目的）。所以，假如用户提出的需求他们无法满足，他们也不愿意给出零回答或者负面回答（“我不知道”、“我不会”、“不太可能”，等等），而是编造一个答案。在某些情况下，尤其是自然语言交互时，幻想答案可能问题不大；但是在编程领域，幻想答案就完全不可接受了。
尤其是，如果这些工具无法预先理解数据库结构、也无法判断执行环境，幻想就会频频发生在各种不同的地方，让人防不胜防。
朋友的想法
他想在本地跑 Code Llama 模型，实现 text2sql。他打算做一些微调，以便突破我前面说的问题。
之所以想在本地跑，是希望借助苹果 CPU 内存数量大的架构优势，突破 GPT 的上下文容量限制。
他不想从 prompt 入手，主要觉得太 low，不够技术。
我的建议
我的观点则相反：一定要从 prompt 入手。Prompt 不是玄学，事实证明，合理优化 prompt，可以得到更好的结果。
其次，不管哪家模型，都已经做好了完整的基础设施建设，基本上不会在生成端遇到问题。开发者只需要关心自己的业务逻辑开发。
从 text2sql 的角度来看，fine-tuning 当然可以得到最好的结果，但是 fine-tuning 之后，数据库结构就跟模型绑定了。否则的话，一定要想办法把数据库结构解释给 LLM，也就是说，一定要把数据结构放进 prompt。这是基本原理，也意味着我们不需要绕开 prompt engineer。
总结起来，我的看法是，如果要做这样的产品，应该：
- 想办法解析表结构、数据库结构
- 把解析结果，准确描述给 LLM（prompt）
- 解析用户的要求，尽量还原成数据库结构
- 然后一起交给 LLM 来执行
这里就存在一些难点：
- 理解数据结构
- 理解用户的需求，和数据结构建立关联
- 输出正确的语句，不要出现幻觉
- 输出稳定，能够被你的后续处理代码正确处理
如果模型比较好，可以节省（3）的时间。但是我猜测如果参数少，比如 7b、13b，那么（1）（2）都会很麻烦。所以，公共模型好，还是自己微调的模型好，最终效果不好判断。
总结
目前 LLM 尚且无法独立完成工作，应该说是我们开发者的幸运。不过，基于 LLM 开发应用跟以往不同，不太好套用以往的经验，比如上来就自建+调优。
我建议大家要对 LLM 的基本原理有一些了解，知道 LLM、fine-tuning、embedding+searching 等之类的功能是怎么实现的，能解决什么问题，会有哪些缺陷。这样就能选择最快捷方便有效的方案。
希望我那个朋友一切顺利。如果各位读者对 LLM 或者应用开发有什么问题，欢迎留言讨论。
欢迎吐槽，共同进步