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

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《测试 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 拦截。

经验教训

1. 尽早考虑测试策略：在 sdk 和直接 http 请求之间进行选择时，请考虑如何测试实现。有时，“更干净”的生产代码可能会使测试更具挑战性。

2. sdk 测试需要不同的工具：使用 sdk 时，需要在 sdk 级别而不是 http 级别进行模拟。这意味着：

   • 模拟整个 sdk 客户端
   • 专注于 sdk 的接口而不是 http 请求
   • 使用 jest 的模块模拟​​功能而不是 http 拦截器

3. 便利性和可测试性之间的平衡：虽然 sdk 提供了出色的开发人员体验，但它们可能会使某些测试方法变得更加困难。在构建应用程序时值得考虑这种权衡。

前进

虽然我还没有完全解决我的测试挑战，但这段经历教会了我关于通过 sdk 测试依赖于外部服务的应用程序的宝贵经验。对于构建类似应用程序的任何人，我建议：

1. 在 sdk 和直接 api 调用之间进行选择时考虑测试策略
2. 如果使用 sdk，请计划在 sdk 级别而不是 http 级别进行模拟
3. 考虑在 sdk 周围编写薄包装器，使它们更易于测试
4. 为可能参与该项目的其他人记录测试方法

结论

测试 llm 应用程序带来了独特的挑战，特别是在平衡 sdk 等现代开发便利性与彻底测试的需要时。虽然我仍在努力提高 gimme_readme 的测试覆盖率，但这次经历让我更好地了解了如何在涉及外部服务和 sdk 的未来项目中进行测试。

还有其他人在测试使用 llm sdk 的应用程序时遇到过类似的挑战吗？我很想在评论中听到您的经验和解决方案！

本篇关于《测试 LLM 应用程序：模拟 SDK 与直接 HTTP 请求中的不幸事件》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！