众所周知，对 gpt-3.5 进行微调是非常昂贵的。本文通过实验来验证手动微调模型是否可以接近 gpt-3.5 的性能，而成本只是 gpt-3.5 的一小部分。有趣的是，本文确实做到了。
在 sql 任务和 functional representation 任务上的结果对比，本文发现：
gpt-3.5 在两个数据集（spider 数据集的子集以及 viggo functional representation 数据集）上都比经过 lora 微调的 code llama 34b 表现略微好一点。gpt-3.5 的训练成本高出 4-6 倍，部署成本也更高。本实验的结论之一是微调 gpt-3.5 适用于初始验证工作，但在那之后，像 llama 2 这样的模型可能是最佳选择，简单总结一下：
如果你想验证微调是解决特定任务 / 数据集的正确方法，又或者想要一个完全托管的环境，那么微调 gpt-3.5。如果想省钱、想从数据集中获取最大性能、想要在训练和部署基础设施方面具有更大的灵活性、又或者想要保留一些私有数据，那么就微调类似 llama 2 的这种开源模型。接下来我们看看，本文是如何实现的。
下图为 code llama 34b 和 gpt-3.5 在 sql 任务和 functional representation 任务上训练至收敛的性能。结果表明，gpt-3.5 在这两个任务上都取得了更好的准确率。
在硬件使用上，实验使用的是 a40 gpu，每小时约 0.475 美元。
此外，实验选取了两个非常适合进行微调的数据集，spider 数据集的子集以及 viggo functional representation 数据集。
为了与 gpt-3.5 模型进行公平的比较，实验对 llama 进行了最少超参数微调。
本文实验的两个关键选择是使用 code llama 34b 和 lora 微调，而不是全参数微调。
实验在很大程度上遵循了有关 lora 超参数微调的规则，lora 适配器配置如下：
sql 提示示例如下：
sql 提示部分展示，完整提示请查看原博客
实验没有使用完整的 spider 数据集，具体形式如下
department : department_id [ int ] primary_key name [ text ] creation [ text ] ranking [ int ] budget_in_billions [ int ] num_employees [ int ] head : head_id [ int ] primary_key name [ text ] born_state [ text ] age [ int ] management : department_id [ int ] primary_key management.department_id = department.department_id head_id [ int ] management.head_id = head.head_id temporary_acting [ text ]
实验选择使用 sql-create-context 数据集和 spider 数据集的交集。为模型提供的上下文是一个 sql 创建命令，如下所示：
create table table_name_12 (class varchar, frequency_mhz varchar, city_of_license varchar)
sql 任务的代码和数据地址：https://github.com/samlhuillier/spider-sql-finetune
functional representation 提示的示例如下所示：
functional representation 提示部分展示，完整提示请查看原博客
输出如下所示：
verify_attribute(name[little big adventure], rating[average], has_multiplayer[no], platforms[playstation])
评估阶段，两个实验很快就收敛了：
functional representation 任务代码和数据地址：https://github.com/samlhuillier/viggo-finetune
了解更多内容，请查看原博客。
以上就是选择gpt-3.5、还是微调llama 2等开源模型？综合比较后答案有了的详细内容。