当前位置：首页 > 文章列表 > 文章 > 前端 > 测试 LLM 应用程序：模拟 SDK 与直接 HTTP 请求中的不幸事件

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

来源：dev.to 2024-11-23 10:52:05 0浏览收藏

推广推荐

支持 PC / 移动端，安全直达

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《测试 LLM 应用程序：模拟 SDK 与直接 HTTP 请求中的不幸事件》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

介绍

让我在这篇博客的前言中说，这个与我的其他博客不同，在这些博客中我能够逐步完成完成任务的步骤。相反，这更多地反映了我在尝试向我的项目 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 提供了出色的开发人员体验，但它们可能会使某些测试方法变得更加困难。在构建应用程序时值得考虑这种权衡。