Čtyři inovace, na kterých teď v TRITON IT pracujeme

Mám rád oborové insighty, nejen jako rychlé postřehy zvenčí, ale i jako pohled do kuchyně firem, které něco reálně staví. Jeden takový z TRITON IT sem dnes napíšu. Máme teď vytvořeny 4 pracovní mini-skupiny. Každá pracuje na jedné inovaci. Konkrétně...

Obr. 1: Nechal jsem Google Geminy načíst text tohoto článku s instrukcí vytvořit abstrahující fotorealistickou scénu, která by text popisovala. Výsledek je analogie novodobého "parního stroje", se kterým kolegové komunikují skrze terminály. Postprocessing: Alma Zajícová

1. Prototypování automatizovaného reportingu 

Jedna z činností, kterou v TRITON IT pro naše klienty zajišťujeme, je automatizovaný monitoring napříč firmou. Integrujeme výstupy z CRM, účetních systémů, pokladen na pobočkách, marketingových nástrojů a manažerům vytváříme report na jednom místě, nejčastěji v Google Looker Studiu a Microsoft Power BI. Připravujeme migraci na open-source Apache Superset (open-source ekvivalent předchozích dvou).

Největší časovou výzvou je odladit finální podobu reportu na míru. To odladění má dvě části: prvně zajistit, že tečou správná data, a potom ověřit, že report zobrazuje vše, co je potřeba vidět, způsobem, jakým je to chtěno. A zde jsou manažeři schopni dávat nejlepší zpětnou vazbu až v momentě, kdy vidí výstupy.

Abychom zefektivnili dlouhotrvající diskuze nad finální podobou, začali jsme na základě prvotních požadavků od manažerů generovat grafické náhledy reportů předem. K tomuto jsme vytvořili vlastní proces s pomocí Claude. Požadavky manažerů převádíme do popisného jazyka. Udělali jsme si doménově specifický jazyk založený na Markdownu, takový lidsky čitelný ekvivalent LookerML od Googlu. Popsané vstupy předáváme Claude a generujeme XML do SVG formátu, které slouží jako náhled pro klienta. Klíčové je, že při každém změnovém požadavku manažera jsme schopni rychle měnit náhledy. Tento proces postupně zdokonalujeme, aby se z něj mohla stát agentová služba v rámci toho, o čem píšu v bodě 4.

2. Automatizace obsahového oddělení

A lidé jsou zde pořád potřeba!

Jak to funguje? S každým klientem či tématem si držíme „bázový dokument“ obsahující vyčerpávající informace o firmě, aplikaci či daném tématu, strukturované v Markdownu.

Pro každé publikační kolo kolegové z obsahu tvoří tzv. „původní text“. Dokument nabitý informacemi, ve kterém je ideálně každé tvrzení podpořeno citací odborné studie, získanými daty či know-how insiderů. V původním textu je popsána celá nosná myšlenka článku, klíčový proces či sledovaná výseč odborného tématu. A tento text je zkontrolován a potvrzen odborníky u nás, nebo u klienta (záleží, zda tvoříme obsah pro své projekty, nebo klienty).

Tento původní text společně s bázovým dokumentem slouží jako vstupy do workflow v n8n. Aktuálně to děláme tak, že na každý případ užití (klíčové téma či klienta) máme zvlášť workflow, vytvořené z kopie šablony, kterou vylepšujeme.

V rámci workflow funguje několik rolí agentů. První jsou generovači, specializovaní každý na jiný kanál (LinkedIn, Facebook, tiskovky atd.). Každý bere jako vstup původní text a jeho parametrem je unikátní konfigurace agenta.

Pak máme kvalitativní agenty. Pokud je například původní text příliš dlouhý a informačně nabitý, navrhují rozdělení příspěvků. Další kvalitativní agenty testují informační hodnotu výstupu z hlediska splnění cílů příspěvku. Jiní pak testují formu.

Máme příklady nevhodné a vhodné formy komunikace, které vznikaly dříve během našich ručně psaných příspěvků a jejich oponentur, něco jako když Michelle Losekoot na svých školeních ukazuje špatné příklady komunikace a brainstormuje se svými posluchači, jak je vylepšit. Michelle se ptá: „A co na to Karel?“

Posledním kvalitativním článkem v procesu je zatím člověk. Kontroluje, zda to, co „vypadlo ze stroje“, je skutečně ono. Pokud ne, společně s informací o tom, co je špatně, to vracíme zpátky do stroje.

Dnes už víme, že celý tento proces za nějaký čas „zahodíme“ a přejdeme na to, co píšu v bodě 4.

3. Centralizace firemních dat pro automatizace i vývoj s genAI

Máme firemní wiki, máme Nextcloud, máme Google Drive, ale potřebujeme mít data na jednom místě tak, aby si pro ně mohly naše automatizační služby šahat. A nejen automatizační služby, vývoj aplikací s integrovaným genAI se stal neodmyslitelnou částí naší práce a je pro nás důležité mít klíčová data přístupná a jednotně spravovaná.

Pro textová data jsme sáhli po osvědčené ChromaDB. Pro multimédia jsme vybrali MinIO.

V případě textových dat dokumenty do ChromaDB ukládáme v Markdown formátu. Máme čtyři základní kolekce s metadaty (klíči) podle ID klienta, projektu/aplikace atd.:

1. „Knowhow source“ - slouží k uchovávání bázových dokumentů či exportů z wiki.

2. „Original posts“ - články z blogů či magazínů, digitalizované tištěné dokumenty, příspěvky na sociálních sítích včetně datace, oborového rozdělení a dalších parametrů.

3. „Comments“ - komentáře pod články, příspěvky na sociálních sítích, e-mailová komunikace, jakékoliv reakce.

4. „Generated posts“ - archiv námi vygenerovaných výstupů.

Data z těchto kolekcí se potom používají napříč workflow v n8n i vyvíjenými aplikacemi. Šahá se na „jedno místo“ do našeho datacentra, vždy s identifikátorem příslušného klienta.

4. Univerzální interní genAI rozhraní

Cílem je mít jednotné prostředí, ve kterém na jedné straně každý člověk ve firmě vyřeší veškeré automatizace a úkony spojené s genAI. A na straně druhé jej bude možno využít jako motor pro tento systém s libovolným LLM, včetně lokálně hostovaných, s možností mezi LLM přepínat dle kvalitativních a nákladových parametrů.

Toto řešení nám na jedné straně velmi usnadní (a již částečně usnadňuje) onboarding, reporting, vývoj softwaru i tvorbu obsahu, protože nahradí obsahové automatizace, o kterých jsem psal v bodě 2.

Na druhé straně nám i našim klientům poskytne maximální míru nezávislosti na korporátech i „kakaných“ softwarech přeprodávajících formou SaaS základní funkce LLM, obalené oborovými prompty.

Na čem to aktuálně stavíme? Vše, kromě části napojených LLM, je open-source.

Na frontendu máme OpenWebUI. Za ním je buď napřímo LLM model, zde se nám zatím nejvíce osvědčuje Claude, protože umí nejlépe používat nástroje doprogramované námi. Nebo jako alternativa k LLM modelu je k dispozici LangChain vrstva agentů, které píšeme na míru našim potřebám a které si umí šáhnout do našich databází pro informace.

Toto je část, na které aktuálně intenzivně pracujeme. Jakmile budeme hotovi, začneme plošně nasazovat u kolegů i vybraných klientů.