Podstatnou část své práce věnuji tomu, abych se vyznal v tom, co se v AI mění. Pro klienty z toho vybírám postupy a nástroje, které mají smysl pro jejich konkrétní situaci: co už stojí za vyzkoušení, co může ušetřit práci a kde je rozumnější ještě počkat.
Nabízím dva balíčky za fixní cenu a vedle nich dlouhodobou spolupráci. Pracuji remote a obvykle na více projektech souběžně, což považuji spíš za výhodu než za omezení: člověk, který pomáhá rozvíjet několik různých AI systémů, poznává vzorce, které se zevnitř jedné firmy vidět nedají, a nemá důvod hájit rozhodnutí, která tam padla před jeho příchodem. Právě proto nabízím review AI řešení, a v dlouhodobé spolupráci navíc odpovědnost za jeho architekturu, ne jen kapacitu dalšího vývojáře v týmu.
Rozsah, potřebné vstupy a termín se u každého balíčku domlouvají předem, protože závisí na tom, kde vede hranice systému a ke komu a k čemu dostanu přístup. Výstupy pak píšu tak, aby je pochopil i ten, kdo AI nedělá: s příklady a analogiemi, s variantami a jejich pro a proti a se zdůvodněním, proč doporučuji právě tu, kterou doporučuji.
Review systému před provozem nebo před nákupem
O tuto službu firmy zpravidla projeví zájem, když mají PoC nebo pilotní verzi v testovacím provozu a chystají se do plné produkce. Ostrý provoz je ale úloha jiného typu než prototyp: systém musí unést zátěž, jeho kvalita se musí měřit, musí být jasné, jak porostou náklady se skutečnou zátěží a jestli zůstanou přijatelné, a k tomu přibývá regulace. Otázka po review obvykle přijde ve chvíli, kdy má někdo schválit větší rozpočet, nebo když už provoz přinesl první pády a nečekanou fakturu.
Dívám se proto na architekturu a na to, jak se měří kvalita odpovědí, což bývá slabé místo, protože bez měření se o zlepšení dá jen diskutovat. Dále na to, co se děje, když některá část systému vypadne, kolik provoz stál minulý měsíc a proč, a co z toho by se při růstu změnilo skokem. Řeším také telemetrii, jak se evidují selhání a jak je nastavená zpětná vazba, aby se pořád dokola neopakovaly ty samé chyby. Potřebuji k tomu přístup k lidem, kteří systém stavěli, a k těm, kteří se o něj mají dál starat, ne jen k dokumentaci, protože důvody k rozhodnutím se do dokumentace zapisují jen zřídka, což je mimochodem vada, kterou se snažím také napravit.
Dostanete dokument s doporučeními seřazenými podle priorit, odhad provozních nákladů, návrh, jak kvalitu pravidelně měřit, a přehled toho, co bude podle evropských pravidel pro AI a pro ochranu osobních údajů chybět v dokumentaci, dohledu a logování. Regulaci přitom posuzuji z pohledu architektury a provozu, tedy co je potřeba doplnit, aby se dala doložit; její právní výklad nechávám právníkům. K tomu prezentaci pro vedení, protože o dalším postupu obvykle rozhodují lidé, kteří celý dokument číst nebudou. Typicky to zabere jeden týden.
Stejné posouzení nabízím i tomu, kdo systém neprovozuje, ale kupuje: pro menšího investora, family office či menší fond, který zvažuje vstup do AI firmy, nebo pro firmu, která se chystá podepsat s dodavatelem AI řešení a chce vědět, co za tím doopravdy je. Prezentace i čísla bývají v pořádku, jenže z nich obvykle nepoznáte, co z toho je skutečně obtížně nahraditelné, za kolik a za jak dlouho by se to dalo postavit znovu a co se stane při změně dodavatele. Ptám se proto, odkud pocházejí data a jak vznikla deklarovaná přesnost, například jestli nepochází z ukázkových dat místo z provozu, a jak moc to celé stojí na hlavách konkrétních lidí: jestli existuje specifikace, ze které se dá vyjít, jestli jsou rozhodnutí a schůzky někde zaznamenané a jestli by na projekt dokázal navázat někdo nový, aniž by se musel vyptávat toho, kdo odešel.
Výstupem je report pro toho, kdo rozhoduje: rizika seřazená podle dopadu, poznámka ke klíčovým lidem a k tomu, co by odchod jednoho z nich znamenal, a otázky, které má podle mě smysl položit managementu nebo dodavateli ještě před podpisem, ať už proto, abyste je měli zodpovězené, nebo abyste podle způsobu odpovědi poznali, s kým jednáte. Rozhodnutí zůstává na vás, mým úkolem je dodat k němu podklad. Počítám na pět až deset pracovních dní.
PoC na vašich datech
Tahle varianta dává smysl, když má produktový tým jeden konkrétní záměr a uvnitř firmy se vede spor, jestli je vůbec proveditelný. Takový spor se obvykle nedá rozhodnout diskusí, protože odpověď závisí na vašich datech a na tom, jak vypadají ve skutečnosti, ne na ukázkách ve výběrovém řízení.
Postavím proto prototyp na vašich vlastních datech a připravím k němu měření, které ukáže, jak realistická jsou očekávání od dané úlohy. Výsledek zřídka bývá prosté ano nebo ne; častěji se úloha rozpadne na části, které jdou dobře, a části, které nejdou vůbec, a právě to rozdělení je pro další rozhodování cennější než jedno souhrnné číslo. Průběžně se proto ptám, co by úloha musela splňovat, aby se dala pustit do provozu, jaká přesnost je přijatelná a především jak ji vůbec spolehlivě měřit. Pokud se během toho ukáže, že cesta nikam nevede, řeknu to raději brzy, protože „ne" po třech týdnech je pro vás mnohem levnější než totéž po roce vývoje.
Garantovaným výstupem je provedený experiment, výsledky měření místo dema a doporučení, zda a v jakém rozsahu v záměru pokračovat; funkční prototyp spolu s návrhem architektury a odhadem nákladů pro variantu, která by opravdu šla do provozu, dostanete pro tu část úlohy, u které se proveditelnost potvrdí. Tím se rozhodnutí, jestli stavět dál, opírá o čísla z vašeho prostředí, a ne o dojem z předvedení. Prototyp od začátku vedu tak, aby po něm zůstala specifikace a zaznamenaná rozhodnutí, ze kterých může navázat i někdo jiný než já. Obvykle to trvá tři až čtyři týdny.
Dlouhodobě: fractional AI lead
Dlouhodobá spolupráce se hodí firmám, které nemají seniorního AI člověka na plný úvazek, nebo mají tým, kterému chybí někdo zodpovědný za směr. V takové situaci se rozhodnutí buď odkládají, protože si je nikdo netroufne udělat, nebo je udělá ten, kdo je zrovna nejhlasitější, a to v době, kdy se možnosti mění rychleji, než stihne dozrát roční plán.
Beru proto na sebe AI roadmapu a rozhodnutí typu postavit vlastní, koupit hotové, nebo doladit existující řešení, dělám review architektury a dodávek a pracuji s týmem tak, aby to po nějaké době zvládal beze mne. Velký důraz při tom kladu na to, jak je projekt veden: specifikace napřed, zaznamenané schůzky a rozhodnutí, dokumentace, kterou pomáhá udržovat AI, a nezávislý druhý pohled, který výsledek zkontroluje dřív, než se považuje za hotový. Podle mé zkušenosti pak projekt nestojí na paměti jednoho člověka a jde na něj navázat bez dlouhého předávání, a neplatí to jen pro software. Sleduji za vás, co se v AI děje, a říkám, co z toho se vás skutečně týká, protože podstatná část novinek se vašeho produktu nedotkne vůbec a rozeznat to stojí čas, který váš tým obvykle nemá.
Průběžně tak vznikají rozhodnutí, která jsou zároveň zapsaná a zdůvodněná, takže je za půl roku dohledatelné, proč jste se rozhodli právě takhle, a architektonické podklady, které vám zbydou i po skončení spolupráce. Rozsah bývá jeden až dva dny týdně, účtováno paušálem za roli a dostupnost.
Jak účtuji práci s AI
Účtuji za výsledek, ne za odpracované hodiny, a nezastírám, že výsledek dnes vzniká ve spolupráci s AI; ručím za něj ale já, ne ona. Pro vás to znamená předvídatelnost: cenu znáte před začátkem, rozpočet se schvaluje jednou a na konci vás nečeká překvapení, kolik to nakonec stálo. Když se v odhadu spletu, ať nahoru, nebo dolů, jde to za mnou, ne za vámi. Změní-li se cestou zadání, domluvíme se znovu, ještě než se to promítne do ceny.
Totéž radím klientům, kteří řeší, jak práci s AI účtovat a vysvětlovat vlastním zákazníkům. Ta otázka přijde dřív nebo později u každého, kdo prodává vlastní práci, a je snazší na ni odpovědět předem: za jaký výsledek zákazník platí a jak se budou domlouvat případné změny zadání.