Przejdź do nawigacji
Zaawansowane

Kaskadowanie LLM

Dowiedz się, jak Agents Platform zapewnia niezawodne odpowiedzi LLM dzięki kaskadowemu mechanizmowi awaryjnemu.

Omówienie

Agents Platform wykorzystuje mechanizm kaskadowania LLM, aby zwiększyć niezawodność i odporność funkcji generowania tekstu. Jeśli skonfigurowany główny LLM zawiedzie, system automatycznie próbuje użyć zapasowych Large Language Models (LLM), zapewniając płynniejsze i bardziej spójne działanie.

Awarie mogą obejmować błędy API, przekroczenia limitu czasu lub puste odpowiedzi od dostawcy LLM. Logika kaskadowania sprawnie obsługuje takie sytuacje.

Jak to działa

Proces kaskadowania przebiega według określonej sekwencji:

  1. Próba użycia preferowanego LLM: System najpierw próbuje wygenerować odpowiedź za pomocą LLM wybranego w konfiguracji agenta.

  2. Sekwencja zapasowych LLM: Jeśli preferowany LLM zawiedzie, system automatycznie przechodzi do zdefiniowanej sekwencji zapasowych LLM. Sekwencja jest dobierana na podstawie wydajności, szybkości i niezawodności modeli. Obecna domyślna sekwencja (może ulec zmianie) to:

    1. Gemini 3.5 Flash
    2. GPT-4o
    3. Gemini 3.5 Flash-Lite
    4. Claude Sonnet 4.6

  3. Zgodność z HIPAA: Jeśli agent działa w trybie wymagającym ścisłej prywatności danych (zgodność z HIPAA / zerowa retencja danych), lista zapasowa jest filtrowana tak, aby obejmowała wyłącznie zgodne modele z powyższej sekwencji.

  4. Ponowne próby: System ponawia proces generowania wielokrotnie (co najmniej 3 próby) dla sekwencji dostępnych LLM (preferowany + zapasowe). Jeśli zapasowy LLM również zawiedzie, system przechodzi do kolejnego w sekwencji. Jeśli w limicie ponownych prób zabraknie unikalnych zapasowych LLM, może ponownie spróbować modeli zapasowych, które wcześniej zawiodły.

  5. Leniwa inicjalizacja: Połączenia z zapasowymi LLM są inicjalizowane tylko wtedy, gdy są potrzebne, co optymalizuje użycie zasobów.

Konkretna lista i kolejność zapasowych LLM są zarządzane wewnętrznie przez ElevenLabs i optymalizowane pod kątem wydajności i dostępności. Powyższa sekwencja przedstawia obecne ustawienie domyślne, ale może zostać zmieniona bez powiadomienia.

Własne LLM

Gdy skonfigurujesz własny LLM jako główny model, standardowa logika kaskadowania do modeli hostowanych przez ElevenLabs jest domyślnie pomijana. System próbuje użyć twojego własnego LLM, a jeśli zawiedzie, ponawia żądanie z tym samym własnym LLM wielokrotnie (zgodnie ze standardową minimalną liczbą prób), zanim uzna żądanie za nieudane.

To domyślne ustawienie utrzymuje cały ruch na własnym endpoincie, ale oznacza, że długotrwała awaria własnego LLM kończy rozmowę. Aby rozmowy trwały dalej, gdy własny LLM jest niedostępny, skonfiguruj własną zapasową kaskadę korzystającą z innych modeli.

Konfiguracja własnej zapasowej kaskady

Własna zapasowa kaskada działa tak samo, gdy głównym modelem jest własny LLM, jak w przypadku każdego innego modelu. Ustaw preferencję zapasowego LLM agenta na override i podaj tablicę order z modelami hostowanymi przez ElevenLabs, do których system ma przechodzić kolejno. Dokładną strukturę znajdziesz w polu backup_llm_config endpointów Tworzenie agenta i Aktualizacja agenta.

Możesz to także skonfigurować w panelu ElevenLabs w sekcji Konfiguracja zapasowego LLM, wybierając Własna i ustawiając modele awaryjne w kolejności. Dostępne opcje znajdziesz w Modelach.

Kaskada stosuje te same opisane wyżej zasady ponawiania prób i limitów czasu: każdy model w kolejności jest próbowany po kolei, a system wykonuje co najmniej 3 próby w całej sekwencji (model główny plus zapasowe), zanim uzna żądanie za nieudane. Ustaw cascade_timeout_seconds (2–15 sekund, domyślnie 4), aby określić, jak długo system czeka na pojedynczy model przed przejściem do następnego.

Własny LLM może być używany tylko jako model główny — nie można go umieścić w zapasowym order. Pozycje zapasowe muszą być modelami hostowanymi przez ElevenLabs.

Gdy głównym modelem jest własny LLM, a backup_llm_config ma wartość default lub disabled, system nie przechodzi do modeli hostowanych przez ElevenLabs — długotrwała awaria własnego LLM kończy rozmowę bez rozwiązania awaryjnego. Użyj override, aby włączyć rozwiązanie awaryjne. Ustaw disabled tylko wtedy, gdy celowo nie chcesz rozwiązania awaryjnego (zdecydowanie odradzane w środowisku produkcyjnym).

W agencie korzystającym z modelu Realtime system przechodzi do zapasowego LLM, jeśli model Realtime nie odpowie na czas. Model Realtime określa, jak długo agent czeka.

Korzyści

  • Większa niezawodność: Ogranicza skutki tymczasowych problemów z konkretnym dostawcą LLM.
  • Wyższa dostępność: Zwiększa szansę na pomyślne wygenerowanie odpowiedzi nawet podczas częściowych awarii LLM.
  • Płynne działanie: Mechanizm awaryjny jest automatyczny i niewidoczny dla użytkownika końcowego.

Konfiguracja

Kaskadowanie LLM działa automatycznie w tle. Domyślnie wystarczy wybrać Preferowany LLM w ustawieniach agenta, a system zajmie się resztą.

Aby dostosować działanie rozwiązania awaryjnego — także gdy głównym modelem jest własny LLM — ustaw Konfigurację zapasowego LLM agenta na Domyślna, Własna lub Wyłączona (zobacz Własne LLM powyżej).