全面对比GPT-3.5与LLaMA 2微调

通用大模型虽好，但通过微调得到一个专属大模型不仅可以提高模型的可操控性、输出格式的可靠性和语气的一致性，还能让用户缩短提示长度，加速API调用，降低成本。

本文作者Sam L'Huillier对GPT-3.5与LLaMA 2的微调进行了基准测试，以验证手动微调的模型能否以较低的成本接近GPT-3.5的性能水平，从而帮助用户在各类任务中选择最佳微调模型。

本文作者是微调实践者Sam L'Huillier。Sam毕业于伦敦帝国理工学院，曾是Brev.dev的创始工程师，致力于构建GPU云。

（本文由OneFlow编译发布，转载请联系授权。原文：https://ragntune.com/blog/gpt3.5-vs-llama2-finetuning）

作者 | Sam L'Huillier

OneFlow编译

翻译｜杨婷、宛子琳

本文中，我将分享在SQL任务和函数表示任务中，对GPT-3.5与LLaMA 2的微调进行基准测试的实验。总体而言：

GPT-3.5在SQL任务（https://github.com/samlhuillier/spider-sql-finetune）和函数表示（https://github.com/samlhuillier/viggo-finetune）任务中的表现都略优于用LoRA微调的CodeLLaMA-34B（我发现的效果最好的模型）。
GPT-3.5的训练成本要高出4-6倍（部署成本甚至更高）。

扫描二维码关注公众号，回复： 17134041 查看本文章

为什么要做这个对比？因为GPT-3.5的微调十分昂贵，我想通过实验来验证，手动微调的模型能否以较低的成本接近GPT-3.5的性能水平。有趣的是，手动微调的模型性能确实更接近GPT-3.5！

实验结果

CodeLLaMA-34B和训练至收敛的GPT-3.5模型在SQL任务和函数表示任务中的表现。GPT-3.5在这两个任务上的准确性都要略优于CodeLLaMA-34B。在让模型生成SQL查询时，我也使用了执行准确性作为指标以比较在虚拟数据库上执行查询的输出。（精确匹配准确性是字符级比较。）

训练成本

供参考：我在去中心化GPU市场vast.ai上使用了一块价格为0.475美元/每小时的A40 GPU。（因为CodeLLaMA-34B量化为int 8后占用的GPU内存略大于40GB，所以无法使用40GB的A100GPU）

实验设置

我使用了Spider数据集和Viggo函数表示数据集的子集。这些数据集非常适合微调：

它们可以教导模型给出人们所期望的输出形式，而不是事实。SQL和函数表示任务都在寻求结构化输出。（这是Anyscale的建议。）
在开箱即用的情况下，预训练模型在这两项任务上表现不佳。

关于GPT-3.5的微调，OpenAI只允许配置epoch数量。为了与OpenAI公平比较，我在LLaMA上进行了最小程度的超参数调优，允许OpenAI选择epoch数量，并在评估集上训练LLaMA直到收敛。

LLaMA架构

使用CodeLLaMA-34B和LoRA进行微调（而非全参数微调）是我的两个关键决策。

OpenAI很可能会做一些适配器或非全参数微调。（他们不可能同时管理和冷启动多个具有175B参数的模型。如了解相关信息请与我联系。）
Anyscale的另一篇博文指出，在SQL和函数表示等任务中，LoRA几乎可以媲美全参数微调。（https://www.anyscale.com/blog/fine-tuning-llms-lora-or-full-parameter-an-in-depth-analysis-with-llama-2）

我基本遵循了LoRA超参数设置。LoRA适配器配置如下：

config = LoraConfig(
    r=8,
    lora_alpha=16,
     target_modules=[
     "q_proj",
     "k_proj",
     "v_proj",
     "o_proj",
 ],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

在实验中，我尝试将适配器应用于所有线性层（就像Qlora论文所建议的那样），但结果显示，这对性能的提升很少。同样地，将r增加到16并不会带来显著的性能提升，只会消耗更多计算资源。

数据集

其中一个示例的SQL提示为：

You are a powerful text-to-SQL model. Your job is to answer questions about a database. You are given a question and context regarding one or more tables.


You must output the SQL query that answers the question.
### Input:
Which Class has a Frequency MHz larger than 91.5, and a City of license of hyannis, nebraska?


### Context:
CREATE TABLE table_name_12 (class VARCHAR, frequency_mhz VARCHAR, city_of_license VARCHAR)


### Response:

相比完整的Spider数据集，该数据集的数据库模式（schema）如下：

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)

（这样做完全是为了节省OpenAI词元数）

函数表示的提示示例如下：

Given a target sentence construct the underlying meaning representation of the input sentence as a single function with attributes and attribute values.
This function should describe the target string accurately and the function must be one of the following ['inform', 'request', 'give_opinion', 'confirm', 'verify_attribute', 'suggest', 'request_explanation', 'recommend', 'request_attribute'].
The attributes must be one of the following: ['name', 'exp_release_date', 'release_year', 'developer', 'esrb', 'rating', 'genres', 'player_perspective', 'has_multiplayer', 'platforms', 'available_on_steam', 'has_linux_release', 'has_mac_release', 'specifier']


### Target sentence:
I remember you saying you found Little Big Adventure to be average. Are you not usually that into single-player games on PlayStation?


### Meaning representation:

输出将为：

verify_attribute(name[Little Big Adventure], rating[average], has_multiplayer[no], platforms[PlayStation])

评估

两个模型都迅速收敛了。

图表展示了训练过程中模型在评估数据集上的损失。SQL（左图）在一段时间后开始出现过拟合。

对于SQL任务，我还使用了spider eval repo来计算SQL查询的执行准确率。该存储库设置了虚拟数据库，并将查询结果与GPT-3.5和LLaMA 2的查询输出进行了比较。

结论

本次实验表明，对于初步验证/最小可行产品（MVP）来说，微调GPT-3.5是一个不错的选择，但在其他方面，LLaMA 2等模型才是最佳选择。

为什么要对GPT-3.5进行微调？

想要验证微调是否为解决特定任务/数据集的正确方法
希望获得完全托管的体验

为什么要微调LLaMA 2等开源模型？

希望节省成本
希望从数据集中获取最佳性能
希望在训练和部署基础设施方面具有完全灵活性
希望保留某些私有数据

其他人都在看

试用OneFlow: github.com/Oneflow-Inc/oneflow/

全面对比GPT-3.5与LLaMA 2微调

猜你喜欢