Budowa AR3S.

Spotkanie z Bartkiem z WAIT (Wrocław AI Team) było jedną z pierwszych rozmów o tym, jak właściwie zabrać się za budowę startupu. Rozmawialiśmy o preakceleracji, inkubatorach, poszukiwaniu CTO i o tym, jak w praktyce funkcjonuje środowisko AI oraz startupów.

Ku mojemu zaskoczeniu okazało się, że we Wrocławiu działa całkiem prężna społeczność związana z AI — wcześniej właściwie nie miałem o niej pojęcia. To właśnie po tej rozmowie dostałem również kontakt do Kuby, do którego miałem się zgłosić po bardziej szczegółowe informacje dotyczące technicznej strony projektu i poszukiwania CTO.

Kontakt przekazany przez Bartka prowadzi do rozmowy z Kubą. Zyskuję kolejne praktyczne wskazówki jak podejść do kwestii znalezienia programisty, a także informacje o realiach ich pracy oraz o sposobach budowaniu produktu na bardzo wczesnym etapie. Kilka tygodni później ten kontakt okaże się kluczowy dla dalszej historii AR3S.

Zarówno Bartek, jak i Kuba zasugerowali mi, że warto zgłosić się do Startup Wrocław. Nie bardzo wiedziałem, jakiej pomocy mógłbym oczekiwać od tej organizacji, ale szybko okazało się, że kontakt miał sens.

Rozmowa z Maciejem pomogła mi uporządkować kolejne kroki. Dostałem konkretne kontakty, wskazówki dotyczące wydarzeń i lepsze rozeznanie, gdzie szukać ludzi, którzy mogą pomóc projektowi przejść od idei do realizacji.

Maciej ze Startup Wrocław wkręca mnie między innymi na odbywające się akurat we Wrocławiu AI Tinkerers Poland & GDG #2, żebym mógł rozejrzeć się za potencjalnym CTO i trochę lepiej poznać środowisko AI.

Zaskakuje mnie atmosfera: ożywione dyskusje, spontaniczne rozmowy z zupełnie obcymi osobami i szybka wymiana kontaktów — zupełnie inaczej niż na konferencjach medycznych, na których do tej pory bywałem.

Opowiadam kilku programistom o AR3S. Część z nich twierdzi, że prototyp da się zbudować w weekend, co mocno rozmija się z moimi wcześniejszymi szacunkami, wskazującymi raczej na kilka tygodni pracy. Te szacunki miałem głównie od LLM — sam nie miałem jeszcze wystarczającej wiedzy technicznej, żeby je sensownie zweryfikować.

Skąd ta różnica? Prawdopodobnie każdy trochę inaczej rozumiał słowo „prototyp”.

Maciej ze Startup Wrocław umawia mnie również na krótkie spotkanie online z Piotrem z CTT (Catch The Tornado). Rozmowa daje mi kilka konkretnych wskazówek dotyczących budowania produktu: ograniczenia pierwszego zakresu, sprawdzenia najważniejszych założeń na możliwie prostym prototypie i niewpadania zbyt wcześnie w pułapkę dopracowywania wszystkiego naraz.

Piotr ma również ciekawy pomysł na wykorzystanie w systemie grafów logicznych. Na etap przed MVP brzmi to zdecydowanie zbyt skomplikowanie, ale zapisuję ten pomysł jako coś, do czego być może warto będzie w przyszłości wrócić.

Po raz kolejny jestem pod wrażeniem, że zupełnie obca osoba poświęca mi swój prywatny czas, żeby pomóc w pracy nad AR3S.

Kuba łączy mnie z Mateuszem — programistą i potencjalnym kandydatem na CTO. Opowiadam mu o problemie, który próbuję rozwiązać, dotychczasowych eksperymentach i ogólnym pomyśle na budowę systemu.

Postanawiam napisać artykuł o WAD — whiplash-associated disorders, czyli zespole dolegliwości występujących po urazie przyspieszeniowo-opóźnieniowym kręgosłupa szyjnego, najczęściej kojarzonym z kolizjami drogowymi. Szczególnie interesuje mnie problem pacjentów, u których utrzymują się rzeczywiste ograniczenia funkcjonalne, mimo że badania obrazowe nie wykazują poważnych uszkodzeń strukturalnych. Roboczy tytuł tekstu brzmi: „Między strukturą a funkcją. O trwałym uszczerbku po niewielkich urazach kręgosłupa”.

Pierwszy cel jest czysto merytoryczny. Wokół niewielkich urazów kręgosłupa, trwałego uszczerbku i znaczenia zaburzeń funkcjonalnych od dawna panuje sporo pojęciowego bałaganu. Chcę uporządkować własne stanowisko, zebrać argumenty medyczne i skonfrontować je z perspektywą prawną. Druga rzecz, że dobra publikacja w czasopiśmie prawniczym mogłaby pomóc mi zbudować rozpoznawalność i wiarygodność wśród prawników zajmujących się sprawami odszkodowawczymi — czyli dokładnie w środowisku, do którego w przyszłości ma trafić AR3S.

Kolejne z serii spotkań umówionych przez Macieja — tym razem z Michałem z bards.ai. Michał sugeruje, żeby uważać z dokładaniem kolejnych kroków tylko dlatego, że da się je dołożyć, i regularnie sprawdzać, czy tego samego nie można zrobić prościej.

Trafia w mój problem, bo mnie naturalnie ciągnie w stronę rozbijania analizy na kolejne etapy. Daje to większą kontrolę nad tym, co robi model, ale każdy kolejny etap kosztuje czas, pieniądze i tworzy następne miejsce, w którym coś może się zepsuć.

Nie wiem jeszcze, gdzie leży granica. Pewnie będziemy się z tym jeszcze trochę szarpać.

Postanawiam sprawdzić, czy założenia pipeline’u w ogóle mają sens, jeszcze zanim powstanie działający system. Mateusz dopiero wdraża się w projekt, więc na tym etapie nie ma jeszcze aplikacji, automatyzacji ani wygodnego interfejsu. Jest tylko koncepcja procesu i potrzeba sprawdzenia, czy poszczególne kroki rzeczywiście da się połączyć w całość.

Cały przebieg wykonuję ręcznie. Każdy etap uruchamiam osobno w kolejnym wywołaniu LLM, z własnym promptem i przygotowanym kontekstem. Wynik jednego kroku kopiuję, porządkuję i przekazuję jako wejście do następnego. To dość żmudne i zajmuje kilka godzin, ale dzięki temu po raz pierwszy mogę prześledzić cały proces od początku do końca, zamiast oceniać pojedyncze elementy w oderwaniu od reszty.

Rezultat nie jest jeszcze gotowym produktem, ale jest wystarczająco użyteczny, żeby potwierdzić najważniejsze założenie: kolejne etapy analizy da się połączyć w spójny pipeline, który daje więcej niż pojedyncze zapytanie do modelu. AR3S przestaje być wyłącznie schematem rozrysowanym w notatkach. Co prawda na razie działa ręcznie, powoli i bardzo nieporęcznie, ale jednak działa.

Bartek łączy mnie z Sebastianem, inwestorem VC. Od początku zaznaczam, że nie jest to rozmowa inwestycyjna — produktu właściwie jeszcze nie ma, a ja szukam przede wszystkim wskazówek, co powinienem zrobić dalej.

Sebastian bardzo wyraźnie przesuwa mój sposób myślenia w stronę rynku: im szybciej pokażę choćby niedoskonałą wersję potencjalnym klientom, tym lepiej. Jego zdaniem nie powinienem czekać, aż wszystko będzie dopracowane. Najpierw trzeba sprawdzić, czy prawnicy rzeczywiście rozpoznają problem, chcą korzystać z rozwiązania i — przede wszystkim — czy są gotowi za nie zapłacić.

Podsyła mi również konkretne materiały i narzędzia, między innymi dotyczące Lean Startup oraz Value Proposition Canvas. Wygląda na to, że będę musiał bardziej skupić się na tej "trakcji".

Jadę na współorganizowany przez Bartka meetup WAIT AI4LAW — poświęcony, jak sama nazwa wskazuje, wykorzystaniu AI w pracy kancelarii prawnych. Skoro buduję narzędzie dla prawników, muszę lepiej zrozumieć ich sposób myślenia o AI, wdrożeniach i związanym z nimi ryzyku.

Jedną z prelegentek jest Maria — prawniczka specjalizująca się w prawnych aspektach wdrażania AI. W przerwie udaje mi się porozmawiać z nią chwilę o moim pomyśle, przyszłych wymaganiach prawnych i kwestiach compliance. Wygląda na to, że ten obszar będzie wymagał znacznie głębszej analizy.

Na miejscu jest również niezastąpiony Maciej.

Mały, ale ważny krok: powstaje pierwsza wewnętrzna specyfikacja pipeline’u MVP. Rozpisuję kolejne etapy analizy, ich cele, założenia działania, oczekiwane dane wejściowe i wyniki, a także prompty oraz historię wprowadzanych zmian.

Dokument ma być dla CTO mapą systemu i wspólnym punktem odniesienia: co dokładnie powinien robić każdy element, które założenia są aktualne i dlaczego w kolejnych wersjach coś zostało zmienione.

Dzięki temu wiedza o AR3S przestaje być rozproszona pomiędzy rozmowami, notatkami i pojedynczymi eksperymentami. Zaczyna powstawać właściwa dokumentacja produktu, która pozwala przełożyć moją koncepcję domenową na konkretną implementację.

Od dzisiaj przestaję przyjmować pacjentów w czwartki. Potrzebuję stałego czasu na rozwijanie AR3S, testowanie kolejnych wersji i przygotowywanie materiałów dla Mateusza. Część odzyskanego dnia nadal przeznaczam na bieżącą pracę nad opiniami sądowymi, ale po raz pierwszy świadomie ograniczam praktykę lekarską, żeby zrobić w tygodniu miejsce na budowę produktu.
Zabawa w startup coraz wyraźniej zaczyna kosztować mnie nie tylko czas wolny i pieniądze przepalane na tokeny, lecz także część przychodu z którego rezygnuję, żeby projekt mógł posuwać się szybciej.

Powstaje pierwsza prezentacja AR3S. Nie jest jeszcze materiałem do wysyłki, ale zmusza nas do opisania projektu językiem rynku: problemu klienta, modelu biznesowego, przewagi i planu wejścia na rynek. Pitch deck zmusza nas też do spojrzenia na AR3S nie tylko jak na system, który trzeba zbudować, ale jak na potencjalną firmę.

Udaje mi się znaleźć pierwsze publiczne dane dotyczące liczby postępowań, w których wykorzystywane są opinie biegłych. Na ich podstawie próbujemy zgrubnie oszacować potencjalną skalę rynku od góry. Szybko okazuje się jednak, że sama liczba spraw niewiele mówi o tym, ile analiz rzeczywiście mogłoby zostać kupionych.

Dlatego zaczynamy również myśleć od dołu: ile kancelarii prowadzi sprawy wymagające oceny opinii medycznych, ile takich spraw przypada na jedną kancelarię i jak często prawnicy mogliby realnie korzystać z AR3S. Na tym etapie są to jeszcze bardzo wstępne szacunki, ale po raz pierwszy próbujemy zamienić ogólne przekonanie, że „rynek powinien być duży”, w liczby, które da się później sprawdzić.

Zaczynam też uważniej przyglądać się potencjalnej konkurencji. Rynek legal AI okazuje się zatłoczony, ale większość narzędzi skupia się na wyszukiwaniu informacji, analizowaniu i podsumowywaniu dokumentów, tworzeniu chronologii, researchu albo przygotowywaniu pism. Część produktów jest bardziej wyspecjalizowana w sprawach odszkodowawczych i dokumentacji medycznej, jednak również tam dominują porządkowanie materiału i generowanie dokumentów.

Na tym etapie nie znajduję jednego oczywistego odpowiednika AR3S. Nie jestem jednak pewien, czy rzeczywiście oznacza to brak bezpośredniej konkurencji, czy po prostu nie szukamy jeszcze wystarczająco dobrze.

Po tygodniach projektowania, budowania i testowania pojedynczych elementów udaje nam się uruchomić pełny przebieg MVP AR3S.

Wynik jest jeszcze bardzo brudny. Pojawiają się powtórzenia, błędne oceny, problemy z formatem i wiele fragmentów, które wymagają poprawy. Mimo to system przechodzi przez cały zaplanowany proces i daje rezultat, który można wreszcie ocenić jako całość. Wśród szumu znajdują się konkretne słabe punkty opinii, które rzeczywiście mogą mieć znaczenie dla prawnika.

Najważniejsza reakcja przychodzi jednak od Mateusza. Do tej pory podchodził do projektu ostrożnie — jako do interesującego pomysłu, który równie dobrze może nie zadziałać. Po zobaczeniu pierwszego wyniku mówi, że zaczyna naprawdę wierzyć, że AR3S rozwiązuje realny problem i może się udać.

Przed nami niewątpliwie ogrom pracy, ale przynajmniej istnieje już coś, co cieszy oczy i rzeczywiście działa!

Rozmowa z Marią podczas AI4LAW nie kończy się na krótkiej wymianie zdań w przerwie. Zlecamy kancelarii Lubasz i Wspólnicy przeprowadzenie audytu prawnego AR3S.

Przesyłamy kancelarii szczegółowe materiały opisujące sposób działania systemu, a ja odpowiadam na liczne pytania dotyczące między innymi przetwarzanych danych, korzystania z zewnętrznych modeli, przechowywania plików, odpowiedzialności stron oraz planowanego sposobu udostępniania usługi kancelariom. Każda odpowiedź prowadzi do następnych pytań i szybko okazuje się, że samo rzetelne opisanie produktu na potrzeby audytu jest już całkiem poważnym zadaniem.

Mateusz nie jest początkowo przekonany, czy na tak wczesnym etapie warto przeznaczać na audyt prawny niemałe — szczególnie jak na projekt finansowany z własnej kieszeni — środki. Rozumiem jego wątpliwości. Audyt nie dodaje żadnej nowej funkcji, nie poprawia wyników i nie przyspiesza budowy MVP. Te same pieniądze można byłoby przeznaczyć na dalszy rozwój produktu.

Mimo to uważam, że warto zrobić to właśnie teraz. AR3S ma analizować materiały zawierające wrażliwe dane medyczne i być wykorzystywany przez prawników. Odkładanie pytań o ochronę danych, zasady korzystania z modeli, umowy i odpowiedzialność do momentu, w którym produkt będzie już gotowy, mogłoby oznaczać konieczność przebudowy rozwiązań, które dopiero tworzymy.

Nie wiem jeszcze, jak skomplikowane okaże się wdrożenie wszystkich zaleceń. Wolę jednak poznać problemy teraz, kiedy wiele rzeczy można jeszcze stosunkowo łatwo zmienić, niż odkryć je dopiero przed pierwszym pilotażem. Poza tym bez uporządkowania kwestii prawnych nie możemy odpowiedzialnie rozpocząć nawet wstępnych testów na prawdziwych sprawach sądowych.

Spotkanie z Marią z kancelarii Lubasz i Wspólnicy było formalnym omówieniem audytu prawnego AR3S. Miałem sporo obaw, czy przy pracy na danych medycznych i materiałach procesowych nie okaże się, że część naszych pomysłów jest po prostu zbyt ryzykowna albo prawnie niewykonalna. Na szczęście wniosek był dużo bardziej optymistyczny: system można wdrożyć w zakładanej formule, tylko trzeba od początku dobrze zaprojektować zasady przetwarzania danych, umowy, zabezpieczenia i komunikację z użytkownikiem.

Co ważne, dostaliśmy też zielone światło dla planowanego modułu wspierającego strategię procesową. Wcześniej nie byliśmy pewni, czy możemy podpowiadać klientowi, jakie działania warto rozważyć w konkretnej sprawie. Okazuje się, że możemy — pod warunkiem właściwego określenia roli systemu, zachowania nadzoru profesjonalnego i jasnego zaznaczenia, że AR3S wspiera decyzję prawnika, a nie podejmuje jej za niego. To była dla mnie duża ulga.

Od początku towarzyszy nam podstawowa obawa: czy podobnego rezultatu nie da się uzyskać po prostu przez przekazanie materiału najmocniejszemu modelowi ogólnemu? Przygotowujemy więc kontrolowany przypadek z 20 celowo wprowadzonymi, często subtelnymi błędami. AR3S i Claude Opus 4.8 otrzymują identyczny materiał, a wyniki porównujemy ręcznie z mapą kontrolną. AR3S wykrywa w pełni 15 błędów i częściowo 2 kolejne, osiągając 16/20 punktów. Claude wykrywa w pełni 13 i częściowo 1, uzyskując 13,5/20. To tylko jeden sztucznie przygotowany test i system nadal wymaga doskonalenia, ale najważniejsza hipoteza przechodzi pierwszą próbę: specjalistyczny proces może dać wynik lepszy niż sam mocny LLM.

Pokazuję surowy rezultat analizy prawnikowi zajmującemu się między innymi odszkodowaniami po wypadkach i błędami medycznymi. Materiał pochodzi ze sztucznie przygotowanej sprawy z celowo wprowadzonymi problemami. Zdaniem prawnika sama analiza wygląda interesująco, ale sposób prezentacji danych jest zbyt chaotyczny. Ma rację — warstwa porządkująca wynik jest jeszcze prowizoryczna, brakuje m.in. agregacji podobnych wyników. Umawiamy kolejne spotkanie na sierpień, gdy będzie już można pokazać bardziej użyteczną formę raportu.

Radykalnie przebudowuję i upraszczam instrukcję dla jednego z kluczowych i najtrudniejszych obszarów CEM. Zajmuje mi to pół dnia, ale efekt jest wyraźny: mniej pomyłek, klarowniejsze odpowiedzi i lepsze trzymanie najważniejszych wymagań. To praktyczne potwierdzenie czerwcowej lekcji — rozwój nie zawsze oznacza dokładanie kolejnych reguł. Czasem trzeba usunąć część złożoności, uporządkować priorytety i zbudować instrukcję od nowa. To jest kierunek.

Na LinkedIn trafiam na informację o europejskich pracach nad dużym, otwartym modelem językowym obejmującym wszystkie oficjalne języki UE. Dla AR3S może to być ważna wiadomość. Taki model mógłby obniżyć koszt mniej wymagających części analizy, a dzięki silniejszemu naciskowi na języki europejskie — w niektórych zadaniach radzić sobie lepiej niż modele projektowane przede wszystkim z myślą o angielskim. Nawet jeśli nie dorówna najmocniejszym modelom amerykańskim w najbardziej złożonych etapach, może stać się użyteczną warstwą europejskiego stosu technologicznego. W dłuższej perspektywie byłoby to szczególnie interesujące przy wejściu AR3S do kolejnych krajów CEE.

Przejście na modele OpenAI trochę nas stresowało, bo z samego cennika wynikało, że koszt pojedynczego tokena będzie wyższy. Obawialiśmy się więc, że pełna analiza stanie się jeszcze droższa. Tymczasem stało się odwrotnie: wyniki całego systemu wyraźnie się poprawiły, a koszt pełnego przebiegu spadł mniej więcej trzykrotnie. Największe zaskoczenie było takie, że droższy token wcale nie oznaczał droższej analizy. Prawdopodobnie duże znaczenie miało skuteczniejsze wykorzystanie cache i mniejsza liczba przebiegów, które trzeba było powtarzać.

Na urlopie wracam myślami do serii problemów, które próbowaliśmy rozwiązywać osobno. Dochodzę do wniosku, że dalsze poprawianie kolejnych instrukcji nie wystarczy — trzeba zmienić organizację całego procesu. Nowe podejście powinno jednocześnie uprościć część analizy, poprawić stabilność i obniżyć koszty. Pipeline robi się coraz bardziej złożony. Mam tylko nadzieję, że nadal rozwiązujemy realny problem, a nie zaczynamy uprawiać overengineeringu.

Po kilku miesiącach wspólnej pracy z prawnikiem zajmującym się sprawami odszkodowawczymi kończymy artykuł o WAD o którym wspominałem we wpisie z 5 lutego. Moja część medyczna zostaje uzupełniona o perspektywę procesową, a tekst przechodzi kolejne rundy poprawek, dopisków i przeredagowywania.

W pewnym momencie pojawia się jednak dość zasadniczy problem: artykuł jest zdecydowanie za długi. Znacznie przekracza standardowy limit 40 tysięcy znaków, a skrócenie go do wymaganej objętości oznaczałoby usunięcie dużej części argumentacji, którą przez ostatnie miesiące mozolnie budowaliśmy.

Kontaktujemy się więc z redakcją czasopisma prawniczego i pytamy, czy mimo wszystko możemy przesłać pełną wersję. Ku naszej uldze redakcja zgadza się przyjąć tekst i skierować go do recenzji, pozostawiając kwestię ewentualnych skrótów na później.

Dzisiaj oficjalnie wysyłamy artykuł.

Nie oznacza to oczywiście, że zostanie przyjęty w obecnym kształcie. Prawdopodobnie czekają nas jeszcze uwagi recenzentów, poprawki i być może bolesne cięcia. Na razie jednak tekst, który przez wiele miesięcy istniał w kolejnych wersjach roboczych, wreszcie opuszcza nasze komputery i trafia do redakcji.

Uruchamiamy nową stronę ar3s.tech i zaczynamy przygotowywać publiczny Build Log. Dziennik ma pokazywać nie tylko kolejne sukcesy, ale również błędne założenia, nieudane próby, koszty i decyzje, które doprowadziły produkt do obecnego kształtu — bez odsłaniania mechaniki CEM.

Od maja wiemy już o Newcase.ai. Produkt łączy dokumentację medyczną, zeznania i pozostałe materiały procesowe, buduje chronologie, wyszukuje sprzeczności oraz wspiera analizę biegłych. Jego zakres jest jednak szerszy niż AR3S i obejmuje całą warstwę litigation intelligence, a nie wyłącznie merytoryczną ocenę konkretnej opinii.

Dzisiaj, podczas kolejnego researchu konkurencji, przypadkiem trafiam na dwa rozwiązania znajdujące się jeszcze bliżej części tego, co próbujemy zbudować: V7 Go oraz ArrowLex.

V7 Go wprost reklamuje analizę raportów eksperckich, ocenę metodologii, identyfikowanie słabości i niespójności, porównywanie raportów oraz mapowanie wniosków do materiału źródłowego. Funkcjonalnie jest to już bardzo blisko części problemów, które próbujemy rozwiązać. V7 pozostaje wprawdzie szeroką platformą do automatyzacji analizy wielu rodzajów dokumentów — od raportów medycznych po techniczne, inżynierskie i finansowe — a nie produktem skupionym wyłącznie na medycznych opiniach sądowych. Trzeba będzie jednak mieć ich bardzo uważnie na oku.

ArrowLex jest z kolei platformą zaprojektowaną dla prawników pracujących z biegłymi. Umożliwia analizowanie raportów eksperckich, przygotowywanie pytań i planów przesłuchań, symulowanie odpowiedzi eksperta oraz porównywanie jego zeznań z dokumentami sprawy. Działa więc w bardzo podobnym procesie pracy prawnika, ale koncentruje się przede wszystkim na przygotowaniu do przesłuchania i szerzej rozumianym expert litigation.

Pierwsza reakcja to irytacja na samego siebie. Zdążyliśmy już wysłać pierwszym inwestorom wcześniejszą wersję pitch decku, w której nie uwzględniliśmy tych firm. Trochę wygląda to tak, jakbyśmy nie potrafili znaleźć własnej konkurencji. Slajd konkurencyjny wymaga natychmiastowej przebudowy.

Co gorsza, nie jest tak, że te firmy pojawiły się właśnie teraz. V7 działa na rynku od lat, a analizą raportów eksperckich nie zajmuje się od wczoraj. ArrowLex również nie wygląda na naprędce przygotowany eksperyment. To nie konkurencja nagle wyrosła nam przed nosem — raczej my dopiero teraz zauważyliśmy, że inni od pewnego czasu zbliżają się do podobnego problemu z różnych stron.

Z drugiej strony odkrycie takich produktów jest również w pewnym sensie dobrą wiadomością. Pokazuje, że potrzeba głębszej analizy raportów eksperckich nie istnieje wyłącznie w mojej głowie. Być może rzeczywiście próbujemy rozwiązać realny problem, a nie stworzyć rynek, którego nikt poza nami nie potrzebuje.

Nadal nie znajduję produktu identycznego z AR3S — łączącego specjalizację medyczną z systematyczną weryfikacją argumentacji konkretnej opinii i poszukiwaniem merytorycznych podstaw zarzutów. Nie możemy już jednak pocieszać się myślą, że działamy w zupełnie pustej kategorii.

Trudno nie poczuć przy tym ukłucia niepokoju. My wciąż budujemy MVP, podczas gdy po drugiej stronie są firmy z gotowymi produktami, zespołami, finansowaniem i kilkuletnią przewagą. Nie wystarczy więc być pierwszym — zwłaszcza że prawdopodobnie już nim nie jesteśmy. Musimy zbudować rozwiązanie wyraźnie lepsze w naszym wąskim zastosowaniu: głębsze, bardziej wiarygodne i rzeczywiście użyteczne dla prawnika mierzącego się z medyczną opinią biegłego.

I musimy zrobić to możliwie szybko.

Dzisiaj miałem półgodzinną, wstępną rozmowę z Magdaleną — osobą z wieloletnim doświadczeniem po stronie funduszy VC i w ocenie startupów na bardzo wczesnym etapie. Chciałem sprawdzić, jak z zewnątrz wygląda AR3S, nasz pitch deck i sam pomysł szukania inwestora jeszcze przed właściwymi pilotażami.

Rozmowa była krótka, ale bardzo przyjemna. Najmocniej wybrzmiała prosta rada: jak najwięcej i jak najwcześniej rozmawiać z prawnikami. Z kilkoma zaprzyjaźnionymi osobami już konsultuję wyniki i kierunek rozwoju, ale trudno udawać, że jest to prawdziwa walidacja rynku.

Problem jest dość oczywisty: AR3S jeszcze nie jest gotowym produktem, a obcy prawnik raczej nie przekaże poufnych materiałów sądowych do czegoś, co nadal znajduje się w budowie. Czekanie na pełną platformę może jednak potrwać zbyt długo.

Wrócił więc pomysł, który rozważałem już wcześniej (zanim jeszcze zająłem się prać nad AR3S) : płatna analiza opinii biegłego wykonywana przeze mnie. Początkowo miała to być całkowicie manualna usługa ekspercka. Teraz mogłaby mieć formę hybrydową — ja odpowiadam za analizę i końcowy rezultat, ale w pracy korzystam już z AR3S.

Klient nie dostawałby jeszcze dostępu do platformy. Otrzymywałby gotową, zweryfikowaną analizę konkretnej opinii. Ja natomiast mógłbym sprawdzić na prawdziwych sprawach, czego kancelarie faktycznie oczekują, w jakiej formie chcą dostać wynik, ile są gotowe zapłacić i czy po pierwszym zleceniu wracają z kolejnym.

Być może właśnie tak powinien wyglądać etap pomiędzy obecnym prototypem a właściwymi pilotażami: pierwsze płatne sprawy i kontakt z rynkiem bez czekania, aż wszystko zostanie wypolerowane na błysk.

Dzisiaj rozmawiałem telefonicznie z Krzysztofem, adwokatem z dużym doświadczeniem procesowym. Bardzo sympatyczny człowiek i świetny rozmówca — pół godziny minęło zdecydowanie za szybko.

Rozmawialiśmy głównie o opiniach biegłych. Z jego doświadczenia wynika, że żeby skutecznie podważyć opinię, trzeba mieć naprawdę mocne argumenty, a czasami nawet to nie wystarcza. Krzysztof zwrócił mi uwagę, że dobrze byłoby, gdyby AR3S tam, gdzie to możliwe, potrafił dodatkowo podeprzeć zarzuty literaturą naukową lub podręcznikową.

Pomysł jest niegłupi, wręcz dość oczywisty dla takiego narzędzia, mam jednak do tego rozwiązania pewien dystans. Wiele błędów, które widzę w opiniach biegłych, nie polega wcale na ewidentnej sprzeczności z podręcznikiem, tylko na niewłaściwej interpretacji materiału, pominięciu czegoś istotnego albo zbyt daleko idącym wnioskowaniu. Mimo wszystko warto zapisać ten pomysł na etap po MVP. Jego realizacja może być jednak bardziej problematyczna, niż się na pierwszy rzut oka wydaje: LLM-y mają wyjątkowo paskudny zwyczaj wymyślania publikacji, których nigdy nie było, a my od początku staramy się trzymać model na krótkiej smyczy i nie pozwalać mu za bardzo fantazjować.

Przy okazji opowiedziałem Krzysztofowi o dwóch artykułach medyczno-prawnych, które mam obecnie w recenzji. Bardzo zainteresował się tym tematem, jeden z preprintów obiecałem mu nawet wysłać mailem. Pojawił się też pomysł, żeby kiedyś napisać coś wspólnie do czasopisma prawniczego. Zobaczymy, co z tego wyjdzie.

Mateusz przed urlopem wrzucił pierwszą wersję większej zmiany w AR3S. Niestety nie zdążył jej dokończyć ani też porządnie przetestować i pierwszy run pokazał sporo błędów. Na ten moment system w zasadzie nie działa tak, jak powinien. I teraz jestem w kropce, bo Mateusz wyjechał na urlop i wróci dopiero za tydzień, a ja przez ten czas nie jestem w stanie w zasadzie niczego sensownego testować ani poprawiać :/ Udało mi się jedynie przenalizować działanie 2 nowych modułów, ale z uwagi na brak ich "współpracy" ze sobą, głębsza analiza nie jest możliwa :/
I znowu wszystko się przesuwa.... Z drugiej strony to była duża poprawka obejmująca wiele modułów i mocno wpływająca na mechanikę systemu więc liczyłem się z tym, że jej wdrożenie chwilę zajmie (ale też łudziłem się, że może jednak pójdzie nieco sprawniej... ).

Udało się w końcu przerobić pitch deck — teraz nie wygląda już jak wypluty przez LLM. Posiedziałem też trochę nad zawartością strony www i chyba czas zrobić jakieś sensowniejsze logo.

Wczoraj miałem godzinną rozmowę z właścicielem kancelarii odszkodowawczej. Umówiliśmy się na spotkanie pod koniec sierpnia. Mam tylko nadzieję, że do tego czasu uda się doprowadzić system do używalności :0

Dzisiaj kolejna rozmowa z prawniczką, tym razem zajmującą się głównie sprawami medycznymi i odszkodowaniami. Powiedziała mi, że zdecydowaną większość spraw medycznych stara się omówić z fachowcem z danej specjalizacji. Jeśli się da — z kimś znajomym, jeśli nie — rozważa płatną konsultację. Część lekarzy, biegłych i instytutów badawczych świadczy takie usługi. Posiłkuje się też AI, korzystając po prostu z chatbota z LLM.

Generalnie potwierdza to moje przypuszczenia. Teraz pytanie, czy AR3S będzie dawał na tyle dobre i powtarzalne wyniki, żeby przy planowanej cenie okazać się atrakcyjną alternatywą.

Umówiliśmy się na spotkanie w przyszłym miesiącu, kiedy system będzie już po poprawkach i będzie co pokazać.

Pod koniec lipca odezwałem się do jednego z dużych polskich ubezpieczycieli. Chciałem sprawdzić, czy problem, który próbujemy rozwiązać w AR3S, jest w ogóle interesujący z perspektywy organizacji prowadzącej dużą liczbę spraw odszkodowawczych.
Kilka dni temu dostałem odpowiedź. Temat wzbudził wstępne zainteresowanie i ma zostać skonsultowany z osobami pracującymi bezpośrednio przy szkodach. Poproszono mnie też o dodatkowe materiały pokazujące, jak działa system.

AR3S jest akurat w trakcie przebudowy, więc nie chcę wysyłać czegoś tylko po to, żeby coś wysłać. Za około 2–3 tygodnie przygotujemy kilka syntetycznych spraw medycznych wraz z pełnym wynikiem analizy. Do każdej będzie też „mapa kontrolna” pokazująca, jakie problemy celowo umieściliśmy w materiale.
Dzięki temu będzie można zobaczyć nie tylko to, co AR3S znalazł, ale również to, czego nie znalazł.

Chyba sensowniejszy test niż kolejny slajd w decku.

Mateusz wrócił z urlopu, dzisiaj dostałem nową wersję systemu z poprawkami do bypassu. Wszystko działa jak zaplanowaliśmy. Bypass w zasadzie nie potrzebuj poprawek aczkolwiek w jednym z analizowanych przypadków pojawił się jeden dziwny błąd - niemal literówka ale w istotnej części dotyczącej OUTPUTu (jakaś halucynacja LLM? trzeba będzie obniżyć temperaturę do 0?). Mając działający bypass siadam do poprawy modułów CEM - dzisiaj na tapetę poszedł pierwszy z modułów - uprościłem prompt, dostosowałem go do nowego rodzaju danych - wynik zdecydowanie lepszy!

btw - znalazłem kolejny startup z USA który buduje to samo co my (Prova Lens) - system do podważania opinii biegłych. Przyjrzałem się trochę ich aplikacji i wygląda na to, ze filozofia działanie jest zupełnie odmienna niż AR3S, niemniej trzeba będzie mieć ich na oku (no i zaktualizować deck... )

Tydzień temu przyszło mi do głowy, żeby odezwać się ponownie do Startup Wrocław. Na początku roku, kiedy dopiero zaczynałem całą tę przygodę ze startupem, naprawdę sporo mi pomogli.

Wysłałem im więc krótki update: na jakim etapie jest teraz AR3S, że rozglądamy się za inwestorem/aniołem i że myślimy też o dołączeniu do zespołu jeszcze jednej osoby.

Dziwny zbieg okoliczności, bo dwa dni później Startup Wrocław wrzucił na LinkedIn post o Made in Wroclaw 2026. W programie ma być m.in. VC Demo Day, czyli dokładnie coś, gdzie można byłoby pogadać z ludźmi, z którymi normalnie trudno złapać kontakt.

Przy okazji okazuje się, że będzie też konkurs dla startupów — mają wybrać dziesiątkę najlepszych. Trochę się obawiam, że AR3S jest za mało „sexy”, żeby konkurować z latającymi deskorolkami, kosmicznym deeptechem i innymi rzeczami, które dobrze wyglądają na scenie. Z drugiej strony może to być całkiem dobra okazja, żeby się pokazać.

Chyba głupio byłoby się nie zgłosić.

W zasadzie od samego początku prac nad AR3S wraca do mnie jedna rzecz — a co jeśli „zwykły” LLM będzie znajdować błędy równie skutecznie co AR3S (albo jedynie niewiele gorzej)? Kolejne generacje LLM będą coraz mocniejsze, więc nawet jeśli AR3S będzie rósł razem z nimi (bo przecież my te silniejsze modele możemy także wykorzystać w wybranych modułach i dodatkowo pomaga nam architektura całego pipeline'u), to w pewnym momencie różnica może zrobić się na tyle mała, że dla klienta może być pomijalna i płacenie za AR3S może tracić sens, skoro niewiele gorszy wynik da „goły” LLM albo jakiś tani wrapper. Na szczęście architektura AR3S pozwala nam nie tylko znajdować tego typu typowe "błędy", ale również oceniać, czy dana teza jest „podważalna”, tzn. czy można dla niej znaleźć równie logiczne (i wiarygodne) alternatywne uzasadnienie. Teoretycznie taka teza to nie jest błąd, bo pierwotna może być cały czas prawidłowa i po prostu posiadać równie prawdopodobne alternatywy. Z punktu widzenia LLM systematyczna ocena całego tekstu opinii pod kątem znalezienia tego typu alternatywnych kwestii będzie znacznie trudniejsza niż „zwykłe” znalezienie błędów. A jednocześnie tego typu alternatywne tezy mogą być bardzo wartościowe dla prawnika bo on nie musi wykazać, że to co napisał biegły jest błędne - często wystarczy, że wykaże, że równie logiczna jest inna interpretacja faktów (oczywiście taka która akurat pasuje jego klientowi). Co więcej, z praktyki biegłego sądowego zauważam, że większa część nieprawidłowości w opiniach biegłych nie polega na popełnieniu przez nich jakichś kardynalnych „błędów”, tylko właśnie na niezbyt dokładnym interpretowaniu faktów, wyciąganiu nie do końca uzasadnionych wniosków i niebraniu pod uwagę alternatyw. I tego typu nieścisłości mogą zostać w łatwy sposób przeoczone, a dodatkowo trudno jest je obiektywnie ocenić (a w przypadku części z nich w ogóle nie jest to możliwe). AR3S jest od początku projektowany tak, żeby dawać output w postaci zweryfikowanej listy alternatywnych interpretacji dla każdego fragmentu opinii, razem z uzasadnieniem tych alternatyw oraz ich półilościową oceną.
W takim wypadku, jeśli architektura AR3S pozwoli prawnikowi na uzyskanie dostępu do tego typu informacji, minimalizując przy tym ryzyko, że coś zostanie przeoczone czy zhalucynowane, to produkt powinien się obronić nawet wtedy, gdy kolejne generacje „gołych” LLM-ów będą coraz lepiej radziły sobie ze znajdowaniem typowych błędów.

Po namyśle podjąłem decyzję, że rzeczywiście trzeba się zgłosić do tego konkursu na Made in Wroclaw — VC Demo Day. Byłoby nieracjonalne przegapić taką okazję. W ostatnich tygodniach wpadłem w lekki marazm w związku z brakiem wyraźnych postępów w pracach nad AR3S, stąd jestem mile zaskoczony, że sama myśl, że idziemy na ten konkurs, dała mi wyraźny zastrzyk nowej energii.

Postanowiłem m.in., że spróbuję samemu zrobić tę ostatnią warstwę programu — czyli moduł prezentujący wyniki oraz moduł generujący strategię procesową/rekomendacje dla prawnika. Na razie zająłem się częścią wizualizującą wynik.

Oczywiście nie znam się nic na programowaniu, ale już od dłuższego czasu ciekawiło mnie, jak w praktyce działa ten cały vibe-coding. Domyślam się, że kod, jaki powstanie, nie będzie idealny, ale zależy mi na tym, żeby na własne oczy widzieć końcową warstwę produktu i na tym już pracować, robiąc dalsze poprawki, a jak już zrobię cały moduł, to wyślę go do Mateusza i w ten sposób będzie on mógł łatwo napisać tę warstwę porządnie, widząc, jak to ma wyglądać. Unikniemy w ten sposób przedłużających się poprawek.

Wydaje mi się, że to działa, bo na samych próbach dostosowania sposobu graficznego pokazania wyników zeszła mi dobra godzina — jakbym za każdym razem musiał dzwonić do Mateusza, żeby zmienił to samemu w kodzie, bawilibyśmy się tak przez tydzień. Mateusz na razie i tak ma co robić, bo cały czas pracuje nad backendem i coś tam poprawia w kodzie modułu agregacji.

Generalnie wyszło to bardzo fajnie — to niesamowite uczucie powiedzieć GPT, żeby coś zakodował, i następnego dnia rano zobaczyć działający program

I najważniejsze — mając już warstwę graficzną, będę mógł zacząć z nią jeździć do prawników i pokazywać im, jak działa produkt, nawet jeśli Mateusz nie zakoduje jej jeszcze w sposób właściwy, bo do prezentacji w zupełności wystarczy to, co wypluje mi GPT.

Ten pomysł z vibe-codowaniem okazał się bardzo dobry. Program, który zrobił LLM, wygląda graficznie ładnie i czytelnie. Wczoraj byłem z wizytą u zaprzyjaźnionej prawniczki, której już od dawna opowiadałem o AR3S — tym razem miałem wreszcie możliwość pokazania, na czym polega praca produktu i jak wygląda jego wynik. Wyglądała na pozytywnie zaskoczoną, aczkolwiek zdaję sobie sprawę, że było to tylko pierwsze wrażenie i nie miała wystarczająco dużo czasu, żeby wgryźć się w detale i przeanalizować wyniki, jakie daje program, a to jest przecież najważniejsze. Dogadaliśmy się, że w przyszłym tygodniu przetestujemy AR3S na zanonimizowanym materiale z jednej z jej aktualnych spraw i wyślę jej gotowy wynik — w ten sposób będzie miała możliwość bezpośredniej oceny, na ile program jest użyteczny. To fajne uczucie mieć w końcu możliwość pokazania, jak to działa, i zebrania feedbacku od użytkowników!

Muszę tylko poprawić detale tego „programu”, jaki zrobił GPT, i dorobić mu moduł do analizy/sugestii strategii procesowej — siadam nad tym dzisiaj. Przy okazji wrzucę też te trzy przykładowe sprawy, jakie miałem wysłać do ubezpieczyciela, z którym kontaktowałem się pod koniec sierpnia — już i tak jestem z tym opóźniony. Chyba najlepiej będzie jeszcze dorobić możliwość udostępnienia tej wersji online, tak żeby konkretna osoba mogła sama zalogować się i spokojnie przejrzeć przygotowany dla niej wynik. Prawniczka dostałaby dostęp do analizy swojej sprawy, a ubezpieczyciel do trzech syntetycznych przypadków demonstracyjnych. Dużo sensowniejsze niż jeżdżenie wszędzie z laptopem i stanie komuś nad głową podczas oglądania wyników.

Zaczynam się zastanawiać, czy na razie w ogóle nie poprosić Mateusza, żeby zatrzymał dalsze prace nad końcówką — skoro ten prototyp wygenerowany przez GPT wygląda całkiem przyzwoicie i spełnia swoją rolę pokazywania, w jaki sposób działa AR3S, to w najbliższych tygodniach powinien być w zupełności wystarczający, żeby wykorzystać go do prezentacji produktu prawnikom. A w tym czasie Mateusz mógłby np. poprawić moduł ekstrakcji tez, bo tam też jest trochę roboty, a jednocześnie dobrze zrobione tezy wyraźnie poprawią działanie w zasadzie wszystkich późniejszych modułów.

W sumie to moglibyśmy podzielić teraz pracę tak, że ja bym szlifował ten moduł prezentujący wyniki i omawiał go z prawnikami, a Mateusz mógłby w tym czasie zająć się dopracowywaniem samego rdzenia analitycznego — bo oprócz ekstrakcji tam jest też trochę innych spraw do zrobienia. Muszę z nim to obgadać.

Przy okazji — kapnąłem się, że nie mam paszportu! A bez tego nie będę mógł odebrać głównej nagrody w konkursie startupów — wyjazdu na demo-day do USA! To trochę głupio brzmi, bo wiem, że mam raczej niewielkie szanse wygrać, ale z drugiej strony to trochę bez sensu startować z myślą, że i tak nie dostanę nagrody, więc umówiłem się na przyszły czwartek na wizytę w biurze paszportowym — i tak miałem to już dawno załatwić.

Wczoraj udało mi się poprawić i uaktualnić pitch deck — jest już teraz w pełni zgodny z aktualnym kierunkiem rozwoju AR3S. Swoją drogą dalej nie udało mi się wymyślić jakiejś lepszej nazwy :/

Po południu wziąłem się za dalsze prace nad aplikacją do prezentowania wyników AR3S, tak żeby pokazywała to, co ma pokazywać, i nie zdradzała zbyt wiele IP. Fajna zabawa, takie „kodowanie” z chatbotem :) Dzisiaj muszę przygotować ze 2–3 przykładowe opinie do analizy — nie „prawdziwe”, tylko przygotowane specjalnie w celu demonstracji — żeby móc przesłać już całość do prawników.

Swoją drogą — zastanawiałem się ostatnio nad naszymi kosztami analizy jednej sprawy. Dalej są dość wyraźne w przypadku większych objętościowo opinii, a przecież planujemy w przyszłości kolejne moduły, m.in. żeby przygotować do analizy dokumentację medyczną. Trzeba będzie nad tym popracować, żeby koszt zbić. Z drugiej strony liczę na to, że z czasem cena tokenów będzie dalej spadać albo — jak do tej pory — będą pojawiać się nowe, wydajniejsze, a zarazem tańsze modele.

Kolejna sprawa — zastanawiałem się ostatnio nad możliwością udostępniania w przyszłości dostępu do AR3S nie tylko prawnikom, ale też „zwykłym” użytkownikom. Część osób broni się sama, szczególnie w sądach pracy, gdzie toczą się np. sprawy przeciwko ZUS albo o stopień niepełnosprawności, i zapewne byliby mocno zainteresowani możliwością profesjonalnego podważenia niekorzystnej opinii biegłego. Audyt prawny, jaki robiliśmy w czerwcu, wykazał, że jak najbardziej możemy oferować taką usługę.

Co więcej — przyszło mi do głowy, że część osób mogłaby chcieć wykorzystać AR3S w celu sprawdzenia, czy prawnik prowadzący ich sprawę rzeczywiście wykorzystał odpowiednie argumenty przeciwko opinii biegłego. Jako lekarz bardzo często spotykam się z sytuacją, że pacjenci sprawdzają, za pomocą różnych źródeł, nasze opinie, więc czemu w przypadku prawników miałoby być inaczej? Świadomość możliwości wykorzystania AI w tym zakresie stale rośnie w społeczeństwie.

Z naszego punktu widzenia taka sytuacja jest tylko na plus — jeśli prawnik będzie mieć świadomość, że jego klient może sprawdzać jego pracę za pomocą zwykłego LLM albo nawet płatnej wersji AR3S, to zapewne będzie bardziej skory, żeby samemu skorzystać z profesjonalnego narzędzia do analizy opinii biegłych, jakim jest (będzie?) AR3S.

Teoretycznie mógłby skorzystać z prostego chatbota LLM, ale pomijając już kwestie prawne wykorzystania takiego prostego chatbota do analizy dokumentacji medycznej, na koniec mógłby się znaleźć w niekomfortowej sytuacji, że wie tyle samo co klient, który korzystał z tego samego LLM — a dodatkowo bez gwarancji, że część odpowiedzi nie została zhalucynowana, jak to z LLM bywa.

Jeśli jednak chcemy pozycjonować AR3S jako sposób na wydobycie lepszych informacji niż „zwykły” LLM, to wersja dla osób niebędących prawnikami musiałaby być po prostu trochę innym produktem. Tańszym, prostszym i nastawionym przede wszystkim na ocenę opinii oraz wskazanie kwestii, które warto dalej sprawdzić. Wersja profesjonalna dla prawników mogłaby z kolei dawać bardziej szczegółowy wynik i dodatkowe narzędzia związane z dalszym prowadzeniem sprawy. Taki trochę AR3S Lite i AR3S Pro.

Vibe-coding działa. Siedziałem nad tym cały weekend, ale jest już zrobiona nakładka pozwalająca przeglądać wyniki AR3S i generująca nawet „na żywo” strategię procesową. Masa szczegółów i decyzji, co i jak ma działać. Musiałem też trochę pogrzebać w samej logice AR3S, poprawić moduł agregacji i zaprojektować logikę i prompty modułu (już nakładki) do robienia strategii procesowej. Do tego bezpieczne logowanie, instrukcje i opisy dla użytkowników, co i jak działa... ufff.

Po przepaleniu 40$ na tokeny zdecydowałem się przejść na wersję PRO od OpenAI, bo pracy jeszcze dużo... Działamy dalej.

Masa roboty jest z przygotowaniem opinii do demonstratora — nie mogą to być opinie prawdziwe, więc muszę każdą przerabiać, anonimizować, częściowo pisać od nowa... Na szczęście planuję na razie zrobić tylko kilka.

Wieczorem zrobię przykładową opinię na stronę internetową. Wysłałem już zaproszenie do demonstratora do pierwszego prawnika!