我们尝试过一段时间，但后来停止了，因为看起来没有前途。我们的用例是/一直是文本转SQL的机器人，会提供特定领域的输出。我们的领域非常复杂，所以任何现成的AI SQL辅助工具对我们来说最多只是个笑话。我的想法大概是这样的：“如果你的数据库结构如此简单，以至于不需要考虑对模型进行微调，那你为什么一开始就需要它的帮助来编写SQL呢？你的答案可能在谷歌上就能找到。”我们现在认为，大语言模型只是一个概率文本转换引擎，必须始终通过某种外部方式来提供上下文。显然，如果我们能包含所有上下文，并且它能容纳得下且成本低廉，我们应该直接这么做。但是，任何人一开始考虑微调的原因就是因为你无法将整个业务都放进提示中（或者因为大规模这样做成本太高）。我们现在正在研究的方法是，一个分类前端，试图发现用户初始提示中所指的相关业务上下文。…
源讨论微调大型语言模型原帖 70 条评论 · 导入时统计把你的经验，加入这段讨论。
你有没有在什么地方记录或分享你的进展？这正好描述了我被要求调查的事情。
完整原文我现在采用类似的方法，我们使用嵌入和向量查询来创建与用户提出的问题相关的上下文，然后将其交给大语言模型。这有时有效，尤其是对于查找相关代码字面量的时候。
完整原文我一直在做同样的事情。在我的案例中，我根据API的模式生成了合成数据，并在上面训练了一个T5模型。基本上是将它视为从人类语言到API的翻译问题。
完整原文我刚刚在huggingface上增强了一些Spider和WikiSQL的数据[1]。我最初打算训练一个将自然语言问题转换为SQL的LLM，它会提供CREATE TABLE语句以提供一些上下文。这样，就不需要仅凭问题本身来胡编乱造列名和表名，我希望CREATE TABLE语句能限制选择范围。我们看看这是否有用，但有趣的是，在完成数据集后我偶然看到了这篇文章[2]。 我很想看看其他人是怎么做的。 [1] https://huggingface.co/datasets/b-mc2/sql-create-context [2] https://blog.langchain.dev/llms-and-sql/
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。