RxOps raz ako uzavretý ekosystém?

Celý RxOps bol pôvodne zamýšľaný len ako pracovný priestor na prípravu promptu. Keď sme sa však s manželkou, farmaceutkou, nahlas zamýšľali nad tým, aké sú výhody a nevýhody tohto prístupu, dospeli sme k tomu, že to nie je také jednoduché a hlavne v dlhodobom horizonte, možno bude aj dobré a bezpečnejšie ísť touto cestou. Nesie to so sebou viacero výhod, ktoré by som tu postupne rád rozobral. Potom by som sa rád zahral na "diablovho advokáta" a skúsil rozobrať nevýhody.

Výhody uzavretého ekosystému

Bezpečnosť a kvalitu nástrojov možno zaručiť priamočiarejšie a lepšie komunikovať

Ak teraz používateľ skončí na treťom kroku, má v rukách pripravený prompt, ktorý pozostáva z:

• špeciálne pripravenej šablóny, ktorá zahŕňa opis úlohy, usmernenia týkajúce sa formátu odpovede, štruktúry finálneho výstupu, medzikroku a pod.,
• dát, ktoré zadal profesionálny používateľ.

Problém však je, že nevieme, čo sa potom s promptom udeje. Vieme odporučiť nejaké postupy, školiť ľudí a pripraviť dobrú dokumentáciu. Nikdy však nezaručíme, čo sa s ním stane: do akého nástroja ho používateľ vloží, aký model použije alebo akú úroveň reasoningu nastaví.

Každé webové rozhranie ma navyše svoje špecifiká a systémové inštrukcie, ktoré nemáme šancu poznať. Nehovoriac o tom, že každý mesiac prichádzajú nové a nové modely. Toto je opak laboratórnych podmienok - ktoré by sme ako prevádzkovatelia medicínskeho IT toolu chceli mať aspon ako tak nastavené a vedeli kontrolovať aspoň tie najdôležitejšie faktory, ktoré ovplyvnia výstup.

Nekontrolujeme teda hlavnú hodnotu RxOps – finálny výstup nástroja – a nevieme ju v dostatočnej miere zaručiť.

Ak sa uzatvoríme a celý chat bude prebiehať u nás, môžeme si vybrať zopár modelov a následne dať používateľovi na výber z nami predvybraného poolu. Môžeme ovládať, aké AI nástroje agent použije (web search, code interpreter a pod.). Môžeme ovládať úroveň reasoningu, a to všetko navyše na úrovni každého nástroja. Takýto setup nám umožňuje pripraviť kvalitné testovacie scenáre ušité na mieru našej situácii, pomocou ktorých adekvátne otestujeme, aký výstup AI vráti. Budeme totiž mať všetko pod kontrolou.

Vycibrením testovania a metrík, ktoré z neho vyplynú, môžeme následne čierne na bielom vidieť, čo funguje a čo nefunguje. Produkt tak môžeme ponúknuť medicínskej verejnosti, ktorej prvá otázka bude smerovať k bezpečnosti: „Ako vieme, že AI nehalucinuje alebo neklame?“

Štruktúra medzikroku (review) a finálneho outputu

Hlavný medzikrok momentálne vyzerá približne takto:

• nejaká krátka analýza a predovšetkým text podobný tomuto: „Hmotnosť: __ kg; alergia na penicilíny/cefalosporíny: __; trvanie užívania lieku MEDOCLAV: 7 dní; UNIFLOX do nosa výslovne ordinoval lekár: __; presné dávkovanie lieku Mometasone: __; Sinupret: 15 kvapiek 3× denne; ProbioMaxík: Dr.Max, 1 tbl. denne. Schvaľujem výsledný návrh so zapracovaním týchto údajov.“

Očakávame pritom, že si používateľ prompt skopíruje a prepíše prázdne polia. Tento krok by sme u nás v aplikácii vedeli spraviť pekne, interaktívne a prakticky – napríklad ako dynamicky generovaný formulár, ktorý používateľ rýchlo prejde tabulátorom, vyplní a spustí generovanie finálnej analýzy.

Finálny výstup môže tiež vyzerať inak – môžeme napríklad priamo po jeho vygenerovaní otvoriť PDF.

Posielanie súborov priamo z RxOps

Môžeme priamo nahrať fotografie na spracovanie, napríklad fotografie balení liekov, lekárske správy, z ktorých boli vopred odstránené identifikačné údaje, a pod. Toto je zvlášť výhoda, ktorá je riešením na momentálne dosť výrazný problem RxOps - a to je to pomalé zadávanie liekov a vypisovanie ich dávkovania. Zaviedli sme už Import/Export, no to skôr pomáha testingu, ako reálnemu užívateľovi. Ak by vedel nahrať jednoducho fotku liekov - krabičiek, to by bola super bočná pomoc.

Nevýhody uzavretého ekosystému

Nastavenie billingu a jeho zložitosť

Keby sme RxOps nechali len ako manažmentový nástroj na skladanie vstupov, billing by bol jednoduchší, keďže celý processing a dáta o používaní by zostali u nás. Ak však chceme používať OpenAI API, vstupujú do toho výdavky na používanie modelov. Budeme musieť dobre premyslieť a prepočítať náklady, aby sme neprerobili a zároveň služba nebola príliš drahá.

Čiže jednoducho - stúpnu výrazne výdavky.

Testing bude dobrý, ale drahý

Od začiatku musíme podľa mňa používať čo najlepší model, respektíve čo najvyššej kvality. Čiže aj testovanie bude niečo stáť, no tieto investície by sa nám potom vrátili v podobe dobrých dôkazov, ktoré môžeme mať po testovaní na stole a argumentovať nimi pri otázkach o bezpečnosti a zabezpečení kvality.

Ďalšie výdavky.

Náročnosť developmentu

Toto som už spomínal kdesi na blogu, no v momente, keď sa napájame na API tretej strany, je to kopa práce, ktorú treba spraviť na aplikácii. Zároveň si to vyžaduje odhodlanie udržiavať aplikáciu aj pripojenie k API tretej strany zdravé a funkčné. Toto bude výzva.

Ďalšie výdavky, hlavne na čas developmentu.

Záver

Ukončil by som to asi tým, čo je po prečítaní predchádzajúceho textu jasné každému - ak chceme niečo viac a lepšie bude to niečo stáť. Otázka je kedy nastane možno v budúcnosti ten spravný moment sa vydať po tejto ceste.