TinyFish 用 Databricks 训练并部署 Web 模型

跳转到主要内容

• TinyFish 使用 Databricks AI Runtime 在托管 GPU 基础设施上训练和微调其 Web 原生模型，并使用 MLflow 进行评估，使用 Databricks Model Serving 进行生产推理。
• 将这些工作流整合在一起，为 TinyFish 提供了一条从生产代理行为到后训练、评估和部署的连续路径。
• 在 TinyFish 的内部 go/no-go 基准测试中，其 Web 原生模型在 2,178 个 Web 代理任务中实现了 77.6% 的任务成功率，衡量的是完整代理是否成功完成了所请求的工作。

TinyFish 为需要代理在实时 Web 上工作的企业构建基础设施。其 Search、Fetch、Browser 和 Agent API 支持大规模、经过身份验证的 Web 工作流，在这些工作流中，代理可能需要浏览动态网站、检索信息、与应用程序交互，并跨多个步骤执行任务。

TinyFish 正在为这些代理任务开发自己的专用 Web 原生模型。随着公司扩展其模型工作，团队还必须构建围绕它的基础设施：用于后训练的 GPU 计算、能够衡量完整代理行为的评估、生产服务，以及理解系统运行状况所需的数据。

TinyFish 没有在多个独立系统中管理这些部分，而是开始在 Databricks 上构建其模型开发生命周期。AI Runtime提供用于训练和微调的托管 GPU 基础设施，MLflow 支持评估，Databricks Model Serving 提供生产服务层。

对我们来说，训练模型只是问题的一部分。我们需要知道某个变更是否真的让代理更擅长完成真实任务，然后能够迅速将这一改进投入生产。借助 AI Runtime，我们可以在 GPU 上训练，使用 MLflow 进行评估，并服务我们的 Web 原生模型，而无需为每个阶段构建单独的堆栈。——Zach Richardson，TinyFish 人工智能负责人

将代理行为转化为更好的模型

TinyFish 开始通过监督微调对其 Web 原生模型进行后训练，并正在转向直接偏好优化（DPO）。团队通过 AI Runtime 在 Databricks 托管的 GPU 上运行这些工作负载，使研究人员能够使用 GPU 基础设施，而无需自己运营单独的训​​练平台。

训练工作与 TinyFish 评估其模型的方式密切相关。由于该模型作为更大 Web 代理的一部分运行，仅评估单个模型响应只能说明部分情况。TinyFish 改为评估完整代理是否成功完成所请求的任务。

在其内部 go/no-go 基准测试中，TinyFish 的 Web 原生模型成功完成了 2,178 个 Web 代理任务中的 1,691 个，任务成功率为 77.6%。一个单独的 LLM 评判器会审查原始请求、代理的操作历史及其最终结果。只有在完成所请求的操作或返回满足所有要求的正确答案时，任务才通过；部分完成、错误答案和无效结果均计为失败。

这为 TinyFish 提供了模型开发的有用信号。团队可以看到其模型的变更如何影响完整代理的性能，并利用这些结果指导后续的后训练。

成功的模型迭代随后可以通过 Databricks Model Serving 进入生产环境。TinyFish 已经在 Databricks 上服务生产模型，包括其搜索重排序器和查询重写器。团队还在该平台上托管并服务其 Web 原生模型。

在最近的 15 天期间，TinyFish 记录了 294,781 次涉及其 Web 原生模型的代理运行，涵盖 640 万个工具步骤。该期间估计的模型服务成本为每次运行 0.088 美元，即每个工具步骤 0.0040 美元。这些数字仅反映 TinyFish Web 原生模型的服务成本，而非完整代理堆栈，并为团队提供了一种一致的方式，在 Databricks 中将服务经济性与质量和使用数据一起跟踪。

这些能力共同为 TinyFish 提供了一条从代理行为到后训练、评估和部署的连续路径。评估结果、使用数据和成本报告可以与服务工作负载一起保留在 Databricks 中，为团队提供共同基础，以了解其模型的表现并为后续模型开发提供信息。

为代理实际执行的工作构建模型

通用基础模型在 TinyFish 的代理架构中仍然发挥着重要作用，但其 Web 原生模型为团队提供了一个可以专门针对 Web 代理任务进行优化的系统。

TinyFish 可以针对其产品实际需要执行的任务来开发和评估其模型，而不是在整个代理中完全依赖外部基础模型 API。支持这种方法需要的不仅仅是 GPU 容量。开发周期涵盖后训练、评估、生产服务以及围绕模型的运营数据。

AI Runtime 为 TinyFish 提供了与其用于周边机器学习生命周期的同一 Databricks 环境内的托管 GPU 基础设施。这使团队能够将训练和服务保持在用于了解其模型表现情况的评估和运营数据附近，而不是围绕模型构建单独的深度学习堆栈。

除了自己的模型之外，TinyFish 正在通过 Unity Gateway 整合对外部基础模型的访问，以实现集中成本跟踪、密钥管理和治理。这为团队提供了一种更一致的方式来管理模型流量，随着代理堆栈的扩展。

对于一家成长中的人工智能公司来说，好处是实际的：需要运营的独立系统更少，意味着更多工程时间可以专注于使 TinyFish 脱颖而出的模型和产品行为。

TinyFish 的优势在于我们能多快让智能体变得更好。我们不希望工程师把时间花在管理 GPU 基础设施，或在彼此割裂的系统之间迁移模型和数据上。Databricks 为我们提供了一个统一的基础，用于构建、改进和运行我们的 Web 原生模型，让团队能够专注于产品。——Sudheesh Nair，TinyFish 联合创始人兼 CEO

为下一代模型迭代而构建

TinyFish 持续演进其开发 Web 原生模型的方法，在监督式微调之外扩展到 DPO，并随着模型的发展探索更大规模的训练工作负载。

底层工作流的设计宗旨是在这些技术变化时保持一致。智能体评估可以显示模型在哪些方面表现良好、在哪些方面还需要进一步工作。这些信息可以反馈到训练后阶段，新版本可以针对完整任务进行评估，而准备好投入生产的模型可以从同一环境中提供服务。

通过在 Databricks 上运行这一生命周期，TinyFish 可以将 GPU 基础设施视为其 ML 平台的一部分，而不是团队必须自行组装和维护的独立系统。这为团队提供了一条更直接的路径，从在生产中了解其模型的情况，到进行模型的下一轮迭代。

将最新文章发送到你的收件箱

订阅我们的博客，即可将最新文章发送到你的收件箱。

注册

查看所有博客