測試 LLM 應用程式：模擬 SDK 與直接 HTTP 請求中的不幸事件-js教程-PHP中文網

測試 LLM 應用程式：模擬 SDK 與直接 HTTP 請求中的不幸事件

Barbara Streisand

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

原創

237 人瀏覽過

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 提供了出色的開發人員體驗，但它們可能會使某些測試方法變得更加困難。在建立應用程式時值得考慮這種權衡。