Príspevok #6 opísal architektúru. Toto je, čo sa stalo, keď naozaj prvýkrát bežala — a aký problém s kvalitou dát to potichu odhalilo.
Príklady a architektúry v tejto sérii vznikajú ako moje osobné vzdelávacie a nekomerčné experimenty; nejde o ponuku IT alebo poradenských služieb.
V príspevku #6 som prešiel architektúru AI CFO agenta — systémy, na ktoré sa pripája, päťkrokovú pipeline a to, ako report skončí v schránke bez toho, aby niekto stlačil tlačidlo. Táto časť je o tom, čo sa stalo, keď táto pipeline prvýkrát skutočne odbehla od začiatku do konca a vyprodukovala niečo, čo si CEO prečítal pri káve.
Report, čísla aj rozhovor nižšie sú modelová ilustrácia poskladaná z opakujúcich sa vzorcov, ktoré som videl naprieč rôznymi projektmi; neopisujú konkrétnu firmu, dátovú sadu ani osobu.
Samotný report vyzeral presne tak, ako mal — jednostránkové zhrnutie vygenerované automaticky cez noc, s tržbami za posledných 30 dní, hrubou maržou a projekciou cash runwayu. Dve z troch čísel boli správne. Tretie nie — a náhodou to bolo práve to číslo, na ktorom CEO to ráno najviac záležalo.
| Metrika | Čo report ukázal | Čo bolo skutočne pravda |
|---|---|---|
| Tržby, posledných 30 dní | 187 400 € | Správne |
| Hrubá marža | 41,2 % | Správne |
| Cash runway | 14,2 mesiaca | V skutočnosti 9,8 mesiaca |
Číslo runwayu nikto neoznačil ako podozrivé, pretože samo o sebe vyzeralo hodnoverne. Odhalila ho pamäť, nie analýza. CEO pár týždňov predtým prebral s účtovníkom hrubý odhad runwayu — niekde okolo desiatich mesiacov — a automatický report teraz tvrdil štrnásť. To nie je malá odchýlka. Je to presne ten typ rozdielu, pri ktorom si niekto zastaví a spýta sa, namiesto toho, aby email len preposlal ďalej.
„Minulý mesiac sme boli na približne desiatich mesiacoch runwayu. Teraz je to štrnásť? Čo sa zmenilo?"
Prevádzkovo sa nezmenilo nič. Zmenilo sa to, že v týždni, kedy bol report vygenerovaný, prišlo na bankový účet čerpanie krátkodobého úveru vo výške 120 000 € — peniaze, ktoré bude firma musieť splatiť, nie tržby, ktoré si zarobila.
Cash flow modul agenta sťahoval každý príjem z pripojeného bankového feedu a použil ho na projekciu do budúcnosti. Nemal žiadne pravidlo na rozlíšenie prevádzkového príjmu — platby od klienta — od finančného príjmu — čerpania úveru, kapitálového vkladu, čohokoľvek, čo so sebou nesie záväzok. Pre pipeline bolo 120 000 € jednoducho 120 000 €. Prišlo to na účet, takže sa to počítalo ako hotovosť dostupná na spálenie, a projekcia runwayu sa podľa toho predĺžila.
„Agent nevedel rozlíšiť peniaze, ktoré ste zarobili, od peňazí, ktoré musíte splatiť. Tento rozdiel je pre každého účtovníka samozrejmý. Systém sa to musí naučiť explicitne — túto logiku nemá nikto v základe."
Toto nie je dramatické zlyhanie. Je to konkrétna, opraviteľná medzera v tom, ako sa interpretuje zdroj dát — a je to veľmi bežná kategória chyby prvýkrát, keď sa reportovacia pipeline dotkne reálnych bankových dát namiesto čistého vzorového súboru.
Pred ďalším reportom pribudli do pipeline dve veci. Po prvé, klasifikačné pravidlo, ktoré oddelí finančnú aktivitu od prevádzkovej ešte pred akýmkoľvek výpočtom cash runwayu — takže čerpanie úveru, splátka alebo kapitálový vklad sa označí a vylúči, namiesto toho, aby sa zmiešal do „hotovosti prichádzajúcej dnu". Po druhé, kontrola zdravého rozumu, ktorá porovná každé nové číslo s predchádzajúcim obdobím a v prípade odchýlky nad stanovenou hranicou report pozastaví na manuálnu kontrolu namiesto automatického odoslania.
Ani jedna z opráv nevyžadovala prestavbu systému. Obe vznikli priamo z toho, že jedno reálne číslo bolo zlé pred očami človeka, ktorý si to všimol.
Podľa mojej skúsenosti vás report, ktorý vyjde čistý a správny, veľa nenaučí o tom, či je systém dôveryhodný — len potvrdí, že jednoduchý prípad funguje. Report, ktorý je zlý, odhalený, vysvetlený a viditeľne opravený, je to, čo skutočne buduje dôveru, pretože ukáže, čo sa stane, keď sa niečo pokazí. Systém, ktorý zlyhá potichu, stráca dôveru natrvalo. Systém, ktorý zlyhá nahlas, je odhalený a opravený, si zaslúži presne ten typ pozornosti, ktorý ho neskôr robí bezpečným na spoliehanie sa.
Príspevok #8 sa venuje tomu, čo sa stalo o pár týždňov neskôr, keď agent označil problém, ktorý napokon žiadnym problémom nebol — a čo ma to naučilo o ladení upozornení, aby ich ľudia nezačali ignorovať.
Dôverovali by ste číslu zo systému aj potom, čo ste ho raz prichytili pri chybe?
Žiadny spam. Jeden príspevok týždenne. Odhláste sa kedykoľvek.