Podcast

Dobrý den, moje jméno je Jirka Fischerk.
Dobrý den všem, moje jméno je Hinek Volner. A vítáme vás u dalšího dílu podcastu Datatalk.

Dnešní díl je speciální, máme po delší době opět dva hosty, Jonáše a Tomáše. Jirko, o čem nám kluci přišli povídat?

Kluci, Jonáš je viceprezident pro umělou inteligenci a strojové učení, a Tomáš je Senior Product Manager, oba z firmy FileVine. Budeme si povídat o Legaltechu a o umělé inteligenci, konkrétně o rozpoznávání řeči. Probereme startupový příběh Perotu, což je startup s česko-slovenskými kořeny, kde kluci pracovali a dneska pracují pro FileVine, protože na začátku letošního roku zažili úspěšný exit a nyní pokračují pod křídly této americké firmy. Takže pánové, vítejte u nás.

Děkujeme.
Ahoj.
Ahoj, děkuji za pozvání.

Než se pustíme do příběhu Perotu a podíváme se pod kapotu, jaké umělá inteligence Perot používá, pojďme se podívat na vás samotné. Jaký byl váš příběh před nástupem do tohoto startupu? Tome, začneme tebou. Kde se vzal Perot? Co jsi předtím zažil?

Má cesta v IT začala na vysoké škole. Studoval jsem Vysoké učení technické v Brně, obor informatika. Během studia jsem pracoval na různých pozicích softwarového inženýra. Konkrétně jsem nějakou dobu pracoval ve firmě Red Hat, stejně jako mnoho studentů v Brně, kteří pocházejí z podobného prostředí. Potom jsem byl zaměstnán v menší hardwarové a softwarové firmě RC Systems v Brně, kde jsme pracovali na různých zajímavých a nestandardních projektech. Kdybych měl zmínit ten poslední, na kterém jsem pracoval, byl to nějaký na míru vytvořený VR headset pro armádu, kde vojáci trénovali práci s dalekohledy.

Současně jsem se na bakalářském studiu věnoval trochu robotice, kde jsem také zpracoval svou bakalářskou práci. Na magisterském studiu jsem se začal více zaměřovat na umělou inteligenci a strojové učení obecně. Vybral jsem si obor Inteligentní systémy, což bylo v té době v Brně na VUT takové fancy označení pro AI.

V té době mě oslovil kamarád a spolužák Tomáš Čavnický, který zakládal startup. Měli založený tým, obchodní myšlenku a potřebovali někoho, kdo by jim pomohl s kódováním, tedy prvního člověka na vývoj. Pro mě jako studenta to bylo velmi zajímavé. Souhlasil jsem a začali jsme pracovat na Perotu. A ten zbytek už znáte, o tom vám povíme víc v tomto podcastu.

Takže první zaměstnanec Perotu, to je super! A co ty, Tome, jaká byla tvoje cesta do Perotu?

Moje cesta byla asi trochu delší než Jirkova. Začal jsem bakalářské studium ekonomie a financí na Karlově univerzitě na Institutu ekonomických studií. Poměrně rychle jsem si uvědomil, že mě ekonomie tolik nebaví a více mě táhne matematika a statistika. Začal jsem tedy brát co nejvíce předmětů ze statistiky a právě oblast machine learningu mi přišla jako hezká kombinace matematiky a statistiky s aplikací v ekonomii. Takže první kontakt s machine learningem jsem měl právě tam a začal jsem se tomu věnovat hlavně samostudiem.

Rozhodl jsem se, že magisterské studium budu pokračovat na Matematicko-fyzikální fakultě UK, zaměřím se na umělou inteligenci. Po několika měsících, myslím že už po dvou měsících, kdy jsem se teprve seznamoval s novým prostředím a programováním, jsem se setkal s Ondřejem Bojarem, mým budoucím školitelem a vedoucím diplomové práce. Ondřej právě začínal meziuniverzitní grant ELITR, jehož cílem bylo dělat překlady v reálném čase pro Evropský parlament.

Když někdo mluví například česky, lidé mají sluchátka a překlad se jim překládá v reálném čase.

To je tedy nahrazení tlumočníků.

Přesně tak, nahrazujeme tlumočníky. Tato myšlenka grantu mi přišla zajímavá. Nikdy předtím jsem se rozpoznáváním řeči nezabýval, nevěděl jsem o tom mnoho, ale přijal jsem výzvu a zapojil se do projektu.

Grant měl částečnou spolupráci s Brnem, konkrétně s VUT, kde je silná skupina zaměřená na rozpoznávání řeči. Byl jsem vyslán do Brna, abych se naučil, o co v rozpoznávání řeči jde. Strávil jsem tam několik měsíců v této skupině.

Bylo to skvělé, dostal jsem se do kontaktu s předními vědci, kteří na světo úrovni vyvíjejí systémy pro rozpoznávání řeči. Tam jsem také poznal svého kamaráda Martina Kocoura, který znal Tomáše Čavnického, a tak se světy propojily. Tomáš tehdy hledal někoho, kdo rozumí rozpoznávání řeči, tak jsme se sešli u piva a další den jsem už seděl v kanceláři Perotu.

V průběhu druhého ročníku magisterského studia jsem vlastně pracoval na částečný – spíše plný úvazek v Perotu.

A o jakém roce se bavíme? Kdy jsi nastupoval? Kdy Perot vznikl?

Myslím, že jsme začínali někdy v létě 2018, to byly úplné začátky, opravdu velmi, velmi early fáze.

A ty jsi nastupoval kdy, Jonáši?

Já jsem nastupoval asi o rok později, někdy v roce 2019.

Dobře. Tak možná nás vezměte do období 2018–2019, co vůbec Perot znamenal, co byla podstata firmy, jaký byznys jste řešili a jaká byla myšlenka startupu? Na co jste získali financování?

Byl tam docela zajímavý příběh, který se lidem často líbí, protože je to opravdu skvělý storytelling. Naši spoluzakladatelé tvořili tříčlenné trio.

Dva bratři Baumovci, jeden z nich byl státní zástupce na Floridě a druhý, Brian Baum, byl serial entrepreneur, měl za sebou řadu dalších byznysů a startupů.

Ten státní zástupce přišel s problémem z praxe. Pracoval na soudním případu, který se blížil ke konci. V poslední den musel obhájit muže, který seděl ve vězení, ale neměl žádné důkazy. Jediné, co měli, bylo asi 20 hodin audiozáznamů z telefonátů z vězení.

Erik si sedl a během jednoho dne si všechno vyslechl, našel v audiozáznamech klíčový moment, ve kterém se obžalovaný přiznal své matce, a díky tomu případ vyhrál.

Když s tímto příběhem přišel ke svému podnikatelskému bratrovi, okamžitě jim to dalo jasný směr, že na to musí existovat řešení.

V očích jim to doslova zazářilo.

A do scénáře vstoupil třetí spoluzakladatel, Tomáš Šavnický, který měl zkušenosti s rozpoznáváním řeči z VUT v Brně. Tito tři začali diskutovat o tom, co z toho vznikne, a rozhodli se to zkusit.

V té době jsem nastoupil já a společně jsme začali prototypovat, dali jsme dohromady první platformu. Použili jsme tehdy Google Speech Recognition API, ale zjistili jsme, že to je úplně k ničemu, nepoužitelné.

Navíc audiozáznamy z vězení byly technicky špatné kvality a obsahovaly různé přízvuky z rozličných regionů, což tehdejší technologie rozpoznávání řeči z roku 2018 nezvládaly.

Takže jsme se chvíli zastavili, nechtěli jsme pokračovat jen tak.

Ale nápad nám pořád připadal zajímavý, protože všichni víme, že v právnickém prostředí je přepis mluveného slova všudypřítomný – jak všichni známe z různých seriálů z právního prostředí, všichni mají diktafony a přepisují výslechy a rozhovory.

Takže jsme stále věřili, že je to dobrý nápad, máme dobrý tým a pojďme to zkusit.

Rozhodli jsme se zaměřit na pobočku státního zástupce na Floridě, kde měli velké množství audiozáznamů výslechů svědků, obětí a obžalovaných, ale neměli dost financí na ruční přepis všech těch záznamů, protože jsou to státní instituce.

Rozhodli jsme se jim tedy audio přepisovat zadarmo, přičemž jsme si ponechali práva k audiu a přepisům, abychom mohli na těchto datech budovat vlastní řešení pro rozpoznávání řeči.

Řekli jsme si, že když nefungují dostupné obecné nástroje jako APIčka, můžeme zkusit vytrénovat naše vlastní řešení zaměřené na tuto specifickou doménu.

Dále jsme iterovali dál.

Zajímalo mě, jak jste dále řešili přepis. Ty jsi říkal, že Google API bylo špatné. Měli jste stovky hodin audiozáznamů, takže jste najali nějaké kontraktory, aby to ručně přepisovali, nebo jak to fungovalo?

Na začátku to byl trochu experiment. Erikova kancelář neměla obrovská očekávání a chápali, že jde o testování technologie, takže to chvíli trvalo.

Od začátku jsme však tušili, že budeme potřebovat „humans in the loop“, tedy lidi, kteří budou opravovat chyby umělé inteligence.

První aplikace byla vlastně editor, do kterého jsme nahrávali přepis vytvořený AI a lidé jej manuálně opravovali právě v našem textovém editoru.

První tým jsme najali asi čtyři až pět full-time lidí v Praze, kteří seděli s námi v kanceláři.

My jsme pro ně postupně ladili editor, protože práce s tím byla na začátku opravdu náročná, technicky i uživatelsky.

Editor musel být synchronizovaný s audiozáznamem, aby bylo možné si přehrávat příslušné části a ověřovat si správnost přepisu.

Pokud by měli pouze dvouhodinové audio bez synchronizace, nedokázali by se v nahrávce orientovat.

Editor musel být dynamicky editovatelný a audio muselo být synchronizováno s textem.

První rok až dva až tři jsme tedy pracovali právě na tomto frontendovém editoru a zároveň jsme budovali vlastní systém rozpoznávání řeči.

Velká část byla má diplomová práce, na jejímž základě jsme tento projekt začali.

Pak už jsem začal pracovat v týmu s Jonášem, který je speech recognition expert.

Společně jsme na tom iterovali.

Jonáš má na to docela zajímavé vzpomínky, že to na začátku bylo dost punkové.

On přišel jako expert na rozpoznávání řeči a vzal si můj kód.

Já jsem při studiu pracoval na českém ASR systému a tehdy v roce 2018 prakticky neexistovala žádná veřejná data.

Na rozpoznávání řeči potřebujete audio a odpovídající přepis, který je potřeba správně zarovnat, aby neuronová síť mohla být správně trénována.

To tehdy neexistovalo, takže jsem napsal web scraper a stáhl jsem z Poslanecké sněmovny záznamy jednání, kde měli audio a přepis pro zákony a slyšení.

Systém jsem data vyčistil a připravil a vytvořil jsem poměrně pěkný dataset.

Ten jsem pak publikoval jako open source.

Na tomto datasetu jsem trénoval systém v toolkit Kaldi, což je tradiční speech recognition nástroj, používaný jako předchůdce end-to-end systémů.

S Kaldi se do té doby vyvíjely systémy založené na skrytých Markovových modelech a jiných přístupech.

Po nástupu do Perotu jsem mohl toto know-how dobře využít, jak při zarovnávání audio a text, tak při metodách rozpoznávání řeči.

Takže první roky v Perotu jsme stavěli právě na Kaldi, což je hybridní systém založený na převodu textu do fonetických jednotek.

Já jsem se hodně věnoval zpracování signálu a extrakci vlastností zvukových dat, například MFCC koeficientů.

Základním modelem byla skrytá Markovova modelová logika, která zarovnávala fonémy na jednotlivé zvukové vlastnosti.

Tato metoda připravuje data pro neuronovou síť, která pak trénuje na tomto zarovnání.

Je to tedy hybridní systém, který ve svých začátcích relativně dobře fungoval na naše data.

Hybridní přístup je výhodný, pokud máte relativně málo dat, protože HMM model pomáhá s bootstrapováním tréninku.

První řešení pro kancelář Erika bylo tedy postavené právě na Kaldi.

Později jsme pokračovali ve vývoji směrem k end-to-end metodám, které se začaly objevovat.

My jsme svůj systém výrazně vylepšovali.

Zajímavé bylo, že jsme měli výhodu spousty doménových dat.

Jak Jonáš zmínil, čím lepší jsou data pro Kaldi, tím lepší výsledky získáváme.

Proto jsme na začátku najímali kontraktory z marketplace pro přepis, ale také jsme měli samostatný tým anotátorů.

Při přepisování textu pro soud je důležité, aby byl relativně čistý. Když někdo řekl například „aha“ nebo jiné nepotřebné zvuky, tam se tyto elementy nepřepisují.

Ale pro trénink AI na rozpoznávání řeči je potřeba mít tak přesný přepis, že každá hláska je zahrnuta.

Tyto přepisy je pak třeba rozdělit na krátké úseky zhruba 10–15 sekund a zarovnat je s úspěšností na desítky milisekund.

Proto jsme vytvořili speciální platformu, kde jsme měli tým asi pěti až deseti anotátorů, kteří následně upravovali přepisy z právního prostředí do podoby vhodné pro trénink.

Tímto způsobem jsme začali vlastně stavět vlastní dataset.

To byl velký poznatek: mít vlastní tým anotátorů in-house.

Zkoušeli jsme také outsourcovat přepisování a anotaci dat externím společnostem, včetně velkých firem jako Scale AI, ale kvalita a přesnost nebyly pro nás dostatečné.

Od začátku až do dnes tedy máme vlastní tým pro anotaci dat.

Nejprve se věnovali anotaci pro rozpoznávání řeči, neskôr už připravovali data i pro sumarizace přepisů lékařských zpráv a dalších produktů.

Data jsou tak od začátku naším tajným receptem v Perotu a nyní v FileVine.

Jak jste měřili kvalitu a přesnost? Používali jste nějaké standardizované metriky, nebo to bylo čistě závislé na konkrétní doméně?

To je dobrý přechod právě k metrikám.

Historicky je to pro nás vždy velké téma.

Myslím, že v oblasti výzkumu funguje hodně jinak než v praxi, kde jsme se to museli naučit tvrdou cestou.

V rozpoznávání řeči jsou běžné metriky jako word error rate, tedy míra chyb ve slovech, a pro diarizaci mluvčích diarization error rate.

Tyto metriky slouží jako jakási severní hvězda, ale ne vždy reflektují kvalitu vnímání člověkem.

Máme koncept doménových slov, což jsou například jména lidí, produktů, geografických lokalit a podobně. To jsou často specifické jednotky slov v celém přepisu.

Všeobecná metrika word error rate toto nezachytí.

Text pokračuje.

Když já zkomolím jméno toho právníka hned v první větě, tak může být celý přepis správný, ale vlastně ta nepříjemná pachuť v ústech zůstane. Proto jsme vlastně pak museli z těch přístupů buď nějak upravit metriky, nebo jsme si dokonce vyvinuli úplně vlastní metriky, které více korelovaly s tím, co jsme od těch systémů skutečně chtěli.

Například u speaker diarizace je to zajímavé. U soudních jednání je spousta otázek, na které se odpovídá ano/ne, tedy velmi rychle, zhruba půlsekundovou odpovědí. To je poměrně těžká predikce pro diarizační systém, aby zachytil, že například půl vteřiny mluvil někdo jiný a pak nastoupil delší úsek, třeba otázka. Ta akademická metrika to obvykle panelizuje tak, že pokud je někde půlsekundová chyba, považuje to za nulovou chybu. Ale pro právníka je to ohromný problém: jestli mu tam napíšeme, že přeskočíme tu část, nebo jestli to opravdu detekujeme.

Proto jsme si vyvinuli vlastní metriky, které jsme použili pro benchmarkování a které pak i v dalších AI aplikacích lépe reflektovaly požadavky klienta. Pokročili jsme v tom tak, že jsme se opravdu snažili uvažovat z pohledu klienta, co od toho chce, a podle toho nastavili metriky, aby co nejlépe odrážely realitu.

Kdy vlastně začalo toto fungovat? Kolik přepisů jste museli pro představu nadspat? Stovky, tisíce? Záleží, co znamená, že to začalo fungovat, protože je to celé spektrum. Možná spíše lidský test toho právníka, když se na to podívá, už bylo lepší.

Myslím, že první systém, který jsme měli založený na Kaldi, měl zhruba 100 hodin audio dat, pokud si správně vzpomínám. Od té doby to jen rostlo. Pak jsme naskočili na trend v hlubokém učení, kdy sekvence problému řešily nejdříve obrázky, potom text (například GPT, transformery, BERT) a až pak řešení řeči trochu zaostávalo. Ještě kolem let 2018–2019 se používal Kaldi, což byl tradiční přístup, ne end-to-end.

Kolem roku 2020 přišla aplikace, kterou nazývali CTC LOSA, která umožnila trénovat neuronovou síť end-to-end – tedy přímo z audio signálu na přepis. Problém byl, že sice máme deset sekund audia a odpovídající text „Jmenuji se Jonáš Kratochvíl“, ale nevíme, jak přesně je ten text mapován na části audia. Tento problém zarovnání řešil Kaldi pomocí HMM, tedy před samotným tréninkem, zatímco CTC umožnil trénink neurónky end-to-end.

To otevřelo spoustu možností. Dlouho se používala konvoluční architektura Quartznet od NVIDIA, která vydala celý toolkit Nemo. Architektura se nám velmi líbila, a proto jsme ji částečně použili (zkopírovali designové vzory) a vytvořili jsme vlastní knihovnu nazvanou Omen, což je Nemo napsané pozpátku.

Tato knihovna se používá dodnes v našich přepisech soudních výpovědí. Takže jsme šli s trendem a později se objevil další milník ve speech recognition, a to předtrénované modely. Proběhl pre-training, kdy první takový model byl Vav2Vec od Facebooku (Meta).

Byl to v podstatě první model podobný BERTu – transformer encoder, upravený na zvukové signály, kde se pomocí maskovaného učení predikovaly části audio signálu reprezentované jako diskrétní bity. Tento model byl možné natrénovat bez dohledu (unsupervised) na obrovském množství dat – myslím, že asi 300 tisíc hodin.

To pro nás byl obrovský skok, protože jsme použili předtrénovaný encoder, napsali vlastní decoder a mohli model doladit na naši doménu.

Mimochodem se v Meta ukázalo, že jsme měli velký problém s akcenty, jak jsem již zmínil. V soudních jednáních jsou často velmi specifické akcenty, protože lidé mluví různými dialekty, navíc jsme působili ve Spojených státech prakticky v různých státech s různými akcenty. Ukázalo se, že nejlepší, co jsme našli, byl multilingvální enkodér, ne ten původní anglický vastuvek. Tento multilingvální checkpoint obsahoval asi 120 jazyků a tato multilingválnost pomohla modelu lépe chápat akcenty a po doladění na anglických datech tam toto „vědění“ zůstalo.

Byl to opravdu zajímavý efekt, který dával smysl i v metrikách. Takže jsme začali s multijazyčným základem a pak jsme doladili na angličtinu, což bylo logické, přičemž evolučně by asi fungovalo i opačně – mít angličtinu a poté doladit na různé akcenty.

Z pohledu startupu a produktu – kde jste byli? Na začátku jsi říkal, že začali jste s jail calls (telefonáty z vězení), což byl úplně první nápad, pak jste přešli na soudní jednání a výpovědi – depozice. Předpokládám, že už to tehdy bylo produktivní, nepoužíval to jenom bratr jednoho ze zakladatelů, ale měli jste nějaké klienty?

Ano, nějakou dobu jsme byli na jednom jediném klientovi, konkrétně Special Victims Unit (jednotka speciálních obětí). Před časem mi někdo připomněl, že celý seriál se jmenuje právě Special Victims Unit, což jsem si nikdy nespojil. Byli jsme s nimi asi dva až tři roky.

Později jsme si uvědomili, že tam není příliš byznysu – klient měl zájem, ale nebyl to zavedený byznys. V té době ještě nebyly depozice tak rozšířené. Special Victims Unit pracovali s velmi specifickými případy týkajícími se zneužívání dětí, což vyžadovalo speciální nastavení, včetně psychologů.

Máme trošku tragikomickou historku: protože v těchto případech se často mluvilo o intimitních a nepříjemných tématech, náš ASR byl za nějakou dobu schopen náhodně „nadávat“, tedy generovat vulgarismy, i když v audio vůbec nic takového nezaznělo.

Podpora nám chodila ještě další 3–4 roky i při práci na depozicích s požadavky, aby vulgarismy v přepisech odstranili, protože klient je nechtěl vidět. Naše AI byla traumatizovaná.

Nakonec jsme nasadili profanity filtry, které jsme hardcodovali: kdykoliv se nějaké zakázané slovo objevilo, rovnou se odstranilo z přepisu. Čas plynul a bylo to funkční.

Během té doby jsme ještě neměli žádný byznys, ale postupně jsme si uvědomili, že musíme přijít s něčím jiným.

Pak jsme si uvědomili, že existuje něco jako court reporting nebo stenografické přepisy, což u nás není běžné, ale v amerických soudních síních je to standardní.

Pokud posluchači viděli nějaký americký soudní film či seriál, znají ty dámy, které vše píší v reálném čase na speciální strojky. Je to dobře zavedený byznys model v USA.

Tyto stenografky mají své soutěže, kdo přepisuje nejrychleji a účastní se i různých pořadů, kde přepisují rap stejně rychle, aby ukázaly svou dovednost.

My jsme si řekli, že jejich průmysl bychom mohli disruptovat, protože je to extrémně drahé – jedna hodina depozice stojí klidně tisíce dolarů.

Další problém je, že mají velmi špatnou demografii: průměrný věk stenografek je kolem 50–60 let a ony se stále drží svého způsobu práce a nechtějí přijmout technologii, i když se k disruptu blíží.

Začali jsme na tom pracovat. Právě v tomto čase udeřil COVID a vše se přesunulo do vzdáleného režimu, což nám velmi pomohlo.

Nám totiž už nebylo třeba jezdit do soudních síní, protože se všechna jednání přesunula na Zoom a další online platformy.

My se mohli jednoduše připojit a začít přepisovat.

K tomu jsme museli změnit i produktový přístup, protože zatímco při běžné transkripci jsme měli systém s lidskou kontrolou (Humans in the Loop marketplace), u court reporting jsme potřebovali postavit další systém.

Stenografky, kromě přepisu, totiž dělají i notářské ověření – musí být certifikované, aby potvrzovaly, že přepis sedí s tím, co bylo řečeno.

Proto jsme vytvořili další marketplace notářů, kteří opravy AI přepisu kontrolovali a potom se připojili vzdáleně na začátku přepisu složili slib a na konci celý dokument opatřili notářskou pečetí.

To už byl skutečný byznys model, který mohl mít zákazníky, a tak se to začalo rozjíždět.

Jeden z prvních klientů byla velká pojišťovna v USA, jedna z pěti největších.

Takto se celý byznys rozjel.

Mám na to i vtipnou historku: mysleli jsme si, že máme pevný termín začátku v lednu, ale pořád jsme neměli funkční speaker diarizaci. Už se blížily Vánoce.

Já jsem tehdy ještě pracoval v týmu strojového učení a kódil s nimi, takže jsme celé Vánoce prakticky zrušili a snažili se dodat funkční diarizaci.

Pamatuji si, jak jsme byly u babičky 25. prosince, já jsem tam rozložil počítač a pracoval na tom.

Jonáš nakonec po Vánocích našel dobrý model z Brna, který fungoval velmi dobře.

Co je diarizace? Je to vlastně speaker segmentation, tedy úloha, kdo mluví kdy v audio nahrávce.

I když to zní jednoduše, jde o velmi obtížný problém z pohledu strojového učení.

Je to jedna z nejtěžších technických výzev, které jsme zatím řešili.

Pokud se dostaneme zpět k příběhu, předpokládáme, že nyní do těchto úloh pronikají i velké jazykové modely (LLM), a zdá se, že je řeší možná nejlépe.

Nakonec to však s klientem dopadlo dobře – Jonáš to vyřešil o Vánocích, ale zákazník nastoupil až v červnu nebo červenci.

Učili jsme se, že enterprise zakázky trvají déle.

Od té doby jsme získávali další klienty a budovali provoz okolo celého court reporting modelu.

To vyžadovalo hodně backoffice, protože původní court reporteři vše vyřizovali po telefonu nebo e-mailem a my potřebovali systém, který umí tento Uber-like rozbitý byznys model škálovat.

Měli jsme tedy dva marketplace a silný operations tým, který to celé koordinoval.

Poté jsme se snažili budovat různé automatizace, ML a AI produkty, o kterých můžeme také hovořit.

Co se týče technologií – probíhají fundamentální změny.

První roky pro nás byly spíše zkoumání a hraní si.

Dostali jsme obrovský AVS cluster se spoustou GPU, kde jsme trénovali, ladili a budovali knihovnu.

Nikdo nám nedával priority ani termíny, prostě jsme si hráli s ASR a ML.

V tuto chvíli jsme pivotoovali k court reportingu a začaly přicházet mnohé další výzvy.

Bylo potřeba, aby systém škáloval, a řešili jsme problémy nad rámec samotného rozpoznávání řeči, například diarizaci, ale také postprocessing.

Výstupní text z ASR je totiž pouze prostý text v malých písmenech bez interpunkce.

Museli jsme tedy naimplementovat postprocessing, který doplní interpunkci, velká písmena a opraví další zvláštnosti.

Já jsem tehdy v týmu ML začal psát takzvaný rough draft pipeline – to je AI výstup přepisu, který pak chodí k lidem na opravu.

Začali jsme využívat všechny možné výhody, které jsme mohli získat, a zakomponovat je do systému.

Naší filozofií je vždy urvat jakoukoliv výhodu a využít ji.

Například jsme zavedli aktivní učení (active learning loop), kdy AI vygeneruje přepis, který pak projde lidskou opravou, a výsledkem je téměř 100% přesný přepis.

Z hlediska strojového učení je to velmi silná věc, protože lze snadno spočítat rozdíly a metriky kvality.

Zde jsem přepsal zadaný text do spisovné češtiny, zachoval jsem kompletní obsah a význam, rozdělil text do odstavců a opravil gramatiku i stylistiku. Pokud budete potřebovat, mohu pokračovat s další částí nebo upravit text dále.

Nějaké atributy můžeme přiřadit k částem té pipeline, můžeme provést nějakou analýzu chyb a vlastně přimíchat zpět data do tréninku. Takže tehdy jsem myslím viděl nějaký talk od Andreje Karpaty, ještě když byl v Tesle. Oni vlastně podobný loop udělali v Autopilotu, kdy když řidič zatočil doprava, ale neuronová síť řekla, že má zatočit doleva, tak to byla určitá anomálie a v tom loopu to zpětně vložili do tréninku a pak provedli auto deploy. To byla nějaká inspirace, protože ten use case máme hodně podobný, takže něco takového by bylo skvělé. Slováci to prostě umí. Přesně tak.

Byla v tom veliká alchymie, protože člověk nemůže brát jenom ty části, kde model chyboval a trénovat jen na nich, protože pak zase zapomíná to, co už uměl. Takže v data samplingu a v kategorizaci chyb je to opravdu složitá záležitost, ale uzavřít ten loop a neustále trénovat se vyplatí.

My jsme třeba čtyři roky v kuse trénovali naše modely, pořád jsme měli jeden checkpoint, jeden start point, který jsme postupně restartovali z různých pozic na nových datech a tak dále, takže to byl vlastně jeden velký celek.

Druhým zajímavým aspektem, který jsme využili, bylo, jak říkal Tom, na deposition seděl náš člověk - court reporter. My jsme ho nazvali digital court reporter, protože už pracoval na dálku, připravoval oficiální zápisy a podobně, ale vlastně byl většinu času nevyužitý. Téměř 95 % času tam jen seděl. Říkali jsme si, že to nemůžeme ponechat takto, musí tam něco dělat.

Takže během deposition jsme měli vlastní live transcript, takže uživatel v reálném čase viděl přepis. Používali jsme stejný end-to-end speech recognition (ESR), který jsme pak využívali i v rough draftu.

Měli jsme algoritmus, který detekoval slova s nízkou jistotou v live streamu a nechával tyto slova opravovat právě u našeho court reportera. Pak jsme seznam opravených slov zpravidla dávali do rough draft pipeline. Tam jsme prováděli fuzzy matching výstupů live streamu, protože live stream funguje na jednom kanálu, takže kvalita je mnohem horší než v rough draftu, kde jsme měli individuální kanály pro jednotlivé mluvčí.

Využívali jsme tak opravená slova jako například jména lidí, názvy produktů, lokalit a podobně, což výrazně zlepšovalo perceived quality, o které jsme mluvili.

Pipeline se výrazně proměnila také po stránce infrastruktury. Přešli jsme na Argo Workflows, což byl velký posun i pro mě, ale také pro ML tým. Umožnilo nám to end-to-end řídit rough draft pipeline definovanou v rozsáhlém YAML konfiguračním souboru, která se exekuovala na Kubernetesu. Jako ML inženýři jsme tak mohli modifikovat libovolnou část pipeline, což jich bylo asi deset až patnáct, což působilo jako zásadní posun v možnostech, co jsme byli schopni dělat.

Řešili jsme i paralelizaci, protože pro některá SLAčka jsme potřebovali mít konstantní dobu zpracování bez ohledu na délku audia - tedy aby úloha na desetiminutovém i pětihodinovém záznamu byla dodána ve stejné době. To přineslo speciální infrastrukturaálně-technické výzvy, které bylo třeba vyřešit.

Snažili jsme se vytvořit systém všeobecného přepisu (transcription), ale zároveň nejlepší AI přepis pro depositions. Měli jsme rozsáhlý seznam pozorování o tom, co se v deposition skutečně děje, co nikde jinde nenajdete, a pár příkladů.

Například díky tomu, že jsme to kompletovali přes Zoom, měli jsme separátní audio kanály pro každého mluvčího, což nám výrazně pomohlo, protože jsme eliminovali cross-talky. Ne vždy, protože někteří účastníci se připojili ze stejného počítače, a pak jsme měli speciální systém, který se snažil cross-talky vyřešit.

Podívali jsme se i na obsah deposition, které vždy sledují podobnou strukturu. Například na začátku court reporter představí datum, čas, uvede, že se sešli kvůli danému případu s příslušným číslem, kdo přišel, a pak jednotliví účastníci postupně představují sami sebe.

Proto jsme například na začátku použili NLP-based diarizaci a segmentaci mluvčích. Pokud přepíšeme prvních pár minut audia a pošleme to například do LLM (nebo někam jinam), ono z textu dokáže rozsegmentovat jednotlivé mluvčí, a to bez nutnosti poslouchat audio. To byl další zajímavý hack a use case.

Pokud se do deposition připojí překladatel, například svědek mluví španělsky, musí tam být někdo, kdo to překládá. Víme, že pořadí mluvčích je vždy něco jako právník klade otázku, překladatel do španělštiny, svědek odpovídá ve španělštině, překladatel zpět do angličtiny a tak dál. Tato informace se může natlačit do systému a hardkodovat, aby se zvýšila přesnost přepisu.

Bylo toho hodně a nyní čekáme, jak dlouho ještě budeme mít nejlepší AI řešení pro transcription deposition, než nás předběhnou velké obecné modely, které zatím bez ohledu na kontextuální informace začínají být konkurenceschopné.

Ještě než se dostaneme k nástupu DNAI a k otázce, kterou část kódu to znamenalo vyměnit za out-of-the-box modely, jak říkal Jonáš, kdy došlo k posunu z výzkumného a akademického režimu do produktového a byznysového, ale hned od začátku jste měli frontend a tržiště.

Pokud se podíváme z pohledu architektury, bavíme se hodně o tom "Magic Sauce", o AI uvnitř a o tréninku modelu. Jak vypadala platforma, jaké byly jednotlivé moduly, kolik jste měli front-endů, kdo byli uživatelé?

Nejde jen o produkt Speech-to-Text, ale o celou platformu. Musím si představit, že tam bylo hodně různých komponent. Lze říci, že to byl spíše front-end heavy systém, protože bylo mnoho typových uživatelů.

Mezi klienty jsme měli několik person, například schedulery – tak se oni opravdu jmenují, jejich pracovní pozice je scheduler. Jejich práce je plánovat deposition. Potřebují tedy celý management deposition, file system, kalendář, UI pro plánování – to je jedna část platformy.

Druhá část byla pro právníky, kteří zase více pracovali se samotnými přepisy, když byly dostupné v aplikaci.

Pak byly marketplaces, což byly separátní aplikace pro notáře, přepisovače a back office. Zjednodušeně jsme do určité doby využívali Django pro frontend i backend a ML heavy workflowy. Nejsem si jistý, v čem to přesně běželo tehdy. Nyní běží v Temporal. Argo workflows sloužil jako backbone infrastruktury.

Celý deep learning stack je postaven na PyTorch, což platí tehdy i z části dosud.

Teď pojďme k fenoménu – transformery a velké jazykové modely (LLM). Když přišly multimodální modely a speech recognition začal dohánět transformery, kdy jste začali nahrazovat vlastní moduly dostupnými obecnými modely? Co to pro vás znamenalo?

Myslím, že ještě předtím, než jsme se dostali k generativní AI v rozpoznávání řeči, jsme začali zkoumat generativní AI v jiných produktech. Náš tým, jak jsem uvedl, vybudoval celou platformu, která byla hlavním rozdílem oproti Core Dripporterům – Core Dripporter dá jen PDF přepis, to je celé. My jsme měli celou platformu.

Ještě u PDF – PDF se stále odesílá na soud, ale my máme platformu, kde je audio synchronizované s přepisem, takže lze kliknout na jakékoliv slovo a přehrát audio od toho místa. Přepisy sumarizujeme – to byl náš první případ použití Gen.AI a LLM, nebo to bylo asi nejvíce zřejmé.

Právníci sami shrnují přepisy, zvláště pokud jde o důležité deposition, a mohou strávit až osm hodin sumarizováním hodinového či dvouhodinového výslechu, takže to pro ně byl obrovský časový úsporný nástroj.

Budovali jsme také semantic search, kde jsme hodně experimentovali s LLM.

Co se týče speech recognition, tedy přímo LLM Gen.AI modelů, začínáme je zkoušet až nyní.

V určitých částech té raw draft pipeline, jak jsem ji popsal – od audia k AI přepisu – jsme začleňovali nejnovější vylepšení.

Například v post-processingu, který dostal výstup ASR a přidává interpunkci, čísla a další – tam hezky vidíte vývoj codebase. Nejprve to byl asi tisíc řádků pravidelného systému, pak jsme natrénovali Bertinův model, pak jsme používali LAMU asi rok a nyní jsme to nahradili modelem typu Sonet nebo něco podobného.

Iterace je jasně vidět.

V oblasti speech-to-text je hodně zajímavý poslední model Gemini 2.5 pro, který přináší slibné výsledky.

Není to ale černobílé, že by šlo jednoduše nahradit všechno. Pozorujeme, že Gemini funguje nejlépe na kratších úsecích, řekněme do deseti minut, kdy se dokáže dobře zaměřit na audio a je velmi přesný.

S delším audiem se kvalita degraduje, což je trend u LLM obecně – čím větší je kontext, tím spíše klesá přesnost.

Proto je potřeba audio segmentovat a vyřešit mapping mluvčích, protože aktuálně nejde jednoduše rozpoznat, zda speaker 0 v prvním segmentu je stejný jako speaker 0 v segmentu posledním.

Gemini neumí moc přesně timestampy, proto používáme externí systém, který dává word-level timestampy a zajišťuje audio alignment.

Je vidět, že trendy určitě směřují tímto směrem.

My máme filozofii, že se nebojíme vyhodit staré a použít to, co dává nejlepší výkon.

Ať už máme k pipeline emocionalní vazbu, sledujeme to aktivně.

Snažili jsme se od začátku stavět systém ve "krabičkovém" módu – pokud je naše custom ASR model, stále tam máme záložní krabičku, která volá nějaké API a dají se vzájemně přepnout.

Post-processing, který zmínil Jonáš, je další krabička, která může zůstat, pokud pomáhá GNAI modelům.

Systém je tedy modulární a klidně se krabičky mohou postupně měnit.

Možná naivní otázka: pokud byste nyní krabičky nahrazovali, například byste dali GNAI Gemini 2.5 model, vyměnilo by se třeba 70 % krabiček, 50 % nebo méně? Zajímá mě, jak to vy vidíte – jestli má smysl stále investovat do současného řešení, nebo raději vše nahradit hned.

My jsme teď v takovém stavu, že jsme byli hodně lean startup – měli někdy jednotky lidí, v nějakém píku maximálně tři, když jsme ještě byli Perot.

Prioritizace byla tedy zásadní.

Rough draft pipeline jsme dostali do slušného stavu, pak jsme ji nechali asi rok až rok a půl běžet na autopilotu, protože jsme úplně pivotovali do dalších věcí. K tomu se ještě dostaneme.

Nyní po akvizici a s velkými plány FileVine pro deployment do všech padesáti států USA platformu kompletně přehodnocujeme.

Myslím, že je realističtější možnost postavit nové krabičky z Gemini modelů od základu.

Samozřejmě tam jsou výzvy, o kterých jsem mluvil, ale v těchto dnech to aktivně zkoumáme, zjišťujeme, co to dá, jestli jen část nebo celou.

Určitě je reálné, že to celé přepracujeme.

Jonáši, ty jsi zmínil FileVine, tak se dostáváme k vašemu úspěšnému exitu, akvizici FileVine na začátku tohoto roku.

Jak to s Perot vypadalo loni? Kam jste se dostali? Co vlastně FileVine kupoval?

Core business, core reporting jsme dotáhli do fáze, kterou lze popsat i čísly: mezi našimi klienty bylo pět největších amerických pojišťoven. To byl asi největší byznysový úspěch. Dále jsme měli další větší i menší právnické firmy.

Minulý rok byl zajímavý hlavně tím, že jsme se začali vzdalovat od core reportingu a začali jsme zkoumat, co dalšího bychom mohli dělat.

Core reporting šlo škálovat a expandovat, ale s těmito klienty, kteří používali náš software, jsme si mysleli, že je v tom větší skrytá hodnota – možnost stavět další produkty a integrovat je, protože core reporting deposition je jenom část soudního procesu, která je spíše uprostřed.

Jinými slovy je to jeden krok, kde se sbírají důkazy formou usnesení.

Dále existují jiné procesy, kde se sbírají důkazy jinak, eventuálně se vytvářejí dokumenty, které se musí poslat soudu a podobně.

Začali jsme produktově přemýšlet jinak a hledat novou produktovou vizi, která nebude jen core reporting.

A ještě než budeš pokračovat, chtěl bych se zeptat, zda jsi už v tu dobu měl PM?

PM jsem měl v momentě, kdy jsme objevili core reporting, tedy to b...

Opravím a přepíšu text do spisovné češtiny s plným zachováním obsahu, bez vynechání či zkracování:

Ono hned na začátku, jak jsem popsal ten vánoční zhon, když jsme získali prvního velkého klienta, tak už to začalo být dost složité a já jsem si uvědomil, že mě vlastně celkem baví organizovat a orientovat se v tom a pomáhat ostatním týmům. Že Jonáše musíš porazit v jiném oboru než strojové učení a zpracování řeči. V tom jsem neměl šanci. Takže tehdy jsem nechal Jonáše u ML a já jsem se začal věnovat produktu, což bylo několik let – chord reporting a hodně operací kolem toho.

Minulý rok jsme začali zkoumat nové možnosti a dospěli jsme k nějaké vizi, kterou jsme popsali jako „Give Attorneys Information Advantage Against Their Opponents“, tedy pomoci právníkům zpracovat všechny informace v případu, aby dokázali vybudovat silnější argumentaci vůči svým protivníkům. A tehdy jsme začali vykonávat možná zajímavější produktovou práci. Začali jsme vybírat velké produkty a hledat, jaké nové funkce implementovat.

Jedna z prvních byla deposition summaries (shrnutí výpovědí). To byl docela úspěch. Byla to relativně jednoduchá funkce. Právníci jsou zvyklí mít shrnutí přibližně ve dvou formátech a my jsme je tehdy konsolidovali do jednoho – nazýval se page line. Celý transcript se rozdělí podle témat do menších segmentů, každý segment se pak separátně posílá do některého LLM (velkého jazykového modelu) na sumarizaci. Jednalo se o celkem jednoduchou funkci a nehrozily halucinace, protože se modelu posílaly pouze krátké úseky k sumarizaci. To byl první produkt, na němž jsme chtěli stavět.

Druhým produktem také souvisejícím s výpověďmi, ale už ne chord reportingem, bylo pomáhat rychleji zpracovávat transkripty. Jeden z problémů, kterým čelili, bylo často zbytečně dlouhé identifikování informací v transkriptech. V případě může být 5 až 10 výpovědí, každá může trvat dvě hodiny, a najít v nich konkrétní informace je složité. Takže se rozběhla naše technická mysl: Think Law Semantics Search. Začali jsme budovat semantické vyhledávání. Jonáš může více popsat technické řešení, myslím, že jsme tam vybudovali něco opravdu zajímavého. Ale tam nastal první velký „learning“. Technicky to bylo něco, na co jsme byli hrdí, ale nikdo to nepoužíval. To nás téměř zastavilo – náš první pokus o větší produkt nikdo nevyužíval.

Možná jsme si uvědomili, že lidé byli zvyklí na chatové rozhraní a chtěli hledat přes chat, v přirozeném jazyce, a tak dále. To byl podle nás ten důvod. Ale ten neúspěch byl skutečný.

Druhý produkt, na kterém jsme pokračovali, byly tzv. narrative summaries (narativní shrnutí), ne už tak strukturované page-by-page nebo line-by-line, ale několikastránkové vyústění ve formě příběhu. Zde jsme už byli poučeni ze zkušeností se semantic search projektem a přišli jsme s jednoduchým, ale chytrým řešením.

Vzal jsme si právníka, který nám připravil velmi pěkný příklad shrnutí deposition summary. To není úplně běžné shrnutí – když řekneš ChatGPT, aby zkrátil transcript nebo dokument, vznikne spíše obecné shrnutí. Právníci ale chtějí mít svoje právnické koncepty, konkrétní právní témata jako kdo tam byl, jaký sled událostí během dopravní nehody a tak dále.

A právě díky tomuto jedinému příkladu, který nám právník poskytl, jsme získali podle zpětné vazby klientů nejlepší depoziční shrnutí na trhu. To byl další moment, kdy jsme byli velmi brzy. V podstatě tehdy nikdo depoziční shrnutí nepoužíval. To byl velký úspěch.

Nevím, jestli Jonáš by se nechtěl vrátit k semantic searchu, protože tam bylo technicky hodně zajímavých věcí. Myslím, že to je pěkný příklad kontrastu.

Symetrické a asymetrické dotazy – uživatel zadává jen jedno či dvě slova. My jsme tam řešili hodně rozdělování bloků do frází, aby byla symetrie mezi tím, co embedujeme. Měli jsme tam rozšířenou entity recognition (rozpoznávání pojmenovaných entit). Pokud člověk chtěl hledat osoby, systém vybral jména jako Jonáš, Tom, prostě John a tak dále. To byla taková proxy embedding, tedy jakoby když se našla osoba, fetchlo to všechny lidi v transkriptu.

Byla tam také hezká evoluční pipeline. Jak říkal Tom, měli jsme na to hodně pravdu, ale nikdo to nepoužíval.

Druhým kontrastem byly narrative summaries, kde když to hodně zjednoduším, jsme zavolali nějaký cloudový model, dali mu ten nádherný příklad, ukázku transcriptu a řekli: takto chceme shrnutí. On to velice přesně a velice rychle replikoval pomocí one-shot promptingu. Všichni z toho byli nadšení a mělo to velkou odezvu.

Z pohledu inženýra to bylo trochu bittersweet, ale z pohledu produktu nám to ukázalo, že generativní AI je správná cesta.

Pak jsme pokračovali v hledání dalších příležitostí. Leadership byl už opatrný, do čeho investovat. Podařilo se nám objevit velmi zajímavou oblast lékařských zpráv. Velká část našich klientů byli personal injury attorneys, tedy právníci či právní firmy, které se zabývají případy úrazů. Většinou autonehody. Klasika, známá z amerických filmů – kdy člověk nosí týden nebo i měsíc tzv. dog collar na krk, protože soudí, že mu „pohnuli s páteří“, když ho někdo srazil na parkovišti.

Naším úkolem bylo vytvořit software, který právníkům pomůže zjistit, co se skutečně stalo, a zároveň dokazovat.

V takových případech je největším zdrojem důkazů lékařská dokumentace. Po určitou dobu pacient leží v nemocnici a právní firma od nemocnic či lékařů získává všechny lékařské zprávy. Jedná se často o tisíce stran dokumentů. Záleží na případu – měli jsme například případ s 20 tisíci stránkami dokumentů, které jsme museli shrnout, což zabere strašně moc času, protože data jsou špatně zpracovatelná.

Jak to známe od nás, tak to vypadá podobně i v Americe – jsou tam ručně psané poznámky, tabulky, diagramy a podobně. Tento produkt jsme viděli jako obrovskou příležitost.

Postupně jsme tento produkt představovali naší vedení, které bylo ze začátku hodně skeptické, protože šlo o obrovský skok od chord reporting a deposition summaries ke zpracování lékařských zpráv.

Já jsem tomu ale opravdu věřil, protože se jedná o velký průmysl. Dosud to fungovalo manuálně, existovaly služby, které takové shrnutí tvoří lidi ručně. My jsme viděli potenciál generativního AI.

Při jedné příležitosti jsem byl v Praze na meetupu, kde jsem mluvil s další firmou, DevStudio, která pracovala na podobném projektu. Ujistili mě, že je to stabilní trh, který stále roste, že z toho žijí poslední tři roky a nevypadá to, že by to vyprchalo.

To mě povzbudilo – oni si za dva týdny vybudovali prototyp. My jsme se chtěli také pustit do prototypu a i když jsme ho sice vytvořili za dva týdny, pak jeho nasazení trvalo další rok.

Leadership jsme stále neměli zcela přesvědčený, ale Jonáš a já jsme tomu opravdu věřili, takže jsme aspoň okrajově postavili prototyp.

Podstatné bylo, že právníkům šlo hlavně o text, obsah a textové shrnutí, takže žádný kompletní produkt jsme nepotřebovali.

Bože, Jonáš! Jonášovi jsem sehnal pár stránek lékařských záznamů, které byly veřejně dostupné na internetu, což vůbec nemělo být, protože jsou to zdravotní záznamy s vysokými bezpečnostními standardy. My jsme ale v Perote měli HIPAA a SOC2 compliance, takže jsme na to byli připraveni, a bylo zajímavé, že nám to přišlo jako oblast, do které bychom se neměli dostat.

Jonáš za dva dny postavil prototyp, který jednoduše do Word dokumentu dumpoval shrnutí ve formátu, který právníci potřebují. Obvykle chtějí pro každou zprávu vyextrahovat datum, jméno lékaře, diagnózy, předepsané léky a základní sadu polí.

Představili jsme to několika klientům a byli úplně nadšení. Tak jsme v tichosti pokračovali s Jonášem ve vývoji a když jsme si mysleli, že to už je solidní, začali jsme získávat i vedení na svou stranu.

Prodeji to ale trochu nechápali a začali to prodávat, i když to vlastně nebyl ještě hotový produkt.

Stalo se to někdy v polovině minulého roku, kdy jedna z velkých pojišťoven – myslím, že můžeme zmínit Travelers – kteří už nás používali na chord reporting, právě v té době měli pilotní program na výběr AI dodavatele pro shrnování lékařských zpráv.

Pro nás to bylo buď se přihlásit a riskovat, že to nezvládneme, nebo se nepřihlásit a přijít o šanci na trh.

Problém byl v tom, že my jsme věděli, jak shrnovat, ale největší komplikací byla nutnost rozdělit obrovské dokumenty o 5000 stranách na jednotlivé lékařské zprávy, které bychom pak mohli zpracovat samostatně.

Tuto část jsme odkládali a říkali si, že to vyřešíme později. Nakonec jsme už ale produkt, kde splitting neexistoval, skoro začali prodávat.

A pak jsme zjistili, že právě dělení dokumentů je nejsložitější problém celého produktu.

Protože jsme si to uvědomili pár měsíců před podpisem smlouvy, museli jsme vytvořit další tržiště (marketplace) pro tzv. Humans-in-the-Loop, kteří to dělení dělali manuálně.

Měli jsme už hodně zkušeností z předchozích tržišť, proto jsme doslova použili starý kód a platformy.

Stejně jsme to pak aplikovali na nový problém, podobně jako když děláme transkripce, kdy se audio rozděluje na menší úkoly, které distribujeme paralelně více zpracovatelům, ti je vypracují a pak se výsledky sloučí a projdou review.

Dále jsme se snažili paralelně s ML týmem proces automatizovat, abychom kontraktory nemuseli mít, protože to jinak špatně škáluje.

Postupně jsme lidský přístup spojovali s AI tak, že kontraktorům jsme dávali návrhy z AI, pokud už jsme měli nějaké AI výstupy, kterým jsme věřili.

Hodně jsme pracovali s úrovní důvěry (confidence level) této AI.

Přejmenovali jsme proces z „annotation“ na „confirmation“, což bylo pro mě psychologicky lepší.

Nakonec vznikl zajímavý systém, který si definoval framework confidence levels – vždy jsme přiřadili každému predikci vysokou nebo nízkou důvěru.

Měřili jsme přesnost těchto confidence predikcí – chtěli jsme mít co nejvíce vysokých důvěr, ale simultánně sledovali, jestli jsou opravdu přesné a nezavádějící.

Vznikl tak dobrý systém, který se dal v ML světě ladit tak, že jsme si stanovili jasný požadavek: když něco označíme jako high confidence, musí to být opravdu přesné.

Poměr high confidence a low confidence jsme časem zlepšovali.

A tím pádem jsme nemuseli „vysoké“ predikce posílat lidskému ověření, jen nízké.

Díky tomu jsme získali systém, kterému jsme mohli věřit na základě testovacích dat.

Momentálně už lidské ověření nemáme, ale stále nejsme na 100% a přijímáme, že chyby budou, že jde o AI.

Dříve byl poměr 50:50, což klientům nemohlo být poskytnuto.

Proč je splitting tak složitý?

Když to řeknete takhle, zní to logicky: „OK, máme stránkové číslování, tak rozbijeme, když začne znovu 1.“

Ale není to tak jednoduché. Existují případy vnořených dokumentů (nested documents), kdy někdy jeden dokument končí na stejné stránce, kde začíná další – tzv. mid-page splitty, to bylo problematické pro celý pipeline.

Ukázalo se, že čím jednodušší bylo definovat pravidla, tím lépe model a i my jsme nad tím přemýšleli.

Z původních asi 20 vlastností (feature) dokumentu jsme dospěli k tomu, že existují přibližně dvě hlavní proměnné, které definiují rozdělení dokumentu.

Postupem času se učili a řešili nové případy – třeba když nebyly klasické lékařské zprávy, ale exportovaná data, jako tabulka, kde každý řádek či box obsahoval informace o jedné zdravotní návštěvě.

Datové vstupy velmi variovaly.

Také jsme řešili i data ohledně termínů – například datum podpisu a další.

Toto je přepis do spisovné češtiny s plnou věrností originálnímu obsahu, rozdělený do přehledných odstavců. Pokud potřebujete, mohu dále text upravit, rozšířit či shrnout dle vašich požadavků.

Datum služby – někdy je to doktor, někdy hlavní doktor, vedlejší doktor, někdy jen sestra. Čili jsme se do toho zamotávali čím dál hlouběji a vlastně jsme nějakou dobu, než jsme se opravdu cítili, že máme vydefinované role tak, jak by měly být, zpracovali několik stovek tisíc stránek, což byly právě hlavně dokumenty od těchto pacientů-cestovatelů. Postupně jsme pak začali otevírat platformu i dalším klientům; v té době jsme měli asi deset beta uživatelů-klientů.

Za prvních pár měsíců jsme nasbírali několik stovek tisíc stránek, které naši anotátoři, o kterých jsme mluvili dříve, ručně zpracovávali. Jejich hlavním úkolem bylo procházet veškeré lékařské zprávy a psát si poznámky – například když narazili na problém, kterému nerozuměli, označili to jako nevyřešené. Pořádali jsme také stand-upy nebo týdenní schůzky, kde jsme s nimi probírali, brainstormovali a řešili, jak na konkrétní problém reagovat.

Možná je dobré zmínit procesy na pozadí, tedy AI-pipeline. Tom zmínil, že začíná tím, že problém popíšeme – přichází k nám obrovský PDF dokument, který má několik tisíc stran. Ten je potřeba rozdělit na jednotlivé dokumenty, tzv. splitting problém. Dále je tam tzv. Trinity Extraction, tedy vytahování trojice údajů – hlavního data, nemocnice a doktora, který je za daný dokument zodpovědný. Pak následuje sumarizační krok.

Vstupní informace z lékařských záznamů jsou nesmírně rozmanité a pokrývají mnoho podoblastí medicíny – jsou tam léčebné plány, rentgenové snímky, laboratorní výsledky a tak dále. Každý podproblém má smysl přistupovat specificky, neřešit vše jedním jediným způsobem, ale zamyslet se nad tím, co přesně se v dokumentu řeší. K tomu je potřeba mít specifické instrukce a také vytvořit kolem toho nějaké hodnotící postupy.

Sumarizační krok byl doplněn o něco, co považuji za velkou inovaci, kterou jsme do systému přinesli a co prochází všemi našimi AI funkcemi – jde o verifikovatelnost AI výstupu. Pro klienty můžeme například říci, že pacient měl 82 let a vážil 150 kg – ale musí to mít možnost někdo ověřit. Proto je nutné každý fakt propojovat se zdrojovou informací.

Vymysleli jsme techniku, kdy ke každému faktu ve shrnutí přidělujeme hypertextový odkaz vedoucí do původního PDF, a to až na úroveň bounding boxu, tj. přesného vymezení oblasti. Když kliknete na odkaz, otevře se vedle zobrazení PDF, kde se klientovi rozsvítí uvedený údaj – například že pacient vážil 150 kg. Tím se dá fakt ověřit. Zároveň to znamená určitý grounding výstupů v jejich zdroji, což působí jako prevence halucinací modelu. Tedy tyto reference systematicky dodáváme.

Dále vytváříme tzv. overview, tedy celkový přehled lékařského záznamu, což je metashrnutí všech dílčích shrnutí. Jde o rychlou, narativní sekci, kde uživatel vidí, o čem se v dokumentech jedná.

Totéž děláme i pro pacienta jako takového – tedy jeho lékařskou historii, demografické údaje a podobně. Tyto informace se totiž téměř ve všech dokumentech opakují, a proto je nechceme opakovat v každém shrnutí zvlášť, ale deduplikujeme je do speciální sekce.

Pak jsme vybudovali celkové front-endové uživatelské rozhraní, velmi interaktivní. Klient může pomocí těch Trinity filtrů – tedy datumy, nemocnice, doktora – filtrovat a vyhledávat v medicínských datech. Pokud například zajímá jen nemocnice Motol v období od roku 2023 do 2024, může si nastavit příslušný subset relevantních dokumentů.

Máme i PDF exporty, protože se ukazuje, že právníci PDF soubory milují a potřebují je.

Než přejdeme dál, blížíme se k exitu – chtěl bych se zastavit u otázky bezpečnosti. Vy jste říkali, že máte nějaké certifikace, například SOC 2 a další. Co to znamená z technologického hlediska, z pohledu stavby architektury? Také protože do systému pouštíte trh s různě citlivými daty – zmínil jste rozdíl mezi opravdu citlivými daty a například litigantními depozicemi, nemocničními záznamy atd. Znamenalo to něco v tom, jak jste stavěli systémy, nebo co jste do nich museli přidat?

Určitě to jsou omezení, se kterými pracujeme denně. Není to tak restriktivní, jak by se možná mohlo zdát.

Například všichni velcí hráči v oblasti generativní AI jsou ochotni podepsat BAA (Business Associate Agreement) compliance kontrakty. Vyžadujeme, aby vše bylo na principu nulové retence – tedy když někam pošleme požadavek, aby oni data nikde neukládali a pouze nám vrátili odpověď.

Pro náš development máme vlastní cluster umístěný za New Yorkem, všechny data musí zůstat v Americe, nesmí ji opustit. Náš cluster má všechny požadované bezpečnostní balíčky, data nesmí z clusteru uniknout. V rámci tohoto bezpečného prostředí pak můžeme s daty pracovat, anotovat je a vyvíjet.

Musíme být tedy velmi opatrní a uvědomovat si, jaké technologie používáme, ale máme s tím již poměrně dlouhodobé zkušenosti. Například u nahrávek z depozic to bylo stejné – jsme zvyklí fungovat v takovém režimu.

Byli jsme compliant už od začátku, někdy v polovině naší časové osy jsme se rozhodli směřovat k těmto compliance normám. Hodně nám pomohla služba Vanta (tu VAMTA jste zmínil – myslím, že šlo o Vantu), což je služba, která pomáhá startupům projít procesem compliance. Naši platformní inženýři tak strávili hodně času tím, že správně nastavili všechna oprávnění pro každý systém, například všechny S3 bucket-y.

Pro některé části systému to znamenalo nutnost reimplementace. Například u rozpoznávání řeči jsme měli originálně nějaké zařízení, které nebylo HIPAA compliant, a proto jsme museli vytvořit zcela nový systém. Byl to téměř roční proces, během kterého jsme celý systém výrazně předělali a dostali do požadovaného stavu.

Přejděme nyní k Filevine – firmě, kterou jste několikrát zmínil jako své nové působiště. Zajímalo by mě, jak Perot zapadal do byznysu Filevine. Z toho, co jste říkal, mám nyní představu, že Perot je legal tech platforma s mnoha produkty, například pro oblast medicíny, medcron, depozice, školení reportů apod. Jak to pasuje do Filevine?

Filevine je oficiální systém záznamů (system of records), tedy platforma, kde právníci pracují. Jejich cílem je podporovat vše tak, aby právníci nemuseli platformu opouštět. V nejzákladnějších definicích to popisují jako systém 3D: documenty, deadliny a dollars. To znamená, že mají velké úložiště dokumentů, kde právníci organizují veškeré dokumenty ohledně svých případů, evidují si kalendáře, deadliny, různé schůzky.

Pokud advokátní firma pracuje současně na stovkách případů, přičemž každý z nich je v jiném stavu a je potřeba řešit různé úkoly, je to velmi komplikované sledovat.

Dále je důležitá složka dollars, tedy účtování hodin, což je pro právníky zásadní.

Velmi zjednodušeně řečeno, Filevine je platforma, kde právníci „žijí“, sledují tam komunikaci s klienty. Například nyní řeší integraci telefonních hovorů, aby právníci mohli volat přímo z platformy, a tyto hovory pak být automaticky přepisovány pro další práci.

Je to obrovský dataset z mnoha zdrojů.

Před zhruba rokem se Filevine rozhodl pokrýt i oblast depozic a soudního reportingu. Už měli produkt nazvaný DepoCoPilot, který se připojuje na depozici přes Zoom nebo telefon; všichni jsou v jedné místnosti a jejich systém nahrává a přepisuje depozici.

Vy sami jste takový produkt měli už dávno, ale oni navíc dělali real-time analýzu.

My jsme podobné funkce neměli, tedy nástroje, které analyzují depozici během jejího průběhu.

Filevine pomáhá právníkům sledovat další otázky a cíle, aby na nic nezapomněli, protože depozice jsou extrémně drahé – stojí spoustu peněz a času na přípravu.

Je to zajímavý produkt.

A v tomto prostoru jsou, už něco o tom vědí, mají zkušenosti. Rozhodli se, že chtějí pokrýt celý segment od reportingu až po depozice.

Dělali průzkum trhu a zjistili, že Perot přistupoval k řešení nejvíce inovativním a škálovatelným způsobem, proto se rozhodli nás koupit.

Oslovili vás, nebylo to tak, že byste se aktivně nabízeli?

Ne, myslím, že během posledního roku se řešilo financování, zda půjdeme vlastní cestou, respektive nevěřím, že by byla možnost být koupeni, ale Filevine tehdy aktivně vyhledávali firmu k akvizici.

Vy jste se s nimi už dříve vídali v rámci ekosystému?

Ano, o nich jsme věděli, protože měli podobný produkt na sumarizaci lékařských zpráv a brali jsme si od nich inspiraci.

Jsou velkým hráčem – mezi systémy záznamů a case management systémů jsou jedni z top několika.

Uvědomili si, že kupují nejen produkt a technologii, ale i celý AI tým v Evropě.

Nyní mají dva AI týmy – původní v USA a evropský tým, který jsme vybudovali zde – a hodně inspirace chodí právě z evropského týmu.

To není špatné, klukům z Čeměřic.

Říkáte, že měli Series E financování ve výši 400 milionů dolarů, takže je to jistý Unicorn, možná i Decacorn s hodnotou v řádu několika miliard dolarů.

Jak velký jste byli v době podpisu, jak velký byl Perot?

Nemohu mluvit konkrétně o číslech, ale byli jsme tým asi 40–50 lidí.

Filevine má nyní kolem 700 zaměstnanců.

Jsme jejich třetí akvizicí.

Takže z Perotu se stal Filevine.

Je to už více než půl roku, co nosíte nová trička. Co se letos děje? Jak probíhá integrace?

Osobně za sebe to mohu říct tak, že akvizice přišla pro nás v Evropě velmi nečekaně, zejména tedy pro nejbližší vedení. Prvních pár týdnů bylo hodně nejistých a možná až frustrujících, protože jsme nevěděli, jak vše dopadne.

S odstupem hodnotíme vše poměrně pozitivně.

Jednou z největších změn je, že naše produkty, hlavně v oblasti medicíny a depozic, byly velmi rychle a intenzivně integrovány do Filevine. Nezůstaly někde ve skříni, ale staly se vlajkovými produkty firmy.

Bylo to velice příjemné.

Na přelomu září jsme byli na konferenci v Salt Lake City, kde má Filevine své sídlo, což je jejich největší uživatelská konference.

Tam ty produkty prezentovali před asi 2000 lidmi.

Byl to pro mě emotivní zážitek.

Vše, co jsme tu vybudovali, je teď ve středu pozornosti v rámci Filevine.

Produkty mají nyní velkou podporu, stejně jako týmy.

Bylo nám schváleno navýšení počtu pracovníků.

Za posledních několik měsíců jsme v týmu vyrůstali.

Když jsme procházeli akvizicí, byli jsme v ML týmu jen dva – já a kolega Martin Salecký.

Nyní budeme koncem roku téměř 20 lidí.

Přidali se i američtí kolegové a ML organizace se tak znatelně rozrostla.

Byla to tedy jízda – jak s náborem, tak s organizací práce, roadmapami a expanzí.

Je fascinující vidět podporu od vedení.

Často za námi jezdí do Prahy a uvědomují si, jak cenný tým mají.

Je potřeba si ještě jednou uvědomit, že k datům nemáme jen dokumenty, ale veškerou komunikaci mezi právníky, jejich poznámky, kontakty, deadliny, kalendáře, události.

Tyto informace lze propojit a využít pro zajímavé AI aplikace.

Ještě jedna zajímavost – snaží se pokrýt věci, které jsou klíčové v právnické praxi.

Právníci často píší... (text zde končí).

Tento přepracovaný text je nyní zformátovaný, gramaticky správný a jazykově upravený do spisovné češtiny, přičemž zcela zachovává původní informace a význam.

Šlo jen o poznámky perem na papír, například i během výpovědí (depositions). A právě zkoumáme digitální pera, jak dostat i tyto psané poznámky k nám na platformu, abychom měli ještě jednu věc připravenou. Opravdu chceme mít všechny data.

Takže se vrátíš ke své robotice. Jak slyším, pero je jako statusový symbol právníka. No a pak budeš mít Apple pero.

Kluci, tak pojďte ještě udělat výhled do budoucna, co vás čeká nyní a v příštím období, co ve FileVinu. Jak třeba balancujete mezi P3 škálováním existujících produktů, které jste přinesli z Perotu, versus zaměřením na AI transformaci? Jak to teď vypadá?

Začali jsme se zaměřovat na většinu segmentů, které se týkají výpovědí (depositions) a základního zpracování zpráv (core reporting). Hlavním cílem je expanze do všech států USA, protože Perot neoperoval ve všech státech. Tam jsou opět další určité důvody týkající se compliance, protože každý stát má trochu jiná pravidla.

Tím, že je to obchodní model typu marketplace, jsou tam klasické problémy jako, jestli máme spíše poptávku nebo nabídku, takže na to jsme neměli dostatek zdrojů. Teď s Filevinem už ano a do konce roku bychom chtěli být ve všech státech, což je plán v oblasti court reportingu.

Co se týká výpovědí obecně, snažíme se court reporting více spojit s produktem Filevin deposition copilot a chceme tam přinést mnohem více umělé inteligence ve fázi přípravy na výpovědi. Protože deposition copilot většinou funguje tak, že si právník přichystá nějaké otázky, které chce, aby mu AI během výpovědi sledovala určitá cíle.

A právě to je ta nejdůležitější část, jak se připravit na výpověď, a v tomto bodě bychom to chtěli produktově propojit s datasetem, který ve Filevinu existuje, a chtěli bychom využít AI, abychom pomohli právníkům co nejlépe se připravit na výpovědi.

Je to vlastně velmi pěkné představit tak, že ve Filevinu jsou stovky tisíc už třeba uzavřených případů, a právník ví, kdo byl soudce v daném případě, jaké argumenty byly použity, jaké bylo řešení, a například v rámci přípravy na výpověď může vidět: „Mám tu soudce Johna a mám nějaký profil toho mého svědka.“

Takže nevím, jestli je to nějaký třicetiletý gangstr a je potřeba optimalizovat strategii tak, aby třeba na soudce Johna fungovaly specifické argumenty, jakým způsobem s tímto svědkem komunikovat, jak strategii nastavit, aby člověk dostal odpovědi právě od tohoto svědka.

Na druhou stranu sedmdesátiletá babička asi bude chtít trochu jinou strategii. Takže vlastně začít se tím „hrát“ až gamifikací toho systému je docela velmi zajímavé.

A pokud jsme už několikrát mluvili o datasetu Filevinu, jak nad tím teď přemýšlíme a co tam vlastně budujeme, je to, že dosud i Perot a vlastně i Filevin hodně nahlížely na ta data nezávisle. Dostanou dokument, zpracují ho, uloží třeba do vektorové databáze, ale ten případ je obrovský kontext a vše se týká jedné věci.

V podstatě chceme vybudovat takovou ontologii, takový knowledge graph, kde uvidím: tady jsou relevantní lidé, to jsou jejich atributy, takto jsou propojení, takto časová osa, a vlastně vnímat celý případ v kontextu.

A tato knowledge graph bude základem, nad kterým budou stát všechny downstream AI funkce. Ať už je to AI asistent, se kterým si mohou povídat a doplňovat informace, nebo je to medcron, který už může propojovat kontexty i s jinými daty, či copilot, který v reálném čase poslouchá výpověď a říká například: „Hele, počasí nesouhlasí s tím, co policista napsal v policejní zprávě,“ protože přes ontologii jsme schopni rozpoznat, že jde o stejnou informaci.

Právě tato fundamentální datová struktura, kolem které je Filevin vystavěn, je velké téma a chceme na ní budovat i další produkty.

Co se týká týmů, z části se chceme věnovat deposition score reporting a AI v této oblasti, a na druhou stranu tým, který pracoval na medcronu, začne vyvíjet novou organizaci, která se bude obecně věnovat AI pro případy (cases) obecně.

Držíme vám moc palce. Moc děkujeme, že jste nás provedli touto úspěšně uzavřenou kapitolou Perotu, dalším startupovým úspěchem. Přejeme vám, aby se vám podařilo co nejvíce věcí rozjet a posunout pomocí umělé inteligence a dostat Filevin do AI doby.

Ještě jednou moc děkuji za návštěvu a těším se na příště. Také děkuji a přeji mnoho dobrých hostů.

Děkujeme, že jste doposlouchali až sem a děkujeme také našim partnerům a členům Data Talk klubu. Jsou jimi Intex, Saska, Bistreet, Colors of Data, Revolt BI, Good Data, Kebula, Emark, Karl Data Company, Datamind, Notino a Flo.

Pokud chcete zůstat v obraze, co se týče české datové scény a globálních datových technologií, nezapomeňte se zaregistrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data!