Triage-and-Voice: poprawka halucynacji LLM

Architektoniczny wzorzec Triage-and-Voice do eliminacji halucynacji LLM

LLM w chatbotcie analizuje korespondencję i zamiast rzeczywistego numeru infolinii wymyśla dziecięcy telefon zaufania. Instrukcja "nie wymyślaj kontaktów" jest ignorowana. Przyczyna — konflikt zadań w jednym przebiegu: precyzyjna analiza i empatyczna odpowiedź konkurują o tokeny, prowadząc do halucynacji w krytycznych danych.

Problem architektury jednoprzebiegowej

W standardowym schemacie produktu LLM dane wejściowe użytkownika trafiają bezpośrednio do modelu, który generuje ostateczną odpowiedź. Analiza wymaga strukturalnego wyjścia JSON z dokładnymi faktami: uczestnicy, ryzyka, cele. Formułowanie odpowiedzi to zadanie kreatywne z głosem i tonem.

Połączenie w jeden prompt prowadzi do kompromisów:

• Model poświęca precyzję na rzecz stylu.
• Halucynacje maskują się pod przekonujący tekst.
• Niemożliwe jest programowe odróżnienie faktu od wymysłu.

Zwiększenie mocy modelu (modele reasoningowe, więcej tokenów) zmniejsza częstotliwość błędów, ale nie eliminuje problemu. W trudnych przypadkach z podtekstem nawet topowe modele mylą motywy i domyślają się szczegółów. Ryzyko dotyczy zaufanych danych: ceny, adresy, dawkowanie, kontakty służb.

Wzorzec Triage-and-Voice

Podziel przetwarzanie na dwa przebiegi LLM z backendową bramą między nimi.

Przebieg 1: Triage (triaż). Strukturalna analiza bez stylu. Model wyodrębnia sygnał w JSON:

{
  "nastrój": "niepokój",
  "czy_kryzys": false,
  "typ_kryzysu": null,
  "uczestnicy": [...],
  "motywy": [...]
}

Przykład kryzysowy:

{
  "nastrój": "czerwona_flaga",
  "czy_kryzys": true,
  "typ_kryzysu": "przemoc"
}

Backend gate. Deterministyczny kod sprawdza flagi:

if (triage.CzyKryzys) {
    var kontakty = await db.PobierzZweryfikowaneKontaktyKryzysowe(triage.TypKryzysu);
    prompt = szablonPromptuKryzysowego.ZKontaktami(kontakty);
}

Podstawiane są zweryfikowane dane z bazy danych. Routing według reguł: kryzys → specjalny prompt.

Przebieg 2: Voice. Model otrzymuje wzbogacone dane wejściowe i generuje odpowiedź w pożądanym tonie. Nie analizuje, nie wymyśla faktów.

Testowanie na DeepSeek V3.2 (dziesiątki przypadków kryzysowych): zero halucynacji kontaktów.

Zalety podziału

• Podział odpowiedzialności. Triage skupia się na strukturze (tokeny na fakty). Voice — na stylu (tokeny na empatię). Jakość w obu wymiarach rośnie (sprawdzone na 40 przypadkach eval).

• Buforowanie. Analiza raz. Przy zmianie głosu (perspektywy w bocie Telegram) uruchamiany jest tylko Voice. Metryki: pierwsza odpowiedź 30–45 s (vs 50–90 s), kolejne 15–20 s.

• Bezpieczeństwo. Kontrola w kodzie, a nie w prompcie. Model ustawia flagę ("kiedy"), backend decyduje ("co"). Testowalne, przewidywalne.

Scenariusze zastosowania

Wzorzec aktualny dla produktów LLM z:

• Analizą danych wejściowych + generacją wyjścia.
• Zaufanymi danymi (finanse, linki prawne, medycyna).
• Przypadkami brzegowymi (kryzysy, wyjątki).
• Wieloma perspektywami bez ponownej analizy.
• Potrzebnym punktem kontrolnym między analizą a wyjściem.

Zasada: model analizuje → kod decyduje → model formułuje.

Sygnał do refaktoryzacji: prompt zawiera "NIE wymyślaj [danych]".

Co ważne

• Przesunięcie architektoniczne: od jednego wywołania do dwóch z bramą, eliminuje konflikt zadań.
• Metryki wydajności: analiza buforowana, Voice przyspiesza 2–3 razy.
• Bezpieczeństwo: deterministyczny backend podstawia fakty, model nie dotyka bazy danych.
• Skalowalność: zastosowanie w chatbotach, analityce, produktach z przypadkami brzegowymi.
• Sprawdzone: 40 eval + dziesiątki przebiegów kryzysowych bez halucynacji.

Ryzyka naiwnej architektury

Jedno wywołanie = operacja atomowa bez walidacji. Brak:

• Sprawdzenia decyzji modelu przed użytkownikiem.
• Bufora analizy.
• Routingu przypadków brzegowych.
• Podstawienia zweryfikowanych danych.

Zaufanie probabilistycznej generacji w krytycznych miejscach — podatność. Triage-and-Voice dodaje kontrolę: +1 wywołanie, +1 brama = sprawdzalny pipeline.

— Editorial Team