Generative AI for Beginners 第 2 课：深入探索并对比不同大语言模型（LLM）的选择与部署实践

Generative AI for Beginners 第 2 课：深入探索并对比不同大语言模型（LLM）的选择与部署实践

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners

本技术指南以开源课程generative-ai-for-beginners的立陶宛语翻译文档 translations/lt/02-exploring-and-comparing-different-llms/README.md 为核心骨架，系统讲解如何按任务类型、架构、开放程度与输出形态分类理解当前的大语言模型（LLM）生态，并在 Azure 平台上完成模型的测试、对比、微调与部署。读完本文，你将掌握一套从"选模型"到"上线模型"的完整决策与实操方法，并了解上下文提示工程、RAG（检索增强生成）、微调与从零训练四条提升 LLM 效果的技术路线。

本课程以一个教育类创业公司（startup）为主线：继第 1 课理解生成式 AI 与 LLM 的工作原理之后，本课的任务是为这个创业公司的实际业务场景挑选合适的模型。核心脉络包括：LLM 有哪些类型 → 如何分类与对比 → 如何在 Azure 上测试迭代 → 如何部署并持续提升效果。

理解不同类型的 LLM

LLM 可以根据架构、训练数据和用途进行多种维度分类。理解这些差异，能帮助创业团队为具体场景选择正确的模型，并理解如何测试、迭代和提升性能。模型的选择取决于：你打算用它做什么、你拥有什么数据、你准备投入多少成本，以及其他因素。

按任务类型划分

根据你要用模型处理的是文本、音频、视频还是图像生成等不同任务，可以选择不同类型的模型：

• 音频与语音识别（Audio and speech recognition）：Whisper 类模型是通用语音识别的经典选择。它们使用多样化的音频数据训练，支持多语言语音识别。如果你的场景是会议转写、多语种语音助手，这类模型是首选。

• 图像生成（Image generation）：DALL-E 与 Midjourney 是两个知名选项，其中 DALL-E 通过 Azure OpenAI 提供。图像生成模型常用于图像编辑、合成与风格迁移，适合营销物料生成、设计辅助等场景。本课程的 09-building-image-applications 一章有专门实践。

• 文本生成（Text generation）：绝大多数 LLM 都以文本生成为核心能力，选择范围从 GPT-3.5 一直到 GPT-4，价格梯度明显——GPT-4 是最贵的。评估时应结合能力与成本两个维度，官方推荐访问 Azure OpenAI 的 Playground 试玩区，直接测试哪个模型最贴合自己的需求。

• 多模态（Multi-modality）：如果你的输入与输出涉及多种数据类型，可以考虑gpt-4 turbo with vision或gpt-4o这类较新发布——它们把自然语言处理与视觉理解结合起来，允许通过多模态界面进行交互，例如"看图问答"、图文混合生成等场景。

关键认知：选定一个模型只意味着获得了一组基础能力，这往往还不够。企业通常拥有专有数据，需要以某种方式"告诉"LLM，这将在后文"提升 LLM 结果"部分展开。

基础模型（Foundation Models）与 LLM 的关系

"基础模型（Foundation Model）"这一术语由斯坦福大学的研究者提出，指满足以下标准的人工智能模型：

• 使用无监督学习或自监督学习训练：基于未标注的多模态数据训练，训练过程不需要人类标注数据；
• 体量巨大：基于极深的神经网络，参数规模达数十亿级别；
• 定位是"其他模型的地基"：可作为其他模型的起点，通过微调（fine-tuning）在其之上构建新模型。

以 ChatGPT 为例可以更直观地理解：早期的 ChatGPT 以 GPT-3.5 作为基础模型，OpenAI 使用对话数据对 GPT-3.5 进行了定制化适配，得到一个在对话场景（如聊天机器人）下表现更佳的精调版本。这正是"基础模型 → 领域化适配"的典型链路。

开源（Open-Source）与专有（Proprietary）模型

另一种重要的分类维度是开放性：

• 开源模型：公开可用，任何人都能使用。通常由开发公司或研究社区发布，可以查看、修改并适配到各种 LLM 用例。但它们的短板也很明显——不一定针对生产环境做了优化，效率可能不如专有模型；且资金支持可能有限，长期无人维护或不跟随最新研究更新。典型例子：Alpaca、Bloom、LLaMA。
• 专有模型：由企业持有并托管，不公开。通常针对生产使用进行了优化，但用户无法查看、修改或适配到不同用例；往往需要订阅或按用量付费；同时用户无法控制模型的训练数据，只能信任模型所有者对数据隐私和负责任 AI 的承诺。典型例子：OpenAI 系列模型、Google Bard、Claude 2。

按输出类型划分：嵌入 / 图像生成 / 文本与代码生成

LLM 还可以按照生成的输出分类：

• 嵌入模型（Embeddings）：将文本转换为数值形式（即 embedding，输入文本的数值表示）。嵌入让机器更容易理解词句之间的关系，可作为分类、聚类等其他模型的输入——这些模型在数值数据上表现更好。嵌入模型常用于迁移学习：先在一个数据充足的代理任务上训练，再把模型权重（嵌入）复用到其他下游任务。典型例子：OpenAI 嵌入模型。

• 图像生成模型：生成图像的模型，常用于图像编辑、合成与转换。它们常用大规模图像数据集（如 LAION-5B）训练，可通过**修复（inpainting）、超分辨率（super-resolution）和着色（colorization）**技术生成新图像或编辑现有图像。典型例子：DALL-E-3、Stable Diffusion 系列。

• 文本与代码生成模型：生成文本或代码的模型，常用于文本摘要、翻译和问答。文本生成模型常用大规模文本数据集（如 BookCorpus）训练，可生成新文本或回答问题；代码生成模型（如 CodeParrot）则用大规模代码库（如 GitHub）训练，可生成新代码或修复既有代码缺陷。在后续课程中，这类能力直接支撑了 06-text-generation-apps 的文本生成应用实践。

按架构划分：Encoder-Decoder 与 Decoder-only

用一个比喻来理解架构差异：假设你的经理让你为学生出考题，你有两位同事——一位负责创作内容，另一位负责审阅。

• Decoder-only 模型：像内容创作者——可以看着主题和你已写的内容，基于上下文继续生成内容。非常擅长撰写引人入胜、信息丰富的内容，但在仅需分类、检索或编码信息的任务上并非最佳。代表：GPT 系列（如 GPT-3）、Llama 系列。
• Encoder-only 模型：像审阅者——审视写好的课程与答案，识别它们之间的关系并理解上下文，但不擅长生成内容。代表：BERT。
• Encoder-Decoder 模型：既能创作又能审阅——既理解输入又生成输出。代表：BART、T5。

从仓库证据看，本课程第 15 课 15-rag-and-vector-databases/README.md 进一步说明：RAG 架构正是基于 Transformer 的编码器-解码器两部分实现的——用户问题被"编码"成语义向量，再"解码"到文档索引并基于用户查询生成新文本，LLM 使用编码器-解码器模型生成输出。

服务（Service）与模型（Model）的区别

最后区分两个常被混用的概念：

• 服务（Service）：云服务商提供的产品，通常是模型、数据和其他组件的组合。服务针对生产环境优化，往往通过图形界面更容易使用；但不一定免费，可能需要订阅或按用量付费——换取的是使用服务方设备与资源、成本优化和轻松扩展。典型例子：Azure OpenAI Service，提供按量付费（pay-as-you-go）套餐，即用户按实际使用量计费；同时在企业级安全和负责任 AI 框架之上提供模型能力。
• 模型（Model）：服务的核心组件，本质是带参数、权重和其他组件的神经网络，常是基础模型（如 LLM）。企业可以本地运行模型，但需要购置设备、搭建扩展架构、获取许可证或使用开源模型。例如 LLaMA 可以直接使用，但运行时需要足够的算力。

如何在 Azure 上测试与迭代不同模型

当团队完成对 LLM 生态的调研、锁定几个候选模型后，下一步就是用自己的数据和工作负载测试它们。这是一个通过实验与度量驱动的迭代过程。

前文提到的绝大多数模型（OpenAI 模型、Llama2 等开源模型、Hugging Face transformers 模型）都可以在Azure AI Studio 的模型目录（Model Catalog）中找到。Azure AI Studio 是专为开发者设计的云平台，用于构建生成式 AI 应用并管理从实验到评估的完整开发生命周期，把各种 Azure AI 服务统一到一个带友好图形界面的中心。模型目录支持以下操作：

• 查找感兴趣的基础模型：目录中同时包含专有模型与开源模型，可按任务、许可证或名称筛选；为改善搜索体验，模型被组织成多个集合（如 Azure OpenAI 集合、Hugging Face 集合等）。

• 查看模型卡（Model Card）：包含预期用途与训练数据的详细描述、代码示例，以及内部评估库中的评估结果——这是判断模型是否适合你的场景的第一手资料。

• 对比模型基准（Model Benchmarks）：通过模型基准面板，对比各模型与业界数据集上的表现，评估哪个模型最贴合业务场景。

• 微调（Fine-tuning）：利用 Azure AI Studio 的实验与追踪能力，用自定义训练数据适配模型，提升其在特定工作负载上的表现。

• 部署（Deploy）：将原始预训练模型或微调版本部署到远程实时推理端点——可选托管计算（managed compute）或无服务器 API（serverless API，按量付费）——供应用直接调用。

[!NOTE] 并非目录中所有模型目前都支持微调和/或按量付费部署。请查看模型卡，了解各模型的能力与限制。

从本仓库的源码实现可以印证这套"测试-迭代-部署"链路的落地方式。共享工具模块 shared/python/api_utils.py 提供了create_openai_client()与create_azure_openai_client()两个工厂函数：前者从OPENAI_API_KEY环境变量读取密钥，后者从AZURE_OPENAI_ENDPOINT与AZURE_OPENAI_API_KEY构造指向<endpoint>/openai/v1/的客户端，恰好对应"在 Azure 上接入 OpenAI 模型"的生产路径。而文本生成示例 06-text-generation-apps/python/oai-app.py 展示了通过 Responses API 调用模型的最小代码：

from openai import OpenAI import os from dotenv import load_dotenv # load environment variables from .env file load_dotenv() # configure OpenAI service client client = OpenAI() deployment = "gpt-5-mini" # add your completion code prompt = "Complete the following: Once upon a time there was a" # make a request using the Responses API response = client.responses.create(model=deployment, input=prompt, store=False) # print response print(response.output_text)

更复杂的交互式示例 06-text-generation-apps/python/oai-app-recipe.py 展示了如何把用户输入插值进 prompt、用max_output_tokens=600控制输出长度，并通过两次调用完成"生成菜谱 → 生成购物清单"的两段式工作流——这正是"用真实工作负载迭代测试模型"的写照。

提升 LLM 结果：四种途径与选型决策

在与创业团队探索了各类 LLM 与云平台之后，下一个关键问题是：什么时候应该微调模型，而不是直接使用预训练模型？还有哪些方式可以提升模型在特定工作负载上的表现？

企业在生产环境部署 LLM 时，可以选择训练程度不同、复杂度/成本/质量各异的多种模型。总体上有四种思路：

上下文提示工程（Prompt Engineering with Context）

预训练 LLM 在通用自然语言任务上表现很好，即使只给一个短提示（如待补全的句子或一个提问）——这就是所谓的**零样本（zero-shot）**学习。

但用户提供的上下文越充分——包含详细请求和示例——回答就越准确、越贴近预期：

• 提示中只含一个示例 →单样本（one-shot）学习；
• 提示中含多个示例 →少样本（few-shot）学习。

上下文提示工程是最具成本效益的起步方式，几乎零额外开销即可明显改善输出质量。

检索增强生成（RAG）

LLM 有一个固有局限：只能使用训练时见过的数据来生成答案。这意味着它们不知道训练之后发生的事实，也无法访问非公开信息（如公司内部数据）。

RAG 正是为此而生：一种在考虑提示长度限制的前提下，以文档片段形式用外部数据扩充提示的技术。它由向量数据库工具（如 Azure Vector Search）支撑——这些工具从各种预定义数据源检索有用片段，并追加到提示的上下文里。

RAG 非常适合以下情况：企业没有足够的数据、时间或资源去微调 LLM，但仍希望在特定工作负载上提升表现，同时降低幻觉、过时或不实回答的风险。

纵深补充：第 15 课 15-rag-and-vector-databases/README.md 详细展开了 RAG 的工程实现——先对文档分块（chunking）、转换为嵌入并存入向量数据库；用户提问时，检索器将问题编码为查询向量，通过最近邻（如sklearn.neighbors.NearestNeighbors）找出最相似的文档片段，拼入提示后交给 LLM 生成 grounded 回答。该课还提供了split_text()分块函数、余弦相似度/欧氏距离/点积等相似度度量、以及基于 Responses API 的chatbot()完整实现，可作为本课的延伸阅读。

微调模型（Fine-tuned Model）

微调是借助迁移学习把模型"适配"到某个下游任务或特定问题的过程。与少样本学习和 RAG 不同，微调会生成一个全新的模型——权重和偏置都被更新。它需要一组训练样本：每条由单一输入（提示）及其关联输出（补全）组成。

以下情况优先考虑微调：

• 使用更小的任务专用模型：与其反复调用大模型，不如微调一个较小的模型处理窄任务，得到更具成本效益、更快的方案；
• 关注延迟（Latency）：特定用例对延迟敏感，无法使用超长提示，或需要学习的示例数量超出了提示长度上限；
• 持续更新：企业拥有大量高质量数据、可靠的标签以及持续更新这些数据所需的资源。

从零训练模型（Trained Model）

从零训练一个 LLM 无疑是最困难、最复杂的方案，需要海量数据、熟练的人才与足够的算力。只有在企业拥有特定领域用例 + 大量领域数据时才应纳入考虑。

知识检测

问题：提升 LLM 补全结果的好方法有哪些？

1. 上下文提示工程
2. RAG
3. 微调模型

答案：三种方法都有效，但适用条件不同——如果时间、资源和高质量数据充足，微调是保持长期相关性的更优选择；如果只想快速改善结果且时间有限，则应优先考虑 RAG。务实的路线是：先用上下文提示工程做低成本快速优化，再视数据与时效需求引入 RAG，最后在样本质量足够高、需要稳定行为时升级到微调。

动手挑战

查阅更多资料，了解如何将RAG 应用于你的业务场景：例如结合本仓库第 8 课 08-building-search-applications 的搜索应用实践（其requirements.txt包含 openai、pandas、scikit-learn 等依赖），用你自己的文档数据构建一个"先检索、再生成"的问答链路，直观体会 RAG 相比纯提示工程的提升。

继续学习

完成本课后，可继续学习第 3 课：如何负责任地使用生成式 AI，其中讨论了构建生成式 AI 应用时的伦理与安全实践。

免责声明：本文章所对应的立陶宛语课程文档由 AI 翻译服务（Co-op Translator）自动生成，可能存在误差或不准确之处；原文以其母语版本为准。本文在保留该翻译文档核心内容的同时，结合了当前仓库的英文原版课程与源码实现进行佐证与补充。

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners