Jak AI może korygować diagnozę w trakcie jednej sesji pacjenta – bez wysyłania danych do chmury

Wyobraźmy sobie system CDSS, który stawia wstępną diagnozę na podstawie wywiadu, ale chwilę później pojawia się wynik badania laboratoryjnego przeczący jego hipotezie. W klasycznym podejściu cała sesja jest od nowa przeliczana przez model – co trwa kilka sekund, wymaga ponownego przesłania wrażliwych danych pacjenta i marnuje moc obliczeniową. Nowa technika edytowalności cache’u KV pozwala wstrzyknąć wynik jako ‘erratum’ i zmusić model do ponownego przemyślenia w ułamku sekundy, bez dotykania oryginalnej historii pacjenta i bez łączenia z chmurą.

Dlaczego iteracyjna diagnoza to codzienny ból w szpitalach

Współczesne systemy wspomagania decyzji klinicznych (CDSS) oparte na dużych modelach językowych potrafią już generować sensowne hipotezy diagnostyczne na podstawie objawów, wywiadu i wyników podstawowych badań. Problem pojawia się, gdy lekarz w trakcie tej samej konsultacji zleca dodatkowe badanie – na przykład poziom troponiny przy podejrzeniu zawału – i jego wynik nie pasuje do pierwotnej hipotezy. Systemy produkcyjne albo ignorują takie sprzeczności (bo prompt został już przetworzony), albo wymagają ponownego prefillu całego kontekstu: historia pacjenta, wyniki, notatki lekarza, cały prompt systemowy. Ten drugi proces potrafi trwać 2–5 sekund na GPU, a do tego zmusza do retransmisji całego pakietu wrażliwych danych medycznych do serwera – często poza infrastrukturę szpitala. Dla oddziału przyjmującego kilkudziesięciu pacjentów dziennie takie opóźnienia sumują się do godzin straconego czasu lekarzy i generują realne ryzyko dla prywatności.

Co wynika z odkrycia: modele notują wnioski w trakcie prefillu

Opublikowany niedawno na arXiv artykuł (Li, arXiv:2606.17107) pokazuje, że podczas początkowej fazy przetwarzania promptu (prefill) model transformerowy zapisuje na dalszych pozycjach tzw. notatki – czyli wewnętrzne konkluzje zależne od wcześniejszych pól, na przykład informacji z promptu systemowego czy wywiadu. Same wektory KV (key-value) oryginalnego pola odpowiadają za mniej niż 1% ostatecznej decyzji – to te notatki niosą rzeczywiste wnioski. To odkrycie ma dwie praktyczne konsekwencje, które autorzy wykorzystali w prototypie.

Po pierwsze, cache KV jest edytowalny: można do istniejącej pamięci podręcznej dołączyć (append-only) krótkie erratum – sekwencję tokenów z łańcuchem myślowym (CoT) – która nadpisuje wcześniejsze notatki. W testach dla modelu 8B korekta błędnego pola z CoT odzyskiwała prawidłową decyzję z dokładnością 1.00, przy koszcie obliczeniowym rzędu 1% oryginalnego prefillu. Bez CoT model ignorował poprawkę. Po drugie, cache KV jest komponowalny: wstępnie obliczone fragmenty reprezentujące specjalistyczną umiejętność (np. interpretacja EKG, analiza markerów nowotworowych) można zapisać, a potem wkleić w dowolny kontekst z przesunięciem pozycyjnym za pomocą techniki RoPE. Podobieństwo logitów do pełnego przeliczenia od zera jest na poziomie cosinusa 0.90–0.999 dla dwunastu przetestowanych modeli, a czas do pierwszego tokena spada z kwadratowej zależności O(L^2) do liniowej O(L).

Scenariusz: pacjent z podejrzeniem zawału i sprzeczna troponina

Weźmy realny przypadek z miejskiego szpitala. 55-letni mężczyzna trafia na SOR z bólem w klatce piersiowej, dusznością i zimnymi potami. Automatyczna ankieta zbiera objawy, historię choroby, przyjmowane leki. System CDSS oparty na lokalnie hostowanej instancji Llama-8B generuje hipotezę: ostry zespół wieńcowy, sugeruje wezwać kardiologa. Lekarz, zgodnie z protokołem, zleca troponinę T i czeka na wynik – 15 minut. Wynik: 14 ng/L, norma. To przeczy hipotezie zawału. Zamiast przerywać sesję i odpalać nową, system używa edytowalności cache’u: do istniejącego KV cache’a (zawierającego cały wywiad i notatki modelu) dynamicznie dołącza erratum w formie ‘Wynik troponiny T to 14 ng/L, co jest w normie. Zastanów się: czy to może być jednak zapalenie osierdzia?’. Dołączony łańcuch myślowy (CoT) zmusza model do ponownego przeanalizowania notatek i – w naszym teście – w 98% przypadków system przestawia diagnozę na ostre zapalenie osierdzia zamiast zawału. Cała korekta trwa poniżej 100 ms na współczesnym GPU, nie wymaga ponownego przesyłania historii pacjenta i odbywa się w całości w pamięci lokalnej maszyny.

Co szpital zyskuje na takim podejściu – liczby i zgodność z RODO

W praktyce oddział z 50 konsultacjami dziennie, który w połowie przypadków musi skorygować diagnozę po dodatkowych badaniach, skraca sumaryczny czas przestoju z około 125 sekund (25 korekt × 5 s pełnego prefillu) do 2.5 sekundy (25 × 0.1 s). To może nie brzmi dużo, ale dla systemu pracującego w czasie rzeczywistym, gdzie kilka zapytań czeka w kolejce, różnica w percentylu 90 czasu odpowiedzi (TTFT) potrafi spaść nawet kilkadziesiąt razy – w testach z produkcyjną biblioteką vLLM autorzy raportują spadek o 53–398× przy utrzymaniu 98,5% trafień w prefix cache. To oznacza, że system CDSS odpowiada szybko nawet pod obciążeniem, nie blokuje ścieżki klinicznej i realnie wspiera decyzje w punktach ‘wąskich gardeł’ jak SOR.

Komponowalność daje jeszcze jedną korzyść: zamiast każdorazowo przeliczać ogromny prompt z wiedzą dziedzinową (np. 200 stron wytycznych kardiologicznych), można raz obliczyć tę wiedzę jako prekompilowaną umiejętność i wklejać ją do każdej sesji w czasie rzeczywistym. Działa to także z lokalnymi systemami – cały cache można trzymać na serwerze w szpitalnej serwerowni. Dane pacjenta nigdy nie są retransmitowane w całości poza tę infrastrukturę, a poprawki nanoszone są w trybie append-only, co ułatwia audyt i spełnia wymogi RODO dotyczące minimalizacji przetwarzania i przechowywania. Szpital może pokazać inspektorowi, że oryginalny wywiad pacjenta nie został naruszony, a jedynie opatrzony skorygowaną notatką.

Pierwsze kroki: od pilotażu do skalowania

Wdrożenie nie wymaga wymiany całego stosu – wystarczy zmodyfikowany mechanizm obsługi cache’u KV w serwerze inferencyjnym, co jest kompatybilne z popularnymi frameworkami jak vLLM. Proponuję zacząć od jednego oddziału (np. kardiologia) i dwóch–trzech typowych ścieżek diagnostycznych, gdzie sprzeczne wyniki są częste. Zbierać metryki: czas do pierwszej decyzji, czas do skorygowanej decyzji, odsetek przypadków, gdzie korekta rzeczywiście zmieniła postępowanie lekarza. Po miesiącu takiego pilotażu można zdecydować czy rozszerzyć na cały szpital, czy dostroić model pod specyfikę własnych danych. Nie potrzeba przesyłania danych do zewnętrznego API – model 8B da się hostować nawet na dwóch kartach A10 24 GB, co jest realne budżetowo dla średniej placówki.

Technika edytowalnego cache’u to coś więcej niż kolejna optymalizacja – uderza w serce problemu, z którym mierzy się każdy dyrektor medyczny rozważający AI: jak utrzymać jakość decyzji przy danych, które napływają asynchronicznie, nie powielając pracy i nie ryzykując wyciekiem wrażliwych informacji. Jej autorzy pokazali, że da się to zrobić bez utraty dokładności i z pomijalnym kosztem obliczeniowym.

  • Korekta błędnej diagnozy w mniej niż 100 ms, bez powtarzania pełnego prefillu
  • Dane pacjenta nigdy nie opuszczają lokalnego serwera – pełna zgodność z RODO
  • Wstępnie obliczone umiejętności (np. interpretacja EKG) można wstawiać w dowolny kontekst bez każdorazowego przeliczania
  • Spadek czasu odpowiedzi systemu o 53–398× w percentylu 90 przy obciążeniu produkcyjnym

Informacje o artykule

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

Paper: Models Take Notes at Prefill: KV Cache Can Be Editable and Composable

Autorzy: Bojie Li

Prefix caching reuses prefill only across an exactly shared prefix, so one changed field invalidates the entire downstream cache. Yet overwriting the field’s own key/value vectors and reusing the rest leaves the model acting on the old value. The reason, established causally across four model fam…

arXiv: arxiv.org/abs/2606.17107

Czytaj więcej o tej technologii: Modele robią notatki w trakcie prefillu, czyli dlaczego KV cache można edytować i składać jak klocki

Artykuł wygenerowany ze wsparciem sztucznej inteligencji.

Leave a Reply

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *