在人工智能的快速发展中,监督微调(SFT)作为一种关键的训练技术,被广泛应用于大规模语言模型(LLM)的优化过程。本文将为您详细介绍 SFT 的基础概念、核心技术、实践经验与未来发展趋势,帮助读者深入了解这一领域的前沿动态。
一、SFT 是什么?
SFT,即监督微调(Supervised Fine-Tuning) ,是大模型训练过程中的一个重要环节。简单来说,它是在预训练模型的基础上,使用有标注的特定任务数据对模型进行进一步训练,使得模型能够更好地适应目标任务。
核心思想是“迁移学习”: 利用预训练模型已有的知识(如语言理解能力),通过微调快速适配新任务(如文本分类、对话生成)。
二、SFT 与预训练的区别
在训练方式上,SFT 与预训练没有本质区别,主要的差别在于数据的构成形式。预训练通常使用长度固定的填充数据,而 SFT 则允许数据具有不同的长度。此外,SFT 会引入之前未见过的特殊标记(special token),以助于模型理解与该任务相关的新的语义。对话中常见的角色如用户(user)、助手(assistant)等角色均在此阶段明确标注。
三、技术特点
1.依赖预训练模型: 基于大规模无监督/自监督预训练(如GPT、BERT)。
2.少量标注数据: 只需目标任务的少量标注数据即可微调。
3.参数高效调整: 通常仅调整模型的部分层(如最后几层),而非全部参数。
4.应用广泛: 自然语言处理(NLP)、计算机视觉(CV)等领域的核心微调技术。
四、用“装修房子“理解 SFT
1.预训练模型=毛坯房
开发商(预训练)用通用材料(海量无标签数据)盖好毛坯房,具备基本结构(通用语言理解能力)。
2.监督微调 =个性化装修
房主(用户)根据需求(特定任务)用少量定制家具(标注数据)改造厨房(调整模型参数),使其适合烹饪(如生成医疗报告)。
3.高效与低成本
无需重建地基(保留预训练参数),仅调整墙面颜色(微调顶层网络),节省时间和资源。
SFT 的核心价值: 通过“预训练 + 微调“模式,将通用模型快速适配到垂直领域(如法律、医疗),减少数据需求和训练成本。
局限性: 依赖预训练模型的质量; 标注数据不足时可能过拟合。
五、学习建议
1.基础阶段
掌握 迁移学习 原理,理解预训练模型(如BERT、GPT)的架构 。
学习 PyTorch/TensorFlow 的微调实战(如 Hugging Face 库的 Trainer 类)。
2.进阶方向
研究参数高效微调技术(如 LoRA、P-tuning v2),应对大模型显存限制。
对比不同微调策略: 全参数微调 vs 部分层冻结 vs 适配器(Adapter)。
3.实践重点
数据标注技巧: 如何构造高质量、多样化的标注数据。
调试技巧: 学习率设置、早停法(Early Stopping)、损失函数选择。
六、模型微调常用方法【SFT】原理是什么?
SFT(Supervised Fine-Tuning,监督微调)是一种常见的模型微调方法。它的基本思想是基于已经预训练好的模型,在特定任务上利用标注数据进行监督学习,从而进一步优化模型的表现。
在SFT中,预训练模型首先被加载并固定在初始状态。然后,在给定的标注数据集上进行微调。与一般的微调方法类似,SFT的目标是通过引入任务特定的监督信号(例如标签或目标输出),让模型在目标任务上进一步优化。
七、SFT的步骤是什么?
1.预训练模型:首先使用大规模的通用数据集(如维基百科、新闻文章等)训练一个基础模型,通常是一个大型语言模型(如GPT、BERT等)。
2.收集任务数据:准备与目标任务相关的标注数据集。例如,如果任务是情感分析,则收集带有情感标签的文本数据。
3.监督微调:使用任务特定的标注数据对预训练模型进行微调,模型通过优化预测和实际标签之间的损失来学习任务相关的特征。
八、应用场景
SFT广泛应用于各种自然语言处理任务(如文本分类、情感分析、问答系统、命名实体识别等),因为它能有效利用预训练模型的知识,同时针对具体任务进行优化
九、优缺点
优点:
- 可以充分利用预训练模型的大规模知识,减少训练时间和计算资源。
- 在任务特定的标注数据上进行微调,有助于模型更好地适应任务需求。
缺点:
- 如果目标任务和预训练任务相差较大,可能会导致微调效果不如预期。
- 需要足够的标注数据才能有效微调。
举个通俗的例子
假设你有一个大型预训练语言模型(比如GPT),它已经在大量通用文本数据上进行了训练,可以理解广泛的语言特征。但现在你希望它能很好地处理医学领域的问答任务。
在这种情况下,你可以采用SFT方法,使用大量标注过的医学问答数据集(例如病人问答对,包含正确答案的医学问题)来微调这个模型。这种微调让模型能够将其通用的语言理解能力转化为医学领域的专业能力。
十、大模型SFT该怎么做(经验技巧+分析思路)
背景篇
这里先普及一些 sft 涉及到的基础概念,方便新人同学理解后续内容,老同学则可以跳过这一篇章。
Special Token
pretrain 阶段完全没见过的 token,在sft 阶段会被赋予全新的语义。主要用于标注对话的角色: user、assistant、system 这些。
此外,specialtoken 可以用来“构造知识”,比如"喜欢"这种知识一定是 sft 阶段才会见到的,可以剔除掉 pretrain 先验知识的影响,用来验证 sft 的训练情况,比如会不会过拟合。
我默认大家都知道怎么用special token 去拼prompt,如果不熟悉,看下 tokenizer config.ison 里的"chat template"这个字段也就懂了。
耗时问题
模型的预测时间可以近似理解为:y=kx+b,其中b是首个token的耗时,k是后续每个 token 的耗时,x是生成 token 的总数量。
更具体的,b 会是k的十几倍或更多,和 prompt 的长度几乎呈正相关。这个耗时的近似估算和 KV_cache机制有关,不熟悉的可以自行搜索。
这也就是为什么众人都知 cot效果好,众人又都不使用cot,因为我们可以几乎下断言“模型的生成速度和生成 token 数量呈正相关”,而 cot 恰恰又引入了大量的生成 token。
此外,prompt的长度也并非无所谓,尽量不要在prompt中写那么多废话,它毕竟和首包耗时呈正相关,在生成 token不是特别多的情况下,是影响模型耗时的主要因素。
与 pretrain 的区别
首先,sft和 pretrain 在训练方式上没有任何区别,主要区别在于数据的组成形式上:
1、pretrain 的每条数据都是满编 4K/8K,sft 的每条数据原本多长就是多长;
2、sft 会引入 pretrain 阶段未见过的 special token,来让它们学习全新的语义;
3、sft 会让模型见到最重要的 eos_token,pretrain 模型因为没见过该 token 而无法停止生成;
4、借助 special_token,sft 会把语料切分成不同的角色,标配的有system、user、assistant,根据业务需求也可以有“背景”、“旁白”、“事件”等等;
5、sft 的 prompt 不做 loss,但这并不是说它不能做loss。
主要原因是 prompt的同质化比较严重,不做loss mask的话,同样的一句话会被翻来覆去的学,但如果你能保证你的每条 prompt 都是独一无二的,就完全可以省去prompt 的loss mask 环节。
对了,session 数据一定要想清楚是每一个 answer 都算loss,还是只对最后一轮的 answer算loss。
除此之外,训练目的也不一样。pretrain 是在背书,纯粹的学习知识;sft 则是在做题,学习的是指令 follow 能力。
切勿在 sft 阶段强行给模型做知识注入,比如训个 50W 条的 code 数据,所有的知识注入工作应该采用 continue-pretrain 的思路进行.
否则都会使得模型的通用能力掉点明显(sft 做知识注入基本上是100% 某个知识,但 continue-pretrain 做知识注入会控制在 10%~ 20% 左右的比例)。
幻觉问题
首先,我们需要知道什么是幻觉?广义的幻觉指的就是模型回答错误,一本正经的胡说八道;狭义的幻觉指的是模型本身具备某个知识,但是经过 alignment 处理后就开始回答不对了。
目前的技术路线,前者属于无解的一个问题,唯一的优化点可能是通过 sft/rlhf让模型知道什么时候拒绝回复,但也仅限于训过的同类型case 能拒绝,没训过的case 依旧胡说八道,泛化效果很差。
后者是我们重点优化的方向,它是可以解的,或者说有尽量缓解这个问题的方法。
我们举个例子来理解狭义幻觉:如果 pretrain 阶段喂给模型的数据一直都是“日本的首都是北京”,那么在 sft 之后模型可能出现两种回复:
User: 日本的首都是哪里?Assistant:日本的首都是东京(幻觉)·User:日本的首都是哪里?Assistant:日本的首都是北京(正确)
判断某个问题是不是狭义幻觉的直接方法就是: 让 pretrain 模型续写某个知识点,然后看续写结果和 sft 后的回复结果是否一致。
幻觉可能是 LLM 话题讨论度最高的一个问题,因为其实验成本小,并且可以通过魔改网络结构、loss 函数、推理方式、训练方法等技巧来稍微缓解,备受学术界青睐。
然而,工业界却并不是特别在乎这个问题,主要原因有下面几点:
1、广义幻觉和狭义幻觉在降低用户的交互体验时并无明显区别,做通用 A1助手并不需要区分这两种情况,而现有技术范式下,广义幻觉只能靠外挂 RAG、functioncall的方式来解决;
2、狭义幻觉的缓解方式其实还是调参数,那些魔改 GPT的工作,并不会比调参带来更大的收益。这些工作在不同的基座模型上的收益也完全不一样,还是太 trick了,多少有点旁门左道的感觉;
3、目前,工业界的 AI 助手是一个全链路系统,裸模型的的安全问题与幻觉问题,会被上下游的各种小模型和词典配置进行拦截或者改写,并不会直接暴露出来。
我个人倾向于把狭义幻觉视为是过拟合的一种体现,也或者说是引入special_token 和固定输出格式所必然引起的一种知识丢失现象。所以本文不再讨论如何减少幻觉,对幻觉感兴趣的同学可以去搜索相关论文。
数据篇
先分享下 sft 工作者的一天:晚上下班挂个精心准备的实验,早上起床看结果并随手挂个实验防止 gpu 资源浪费,白天做一天的 case 分析,晚上下班挂一个结合case 分析结果优化完数据的新实验(完成闭环)。
因此,不用质疑,分析数据和清洗数据就是 sft 工作者的 90% 的工作量。
数据多样性
经历了一年多的磕磕绊绊,目前的LLM 从业人员大多都会认同:sft训练数据的核心是数据多样性和数据质量,数据数量并不重要。
数据质量就不谈了,prompt 可以不那么严谨,能看懂就行,但answer是尽量一个标点符号都不要有错误的,该中文引号就中文引号,该单引号就单引号,该把GPT4 啰哩啰嗦的回复精简一下就精简。
我们重点说说数据多样性。即使到了今天,也没人能定义清楚说怎样的一份训练数据叫做数据多样性足够好。
我们能做的只能是从先验的角度,把模型能遇到的各种任务类型都让它见一次。从个人经验来说,我认为数据多样性主要包含两个维度,“数据用途”和“数据形式”。
先说数据用途,也就是 task type,可以结合这几个思路进行数据收集:
1、OpenAl 官网列出了 ChatGPT 擅长的所有任务项,诸如翻译、emoii 聊天…之类的。我们就每个任务项都想办法来一点数据,照着尖子生的作业抄;
2、LLM 毕竟是个语言模型,传统的每个NLP 模型它都应该能胜任,那就把什么NER、机器阅读理解、意图识别等传统的 NLP任务也给模型补充一点,如果已有类似任务就不补充了。
训练数据也很好搞,传统 NLP 数据集质量都很高,直接拿来用就行;
3、参考业务需求,下游业务需要某个特殊场景的任务,那就让 sft 阶段提前见一见,这种数据的典型代表就是过年前给模型灌一些对春联、猜灯谜的的数据。只要数据质量没问题,一般都不会破坏模型能力;
4、……
重点来了,每一条 sft 训练数据必须要 task type 类型,千万别搞大杂烩,否则对后续的 case 分析简直是灾难性的伤害。
在实际工作中,双层task_type 都很常见,比如“逻辑推理-常识推理”,“逻辑推理-cot多步骤推理”这种。
至于每种 task_type 的数据量,别搞平均主义:难 task_type 酒数据多点,简单task_type 就数据少点,也要结合自己的 base 模型能力动态调整。
task_type 的划分就是 sft 数据最重要的基建工作,没有之一。
我们还需要从数据形式的角度来兼顾数据的多样性:
1、prompt 表达方式多样性,不要千篇一律的“把中文句子A翻译成英文”也要适当有一些“我在英国旅游,我现在需要向路人问路,我想表达A的意思,该怎么说”,“我是一个英文老师,我需要向我的学生讲解句子A用英文怎么写,请你用最正宗的表达方式帮我完成。”
这么做的目的是防止模型只认识 prompt中的几个关键 token,进而导致训练过拟合或者泛化性变差;
2、prompt 长度均衡,既要有短数据,也要有长数据,避免模型的attention 退化到无法聚焦长 prompt。
长数据还不能是字面意思的长,要有那种关键信息藏在开头/中间/结尾 的各种数据场景,避免模型在训练时偷懒,只对prompt 的起始 token 或结束 token 有 attention;
3、answer 长度均衡,不能让模型没出输几个 token 就停止,适当的有一些语料让它学会输出尽量长的 answer,否则模型会很难 follow“不少于2000字”这种指令;
4、多轮聊天的切换 topic能力,也就是说,有的数据当前 query 是和 session 有关系的,有的数据则是当前 query和 session 毫无关系,要让模型自己学会判断query 是否和 session 有关。
类似的数据还要有 system 是否生效,有些数据system 是个摆设,有些数据的answer则和system 直接相关;
5、answer 分布的多样性,这最重要,千万别总共一万条训练数据,一千条数据的 answer都说同一句话,answer 可是算loss的,太单一的话会严重让模型过拟合;
概括起来,所有的数据形式多样性都可以总结为一句话:数据形式不能让模型找到规律,关键信息在 prompt 中的位置分布要足够随机。
目的是避免模型在训练时退化,只聚焦于某些或某些位置的token,而不是聚焦于完整的prompt。模型和人一样,骨子里都是有偷懒倾向的。
数据生产
生产 prompt
说实话,我已经不太记得通用模型的 prompt 是怎么造的了,那都是去年的工作,感觉当时都是直接翻译英文数据集的 prompt并重新标注完成的。
印象里,斯坦福有一个 self-Instruct 的工作,给每个task_type 准备一些 seed prompt,然后随机采样 seed,再喂给一个能力很强的 pretrain 模型,让它基于这些 seed问题再续写出一些问题。
其实也不必是 pretrain 模型,GPT4 模型的指令 follow能力已经足够强了,让它基于一些 seed 问题直接仿写出一些 prompt 也是可以的。
今年的话,应该有很多现成的sft 训练集,或者是 nlp 训练集,想个办法到处搜刮一下,然后简单筛选下质量就行,反正我们只要 prompt,并不要answer。
最近讨论的比较热的“合成数据”,基本也都是各种启发式规则造 prompt,可以重点留意一下。
按照我前文中介绍的数据多样性,去搜集不同task_type 的数据集集合,然后适当做做改写。实在是找不到合适的 prompt,就自己动手写一点,answer写不出来,prompt还能写不出来吗?
收集或设计 prompt 的时候一定要结合实际情况,不要指望模型一次性写一篇万字爽文,这种事情连人都做不到。我们要把比较困难的任务提前拆解好 prompt,比如:
prompt1: 请设计一个重生故事的大纲,大纲包含“父母重男轻女,女主高考状元,弟弟彩礼”等要素;
prompt2: 请基于给定的故事大纲,扩充内容,生成一篇不少于多少字的文章。LLM 只是知识量比人多,而不是知识掌握度比人精细。
如果普通人做起来都费劲,那这个 prompt 大概率是需要拆解的,这在“利用 sft 后的模型去对接业务”时格外重要。
生产 answer
GPT4 is all you need,这里的 GPT4 不仅仅是字面意思上的 GPT4,还可以理解为good model的意思,指的是利用一个效果好的模型来生产answer。
不在乎成本,就选 GPT4/Claude3,用过的人都说好;在乎成本,就在自己的机器上部署 Qwen_72B/deepseek_MOE,部署过的人都说好;
llama 系列的模型就算了,它的中文能力,体验过的人都说不好;文心/豆包 等效果不如 GPT4 的闭源模型,属于品味之选,为国产大模型助力,点赞。
你一定要知道你喜欢的模型适合用什么prompt,提前在ChatGPT的playground 上多测一下,找到模型回复效果最好的 prompt,该加 few shot 就加few shot(few shot最好有一个种子池,不然模型的回复会比较单一),访问 GPT4的 prompt 并不等价于喂给模型的prompt。
然后,我们说最实用且最经济的一个方法: 训个小模型,这里再次搬出万能公式: 小型+SFT≈GPT4+zero_shot/few_shot/cot(复杂指令和逻辑推理可能不行
开卷考试就是这么无解,小模型知道考卷是什么,然后只学什么,就是能考出来好成绩。
对于某种特殊需求的 task_type,我们利用 GPT4 生产一千条 answer,然后去训小模型,再利用小模型去预测出上万条数据,这个方法真的十分非常相当的好用。
利用 GPT4 生产数据的时候,由于模型不 follow 格式,数据可用率大概只有 70%左右,但是利用自己训的小模型生产数据,那可是100%的follow 格式。
任何模型在预测的时候,有cot确实比没有cot 效果好很多,尤其是分类任务。这很容易理解嘛,直接说答案肯定不如分析完每个选项再说答案靠谱。
我前面提到过,实际工作中,出于耗时的考虑,可能不会用cot来训模型,但是数据生产的时候,为了保证回复质量还是应该让 GPT4用cot的方式进行回复,我们在训自己的模型的时候,省去cot 环节即可。
最后,苦力还是要做的,GPT4也好,自己训模型也罢,还是会出现出现数据质量不可用的情况,这时候必须要写规则,或者通过肉眼看来做个校验。
数据去重环节也得做,因为一个模型针对一种 task_type 生产出来的数据,同质化十分严重,一定要避免answer 过于相似的情况发生,实在看不过来就大批量剔除生产的训练数据吧。还是那句话,sft数据要的是质不是量。
小结
数据质量就是 sft 工作最核心的内容,数据生产工作一定不能当甩手掌柜,把 excel 给到标注同学后,等他们标完看都不看就直接拿来用。
有时候,把想办法“造数据/洗数据”的时间拿来手动标数据,工作早做完了,还能加深自己对数据的理解,所以不要把事情复杂化,也不要排斥去做那些所谓的“脏活”。
prompt的表达方式,answer的回复风格,训练者一定要烂熟于心。
数据飞轮
模型的上线不并代表着 sft 工作的结束,它反倒代表着 sft 真正工作的开始。只有到了这一刻,我们才开始接触“最真实的用户prompt”
前面说了,prompt的生产是需要有 seed 种子的,也就是终归是有限的,但用户的脑洞是无限的啊,用户的 query 就是我们的候选 prompt 数据集。
尤其是多轮聊天数据,自己生成的多轮对话数据,通常都默认模型回复的是正确的,用户会 follow 模型的回复。但线上可不是这种情况,你聊你的,我聊我的是时有发生的事情。
以代码任务为例,我让 GPT4 模型给我写个代码,它写了,我复制粘贴加执行,然后报错了,我把报错复制粘贴发给 GPT4,它修改了代码,我又执行还是报错……
重复了这个流程4、5 轮之后,它写的代码终于执行成功了。显然,我和模型的这5轮对话数据,就是最好的多轮理解+代码生成数据,但它几乎没有任何能标注出来的可能性,只能靠捞用户日志来获得。
不仅如此,用户日志往往还配了“点赞/点踩”的选项,甚至还能为dpo/rlhf生产数据呢(一定要清洗,这种数据很脏,我朋友说他每次都是反着点的,就是故意要污染OpenAl的训练数据)。
用户的 prompt 天然比我们自己准备的 prompt 复杂,我们自己的 sft 训练集可能就是让模型翻译一个句子,但是用户的需求可不这么简单,用户会让模型把翻译后句子的某个单词换一个表达方式,或者是提问这个句子中某个的单词是什么意思。
因此,基于用户 log生产的训练数据,是很适合培养模型的话题转移能力,自我纠错能力,坚持已见能力,结合新需求重新改写答案的能力,等等。
只有把“定期拉取用户日志,利用规则筛选有价值的 prompt,访问 GPT4获取答案,加入新数据更新模型”这样的数据飞轮 run 起来了,我们的 sft 工作才进入到了一个良性循环状态。
这里再额外说一个东西,我们的训练数据最好有一些“鲁棒性数据”:也就是 answer很正常,但 prompt 表达很差劲的训练语料。
prompt差指的是,它或者是有错别字,或者是话没说完整,亦或者是中文英文拼音夹杂着表达。
不用担心会破坏模型效果,毕竟 prompt 根本不算 loss,这么做的目的是适应线上用户的糟糕表达,没有一个用户会希望听到“不是我们的模型不行,而是你 prompt 写的不行”这种观点(我试了一圈,糟糕 prompt 的理解能力,感觉国内模型和 GPT4 的差距挺大的)。
鲁棒性数据可以直接从线上拉取,也可以手动修改原本的 prompt。切记给这类数据打上一个专属标签,千万别让新人看见之后直接给当成脏数据给清洗了
专项数据
所谓专项数据,也就是我们老生常谈的 RAG、长文本、Agent、复杂指令、function call 等 sft 数据。
这些 sft 的进阶任务,在训练上几乎没有任何额外的技巧(除了长文本训练要学会变 rope 基底和 sequence_parallel),它们所有的工作难点-半在数据生产,另一半在工程开发,而后者和算法同学也没啥太大关系。
既然这些专项都是数据工程,那就不要把它们想得那么高大上,大胆的尝试吧。这里我针对每个专项简单介绍两句它们是什么,如果想更深入的了解还需要去实操,遇到几次瓶颈也就会了。
RAG
rag的核心工作在于建库,知识库检索的准确性决定了这个工作的上限。此外,rag需要外挂两个模型:
知识/聊天二分类模型,用于判别该不该做rag。不要纠结说自己的模型知道世界最高山是什么,这个知识不用做rag。你根本没办法测出来哪些知识是模型具备且正确的,所以是知识问题就必须做 rag;
传统的 IR 模型,快速从库里面进行检索出候选候选文档,没太多说的,老NLP技能
rag 的训练 sft 数据构造主要有几个细节需要留意:
检索内容为空的时候模型会怎么回复,别让它自由发挥出一些奇怪的结果;
检索内容相互矛盾的情况,别让他只盯着第一条/最后一条的内容回复;
检索内容和query完全无关的情况,也是需要让模型见过,防止出奇怪的结果;
检索内容错了。那就让模型照着错的答案念,千万别想着让模型自己判断 rag 的知识和自己的知识谁更正确。
我们做rag 的大前提就是默认“数据库知识准确率高于模型自己具备的知识”。这种取巧心理很容易把模型搞迷糊,到时候模型不follow rag 内容就麻烦了。
问题:如何处理模型在 SFT 后会出现的“复读机”情况?
预训练(pretrain)模型的能力存在不足。
由于复读的数据无法为模型提供更多有效信息,在进行注意力(attention)计算时,模型会跳过这部分数据,继续依据之前的上下文(context)来进行预测,即从到复读数据,以及<context,复读数据>的过程中,模型还是基于之前的上下文对复读数据进行预测。
以往常通过设置复读惩罚(penalty)来避免这种情况,但如今这种方法几乎不再起作用。
在预训练(pre train)阶段,模型能力受两方面因素影响:
一是模型自身的承载能力,包括模型大小和模型结构;
二是数据的多样性。
当监督微调(sft)的数据训练量过少时,也会出现复读现象。
其本质原因在于模型通常难以学会何时停止输出结果,因为在预训练时一般采用打包(packing)的方式,导致模型基本无法学会输出(结束符),所以预训练(pre-train)模型通常会出现复读的情况。
如何学习大模型 AI ?
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费
】
第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。