建一个行业的大模型，需要一些必备的条件， 比如：我们动手去做一个事情时，往往就需要考虑到一个选型的问题，这个从根本上决定这个事情从逻辑上是不是本身就不成立。
- 算力条件【有性能不错且一定数量的卡】
- 数据条件【有足够数量，足够质量的预训数据或者微调数据】
- 算法条件【有足够多的落地的场景，进行数据的标准、训练】
坦白说，这着实让人鼓舞，这种百花齐放的状态，掀起了一个创新应用的大风，肯定会有很多惊艳的发展。
一、行业大模型需要有明确的场景
我们在之前的文章中有说到，目前已经有医疗行业、金融行业、法律行业、教育行业等不同领域的模型，如下所示：
1、医疗行业微调模型
1）MedPalm
项目概述：Google在Faln-PaLM的基础上通过多种类型的医疗QA数据进行prompt-tuning指令微调得到，同时构建了MultiMedQA
2）ChatDoctor
项目概述：110K真实医患对话样本+5KChatGPT生成数据进行指令微调
项目地址：github.com/Kent0n-Li/C…)
3）Huatuo
项目概述：医学知识图谱和chatgpt构建中文医学指令数据集+医学文献和chatgpt构建多轮问答数据
4）Med-ChatGLM
项目概述： 医学知识图谱和chatgpt构建中文医学指令数据集+医学文献和chatgpt构建多轮问答数据
5）Chinese-vicuna-med
项目概述：Chinese-vicuna在cMedQA2数据上微调
项目地址：github.com/Facico/Chin…)
6）OpenBioMed
项目概述：清华AIR开源轻量版BioMedGPT, 知识图谱&20+生物研究领域多模态预训练模型
7）DoctorGLM
项目概述：ChatDoctor+MedDialog+CMD 多轮对话+单轮指令样本微调GLM
8）MedicalGPT-zh
项目概述：自建的医学数据库ChatGPT生成QA+16个情境下SELF构建情景对话
9）PMC-LLaMA
项目概述：医疗论文微调Llama
10）NHS-LLM
项目概述：Chatgpt生成的医疗问答，对话，微调模型
2、法律行业微调模型
1）LawGPT-zh
项目概述：利用ChatGPT清洗CrimeKgAssitant数据集得到52k单轮问答+根据中华人民共和国法律手册上最核心的9k法律条文，利用ChatGPT联想生成具体的情景问答+知识问答使用ChatGPT基于文本构建QA对
2）LaWGPT
项目概述：LaWGPT，亮点在于扩充法律领域词表，在大规模法律文书及法典数据上预训练Chinese-LLaMA，使用 50w 中文裁判文书数据二次预训练，形成Legal-Base-7法律基座模型，第二阶段包括构造法律领域对话问答数据集，在预训练模型基础上指令精调，共构造30w高质量法律问答数据集，并通过 Knowledge-based Self-Instruct 方式基于中文法律知识生成数据；
3)lawyer-llama
项目概述：在持续训练阶段注入领域知识，提供了一个版本。
4）LexiLaw
项目概述：LexiLaw 是一个经过微调的中文法律大模型，它基于 ChatGLM-6B 架构，通过在法律领域的数据集上进行微调，亮点在于其数据的构造上。
3、金融行业微调模型
1）FinChat.io
项目概述：使用最新的财务数据，电话会议记录，季度和年度报告，投资书籍等进行训练 项目地址：finchat.io/
2）OpenGPT
项目概述：领域LLM指令样本生成+微调框架
项目地址：github.com/CogStack/Op…
3）乾元BigBang金融2亿模型
项目概述：金融领域预训练+任务微调
项目地址：github.com/ssymmetry/B…
4）度小满千亿金融大模型
项目概述：在Bloom-176B的基础上进行金融+中文预训练和微调
项目地址：huggingface.co/xyz-nlp/Xua…
4、教育领域
1）桃李（Taoli）
一个在国际中文教育领域数据上进行了额外训练的模型。基于chinesellama，使用共计 88000 条的高质量国际中文教育问答数据集。
这些模型在某种程度上，在发布之时，都是为了解决某个特定问题提出的，但究其共性，那就是做问答，做知识问答。与之前kBQA、FAQ相比，能够给出更多丰富多样的回答，能问的更多，答得更好。
不过，我们应该想到的是，利用领域微调数据，尤其上上述的开源微调模型，绝大多数走的都是基于一个基础语言模型，使用微调QA数据完成训练的，体现的是基于QA形式来处理相应任务，也就是说以QA来完成各类任务。
但这个任务是什么？是用这个任务来解决医疗诊断？做病因自查？做股价预测？做新闻情感分析？做行业实体识别？还是做什么。
今天有位社区朋友，让大模型去做FAQ的意图识别：给定用户的问题，以及一些靠向量化计算第一步筛选出来的若干个标准问，然后拼接成prompt，再让大模型去做筛选，效果很不好。从机理上去做分析，这个根本就不是大模型的菜，大模型最大的能力是生成和总结能力。正确的做法是走DSSM这种模型去做相关性计算，或者采用粗排加精排的方式进行优化，完全没有蹭大模型的必要。
再抽象一层。做领域微调模型的目的在理想情况下，应该是提高生产力，而不是平替或者还不如之前的生产力工具。已经有一些研究的工作表明，在参数量不是太大的大模型上做微调，效果其实并不如一些监督模型。比如上面的意图识别问题，又如相关性检索问题，之前已经有一些表现很好的模型，如Bert、DSSM、Simcse等，这些已经能够解决的很好，其实再拉大模型把之前平替掉，并不现实跟经济。
所以，我们应该更进一步的想到，大模型来做，其入场的缘由应该是解决一些之前监督模型无法解决或者解决不好的场景，用大模型来提升标注进度，提升多个模型迁移带来的成本，还是来开拓一些新的场景？
所以，我们更应该明确的是，领域微调模型的意义究竟是什么。它应该是同时拥有基础模型的强大的泛化能力，强大的语义理解能力，强大的生成能力，同时也兼具领域的专业知识。而且，这些能力，一定要和具体的业务场景做结合，切实地有一些业务效益的增益，才更有价值。
总结说，与之前已有的场景方案相比，做微调模型的必要性应该是：与之前存量的方案有直接增益，降本提点。或者说，做一些增量的收益，解之前不能解，开拓新的场景，新的机会。如果这两个都不具备，那匆忙入手微调模型这个事情从根本上就不成立。
总之，三思而后行。
二、是否有足够的数据跟算力
当我们完成了必要性这一逻辑的论证之后，我们再看看做一个微调模型要付出多大的成本，以及还存在哪些风险。
我们前面说到，做领域微调模型，目标是为了注入领域知识，而注入领域知识，分成三种：一种是继续预训练注入、微调注入以及外挂注入。
继续预训练注入：因为基础模型训练数中包含少量或者压根就不包含领域知识时，最好的方式就是让它去记住。而继续预训练就是在做这个事，通过收集领域文本，组织与预训数据一样格式的数据进行训练，这个其实与之前打榜的思路是一致的，即拿到训练数据后，根据训练数据，去找相应的语料，或者做伪标数据，先继续预训练一把，然后作为一个base，后续再调优。
但是，继续训训练存在一个很大的风险，那就是可能训不进去。训不进去有2个原因：
一个是数据量太少，与动辄大几百GB甚至上TB的数据相比，如果微调数据就几个G，几十个G，或者几百兆数据，有时候甚至就几千篇文档时，这个很少，可能被淹没掉了。所以，这个涉及到量，也就是我们需要多少领域数据的问题，数据配比如何。
另一个原因是数据太难学。大模型本质上学的也是一些通用知识，并且具备一定的泛化类比能力，但这种类比能力包括两个领域，如果微调领域跟基础模型在所用数据上分布差异大，那么迁移能力就会受到限制。基础模型都是正儿八经的网站新闻、书籍、百科【今天刚在AIGC上起底了现有一些模型的数据构成】，如果你的领域是一些专利富文本、哈希值，与代号等数据构成时，那么就很可能会很难学，学不进去。而且，构造这些数据可能还很脏。
除此之外，特定领域有特定的词，有一些说不清道不明的一些特殊字符和组词规律。基础模型的tokenizer是否能很好的表达这些词，其实也是需要打问号的。【当然，我们需要去实证分析】。
如果某个场景足够不幸，受到数量，也会受到质量，领域gap太大的、tokenizer表达能力不够的多重暴击，那么微调模型的效果可能真就会变得不会那么尽如人意。
有趣的是，与学不进去相比，还有另一个叫做遗忘的问题，即学特定知识学的太好，记得太住，从而忘掉之前能力。这个在微调阶段已经被大家充分论证。我们接下来看微调注入。
微调注入，是更多人的选择，因为这个步骤要比继续预训练要便宜的多。我们可以构造大量的微调数据，放入模型中进行微调学习，以达到某种效果。但是，这个出现了几个有趣的问题：
首先，微调阶段学的只是知识的引导方式，只是在学任务的形式，比如lima等论文，有个知识假说，即大模型所有的能力都来自预训练阶段也就是说微调阶段或许注入不了知识，
其次，也有大量的微调项目的结果发现，加大微调数据的规模其实是可以提升问答效果。并且能回答一些未微调或者微调数据不太够的问题。这又在某种程度上说明了微调阶段又是能注入知识的。
当然，这就是典型的，公说公有理婆说婆有理的情况，我们需要自己验证。
但回过头来，我们还得面对这个遗忘的问题。为什么会这样？是跑的epoch数太多导致的过拟合？，我见过有社区朋友跑成千上万次，把之前忘得一干二净，只会回答那几个问题，【一般都是跑1-6个】，然后导致在生成阶段理解输入query时会优先地往sft微调数据中的问题靠近，从而限制了它来采样原有的token，从而造成让人感到"遗忘"的现象。如果是这样，我们是否可以通过增加微调prompt的多样性从而避免这过拟合。
另外，我们是否可以想到，是否还是因为domain差异过大，导致无论你跑多少个epoch，它都会倾向于老老实实地题听从你的指令，然后你问啥就是啥，然后在进行推理时也尽可能地往训练阶段来靠近，从而"不敢来生成之前已有的知识"？
当然，我们再往回捯饬，遗忘的表现，从根本上来说，应该是指令理解岔了，岔到微调的数据上了，语义编码后，把微调的关注放的太多，从而决定了在encoder后的embedding产生了有偏选择。有了这种输入，那自然在解码环节也会顺着这个embedding生成类似的答案，最终造成遗忘的现象。
所以，这是否意味着，我们需要针对领域微调数据，改attention，平衡一下score的计算，或者变成领域微调embedding的一个外挂，从而解决这些问题？【此处在YY】。当然，有直接的方式，就是把之前的数据加进去混着训。
所以，这块是需要从训练方法和数据两个方面加以处理和，这也是有趣的方向，也是你在落地时，需要拿着你的微调数据仔细研究，然后得出判定结果。
最后，我们看外挂注入。
外挂注入就是不训练，没有训练的过程，只有构造prompt，然后让模型做生成推理的过程。优点是很低成本，很灵活，可以适配到各种各样的，小的，大的，复杂的，简单的领域数据。但由于没有训练的过程，直接做的是对输入的干预，所以也容易出现怎么构造更好的prompt以达到比较好效果的问题。
我们在前面说了，外挂的本质是prompt工程，通过用户的query，通过向量化召回相关文档，然后拼接成prompt，融入模型做生成。其核心在于怎么召回一些好的文档，这个好体现在相关，即问题的答案就在召回的文档里，因此这就要求我们怎么构造一个好的底库，文档如何组织的更好，embedding如何建的更好，如何检索的更好。这些也都是问题。
不过，我们需要坦白的是，外挂是一种治标不治本的玩法，如果基础模型理解不了这些构造的文档prompt，也就不会取得较好的效果，模型真正具备这种领域知识的能力，才是根。
因此，这又涉及到一个问题，就是当你做领域微调模型，如果只做这个外挂注入，那其实已经丧失了其"领域微调模型"的本质，变得名不符实。
最后，我们看微调的成本，微调的成本跟你的微调数据量成正相关，也跟你使用的基础模型参数量正相关。具体的数据可以看github开源项目的配置，但如果你想走的远，至少3090，a100等得有若干台/张，这是自很实实在在的指标。当然，如果用低精度且只推理，在此基础上可以继续降配置。但是，如果连这些也不具备，那么，做微调模型，也就不成立。
