← Zpět k článkům
Quando l'AI aziendale non sa quello che sa Kapitola 1 z 6
AI 2026-04-16 ProtoMedia

Motor, který měl šest pólů — Mýtus ze deset řádků kódu

Přeloženo automaticky z italštiny · přečíst originál

Investigace v šesti dílech o důvdech, proč dokumentační chatbot, který vám prodali, stále vymýšlí — a o jiném směru, kterým někdo začal v počátcích roku 2026 procházet.

Obsah reportáže

  1. Motor, který měl šest pólů — Mýtus ze deset řádků kódu
  2. Tabulky, které neexistovaly
  3. Lhavý reranker
  4. Děděná halucinace
  5. Skrytá cena cloudu
  6. Strategie jako dokument — Sedmá kapitola

Investigace v šesti dílech o důvdech, proč dokumentační chatbot, který vám prodali, stále vymýšlí — a o jiném směru, kterým někdo začal v počátcích roku 2026 procházet.

Úvod — Motor, který měl osm pólů (ale měl šest)

Milán, březen 2026. Manažer otevře interní firemní chatbot, takový, který byl sestaven „za dva týdny“ z velkým nadšením a malou nejistotou. Velmi jednoduchá otázka: „Kolik pólů má motor CMP40M?“. Chatbot odpoví se celou jistotou, kterou velké jazykové modely umí předvést: „Motor CMP40M má osm pólů.“

Špatně. Má jich šest. Správná odpověď nebyla v katalogu o 422 stránkách, který někdo před měsíci s naprostou důvěrou nahrál do vektorové databáze, přesvědčen, že systém "bude vědět všechno". Tato data v katalogu prostě nebyla. Byla v PDF příloze e-mailu od techniků SEW, uloženém ve složce, kterou si nikdo nedal práci indexovat.

Tato scéna, s odlišnými obory a dialekty, se opakuje ve stovkách italských kanceláří. Slib byl jednoduchý a lákavý: dejte svému AI asistentovi všechny firemní dokumenty a bude schopen odpovědět na jakoukoli otázku týkající se jich. Realita je mnohem prozaičtější: chatbot čte, ale nerozumí, hledá, ale nenajde, a když nenajde – místo aby to řekl – si vymýšlí. Vymýšlí plynule, s dokonalou gramatikou, s věrohodnými čísly. A to je mnohem horší než neodpovědět.

Mezi koncem roku 2024 a začátkem roku 2026 jsme strávili měsíce pitváním těchto neúspěchů. Ne abychom podněcovali polemiky, ale abychom pochopili jednu věc: proč se tak lineární myšlenka – "dej mu dokumenty a pak se ho na něco zeptej" – stane tak obtížnou, když opustí pódium dema a vstoupí do místnosti se skutečnými servery.

Tato šestidílná sonda popisuje, co jsme zjistili: tiché chyby, které mazaly celé katalogy, cloudové rerankery se špatnými skóre, halucinace vzniklé ne modelem, ale kontaminovanými daty z let minulých, faktury, které činily každý dotaz dražším, než jakou měl hodnotu, a „populární“ frameworky, které slibují vše v deseti řádcích kódu, pokud od nich nebudete chtít příliš mnoho. A v poslední kapitole směr, kterým se někdo potichu vydal na začátku roku 2026 – architektura, ve které strategie vyhledávání přestává být kód a stává se dokumentem, který si může kdokoliv ve firmě přečíst a upravit.

Každá kapitola stojí za sebe. Pokud chcete začít příběhem o 342 zmizelých tabulkách, nebo o lživém rerankeru, jste svobodní to udělat. Ale celý příběh má morální ponaučení, které vyplývá až na konci: firemní RAG – ten technický akronym, který znamená Retrieval-Augmented Generation, tedy „generuj odpovědi na základě dokumentů, které nejprve načteš“ – ještě není hotový produkt. Je to hranice. A jako každá hranice, doposud ji vyprávěli především prodejci. Je čas poslechnout si i ty, kteří v ní žili.

Kapitola 1 — Mýtus deseti řádků kódu

Snímek je identický na každé konferenci o AI od roku 2023: "Váš firemní dokumentační asistent v 10 řádcích kódu." Pod nadpisem je blok kódu v pastelových barvách, který ukazuje open-source knihovnu – typicky jednu z těch slavných amerických, jejíž název evokuje řetězce stromů nebo tibetské lamy – která načítá PDF, rozděluje je, vkládá do vektorové databáze a dotazuje se na ně pomocí jazykového modelu. Za pět minut máte chatbota. Za pět minut potlesk. Za pět minut se italská firma střední velikosti přesvědčí, že problém je vyřešen, a že její IT oddělení to zvládne za dva týdny.

Problém – ten, který snímek neříká – je, že demo je postaveno se třemi dobře formátovanými PDF, otázkou ušitou na míru, aby odpovídala obsahu, jevištěm bez reálných latencí a přednášejícím, který to všechno zkoušel sedmadvacetkrát, než vystoupil. Ve skutečnosti jsou firemní dokumenty geologickou katastrofou: skeny skenů, tabulky překrývající text, poznámky pod čarou vkládající se do odstavců, alfanumerické kódy typu "RH1M", které chunker rozseká napůl a považuje je za slova, obrázky, které obsahují sedmdesát procent užitečných informací, ale které nikdo skutečně neextrahují, a rozložení tak kreativní, že vyžadují archeologa spíše než parser.

RAG – to je myšlenka pod kapotou – je skvělý nápad. Vezměte otázku uživatele, prohledejte svůj archiv a najděte nejrelevantnější dokumenty, předávejte je jazykovému modelu a nechte si vygenerovat odpověď založenou na těchto dokumentech. Teoreticky elegantně řeší problém halucinací: model už nemusí „vědět“ odpověď, stačí, když si ji „přečte“ v kouscích, které jste mu poskytli. V praxi má každý článek řetězce – rozdělování na části, vkládání, vyhledávání, opětovné řazení, finální generování – své vlastní způsoby, jak selhat, a selhání se zřídka projevuje jako viditelná chyba. Projevuje se jako mírně nesprávná odpověď. Pak jako zcela nesprávná odpověď. Pak jako manažer, který se ptá, proč platí za systém, který ví méně než stážista.

Open-source frameworky, které zpopularizovaly RAG, jsou navrženy tak, aby demonstrovaly, nikoli aby produkovaly. Jsou to elegantní řetězce abstrakcí, v nichž každá vrstva skrývá nevyřčený předpoklad: že vaše PDF mají slušné OCR, že vaše fotografie již byly popsány, že vaše tabulky dodržují konvenci, že embedding model skutečně mluví vaším jazykem (spoiler: mnoho dobře mluví pouze anglicky), že váš archiv byl již očištěn od duplikátů. Když jeden z těchto předpokladů selže – a alespoň jeden selže vždy, téměř vždy tři – systém nepřestane fungovat. Hůře: přestane fungovat dobře, ale pokračuje ve vydávání odpovědí. Plynulých, jistých a často nesouvisejících s pravdou.

Obíhá fráze mezi těmi, kteří tyto systémy staví profesionálně, a kterou v tutoriálech nikdy nepřečtete: "RAG se snadno udělá, ale těžko udělá dobře." Mezi prvním demem a produkční službou je propast, kterou nelze překlenout přidáním GPU nebo změnou modelu. Překlenuje se pochopením nepříjemné věci: když stavíte firemní RAG, nepíšete kód. Navrhujete malý, vytrvalý vyhledávač na míru vašim dokumentům, se všemi redakčními volbami, které to s sebou nese – co je šum, co je signál, co se má indexovat dvakrát a co se má vyhodit. Jenže v tutoriálech o deseti řádcích jsou tyto volby učiněny za vás jednou někým, kdo nikdy neviděl vaše dokumenty. A jsou téměř vždy špatné pro váš případ.

Ponaučení ve zkratce: RAG se snadno udělá, a těžko udělá dobře. Mezi prvním demem a produkční službou je propast.

Máte připomínku? Napište nám

Zpráva je určena pouze nám. Pokud bude váš komentář zajímavý, můžeme ho zveřejnit na konci článku, ale až po posouzení.

Zatímco píšete, váš prohlížeč řeší drobný výpočet – to je náš způsob, jak zabránit automatické poště bez použití externích služeb a bez nutnosti rozpoznávat semafory. Nic se vás neptáme a žádná data toto místo neopustí.