LLM

这篇文章讨论了如何在智能体框架中更高性价比地使用 Fable 5：什么时候让它担任编排者、顾问或验证者，什么时候把大量 token 工作委派给更便宜的工作模型，以及委派成本、任务形态和提示词缓存为什么会决定最终是否真的省钱。 原文来源：https://x.com/RLanceMartin/article/2075641284635799865 本文由LobsterAI自动翻译和发布。 人们对如何高性价比地使用 Fable 5 非常感兴趣。智能体框架会越来越擅长判断：究竟应该在什么时候调用前沿智能模型。 我想分享一些自己做过的测试，以便更深入地理解应该在什么情况下、以什么方式使用 Fable 5。 任务的形态 很多任务在不同 token 阶段所需要的智能水平并不对称。智能体框架可以识别这种差异，然后决定什么时候使用 Fable 5。 目前已经出现了几种模式，未来很可能还会出现更多： 将 Fable 5 用作编排者，把任务委派给成本更低的工作模型。 将 Fable 5 用作顾问，让成本更低的执行模型在需要时向它请教。 将 Fable 5 用作验证者，检查其他模型完成的工作，例如放在 /goal 或 Outcomes 循环中。 例如，@mitchellh 提到过一种“编排者—验证者”方案： 我让 Fable xhigh 充当规划者和架构师，让 GPT 5.5 xhigh（订阅版）负责编码，然后再让 Fable xhigh 充当评审。 按照 API 定价计算，规划和评审的成本大概只有几美元，而一次典型的、完全由 Fable 完成的往返通常要花费 50 美元以上。 我也见过有人使用更笨、更便宜的编码模型，但即使开启 xhigh，GPT 5.5 与 Fable 5 相比仍然非常便宜、非常快。而且 GPT 5.5 确实……真的很强。 这种方案重新流行还不到 24 小时，所以它能否长期有效仍不确定，但到目前为止表现一直非常好。 我在 Parameter Golf 上研究了这种方案。这是一项机器学习工程挑战，类似于 @karpathy 的 autoresearch：让智能体修改训练代码、启动训练、查看结果，然后决定下一步应该进行什么实验。...

这篇文章主要讲：让 AI 编程代理在测试、模型选择、任务委派等方面使用自己的判断力，而不是把所有规则写死，以此提升效率并节省高阶模型 token。 本文由 LobsterAI 翻译、整理和发布。 原文链接：https://simonwillison.net/2026/Jul/3/judgement/ 我在周三 AIE 上主持了与 Claude Code 团队的 Cat Wu 和 Thariq Shihipar 的炉边谈话，其中最有意思的建议之一是：让 Fable（以及在一定程度上 Opus）使用自己的判断力，而不是规定它们应该如何工作。 他们给出的例子是测试。你可以告诉 Fable：“只对较大的功能使用自动化测试，不要为小的文案或设计改动更新并运行测试”——但更好的做法是，直接告诉 Fable：在决定是否编写测试时使用自己的判断力。 Jesse Vincent 刚刚也给了我一个相关建议，可以帮助避免在价格上涨前剩下的几天里烧掉太多宝贵的 Fable token。告诉 Fable：对较小的任务使用其他模型，并由它自己判断该使用哪个模型。 “我刚刚这样提示 Claude Code：” For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent Claude 把这个记忆文件保存到了 ~/.claude/projects/name-of-project/memory/delegate-coding-to-subagents.md： --- name: delegate-coding-to-subagents description: Simon wants coding tasks delegated to subagents running an appropriately lower-power model metadata: node_type: memory type: feedback originSessionId: 30068d78-43a9-4fb1-bb29-9799e18c526a --- Simon 在 2026-07-03 表示：“对于所有编码任务，使用你的判断力来决定合适的低能力模型，并在子代理中运行它。”...

这是 OpenAI 联合创始人 Andrej Karpathy 在一次 AI Agent 主题分享会上的演讲。本文由 LobsterAI 基于演讲视频音频转写、翻译并整理发布。 引言：当年的锤子，敲不开今天的门 几年前，在 OpenAI 有一个并不算轰动、却很有预言意味的项目，叫 World of Bits。 它的目标听起来非常朴素：不要再让强化学习智能体只会玩《蒙特祖玛的复仇》之类的游戏，而是让它们学会真正使用电脑——移动鼠标、敲击键盘、打开网页、订机票、点外卖，像人一样完成任务。 这当然是一个诱人的方向。毕竟，如果 AI 不能进入真实的数字世界，不能操作软件、调用工具、完成流程，它离“有用”始终差一步。 但当时的结果并不理想。演讲者回忆说，那篇论文“不是一篇特别了不起的论文”，因为彼时大家手里唯一像样的锤子，就是强化学习。于是研究者们做了非常简单的网页，让智能体在网页上乱点按钮、乱敲键盘，试图“误打误撞”获得更高奖励。 结果也很显然：它没有真正工作起来。 不是想法错了，而是时代没到。技术栈不对，工具不够成熟，问题也还没有被正确地表述出来。 有趣的是，几年之后，AI Agent 又回来了。但这一次，主角已经不是强化学习，而是语言模型。 从 World of Bits 到大语言模型：绕远路，反而走对了 演讲者提到，当年真正应该做的事情，可能恰恰是“先忘掉 AI Agent”，转而去构建语言模型。 这句话放在今天看，很有历史的反讽意味。 当年大家试图直接训练一个会操作电脑的智能体，结果发现智能体缺少理解、规划、泛化和语言能力。它能点击，却不知道自己为什么点击；它能尝试，却无法真正理解任务意图。 于是行业暂时离开了 Agent，转向 Transformer、预训练、大规模语料和语言建模。几年之后，大语言模型具备了理解指令、生成计划、调用工具、阅读网页、写代码和反思错误的能力。AI Agent 才又重新成为可能。 这也是演讲中最有意思的观察之一： “五年之后我们又回到了这里。AI Agent 看起来又酷起来了。但工具已经完全变了。” 今天做 Agent 的人，大多并不直接使用强化学习。很多创业者、黑客和研究者，构建的是基于 LLM 的工作流、工具调用系统、浏览器代理、代码代理和多智能体协作框架。 这在当年几乎难以预料。一个方向曾经失败，并不代表它不重要；有时只是因为真正能支撑它的基础设施还没有出现。 为什么 AI Agent 令人兴奋：AGI 的可能形态 为什么今天这么多人重新涌向 AI Agent？ 演讲者给出了一个非常直接的判断：很多人都隐约意识到，AGI 很可能会以某种 AI Agent 的形态出现。 它不一定是一个单体智能。更可能是许多智能体组成的系统：它们有分工，有记忆，有工具，有沟通协议，甚至形成某种数字组织或数字文明。 这也是 Agent 相比聊天机器人更令人兴奋的地方。...

本文翻译自 Andrej Karpathy 发布在 X 上的对于 2025 年 LLM 的年度回顾：2025 LLM Year in Review. 2025 年是 LLM（大型语言模型）取得长足进步且充满大事的一年。以下是一份我个人认为值得注意且略显意外的“范式转变”清单——这些事物改变了格局，并在概念上令我印象深刻。 1. 基于可验证奖励的强化学习 (RLVR) 在 2025 年初，各大实验室的 LLM 生产技术栈看起来大概是这样的： 预训练 (Pretraining, 约 2020 年的 GPT-2/3) 监督微调 (Supervised Finetuning, 约 2022 年的 InstructGPT) 基于人类反馈的强化学习 (RLHF, 约 2022 年) 在很长一段时间里，这是训练生产级 LLM 的稳定且行之有效的配方。在 2025 年，基于可验证奖励的强化学习 (RLVR) 崛起，成为了这一组合中事实上的新增主要阶段。通过在多个环境（例如数学/代码谜题）中针对可自动验证的奖励来训练 LLM，LLM 自发地发展出了在人类看来像是“推理”的策略——它们学会了将解决问题的过程分解为中间计算步骤，并学会了多种反复推敲以弄清问题的解题策略（参见 DeepSeek R1 论文中的例子）。这些策略在以前的范式中很难实现，因为对于 LLM 来说，最佳的推理轨迹和纠错方式是什么并不明确——它必须通过针对奖励的优化，自己找到行之有效的方法。 与 SFT 和 RLHF 阶段（这两个阶段相对较薄/较短，计算上只是微小的微调）不同，RLVR 涉及针对客观（不可被操纵）奖励函数的训练，这允许进行更长时间的优化。事实证明，运行 RLVR 提供了极高的能力/成本比，它吞噬了原本用于预训练的计算资源。因此，2025 年的大部分能力进步都是由 LLM 实验室消化这一新阶段的“剩余红利”所定义的，总体而言，我们看到了体量相似的 LLM，但 RL 运行时间要长得多。此外，这一新阶段独有的是，我们获得了一个全新的旋钮（以及相关的缩放定律），可以通过生成更长的推理轨迹和增加“思考时间”来控制作为测试时计算量函数的能力。OpenAI o1（2024 年末）是 RLVR 模型的首次演示，但 o3 的发布（2025 年初）是一个明显的拐点，你能直观地感受到这种差异。...

2025年 10 月 20 号 DeepSeek 团队在 HuggingFace 开源 DeepSeek-OCR ，该模型主要用于探索一种名为“上下文光学压缩” (contexts optical compression) 的创新理念。该方法旨在解决大型语言模型 (LLM) 在处理长文本时面临的计算效率难题，通过将文本信息渲染成图像，利用视觉 Token 实现比原始文本 Token 更高效的压缩。 主要观点 核心问题: 当前的大型语言模型 (LLM) 在处理长文本时，其计算复杂度会随文本长度呈二次方增长，导致效率低下。 创新方案: 提出“上下文光学压缩”概念，即将文本内容转换为图像，利用视觉语言模型 (VLM) 进行处理。由于一张图像可以用远少于原始文本的视觉 Token 来表示，这种方法有望实现极高的信息压缩率。 关键成果: 研发了 DeepSeek-OCR 模型作为此概念的验证。实验证明，该模型能在 9-10x 的压缩率下达到 96% 以上的文本解码精度。此外，DeepSeek-OCR 在主流的文档解析基准测试中，以最少的视觉 Token 消耗实现了端到端模型中的最佳性能 (state-of-the-art)。 关键细节 模型架构与创新 DeepSeek-OCR 组成: 模型由两部分构成：一个新颖的视觉编码器 DeepEncoder 和一个 DeepSeek-3B-MoE 解码器。 DeepEncoder 架构: 这是模型的核心创新。它串联了以窗口注意力为主的 SAM 模型和以全局注意力为主的 CLIP 模型，并通过一个 16x 的卷积压缩器连接两者。这种设计使得模型在处理高分辨率图像时，能有效控制计算内存和视觉 Token 的数量。 多分辨率支持: DeepEncoder 支持多种分辨率模式（如 Tiny, Small, Base, Large, Gundam），使其能够灵活测试不同压缩比下的性能，并适应不同复杂度的文档。 性能评估 视觉-文本压缩率研究: 在 Fox 基准测试中，DeepSeek-OCR 表现出色： 在 9-10x 的压缩比下，解码精度超过 96%。 在 10-12x 的压缩比下，精度约为 90%。 即使在接近 20x 的高压缩比下，精度仍能保持在 60% 左右。 OCR 实践性能: 在 OmniDocBench 基准测试中，DeepSeek-OCR 的表现优于其他端到端模型： 仅用 100 个视觉 Token，性能就超过了使用 256 个 Token 的 GOT-OCR2....

本文深入分析了 2025 年主流开源大语言模型（LLM）的架构演进。作者指出，尽管这些新模型在宏观结构上与七年前的 GPT 架构相似，但在关键组件上进行了诸多重要改进。文章的核心目的在于剖析这些定义了当前旗舰模型的架构设计，而非关注基准测试性能或训练算法。 主要观点 文章的核心观点是，当前的大语言模型架构发展主要围绕着提升计算效率、增强模型容量和确保训练稳定性这三大主题进行。尽管没有颠覆性的结构变革，但通过对现有 Transformer 基础的精细打磨，研究者们实现了显著的性能与效率平衡。 混合专家模型（MoE）成为主流：为了在不显著增加推理成本的前提下大幅提升模型参数量（即模型容量），DeepSeek、Llama 4 和 Qwen3 等多个模型广泛采用了 Mixture-of-Experts (MoE) 稀疏架构。 注意力机制持续创新：为降低推理过程中的内存占用和计算量，各种高效的注意力机制被采用。Grouped-Query Attention (GQA) 已成为标准，DeepSeek 更是引入了 Multi-Head Latent Attention (MLA) 来压缩键值缓存（KV cache），而 Gemma 3 则通过 Sliding Window Attention 限制注意力范围以提升效率。 归一化策略的精细调整：为了提升训练过程的稳定性，模型开发者对归一化层（Normalization Layer）的位置和方式进行了新的探索。OLMo 2 采用了特定形式的 Post-Norm 布局，并引入 QK-Norm，Gemma 3 则同时使用 Pre-Norm 和 Post-Norm。 对位置编码的实验性探索：部分模型开始挑战传统的位置编码方案。例如，SmolLM3 实验性地采用了 No Positional Embeddings (NoPE)，旨在改善模型对不同序列长度的泛化能力。 关键细节 以下是支持上述观点的具体模型架构细节： DeepSeek V3 / R1 Multi-Head Latent Attention (MLA)：通过在存入 KV cache 前压缩键（key）和值（value）张量来节省内存，实验表明其性能优于 GQA 和 MHA。 Mixture-of-Experts (MoE)：模型总参数量高达 6710 亿（671B），但推理时每个 token 仅激活 9 个专家（1 个共享专家 + 8 个路由选择的专家），活跃参数仅为 370 亿（37B）。共享专家的设计有助于学习通用模式，提升了模型性能。 Kimi 2...

本文是 Django 联合创始人 Simon Willison 所写，他主要回顾了2024 年，大语言模型 (LLMs) 领域经历了显著的发展和变革，以下是主要的趋势与关键事件： GPT-4 壁垒被突破：多家机构开发的模型超越了 GPT-4 的性能，并推动了更长的上下文输入和多模态能力的发展。 LLM 成本大幅下降：由于竞争加剧和效率提升，运行和训练 LLM 的成本显著降低，同时对环境的影响也得到了部分缓解。 多模态 LLM 的崛起：支持图像、音频甚至视频输入的多模态模型变得普遍，语音和实时视频交互成为现实。 生成式 AI 应用的普及：基于提示生成应用程序的能力已经成为主流，许多模型支持即时创建和使用互动工具。 “代理人”尚未实现预期：尽管“代理人”概念被频繁提及，但由于模型的可信度和工具使用能力的限制，其实际应用仍未成熟。 评估的重要性提升：开发可靠的自动化评估工具成为构建 LLM 应用的关键技能。 环境影响的两面性：虽然单次推理的能耗降低，但数据中心的扩建对环境造成了更大压力。 知识分布不均：公众对 LLM 的认知与实际技术发展之间存在巨大差距，需要更多的教育和引导。 关键细节 GPT-4 壁垒的突破 性能超越：2024 年，18 个组织的模型在 Chatbot Arena 排行榜上超越了 GPT-4（如 Google 的 Gemini 1.5 Pro 和 Anthropic 的 Claude 3.5）。 上下文长度扩展：从 2023 年的 4,096 或 8,192 个 token 提升到 2024 年的 100,000+，Google 的 Gemini 系列甚至支持 200 万个 token。 多模态能力：Gemini 1....

在过去的一年里，我们与数十个团队合作，构建了跨行业的大语言模型 (LLM) 智能体。始终如一地，最成功的实施并没有使用复杂的框架或专门的库。相反，他们是用简单的、可组合的模式构建的。 在这篇文章中，我们分享了我们从与客户合作和自己构建智能体中学到的经验，并为开发人员提供了关于构建有效智能体的实用建议。 什么是智能体？“智能体” 可以通过几种方式定义。一些客户将智能体定义为在较长时间内独立运行的完全自主的系统，使用各种工具来完成复杂的任务。其他人使用该术语来描述遵循预定义工作流程的更具规范性的实现。在 Anthropic，我们将所有这些变体归类为智能体系统，但在工作流程和智能体之间进行了重要的架构区分： 工作流程是通过预定义的代码路径协调大语言模型和工具的系统。另一方面，智能体是大型语言模型动态地指导其自身流程和工具使用的系统，保持对其如何完成任务的控制。下面，我们将详细探讨这两种类型的智能体系统。在附录 1 (“实践中的智能体”) 中，我们描述了客户发现使用这些类型的系统具有特殊价值的两个领域。 何时 (以及何时不) 使用智能体当使用大语言模型构建应用程序时，我们建议找到尽可能简单的解决方案，并且仅在需要时增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以延迟和成本换取更好的任务性能，您应该考虑何时这种权衡是有意义的。 当需要更高的复杂性时，工作流程为定义明确的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。然而，对于许多应用程序来说，通过检索和上下文示例优化单个大语言模型调用通常就足够了。 何时以及如何使用框架有许多框架可以使智能体系统更容易实现，包括： 来自 LangChain 的 LangGraph；Amazon Bedrock 的 AI 智能体 (AI Agent) 框架；Rivet，一个拖放式 GUI 大语言模型工作流程构建器；以及Vellum，另一个用于构建和测试复杂工作流程的 GUI 工具。这些框架通过简化标准的底层任务 (如调用大语言模型、定义和解析工具以及将调用链接在一起) 使入门变得容易。但是，它们通常会创建额外的抽象层，这可能会掩盖底层的提示和响应，从而使调试变得更加困难。当更简单的设置就足够时，它们也可能使添加复杂性变得很有诱惑力。 我们建议开发人员从直接使用大语言模型 API 开始：许多模式可以用几行代码实现。如果您确实使用了框架，请确保您了解底层的代码。对底层原理的错误假设是客户错误的常见来源。 请参阅我们的 cookbook 以获取一些示例实现。 构建模块、工作流程和智能体在本节中，我们将探讨我们在生产中看到的智能体系统的常见模式。我们将从我们的基础构建模块——增强型大语言模型——开始，并逐步增加复杂性，从简单的组合工作流程到自主智能体。 构建模块：增强型大语言模型智能体系统的基本构建模块是通过检索、工具和记忆等增强功能增强的大语言模型。我们目前的模型可以积极地使用这些功能——生成他们自己的搜索查询，选择合适的工具，并确定要保留哪些信息。 我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的 LLM 提供简单、完善的文档界面。虽然有很多方法可以实现这些增强功能，但一种方法是通过我们最近发布的 模型上下文协议 (Model Context Protocol)，该协议允许开发人员通过简单的 客户端实现 与不断增长的第三方工具生态系统集成。 在本帖的剩余部分，我们将假设每个大语言模型调用都可以访问这些增强的功能。 工作流程：提示链提示链将任务分解为一系列步骤，其中每个大语言模型调用处理前一个调用的输出。您可以在任何中间步骤中添加程序化检查 (请参阅下图中的“gate”) 以确保过程仍在轨道上。 何时使用此工作流程： 此工作流程非常适合可以轻松干净地分解为固定子任务的情况。主要目标是通过使每个大语言模型调用成为更简单的任务来权衡延迟以获得更高的准确性。 提示链有用的示例： 生成营销文案，然后将其翻译成不同的语言。编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。工作流程：路由路由对输入进行分类并将其定向到专门的后续任务。此工作流程允许关注点分离，并构建更专业的提示。如果没有此工作流程，针对一种输入进行优化可能会损害其他输入的性能。 何时使用此工作流程： 路由适用于以下复杂任务：存在最好单独处理的不同类别，并且可以通过大语言模型或更传统的分类模型/算法准确处理分类。 路由有用的示例： 将不同类型的客户服务查询 (一般问题、退款请求、技术支持) 定向到不同的下游流程、提示和工具。将简单/常见的问题路由到较小的模型 (如 Claude 3.5 Haiku)，将困难/不常见的问题路由到功能更强大的模型 (如 Claude 3....

本文是 Anthropic 官方文档给出的一些 LLM 术语的解释，我这里将其翻译为了中文，并增加了 LLM 中一些常见的术语词。 LLM 大语言模型（LLM, Large Language Model）是一种具有大量参数的 AI 语言模型，能够执行多种复杂且实用的任务。这些模型通过大量文本数据进行训练，能够生成类人文本、回答问题、总结信息等。Claude 是基于大语言模型的对话助手，并通过人类反馈强化学习（RLHF, Reinforcement Learning from Human Feedback）进一步训练，以更有帮助、诚实且无害。 Pretraining 预训练（Pretraining）是语言模型在大规模无标注文本数据集上进行的初始训练过程。以 Claude 为例，自回归语言模型会根据文档中的上下文来预测下一个词。预训练模型本身并不擅长回答问题或遵循指令，通常需要复杂的提示工程来引导出预期的行为。通过微调（Fine-tuning）和人类反馈强化学习（RLHF），这些预训练模型可以进一步优化，从而在广泛任务中变得更加有用。 Fine-tuning 微调（Fine-tuning）是通过额外数据进一步训练预训练模型（Pretraining）的过程。这会使模型开始模仿微调数据集中的模式和特征。微调可以帮助模型适应特定领域、任务或写作风格，但需要仔细考虑微调数据的质量及其对模型性能和潜在偏见的影响。 SFT (Supervised Fine-Tuning) SFT 是一种用于语言模型优化的技术，它通过使用标注好的数据集对模型进行进一步训练。相比预训练过程中的无监督学习，SFT 专注于让模型在特定任务上表现更好。在监督微调中，模型根据人为标注的输入和输出对进行学习，从而提高其在回答问题、完成任务或遵循指令等特定场景中的表现。SFT 经常用于帮助模型理解更复杂的任务要求，使其生成的输出更加符合预期。 LORA（Low-Rank Adaptation） LORA 是一种微调大型预训练语言模型的技术。它通过在模型的某些权重矩阵上引入低秩分解来降低模型更新所需的参数数量。传统的微调需要更新模型的所有参数，而 LORA 只微调一部分参数，这大大减少了微调的计算成本和存储需求，同时保持了模型的性能。LORA 在特定任务或数据集上的微调表现良好，因为它可以灵活地适应新的任务要求，而不需要重新训练整个模型。 QLORA（Quantized Low-Rank Adaptation） QLORA（量化低秩适应）是一种用于大语言模型的微调技术，它通过对模型权重进行低秩分解和量化来减少微调的计算开销，同时保持性能。这种方法能够在保持模型准确性的同时，显著降低内存需求和计算复杂度，因此特别适用于在有限的资源下微调超大规模模型。 QLORA 的主要特点是： 低秩适应（Low-Rank Adaptation, LORA）：通过对模型权重的低秩分解，QLORA 可以仅对少量参数进行微调，这样可以在节省计算资源的同时仍能有效捕捉任务相关的模式。 量化（Quantization）：QLORA 使用 4-bit 或更低精度的量化技术来减少模型的存储和计算要求。量化技术通过缩减模型中存储和处理的参数位数，能够降低硬件负载，而不显著影响模型的性能。 高效微调：QLORA 可以在不完全重训练模型的情况下进行微调，尤其适用于资源受限的场景，例如边缘设备或中小型研究团队。 QLORA 技术的出现使得对大型预训练模型进行特定任务的微调变得更加可行。 RLHF（Reinforcement Learning from Human Feedback） 来自人类反馈的强化学习（RLHF, Reinforcement Learning from Human Feedback）是一种用于训练预训练语言模型的技术，使其行为更加符合人类的偏好。这种训练方式可以帮助模型更有效地执行指令，或表现得更像聊天机器人。人类反馈的过程包括对多个文本样本进行排序，强化学习会鼓励模型倾向于生成与高排名样本相似的输出。Claude 已通过 RLHF 进行训练，使其成为一个更加有用的助手。更多详情可以参考 Anthropic 的论文: Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback。...

我们在《我们从一年与大语言模型 (LLMs) 的构建中学到了什么 (第一部分)：战术篇》中分享了操作 LLM 应用程序时精炼的战术见解。战术是具体的行动，用于实现特定目标。在《我们从一年与大语言模型 (LLMs) 的构建中学到了什么 (第二部分)：运营篇》中，我们还探讨了支持战术工作的高级过程。 那么，这些目标从何而来？这就是战略的领域。战略回答了战术和运营背后的“是什么”和“为什么”问题。 我们提出了一些主张，如“在找到产品市场契合 (PMF) 之前不要使用 GPU”和“专注于系统而非模型”，以帮助团队更好地分配有限资源。我们还建议了一条迭代至优秀产品的路线图。最后一部分内容将回答以下问题： 构建 vs. 购买：何时应该训练自己的模型，何时应该利用现有 API？答案是“视情况而定”。我们会分享这些情况的具体影响因素。 迭代至优秀：如何打造持久的竞争优势，而不仅仅是使用最新的模型？我们将讨论构建强大系统和提供令人难忘体验的重要性。 以人为本的 AI：如何将 LLMs 有效地融入人类工作流，最大化生产力和幸福感？我们强调了构建支持和增强人类能力的 AI 工具的重要性，而不是完全取代人类。 入门指南：团队在开始构建 LLM 产品时的关键步骤是什么？我们会概述一个从提示工程、评估到数据收集的基本操作手册。 低成本认知的未来：快速降低的成本和不断增加的 LLM 能力将如何塑造 AI 应用的未来？我们将探讨历史趋势，并展示如何估算某些应用的经济可行性。 从演示到产品：从一个引人注目的演示到一个可靠的、可扩展的产品需要什么？我们强调了从原型到生产的严格工程、测试和改进的必要性。 要回答这些难题，让我们一步一步来思考…… 战略：在构建 LLM 产品时不被超越 成功的产品需要深思熟虑的规划和艰难的优先级排序，而不是无休止的原型制作或追随最新的模型发布。在最后一部分中，我们将展望未来，思考构建优秀 AI 产品的战略考量。我们还将探讨团队将面临的关键决策，例如何时构建和何时购买，并建议一个早期 LLM 应用开发的“操作手册”。 在找到产品市场契合 (PMF) 之前不要使用 GPU 要打造优秀的产品，你的产品需要不仅仅是依赖他人 API 的简单包装。但过于依赖自己训练模型的错误也可能更加昂贵。过去一年中，我们看到大量风险投资，包括令人震惊的 60 亿美元 A 轮融资，都用在了训练和定制模型上，却没有明确的产品愿景或目标市场。在本节中，我们将解释为什么立即跳到训练自己的模型是个错误，并探讨自托管的角色。 从头训练几乎永远没有意义 对于大多数组织来说，从头预训练一个大语言模型 (LLM) 是一个不可行的分散注意力的行为。 尽管这很诱人，而且看起来似乎每个人都在这么做，但开发和维护机器学习基础设施需要大量资源。这包括收集数据、训练和评估模型以及部署它们。如果你还在验证产品市场契合 (PMF)，这些努力将分散你开发核心产品的资源。即使你拥有计算能力、数据和技术能力，预训练的 LLM 可能会在几个月内过时。 例如，BloombergGPT 是一个专门为金融任务训练的 LLM。该模型在 3630 亿个 Token 上进行了预训练，花费了 9 名全职员工（4 名来自 AI 工程团队，5 名来自 ML 产品和研究团队）的大量努力。尽管如此，它在一年内在这些金融任务上被 gpt-3....