V prvním díle jsem popsal tenkého klienta nad ekonomickým systémem POHODA. Ne další chatbot, který dostane přístup k účetnictví, ale několik jasně oddělených vrstev: POHODA jako účetní základ, nad ní omezený katalog bezpečných operací, nad ním znalostní báze a teprve úplně nahoře jazykový model.
Od té doby jsem se věnoval otázce:
Odkud má model vědět, jak se POHODA skutečně chová?
Při práci jsem použil různé jazykové modely (5.6 Sol, Opus 5/Fable 5) v oddělených prostředích. Nechal jsem je vyhledávat zdroje, navrhovat testy, rozporovat závěry a předávat si výsledky přes Git. Byly mimořádně rychlé. Během několika dnů dokázaly zpracovat množství materiálu, na které bych sám potřeboval týdny, možná měsíce.
Současně se ukázalo něco podstatnějšího: jazykový model může být skvělý badatel, programátor i oponent, ale nesmí být zdrojem pravdy sám o sobě. Jakmile mu v podkladech něco chybí, velmi přirozeně doplní zkušenost z jiného systému, obecnou zvyklost nebo prostě věrohodně znějící vysvětlení.
Právě z toho postupně vznikl koncept, kterému říkám Atlas.
Atlas není wiki článků
Klasická wiki ukládá text. Atlas má ukládat především tvrzení.
Například: Při určitém typu importu může POHODA vrátit celkový stav „ok“, přestože uvnitř odpovědi obsahuje varování a doklad byl vytvořen jinak, než klient zamýšlel.
Taková věta sama o sobě nestačí. Atlas k ní potřebuje vědět:
odkud pochází,
pro kterou verzi, edici a typ databáze platí,
zda ji uvádí dokumentace, nebo ji někdo skutečně pozoroval,
zda existuje reprodukovatelný důkaz,
jak ji lze po další aktualizaci programu znovu otestovat,
a co ze zdroje smím citovat, ukládat nebo dál šířit.
To je hlavní rozdíl. Atlas nemá být knihovna přesvědčivých odpovědí. Má to být systém, který dokáže u každé odpovědi říct: jak to víme, kde to platí a jak silný je podklad.
V návrhu proto rozlišuji několik stavů tvrzení:
domněnka — závěr, který zatím nemá přímý podklad,
dokumentováno — výrobce, schéma nebo jiný zdroj to přímo uvádí,
pozorováno — vlastní běh takový výsledek obsahuje, ale ještě z něj nevznikl samostatný strojový důkaz,
ověřeno — pro konkrétní prostředí existuje strojově čitelný důkaz,
vyvráceno nebo neplatné — test ukázal opak nebo se změnila verze a původní tvrzení už neplatí.
Nejde o akademickou přesnost. POHODA se liší podle edice, databáze i release. Tvrzení ověřené v Premium nad MDB není automaticky pravda o E1 nad SQL. A informace z dokumentace není totéž jako výsledek běhu, stejně jako výsledek jednoho běhu není univerzální vlastnost všech instalací.
Z čeho se taková znalost skládá
Na začátku jsem si pod pojmem „zdroje“ představoval hlavně dokumentaci výrobce a zkušenosti konzultantů. Ve skutečnosti je mapa mnohem širší:
nápověda dodaná s programem,
veřejná dokumentace XML rozhraní a partnerské materiály,
časopis Moje POHODA a přehledy změn jednotlivých verzí,
licencované open-source konektory,
odborná literatura, fóra a diskuse,
vlastní testy proti programu,
a nakonec i hypotézy, které o produktu nabídne jazykový model.
Každá skupina přináší něco jiného. Dokumentace dobře popisuje zamýšlené použití. Open-source konektor může ukázat praktický detail, na kterém už někdo ztroskotal. Fórum obsahuje neocenitelnou zkušenost z konkrétní situace. Vlastní běh jako jediný odpoví na otázku, co se stalo v přesně popsaném prostředí.
Ani jeden z těchto zdrojů ale není automaticky „pravda“ — a už vůbec není automaticky volně použitelný.
To pro mě byla důležitá korekce původní představy o OSINT. Veřejně dostupné neznamená volné ke kopírování a redistribuci. Odkaz a citace také samy o sobě nelegalizují plošné převzetí obsahu. Atlas proto u zdroje potřebuje evidovat nejen jeho původ, ale i režim užití: vlastní obsah, licencovaný obsah, zdroj pouze k odkázání nebo materiál, který nesmí opustit konkrétní počítač.
Praktickým důsledkem je, že distribuovaný Atlas nemá obsahovat cizí manuály, celé články ani kopie fór. Má nést vlastní stručná tvrzení, jejich dohledatelný původ, odkazy, licenci a důkazy tam, kde je lze vytvořit.
U nápovědy dodané s programem volím zatím ještě opatrnější variantu. Atlas její text nekopíruje. Uchová pouze ukazatel na příslušné téma a verzi programu; téma se otevře až na počítači uživatele, který má vlastní licencovanou instalaci. Ani to nevydávám za definitivně právně posouzené řešení. Je to minimalizační technický návrh, který má předcházet zbytečnému kopírování, dokud právní rámec nebude vyjasněný.
Co se dá testovat — a co ne
Tady pro mě vede nejdůležitější hranice celého projektu.
Tvrzení o chování programu se často dá převést na test:
přijme POHODA tento požadavek,
vytvoří doklad,
vrátí varování nebo chybu,
změní konkrétní pole,
zopakuje operaci bezpečně po timeoutu?
Takové tvrzení může mít scénář, který se po aktualizaci programu spustí znovu. Pokud se změní dokumentace nebo test přestane procházet, Atlas neprohlásí původní tvrzení okamžitě za nepravdivé. Označí ho k přezkoumání. Selhat mohl program, síť, testovací prostředí i samotný test.
Přesto je to zásadní posun: wiki o softwaru se nemusí ověřovat jen odkazem. Část jejích tvrzení lze znovu spustit.
Úplně jiná situace nastává u účetních a daňových postupů. Program umí ověřit, že doklad vznikl, že obsahuje určité částky a že se zaúčtoval na zadané účty. Neumí tím ale potvrdit, že je postup správný podle platného práva a odpovídá konkrétní situaci klienta.
To, že POHODA doklad přijala, není právní ani účetní autorita.
Proto nechci automaticky proměnit obsah fór a odborných článků v instrukce k účtování. Normativní znalost potřebuje jiný režim: jurisdikci, datum účinnosti, rozhodné okolnosti, hierarchii zdrojů, odborného posuzovatele a datum příští revize. Atlas může najít relevantní zdroje, ukázat možné režimy a upozornit, které informace chybí. Konkrétní rozhodnutí ale musí zůstat člověku, který za něj nese odpovědnost.
Jinak bych postavil systém, který dokáže technicky bezchybně provést právně chybný postup.
Jedno zjištění, které změnilo návrh
Většinu laboratorního deníku nemá smysl čtenáři předkládat. Jeden výsledek ale stojí za popis, protože vysvětluje, proč nestačí připojit LLM přímo k XML rozhraní.
V testovací jednotce jsem poslal fakturu s položkou odkazující na neexistující skladovou zásobu. Očekával jsem odmítnutí.
Vnější vrstvy odpovědi hlásily úspěch. Teprve uvnitř byla varování, že zásoba neexistuje a že program některé hodnoty doplnil sám.
Doklad přesto vznikl.
Pro běžnou integraci je to nepříjemný detail. Pro autonomní systém je to zásadní bezpečnostní problém. Klient nesmí kontrolovat pouze HTTP kód ani hlavní stav odpovědi. Musí rozumět více úrovním výsledku a ověřit také skutečný následek operace.
Právě tady je rozdíl mezi „příkaz proběhl“ a „stalo se to, co uživatel zamýšlel“.
To je jeden z důvodů, proč jsem původní architekturu rozdělil na tři části:
Atlas uchovává tvrzení, zdroje, důkazy a testovací scénáře.
Pilot je tenký klient, který nabízí jen omezený katalog operací.
Lab spouští scénáře v bezpečné testovací jednotce a vyrábí důkazy.
Jazykový model může navrhnout postup nebo vybrat operaci. Nemůže si ale sestavit libovolné XML a odeslat ho do účetnictví.
Proč má Atlas běžet lokálně
Centrální vyhledávací API jsem z návrhu vyřadil. Nejen kvůli nákladům a PHP workerům. Dotaz do účetní znalostní báze může sám obsahovat citlivou informaci o firmě, klientovi nebo konkrétním případu.
Tenký klient si proto stáhne podepsaný a verzovaný balíček Atlasu a prohledává ho lokálně. Základ může být překvapivě obyčejný: SQLite, fulltextové hledání FTS5 a řazení výsledků pomocí BM25.
Vyhledávání by probíhalo přibližně takto:
z dotazu se určí agenda, typ operace a prostředí uživatele,
vyřadí se tvrzení pro jinou edici, databázi nebo neplatnou verzi,
lokální fulltext najde kandidáty,
výsledky se seřadí podle relevance, síly důkazu a aktuálnosti,
model z nich sestaví odpověď s uvedením zdrojů a míry jistoty.
Sémantické vyhledávání nebo lokální embeddingy lze přidat později jako další vrstvu. Neměly by ale rozhodovat o pravdivosti. Mohou pomoci najít vhodné tvrzení; jeho důvěryhodnost stále určuje stav, rozsah a důkaz.
Centrální infrastruktura pak nemusí odpovídat na každý uživatelský dotaz. Stačí, když publikuje nové podepsané verze balíčku a jejich změny. Klient si je stáhne podobně jako aktualizaci antivirových definic a pracuje dál bez serveru — a v případě potřeby i bez internetu.
Model nesmí obejít bezpečnostní bránu
Druhá podmínka je stejně důležitá jako znalost.
Pilot nesmí být univerzální vykonavatel XML. Musí nabízet malý katalog pojmenovaných operací, u kterých je předem jasné:
zda pouze čtou, nebo zapisují,
do které účetní jednotky smějí,
jaké mají vedlejší účinky,
co musí člověk potvrdit,
a jak se ověří výsledek.
Bezpečnostní kontrola přitom nesmí být jen v grafickém dialogu. Musí ležet přímo ve vrstvě operací, kudy prochází každý vstup — okno, automatický scénář i budoucí model. Pokud automatický vstup neumí získat požadované potvrzení, zápis se neprovede.
Stejný princip platí pro síť. Pilot nemůže předpokládat, že domácí nebo firemní LAN je důvěryhodná. Potřebuje omezeného uživatele, povolení pouze pro konkrétní účetní jednotku a mServer dostupný jen po dobu nezbytné práce. Síťové použití vytváří nová rizika a tenká vrstva je musí pokrýt sama.
Jakou roli v tom mají LLM
Při vzniku Atlasu mi jazykové modely výrazně urychlily práci. Jeden pracoval u počítače s POHODOU, druhý nad zdroji a strukturou znalostní báze. Přes Git si předávaly návrhy, připomínky a výsledky kontrol.
Neberu to jako experiment dokazující, že dva modely vytvoří pravdu. Právě naopak: dva modely se mohou shodnout na stejné přesvědčivé chybě. Jejich největší přínos byl jinde — dokázaly rychle vyrábět kontrolovatelné výstupy: návrh tvrzení, testovací scénář, změnu schématu, seznam rozporů nebo programovou kontrolu.
V Atlasu proto platí jednoduché rozdělení rolí:
LLM smí navrhovat tvrzení, otázky, scénáře a vysvětlení.
Zdroj může tvrzení doložit jako dokumentované.
Vlastní běh ho může povýšit na pozorované.
Teprve samostatný strojový důkaz z konkrétního prostředí z něj udělá ověřené tvrzení.
Zápis do účetnictví vždy prochází předem definovanou operací a bezpečnostní bránou.
Model je tedy rozhraní a pracovní síla. Není autorita.
Kde je projekt dnes
Atlas, Pilot i Lab jsou zatím prototypy, ne hotový produkt.
Funguje základní řetězec: lokální klient sestaví povolenou operaci, bezpečnostní brána zastaví nepovolený zápis, testovací scénář lze spustit bez grafického rozhraní a výsledek uložit jako strojový důkaz. Znalostní báze rozlišuje domněnky, dokumentaci, pozorování a ověřené výsledky a její strukturu kontrolují automatická pravidla.
Zdaleka ještě nefunguje všechno, co by bylo potřeba pro běžné nasazení. Katalog operací je úzký. Mnoho pozorování čeká na převod do reprodukovatelných důkazů. Je potřeba právně posoudit práci s licencovanou dokumentací, navrhnout správu komunitních příspěvků a udělat slepý benchmark vyhledávání a odpovědí.
To ale nemění základní směr.
„Monstrum chytřejší než celá partnerská síť“ nemá vzniknout tím, že nasadím větší jazykový model. Může vzniknout jedině tak, že se zkušenosti mnoha lidí přestanou ztrácet v hlavách, e-mailech a fórech — a každá z nich dostane původ, rozsah platnosti, právní režim a tam, kde je to možné, i test.
Pak může model nad společnou znalostí pracovat rychleji než kterýkoli jednotlivec. Současně ale nebude smět předstírat, že ví něco, co Atlas nedokládá.
A to je podle mě mnohem zajímavější cíl než další chatbot nad dokumentací.
Zajímají mě hlavně dvě otázky:
Které provozní zvláštnosti POHODY podle vás zná každý zkušený konzultant, ale v dostupné dokumentaci se hledají obtížně?
Kde by podle vás měla vést hranice mezi technickou znalostí programu a účetním nebo daňovým doporučením?
Právní poznámka: Text není právním stanoviskem. Český autorský zákon upravuje automatizovanou analýzu textů a dat v § 39c a evropský rámec vychází z čl. 4 směrnice (EU) 2019/790. Tato úprava sama o sobě není licencí k následnému zveřejnění nebo redistribuci cizího obsahu; konkrétní použití je nutné posoudit také podle aktuálních licenčních podmínek a povahy zdroje.