探索与对比不同的大语言模型

原文出处：Exploring and comparing different LLMs 原作者：Microsoft · 许可证：MIT License 中文译本由诸葛AI学院整理，仅供学习参考，版权归原作者与微软所有。

本课有配套教学视频，可在 YouTube 观看：https://youtu.be/KIRUeDKscfI

上一课我们看了生成式 AI 正在怎样改变技术版图，大语言模型（Large Language Model，LLM）是怎么工作的，以及一家公司，比如我们假设的那家初创企业，如何把它们用到自己的场景里获得增长。这一章要对比不同类型的 LLM，弄清各自的长处和短处。

初创旅程的下一步，是摸清当下 LLM 的整体格局，判断哪些适合我们的场景。

引言

本课将涵盖：

当前格局里的不同类型 LLM。
在 Azure 上针对你的场景测试、迭代、对比不同模型。
如何部署一个 LLM。

学习目标

学完本课后，你应当能够：

为自己的场景选对模型。
明白如何测试、迭代并改进模型的表现。
了解企业要怎样部署模型。

认识不同类型的 LLM

可以按架构、训练数据、用途等多个维度给 LLM 分类。搞清楚这些差别，我们的初创公司才能给场景选对模型，也才知道怎么测试、迭代、改进效果。

LLM 的种类很多。选哪一个，取决于你想拿它做什么、你有什么数据、愿意花多少钱，诸如此类。

你想处理的是文本、音频、视频还是生成图片，对应的模型类型也会不一样。

音频与语音识别。Whisper 这类模型仍是好用的通用语音识别选择，但现在生产环境里也常用更新的语音转文字（speech-to-text）模型，比如 gpt-4o-transcribe、gpt-4o-mini-transcribe，以及带说话人分离（diarization）的版本。要按你的场景评估语言覆盖、说话人分离、实时支持、延迟和成本。细节见 OpenAI 语音转文字文档。
图片生成。DALL-E 和 Midjourney 是名气最大的图片生成选项，不过 OpenAI 现在的图像 API 以 GPT Image 系列为主（如 gpt-image-2），同时 Stable Diffusion、Imagen、Flux 等模型家族也常被选用。对比时看提示词（prompt）遵循度、编辑支持、风格控制、安全要求和许可协议。可参考 OpenAI 图片生成指南和本课程第 9 章。
文本生成。文本模型如今覆盖面很广：前沿模型、推理模型、低延迟的小模型、开放权重（open-weight）模型都有。当前的例子包括 OpenAI 的 GPT-5.x 系列、Anthropic 的 Claude 4.x 系列、谷歌的 Gemini 3.x 系列、Meta 的 Llama 4 系列，以及 Mistral 的模型。别只看发布时间和价格；要对比任务质量、延迟、上下文窗口（context window）、工具调用、安全表现、区域可用性和总成本。Microsoft Foundry 模型目录是对比 Azure 上可用模型的好地方。
多模态。现在很多模型处理的不再只有文本。有的能接收图片、音频或视频输入，有的能调用工具，还有专门生成图片、音频、视频的模型。比如 OpenAI 当前的模型支持文本和图片输入；Gemini 按版本不同，可支持文本、代码、图片、音频、视频输入；Llama 4 Scout 和 Maverick 是开放权重的原生多模态模型。围绕一个模型搭工作流之前，先去它的模型卡片（model card）上确认支持哪些输入输出模态。

选好模型，只是拿到了基础能力，往往还不够。公司特有的数据，你总得想办法让 LLM 知道。这事有几条路可走，后面几节会展开。

基础模型与 LLM 的区别

"基础模型"（Foundation Model）这个说法出自斯坦福研究者的论文，指的是满足几条标准的 AI 模型，例如：

用无监督学习或自监督学习训练，即在无标签的多模态数据上训练，训练过程不需要人工标注数据。
体量很大，基于深度神经网络，参数量以十亿计。
通常用来给其他模型打底，也就是当作起点，在其上构建新模型，构建手段可以是微调（fine-tuning）。

原文此处有两张图，一张画基础模型与 LLM 的关系（来源：Babar M Bhatti 发表于 Medium 的 Essential Guide to Foundation Models and Large Language Models），一张出自论文 arXiv:2108.07258，内容都是上一组要点的示意。

再拿 ChatGPT 举个历史例子，把这个区别讲清楚。早期版本的 ChatGPT 以 GPT-3.5 作为基础模型，OpenAI 再用聊天场景的数据和对齐（alignment）技术调出一个更擅长对话的版本，用来做聊天机器人这类场景。如今的 AI 服务常常在好几个模型变体之间动态路由，所以服务名和底层模型名不总是一回事。

开放权重/开源模型与专有模型

给 LLM 分类的另一条线，是看它属于开放权重、开源还是专有。

开源和开放权重模型把模型资产开放出来，供人查看、下载或改造，但许可条款各不相同：有的完全开源，有的只是开放权重、附带使用限制。企业如果要在部署、数据驻留、成本、定制上有更多控制权，这类模型会有用。不过上生产之前，团队仍要把许可条款、服务成本、维护、安全更新、评估质量逐条过一遍。例子包括 Meta Llama 4、部分 Mistral 模型，以及托管在 Hugging Face 上的大量模型。

专有模型由厂商持有并托管。它们往往针对托管的生产环境做过优化，能提供更强的支持、安全体系、工具集成和规模。但客户通常看不到、也改不了模型权重，并且要审阅厂商条款里的隐私、数据保留、合规、可接受使用政策。例子包括 OpenAI 模型、Google Gemini 和 Anthropic Claude。

嵌入、图片生成、文本与代码生成

还能按产出物给 LLM 分类。

嵌入（embedding）是一类把文本转成数字形式的模型，这个形式就是输入文本的数值表示。有了嵌入，机器更容易理解词与词、句与句之间的关系；它还能当作其他模型的输入，比如分类模型、聚类模型，这些模型在数值数据上表现更好。嵌入模型常用于迁移学习（transfer learning）：先在一个数据充足的替代任务上训好模型，再把模型权重（也就是嵌入）复用到其他下游任务。这一类的例子是 OpenAI embeddings。

图片生成模型负责产出图片，常用于图片编辑、图片合成、图片转换。这类模型多在大规模图片数据集上训练，比如 LAION-5B，既能生成新图，也能用补绘（inpainting）、超分辨率、上色等技术编辑已有图片。例子包括 GPT Image 系列、Stable Diffusion 系列和 Imagen 模型。

文本与代码生成模型产出的是文字或代码，常用于文本摘要、翻译、问答。文本生成模型多在大规模文本数据集上训练，比如 BookCorpus，用来生成新文本或回答问题。代码生成模型，比如 CodeParrot，多在 GitHub 这类大规模代码数据集上训练，用来生成新代码，或修已有代码的 bug。

原文此处有三张图，分别示意嵌入、图片生成、文本与代码生成这三类模型的输入输出，各配一段上文对应的文字说明即可，图本身没有新增信息。

编码器-解码器与仅解码器

讲 LLM 的架构类型，先打个比方。

假设经理交给你一个任务：给学生出一套测试题。你有两位同事，一位负责出题，一位负责审题。

出题的同事就像仅解码器（decoder-only）模型：看一眼题目主题，看看你已经写了什么，就着这些上下文继续往下生成。它们很会写既好看又有料的内容，但任务如果只是分类、检索、编码信息，它们未必是最佳选择。GPT 和 Llama 系列都是仅解码器模型。

审题的同事像仅编码器（encoder-only）模型：通读写好的课程内容和答案，注意两者之间的关系、理解上下文，但不擅长生成内容。BERT 就是仅编码器模型。

再想象有这么一个人，既能出题又能审题，这就是编码器-解码器（encoder-decoder）模型。BART 和 T5 属于这一类。

服务与模型

再说说服务和模型的区别。服务是云服务商提供的产品，通常是模型、数据和其他组件的组合；模型是服务的核心组件，往往是基础模型，比如 LLM。

服务多为生产环境做过优化，还有图形界面，比裸模型好用。但服务很少免费，多半要订阅或付费，换来的是借用服务方的设备和资源：省了优化开销，也容易扩容。Azure OpenAI 服务是一例，它提供按量付费（pay-as-you-go）的计费方式，用多少付多少；在模型能力之外，还附带企业级安全和一套负责任 AI 的框架。

模型是神经网络这套资产：参数、权重、架构、分词器（tokenizer）和配套配置。要在本地或私有环境里跑模型，你得有合适的硬件、推理服务基础设施、监控，还要拿到匹配的开源/开放权重许可或商业许可。Llama 4、Mistral 这类开放权重模型可以自托管，但算力和运维功底一样少不了。

在 Azure 上测试、迭代，摸清模型性能

团队摸清 LLM 格局、圈出几个合适的候选模型之后，下一步就是拿自己的数据、自己的负载去测。这是个迭代过程，靠实验和度量一步步推进。前面提到的大多数模型（OpenAI 模型、Llama 4 和 Mistral 这类开放权重模型、Hugging Face 上的模型）都能在 Microsoft Foundry Models 里找到。

Microsoft Foundry（由 Azure AI Studio / Azure AI Foundry 演进而来）是 Azure 上构建 AI 应用与智能体的统一平台，帮开发者管好从实验、评估到部署、监控、治理的整个生命周期。它的模型目录能让用户做这些事：

在目录里找到你想要的基础模型，既有 Azure 出售的，也有合作伙伴和社区提供方提供的；可按任务、提供方、许可、部署方式或名称筛选。
查看模型卡片，里面有预期用途、训练数据的详细说明、代码示例，以及内部评估库上的评测结果。
通过模型基准（Model Benchmarks）面板，对比业界各模型、各数据集的基准成绩，判断哪个符合业务场景。
对支持微调的模型，用自定义训练数据做微调，借 Microsoft Foundry 的实验与追踪能力，让模型在特定负载上跑得更准。
把原始预训练模型或微调后的版本部署到远程的实时推理端点，可选托管算力或 serverless 部署，供应用调用。

注意目录里并非所有模型都支持微调，也不是都支持按量付费部署。模型的能力与限制，以模型卡片为准。

改善 LLM 的效果

到这里，我们和初创团队一起看过了各类 LLM，也认识了一个云平台（Microsoft Foundry），有了它就能对比模型、用测试数据评估、改进表现，再把模型部署到推理端点。

但什么时候该考虑微调一个模型，而不是直接用预训练模型？想让模型在特定负载上表现得更好，还有没有别的办法？

想让 LLM 达到业务需要的效果，办法有好几个。在生产环境部署 LLM 时，可以选择训练程度不同的模型类型，各自的复杂度、成本、质量都不一样。下面列几种：

带上下文的提示工程。核心思路是提问时给足上下文，确保拿到你要的回答。
检索增强生成（Retrieval Augmented Generation，RAG）。你的数据可能存在数据库或某个 web 端点上。为了让提问时带上这些数据（或其中一部分），可以先取回相关内容，拼进用户的提示词里。
微调模型。拿自己的数据对模型继续训练，模型会更精准、更贴合你的需求，但代价可能很高。

原文此处有一张图，画的是企业部署 LLM 的四种方式（带上下文的提示工程、RAG、微调、从头训练）在成本、复杂度、质量上的梯度对比，来源是 Fiddler AI 博客的 Four Ways that Enterprises Deploy LLMs。

带上下文的提示工程

预训练的 LLM 在泛化的自然语言任务上已经很好用，哪怕只给一句很短的提示词，比如半句话让它补全、或一个问题，也就是所谓的"zero-shot"（零样本）学习。

但用户越会把问题框清楚，给出详细的请求加示例（也就是上下文），答案就越准、越接近预期。提示词里只含一个示例叫"one-shot"（单样本）学习，含多个示例叫"few-shot"（少样本）学习。起步阶段，带上下文的提示工程是性价比最高的做法。

检索增强生成（RAG）

LLM 有个先天限制：回答问题只能用训练时用过的数据。训练过程结束之后发生的事实它不知道，也访问不到非公开信息（比如公司数据）。

RAG 能绕过这个限制：把外部数据切成文档块，在提示词长度上限之内补进提示词。支撑它的是向量数据库工具（比如 Azure Vector Search），从预先定义好的各路数据源里取回有用的片段，加进提示词的上下文。

企业没有足够的数据、时间或资源去微调 LLM，但又想在特定负载上把结果做得更好、降低幻觉回答、过时回答、无依据回答的风险时，这招很有用。

微调模型

微调是借助迁移学习把模型"适配"到下游任务或某个具体问题的过程。和 few-shot、RAG 不同，微调的产出是一个新模型，权重和偏置都更新了。它需要一组训练样本，每条样本是一个输入（提示词）配上对应的输出（补全）。遇到下面几种情况，微调会是首选：

用较小的任务专用模型。企业想挑个小模型针对窄任务微调，而不是反复去提示一个大的前沿模型，这样更省钱、更快。
在意延迟。场景对延迟敏感，塞不下很长的提示词；或者要学的示例数量超出提示词长度限制。
固化稳定的行为。企业有大量高质量样本，希望模型稳定遵循某种任务模式、输出格式、语气或领域风格。要解决的主要问题若是频繁更新的新事实或私有知识，该用 RAG，而不是只靠微调。

从头训练的模型

从头训练一个 LLM，无疑是最难、最复杂的路线，要有海量数据、专业人才和足够的算力。只有当企业有领域专属的场景、又握有大量领域数据时，才该考虑这条路。

知识检查

想改善 LLM 的生成结果，哪些是好办法？

带上下文的提示工程
RAG
微调模型

答案：三个都有用。先用提示工程加上下文快速见效；模型需要最新事实或私有业务数据时上 RAG；有足够多的高质量样本、要求模型稳定遵循某种任务、格式、语气或领域模式时，选微调。

动手挑战

进一步阅读：如何为你的业务使用 RAG。

继续学习

学完本课，可以看看微软的生成式 AI 学习合集，继续补课。

下一课我们讲如何负责任地构建生成式 AI 应用。