Shen.ai: bezpieczna edukacja pacjentów

5 min czytaniaSimon BudziakAutor: Simon Budziak

Na tej stronie8 sections

Shen.ai zamienia kamery smartfonów w monitory zdrowia, które na podstawie skanu twarzy mierzą ponad 30 parametrów życiowych. Pacjenci potrzebowali pomocy w zrozumieniu, co oznaczają ich wyniki i jakie kroki podjąć dalej. Soba Labs zbudowało asystenta, który to zapewnia.

Asystent w takim kontekście nie może wypełniać luk wiarygodnie brzmiącą odpowiedzią. Musi wyjaśniać zatwierdzone informacje prostym językiem, oddzielać edukację od diagnozy i kierować niepewne lub kliniczne pytania do człowieka.

Problem

Asystent dla pacjentów musiał:

  • wyjaśniać wyniki skanu zdrowia prostym językiem;
  • odpowiadać na pytania uzupełniające w formie rozmowy;
  • pobierać treści edukacyjne z zatwierdzonej medycznej bazy wiedzy;
  • proponować odpowiedni kolejny krok, na przykład informacje o samoopiece lub wizytę;
  • kierować pytania o niskim poziomie pewności oraz pytania kliniczne do klinicysty;
  • przechowywać wystarczająco dużo dowodów, by można było odtworzyć, co system powiedział i dlaczego.

Stawka zmieniła podejście inżynieryjne. Pewne siebie, lecz niepoparte źródłami wyjaśnienie nie jest drobną usterką doświadczenia użytkownika. Zespół potrzebował jawnych granic bezpieczeństwa i śladu dla każdej decyzji.

Na wczesnym etapie pojawiły się dwa ryzyka.

Niewidoczne halucynacje. Słabe wyszukiwanie mogło mimo to prowadzić do płynnej, pewnie brzmiącej odpowiedzi.

Niejasna eskalacja. Prompt nakazujący modelowi ostrożność nie określał, kiedy system musi się zatrzymać i poprosić o ocenę kliniczną.

System

Asystenta zbudowaliśmy jako maszynę stanów LangGraph. Stan przechowywał wyniki skanu, pobrany kontekst medyczny, wskaźnik pewności, status weryfikacji i historię rozmowy.

Kluczowa decyzja dotycząca routingu znajdowała się w kodzie, a nie w prompcie.

class PatientEducationState(MessagesState):
    test_results: dict
    confidence_score: float
    requires_review: bool
    thread_id: str

def should_route_to_human(state: PatientEducationState) -> str:
    if state["confidence_score"] < 0.7 or state["requires_review"]:
        return "human_review"
    return "education_module"

graph.add_conditional_edges("retrieve_kb", should_route_to_human)

Dzięki temu granica pozostała widoczna. Model generował treść w ramach dozwolonej ścieżki, ale nie decydował o tym, czy eskalację kliniczną można pominąć.

Co sprawiło, że system był wystarczająco bezpieczny do wdrożenia

Zatwierdzona wiedza z oceną pewności

Asystent korzystał z retrieval-augmented generation na wersjonowanej bazie wiedzy zawierającej wyjaśnienia kliniczne i materiały edukacyjne dla pacjentów. Wpisy zawierały informacje o źródle, a wyszukiwanie łączyło trafność semantyczną z jakością źródła.

Confidence gating uczyniło niepewność jawną. Wyniki o niskim poziomie pewności nie trafiały na standardową ścieżkę odpowiedzi. Uruchamiały bezpieczną odpowiedź i weryfikację przez klinicystę.

Baza wiedzy podlegała tej samej dyscyplinie co kod produkcyjny: historii wersji, śledzeniu zmian i możliwości wycofania. Dzięki temu można było ustalić, jakie materiały medyczne były dostępne dla asystenta podczas konkretnej rozmowy.

Jawne kierowanie do klinicysty

Niepewność stała się stanem systemu. Początkowy wzorzec routingu wykorzystywał łączny sygnał z jakości wyszukiwania, pewności modelu i określonych wyzwalaczy klinicznych.

Pytania o objawy, leki lub diagnozę trafiały na ścieżkę weryfikacji human-in-the-loop. Celem nie było odpowiadanie na każde pytanie. Chodziło o odpowiadanie na pytania edukacyjne na podstawie zatwierdzonych materiałów i bezpieczne zatrzymanie we wszystkich pozostałych przypadkach.

Po dostrojeniu progów zaobserwowany w produkcji wzorzec wyglądał następująco:

  • około 15% rozmów trafiało do weryfikacji przez człowieka, głównie przypadki brzegowe lub pytania niezwiązane z tematem;
  • według informacji zwrotnej od klinicystów około 80% tych eskalacji było zasadnych;
  • obniżenie początkowego progu z 0.8 do 0.7 zmniejszyło liczbę zbędnych weryfikacji o około 40%;
  • cotygodniowe próbkowanie audytowe wykazało bardzo niski odsetek niewłaściwych porad klinicznych.

Te liczby opisują okres strojenia i proces weryfikacji zastosowany w tym systemie. Nie stanowią ogólnego benchmarku dla asystentów w ochronie zdrowia.

Trace wyjaśniający każdą odpowiedź

LangSmith rejestrował wywołania modelu, pobrane dokumenty, wskaźniki pewności, decyzje routingu i metadane przebiegu dla każdej rozmowy. Jego model obserwowalności utrzymywał kroki każdej operacji w jednym trace.

Ten trace pełnił dwie funkcje. Inżynierowie mogli zdiagnozować, dlaczego odpowiedź wyszła poza zamierzoną granicę. Weryfikujący mogli po fakcie odtworzyć wersję bazy wiedzy, wersję modelu i stan routingu stojące za odpowiedzią.

Checkpointing sesji w PostgreSQL pozwalał ponadto pacjentom opuścić rozmowę i do niej wrócić bez utraty stanu potrzebnego do kontroli bezpieczeństwa.

Błąd, który zmienił zasadę oparcia na źródłach

Podczas testów asystent pewnie wyjaśnił schorzenie, którego nie było w zatwierdzonej bazie wiedzy.

Trace pokazał, co się stało. Wyszukiwanie zwróciło słabe dopasowania, ale wygenerowana odpowiedź nie odzwierciedlała tej niepewności. Model wypełnił lukę informacjami ze swoich danych treningowych.

Poprawka przeniosła granicę z promptu do przepływu pracy:

  1. Wyniki wyszukiwania poniżej bezpiecznego progu pewności nie mogły trafić do standardowego węzła odpowiedzi.
  2. Asystent informował, że nie ma wystarczających informacji, aby odpowiedzieć bezpiecznie.
  3. Rozmowa trafiała do weryfikacji przez klinicystę.
  4. Zestaw pytań o znanych niewiadomych dołączono do zbioru ewaluacyjnego.

W tym systemie odpowiedź “nie wiem” była wymaganym wynikiem, a nie porażką modelu.

Luka audytowa

Wczesny audyt LLM observability pozwalał odzyskać końcową wiadomość, ale nie pełną podstawę, na której powstała. To nie wystarczało. Weryfikujący potrzebowali pobranych materiałów, wskaźnika pewności, wersji modelu, decyzji routingu i znacznika czasu.

Produkcyjny trace uzupełniono o stabilne identyfikatory sesji, wersje bazy wiedzy, wersje modelu, ustrukturyzowane eksporty i reguły redakcji danych monitoringowych. W efekcie powstał zapis, który wyjaśniał zarówno odpowiedź, jak i ścieżkę, która do niej dopuściła.

Rezultat

Shen.ai otrzymało asystenta edukacji pacjentów, który wyjaśnia wyniki skanu na podstawie zatwierdzonych materiałów i traktuje niepewność jako jawną ścieżkę. System oddziela edukację od diagnozy, przekazuje pytania kliniczne ludziom i rejestruje dowody stojące za każdą decyzją produkcyjną.

Główny wniosek nie polega na tym, by prosić model medyczny o ostrożność. Należy określić, na co może odpowiadać, uczynić warunki zatrzymania deterministycznymi i testować przypadki, w których prawidłową odpowiedzią jest przekazanie sprawy człowiekowi.

Słowami klienta

“Soba Labs built us a patient education agent that explains scan results from medical knowledge we approved. Anything uncertain routes to a clinician, and every answer leaves a record we can audit.”

Anna Harris, CRO, Shen.ai

Źródła techniczne

Ostatnia aktualizacja:

Porozmawiajmy o podobnym wdrożeniu