Niezawodność narzędzi chatbota: timeouts, retry, idempotency i audyt

Niezawodność jako kontrakt

Integracje narzędzi (API, bazy, systemy ticketowe, CRM) są najczęstszym źródłem degradacji jakości chatbota. Dobra praktyka to traktowanie niezawodności jako kontraktu: z jawnie opisanymi limitami, polityką retry/timeout, idempotency oraz audytem decyzji wykonawczych.

Klasy awarii, które trzeba projektować „z góry”

• Timeout (zależność wolna lub przeciążona) – wymaga budżetu czasu na krok.
• Transient errors (5xx, sieć, rate limit) – wymagają retry z backoffem i jitterem.
• Permanent errors (4xx, walidacja) – nie retry; naprawa danych wejściowych.
• Duplikacja (powtórne wywołanie) – wymaga idempotency key i deduplikacji po stronie narzędzia.
• Niejawny stan (kolejki, procesy) – wymaga korelacji (trace/correlation id).

Minimalny standard timeout + retry

tool_policy:
  timeout_ms: 3500
  retries:
    max: 2
    backoff: "exponential"
    jitter: true
    retry_on: ["timeout", "429", "5xx"]
  no_retry_on: ["schema_error", "4xx_validation"]
  circuit_breaker:
    enabled: true
    open_after: 8
    window_s: 60

Idempotency i dokładność skutków

W środowisku LLM powtórzenia są normalne (retry, ponowne planowanie, użytkownik „dopytał”). Dlatego narzędzia powinny wspierać idempotency key (najlepiej deterministyczny: trace + step), a odpowiedzi narzędzi powinny zawierać identyfikator wykonania i stan (created/updated/no-op).

Audyt i obserwowalność

• Trace ID wspólny dla rozmowy i narzędzi (end-to-end).
• Step log: wejście → walidacja → wykonanie → wynik → post-processing.
• Redakcja danych (PII, sekrety) w logach; przechowywanie zgodne z polityką retencji.
• Metryki: latency p95/p99, success rate, retry rate, duplicate rate, fallback rate.

Checklista wdrożeniowa

• Każde narzędzie ma: schema, limity, timeout, retry, idempotency, log audytu.
• Każda odpowiedź narzędzia jest „samopopisowa” (status, id, timestamp, wersja).
• Każda degradacja ma plan B: fallback, „manual review”, kolejka, komunikat do użytkownika.