LLM-applikationer i produktion (RAG + vektordatabase + caching) · Lektion

Fejlhåndtering og resiliensmønstre

Design robust fejlhåndtering, mekanismer til gentagne forsøg og circuit breakers for at gøre Deres LLM-applikationer mere modstandsdygtige over for fejl.

Lektion 3 af 411 trin

Fejlhåndtering og resiliensmønstre er en gratis LLM-applikationer i produktion (RAG + vektordatabase + caching)-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i LLM-applikationer i produktion (RAG + vektordatabase + caching), og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. LLM-applikationer i produktion (RAG + vektordatabase + caching)-kurset indeholder 4 lektioner i alt.

Byg robuste LLM-programmer

LLM-programmer, især dem der kommunikerer med eksterne API'er, skal være modstandsdygtige!

Modstandskraft handler om at designe systemer, der kan komme sig over fejl på en ordentlig måde uden at gå ned eller give brugeren en dårlig oplevelse.

I denne lektion lærer du mønstre, der gør dine LLM-programmer bedre til at håndtere fejl.

Typiske fejl

Hvilke fejl kan et LLM-program støde på?

API-hastighedsbegrænsninger: For mange forespørgsler på én gang.
Netværksproblemer: Midlertidige forbindelsesafbrydelser.
Utilgængelig LLM-tjeneste: LLM-udbyderen er nede.
Ugyldige LLM-svar: Modellen returnerer ugyldig JSON eller hallucinerer.
Fejl i afhængigheder: Vektordatabasen eller andre tjenester svigter.

Standard-try-catch

Den første forsvarslinje er almindelig fejlhåndtering ved hjælp af try-catch-blokke. Det forhindrer hele dit program i at gå ned, når der opstår en forventet fejl.

Det giver dig mulighed for at logge fejlen, informere brugeren eller forsøge med en reservefunktion.

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

Hvorfor det ikke er nok bare at fange fejl

Nogle fejl er forbigående, hvilket betyder, at de er midlertidige og måske forsvinder, hvis du prøver igen. Det kan f.eks. være en kortvarig netværksfejl eller en midlertidig hastighedsbegrænsning.

En simpel try-catch mislykkes med det samme. Ved forbigående fejl kan en mekanisme til nye forsøg forbedre pålideligheden betydeligt uden brugerindgriben.

Enkel logik til nye forsøg

Vi kan implementere en enkel løkke til nye forsøg. Hvis der opstår en fejl, venter vi lidt og prøver igen, op til et maksimalt antal forsøg.

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

Smarte nye forsøg: eksponentiel backoff

Konstante forsinkelser mellem nye forsøg kan overbelaste en tjeneste, der allerede har problemer. Eksponentiel backoff er en strategi, hvor forsinkelsen mellem nye forsøg øges eksponentielt.

Det giver den eksterne tjeneste mere tid til at komme sig og forhindrer, at dit program bombarderer den med forespørgsler.

Indledende forsinkelse: 1s
Anden forsinkelse: 2s
Tredje forsinkelse: 4s
Og så videre...

Circuit Breaker-mønsteret

Hvad nu, hvis en tjeneste virkelig er nede og ikke blot oplever forbigående fejl? Gentagne nye forsøg spilder kun ressourcer og forsinker registreringen af fejlen.

Circuit Breaker-mønsteret forhindrer et program i gentagne gange at forsøge at kalde en tjeneste, der sandsynligvis vil fejle. Det sparer ressourcer og giver tjenesten tid til at komme sig.

Circuit Breaker-tilstande

En circuit breaker har tre hovedtilstande:

Lukket: Operationer fortsætter normalt. Hvis antallet af fejl overstiger en tærskel, skifter den til Åben.
Åben: Alle forespørgsler mislykkes med det samme uden at forsøge at kontakte tjenesten. Efter en timeout skifter den til Halvåben.
Halvåben: Et begrænset antal forespørgsler får lov til at passere for at teste, om tjenesten er kommet sig. Hvis det lykkes, skifter den tilbage til Lukket; ellers tilbage til Åben.

Undgå fastlåste forespørgsler med timeouts

LLM API-kald kan nogle gange hænge på ubestemt tid, mens de venter på et svar, der aldrig kommer. Det kan opbruge ressourcer og forringe brugeroplevelsen.

Konfigurer altid timeouts for dine API-kald. Det angiver den maksimale tid, dit program vil vente på et svar, før det giver op og udløser en fejl.

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

Robusthedstjek

Hvornår bør du bruge mønstret Circuit Breaker i stedet for blot en Retry-mekanisme?

Besvar den i den interaktive lektion

Opsummering: Opbygning af robuste LLM-programmer

Vi har gennemgået vigtige mønstre til at gøre dine LLM-programmer modstandsdygtige over for fejl:

Grundlæggende fejlhåndtering: Brug af try-catch til øjeblikkelig håndtering af fejl.
Forsøgsmekanismer: Til håndtering af midlertidige fejl, ofte med eksponentiel backoff.
Circuit breakers: Til at forhindre, at tjenester med vedvarende fejl bliver overbelastet.
Timeouts: Vigtige for at forhindre fastlåste API-kald og opbrugte ressourcer.

Disse mønstre er afgørende for robuste LLM-systemer i produktion!

Gratis at komme i gang

Lær LLM-applikationer i produktion (RAG + vektordatabase + caching) med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 12
Lektioner: 48

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Fejlhåndtering og resiliensmønstre” gratis?

Ja — hele teksten til “Fejlhåndtering og resiliensmønstre” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af LLM-applikationer i produktion (RAG + vektordatabase + caching)-kurset, skal du opgradere til CoddyKit PRO. LLM-applikationer i produktion (RAG + vektordatabase + caching)-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Fejlhåndtering og resiliensmønstre”?

Design robust fejlhåndtering, mekanismer til gentagne forsøg og circuit breakers for at gøre Deres LLM-applikationer mere modstandsdygtige over for fejl. Du øver dig i LLM-applikationer i produktion (RAG + vektordatabase + caching) med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på LLM-applikationer i produktion (RAG + vektordatabase + caching)?

Der kræves ingen tidligere erfaring. LLM-applikationer i produktion (RAG + vektordatabase + caching) på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.

Hvor lang tid tager lektionen “Fejlhåndtering og resiliensmønstre”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne LLM-applikationer i produktion (RAG + vektordatabase + caching)-lektion?

Ja. Alle LLM-applikationer i produktion (RAG + vektordatabase + caching)-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Sikring af LLM-API-nøgler og følsomme data
Rate limiting og forebyggelse af misbrug
Fejlhåndtering og resiliensmønstre
Beskyttelse mod prompt injection

← Tilbage til LLM-applikationer i produktion (RAG + vektordatabase + caching)