目录

一、原生大模型和微调大模型定义

1.原生大模型

2.微调模型

二、问答过程调用大模型的原理

（一）原生大模型

1.普通问答

步骤一：调度服务 -> 应用算法服务

步骤二：应用算法服务 -> LLM本地模型服务

步骤三：LLM本地模型服务处理并返回

步骤四：应用算法服务后处理并返回

步骤五：调度服务 -> 前端

Q1：看到这里是否会有一个疑问呢？步骤二的应用算法服务里构建Promt（提示词）的过程，是问答的时候启用，还是预先训练好的呢？这个过程是否有调用大模型来生成呢？

Q2：前面提到的“本地部署的大模型”是什么意思？

1.“本地部署”的详细含义

2.优缺点对比

2.问答+联网搜索/知识库检索（rag）

知识库检索环节的详细分解

“联网搜索”环节的详细分解

Q3：如果有历史对话记录，在这个过程又是怎么处理的呢？

方法一：将历史记录直接作为对话上下文（更常见）

方法二：基于历史记录优化当前查询（更智能）

最常见的工业级实践是：方法一 + 方法二的结合。

3.问答+深度思考

“深度思考”环节的详细分解

方法一：单次调用，诱导出思维链（最常用）

方法二：多次调用，自我验证与改进（更强大）

方法三：函数调用（Function Calling）与工具使用

4.问答+联网搜索/知识库检索+深度思考

（二）微调大模型

1.微调大模型训练

2.问答+联网搜索/知识库检索+深度思考

Q4：微调后的大预言模型输出的答案除了内容质量上的变化，还有其它变化吗？由什么决定呢？

1. 训练数据格式的模仿（最主要的原因）

2. 过拟合与灾难性遗忘

3. 损失函数的导向

---

在学习大模型原理的过程中，对大模型的知识存在很多疑问，通过与AI问答理解内容后，整理出本文的内容，需声明：大部分答案都是AI回答的，请辩证思考，也欢迎指正！

一、原生大模型和微调大模型定义

1.原生大模型

原生大模型，也称为基础模型，是指在大规模、广泛的数据集上经过预训练，但尚未针对任何特定任务或领域进行进一步优化的大型语言模型。

比如，市面上通用的大模型：

• OpenAI 的 GPT-4（未经过特定微调的版本）

• Meta 的 Llama 3（开源的基础版本）

2.微调模型

微调模型是指在原生大模型的基础上，使用特定的、规模较小的数据集进行额外训练的模型。这个过程旨在让模型适应特定任务、风格或领域。

特点：

1. 训练数据：使用小型、高质量、针对性的数据集（例如，客服对话记录、法律文书、医疗文献、公司内部文档等）。

2. 专业性：通过微调，模型在特定任务或领域上的性能会大幅提升，同时可能会牺牲一部分其他领域的通用能力。

3. 风格化：微调不仅可以灌输知识，还可以让模型模仿特定的风格、语气和格式。例如，让它像律师一样说话，或者生成符合公司规范的邮件。

4. 效率：微调的成本远低于从零开始训练一个基础模型，它是在已有“通用智能”上进行高效的精加工。

比如，

• 用公司过去的客服日志微调一个基础模型，得到一个能处理公司特定产品的智能客服模型。

• 用某个领域（比如汽车行业）的专业知识形成问答对训练原生大模型，使其具备该领域的专业知识。

二、问答过程调用大模型的详细流程

（一）原生大模型

1.普通问答

实时流程：前端 -> 调度服务 -> 应用算法服务 -> LLM本地模型服务（再将结果依次返回）

eg：假设一个用户在前端输入：“帮我总结一下今天下午三点会议的要点。”

步骤一：调度服务 -> 应用算法服务

1. 接收请求： 调度服务从前端接收到一个请求，请求中可能包含：{ "action": "summarize_meeting", "meeting_id": "12345", "user_id": "67890" }。

2. 请求验证与路由：

   • 调度服务会先验证用户令牌、参数合法性等。

   • 然后，它根据 action 字段（或其它路由规则）判断这个请求应该由哪个“专家部门”处理。这里 action 是 summarize_meeting，所以它知道要调用 “会议总结算法服务”。

3. 发起调用： 调度服务通过内部网络（通常是HTTP/REST或gRPC协议），将请求转发给“会议总结算法服务”的特定API端点（例如 POST /api/summarize）。

调度服务的工作到此基本完成，它会等待算法服务的回复，然后再原路返回给前端。

步骤二：应用算法服务 -> LLM本地模型服务

“会议总结算法服务”开始工作：

1. 准备数据：

   • 它收到调度服务发来的 meeting_id 和 user_id。

   • 它首先会去公司的数据库里查询，找到ID为 12345 的会议记录、 transcript（文字实录）、参会人员列表等原始数据。

2. 构建Prompt：

   • 这是最关键的一步。算法服务根据其“会议总结”这个专门任务的逻辑，将原始数据构造成一个LLM能理解的、高质量的提示（Prompt）。

   • 例如，它可能生成这样一段文本：

     你是一个高效的会议助手。请根据以下的会议文字记录，生成一段简洁的会议摘要，突出会议的决定和待办事项。
     
     会议记录：
     {这里是从数据库查到的很长的一段会议文字实录...}
     
     会议摘要：

   • 这个Prompt工程的质量直接决定了LLM回复的质量。

3. 调用本LLM服务（这里是调用的本地部署的大模型）：

   • 算法服务通过内部网络，向LLM本地模型服务发起调用。

   • 调用通常是一个HTTP POST请求，发送到LLM服务的API（如 http://llm-service:8080/v1/completions）。

   • 请求体中包含了精心构建的Prompt以及一些生成参数（如 max_tokens：最大生成长度，temperature：创造性程度等）。

步骤三：LLM本地模型服务处理并返回

1. 模型推理：

   • LLM服务（例如运行着类似FastChat、Text Generation Inference、或Ollama等框架的服务器）接收到请求。

   • 它将Prompt输入到其加载好的大语言模型（如Llama 3, Qwen等）中。

   • 模型在GPU上进行复杂的数学运算（推理），逐词生成最合适的回复内容。

2. 返回结果： 生成完成后，LLM服务将结果封装成JSON格式返回给调用它的算法服务。

   • 返回体示例： { "completion": "本次会议于今天下午三点召开，主要讨论了Q3产品规划。决定推迟XX功能发布，并确定由张三负责在下周五前完成市场调研报告。", ... }

   LLM服务的工作到此结束，它不关心这个摘要会被用来做什么。

步骤四：应用算法服务后处理并返回

1. 接收并处理LLM回复：

   • “会议总结算法服务”收到LLM返回的原始文本摘要。

   • 它可能还会对这个摘要进行一些后处理，比如：提取关键行动项并存入数据库、格式化文本、过滤敏感词等。

2. 最终响应： 算法服务将处理好的最终结果（例如一个结构化的JSON数据）返回给正在等待的调度服务。

{
  "status": "success",
  "summary": "本次会议于今天下午三点召开...",
  "action_items": [
    {"owner": "张三", "task": "完成市场调研报告", "due_date": "2023-10-27"}
  ]
}

步骤五：调度服务 -> 前端

调度服务收到算法服务的最终回复后，将其原封不动地、或者再包装一层标准格式后，返回给最初发起请求的前端。前端应用程序接收到数据后，将其渲染展示给用户：“这是您的会议摘要...”

到此就结束一个问答过程了，总结起来：用户提问--前端传递给调度服务--调度服务将问题分类给到对应的算法应用服务--算法应用服务收到问题后重构promt（提示词）--调用大语言模型（根据重构后的提示词）生成答案--LLM将答案返回给算法应用服务--算法应用服务处理收到的结果并以JSON格式返回给调度服务--调度服务将答案返回给前端--前端渲染--用户看到回复。

Q1：看到这里是否会有一个疑问呢？步骤二的应用算法服务里构建Promt（提示词）的过程，是问答的时候启用，还是预先训练好的呢？这个过程是否有调用大模型来生成呢？

回答：预先训练好的，它不是在每次用户问答的实时链路上动态生成和测试的。这里我们区分 “开发阶段” 和 “运行阶段”来解释。

1. 开发阶段 

-- 可以分两个角度来理解：1.生成提示词是怎么生成的（手动设计还是调大模型）；2.生成后怎么确定是符合预期的呢？

开发阶段指在将“应用算法服务”部署上线之前，工程师所做的工作。这个过程是离线的，并且非常耗时。

• Prompt生成与迭代：工程师会基于业务目标（如会议总结、情感分析、代码生成）手动设计Prompt的初版，或者使用另一个大模型来辅助生成一些候选Prompt。

• 大量测试与评估：然后，工程师会准备一个测试数据集（包含大量不同的输入用例），用这些候选Prompt去批量调用LLM模型。

• 分析与选择：通过人工评估或自动化指标（如准确性、相关性、长度等）来分析所有结果，选出表现最好、最稳定的那个Prompt。

• 固化：最终，将这个最优的Prompt固化到“应用算法服务”的代码或配置文件中，成为一个模板。

2. 运行阶段 

这是指用户在前端提问后，请求流经整个系统的实时过程。这个过程要求极低延迟和高稳定性。

• 应用算法服务中存储的是事先准备好的、固化的Prompt模板。

  • 例如：“你是一位资深编辑，请用简洁的语言总结以下文本，并列出三个关键点：{user_input}”

• 当服务收到调度服务转发的用户请求时，它只需要做一件事：

  1. 获取业务数据（从数据库或请求参数中）。

  2. 渲染Prompt模板：将用户的具体数据（如user_input = 具体的会议记录）填充到模板的预置占位符中，形成一个完整的、具体的Prompt。

  3. 调用LLM本地模型服务：将这个完整的Prompt发送给LLM，并等待结果。

• 在这个实时过程中，绝对不会再去调用另一个大模型来生成或测试新的Prompt。它只是在机械地执行“填充数据 -> 发送”的流程。

Q2：前面提到的“本地部署的大模型”是什么意思？

回答：“将大模型部署到本地” 指的是将大型语言模型（LLM）的软件和硬件基础设施完全设置在自己的控制范围内，而不是通过互联网调用外部公司提供的API服务。

A：“本地部署”的详细含义

1. 硬件本地化

• 含义：自己购买并维护运行大模型所必需的硬件设备，通常是配备了高性能GPU（如NVIDIA H100, A100, 甚至消费级的RTX 4090）的服务器或工作站。

• 为什么：大模型的推理（生成答案）和训练/微调是计算密集型任务，极度依赖GPU的并行计算能力。CPU几乎无法有效运行这些模型。

2. 软件环境本地化

• 含义：在自己的服务器上搭建一整套软件栈，包括：

  • 操作系统：通常是Linux。

  • 驱动：如NVIDIA的GPU驱动。

  • 深度学习框架：如PyTorch, TensorFlow。

  • 推理引擎：专门为高效运行模型而优化的软件，如vLLM, Text Generation Inference (TGI),  Ollama, LM Studio等。

  • 模型文件：将模型权重文件（通常是几十GB到几百GB）下载并存储在本地硬盘上。

3. 网络访问本地化

• 含义：一旦部署完成，所有数据的传输都在自己的内部网络中完成。

• 流程：你的应用程序（如一个聊天界面）直接向本地服务器上的一个API端点（如 http://192.168.1.100:8000/v1/chat/completions）发送请求，服务器上的模型处理完后，直接将结果返回给你的应用。整个过程完全不需要连接互联网（除了最初下载模型和软件时）。

4. 控制权本地化

• 含义：这是最核心的一点。你拥有对模型的完全控制权。

  • 数据隐私：所有提问和生成的答案永远不会离开你的内部环境，彻底杜绝了数据泄露给第三方的风险。这对于处理法律、医疗、金融等敏感信息至关重要。

  • 定制自由：你可以随意对模型进行微调、量化（缩小模型体积以提升速度）、优化，而不受任何云服务商的条款限制。

  • 成本结构：从“按调用付费”的可变成本，转变为“一次性硬件投资+电费”的固定成本。调用次数越多，单次成本就越低。

  • 可靠性：你不受云服务商API故障、网络中断或费率变更的影响。你的服务稳定性取决于你自己的基础设施。

B：优缺点对比

	本地部署	调用云端API
数据隐私	极佳，数据不出内网	存在风险，数据需发送给第三方
控制权	完全控制，可任意修改	受限于服务商，遵守其规则
成本	前期投入高（硬件成本），后期成本低	无前期成本，按使用量付费
性能	取决于自身硬件，可优化	取决于服务商，通常很好但不可控
可靠性	自担责任，自己维护	服务商担责，但有网络依赖
模型更新	自己手动更新	自动更新，无需操心

2.问答+联网搜索/知识库检索（rag）

这里先讲知识库检索部分-整个实时流程会变为：前端 -> 调度服务 -> 应用算法服务 -> (知识库检索) -> LLM本地模型服务

这里先解释下什么是知识库检索，知识库检索是给大模型补充对应知识：采用对文件切片（向量化，切成一块一块存储起来）的方式，后续对问题也进行切片，再根据特定的向量公示计算问题片段与知识库片段的相似度，取相似度最高的前几个片段（个数可设置）放到增强的提示词中。

A：知识库检索环节的详细分解

这个新增的环节发生在“应用算法服务”接收到调度服务的请求之后，调用LLM之前。

1. 接收请求与解析

• “应用算法服务”从调度服务收到用户请求，例如：“我们公司今年最新的差旅政策有什么变化？”

2. 查询重构

• 服务会对用户的原问题进行一些预处理，使其更适合检索。

• 例如，它可能会提取关键词：“差旅政策 最新 变化 2024”。有时甚至会用一个更小的模型来生成更优的搜索查询。

3. 知识库检索

• 这是核心步骤。应用算法服务使用重构后的查询，去调用知识库检索服务。

• 检索过程：知识库通常被处理成向量形式。检索服务会将查询也转换为向量，并在向量数据库中进行相似度搜索，找到与查询最相关的文本片段（chunks）。

• 检索结果：检索服务返回Top-K个最相关的段落或文档片段。例如，它可能返回3段来自公司《2024年差旅规定V2.0.pdf》中的具体条文。

4. 构建增强Prompt

• 应用算法服务现在拿到了两样东西：1. 用户原问题； 2. 从知识库检索到的相关上下文。

• 它不会直接把问题扔给LLM，而是构建一个特殊的Prompt，将两者结合。这个Prompt通常遵循一个固定的模板：

  请严格根据以下提供的内容来回答问题。如果内容中没有答案，请直接说"根据现有资料，无法回答该问题"，不要编造。
  
  【相关资料】：
  {这里是检索到的知识库文本片段1...}
  {这里是检索到的知识库文本片段2...}
  {这里是检索到的知识库文本片段3...}
  
  【问题】：
  {重构后的用户原问题}
  
  【答案】：

5. 调用LLM并返回

• 将这个构建好的、包含了上下文的增强Prompt发送给LLM本地模型服务。

• LLM的角色从一个“无所不知的学者”变成了一个“基于给定材料的信息提取和总结专家”。它会严格遵守Prompt的指令，在提供的资料中寻找答案。

• 最终，LLM生成的答案被一路返回给前端。

B：“联网搜索”环节的详细分解

这个环节发生在“应用算法服务”解析了用户请求之后，与“知识库检索”同时或顺序进行。

1. 执行搜索：

• 应用算法服务调用一个专用的搜索API（如Google Search API、Bing API、Serper API等）。

• 它会将用户的问题（或经过查询重构后的问题）发送给搜索API。

• 搜索API返回一系列相关的网页链接、标题和摘要片段。

2. 处理搜索结果：

• 搜索API返回的是原始、冗长且可能冗余的文本。

• 应用算法服务需要对结果进行清洗、去重和摘要，只提取最相关、最核心的几段文本作为“联网搜索的结果”。

• （可选）在一些更复杂的架构中，甚至可以用一个小型LLM来快速总结搜索到的内容。

3. 整合信息并构建终极Prompt：

这是最关键的一步。现在，“应用算法服务”手上有两/三部分材料：

1. 内部知识片段：从向量数据库来的、权威的内部知识。

2. 外部搜索结果：从互联网来的、最新的外部信息。

3. 用户原始问题。

它需要将这些信息整合，构建成一个终极Prompt：

请综合参考以下提供的内部资料和外部网络信息，逐步推理，回答用户的问题。如果信息间有冲突，请优先采信内部资料。
如果无法得出结论，请说明。

【内部资料】：
{从向量知识库检索到的片段}

【外部网络信息】（截至{当前时间}）：
{从联网搜索得到的摘要片段1}
{从联网搜索得到的摘要片段2}

【问题】：
{重构后的用户原问题}

【答案】：

5. 调用LLM并返回：

• 将这个庞大的、信息丰富的Prompt发送给LLM。

• LLM的角色现在变成了一个强大的信息综合分析师：它需要交叉验证内部和外部的信息，处理可能存在的矛盾，并生成一个全面、准确且最新的最终答案。

• 最终答案被返回给用户。

知识库检索和联网搜索可一起使用，也可独立使用。

Q3：如果有历史对话记录，在这个过程又是怎么处理的呢？

处理历史记录的目的是为了让模型具备上下文理解能力，实现真正的多轮对话。主要方法如下：

方法一：将历史记录直接作为对话上下文（更常见）

这是最直接、最广泛使用的方法。它将历史记录直接作为Prompt的一部分输入给LLM。

1. 工作原理：

• 在构建给LLM的Prompt时，除了本次检索到的知识库片段/联网搜索的内容和当前问题，还会附加最近几轮的对话历史。

• LLM会看到一整段连续的对话，从而理解“你”和“它”之前说了什么，并基于此生成符合上下文的回复。

2. 在增强Prompt中的体现：

请严格根据以下提供的内容来回答问题。如果内容中没有答案，请直接说"根据现有资料，无法回答该问题"，不要编造。

【相关资料】：
{检索到的知识库文本片段/联网搜索的内容}

【历史对话】：
用户：我们公司年假是怎么规定的？
AI：根据公司规定，正式员工每年享有15天带薪年假。
用户：那病假呢？
AI：正式员工每年有12天带薪病假。

【当前问题】：
用户：那年假和病假会一起扣工资吗？

【答案】：

方法二：基于历史记录优化当前查询（更智能）

这种方法更高级，它利用历史记录来改进检索本身，而不仅仅是把历史记录扔给LLM。

1. 工作原理：

• 在用户当前问题发送到知识库进行检索之前，系统会先将当前问题 + 历史对话一起发送给一个“查询重构”模块。

• 这个模块（可以是一个规则系统或一个小型LLM）会分析整个对话上下文，然后生成一个更清晰、更完整、更利于检索的查询语句。

2. 举例：

• 历史对话：

  • 用户：我们公司的年假有多少天？

  • AI：根据规定，正式员工有15天年假。

• 当前问题：那实习生的呢？

• 未经重构的查询："实习生的呢"（这是一个很差的检索查询，向量数据库无法理解“那”指的是什么）。

• 经过历史上下文重构后的查询："实习生 年假 规定 天数"（这是一个优秀的、信息完整的查询）。

最常见的工业级实践是：方法一 + 方法二的结合。

1. 首先，使用历史记录来重构和优化当前查询（方法二），然后用它去检索知识库，确保拿到最相关的资料。

2. 然后，在构建Prompt时，附加上最近1-2轮最关键的对话历史（方法一），帮助LLM理解最新的对话上下文和指代关系。

3. 最终，将相关资料 + 历史对话 + 当前问题一起组合成增强Prompt，发送给LLM生成最终答案。

3.问答+深度思考

整个实时流程会变为：前端 -> 调度服务 -> 应用算法服务 -> (深度思考) -> LLM本地模型服务

核心变化在于，“调用LLM”这一步可能从一个简单的“一问一答”，变成一个“多步推理”的循环。

“深度思考”环节的详细分解

这个环节发生在“应用算法服务”重构提示词之后，其目标是引导LLM展示其推理过程，从而得到更可靠、更准确的答案。

方法一：单次调用，诱导出思维链（最常用）

• 在Prompt中的体现：

  请严格根据以下提供的内容来回答问题。请逐步推理，最后在【答案】中给出最终结论。
  
  【问题】：
  {重构后的用户原问题}
  
  【思考过程】：
  （模型会在这里开始一步步思考...）
  
  【答案】：
  （模型在这里写出最终答案）

• 流程：应用算法服务调用一次LLM，然后从LLM返回的完整文本中，解析并提取 【答案】 部分的内容返回给用户。

• 优点：简单，只增加少量Token消耗，效果提升显著。

• 缺点：思考过程不可控，可能仍有错误。

方法二：多次调用，自我验证与改进（更强大）

• 做法：将复杂问题分解，进行多次LLM调用。第一次调用生成推理和答案，后续调用可以扮演“批判者”或“验证者”的角色，检查之前的推理是否有误。

• 流程：

  1. 第一次调用：同方法一，让模型生成思考过程和答案1。

  2. 第二次调用：将第一次的思考过程和答案1作为新Prompt的一部分，要求模型进行自我验证。

     • Prompt示例：“以下是对问题'{用户问题}'的推理过程和答案。请严格根据提供的资料批判性地检查这段推理是否有逻辑错误、计算错误或与资料不符的地方。推理：[{思考过程}]。请指出任何问题：”

  3. 第三次调用：如果第二次调用发现了错误，可以要求模型基于批判重新生成答案。

• 优点：能极大提高复杂问题的准确性，减少幻觉。

• 缺点：延迟和成本非常高（多次调用），架构复杂。

方法三：函数调用（Function Calling）与工具使用

• 做法：这是深度思考的终极形态。模型在推理过程中，发现自己需要更多信息（如需要进行计算、查询数据库、调用某个API），可以主动“请求”应用算法服务去执行一个操作（函数），获取结果后继续思考。

• 流程：

  1. 模型在思考：“要回答这个问题，我需要先计算一下今年的增长率。”

  2. 模型输出一个结构化请求（如JSON），请求调用 calculate_growth_rate(year=2024) 函数。

  3. 应用算法服务接收到这个请求，执行相应的函数代码，获取结果（例如 0.125）。

  4. 应用算法服务将函数执行结果重新塞回Prompt，让LLM继续推理。

  5. LLM接收到结果后，继续回答：“根据计算，今年增长率为12.5%，因此...”

• 优点：将LLM的推理能力与外部工具的计算/信息获取能力结合，能力边界极大扩展。

• 缺点：实现极其复杂，需要为模型定义各种工具函数，并安全地执行它们。

4.问答+联网搜索/知识库检索+深度思考

结合了2.问答+联网搜索/知识库检索和3.问答+深度思考，深度思考发生在进行知识库检索之后，提示词变化如下：

请严格根据以下提供的内容来回答问题。请逐步推理，最后在【答案】中给出最终结论。

【相关资料】：
{检索到的知识库文本片段}

【问题】：
{重构后的用户原问题}

【思考过程】：
（模型会在这里开始一步步思考...）

【答案】：
（模型在这里写出最终答案）

（二）微调大模型

1.微调大模型训练

• 核心：模型训练。让一个大模型在训练阶段就学习并内化专业知识，得到一个专业的、定制化的大模型。

• 阶段：

  1. 离线阶段（训练时）：准备专业的训练数据（问答对、文档） -> 在强大的GPU上对基础模型进行微调或继续预训练。这个过程耗时很长（小时/天级），成本高昂。

  2. 实时阶段（运行时）：直接调用这个已经练好的专业模型。

2.问答+联网搜索/知识库检索+深度思考

与调用原生大模型无太大区别，在“构建特殊提示词”这一步之后，整个流程的最后一个动作就是“调用大语言模型”。此时，系统的最终表现（回答的质量、风格、专业性）——最关键的区别就在于：调用的是一个“通用基础模型”还是一个“专业微调模型”。

可以把这个选择想象成你要完成一项任务，需要向一个“专家”咨询：

• 调用通用模型：就像您拿着精心准备的资料（检索到的知识库片段+问题），去咨询一位博学的通才。

  • 他的特点：知识面极广，能理解各种事情，逻辑推理能力强。

  • 他的工作方式：他会非常认真地阅读您提供的资料，然后基于这些资料和他自己的通用知识来为您解答。他的答案质量高度依赖于您提供的资料是否准确、完整。

  • 风险：如果资料不完整，他可能会用自己泛泛的知识来“脑补”，从而增加“幻觉”的风险。

• 调用专业模型：就像您把同样的问题和资料，拿去咨询一位在这个领域深耕多年的资深专家。

  • 他的特点：他天生就具备这个领域的深层知识、术语体系和思维模式。

  • 他的工作方式：他也会看您提供的资料，但他能以一种更深入、更专业的角度来理解和运用这些资料。他甚至能发现您提供的资料中的潜在联系或错误。

  • 优势：即使您提供的资料稍有欠缺，他也能凭借其深厚的专业背景进行更合理的推断，生成更具洞察力的答案，并且回答的风格和术语会更专业。

Q4：微调后的大预言模型输出的答案除了内容质量上的变化，还有其它变化吗？由什么决定呢？

微调大模型输出的答案（风格、模式、长度等）由训练数据、训练方法和损失函数共同导致的

1. 训练数据格式的模仿（最主要的原因）

大语言模型微调的本质是模仿。它会拼命学习提供的训练数据中的模式、风格和长度。

• 场景：想象一下，用来微调的数据大部分是“问答对”格式，比如：

  • Q: “公司的年假有多少天？”

  • A: “15天。” （非常简短）

  • Q: “病假需要什么手续？”

  • A: “提交医院证明和申请表。” （依旧简短）

• 模型学到了什么：模型从这些数据中学到的不仅仅是“年假是15天”这个事实，更重要的是它学到了回答的风格：“对于这类问题，答案就应该是一个简短的、事实性的陈述句”。

• 结果：在推理时，即使你问了一个开放性的问题，模型也会倾向于用它在训练数据中看到的最常见的模式——简短回答——来回应你。

2. 过拟合与灾难性遗忘

• 过拟合：如果训练数据集不够大、不够多样，模型可能会过度适应这些少量的、简短的示例。它失去了基础模型原有的生成流畅、详细文本的能力，变得“只会说短话”。

• 灾难性遗忘：在微调过程中，模型为了学好新任务（如专业问答），可能会削弱甚至“忘记”它在大规模预训练时学到的其他能力，其中包括如何生成冗长、详细、富有推理过程的文本。

3. 损失函数的导向

在训练时，模型通过计算“预测的下一个词”和“真实的下一个词”之间的差异（损失）来学习。简短的答案意味着：

• 更少的词需要预测：序列更短，整体损失更容易降低。

• 更低的困惑度：说出“15天”的正确概率，远高于生成一段包含“根据公司2023年最新颁布的《考勤管理规定》第五章第二条...”的长篇大论的正确概率。
  模型会自然而然地倾向于选择那条更简单、更容易、损失更低的路径——生成简短答案。

可以通过设计训练数据、调整训练参数（降低学习率、减少训练轮数）、使用Prompt进行引导等方式调整输出答案的风格。

微调大模型是在原生大模型的基础上进行训练，这个过程是很复杂的，涉及到原生大模型的参数量等信息，训练过程要调整的东西很多，感兴趣的可以去进一步了解大模型的基本原理。