测试 LLM 应用程序：模拟 SDK 与直接 HTTP 请求中的不幸事件-js教程-PHP中文网

测试 LLM 应用程序：模拟 SDK 与直接 HTTP 请求中的不幸事件

Barbara Streisand

发布： 2024-12-04 11:03:14

原创

172 人浏览过

Testing LLM Applications: Misadventures in Mocking SDKs vs Direct HTTP Requests

介绍

让我在这篇博客的前言中说，这个与我的其他博客不同，在这些博客中我能够逐步完成完成任务的步骤。相反，这更多地反映了我在尝试向我的项目 gimme_readme 添加测试时遇到的挑战，以及我在此过程中学到的关于测试 LLM 支持的应用程序的知识。

背景

本周，我和我的开源开发同学的任务是向包含大型语言模型 (LLM) 的命令行工具添加测试。乍一看这似乎很简单，但它让我陷入了一个我没有预料到的测试复杂性的兔子洞。

我的测试之旅

最初的方法

当我第一次构建 gimme_readme 时，我使用 Jest.js 添加了一些基本测试。这些测试相当简单，主要关注：

验证函数输出
检查基本错误处理
测试简单的实用函数

虽然这些测试提供了一些覆盖范围，但它们并没有测试我的申请中最关键的部分之一：LLM 交互。

挑战：测试 LLM 交互

当我尝试添加更全面的测试时，我对我的应用程序如何与法学硕士进行通信有了一个有趣的认识。最初，我认为可以使用 Nock.js 来模拟对这些语言模型的 HTTP 请求。毕竟，这就是 Nock 的擅长之处 - 拦截和模拟 HTTP 请求以进行测试。

但是，我发现我使用LLM的方式让我很难使用Nock编写测试。

SDK 与直接 HTTP 请求的困境

这就是事情变得有趣的地方。我的应用程序使用由 LLM 服务（例如 Google 的 Gemini 和 Groq）提供的官方 SDK 客户端。这些 SDK 充当抽象层，在幕后处理所有 HTTP 通信。虽然这使得代码更干净、更容易在生产中使用，但它带来了有趣的测试挑战。

考虑这两种实现 LLM 功能的方法：

// Approach 1: Using SDK
const groq = new Groq({ apiKey });
const response = await groq.chat.completions.create({
  messages: [{ role: "user", content: prompt }],
  model: "mixtral-8x7b-32768"
});

// Approach 2: Direct HTTP requests
const response = await fetch('https://api.groq.com/v1/completions', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${apiKey}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    messages: [{ role: "user", content: prompt }],
    model: "mixtral-8x7b-32768"
  })
});

登录后复制

SDK 方法更简洁，并提供更好的开发人员体验，但它使得 Nock 等传统 HTTP 模拟工具不太有用。 HTTP 请求发生在 SDK 内部，这使得它们更难被 Nock 拦截。

经验教训

尽早考虑测试策略：在 SDK 和直接 HTTP 请求之间进行选择时，请考虑如何测试实现。有时“更干净”的生产代码可能会使测试更具挑战性。
SDK 测试需要不同的工具：使用 SDK 时，需要在 SDK 级别而不是 HTTP 级别进行模拟。这意味着：
- 模拟整个 SDK 客户端
- 专注于 SDK 的接口而不是 HTTP 请求
- 使用 Jest 的模块模拟功能而不是 HTTP 拦截器
便利性和可测试性之间的平衡：虽然 SDK 提供了出色的开发人员体验，但它们可能会使某些测试方法变得更加困难。在构建应用程序时值得考虑这种权衡。