"Nasz bot jest oparty na GPT-4" — popularne hasło, które nie zawsze jest zaletą
W 2024–2026 roku niemal każde nowe narzędzie AI w Polsce reklamuje się użyciem GPT-4 lub innego dużego modelu językowego (LLM). To naturalne: GPT-4 robi imponujące wrażenie w demonstracjach, a jego nazwa jest rozpoznawalna.
Problem pojawia się, gdy takie narzędzie trafia do środowiska produkcyjnego przychodni medycznej. Wtedy okazuje się, że GPT-4 nie jest ani jedyną, ani zawsze najlepszą architekturą dla voicebotów medycznych. Istnieją scenariusze, gdzie przewyższa dedykowane silniki NLP — i takie, gdzie je dramatycznie zawodzi.
Ten artykuł porównuje obie architektury rzetelnie, na podstawie rzeczywistych właściwości technicznych.
Czym różnią się te dwie architektury?
Duże modele językowe (LLM: GPT-4, GPT-4o, Claude, Llama)
LLM to modele trenowane na ogromnych zbiorach tekstu, zdolne do rozumienia i generowania języka naturalnego w bardzo szerokim zakresie tematów. W kontekście voicebota ich rola to zazwyczaj warstwa rozumienia i generowania odpowiedzi — nie cały pipeline głosowy.
Typowy pipeline głosowy z LLM: `` Mowa pacjenta → ASR (rozpoznanie mowy) → tekst → LLM (rozumienie + odpowiedź) → TTS (synteza mowy) → odpowiedź głosowa `
Dedykowane silniki NLP/NLU
Dedykowane silniki NLP (Natural Language Processing) i NLU (Natural Language Understanding) to modele trenowane na ograniczonym, precyzyjnie zdefiniowanym zbiorze intencji i encji — np. wyłącznie do obsługi rejestracji medycznej w języku polskim.
Typowy pipeline: ` Mowa pacjenta → ASR → tekst → NLU (klasyfikacja intencji + ekstrakcja encji) → logika biznesowa → TTS → odpowiedź ``
Kluczowa różnica: LLM generuje odpowiedź, dedykowany NLU klasyfikuje wypowiedź do jednej z zdefiniowanych kategorii i uruchamia gotowy scenariusz działania.
Parametr 1: Latencja — kluczowa dla naturalnej rozmowy głosowej
W rozmowie telefonicznej naturalny czas odpowiedzi to 200–400 milisekund od zakończenia wypowiedzi rozmówcy. Dłuższe przerwy są odczuwalne jako "zawieszenie" i obniżają jakość doświadczenia.
GPT-4 (API OpenAI, stan na 2026):
- Czas generowania odpowiedzi (API): typowo 1,5–4 sekund dla pełnej odpowiedzi tekstowej
- GPT-4o (wersja szybsza, multimodalna): 0,8–2 sekundy — wyraźna poprawa, ale nadal wyżej niż optimum dla głosu
- Latencja wzrasta przy długich kontekstach rozmowy i przy obciążeniu serwerów OpenAI
- Klasyfikacja intencji i ekstrakcja encji: typowo 50–300 milisekund
- Całkowity pipeline ASR+NLU+TTS: 300–800 milisekund — mieści się w naturalnym rytmie rozmowy
Zastrzeżenie: Latencja zależy silnie od infrastruktury, obciążenia serwerów i długości odpowiedzi. Podane wartości to typowe zakresy, nie gwarantowane parametry — zawsze pytaj dostawcę o SLA latencji w środowisku produkcyjnym.
Parametr 2: Hallucynacje — krytyczne ryzyko w kontekście medycznym
LLM mają udokumentowaną właściwość generowania "hallucynacji" — przekonujących, ale nieprawdziwych odpowiedzi. W kontekście medycznym to poważne ryzyko:
- Bot może podać błędną informację o godzinach pracy konkretnego lekarza
- Bot może "wymyślić" zabieg, którego klinika nie oferuje
- Bot może błędnie potwierdzić termin, który nie istnieje w kalendarzu
GPT-4 z RAG (Retrieval-Augmented Generation) — architektura, w której model przed wygenerowaniem odpowiedzi pobiera aktualne dane z bazy (np. kalendarza HIS) — znacząco redukuje ryzyko hallucynacji, ale go nie eliminuje. RAG wymaga dobrze zaprojektowanej warstwy pobierania danych i nadal może generować błędne syntezy.
Dedykowane NLU z logiką deterministyczną — nie generuje odpowiedzi, lecz wykonuje zdefiniowane akcje (sprawdź dostępność w HIS → zwróć listę slotów → potwierdź wybór). Zero ryzyka "wynalezienia" odpowiedzi — system nie może odpowiedzieć czegoś, czego nie zaprogramowano.
Wniosek: W krytycznych ścieżkach (rezerwacja, potwierdzenie terminu, instrukcje przedzabiegowe) — deterministyczna logika dedykowanego NLU jest bezpieczniejsza niż generatywny LLM. GPT-4 z RAG może być użyty do bardziej otwartych dialogów (FAQ, odpowiedzi na pytania ogólne), gdzie ryzyko hallucynacji jest niższe.
Parametr 3: RODO i transfer danych do serwerów OpenAI
To jeden z najważniejszych aspektów prawnych przy wyborze architektury.
GPT-4 przez API OpenAI: OpenAI Inc. ma siedzibę w USA. Wysyłanie danych pacjentów (imię, termin wizyty, informacje o zabiegu) do API OpenAI oznacza transfer danych do państwa trzeciego w rozumieniu RODO.
Jest to dozwolone, ale wymaga:
- Zawarcia Standardowych Klauzul Umownych (SCC) z OpenAI
- Oceny ryzyka transferu (TIA — Transfer Impact Assessment) zgodnie z wytycznymi EROD
- Poinformowania pacjentów o transferze do USA w polityce prywatności
Modele LLM open-source (np. Llama, Mistral) hostowane na serwerach w UE: Eliminują problem transferu do USA — dane przetwarzane są lokalnie. Wymagają jednak własnej infrastruktury obliczeniowej i utrzymania modelu.
Dedykowane silniki NLU na infrastrukturze UE: Dane nie opuszczają EOG — najprostsza ścieżka compliance dla placówek medycznych.
Parametr 4: Jakość rozpoznawania polskiego języka medycznego
Polski jest językiem fleksyjnym z rozbudowaną odmianą — co stanowi wyzwanie dla modeli ASR (rozpoznawanie mowy) i NLU.
GPT-4 w języku polskim: Jakość rozumienia polskiego przez GPT-4 jest wysoka w ogólnym kontekście. Jednak specjalistyczna terminologia medyczna (nazwy leków, procedur, nazwy oddziałów szpitalnych) może być rozpoznawana mniej precyzyjnie — szczególnie gdy pacjent wymawia je niewyraźnie lub z błędem.
Dedykowane modele ASR trenowane na polskim języku medycznym: Modele trenowane na danych z polskich przychodni (ze specyficzną akustyką połączeń telefonicznych, szumem tła) osiągają wyższą precyzję rozpoznawania dla domeny medycznej. Przykłady technologii: Whisper (OpenAI, open-source) jako ASR + dedykowany NLU, Speechlab PAN (Polská Akademia Nauk), komercyjne modele polskojęzyczne.
Architektura hybrydowa — najlepsze z obu światów
W praktyce najlepsze voiceboty medyczne nie wybierają między LLM a dedykowanym NLU — łączą oba podejścia:
| Ścieżka dialogu | Technologia | Uzasadnienie |
|---|---|---|
| Rejestracja, potwierdzenie terminu | Dedykowane NLU + deterministyczna logika | Zero hallucynacji, niska latencja |
| FAQ (godziny, cennik, dojazd) | LLM z RAG z bazy wiedzy kliniki | Elastyczność, naturalne odpowiedzi |
| Triage wstępny (pytania o objawy) | LLM z ograniczonym kontekstem + eskalacja do lekarza | Rozumienie niestandardowych opisów objawów |
| Rozpoznawanie mowy (ASR) | Whisper lub dedykowany model PL | Najlepsza precyzja dla polskiego |
Porównanie zbiorcze
| Parametr | GPT-4 / LLM | Dedykowany NLU | Hybrydowy (VoiceLink) |
|---|---|---|---|
| Latencja głosowa | 0,8–4 sek. | 0,3–0,8 sek. | 0,3–0,8 sek. |
| Ryzyko hallucynacji | Średnie–wysokie | Brak (deterministyczny) | Niskie (NLU dla krytycznych ścieżek) |
| RODO (dane w UE) | Wymaga SCC (API OpenAI) | Tak (przy UE-hostingu) | Tak |
| Elastyczność dialogu | Bardzo wysoka | Ograniczona | Wysoka |
| Koszt per rozmowa | Zmienny (tokeny) | Stały (abonament) | Stały |
| Czas wdrożenia | Krótszy (prompt engineering) | Dłuższy (trenowanie) | Średni |
| Aktualizacja bazy wiedzy | Łatwa (RAG) | Wymaga rekonfiguracji | Łatwa |
FAQ — Pytania techniczne dyrektorów IT placówek medycznych
Czy OpenAI oferuje wersję GPT-4 hostowaną w UE, która rozwiązuje problem RODO? Tak, częściowo. Microsoft Azure OpenAI Service oferuje hosting modeli GPT-4 na serwerach w Europie (regiony: West Europe, North Europe). Przy wyborze tej opcji transfer danych do USA nie następuje, co upraszcza compliance RODO. Wymaga jednak zawarcia umowy z Microsoft Azure jako podmiotem przetwarzającym.
Jak ocenić, czy konkretny dostawca voicebota medycznego stosuje architekturę bezpieczną dla danych pacjentów? Pytania do dostawcy: (1) Gdzie fizycznie przetwarzane są dane głosowe? (2) Czy dostawca korzysta z zewnętrznych API LLM (OpenAI, Anthropic, Google) czy własnej infrastruktury? (3) Czy możliwe jest przetwarzanie on-premise lub w prywatnej chmurze klienta? (4) Jakie dane są wysyłane do zewnętrznych modeli, a jakie przetwarzane lokalnie?
Czy voicebot oparty wyłącznie na GPT-4 bez dedykowanego NLU nadaje się do produkcyjnego wdrożenia w przychodni? Przy aktualnym stanie technologii (2026) — ostrożnie. GPT-4o z niską latencją i dobrze zaprojektowanym RAG jest technicznie możliwy do wdrożenia. Główne ryzyka to: niezerowe ryzyko hallucynacji w krytycznych ścieżkach, zmienne koszty per rozmowa przy wzroście wolumenu, zależność od dostępności API zewnętrznego dostawcy. Dla wdrożeń produkcyjnych rekomendujemy architekturę hybrydową z deterministyczną logiką dla ścieżek krytycznych.
Podsumowanie: Technologia powinna służyć pacjentowi, nie imponować w prezentacji
Wybór architektury voicebota medycznego to decyzja inżynierska z konsekwencjami prawnymi i klinicznymi. Nie istnieje "najlepsza" technologia w oderwaniu od kontekstu — istnieje technologia najlepiej dopasowana do konkretnych wymagań: latencji, bezpieczeństwa, elastyczności i skali.
VoiceLink stosuje architekturę hybrydową, w której każda ścieżka dialogu korzysta z technologii optymalnej dla jej wymagań — a dane pacjentów nigdy nie opuszczają infrastruktury UE.
Zapytaj o specyfikację techniczną VoiceLink → Dostarczymy pełną dokumentację architektury, opis przepływu danych i certyfikaty bezpieczeństwa — do oceny przez Twój dział IT lub zewnętrznego audytora.
