Testen von LLM-Anwendungen: Missgeschicke beim Verspotten von SDKs im Vergleich zu direkten HTTP-Anfragen

Einführung

Lassen Sie mich vor diesem Blog Folgendes sagen: ist nicht wie in meinen anderen Blogs, in denen ich die Schritte durchgehen konnte, die ich zur Erledigung einer Aufgabe unternommen habe. Stattdessen ist dies eher eine Reflexion über die Herausforderungen, denen ich begegnet bin, als ich versuchte, Tests zu meinem Projekt, gimme_readme, hinzuzufügen, und darüber, was ich dabei über das Testen von LLM-basierten Anwendungen gelernt habe.

Der Kontext

Diese Woche wurden meine Klassenkameraden in der Open-Source-Entwicklung und ich damit beauftragt, Tests zu unseren Befehlszeilentools hinzuzufügen, die Large Language Models (LLMs) integrieren. Das schien zunächst unkompliziert, aber es führte mich in ein Kaninchenloch voller Testkomplexitäten, mit denen ich nicht gerechnet hatte.

Meine Testreise

Der erste Ansatz

Als ich gimme_readme zum ersten Mal erstellt habe, habe ich einige grundlegende Tests mit Jest.js hinzugefügt. Diese Tests waren recht einfach und konzentrierten sich hauptsächlich auf Folgendes:

• Funktionsausgaben überprüfen
• Überprüfung der grundlegenden Fehlerbehandlung
• Testen einfacher Hilfsfunktionen

Obwohl diese Tests eine gewisse Abdeckung boten, testeten sie nicht einen der kritischsten Teile meiner Anwendung: die LLM-Interaktionen.

Die Herausforderung: LLM-Interaktionen testen

Als ich versuchte, umfassendere Tests hinzuzufügen, stieß ich auf eine interessante Erkenntnis darüber, wie meine Anwendung mit LLMs kommuniziert. Anfangs dachte ich, ich könnte Nock.js verwenden, um die HTTP-Anfragen an diese Sprachmodelle zu verspotten. Schließlich ist Nock darin großartig: HTTP-Anfragen zu Testzwecken abzufangen und zu verspotten.

Ich habe jedoch festgestellt, dass die Art und Weise, wie ich LLM verwende, es mir schwer macht, Tests mit Nock zu schreiben. Das Dilemma zwischen SDK und direkten HTTP-Anfragen

Hier wird es interessant. Meine Anwendung verwendet offizielle SDK-Clients, die von LLM-Diensten wie Gemini und Groq von Google bereitgestellt werden. Diese SDKs fungieren als Abstraktionsebenen, die

die gesamte HTTP-Kommunikation im Hintergrund abwickeln

. Dies macht den Code zwar sauberer und erleichtert die Arbeit mit ihm in der Produktion, stellt aber auch eine interessante Testherausforderung dar. Betrachten Sie diese beiden Ansätze zur Implementierung der LLM-Funktionalität:

Der SDK-Ansatz ist sauberer und bietet eine bessere Entwicklererfahrung, macht jedoch herkömmliche HTTP-Mocking-Tools wie Nock weniger nützlich. Die HTTP-Anfragen erfolgen innerhalb des SDK, was es schwieriger macht, sie

// 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"
  })
});

mit Nock abzufangen

. Gelernte Lektionen

1. Erwägen Sie frühzeitig die Teststrategie

   : Überlegen Sie bei der Wahl zwischen SDKs und direkten HTTP-Anfragen, wie Sie die Implementierung testen. Manchmal macht der „sauberere“ Produktionscode das Testen schwieriger.

2. SDK-Tests erfordern unterschiedliche Tools: Wenn Sie SDKs verwenden, müssen Sie auf SDK-Ebene statt auf HTTP-Ebene simulieren. Das bedeutet:

   • Verspottung des gesamten SDK-Clients
   • Konzentrieren Sie sich auf die SDK-Schnittstelle und nicht auf HTTP-Anfragen
   • Verwendung der Modul-Mocking-Funktionen von Jest anstelle von HTTP-Interceptoren

3. Gleichgewicht zwischen Komfort und Testbarkeit: Während SDKs eine großartige Entwicklererfahrung bieten, können sie bestimmte Testansätze schwieriger machen. Es lohnt sich, diesen Kompromiss bei der Architektur Ihrer Anwendung zu berücksichtigen.

Vorwärts gehen

Obwohl ich meine Testherausforderungen noch nicht vollständig gelöst habe, habe ich durch diese Erfahrung wertvolle Lektionen über das Testen von Anwendungen gelernt, die auf externen Diensten über SDKs basieren. Für alle, die ähnliche Anwendungen erstellen, würde ich Folgendes empfehlen:

1. Denken Sie über die Teststrategie nach, wenn Sie zwischen SDKs und direkten API-Aufrufen wählen
2. Wenn Sie SDKs verwenden, planen Sie eine Verspottung auf SDK-Ebene und nicht auf HTTP-Ebene
3. Denken Sie darüber nach, dünne Wrapper um SDKs zu schreiben, um sie testbarer zu machen
4. Dokumentieren Sie den Testansatz für andere, die möglicherweise an dem Projekt arbeiten

Abschluss

Das Testen von LLM-Anwendungen stellt einzigartige Herausforderungen dar, insbesondere wenn moderne Entwicklungsfunktionen wie SDKs mit der Notwendigkeit gründlicher Tests in Einklang gebracht werden müssen. Während ich immer noch daran arbeite, die Testabdeckung für gimme_readme zu verbessern, habe ich durch diese Erfahrung ein besseres Verständnis dafür gewonnen, wie ich Tests in zukünftigen Projekten angehen soll, die externe Dienste und SDKs beinhalten.

Ist jemand beim Testen von Anwendungen, die LLM-SDKs verwenden, auf ähnliche Herausforderungen gestoßen? Ich freue mich über eure Erfahrungen und Lösungen in den Kommentaren!

Das obige ist der detaillierte Inhalt vonTesten von LLM-Anwendungen: Missgeschicke beim Verspotten von SDKs im Vergleich zu direkten HTTP-Anfragen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!