前沿模型是推出AI产品的最快方式，但当使用量扩大后会发生什么？在我们的最新案例研究中，@Shopify 分享了他们如何使用 @PyTorch 和 @vllm_project 为其GraphQL智能体构建持续学习循环，将日常生产故障直接转化为模型权重改进。

阅读 Cody Mazza-Anthony 和 @Drewch 的完整解析，深入了解他们如何定义质量、校准评估器以及在GPU间分配训练：https://pytorch.org/blog/how-shopify-built-a-continual-learning-loop-with-pytorch-and-vllm/

此外，不要错过 @ShopifyEng 在 #PyTorchCon NA 上的主旨演讲，了解小型模型如何在精确定义的任务上以更低的成本、更低的延迟和更高的吞吐量超越前沿模型。

获取PyTorch北美会议门票（10月20-21日，加州圣何塞）：https://hubs.la/Q04v8Lq_0

Shopify如何使用PyTorch和vLLM构建持续学习循环 – PyTorch

来源：https://pytorch.org/blog/how-shopify-built-a-continual-learning-loop-with-pytorch-and-vllm/

特色项目

• PyTorch标志 (https://pytorch.org/projects/pytorch/)
• vLLM标志 (https://pytorch.org/projects/vllm/)

Shopify如何使用PyTorch和vLLM构建持续学习循环
摘要：本案例研究探讨Shopify如何每天将生产故障压缩为模型权重，通过构建基于PyTorch和vLLM的持续学习循环，超越前沿模型质量并将服务成本降低96%。

前沿模型通常是推出新AI产品的最快方式。小型团队可以快速向用户展示实用功能，并从实际使用中学习。但随着使用量增长，经济性发生变化：前沿模型可能过慢且成本过高，无法大规模处理每个请求。

前沿模型是通用的，未针对您的产品定制。更重要的是，它们不会自动从生产中学习。用户更正、被拒绝的输出或反复出现的故障不会让下一次响应变得更好。但每个故障都是关于您产品的宝贵知识，持续学习始于捕获这些知识并将其反馈到系统中。

此外，部署的前沿模型权重是冻结的。它没有机制来内化生产经验。相反，改进累积在周围的离散工件中：提示编辑、检索示例、路由规则和框架代码。生产知识在文字和代码中堆积，而模型权重保持不变。飞轮机制正是我们的解决方案：一个将生产经验压缩到模型权重连续空间的持续学习循环。PyTorch提供了使这些更新成为可能的训练基础。

Shopify的GraphQL智能体是该循环在生产中运行的最清晰示例。该飞轮机制提供了比前沿模型更高的质量，同时降低了延迟并削减了96%的成本。

飞轮优化流程

从定义质量开始；它成为奖励信号

定义质量是循环中最重要的步骤——也是团队最容易匆忙处理的环节。它始于对“良好”的具体描述，并成为驱动学习的奖励信号。如果评估标准或规格有误，下游所有环节都会优化错误的行为。

质量始于一个评估标准，该标准将您的产品需求转化为几个评分标准：完整性、执行、响应质量和安全性。每个标准都有具体的锚点来定义每个分数的含义。可以将其视为您产品团队对好坏的定义。这是所有下游工作的质量契约，也是标注员将对话转化为真实数据的依据。关键的是，该真实数据应包含随机抽样的流量，而不仅仅是精心挑选的示例。黄金测试集测试您已知要关注的案例；随机样本则揭示生产中好坏实际的表现。

一旦您对评估标准满意，请安排两名最佳标注员/产品专家盲目标注25个随机样本，并记录他们之间的标注员一致性。我们使用Cohen’s kappa (https://en.wikipedia.org/wiki/Cohen%27s_kappa) 来衡量超越偶然的一致性。如果该值非常低（约0.2），则评估标准存在歧义：需要再次会面并迭代。如果这个评估标准让每天处理该产品的多名产品专家都感到困惑，那么它也会让大语言模型（LLM）感到困惑。

这种一致性是评估器的上限：即使是专家标注员也无法100%达成一致，因为某些对话确实存在模糊性。目标不是创建一个“完美”的评估器，而是一个与人类判断匹配度与人类彼此匹配度相当的评估器。

当您收集标注时，请力求详细。单靠分数和一句话不足以让校准算法学习。您需要每个分数背后的原因，而这些推理才是金矿。

评估器

校准您的评估器

评估标准只是起点。它是评估器的第一个提示，但尚未从您的真实数据中学习任何东西。校准将采用该标准，并将其转化为一个可以在无限生产数据点上运行的评估器。

我们对此非常推崇DSPy，并使用基于反思的优化器（如GEPA和智能体上下文工程[1,2]）进行校准。GEPA通过反思自然语言故障痕迹来改进提示，并维护一个候选方案的帕累托前沿，而不是贪婪地选择单一最优方案。ACE通过微小增量编辑来策划一个结构化的操作手册。

评估器是您的离线指标，是您在发布前优化的目标。但它只是一个代理指标，因此您需要确认它反映了真实流量上的性能，并与您的在线指标一致。通过历史A/B测试进行回测：它能否重现已知在参与度、留存率或产品旨在推动的行为方面取得的胜利或失败？

然后进行针对性的降级测试，可以在离线进行，也可以在严格控制的流量切片上进行。刻意让一种行为变差，并确认相应的标准分数下降。例如，如果系统停止尝试实现用户目标，那么目标达成分数应该特定地下降。

保持每个评估器小而有针对性，而不是将产品的所有行为都塞进一个评估器中。专注的评估器使这些测试更易于解释，结果指标更易于信任。您可以随时添加更多。

使用自动研究改进前沿基线

现在我们有了一个可靠的评估器，可以用它来改进我们最初推出的基于前沿模型的产品，即为了快速向用户展示而构建的基线系统。在这个阶段，我们将在不修改权重的情况下，将该系统推向其极限。所有改进都体现在提示、工具定义和框架中。

但改进这个基线系统与构建评估器是不同的问题。它已经是一个生产应用程序，具有动态组装的提示、自定义控制循环和跨大型代码库的特定编排。没有任何单一提示决定其行为，因此提示调整只涉及系统的一小部分。优化目标是整个框架：其提示、工具定义和编排代码。

因此，我们将其视为一个自动研究 (https://shopify.engineering/autoresearch) 问题，遵循卡尔帕西最近项目 (https://github.com/karpathy/autoresearch) 的精神：一个智能体提议对提示、工具定义或框架进行更改；根据评估器进行评估；如果分数提高则保留更改；否则丢弃。

我们用一个可读的Markdown文件配置整个流程：从哪里获取数据、智能体可以编辑哪些目录、评估器作为指标、要使用的优化器，以及提议-评估-保留或丢弃循环。

program.md

从离散工件到连续参数更新

一旦框架改进趋于饱和，我们就开始在参数空间进行优化，通过挖掘匿名生产流量寻找困难负例：评估器正确评分较低且暴露模型最薄弱环节的对话。

在数百万多样化商家中，真实流量产生了源源不断的困难案例：部分上下文、模糊请求、特定业务流程、工具故障以及表达相同意图的多种方式。在传统工作流程中，每个故障都会变成缺陷报告或Slack讨论串。在飞轮机制中，这些故障自动进入一个自我修复管道，由一组前沿推理模型将其转化为训练信号，然后强化学习将其折叠回模型的权重中。

失败对话流
一组前沿推理模型对每个故障进行批判。仲裁者将这些批评合并为单个修复指令，该指令被注入到用户轮次之前，这种技术有时被称为“提示”。我们从该点重放对话，评估器再次评分。如果修复通过，重放轨迹就成为强化学习的轨迹，评估器的分数作为其奖励。如果仍然失败，我们将其标记为需要人工标注。这就是Toloka (https://toloka.ai/) 发挥作用的地方：其专家标注员更正我们的批评者无法修复的对话，并按照用于校准评估器的同一评估标准进行评分。

训练分两个阶段进行。首先，我们通过监督微调将修复后的轨迹蒸馏到一个较小的模型中。我们在完整的轨迹上进行训练——包括产生这些轨迹的推理过程，而不仅仅是最终答案（参见Toloka关于智能体工作流微调的文章 (https://toloka.ai/blog/fine-tuning-for-agentic-workflows-building-a-production-cv-parser-with-shopifys-tangle/)）。这种思维链蒸馏使较小的模型能够继承仅从答案中无法学习到的行为[3]。

其次，我们应用GRPO（广义强化策略优化），使用校准后的评估器作为奖励信号。对于每个提示，模型采样一组响应，评估器进行评分，GRPO强化表现最好的响应。监督微调教会模型模仿成功的轨迹；GRPO直接根据我们的质量定义进行优化。

自我修复管道每天运行，持续向训练语料库添加新轨迹。按照相同的节奏，我们在累积数据上运行全参数微调，然后重复GRPO。在新旧轨迹上进行训练限制了周期之间的漂移和灾难性遗忘[4]。随着飞轮转动，质量提升并最终超越基于前沿模型的基线。

我们使用PyTorch通过张量、上下文和数据并行性在GPU间分配训练，使全参数微调在实际规模下可行。

压缩提示以更快服务

更好的模型仍然需要运行，而智能体的系统提示冗长且静态。注意力机制随序列长度缩放，因此每个生成的令牌都需关注整个前缀。长提示是延迟和服务成本上的固定税负，每次请求都需支付。

要点压缩（Gist Compression）消除了大部分这种税负。我们以两种方式运行相同的模型：一个带有完整系统提示的教师模型，和一个用学习到的简短要点令牌序列代替的学生模型。我们构建了一个自定义的PyTorch训练器，通过匹配教师的输出分布来学习要点令牌嵌入，同时保持模型权重冻结。结果是少量令牌，能够以原始长度的一小部分再现提示的行为，且评估器上无测量到的质量损失[5,6]。

system prompt

飞轮在行动：GraphQL智能体

商家助手对话
观察整个循环运作最清晰的地方是我们的GraphQL智能体，它在生产环境中每分钟处理多达2,000个请求。它通过编写并执行对Shopify Admin GraphQL API的查询来回答商家关于其商店的问题：商家可能询问哪些产品库存即将不足，智能体则推导出正确的查询，针对商店运行查询，并将结果转化为自然语言答案。

GraphQL蒸馏
以下是其工作原理：

它使模型更好。自我修复管道将低分的生产对话转化为成功的轨迹，为模型提供源源不断的来自真实商家需求的经验教训。结合SFT（监督微调）和RL（强化学习），使专用模型能够超越前沿模型的性能。

它使模型服务成本大大降低。我们通过vLLM（基于PyTorch构建的推理引擎）提供模型服务。vLLM通过连续批处理保持高吞吐量，并且非常适合我们工具调用密集型的工作负载。在前沿模型上处理这些流量，根据平均令牌成本估算，每年可能花费约2700万美元。微调模型的成本可能只是其中的一小部分，接近100万美元：服务成本降低了96%。这就是在Shopify规模下运行一个功能令人痛苦与我们可以放心为每个商家启用之间的区别。

它使模型更快，并且在负载下差距增大。要点压缩将智能体冗长、静态的系统提示从大约6,000个令牌压缩到约1,500个学习到的要点令牌。在每分钟350个请求的负载测试中，首个令牌生成时间（TTFT）降低了约19%，端到端延迟降低了约38%。

它释放了硬件。相同的压缩提高了吞吐量：在相同GPU上，每秒请求数提高约16%，每秒输出令牌数提高约12%，这意味着处理相同流量所需的GPU数量减少了约14%。

超越框架：不断复合的持续学习

前沿模型帮助您启动，最初的改进存在于其周围的离散工件中：提示、上下文、工具定义和控制流。这些更改增强了框架，但模型本身保持不变。

持续学习更进一步，将这些经验教训转化为模型连续参数空间的更新。每个周期从一个能力更强的模型开始，而不仅仅是一个更复杂的框架。这就是为什么一个更小的模型可以在您的任务上比前沿基线更快、更便宜、更好的原因。持久优势在于这个不断将生产经验转化为更好权重的循环。

参考文献

1. Agrawal 等. GEPA: 反思式提示进化能超越强化学习. arXiv:2507.19457
2. Zhang 等. 智能体上下文工程: 为自我改进的语言模型演化上下文. arXiv:2510.04618
3. Hsieh 等. 逐步蒸馏！用更少训练数据和更小模型超越大型语言模型. arXiv:2305.02301
4. Shuttleworth 等. LoRA vs 全量微调：一种等价性的错觉. arXiv:2410.21228
5. Wingate 等. 用于语言模型可控性和毒性降低的提示压缩与对比条件. arXiv:2210.03162
6. Mu 等. 学习用要点令牌压缩提示. arXiv:2304.08467

最初发布于**Shopify工程博客 (https://shopify.engineering/)。此版本已为PyTorch社区进行了改编。