AI产品开发的艺术——探索与评估语言模型

本章内容概览

• 理解语言模型的能力
• 选择合适的语言模型
• 针对特定任务定制语言模型
• 在更广泛的应用场景中考虑语言模型
• 评估语言模型

本章将带你深入了解语言模型（LM）的世界，这些模型可应用于多种任务，从内容创作，到文本摘要、翻译，再到更复杂的问题解决。你将获得扎实的语言模型知识，帮助你在模型选择、部署、定制及风险管理方面做出明智决策。同时，你需要支持工程师在更大AI系统中设计语言模型的集成、适配和评估方案。

术语说明
虽然大型语言模型是生成式AI爆发的主要推手，但目前也有向更小、更高效模型下沉的趋势。本文中，“语言模型”（LM）是一个通用术语，涵盖参数量超过20亿的大型语言模型（LLM）和参数量低于20亿的小型语言模型（SLM）。

在探索过程中，我们将跟随创业者 Alex 的故事。Alex 最近辞掉全职工作，准备打造一款内容生成应用的最小可行产品（MVP）。他既懂编码又懂市场营销，目标是为企业创造高质量、个性化内容，并借助语言模型自动化大量内容创作任务。为了建立竞争壁垒，这款应用必须保证高事实准确性，同时体现每个客户独特的品牌、语调和策略。Alex 仅有三个月和有限预算，面临紧张的期限和高期望。在使用主流大型语言模型如 GPT-4 进行概念验证时，他迅速意识到这些模型的挑战和局限，必须在易用性、定制化和可扩展性之间取得平衡，同时解决偏见和幻觉等问题。

本章为使用语言模型奠定基础。你将了解语言模型的工作原理，以及它们如何影响最终用户体验。作为产品经理，你在这一过程中扮演关键角色——明确目标、确保技术符合用户需求，并做出战略部署和优化决策。同时，你还需评估风险、保证伦理合规，并与工程和数据科学团队紧密合作，确保模型契合整体产品愿景。接下来，我们将探讨如何为具体产品和使用场景定义模型需求，帮助你权衡性能、成本和扩展性。你将学会基于这些需求评估不同模型，选出最适合应用目标的方案。产品经理在这一评估流程中发挥主导作用，确保选用的模型能实现理想的用户和业务效果，避免不必要的复杂度和开销。

在第6至9章中，我们将以此为基础，深入探讨提示工程（prompt engineering）、检索增强生成（RAG）、微调和智能代理AI等更高级主题。第5至9章将为你提供全面指南，助你掌握生成式AI，构建技术领先且具市场竞争力的应用。

5.1 语言模型的工作原理

尽管时间紧迫，创业者 Alex 仍然明白，使用语言模型（LM）需要更深入的技术知识。他知道这些模型常被过度炒作，实际能力并非完全如宣传那样。将第三方语言模型集成到应用中，就意味着要承担其不完善和潜在风险的责任——而这些风险往往事先未知。扎实掌握技术基础将帮助他避开常见陷阱（例如幻觉问题），并做出更明智的产品决策。为此，Alex 学习了 Andrew Ng 的《人人都能学的生成式AI》课程（mng.bz/4nAQ），并阅读了多篇优质相关文章（详见本书末尾的“进一步阅读”和“参考文献”）。让我们从他的学习中提炼出关键洞察，重点关注训练数据、训练过程，以及针对具体任务定制语言模型。

5.1.1 理解语言模型的训练数据

传统上，训练语言模型所用的数据是涵盖多种文体的文本数据，如文学作品、用户生成内容和新闻报道。数据可能是多语言的，且通常还包含代码。通过接触各种文本类型，模型学会捕捉语言的细微差别，并将其融入生成结果中。训练数据极大影响语言模型的知识范围。例如，如果模型从未见过意大利语文本，就难以期望它能用意大利语与你交流。

在将第三方语言模型集成到你的应用前，务必仔细审查其训练数据。这些数据决定了模型的优势，也带来限制和风险。如果训练数据不完整或存在偏见，模型的输出可能会出乎意料地有缺陷。举例来说，若你测试一个为客服设计的聊天机器人，发现它难以理解新的俚语，或在回复中低估某些群体，这正是训练数据存在空缺的直接表现。事先了解这些风险，有助于你预测问题、设定合理预期并实施保障措施，提高模型的可靠性。以下是影响模型性能和安全性的训练数据关键因素：

• 规模与多样性
  训练数据的规模和多样性使模型能够捕捉语言的广泛理解，包括语境、语气和事实知识。这种广泛知识使模型在不同领域表现良好，但可能缺乏在训练数据中代表性较少的专业领域的深度专长。如果你的产品需要特定领域知识（如法律或医疗），通用语言模型可能产生听起来流畅但不精确甚至错误的内容。在 Alex 的应用中，规模和多样性尤为关键：一方面应用要覆盖多个行业，另一方面模型不仅要语言流畅，还需风格多变，能体现每个公司或品牌独特的声音。
• 偏见
  训练数据来自互联网和各类开放资源，因此难免反映出其中的偏见和刻板印象。语言模型可能无意中延续性别、种族或文化偏见（详见文献[1]关于语言模型偏见的综述），甚至倾向某些社会或政治观点。一个典型例子是模型会将高薪职业（如医生）与男性关联，而低薪职业（如护士）则更紧密地与女性联系。当开发用户直接与语言模型交互的产品（如 Alex 的内容生成应用）时，必须警惕偏见输出的风险，并建立识别及缓解机制。尤其是生成内容最终会公开，Alex 测试了带有微妙偏见的输出后，意识到不能指望普通用户主动发现并消除这些问题。
• 数据质量与噪声
  模型训练集中的数据并非全部高质量或经过事实验证。若模型以用户生成内容、博客或社交媒体数据训练，可能吸收错误信息、猜测性内容或错误概念。若你的应用依赖语言模型生成事实准确且可靠的内容，就需要增加额外的输出校验。Alex 希望为企业生成可验证内容，这就需要额外的事实检查或人工审核，确保生成文本的质量和真实性。第7章你还会学习如何利用检索增强生成（RAG）减少事实错误输出的风险。
• 知识截止时间
  大多数语言模型的训练数据截至某一固定时间点，无法访问实时信息或更新，除非连接外部数据库。其知识冻结于训练数据收集时。例如，截至2025年3月，GPT-4o的训练数据截止至2023年10月，而Anthropic的Claude 3.7 Sonnet截止至2024年10月。Alex 的客户希望在传播和公共形象上领先潮流，因此内容必须基于最新趋势、数据和突发新闻。除了优选截止时间较晚的模型，他还计划辅以实时数据源以确保内容准确且相关。
• 数据隐私与敏感性
  训练数据有时包含从公开渠道抓取的个人信息或敏感数据。尽管通常采取措施降低风险，但依然是关注点——特别是涉及版权或专有内容时。比如，有些基于公开图像训练的AI模型因未经艺术家许可使用作品而遭受争议，引发伦理和法律问题。对企业而言，这强调了审查训练数据来源、避免无意侵犯知识产权和隐私权的重要性。

大多数语言模型都会提供训练数据的描述（好坏参半）。若模型在学术论文中首次亮相，通常会说明训练数据集。否则，可查看模型中心（如 Hugging Face 的模型卡 mng.bz/Ow9a）或提供商官网的文档。但要准备面对不完整或模糊的资料——在AI热潮中，许多开发者更注重快速发布，忽略了训练数据的准确和透明。随着人们逐渐意识到训练数据对下游任务和输出的影响，关于改进训练数据文档和透明度的讨论正持续进行（例如Google 的《数据卡手册》sites.research.google/datacardspl…）。

5.1.2 语言建模任务

当 Alex 第一次使用 ChatGPT 时，他被这款能进行自由流畅、富有同理心对话的工具深深吸引，感觉像在和一位知识渊博、高效的真人交流。像大多数外行人一样，Alex 并不知道 ChatGPT 为实现这种沟通能力，经历了所谓“完成学业”的阶段——用技术语言说，就是通过人类反馈的强化学习（RLHF）进行了微调。

在基于 AI 模型构建产品时，你应了解其训练过程，这有助于你与技术团队沟通，并支持在定制调优、用户体验设计以及成本和风险管理上的合理决策。让我们回顾每个语言模型在“高中阶段”即预训练中必须学习的内容。事实证明，这一阶段的目标相当基础——具体来说，给定过去或上下文，语言模型学习预测文本中的下一个词。掌握了这一技能后，模型变得多才多艺，可以被适配用于更多专业任务。

为理解这一预训练目标，Alex 试着用不同模型测试一句话：“Hey, I am super excited about working with you and trying new stuff!” 他访问了开源AI模型聚集地 Hugging Face，并在多个先进语言模型的推理界面测试这句话。图5.1展示了他从 Mistral 模型获得的输出示例。

图5.1 展示了 Mistral 模型，该模型以语言建模的“原始”目标进行训练，但未能顺畅进行对话。

Mistral 的回复语法正确，但并没有提供有帮助的对话内容。此外，模型为何在句子中途停止？对 Alex 来说，他不清楚该如何继续这段对话。于是他回到 ChatGPT，尝试了同样的问题，见图5.2。

图5.2 显示了经过微调以进行类人对话的 ChatGPT。

与 Mistral 不同，ChatGPT 能进行流畅且令人舒缓的对话，并且会努力完成句子。结果差异如此之大，是因为两者训练目标不同。训练过程中，Mistral 旨在遵循语言建模的“原始”目标。它基于前后文（如图5.3所示）预测缺失的词语。随着词语不断生成，模型最终输出一段尽可能连贯且正确的完整句子或文本。

图5.3 语言建模的目标是基于上下文预测词语。

这可以通过三种方式实现，分别是序列到序列转换（sequence-to-sequence transduction）、自回归（autoregression）和自动编码（autoencoding）。虽然这三种方法都要求模型掌握广泛的语言知识，但最终生成的模型在特定任务上表现出色。下面我们来逐一了解这些目标：

• 序列到序列转换
  编码器-解码器架构和Transformer模型最初解决的任务是序列到序列转换，即将一个序列“翻译”为另一种表示形式的序列。经典的序列到序列任务是机器翻译，但其他任务如文本摘要和代码生成也可以使用该目标。需要注意的是，输出不一定是文本，也可以是计算机代码或图像等其他格式。序列到序列语言模型的一个例子是双向自回归变换器（BART）系列（mng.bz/YZea）。
• 自回归
  第二种任务是自回归，这是语言建模的基础目标。在自回归中，模型学习基于之前的标记预测下一个输出（标记）。单向性的限制限制了学习信号——模型只能利用预测标记的左侧或右侧信息。这是一个显著的限制，因为在语言中，词语的含义可能依赖于前后文。例如，考虑动词“written”对图5.4中句子的双向影响。

图5.4 词语与其前后词语都可能存在语义关联。

• 在这里，单词 paper 的位置受限于动词 written 所能书写的对象。相比之下，student 一词的位置则受限于表示人类，或至少是另一种具备写作能力的智能实体。

GPT 系列及许多其他大型商业自回归语言模型正是当前生成式AI热潮的主要驱动力。这些模型广泛适用于对话、摘要和文本生成等大多数语言任务。但由于缺乏结构化知识表示，它们往往会产生幻觉（详见“理解与应对幻觉”侧栏）。

第三种任务——自动编码（autoencoding）——解决了自回归语言模型的单向性问题。训练自动编码器时，先将输入中一定比例（通常为10%-20%）的标记遮蔽，模型学习根据上下文（包括前后词）重建正确输入。典型的自动编码语言模型是双向编码器表示变换器（BERT）系列[2]。通过学习更完整的语义上下文，自动编码模型能够构建更优的知识表示，适合命名实体识别和情感分析等分析类任务。

理解与应对幻觉（Hallucinations）

AI 幻觉指语言模型生成的虚假、误导或无意义但看似合理的信息。这类错误源于模型基于模式预测文本，而非从结构化知识库检索事实。常见幻觉类型包括：

• 捏造事实
  模型编造不存在的细节。
  示例：聊天机器人声称爱因斯坦因相对论获得诺贝尔物理学奖（实际上他因发现光电效应定律获奖）。
• 不连贯或自相矛盾的陈述
  AI 生成逻辑不一致的文本。
  示例：AI 助手在同一回应中说埃菲尔铁塔既在巴黎又在伦敦。
• 错误归因引用或来源
  模型将话语错误归给某人或创造不存在的引用。
  示例：模型错误地将马克·吐温的话归给莎士比亚。
• 虚假的因果关系
  模型假设事实间不存在的联系。
  示例：“每天早晨喝咖啡能延长寿命”，但无科学依据。

发生原因：
语言模型不“知道”事实，只是基于概率预测词语。
缺乏对现实世界的理解和结构化知识检索。
训练数据庞大且可能包含矛盾或不可靠的信息。

缓解策略：
用可靠来源对AI输出进行事实核查。
利用检索增强生成（RAG）技术调用真实知识库（见第7章）。
用领域专属数据微调模型减少错误，特别是通过记忆微调将硬事实植入模型知识（见第8章）。

更具体的预训练目标可为模型在下游任务上的表现提供重要线索。例如，对话和内容创作最适合自回归模型，分析类任务则更符合自动编码目标。截止2025年，自回归模型主导市场，是最强大的模型，因而往往是文本生成以外任务的优选，且在序列到序列及分析任务中表现出色。

注释
想了解更多预训练过程和目标，请参考我的文章《为你的NLP用例选择合适的语言模型》（mng.bz/Gw4J）。

语言建模是强大的上游任务，但仅凭随机文本生成的模型业务价值有限。幸运的是，这项技能对文本生成以外的多种任务也有帮助。能够生成语言的模型还有潜力解决更专业的语言挑战，如分类、摘要、问答和对话。通过更高级目标的进一步微调即可获得这些能力。

5.1.3 扩展语言模型的能力

语言模型的基础预训练赋予了它广泛的语言和世界知识，但大多数实际任务需要更多能力。通常，语言模型需要理解用户意图并在特定上下文中做出响应——这超出了其预训练的范畴。Alex 在比较 Mistral 和 ChatGPT 时深刻体会到了这一点。Mistral 虽然训练目标广泛但较为“原始”，能生成正确的英语，却在语义上令人困惑；而 ChatGPT 经过针对人类对话的微调，似乎“理解”了 Alex 的提问，使交互更加流畅和直观。

除了对话和内容创作，Alex 还设想了应用中语言模型可以承担的几个更具体任务：

• 生成可执行代码
  为了构建竞争壁垒，Alex 希望他的应用不仅能生成文本，还能访问不同数据源以指导内容创作。例如，用户可能想查看网站分析数据，了解当前受关注的话题和产品。在此情况下，模型会调用函数获取相关数据，并基于数据为客户定制报告。这一功能使应用能够动态生成内容，结合实时数据提升生成材料的相关性。
• 执行任意指令
  Alex 应用的另一个关键功能是遵循用户特定指令。例如，客户可能要求“将产品描述缩短并更活泼”，语言模型会理解指令，数秒内调整内容以符合期望的语调和风格。稍后，同一客户可能要求“把内容改成正式的新闻稿”，语言模型也能再次调整内容以满足新需求。灵活执行各种指令，使 Alex 能提供高度个性化的工具，满足从专业到创意的多样客户需求。
• 分析类任务（信息提取、情感分析等）
  Alex 希望为用户提供更深入的公共话语洞察，帮助生成紧跟潮流的内容。语言模型可从公共文档中提取相关数据，分析情感倾向，识别热点话题等。Alex 计划将这些洞察呈现在美观的仪表盘中，供用户随时查看市场动态。

为高效实现这些功能，Alex 考虑采用不同的微调方法。他可针对特定任务（如情感分析、函数调用）使用监督微调，对更灵活的任务采用指令微调。这些方法将在第8章深入探讨。虽然 GPT-4 等主流大型语言模型开箱即用也能完成许多任务，但成本高且体积庞大。微调较小的专业模型可能更高效且可持续。

语言模型领域迅速发展，掌握成本与能力之间的权衡对成功集成至关重要。通过战略性微调模型并规避特定上下文风险，你可以构建强大且高效的应用。

5.2 语言模型的使用场景

语言模型（LM）令人惊叹且多功能的能力也伴随着一定的缺陷——尽管它们非常灵活，但也容易犯错。它们会撒谎、产生幻觉、输出伦理上有问题的内容——而且这些错误通常表现得非常流畅、自信且积极。为了有效选择和集成语言模型，你需要现实地评估它在你的应用中可能出现的失败情况，以及如何应对这些失败。例如，它会不会生成面向客户的内容，如果内容带有偏见或幻觉，可能会影响你的品牌？它会不会生成执行时可能破坏周边系统的代码？它会不会做出导致有害后续决策的预测？这些失败的影响取决于语言模型在应用更大环境中的使用方式——用户是否直接与其交互，是否有下游软件组件执行它的输出，等等。例如，对于程序化使用来说，偏见问题相对较小，但如果在直接且未经过滤的用户交互中出现偏见，则可能带来严重影响。

本节将探讨语言模型的三种广泛使用模式：开放式的用户交互、程序化使用，以及明确的专用任务。我们将从输入和输出的多样性与复杂性角度对它们进行分析，如图5.5所示。

图5.5 三种常见的语言模型使用模式

复杂度越高，实现难度也越大。下一节将概述每种模式的需求和风险。在第6至9章，我们将深入探讨语言模型的集成以及复合型AI系统的设计，进一步细化这些内容。

5.2.1 用户与模型的直接交互

在 Alex 的应用中，用户直接与语言模型交互以生成定制内容，如图5.6所示。例如，市场团队可能需要一篇博客文章，销售主管则可能需要一份个性化的销售提案。

虽然非常常见，但直接交互是一个高风险场景。通过让用户直接接触模型，你可以充分利用其多功能性，但风险也很大，因为你无法控制输入和输出的空间。潜在的输入和输出数量是无限的，恶意用户和表现不佳的模型可能带来危害。因此，你应选择具备以下特征的语言模型：

• 强有力的安全防护措施（如伦理准则）和去偏见的训练数据，以防止偏见或不当回复
• 较高的语言能力，能处理各种输入和风格
• 扎实的世界知识，减少幻觉产生
• 稳定且响应较快（延迟要求）

主流商业大型语言模型（LLM），如 GPT-4、GPT-4o 和 Anthropic 的 Claude，提供了良好的起点。一个实用的经验法则是，观察模型提供者是否方便地在试玩平台、对话界面等处开放其模型访问权限。若访问较为自由（如部分 OpenAI 模型），通常意味着模型性能经过广泛测试且关键的安全防护已就绪。

此场景可通过 LLM 路由器和级联设计模式加以优化——这些模式利用多模型各自优势，降低成本并提升性能。在路由器模式中，位于用户与模型之间的路由器会分析用户输入，并将其导向最合适的模型，如图5.7所示。交互仍为直接，路由器提高了高质量且无害回复的概率。

在级联模式中，用户请求会依次传递给多个模型——通常从简单到复杂——直到某个模型给出有信心的答案，如图5.8所示。两种模式均可结合“人机协作”机制，将复杂或困难请求转给人工客服处理。

这些多模型方案提升整体效率，因为较小且成本低的模型可处理大量请求。例如，在典型客户服务聊天机器人中，十几个常见问题占据了大部分客户咨询量。大部分标准请求可由相对简单的模型处理，只有少量复杂请求需转给更昂贵的模型或人工客服。与仅使用最先进的单一大型语言模型相比，LM 级联能节省高达98%的成本（见文献[3]）。

第7章你还将学习本章前面提到的检索增强生成（RAG）技术。在该架构中，语言模型辅以外部数据库支持，降低幻觉风险。

图5.7 语言模型路由器分析用户请求，并将其发送到最合适的模型
（或可选地，发送给人工客服）。

图5.8 在大型语言模型级联中，用户请求会依次传递给多个模型，直到某个模型给出高度自信的答案。

5.2.2 程序化使用

在第二种使用模式中，模型生成的代码由下游组件或插件自动执行（见图5.9）。例如，在函数调用场景中，模型会选择并运行合适的函数；在 Text2SQL 场景中，模型生成 SQL 查询。

输入可以直接来自用户，使模型面临无数可能的请求，这与前面提到的直接交互场景类似。这种模式常见于辅助编程系统（copilot），大型语言模型连接多个插件，根据用户请求按需调用。或者，输入可能来自另一个代理语言模型。在这种情况下，输入仍是非结构化的自然语言，但因为由AI生成，通常更可预测，开发者更容易控制。代理语言模型的输入往往遵循其已学会的模式，减少了意外变动。代理系统将在第9章中详细介绍。

输出空间——如计算机代码或定义明确的表示形式（例如 JSON）——比自然语言输出更结构化、变化更少。然而，这里存在两个主要风险。首先，错误的代码可能会干扰应用流程，令用户感到沮丧。其次，代码虽然有效，但可能以有害的方式错误。例如，假设你用语言模型生成 SQL 查询，它却生成了 DELETE 查询而非纯读取查询（SELECT）。如果没有适当的安全防护措施和保障机制，自动执行这类有缺陷的代码可能带来不可控的后果。

生成程序化输出的模型需要熟悉下游组件的工作原理和约束条件。在大多数情况下，这需要专门的训练或微调。例如，NexusRaven 语言模型针对函数调用进行了调优，多款模型如 PaLM 和 T5 则针对将用户问题翻译成 SQL 查询（Text2SQL）进行了微调（详见我的文章《通过对话式数据访问打造信息优势》mng.bz/z2lA）。

语言模型的程序化使用是 AI 代理的重要组成部分，它们能够协调多种软件工具。第9章将深入讲解代理系统。

5.2.3 用于预定义任务的语言模型

另一种无需直接暴露给用户即可使用语言模型的强大方式，是在后端针对特定任务应用它。在这种情况下，语言模型处理的输入空间由开发团队严格控制。例如，它可执行实时摘要、情感分析或个性化推荐。输出通常以结构化或半结构化形式（如 JSON 格式）呈现，并可在展示给用户前进行额外验证。

你还可以选择离线处理而非实时生成，以获得更受控且可靠的输出。这时，语言模型将结果写入数据库，而非直接展示给用户（见图5.10）。这是使用语言模型执行特定任务的保守且安全的方式。数据库生成后，你可以对数据进行各种检查和过滤，确保其准确性和适宜性。此外，依据吞吐量，延迟要求可相应放宽——比如若你夜间运行语言模型分析，很多用户可能不在意耗时是2小时还是5小时。这种做法在 B2B 场景尤为实用，因用户要求极高的可靠性，任何不确定性或错误都可能导致业务停摆。但请注意，这种方式牺牲了语言模型的实时灵活性，将其限制于固定分析集，类似传统预测性 AI 的使用方式。

图5.10 语言模型可用于离线处理，允许对其输出进行额外验证。

控制语言模型规模

鉴于如今访问大型语言模型变得非常便捷，许多团队在各类任务中广泛使用它们，包括一些基础任务如分类。但这些任务往往可以用更小的语言模型或自行训练的预测模型来完成。为了了解你实际需要投入的AI能力，可以尝试以下练习：

• 在使用最先进的大型语言模型达到高准确率后，尝试用参数量更小的语言模型调整性能。
• 利用大型语言模型生成任务的训练数据，然后训练一个预测模型，比如逻辑回归或简单神经网络，来执行该任务。

使用大型语言模型的成本可能迅速累积，且一旦你的AI系统成熟，回退模型和架构决策将变得困难。建议从一开始就审慎考虑资源使用。

工程视角：结构化语言模型输出

随着AI代理的流行，语言模型越来越多用于生成结构化输出，无论是代码（见5.2.2节）还是数据（见5.2.3节）。在这些场景中，工程师需控制语言模型的行为以遵守特定编程语言或数据模式。以下是一些结构化生成的选项：

• 函数调用语言模型
  一些模型专门针对函数调用进行微调，例子包括 Salesforce 的 ActionGemma（mng.bz/0z7v）和 Nexusflow 的 NexusRaven（github.com/nexusflowai…）。
• 推理时的结构化生成
  包如 Outlines（github.com/dottxt-ai/o…）和Guidance（github.com/guidance-ai…）在生成过程中强制执行结构约束。
• 事后验证数据结构
  Pydantic（docs.pydantic.dev/）是一个流行库，用于生成后验证模型输出，确保其符合预定义的模式。
• 结构化输出的API功能
  商业语言模型提供商也提供控制模型输出的选项。例如，OpenAI API 支持函数调用（mng.bz/KwEO）和结构化生成（mng.bz/9ywr），为语言模型集成提供灵活性。

这些方法保证了在对精度和严格输出格式有高要求的应用中的可靠性。

要构建成功的语言模型应用，必须了解其局限性，并通过实时交互、自动化或后端处理，准备好管理相关风险。基于此认知，你现在可以探索可用的语言模型选项，并评估哪些模型最适合你的需求。下一节，我们将深入介绍从通用模型到针对特定任务微调的小型模型的语言模型生态，并讨论如何评估适合你应用的最佳选择。

5.3 语言模型生态概览

在语言模型（LM）生态中导航可能让人感到不知所措。截至2025年初，仅开源平台 Hugging Face 就托管了超过15万个文本生成模型。再加上众多商业选项，选择似乎无穷无尽。了解每种模型类型的优势与权衡，是选择最适合你需求模型的关键——无论你是追求快速部署、深度个性化、增强隐私，还是成本与复杂度的最佳平衡。本节将语言模型划分为五大类，比较每类的优缺点及适用场景，详见表5.1。帮助你快速比较选项，识别最适合你应用的方案。

5.3.1 主流商业大型语言模型（LLM）

来自 OpenAI、Cohere、Anthropic 等供应商的大型商业模型属于“LLM即服务”（LLMaaS）类别。对于希望快速将 LLM 功能集成到应用中的公司而言，这是常见且默认的起点。这类模型的主要优势是通用性强、部署速度快。预训练模型可通过API访问，适合缺乏内部 AI 专业知识或处于探索阶段的团队。

表5.1 不同语言模型类别的优缺点与使用场景比较

类型	优点	缺点	适用场景
主流商业LLM	GPT-4o、Anthropic Claude等	快速部署；API易集成；供应商维护更新；知识广泛	规模大，成本高；微调定制受限；同质化，无壁垒；隐私问题
开源语言模型	Llama、Mistral、Qwen等	完全掌控；灵活性强；无API成本；隐私更好	基础设施需求高；需技术专长部署维护
推理语言模型	DeepSeek、OpenAI o1、o3等	适合复杂（多步）推理；泛化能力强	更昂贵，推理速度慢；需更多提示工程
小型语言模型（SLM）	Phi-3、Orca 2、小型Llama版本	速度快，成本低	适合简单特定任务
多模态LLM	Gemini	支持多输入类型（文本、图像等）；用户体验丰富	资源密集，部署复杂；文本任务可能用不上

LLMaaS 还为快速原型和迭代提供了高效路径。预训练模型功能强大，涵盖文本生成、摘要、问答等多种任务。开发者可通过调整提示快速获得结果，无需昂贵训练基础设施或机器学习运维（MLOps）管道。Alex 就是从这里起步，使用 GPT-4o 实验自动化写作任务。

然而，随着规模和复杂度增长，LLMaaS 的局限也显现。其一是定制能力有限。尽管可通过提示与模型交互，但往往无法完全集成特定业务或客户数据来个性化输出。Alex 很快发现 GPT-4o 在风格上存在局限——大多数用户能分辨出AI生成内容与人工内容，AI内容显得生硬、泛泛而谈，难以传达品牌独特声音。

为弥补开箱即用解决方案与定制模型之间的差距，OpenAI、Anthropic 等提供“上下文学习”微调，即将微调数据作为提示传入模型。相比第8章介绍的模型微调，这种方法定制程度有限，且因提示过长可能导致性能下降。

对 Alex 来说，当他将内容生成应用扩展到多行业时，这可能成为瓶颈。虽然上下文学习可注入一定个性化，但无法让模型完全整合公司特有的品牌、风格和策略信息，输出内容仍难满足客户对细腻内容的期待。此外，微调数据量有限，管理庞大提示结构也可能带来维护上下文等新挑战。

5.3.2 开源模型

开源模型为商业 LLM 提供了灵活且强大的替代方案，使企业在模型部署、微调和数据隐私方面拥有更大控制权。Hugging Face 等平台提供成千上万可免费下载、微调和部署的模型。截止2025年初，流行开源模型包括 Llama、Mistral 和 Qwen 家族，涵盖多种规模与能力，满足不同业务需求。

开源语言模型的关键优势在于其开放性，允许你利用预训练成果的同时，全面掌控基础设施和部署流程。这种灵活性使你能在自有服务器上安全处理敏感数据，尤其适合对数据法规要求严格的行业（如医疗、金融）。企业内部部署这些模型，可以消除向外部第三方服务器发送用户输入或专有数据的担忧，这在商业 LLM 中通常是必须的。

但这种方式也对 AI 和基础设施管理提出了较高要求。开源模型的成功应用依赖于选择合适模型、平衡模型规模与部署成本，以及构建稳健的 MLOps 基础设施。例如，Llama 3 提供多种规模（如8B和70B参数），较小模型响应更快且部署成本低，但可能影响输出质量和能力。挑战是找到在延迟和基础设施成本可控的前提下，能满足具体任务需求的最小模型。

部署开源语言模型时，企业通常有两条路径：内部托管或使用托管平台。两者各有优势，取决于组织的技术能力和业务优先级。具备技术资源的公司可选择内部托管，全面控制模型各方面，包括微调。对 Alex 这样的公司而言，这是一条理想的长期路线，通过逐步用企业和领域专属数据定制模型，构建坚实壁垒。

自托管部署在基础设施和专业技术上要求较高。大多数开源模型有多种规模可选，如 Llama 3.2 提供1B、3B、11B、90B参数版本，模型越大，部署越复杂。特别是在需要与用户直接对话等场景，更可能倾向使用大模型以适应更多样的用户请求。

若缺乏资源或工程实力管理基础设施，可以考虑通过托管服务微调和部署开源模型。大规模云服务商如亚马逊 AWS 和谷歌云均有自己的训练与托管平台（Amazon SageMaker、Google Vertex AI），专业创业公司如 Lamini 提供开源 LLM 管理的专业服务。

工程角：模型托管的硬件需求

开源模型部署的硬件需求因模型大小和架构而异。以下是针对不同规模模型的大致配置建议：

较小模型（如 Mistral 7B，Llama 7B）：

• GPU：

  • 最低：1块 NVIDIA A100 40GB GPU
  • 推荐：1块 NVIDIA A100 80GB 或 H100 80GB GPU

• 内存：至少32GB

• 存储：NVMe SSD，用于加快模型加载速度

较大模型（如 Llama 65B）：

• GPU：

  • 最低：2块 NVIDIA A100 80GB GPU
  • 推荐：4块 NVIDIA A100 80GB 或 H100 80GB GPU

• 内存：至少256GB（详见 mng.bz/jZ5e）

• 存储：高速 NVMe SSD

节省资源的小贴士：

• 利用竞价实例（Spot Instances）处理非关键任务以降低成本。
• 采用量化技术（Quantization）优化模型，减少内存使用并提升性能。
• 探索专业云GPU供应商，如 RunPod 和 Paperspace，获取更具竞争力的价格。

5.3.3 推理语言模型

想象有人问你：“中国的首都是哪里？”你会立即从你的百科知识中查找答案并给出回应。接着对方又问：“67 × 81 等于多少？”这时你需要停下来，回忆长乘法的步骤，并应用这一多步骤过程来解决问题。

传统语言模型在回答百科类问题方面表现出色，但在多步骤推理和问题解决上能力较弱。随着AI代理的兴起（见第9章），对支持推理能力模型的需求不断增长，语言模型提供商也推出了推理模型，如 DeepSeek-R1（见图5.11）以及 OpenAI 的 o1 和 o3。这些模型在结构化、多步骤任务中尤为有用，例如财务建模、科学研究、高级编程，以及法律和商业智能中的结构化决策。此外，它们具备更强的泛化能力，能够比传统语言模型更有效地适应未见过的问题。

图5.11 DeepSeek 向用户展示其推理过程。

这些优势也伴随着权衡。由于推理模型需执行额外的计算步骤以更深入地分析问题，它们往往计算成本更高、推理速度更慢。目前，推理模型无法区分简单的百科查询和复杂问题，默认都会启动推理过程，因此像“什么是中国的首都？”这样简单的查询，处理时间可能与复杂的概念性问题相当。

就 Alex 而言，推理模型在内容生成上的附加价值有限，且不值得承担额外的推理成本和速度下降。但如果你的价值主张侧重于解决问题而非单纯内容生成，投资推理模型可能带来显著竞争优势。此类应用示例包括：

• 财务或科学分析——财务预测、物理模拟或工程计算
• 高级编码与调试——编写、优化和排查复杂算法
• 战略决策——商业智能、法律推理及长期规划

注释：想了解推理模型如何获得这些能力，请参阅博客《理解推理大型语言模型：构建与完善推理模型的方法与策略》[4]。

5.3.4 小型语言模型（SLMs）

小型语言模型，如 Phi-2 和 DistilBERT，是设计得更紧凑的模型，相较大型模型，它们运行更快、更高效，且资源消耗更少。主流大型语言模型拥有数十亿甚至数万亿参数，而小型模型的参数数量通常在百万到几亿之间。虽然小型模型缺乏大型模型的强大算力和深度，但仍能有效处理许多常见的预测或生成任务。它们小巧的规模往往配合更干净、受控的训练数据，在特定任务上输出更准确可靠。

对于希望降低基础设施成本同时发展战略性 AI 能力的企业，小型语言模型是有趣的替代方案。由于体积较小，它们可部署在相对低配的硬件上，更适合小型企业和精简基础设施。这使得 SLMs 非常适合不需要大型模型广泛知识或复杂创造力的应用场景。

例如，在 Alex 的创业项目中，虽然主要目标是生成丰富且高度定制的内容，他也希望提供分析用户竞争对手内容、发现重要趋势和话题的功能。此时，小型语言模型是绝佳选择。它们在处理大量、低复杂度任务时能提供所需的速度和响应能力，同时避免为每个用例运行大型模型带来的高昂成本。然而，在需要更深层次、复杂内容创作或丰富上下文理解的任务（如撰写行业报告或生成高度个性化品牌信息）中，SLMs 表现不足，难以产出细腻或上下文丰富的结果。

大多数小型语言模型作为开源项目发布，可像大型开源模型一样进行微调和内部部署或通过托管服务使用，但更小的体积使得它们更易于管理。

注释：想了解更多关于小型语言模型的信息，请参阅 IBM 文章《什么是小型语言模型？》（mng.bz/WwOW）。

5.3.5 多模态模型

多模态模型（MMMs），如 Gemini 和 GPT-4o，扩展了传统语言模型的能力，不仅能够处理和生成文本，还能处理其他模态的数据，包括图像、音频和视频。这些模型使企业能够构建与用户进行更丰富、更动态交互的应用。一些最著名的例子包括具备视觉能力的 OpenAI GPT-4、DeepMind 的 Gemini 以及支持图像处理的 Google Bard。

利用多模态模型，企业可以超越纯文本交互，结合视觉和语言信息，提供更加沉浸式的输出。以 Alex 为例，他的目标是生成针对特定公司的高质量、可验证内容，多模态模型在初期可能显得有些过于强大——毕竟大部分内容仍是文本。不过，随着业务发展，这些模型可能成为强有力的差异化工具。未来，用户可能会期待能够创建视觉内容或处理多媒体内容，作为其营销策略的一部分，多模态模型将支持这些功能升级。例如，Alex 的客户可以提供书面内容和产品图片，由多模态模型生成相应的描述、社交媒体帖子，甚至推荐图片编辑方案。

相比仅处理文本的模型，部署多模态模型需要显著更多的基础设施和计算资源。它们必须同时处理多种数据流，对内存、计算能力和存储提出更高要求。

至此，你已经对语言模型的基础知识有了较全面的了解：它们如何工作、多样化的应用以及市场上的各种选择。打好基础后，接下来就是深入探索如何在你的应用中实际使用语言模型。

5.4 语言模型生命周期管理

本节将探讨语言模型开发与部署的一般生命周期。如图5.12所示，该生命周期包括选择模型、根据具体需求定制模型，以及持续优化模型，直至达到验收标准。

需要注意的是，这些步骤的顺序并非固定，而是一个灵活的迭代过程，应与用户期望和应用风险相匹配。例如，低风险的消费者应用在初步定制后可能即具备上线条件，而面向医疗专业人士的应用可能需要多轮优化，才能达到所需性能。你应根据项目的具体需求和目标调整方法，确保模型既满足功能要求，也符合伦理标准。

5.4.1 模型选择

为应用选择合适的语言模型需要在多个权衡之间做出平衡，如质量、学习效率、治理要求和计算成本。由于影响因素众多，选择过程往往是反复迭代的。你会尝试不同模型，优化选择标准，调整优先级，以最大程度支持项目需求。为了让这一过程更易管理并更有把握，以下是实用指南，助你理顺模型选择：

• 首先识别“硬性”治理要求，这些要求可能从一开始就限制你的选择范围。例如，Alex 有些客户对隐私有严格政策，因而无法使用商业的 LLMaaS 服务。另一个例子是欧盟因《人工智能法案》（artificialintelligenceact.eu/；详见第11章）限制先进多模态模型的使用。

• 与工程团队紧密沟通，根据战略优先级和扩展计划，确定部署和定制的可行选项。同时，考虑团队技术水平和动力。如果团队工程师技能高，可能更愿意打造定制 AI 模型，而非依赖预构建的商业API，这也有助于构建竞争壁垒。因此，尽管 LLMaaS 是 Alex 初期首选，但很快他便得到一位工程同事支持，引入开源模型以改进应用。

• 明确你当前的AI旅程阶段：

  • 初期，使用 LLMaaS 进行试验有助于快速启动AI项目、测试可行性并推动产品市场匹配。
  • 一旦实现产品市场匹配，可考虑微调并自行托管模型，以获得更大控制权、针对应用进一步优化性能，强化竞争优势。

• 用标准化基准测试和定制评估策略评估首选模型（详见5.4.2节）。

• 基于用户调研，提出额外需求和期望，如延迟、治理、样本效率等，并据此评估模型选择。例如，Alex 的用户愿意为完整草稿等待更长时间，但对文本后续编辑的响应速度有较高期待。

• 在真实任务和数据集上测试候选模型，初步感知性能表现。

• 在此过程中，记住生成式AI创新和趋势变化迅速，当前领先的模型榜单可能在数月甚至数周内发生改变。使用语言模型时，要关注其生命周期和整体生态动态，寻找提升竞争力的机会。Anacode 的 AI Radar（anacode.de/ai-radar）提供动态趋势概览。与工程团队协商，制定处理模型变更的方案。虽然在代码库中将模型作为可替换参数实现技术上较简单，但定制、微调和评估的下游工作往往难以扩展。最后，随着AI能力的扩展和产品功能的增加，你可能会采用多模型架构，为不同任务使用多款语言模型。

5.4.2 语言模型评估

当 Alex 经过5.4.1节的流程，筛选出几款语言模型时，他想知道如何评估它们的质量，以及“质量”在这里具体指什么。作为博主，他可以先尝试“自用”（dogfooding）——用不同模型生成文章，培养对模型表现的直觉。这种眼球检测在初期有用，但存在主观偏见。Alex 需要更广泛且客观的评估，了解模型在不同行业和客户群体中的表现和扩展性。这将帮助他在开发的不同阶段：

• 选择最佳的预训练语言模型
• 制定模型发布前必须满足的验收标准和性能门槛
• 指导后续优化以提升模型表现

Alex 从查阅已有的公开基准测试开始，逐步将更多定制且结果导向的评估要素纳入策略。

评估公开基准

大多数预训练模型都会在公开论文、报告和模型卡中进行介绍和说明，供开发团队评估。这些文档通常使用通用基准进行测试，并将模型与其他同类模型比较。例如，图5.13展示了 Hugging Face 上 Llama 3.2 1B 模型页面提供的小型 Llama 3 变体的评估结果。

图5.13 使用公开基准对部分 Llama 3 变体的评估（来源：mng.bz/8XzD）

表5.2 解读了用于评估的基准测试。每个基准测试采用特定的评价指标，例如 SQuAD 使用精确匹配（EM），ARC 使用字符级准确率（acc_char）。图5.11中的结果以百分比形式呈现。

• MMLU
  大规模多任务语言理解基准，用于评估大型语言模型在多种任务上的表现。
• AGIEval
  人工通用智能评估基准，设计用来测试大型语言模型在人类通常感到困难的任务上的能力，常用于评估人类智能水平。
• ARC
  抽象与推理挑战基准，专门测试AI模型的推理能力，通过针对中学生的多项选择科学问题进行评估。
• SQuAD
  斯坦福问答数据集，是自然语言处理领域广泛使用的基准，用于评估模型理解文本并生成答案的能力。
• QuAC
  上下文问答数据集，用于评估模型处理对话式问答的能力。
• DROP
  文章离散推理数据集，用于测试模型在阅读理解任务中的离散推理能力。

在查看公开基准时，应识别与目标应用最接近的代理指标。例如，对于 Alex 的内容生成功能，应重点关注 MMLU 和 HELM（语言模型整体评估，crfm.stanford.edu/helm/）等通用基准，这些基准测试模型的整体语言性能和知识水平。由于他还需要高事实准确性，Alex也会查看问答类基准，如 ARC 和 SQuAD。若计划程序化使用 LLM 输出，则可关注专业基准，如 Berkeley 函数调用排行榜（BFCL，mng.bz/EwdR）和 Spider（yale-lily.github.io/spider）用于Text2SQL。

注释
想了解更多关于语言模型基准的内容，请阅读《什么是LLM基准？》（<www.ibm.com/think/topic…

设置自定义评估策略

标准化基准虽有帮助，但不能反映用户对应用的真实感受。自定义评估策略让你将模型与特定用户需求和期望对齐。Alex 在搭建评估框架时，首先考虑谁来执行评估——他自己、外部标注员，甚至是大型语言模型。不同选择在速度和可靠性上存在权衡，如图5.14所示。

起初，Alex 自己进行“目测”评估，但计划引入人工评审以减少个人偏见。人工评估对创造力、语气和连贯性等难以自动衡量的定性方面尤为重要。但人工评估成本高、速度慢且难以扩展。Alex 初期尝试众包，但发现质量不稳定。随后，他采用混合方案，将人工监督与语言模型驱动评估结合，兼顾自动化速度与对语调、风格及整体质量等关键领域的人为把控。使用先进的语言模型（如 GPT-4）可帮助 Alex 实现评估规模化，但他必须缓解模型潜在偏见，如位置偏见、自我偏好或冗长表达。人工复核环节有助于解决这些问题，确保评估质量并符合用户预期。

图5.14 在评估语言模型时，需要权衡速度与可靠性。

为了让评估更贴合他应用中的具体用户成果，Alex 设计了以下评估指标：

• 品牌契合度——衡量回复内容与客户声音及品牌价值的匹配程度。
• 可读性——评估内容的清晰度和易读性，使用可读性评分或评估者评分，确保内容易于理解。
• 准确性——验证事实正确性，尤其针对建议或解释，通常通过事实核查实现。
• 创造力——评价回复的新颖性，帮助模型生成新鲜且吸引人的回答，而非公式化答案。
• 上下文相关性——评分回复是否直接针对用户提问，确保回答准确且恰当。
• 客户特定指标——为独特需求创建定制指标，如行业专用语言或合规性。Alex 计划为高端客户添加此类指标。

部分指标如准确性和上下文相关性较为客观；而创造力和品牌契合度则较为主观，受个人喜好和感知影响较大。针对后者，广泛收集人类和语言模型的反馈尤为重要，以捕捉多样观点，确保符合细致的用户期望。

注释
想深入了解语言模型评估，请参阅《评估大型语言模型：全面综述》[5]。

5.4.3 根据需求定制语言模型

为了让应用真正发挥作用，Alex 需要将语言模型调整到与客户特定领域、品牌及内容生成独特需求相匹配。他采用了三种关键适配技术——提示工程（prompt engineering）、检索增强生成（RAG）和微调（见图5.15），逐步提升模型的相关性和有效性。

提示工程：打造有效指令

Alex 初次涉足语言模型，便从提示工程开始。通过设计巧妙的提示，他能够在无需复杂调整的情况下提升模型的回复质量。细致地编写指令，他能引导模型生成符合特定语调或风格的内容。例如，在为科技客户撰写营销博客时，简单调整提示——如指定“使用权威且专业的语气”或“用亲切、平易近人的声音写作”——就能显著提升输出质量。经过反复测试，Alex 学会了如何构建提示以获得稳定的效果。但他也意识到提示的局限性：虽然有帮助，单靠提示无法完全捕捉品牌独特声音，也无法彻底避免幻觉问题。

检索增强生成（RAG）：提升事实准确性

随后，Alex 探索了检索增强生成（RAG）来解决准确性问题。他需要应用输出事实准确的内容，特别是在生成具体行业洞察或产品描述时。通过集成 RAG，模型得以辅以动态且最新的知识库——无论是客户信息数据库、最新行业新闻还是详尽的产品规格。这样，模型生成内容时能调用实时信息，大大降低错误概率。Alex 还能根据客户特定需求定制回复，提升相关性和精确度，而无需对模型进行全面再训练。RAG 是实现准确性目标的有力工具，但仅靠此法，Alex 仍难以完全复制品牌的语调和深度。

微调：赋予模型独特声音

为了真正体现每位客户的个性化声音和风格，Alex 最终选择了微调。通过用客户专属的示例数据（如过去博客、社交媒体更新和品牌指南）训练模型，他打造出了体现每位客户独特声音的定制模型。例如，Alex 使用一组捕捉某客户幽默、无拘无束风格的历史内容数据微调模型。结果符合他的预期：回复更丰富、更细腻，生成后需要调整的内容大幅减少。

成功的模型定制是语言模型应用的成败关键。它不仅决定你是否能满足用户需求和期望，还能帮助构建坚实的竞争壁垒。在第6至8章，我们将深入 Alex 的开发历程，学习这三大定制技术的核心方法与细节。

5.4.4 生产环境中的反馈收集

对语言模型最准确、最真实的测试发生在其投入真实生产环境时。在这里，你可以直接观察和测量模型对现实输入和数据的响应情况，以及它满足用户期望的程度。因此，当 Alex 发布他的最小可行产品（MVP）时，他迅速收集了许多新的洞见，例如用户如何与模型互动，模型生成的内容是否提升了用户参与度、满意度和留存率。主要的注意事项是，你需要具备相当成熟的开发能力才能承受这种实时测试。如果过早进行，模型性能不稳定可能吓跑用户，无法满足他们的需求。

此阶段，收集明确的用户反馈极为宝贵。Alex 实施了一个简单的反馈机制——点赞/点踩小部件，用于收集内容质量的实时反馈。他还监控更复杂的指标，如用户满意度评分、与内容互动的时间和转化率，并将这些指标与模型输出关联起来，深入理解大型语言模型如何影响用户行为和业务成果。第10章你将学习更多关于收集AI性能用户体验反馈的工具。

5.4.5 持续优化语言模型配置

部署语言模型并非一次性任务。模型上线后，持续迭代和优化应成为常态。定期更新确保模型能适应不断变化的用户期望、新数据及AI技术进步，使其长期持续产出价值。

优化需持续投入，侧重于细致的错误分析和逐步改进。虽然这一过程需要坚持不懈，但收获颇丰。深入理解模型的优势与不足，有助于有针对性地提升性能，打造难以复制的竞争优势。优化的两个主要驱动力如下：

• 定制数据
  持续完善数据，确保其具代表性且及时更新——无论是通过少样本示例、RAG数据库还是微调——保持模型与发展趋势及用户行为同步。有效的数据管理实践（DataOps）是这一迭代过程的关键。你应特别关注模型过往的失败案例，向数据集中添加纠正示例，以支持用户对AI系统持续改进的期待。
• 高级定制技术
  利用先进方法如精细提示、改进的 RAG 搜索策略和参数高效微调，可显著提升模型性能和扩展性。虽然语言模型领域充斥着各种优化技术，但并非所有方法都适合你的应用。许多技术仅在特定小众场景带来轻微提升，有些则是旧技术的重新包装。理想情况下，工程团队应持续关注最新学术和技术动态，筛选真正能带来显著性能提升的“瑰宝”，保持竞争领先。

为简化优化流程，团队应自动化关键环节，如数据监控、错误跟踪、评估和模型更新——这就是所谓的 MLOps（或针对语言模型的 LLMOps）。目标是加快迭代周期，使新数据和洞察能迅速整合，提升用户满意度和参与度，并为下一轮迭代产生宝贵反馈。

总结

• 在将语言模型（LM）集成到应用之前，先熟悉其内部机制、可用选项和核心能力，以指导设计和部署决策。
• 根据质量、成本、治理和可扩展性等权衡因素选择模型，优先考虑符合项目目标的因素。
• 将语言模型生命周期视为灵活的迭代过程，调整开发流程以满足不断变化的用户期望和项目风险。
• 使用标准化基准（如 MMLU、SQuAD）评估模型性能，尤其是在早期阶段。
• 制定定制评估指标（如品牌契合度、可读性、准确性），确保模型满足特定用户需求。
• 利用提示工程进行即时调整，采用检索增强生成（RAG）提升准确性，通过微调实现个性化输出。
• 监控训练数据中的潜在偏见和不准确，建立机制在部署前识别并减轻有害输出。
• 在无需用户直接交互时，将语言模型应用于特定、明确的后端任务，提高可靠性和可控性。
• 实施反馈机制，如点赞/点踩评分和用户满意度指标，持续优化部署后的模型。
• 持续完善数据，添加纠正示例，使模型输出与发展趋势和用户期望保持一致；有效的数据管理（DataOps）至关重要。
• 工程师应定期跟踪最新学术和技术进展，识别可提升性能的技术。
• 通过结构化的 MLOps 流水线实现数据监控、错误跟踪和模型更新自动化，加快迭代周期，使模型更贴合用户需求。