大模型微调方案设计和能力整合

01

• 数据服务：大规模模型对数据的要求极高，厂商可通过自主标注数据或采购外部数据的方式满足需求。
• 云平台：大规模模型的训练和推理过程对算力资源的需求也十分庞大，拥有自身基础架构的厂商可自行采购裸金属或利用现有云平台所提供的 PaaS 服务来构建计算平台。
• 开源社区：活跃度极高，众多优秀的开源模型如 LLama、micheal 等不断涌现，为训练和推理提供了高效的工具。企业通常通过整合开源模型、数据和代码方案，以迅速建立自身的模型能力和推理训练能力；

• 数据构建：涵盖了数据清洗、分类和管理等工作。
• 模型训练：涵盖了模型预训练、微调和评估等工作。
• 模型部署：涵盖了模型转换、量化和裁剪等工作。

2. 应用开发生命周期

• 首先，明确业务范畴与交互场景。这要求界定产品功能中哪些部分依赖大模型支持并确定其交互边界。以聊天功能为例，需要界定大模型在其中的作用范围和交互限制，通常大模型与用户的交互界面是一个聊天框，因此，交互设计应以聊天为主，并支持流式输出，这是设计过程中需考虑的第一个方面。
• 其次是关注业务目标。以聊天为例，若产品属性为工具类，如智能助手，业务目标应为用户需求达成率，衡量这一目标，可观察用户点赞数量或正反馈数量；若产品属性为情感陪伴，则应关注对话轮次和对话次数，在这一场景下，期望 AI 与用户进行尽可能多的交流和陪伴，因此数据埋点需相应调整。

• 模型选择是关键步骤，需要依据不同应用场景挑选最合适的模型。例如，针对多轮对话场景，更倾向于选择对话效果更优的模型，如 LLaMA chat 等模型；在知识问答方面，更倾向于选择具有高检索能力和安全性的工具。在此基础上进行效果调优，包括 PE、模型微调以及强化学习等。调优完成后，将对模型本身的效果进行评估，评估每个阶段的效果均达到预期后，还需对整体效果进行综合评估。
• 另一方面是选择相应的工具，通过流程编排来实现整体的互动效果。最后考虑到大模型具有较高的参数量和推理成本，需要对最终方案进行严格的性能压测，如基于线上流量等因素测试，以确保线上服务不会因性能问题而影响效果。

• 一方面是与现有其他产品模块的集成测试和上线等工作。
• 另一方面是构建大模型的持续迭代和持续学习能力，包括对线上数据进行回收，以及对线上案例进行分析。

核心要素

1. 模型调优 – 提示词工程

• 编写一条优秀的提示词或指令
• 对这些指令进行调优，并通过流程编排使其最大限度地满足业务需求
• 评估提示词是否满足实际业务需求

• Few Shot：除了描述要做什么以外，还为模型举了一些例子。优点是可以让模型快速适应新任务，而不需要大量数据，但需要精心设计例子来引导模型。
• StepByStep：将复杂任务分解为更小、更简单的步骤。其缺点显而易见，就是需要调多次，过程繁琐。
• 思维链：首先给出一个指导性的问题，模型会自动完成思考并提供答案。接着，这个答案和思考过程被分割处理，再补充指导信息，指示模型基于此问题及其思考和答案提出下一个问题。这一过程持续进行，逐步引导模型达到最终结果。这个过程能有效增强模型推理能力，但也存在繁琐的缺点。

• ReAct&Langchain：首先将业务工具封装成小函数；其次是询问模型以确定函数调用顺序，最后按此顺序调用函数，将结果反馈给模型。
• RAG（Retrieval-augmented Generation ）：检索式模型，通过外部知识库增强模型在典型场景下的表现。因为模型训练完成后，知识库固定于某个时间点。模型通过搜索能力，如提出问题并搜索相关资料，将这些资料提供给问题处理模型，从而准确回答问题。检索式模型的优点在于，额外信息可增加其回答的准确性。然而，该模型的缺点是仍然依赖于外部知识库的质量以及检索过程的效率。
• 策略组合：这实际上是一种面向未来的方法。以 OpenAI 去年发布的一个项目为例，该项目基于状态机和决策模型，核心理念在于通过模型对各个操作节点进行深入思考与评估，探询最佳问题解决策略。在执行过程中，模型通过调用特定接口以应对问题。问题解决后，模型会再次评估，决定下一步行动。这一过程循环进行，直至问题彻底解决并输出结果。

2. 模型调优 - 微调

• 通过提示词工程无法得到满意的效果；
• 线上有很多 bad case，无法有效处理；
• 在参数量大的模型中取得了较好的效果，但希望压缩成本，可以用大模型来造数据，让小模型进行学习，这样在较小的参数量，较低的成本下也能够取得和大模型类似的效果。

3. 迭代要素

4. 方案设计&能力整合

5. 评估

应用案例