Fehlerbehandlung und Resilienz-Muster
Entwerfen Sie robuste Fehlerbehandlung, Wiederholungsmechanismen und Circuit Breaker, um Ihre LLM-Anwendungen fehlertoleranter zu machen.
Fehlerbehandlung und Resilienz-Muster ist eine kostenlose LLM Apps in Production (RAG + Vector DB + Caching)-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des LLM Apps in Production (RAG + Vector DB + Caching)-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der LLM Apps in Production (RAG + Vector DB + Caching)-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Build Robust LLM Apps
LLM applications, especially those interacting with external APIs, need to be tough!
Resilience is about designing systems that can recover from failures gracefully, without crashing or providing a bad user experience.
In this lesson, we'll learn patterns to make your LLM apps more fault-tolerant.
Typical Failures
What kind of errors can an LLM application face?
- API Rate Limits: Too many requests at once.
- Network Issues: Temporary connection drops.
- LLM Service Unavailability: The LLM provider is down.
- Bad LLM Responses: Model returns invalid JSON or hallucinates.
- Dependency Failures: Vector DB or other services fail.
Standard Try-Catch
The first line of defense is standard error handling using try-catch blocks. This prevents your entire application from crashing when an expected error occurs.
It allows you to log the error, inform the user, or attempt a fallback.
public class Main {
public static void main(String[] args) {
try {
// Simulate an LLM API call that might fail
callLlmApi();
System.out.println("API call successful.");
} catch (Exception e) {
System.out.println("Error: " + e.getMessage());
// Log the error, notify user, etc.
}
}
public static void callLlmApi() throws Exception {
// In a real app, this would make an actual API call
if (Math.random() < 0.5) { // 50% chance of failure
throw new RuntimeException("LLM service unavailable.");
}
}
}Why Just Catching Isn't Enough
Some errors are transient, meaning they're temporary and might resolve if you just try again. Think of a brief network glitch or a momentary rate limit.
A simple try-catch just fails immediately. For transient errors, a retry mechanism can significantly improve reliability without user intervention.
Simple Retry Logic
We can implement a basic retry loop. If an error occurs, we wait a bit and try again, up to a maximum number of attempts.
public class Main {
public static void main(String[] args) {
int maxRetries = 3;
int currentRetry = 0;
boolean success = false;
while (currentRetry < maxRetries && !success) {
try {
System.out.println("Attempt " + (currentRetry + 1));
callLlmApi();
System.out.println("API call successful.");
success = true;
} catch (Exception e) {
System.out.println("Error: " + e.getMessage());
currentRetry++;
if (currentRetry < maxRetries) {
System.out.println("Retrying in 1 second...");
try { Thread.sleep(1000); } catch (InterruptedException ie) {}
}
}
}
if (!success) {
System.out.println("All retries failed.");
}
}
public static void callLlmApi() throws Exception {
// Simulate an LLM API call with 70% chance of failure
if (Math.random() < 0.7) {
throw new RuntimeException("Transient network error.");
}
}
}Smart Retries: Exponential Backoff
Constant retry delays can overwhelm a struggling service. Exponential backoff is a strategy where the delay between retries increases exponentially.
This gives the remote service more time to recover and prevents your app from hammering it with requests.
- Initial delay: 1s
- Second delay: 2s
- Third delay: 4s
- And so on...
Circuit Breaker Pattern
What if a service is truly down, not just experiencing transient errors? Retrying repeatedly only wastes resources and delays failure detection.
The Circuit Breaker pattern prevents an application from repeatedly trying to invoke a service that is likely to fail, saving resources and allowing the service time to recover.
Circuit Breaker States
A circuit breaker has three main states:
- Closed: Operations proceed normally. If errors exceed a threshold, it trips to Open.
- Open: All requests fail immediately without trying the service. After a timeout, it transitions to Half-Open.
- Half-Open: A limited number of requests are allowed to pass through to test if the service has recovered. If successful, it goes back to Closed; otherwise, back to Open.
Preventing Hung Requests with Timeouts
LLM API calls can sometimes hang indefinitely, waiting for a response that never comes. This can exhaust resources and degrade user experience.
Always configure timeouts for your API calls. This sets a maximum duration your application will wait for a response before giving up and throwing an error.
import java.util.concurrent.TimeUnit;
public class Main {
public static void main(String[] args) {
long startTime = System.nanoTime();
long timeoutMillis = 2000; // 2 seconds timeout
try {
System.out.println("Calling LLM API with a timeout...");
callLlmApiWithTimeout(timeoutMillis);
System.out.println("API call completed successfully.");
} catch (Exception e) {
System.out.println("API call failed: " + e.getMessage());
}
long endTime = System.nanoTime();
long duration = TimeUnit.NANOSECONDS.toMillis(endTime - startTime);
System.out.println("Total duration: " + duration + "ms");
}
public static void callLlmApiWithTimeout(long timeoutMillis) throws Exception {
// Simulate a long-running/hung API call
long processingTime = 2500; // 2.5 seconds
if (processingTime > timeoutMillis) {
throw new RuntimeException("Operation timed out after " + timeoutMillis + "ms");
}
try {
Thread.sleep(processingTime);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException("API call interrupted.", e);
}
}
}Resilience Check
When should you use a Circuit Breaker pattern instead of just a Retry mechanism?
Recap: Building Resilient LLM Apps
We've covered key patterns for making your LLM applications fault-tolerant:
- Basic Error Handling: Using
try-catchfor immediate failure management. - Retry Mechanisms: For handling transient errors, often with exponential backoff.
- Circuit Breakers: To prevent overwhelming consistently failing services.
- Timeouts: Essential for preventing hung API calls and resource exhaustion.
These patterns are crucial for robust production LLM systems!
Häufig gestellte Fragen
Ist die Lektion „Fehlerbehandlung und Resilienz-Muster“ kostenlos?
Ja — der vollständige Text von „Fehlerbehandlung und Resilienz-Muster“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des LLM Apps in Production (RAG + Vector DB + Caching)-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der LLM Apps in Production (RAG + Vector DB + Caching)-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Fehlerbehandlung und Resilienz-Muster“?
Entwerfen Sie robuste Fehlerbehandlung, Wiederholungsmechanismen und Circuit Breaker, um Ihre LLM-Anwendungen fehlertoleranter zu machen. Du übst LLM Apps in Production (RAG + Vector DB + Caching) mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um LLM Apps in Production (RAG + Vector DB + Caching) zu starten?
Keine Vorkenntnisse erforderlich. LLM Apps in Production (RAG + Vector DB + Caching) auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.
Wie lange dauert die Lektion „Fehlerbehandlung und Resilienz-Muster“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser LLM Apps in Production (RAG + Vector DB + Caching)-Lektion Code schreiben und ausführen?
Ja. Jede LLM Apps in Production (RAG + Vector DB + Caching)-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- LLM-API-Schlüssel und sensible Daten schützen
- Ratenbegrenzung und Missbrauchsprävention
- Fehlerbehandlung und Resilienz-Muster
- Schutz vor Prompt Injection