LLM-applikationer i produktion (RAG + vektordatabaser + cachning) · Lektion

Felhantering och resiliensmönster

Utforma robust felhantering, mekanismer för nya försök och circuit breakers för att göra era LLM-applikationer mer feltåliga.

Lektion 3 av 411 steg

Felhantering och resiliensmönster är en gratis lektion i LLM-applikationer i produktion (RAG + vektordatabaser + cachning) på CoddyKit. Detta är lektion 3 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för LLM-applikationer i produktion (RAG + vektordatabaser + cachning), och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i LLM-applikationer i produktion (RAG + vektordatabaser + cachning) innehåller totalt 4 lektioner.

Bygg robusta LLM-applikationer

LLM-applikationer, särskilt de som kommunicerar med externa API:er, måste vara tåliga!

Resiliens handlar om att utforma system som kan återhämta sig från fel på ett smidigt sätt, utan att krascha eller ge användaren en dålig upplevelse.

I den här lektionen lär vi oss mönster som gör dina LLM-applikationer mer feltåliga.

Typiska fel

Vilka typer av fel kan en LLM-applikation råka ut för?

API-hastighetsbegränsningar: För många förfrågningar på en gång.
Nätverksproblem: Tillfälliga anslutningsavbrott.
LLM-tjänsten otillgänglig: LLM-leverantören ligger nere.
Felaktiga LLM-svar: Modellen returnerar ogiltig JSON eller hallucinerar.
Fel i beroenden: Vektordatabasen eller andra tjänster slutar fungera.

Standardiserad try-catch

Den första försvarslinjen är standardiserad felhantering med try-catch-block. Det förhindrar att hela applikationen kraschar när ett förväntat fel inträffar.

Det gör att du kan logga felet, informera användaren eller försöka använda en reservlösning.

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

Varför det inte räcker att bara fånga felet

Vissa fel är tillfälliga, vilket innebär att de kan försvinna om du försöker igen. Tänk på ett kortvarigt nätverksproblem eller en tillfällig hastighetsbegränsning.

En enkel try-catch misslyckas direkt. Vid tillfälliga fel kan en mekanism för nya försök förbättra tillförlitligheten avsevärt utan att användaren behöver ingripa.

Enkel logik för nya försök

Vi kan implementera en enkel loop för nya försök. Om ett fel inträffar väntar vi en stund och försöker igen, upp till ett maximalt antal försök.

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

Smarta nya försök: exponentiell backoff

Konstanta fördröjningar mellan nya försök kan överbelasta en redan hårt belastad tjänst. Exponentiell backoff är en strategi där fördröjningen mellan försöken ökar exponentiellt.

Det ger fjärrtjänsten mer tid att återhämta sig och förhindrar att din app överöser den med förfrågningar.

Inledande fördröjning: 1 s
Andra fördröjningen: 2 s
Tredje fördröjningen: 4 s
Och så vidare …

Circuit breaker-mönstret

Vad händer om en tjänst faktiskt ligger nere och inte bara drabbas av tillfälliga fel? Att försöka om och om igen slösar bara resurser och fördröjer upptäckten av felet.

Circuit breaker-mönstret förhindrar att en applikation upprepade gånger försöker anropa en tjänst som sannolikt kommer att misslyckas. Det sparar resurser och ger tjänsten tid att återhämta sig.

Circuit breaker-tillstånd

En circuit breaker har tre huvudlägen:

Stängd: Operationerna fortsätter normalt. Om antalet fel överskrider en tröskel löser den ut och övergår till Öppen.
Öppen: Alla förfrågningar misslyckas omedelbart utan att tjänsten kontaktas. Efter en timeout övergår den till Halvöppen.
Halvöppen: Ett begränsat antal förfrågningar tillåts passera för att testa om tjänsten har återhämtat sig. Om de lyckas övergår den till Stängd; annars tillbaka till Öppen.

Förhindra hängande förfrågningar med timeouts

LLM API-anrop kan ibland hänga sig på obestämd tid i väntan på ett svar som aldrig kommer. Det kan förbruka resurser och försämra användarupplevelsen.

Konfigurera alltid timeouts för era API-anrop. Det anger hur länge programmet som mest väntar på ett svar innan det ger upp och kastar ett fel.

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

Resilienskontroll

När bör ni använda mönstret Circuit Breaker i stället för enbart en mekanism för Retry?

Besvara frågan i den interaktiva lektionen

Sammanfattning: Bygga resilienta LLM-appar

Vi har gått igenom viktiga mönster för att göra era LLM-applikationer feltåliga:

Grundläggande felhantering: Användning av try-catch för att hantera fel direkt.
Försöksmekanismer: För hantering av tillfälliga fel, ofta med exponentiell backoff.
Circuit breakers: För att förhindra att tjänster som ständigt misslyckas överbelastas.
Timeouts: Avgörande för att förhindra hängande API-anrop och uttömning av resurser.

Dessa mönster är avgörande för robusta LLM-system i produktion!

Gratis att börja

Lär dig LLM-applikationer i produktion (RAG + vektordatabaser + cachning) med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 12
Lektioner: 48

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”Felhantering och resiliensmönster” gratis?

Ja – hela texten till ”Felhantering och resiliensmönster” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i LLM-applikationer i produktion (RAG + vektordatabaser + cachning), kan Ni uppgradera till CoddyKit PRO. Kursen i LLM-applikationer i produktion (RAG + vektordatabaser + cachning) innehåller totalt 4 lektioner.

Vad lär jag mig i ”Felhantering och resiliensmönster”?

Utforma robust felhantering, mekanismer för nya försök och circuit breakers för att göra era LLM-applikationer mer feltåliga. Ni övar på LLM-applikationer i produktion (RAG + vektordatabaser + cachning) med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig LLM-applikationer i produktion (RAG + vektordatabaser + cachning)?

Du behöver inga förkunskaper. Utbildningen i LLM-applikationer i produktion (RAG + vektordatabaser + cachning) på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Felhantering och resiliensmönster”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här LLM-applikationer i produktion (RAG + vektordatabaser + cachning)-lektionen?

Ja. Varje LLM-applikationer i produktion (RAG + vektordatabaser + cachning)-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

Skydda LLM-API-nycklar och känsliga data
Hastighetsbegränsning och förebyggande av missbruk
Felhantering och resiliensmönster
Försvara er mot prompt injection

← Tillbaka till LLM-applikationer i produktion (RAG + vektordatabaser + cachning)