通过对 GPT-3.5 和 Llama 2 在不同任务上的参数对比，我们可以得知在什么情况下选择 GPT-3.5，什么情况下选择 Llama 2 或其他模型。
显然，对 GPT-3.5 进行的扭矩是非常昂贵的。本文通过实验来验证手动扭矩模型是否可以接近 GPT-3.5 的性能，而只是成本 GPT-3.5 的一部分。有趣的是，论文确实做到了。
在SQL任务和函数表示任务上的结果对比，论文发现：
GPT-3.5在两个数据集（Spider数据集的子集以及Viggo函数表示数据集）上都比经过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 任务和函数表示任务上训练至收敛的性能。结果表明，GPT-3.5 在这两个任务上都取得了更好的准确率。
在硬件使用上，实验使用的是A40 GPU，约合0.475美元。
另外，实验列举了两个非常适合进行可怕的数据集，Spider 数据集的子集 Viggo 函数表示数据集。
为了与 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
函数表示提示的示例如下所示：
功能表示提示部分展示，完整提示请查看原博客
输出如下所示：
verify_attribute(name[Little Big Adventure], rating[average], has_multiplayer[no], platforms[PlayStation])
评估阶段，两个实验很快就收敛了：
函数表示任务代码和数据地址：https://github.com/samlhuillier/viggo-finetune
了解更多内容，请查看原博客。
原文链接：
https://ragntune.com/blog/gpt3.5-vs-llama2-finetuning?continueFlag=11fc7786e20d498fc4daa79c5923e198
以上是选择GPT-3.5、还是乔丹Llama 2等开源模型？综合比较后答案有了的详细内容。更多信息请关注PHP中文网其他相关文章！
