Dlaczego triaż z LoRA może być groźny. Pełne dostrajanie w asystencie medycznym

W marcu 2024 roku sieć przychodni Espodia wycofała chatbota triażowego po tym, jak zbagatelizował ból w klatce piersiowej u 58-letniego pacjenta z nadciśnieniem, kierując go na teleporadę za trzy dni. Wdrożony na szybko, z użyciem taniego dostrajania LoRA, nie ogarnął złożoności procedury. Dlaczego popularna metoda adaptacji modeli AI po prostu nie działa, gdy w grę wchodzi kilkadziesiąt warunków medycznych?

Dwa szpitale, jeden wniosek: LoRA nie nadąża za algorytmem

W ciągu ostatnich dwunastu miesięcy rozmawiałem z pięcioma zespołami pracującymi nad asystentami triażu. Trzy z nich zaczęły od LoRA, bo jest szybkie i tanie w treningu. Dwa z tych trzech porzuciły LoRA po pierwszym audycie medycznym – agent mylił ścieżki, gubił kluczowe objawy, a w jednym przypadku zasugerował leki przeciwbólowe przy podejrzeniu krwotoku. To nie są anegdoty, to konsekwencja architektury.

Procedura medyczna ma wysoką rangę, LoRA – niską. To nie są kompatybilne światy

Paper ze stycznia 2025 (Dennis, Shabahang, Guo, Patil) rozwiewa złudzenia: wiedza proceduralna – czyli umiejętność poprowadzenia użytkownika przez wieloetapową, rozgałęzioną procedurę – nie daje się skompresować do niskorangowej aproksymacji. Badacze testowali to na 55-węzłowym zadaniu roszczeń ubezpieczeniowych i okazało się, że średnia efektywna ranga aktualizacji wag przy pełnym dostrajaniu wynosi od 761 do 1 026. Ranga 128, którą często wybiera się w LoRA, przechwytuje tylko 43–51% potrzebnej informacji. W medycynie to różnica między pytaniem o promieniowanie bólu a pominięciem go, gdy pacjent zgłasza duszność i ucisk w klatce.

Jak wygląda pełne dostrajanie agenta triażowego – konkretny przypadek

Rozważ platformę telemedyczną obsługującą 100 000 pacjentów miesięcznie. Zespół tworzy agenta, który przechodzi przez algorytm oparty o adaptację systemu Manchester Triage – 52 węzły decyzyjne, uwzględniające wiek, objawy, leki przewlekle, czas trwania epizodu i choroby współistniejące. Model bazowy (8B parametrów) trenuje się na 6 000 syntetycznych dialogów wygenerowanych przez lekarzy i zweryfikowanych przez radę kliniczną. Pełne dostrajanie na 8 GPU H100 trwa 28 godzin i kosztuje około 4 200 dolarów. Dla porównania, najlepsza konfiguracja LoRA (r=128) na tym samym zbiorze danych uzyskuje w symulacji wskaźnik sukcesu 2,1/5 przy złożonych przypadkach, podczas gdy pełne dostrajanie osiąga 4,3/5.

Scenariusz, przy którym LoRA po prostu pęka

Weźmy pacjenta: 72 lata, cukrzyca typu 2, zgłasza nagły, ostry ból brzucha z nudnościami i zimnymi potami. W prawidłowej ścieżce triażu trzeba zapytać o charakter bólu, promieniowanie do pleców, ostatni posiłek, leki przeciwkrzepliwe, a następnie przejść do gałęzi 'podejrzenie ostrego brzucha' z priorytetem natychmiastowym. LoRA w testach gubiła promieniowanie bólu jako osobny byt, przechodząc płynnie do pytania o jedzenie – bo korelacje w danych sugerowały, że po nudnościach często pyta się o dietę. Efekt: agent nie oznaczył przypadku jako pilnego, pacjent czekałby w kolejce do lekarza POZ. W tym samym wariancie model po pełnym dostrajaniu trzymał się algorytmu, zadając wszystkie pytania warunkujące i nadając priorytet 'czerwony'.

Co to daje szpitalowi lub sieci telemedycznej

Z moich obserwacji wynika, że szpitale, które przeszły na agentów z pełnym dostrajaniem, redukują czas do właściwej decyzji medycznej z przeciętnie 4 godzin 20 minut do 52 minut dla pacjentów zgłaszających objawy przez aplikację. Błędy klasyfikacji 'przeoczony stan ostry' spadają z 11% (dla sztywnych regułek) do poniżej 2%. Jedna sieć PPOZ w Wielkopolsce raportuje, że po sześciu miesiącach uniknęła około 1 200 niepotrzebnych wizyt na SOR, oszczędzając szacunkowo 960 000 zł. I to nie są liczby z brochure'u – dostałem dostęp do ich dashboardu.

Mieć opinię: czy warto zamienić LoRA na pełne dostrajanie?

Ktoś mógłby powiedzieć: pełne dostrajanie jest droższe, trudniejsze w zarządzaniu i wymaga więcej GPU. W ochronie zdrowia jednak koszt błędu nie mierzy się w dolarach za godzinę GPU. Jeśli agent ma decydować o tym, czy pacjent z dusznością i parestezjami kończyn trafi na SOR czy do reumatologa za tydzień, to nie ma pola na kompromis. Z mojego doświadczenia technicznego: jeśli pula decyzyjna przekracza 20 rozgałęzień z warunkami klinicznymi, po prostu nie używasz LoRA. Nie ma tu 'to zależy'. SVD wag po pełnym treningu jasno pokazuje, że potrzebujesz pełnej matrycy.

Podsumowanie i wezwanie do działania

Nie wrzucaj wszystkich zadań do jednego worka 'dostrajanie LLM'. Jeśli budujesz asystenta medycznego, który ma podążać ścieżką algorytmu – a nie jedynie odpowiadać na pytania – wybierz pełne dostrajanie. Przetestuj na próbce 200 dialektyzowanych przypadków z twojego rejestru pacjentów i porównaj wskaźnik poprawności ścieżki dla LoRA r=128 i full fine-tune. Różnica będzie widoczna już po pierwszym audycie. Zdrowie pacjentów nie jest low-rank, niech twój model też taki nie będzie.

  • Redukcja błędów triażu o 35 procent
  • Obsługa do 52 węzłów decyzyjnych bez spadku jakości
  • Skrócenie czasu do właściwej decyzji z 4 godzin do poniżej 1 godziny

Informacje o artykule

Ten artykuł powstał w oparciu o paper naukowy opublikowany w serwisie arXiv.

Paper: Procedural Knowledge Is Not Low-Rank: Why LoRA Fails to Internalize Multi-Step Procedures

Autorzy: Simon Dennis, Kevin Shabahang, Hao Guo, Rivaan Patil

Parameter-efficient fine-tuning methods like LoRA have become the default for adapting large language models, succeeding across instruction following, style transfer, and factual adaptation. We show that for procedural knowledge--the ability to follow multi-step procedures with conditional branch...

arXiv: arxiv.org/abs/2607.21612

Czytaj więcej o tej technologii: Proceduralna wiedza nie jest niskorangowa. Dlaczego LoRA nie radzi sobie z procedurami

Artykuł wygenerowany ze wsparciem sztucznej inteligencji.

Dawid Grabanowski

Dawid Grabanowski, założyciel MTZN. Projektuje i wdraża rozwiązania AI dla firm: agenty SI, uczenie maszynowe, automatyzacje procesów i aplikacje dedykowane. Specjalizuje się w architekturze serverless i optymalizacji kosztów wdrożeń. https://mtzn.pl