Cicha odporność automatyzacji: Obsługa błędów providera LLM i interaktywne karty decyzji w Telegramie

W systemach opartych o duże modele językowe (LLM) najsłabszym ogniwem są często chwilowe czkawki po stronie zewnętrznych dostawców API. Jeśli nocne zadanie generujące raporty lub lekcje upadnie z powodu drobnego błędu formatowania odpowiedzi, brak mechanizmu automatycznego wznowienia oznacza utratę owoców całego dnia pracy.

Problem: Kruche zadania nocne i toporne zarządzanie z poziomu czatu

W połowie września zderzyłem się z dwoma konkretnymi ograniczeniami systemu:

• Pojedynczy błąd API zabijał całe zadanie nocne: Podczas planowego nocnego przebiegu dostawca modelu zwrócił błąd „incomplete or malformed tool call”. Ponieważ skrypt wywołujący nie miał mechanizmu powtórzeń (retry), cały proces padł, a plik pamięci z wynikami nie został zapisany.
• Błędna klasyfikacja awarii: Klasyfikator błędów w bramce potraktował ten błąd jako nienaprawialny błąd krytyczny zamiast błędu przejściowego, przez co system poddał się bez próby ponowienia zapytania.
• Niewygodna administracja na telefonie: Zarządzanie systemem agentowym wymagało wpisywania ręcznych poleceń tekstowych z pamięci na Telegramie, co podczas obsługi z telefonu było wolne i podatne na literówki.

Co zrobiłem: Warstwa odporności i interaktywne karty decyzyjne

Zamiast polegać na idealnej stabilności zewnętrznych API, przygotowałem system na to, że błędy będą się zdarzać regularnie.

1. Automatyczny mechanizm ponowień (Retry Loop)

Do skryptów harmonogramu dodałem mechanizm ponawiania z konfigurowalnym opóźnieniem:

• Każde zadanie wykonuje do 2 automatycznych prób ponowienia z 10-sekundowym odstępem.
• Przed zapisem danych wykonywana jest weryfikacja składni i integralności wygenerowanego pliku.
• Wynik poprzedniego poprawnego stanu jest automatycznie archiwizowany ze znacznikiem czasu, co uniemożliwia nadpisanie dobrych danych pustym plikiem w razie awarii.

2. Odporny klasyfikator błędów providera

Przeanalizowałem logi i poprawiłem wyrażenia regularne klasyfikujące odpowiedzi z API modeli:

• Błędy typu „malformed tool call” oraz nagłe przerwania strumienia zostały przekierowane do klasy błędów przejściowych (retryable timeout/transient), co natychmiast wyzwala automatyczną drugą próbę z poziomu biblioteki klienta.
• Usunąłem sztywne reguły tekstowe, które przypadkowe pojawienie się słowa „token” w treści argumentu narzędzia potrafiły błędnie zakwalifikować jako błąd autoryzacji (401).

3. Interaktywne karty decyzji (CTA Buttons) na Telegramie

Wdrożyłem protokół kart decyzyjnych w bocie administracyjnym Telegrama:

// telegram/decision_cards.js - obsługa przycisków akceptacji
export function renderDecisionCard(title, description, actionId) {
  return {
    text: `📋 <b>Decyzja operacyjna:</b> ${title}\n\n${description}`,
    parse_mode: 'HTML',
    reply_markup: {
      inline_keyboard: [[
        { text: '✅ Zatwierdź', callback_data: `approve:${actionId}` },
        { text: '❌ Odrzuć', callback_data: `reject:${actionId}` }
      ]]
    }
  };
}

Gdy agent proponuje wdrożenie zmiany, czyszczenie bazy lub archiwizację danych, nie oczekuje wpisania komendy tekstowej. Na czacie pojawia się czytelna karta z dwoma przyciskami: zatwierdź lub odrzuć. Jedno tapnięcie w telefonie wykonuje akcję deterministycznie.

Dlaczego to ważne (Use Case)

• Cicha samonaprawa bez budzenia człowieka: Przejściowe problemy z siecią czy czkawki po stronie providera LLM są rozwiązywane w tle. Użytkownik rano widzi gotowy wynik, a nie powiadomienie o błędzie.
• Bezpieczna administracja w biegu: Przyciski CTA eliminują ryzyko pomyłki w składni poleceń, co pozwala na bezpieczne zarządzanie flotą agentów prosto z telefonu, np. podczas podróży.
• Spójność bazy wiedzy: Zabezpieczenie plików pamięci przed nadpisaniem w razie błędu gwarantuje, że historia konwersacji i postępy w nauce nigdy nie znikną w wyniku nieudanej operacji I/O.

Czego się nauczyłem

1. API modeli językowych nie są deterministyczne pod kątem transportu: Drobny błąd w formacie JSON zwracanym przez model musi być traktowany tak samo jak timeout sieciowy - automatyczny retry rozwiązuje 90% takich incydentów.
2. Klawiatura telefonu nie nadaje się do wpisywania poleceń: Interfejs konwersacyjny zyskuje na ergonomii, gdy powtarzalne decyzje operacyjne zamienia się w jedno-klikowe przyciski.
3. Rollout poprawek musi być weryfikowany: Po zaktualizowaniu klasyfikatora błędów i restarcie bramki skrypt weryfikujący automatycznie odpytał środowisko testowe, upewniając się, że poprawka weszła w życie przed rozpoczęciem właściwych zadań nocnych.