Co zbudowaliśmy
Zbudowaliśmy MVP produktu dla kancelarii prawnych liczących około 10–50 osób. Produkt odpowiadał na powtarzalny problem zarządzania wiedzą: odnajdywanie właściwych materiałów we wcześniejszych sprawach, dokumentach i archiwum kancelarii bez polegania na pamięci jednego partnera albo długim ręcznym przeszukiwaniu. Wyszukiwanie dokumentów prawnych miało udostępniać wcześniejszą pracę całemu zespołowi.
Przeszliśmy przez kilka iteracji produktu. Każda z nich pomagała oddzielić atrakcyjną wizję szerokiego copilota prawnego od bardziej bezpośredniego ograniczenia operacyjnego. Oprogramowanie używane przez kancelarie utrudniało szybkie wyszukiwanie wcześniejszej pracy. Dlatego asystent dokumentów prawnych koncentrował się na wyszukiwaniu i dostępie do wcześniejszych materiałów, a nie na zastępowaniu doradcy prawnego.
Luka w dostępie do wiedzy
Partnerzy z długim stażem często potrafili z pamięci wskazać właściwą sprawę, dokument albo argument z dobrą trafnością. Taki nieformalny indeks nie działał jednak dla pozostałych pracowników. Młodsi prawnicy i inne osoby w zespole nie miały tej samej historii kontaktu ze sprawami kancelarii, nawet gdy pliki były uporządkowane w folderach i szczegółowo opisane.
Ręczne wyszukiwanie nadal zajmowało dużo czasu. Trzeba było przewidzieć, która sprawa mogła zawierać odpowiedni precedens, przejrzeć foldery, otworzyć kilka dokumentów i ocenić przydatność każdego z nich. Problem nie wynikał więc wyłącznie z braku dokumentacji. Dotyczył różnicy między przechowywaniem wiedzy a udostępnieniem jej osobie, która wcześniej nie wiedziała, gdzie szukać.
Jak MVP wspierało wyszukiwanie
MVP projektowaliśmy wokół prywatnych materiałów prawnych: wcześniejszych spraw, dokumentów wewnętrznych i fragmentów pracy możliwych do ponownego wykorzystania. Taki prywatny zbiór dokumentów wymagał innego podejścia niż publiczna wyszukiwarka. Badaliśmy parsowanie, tagi, wyszukiwanie semantyczne i grupowanie powiązanych treści. Dzięki temu zapytanie mogło wskazać materiał również wtedy, gdy nie powtarzało dokładnych słów ze źródła.
Wyniki wyszukiwania musiały pozostać powiązane z oryginalnymi dokumentami. W pracy prawnej wiarygodnie brzmiąca odpowiedź bez możliwego do sprawdzenia źródła jest mniej użyteczna niż węższy wynik, który można samodzielnie ocenić. Kierunek produktu traktował więc wyszukiwanie jako podstawową funkcję, a wsparcie redagowania jako późniejsze wykorzystanie znalezionego kontekstu, nie jako zastępstwo profesjonalnej kontroli.
Wyszukiwanie dokumentów musiało działać dla osoby, która nie znała nazw wcześniejszych spraw. Sam układ folderów pomagał w archiwizacji, lecz nie odpowiadał na pytanie o podobny problem opisany innymi słowami. MVP miało skrócić drogę od pytania do listy materiałów, które pracownik mógł następnie otworzyć i samodzielnie ocenić.
Iteracje ujawniły też praktyczne pytania produktowe: ile kontekstu pokazać, jak rozróżniać podobne sprawy oraz jak przygotować wyniki dla pracowników bez historycznej wiedzy partnera. Te decyzje miały większe znaczenie dla doświadczenia użytkownika niż długa lista algorytmów albo frameworków.
Dlaczego odłożyliśmy dalszy rozwój
MVP potwierdziło kierunek produktu, ale dalszy rozwój został odłożony. Technologia pozostawała wówczas kosztowna w porównaniu z powszechną alternatywą. Kancelarie mogły zlecać dużą część ręcznego wyszukiwania praktykantom zdobywającym doświadczenie, często przy niewielkim albo zerowym bezpośrednim koszcie pracy.
To porównanie zmieniało uzasadnienie biznesowe. Produkt nie konkurował wyłącznie z niewygodnym oprogramowaniem prawniczym. Konkurował także z tanim rozwiązaniem organizacyjnym. Lepsze wyszukiwanie mogło ograniczyć pracę ręczną, ale dostępne dane nie uzasadniały twierdzenia, że całkowity koszt rozwiązania będzie niższy dla docelowych kancelarii.
Odłożenie prac było więc decyzją produktową, a nie dowodem na zniknięcie problemu. Badania pokazały konkretną potrzebę, lecz ekonomia rozwiązania na tamtym etapie nie uzasadniała przejścia do większego wdrożenia.
Potwierdzony rezultat i granice
Potwierdzonym rezultatem jest rozwijane iteracyjnie MVP oraz dokładniejsze określenie najważniejszego problemu segmentu: praktycznego udostępnienia większej liczbie pracowników wiedzy zapisanej we wcześniejszych sprawach i dokumentach. Projekt wskazał też słabe wyszukiwanie w istniejącym oprogramowaniu i ekonomię pracy praktykantów jako istotne bariery wdrożenia.
Opis nie deklaruje wdrożenia produkcyjnego, aktywnego użycia w wielu kancelariach, zmierzonej jakości wyszukiwania, skrócenia czasu pracy ani oszczędności finansowych. Nie twierdzi też, że generowany tekst był poprawny prawnie. Takie rezultaty nie zostały dostarczone jako potwierdzone dane.
Dla organizacji z podobnym problemem punktem wyjścia są zbiór dokumentów, reguły dostępu, reprezentatywne pytania i koszt obecnego procesu. Więcej o takim podejściu można przeczytać na stronie o inteligentnym przetwarzaniu dokumentów i RAG.