Ako premýšľa ChatGPT a moderné jazykové modely

Kapitola 02 · 39 min čítania Zadarmo po registrácii

Jazykový model nepracuje priamo so slovami ani znakmi tak, ako ich vidí človek. Text najprv rozdelí tokenizer na jednotky, ktoré ovplyvňujú cenu, dĺžku kontextu aj správanie v rôznych jazykoch.

Keď človek napíše do chatbota vetu, vidí slová, medzery a interpunkciu. Jazykový model však nedostáva túto vetu v rovnakej podobe. Medzi textovým rozhraním a neurónovou sieťou stojí tokenizér: algoritmus a slovník, ktoré reťazec prevedú na postupnosť celých čísel. Každé číslo označuje položku v konečnom slovníku modelu. Až tieto identifikátory sa mapujú na vektory a vstupujú do transformerových vrstiev. Token môže predstavovať celé časté slovo, časť slova, interpunkčné znamienko, medzeru spolu s nasledujúcim výrazom, niekoľko bajtov alebo špeciálny riadiaci symbol. Rovnaké napísané slovo sa môže v rôznych tokenizéroch rozdeliť rozdielne. Dokonca aj v jednom tokenizéri môže mať jeho segmentácia inú podobu podľa toho, či stojí na začiatku vety, za medzerou alebo vedľa interpunkcie. Token preto nie je prirodzená jazyková konštanta. Je to rozhranie medzi textom a konkrétnym modelom. V kapitole 1 sme LLM definovali ako pravdepodobnostný model sekvencií. Táto kapitola spresňuje, z čoho je sekvencia zložená.

Ťažisko tvoria časti „Token nie je slovo, znak ani morféma“, „Od textu k číselným identifikátorom“ a „Unicode: prečo „jeden znak“ nemusí byť jedna jednotka“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť vysvetliť, čo je token a tokenizácia a odhadnúť vplyv tokenov na kontext a cenu. Praktickým výsledkom bude schopnosť rozpoznať, prečo sa tokenizácia líši medzi jazykmi a modelmi.

Kapitola odpovedá aj na otázku „Je jeden token vždy jedno slovo?“ Nie. Token môže byť celé krátke slovo, časť slova, interpunkcia alebo iný textový fragment. Rozdelenie určuje konkrétny tokenizer.

Kapitola 03 · 41 min čítania Zadarmo po registrácii

Tréning LLM je priemyselný proces, v ktorom sa spájajú dátové rozhodnutia, optimalizácia, rozsiahly výpočet, priebežné hodnotenie a následné prispôsobenie modelu na bezpečné používanie.

Výraz „model bol vytrénovaný na internete“ skrýva tisíce technických a organizačných rozhodnutí. Ktoré zdroje sa získali? Aké dokumenty sa vyradili? Ako sa vyvažovali jazyky a domény? Ktoré duplicity alebo osobné údaje sa odstránili? Aký tokenizér sa použil? Koľko parametrov, tokenov a výpočtov dostal experiment? Podľa čoho sa zistilo, že tréning napreduje a že výsledok je bezpečnejší než predchádzajúci checkpoint? Tieto otázky sú dôležité, pretože tréningové dáta a cieľ neurčujú model mechanicky, ale vytvárajú podmienky, v ktorých sa model učí. Rovnaká transformerová architektúra môže po odlišnom tréningu produkovať odborný encoder, generatívny základný model, chatového asistenta alebo model špecializovaný na kód. Ani veľmi kvalitný predtréning automaticky nevytvorí systém, ktorý rozumie pokynom, odmieta nebezpečné požiadavky a priznáva neistotu. V kapitole 1 sme definovali LLM ako parametrický pravdepodobnostný model sekvencií a v kapitole 2 sme ukázali, ako text prechádza na tokenové ID. Teraz sledujeme, ako sa parametre nad týmito sekvenciami učia. Detailné metódy adaptácie nechávame pre kapitolu 6 - Fine-tuning modelov; tu ich zasadíme do celého životného cyklu.

Ťažisko tvoria časti „Čo presne znamená „trénovať model““, „Tréning nie je jedna fáza“ a „Celý pipeline v jednej mape“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť popísať predtrénovanie, post-training a evaluáciu a vysvetliť úlohu stratovej funkcie a optimalizátora. Praktickým výsledkom bude schopnosť rozpoznať dátové, výpočtové a bezpečnostné kompromisy.

Kapitola odpovedá aj na otázku „Čo sa model učí počas predtrénovania?“ Učí sa znižovať chybu pri predikcii tokenov. Na to musí zachytiť gramatické, štylistické, faktické a programátorské vzory prítomné v dátach.

Kapitola 04 · 40 min čítania Zadarmo po registrácii

Halucinácia nie je náhodná technická porucha oddelená od fungovania LLM. Vzniká z toho, že model optimalizuje pravdepodobné pokračovanie, nie automatické overenie každého tvrdenia.

Keď jazykový model uvedie neexistujúci rozsudok, zamení autora vedeckej práce, doplní do súhrnu udalosť, ktorá v zdroji nie je, alebo presvedčivo vysvetlí chybný predpoklad otázky, hovoríme zvyčajne o halucinácii. Tento pojem označuje jeden z najvýznamnejších problémov generatívnej AI: systém dokáže vytvoriť jazykovo kvalitný text aj vtedy, keď pre jeho tvrdenia nemá spoľahlivú oporu. Halucinácia neznamená, že model „klame“ v ľudskom psychologickom zmysle. Klamstvo predpokladá presvedčenie, poznanie pravdy a úmysel uviesť niekoho do omylu. Samotný LLM je však pravdepodobnostný model tokenových sekvencií, ako sme vysvetlili v kapitole 1. Jeho bezprostrednou operáciou je výpočet pravdepodobností ďalšieho tokenu, nie konzultácia vnútornej encyklopédie s garantovanými záznamami. Preto môže byť nepravdivý výstup plynulý, štruktúrovaný a štylisticky nerozoznateľný od správneho. Táto kapitola vytvorí presný slovník, vysvetlí hlavné príčiny a ukáže, ako sa halucinácie merajú, odhaľujú a obmedzujú. Detailný návrh systémov s externými zdrojmi rozoberie kapitola 7 - Retrieval Augmented Generation, všeobecné hranice schopností kapitola 12 - Limity jazykových modelov a rozhodovanie o praktickej dôvere kapitola 15 - Kedy AI dôverovať a kedy nie.

Ťažisko tvoria časti „Čo presne nazývame halucináciou“, „Prečo je slovo „halucinácia“ iba metafora“ a „Faktickosť a vernosť nie sú to isté“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť rozlíšiť faktickú chybu, neistotu a neaktuálnu informáciu a vysvetliť príčiny presvedčivo formulovaných omylov. Praktickým výsledkom bude schopnosť navrhnúť overovanie podľa dopadu odpovede.

Kapitola odpovedá aj na otázku „Prečo halucinácia znie tak presvedčivo?“ Model je trénovaný na tvorbu jazykovo pravdepodobného textu. Plynulosť a sebavedomý štýl preto nemusia korešpondovať s faktickou istotou.

Kapitola 05 · 36 min čítania Zadarmo po registrácii

Kontextové okno je pracovný priestor modelu pre aktuálnu požiadavku. Nejde o ľudskú pamäť a jeho veľkosť sama osebe nezaručuje, že model použije každú vloženú informáciu správne.

Keď používateľ vloží do chatbota otázku, zmluvu, staršiu konverzáciu a tabuľku, model nepracuje s každým prvkom oddelene. Aplikácia z nich vytvorí vstupnú sekvenciu tokenov. Táto sekvencia je dočasným pracovným prostredím, v ktorom model interpretuje pokyny a vypočítava ďalšie tokeny odpovede. Jej maximálny rozsah sa označuje ako context window, po slovensky kontextové okno. Okno je jednou z najviditeľnejších technických vlastností moderných LLM. Umožňuje analyzovať celé reporty, dlhšie úseky kódu, viac dokumentov či rozsiahlu konverzáciu. Zároveň patrí k najčastejšie nesprávne interpretovaným parametrom. Údaj „128K“ alebo „1M tokenov“ neznamená, že model všetko v takom vstupe chápe ako odborník, že si obsah uloží natrvalo ani že dokáže rovnako presne pracovať s každou pozíciou. V kapitole 1 - Čo je Large Language Model sme rozlíšili model od aplikácie a v kapitole 2 - Tokeny a ich význam sme vysvetlili tokenizáciu. Teraz tieto základy spojíme s attention, pozičnou informáciou, pamäťou pri inferencii a prácou s dlhými vstupmi.

Ťažisko tvoria časti „Čo je kontext v jednom volaní modelu“, „Kontextové okno, dĺžka vstupu a výstupný limit“ a „Tokeny nie sú slová ani strany“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť rozlíšiť kontextové okno, parametre modelu a externú pamäť a navrhnúť poradie a štruktúru dlhého vstupu. Praktickým výsledkom bude schopnosť testovať stratu informácií v rozsiahlych dokumentoch.

Kapitola odpovedá aj na otázku „Čo sa počíta do kontextového okna?“ Systémové inštrukcie, história rozhovoru, vložené dokumenty, aktuálna otázka, výsledky nástrojov a často aj pripravovaná odpoveď.

Kapitola 06 · 38 min čítania Zadarmo po registrácii

Fine-tuning má zmysel vtedy, keď treba opakovane meniť správanie modelu, nie keď mu iba chýba aktuálny fakt. Pred výberom metódy treba oddeliť problém znalostí, štýlu a procesu.

Predtrénovaný jazykový model pozná všeobecné jazykové vzory a množstvo faktických či procedurálnych súvislostí, ale nemusí sa správať ako užitočný asistent. Môže iba pokračovať v texte, nepoznať požadovaný firemný formát alebo nespoľahlivo rozlišovať konkrétne kategórie. Fine-tuning mení jeho parametre alebo k modelu pridáva malé trénovateľné komponenty tak, aby sa zvýšila pravdepodobnosť požadovaných výstupov. Najjednoduchší príklad obsahuje vstup a kvalitnú cieľovú odpoveď. Model vygeneruje distribúciu tokenov, vypočíta stratu voči cieľu, gradient a aktualizáciu parametrov. Po mnohých príkladoch sa učí nielen slovník, ale aj spôsob interpretácie úlohy, štruktúru odpovede, rozhodovacie hranice a štýl demonštrácií. Fine-tuning však nie je automatický import databázy ani univerzálna oprava modelu. Úzky dataset môže zlepšiť cieľovú úlohu a súčasne poškodiť všeobecné schopnosti, bezpečnosť či kalibráciu. Preto nadväzujeme na celý životný cyklus z kapitoly 3 - Tréning modelov, riziko halucinácií a prácu s kontextovým oknom. Externé meniace sa poznanie bude osobitne riešiť kapitola 7 - RAG. Teacher forcing poskytne modelu pri každej tréningovej pozícii správny prefix cieľovej odpovede a požaduje predikciu ďalšieho tokenu.

Ťažisko tvoria časti „Čo sa pri fine-tuningu matematicky deje“, „Kde fine-tuning patrí v životnom cykle“ a „Čo fine-tuning dokáže a čo negarantuje“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť rozlíšiť fine-tuning od promptovania a RAG a určiť vhodné prípady pre dolaďovanie modelu. Praktickým výsledkom bude schopnosť navrhnúť dáta a evaluáciu pred spustením tréningu.

Kapitola odpovedá aj na otázku „Kedy použiť fine-tuning?“ Keď potrebujete stabilne meniť formát, štýl alebo správanie v opakovanej úlohe a máte kvalitné príklady aj spôsob merania výsledku.

Kapitola 07 · 45 min čítania Zadarmo po registrácii

RAG nie je iba vloženie dokumentu do promptu. Je to celý reťazec od spracovania a oprávnení cez vyhľadanie správnej pasáže až po odpoveď, citáciu a meranie kvality.

Moderný jazykový model dokáže plynulo formulovať odpoveď, no jeho parametre nie sú živou, úplnou ani transparentnou databázou. Nevie automaticky, čo sa v organizácii zmenilo včera, z ktorého dokumentu pochádza konkrétny údaj ani či používateľ smie daný dokument vidieť. Retrieval Augmented Generation, skrátene RAG, rieši časť tohto problému tým, že pred generovaním alebo počas neho vyhľadá relevantné externé podklady a vloží ich do pracovného kontextu modelu. Používateľ sa napríklad opýta, dokedy možno reklamovať konkrétny produkt. Systém nežiada model, aby sa spoliehal iba na pravdepodobnosti uložené vo váhach. Najprv vyhľadá platné obchodné podmienky, získa príslušné odseky, pridá ich do promptu s identifikátormi zdrojov a až potom požiada model o odpoveď. Ak je systém správne navrhnutý, odpoveď sa opiera o dohľadateľný dôkaz a pri zmene smernice stačí aktualizovať zdrojový korpus. RAG však nie je automatická záruka pravdy. Retriever môže vybrať nesprávny dokument, parser stratiť tabuľku, index obsahovať starú verziu, generátor môže dôkaz ignorovať a citácia môže iba zdanlivo podporovať tvrdenie. Kapitola preto nadväzuje na halucinácie AI, kontextové okno a fine-tuning.

Ťažisko tvoria časti „Čo presne znamená Retrieval Augmented Generation“, „Prečo RAG vznikol“ a „Dve pamäte a pravdepodobnostný pohľad“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť opísať komponenty produkčného RAG systému a rozlíšiť chybu vyhľadávania od chyby generovania. Praktickým výsledkom bude schopnosť navrhnúť hodnotenie relevancie, vernosti a oprávnení.

Kapitola odpovedá aj na otázku „Čo rieši RAG?“ Dodáva modelu relevantné externé pasáže v čase odpovede, čo pomáha pracovať s internými alebo aktuálnymi informáciami bez pretrénovania základného modelu.

Kapitola 08 · 42 min čítania Zadarmo po registrácii

Multimodálny systém spája text, obraz, zvuk alebo video do spoločnej úlohy. Každá modalita však prináša vlastnú neistotu, náklady a bezpečnostné hranice.

ChatGPT a ďalšie moderné AI systémy už nie sú iba textové rozhrania. Používateľ môže nahrať fotografiu, odfotiť tabuľu, diktovať otázku, analyzovať graf, viesť hlasový rozhovor alebo požiadať o vytvorenie obrázka. Za jednoduchým používateľským zážitkom sa však skrýva viac možných architektúr. Niekedy jedna neurónová sieť pracuje s tokenmi rôznych modalít, inokedy aplikácia spája samostatný model na rozpoznávanie reči, jazykový model a syntetizátor hlasu. Produkt preto môže pôsobiť multimodálne, aj keď jeho jadro tvorí reťazec špecializovaných komponentov. Táto kapitola vysvetľuje, ako sa obraz, zvuk a video menia na reprezentácie, s ktorými dokáže pracovať transformer; ako sa modality prepájajú pri tréningu; v čom sa líši porozumenie od generovania; a prečo multimodalita rozširuje schopnosti aj priestor na chyby. Nadväzuje najmä na tokeny a ich význam, tréning modelov, halucinácie AI a kontextové okno. Bez týchto základov by sa multimodálny model ľahko javil ako stroj, ktorý jednoducho „vidí a počuje“. Presnejšie je povedať, že sa učí matematicky spracúvať a spájať štruktúrované signály. Text je diskrétna sekvencia symbolov, ktorú jazykový model zvyčajne rozdelí na tokeny. Digitálny obraz je mriežka hodnôt pixelov.

Ťažisko tvoria časti „Čo je modalita“, „Kedy je model multimodálny“ a „Multimodálny systém nie je nevyhnutne jeden model“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť vysvetliť základný princíp práce s viacerými modalitami a rozpoznať chyby OCR, obrazu, reči a časového kontextu. Praktickým výsledkom bude schopnosť navrhnúť kontrolu multimodálneho pracovného postupu.

Kapitola odpovedá aj na otázku „Čo znamená multimodálny model?“ Dokáže prijímať alebo vytvárať viac druhov informácií, napríklad text, obraz, zvuk či video, a prepájať ich v jednej úlohe.

Kapitola 09 · 40 min čítania Zadarmo po registrácii

Voľba medzi otvoreným a komerčným modelom nie je súboj ideológií. Je to architektonické rozhodnutie o kontrole, nákladoch, prevádzke, súkromí, podpore a možnosti odísť k inému riešeniu.

Diskusia o otvorených a komerčných modeloch býva zjednodušená na súboj dvoch táborov. Na jednej strane má byť „open source“: lacný, transparentný a úplne pod kontrolou používateľa. Na druhej strane „komerčný model“: výkonnejší, jednoduchší, ale uzavretý a drahý. Takéto rozdelenie nezodpovedá realite. Otvorené váhy možno prevádzkovať ako platenú cloudovú službu a proprietárny poskytovateľ môže ponúkať bezplatnú úroveň. Model s verejným kódom nemusí zverejniť tréningové dáta a model s neverejnými váhami môže publikovať podrobnú bezpečnostnú dokumentáciu. Preto treba oddeliť aspoň tri otázky. Čo je otvorené? Môžu to byť váhy, zdrojový kód, tréningové dáta, recept, evaly alebo dokumentácia. Za akých právnych podmienok? Verejné stiahnutie ešte neznamená slobodu model používať, meniť a ďalej šíriť na každý účel. Ako sa model prevádzkuje? Organizácia môže použiť externé API, riadený endpoint s otvorenými váhami alebo vlastnú infraštruktúru. Kapitola nadväzuje na tréning modelov, fine-tuning, RAG a multimodálne modely. Tieto technické vrstvy určujú, čo organizácia potrebuje od modelu a čo musí vedieť reprodukovať.

Ťažisko tvoria časti „Prečo názov témy vytvára falošnú dichotómiu“, „Základná terminológia“ a „AI model je súbor artefaktov, nie jeden súbor“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť porovnať otvorené váhy, lokálnu prevádzku a spravované API a vypočítať celkové náklady namiesto porovnania jednej ceny. Praktickým výsledkom bude schopnosť navrhnúť test kvality, bezpečnosti a prenositeľnosti.

Kapitola odpovedá aj na otázku „Znamená open source automaticky bezplatné riešenie?“ Nie. Aj bez licenčného poplatku vznikajú náklady na hardvér, prevádzku, aktualizácie, bezpečnosť, monitoring a odborný tím.

Kapitola 10 · 54 min čítania Zadarmo po registrácii

GPT, Claude, Gemini a Grok nemožno férovo zoradiť jedným rebríčkom. Porovnáva sa konkrétna verzia, produkt, konfigurácia a výkon na reálnej úlohe - vrátane slovenčiny, nákladov a dátových podmienok.

Aktualizované: september 2026. Názvy, verzie a dostupnosť modelov sa menia podstatne rýchlejšie než princípy ich hodnotenia. Preto táto kapitola nie je rebríčkom „najlepších chatbotov“. Ukazuje, ako oddeliť značku, konkrétny model, aplikáciu a celý pracovný systém - a ako ich porovnať na vlastnej úlohe. Ak si chcete najprv ujasniť rozdiel medzi modelom a produktom, začnite kapitolou Čo je Large Language Model. Otázku otvorených váh a spravovaných služieb rozoberá Open-source vs. komerčné modely. Tieto názvy nie sú technické špecifikácie. Provider môže pod jednou značkou ponúkať rýchly lacnejší model, model pre komplexné uvažovanie, multimodálny model alebo špecializovaný variant. Produkt môže navyše automaticky prepínať model podľa požiadavky. Tvrdenie „Claude odpovedal lepšie než GPT“ je preto neúplné, ak nepoznáme presnú verziu, dátum, režim, prompt a dostupné nástroje. Rozlišujte aspoň štyri vrstvy: provider → modelová verzia → produkt alebo API → konkrétna konfigurácia.

Ťažisko tvoria časti „Štyri názvy, nie štyri nemenné produkty“, „Čo sa dá z dokumentácie zistiť - a čo nie“ a „GPT: široký ekosystém a oddelenie modelu od ChatGPT“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť odlíšiť značku, model, aplikáciu a konkrétnu konfiguráciu a navrhnúť porovnávací eval na vlastných slovenských prípadoch. Praktickým výsledkom bude schopnosť vybrať model podľa prahov kvality, rizika, ceny a prenositeľnosti.

Kapitola odpovedá aj na otázku „Ktorý model je dnes najlepší - GPT, Claude, Gemini alebo Grok?“ Bez konkrétnej úlohy neexistuje zodpovedná odpoveď. Porovnajte presné verzie s rovnakými podkladmi na vlastných prípadoch a samostatne merajte kvalitu, bezpečnosť, latenciu a cenu úspešného výsledku.

Kapitola 11 · 53 min čítania Zadarmo po registrácii

LLM nenačíta hotovú vetu z databázy. Opakovane vypočítava distribúciu ďalšieho tokenu; výsledok preto ovplyvňuje každý skorší token, decoding, zostavený kontext aj nástroje okolitej aplikácie.

Keď chatbot vypíše vetu plynulo po slovách, môže pôsobiť, akoby si odpoveď najprv celú premyslel a potom ju iba prepísal. Základný mechanizmus je iný: model opakovane vypočítava pravdepodobnosti ďalšieho tokenu, jeden vyberie, pridá ho ku kontextu a proces zopakuje. Používateľ vidí svoju otázku, no model často dostane širší balík. Môže obsahovať systémovú inštrukciu, pravidlá produktu, históriu rozhovoru, používateľské preferencie, relevantné dokumenty, výsledky nástrojov a požadovaný formát odpovede. Poradie a hranice správ sú dôležité. Systémové pravidlo má mať vyššiu prioritu než text používateľa, ale dokument vložený do promptu môže obsahovať vetu tváriacu sa ako inštrukcia. Bez správnej izolácie vzniká prompt injection. Model totiž dostáva dôveryhodný pokyn aj nedôveryhodné dáta v podobnej textovej reprezentácii. Pred odoslaním sa vstup niekedy skráti, zhrnie alebo doplní retrievalom. Preto dve aplikácie používajúce rovnaký model môžu odpovedať zásadne odlišne. Tokenizer rozdelí text na tokeny a priradí im celočíselné identifikátory. Token môže byť slovo, časť slova, medzera, interpunkcia alebo fragment kódu. Presné delenie závisí od slovníka modelu.

Ťažisko tvoria časti „Krok 1: aplikácia zostaví skutočný vstup“, „Krok 2: tokenizer zmení text na identifikátory“ a „Krok 3: embeddingy preložia ID do vektorov“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť popísať cestu od promptu cez transformer k ďalšiemu tokenu a vysvetliť vplyv temperature, top-p a opakovaného generovania. Praktickým výsledkom bude schopnosť odlíšiť návrh tool callu od bezpečného vykonania akcie.

Kapitola odpovedá aj na otázku „Generuje model odpoveď celú naraz?“ Nie. Autoregresívny model vyberá ďalší token, pridá ho ku kontextu a proces opakuje až po stop podmienku alebo limit.

Kapitola 12 · 52 min čítania Zadarmo po registrácii

Plynulosť zakrýva rozdiel medzi chýbajúcim dôkazom, krehkým uvažovaním, prehliadnutým kontextom a chybou celého systému. Každý limit preto potrebuje konkrétne meno, meranie a kontrolu.

Jazykový model môže v jednej minúte opraviť kód, zhrnúť zmluvu a vytvoriť presvedčivý odborný text. Táto šírka ľahko vyvolá dojem, že jeho zostávajúce chyby sú iba drobné nedostatky, ktoré odstráni ďalšia verzia. V skutočnosti pochádzajú z viacerých vrstiev: z tréningového cieľa, dát, rozhrania, nástrojov aj spôsobu nasadenia. Mechanizmus, z ktorého časť limitov vyrastá, vysvetľuje Ako modely generujú odpovede. Praktický rámec pre rozhodovanie uzatvorí kapitola Kedy AI dôverovať a kedy nie. Rovnaká chybná veta môže mať inú príčinu. Vymyslený zákon môže vzniknúť z chýbajúcej aktuálnej databázy, zle nájdeného dokumentu, nesprávnej interpretácie správnej pasáže alebo z promptu, ktorý model núti odpovedať aj bez dôkazu. Bez diagnózy sa ľahko nasadí nesprávna oprava. Halucinácia je fakticky alebo zdrojovo nepodložený výstup podaný ako odpoveď. Model môže vymyslieť citáciu, zmeniť číslo alebo doplniť chýbajúci detail. Samostatná kapitola Halucinácie AI vysvetľuje príčiny a mitigácie. Preto nehodnoťte iba „je veta pravdivá?“. Hodnoťte aj úplnosť, relevanciu, aktuálnosť, oprávnenie, kalibráciu neistoty a následok použitia.

Ťažisko tvoria časti „Päť druhov limitov, ktoré sa nesmú miešať“, „Halucinácia nie je jediný problém“ a „Model nepozná hranicu svojich vedomostí spoľahlivo“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť rozlíšiť epistemické, schopnostné, interakčné a systémové limity a navrhnúť eval s hraničnými, neodpovedateľnými a adversariálnymi prípadmi. Praktickým výsledkom bude schopnosť vytvoriť register limitov s vlastníkom a spúšťačom revízie.

Kapitola odpovedá aj na otázku „Sú halucinácie jediným významným limitom LLM?“ Nie. Model môže vynechať výnimku, zle použiť správny zdroj, zlyhať pri parafráze, prehliadnuť detail v dlhom kontexte alebo vykonať chybnú sériu krokov.

Kapitola 13 · 52 min čítania Zadarmo po registrácii

Model nie je bezpečnostná hranica. Systém musí chrániť dáta, nástroje a ľudí aj vtedy, keď modelový výstup obsahuje chybu, podľahne prompt injection alebo ho zámerne manipuluje útočník.

Bezpečnosť LLM nie je jedno tlačidlo „safe“. Zahŕňa odolnosť voči útokom, ochranu súkromia, obmedzenie škodlivého obsahu, spoľahlivú prevádzku aj jasnú zodpovednosť. Model môže mať kvalitný safety post-training a napriek tomu byť súčasťou nebezpečnej aplikácie s príliš širokými oprávneniami. Najprv si prečítajte Limity jazykových modelov. Táto kapitola pridáva protivníka: človeka alebo obsah, ktorý sa aktívne snaží systém oklamať. LLM spracúva dôveryhodné inštrukcie aj nedôveryhodný obsah ako tokeny. Môže sa naučiť rešpektovať hierarchiu správ, ale nie je kryptografickým ani autorizačným mechanizmom. Prompt „nikdy neprezraď tajomstvo“ nesmie byť jedinou ochranou tajomstva. Pred mitigáciami určte, čo chránite: osobné údaje, interné dokumenty, system prompt, API kľúče, peniaze, reputáciu, dostupnosť služby či rozhodovacie práva. Potom zmapujte aktérov, vstupné kanály a hranice dôvery. Threat model sa robí pre konkrétny dátový tok. Všeobecná veta „používame bezpečný model“ neidentifikuje žiadnu hranicu ani kontrolu. Pri priamej prompt injection útočník napíše pokyn do konverzácie.

Ťažisko tvoria časti „Model nie je bezpečnostná hranica“, „Threat model začína aktívami, nie zoznamom útokov“ a „Prompt injection: inštrukcia ukrytá v dátach“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť odlíšiť safety, security, privacy a reliability a zmapovať prompt injection, únik dát, nadmernú agentnosť a supply-chain riziká. Praktickým výsledkom bude schopnosť navrhnúť defense-in-depth tok s minimálnymi právami a incidentným plánom.

Kapitola odpovedá aj na otázku „Zabráni dobrý system prompt všetkým útokom?“ Nie. Je iba jednou vrstvou. Tajomstvá a akcie musia chrániť autentifikácia, autorizácia, izolácia, validácia, limity a potvrdenie mimo modelu.

Kapitola 14 · 52 min čítania Zadarmo po registrácii

Budúcnosť LLM nebude iba príbehom väčších modelov. Výsledok vytvoria efektívnejší tréning, výpočet počas odpovede, multimodalita, nástroje, menšie lokálne modely, energia a schopnosť preukázať kontrolu.

Predpovede o jazykových modeloch často miešajú tri odlišné veci: čo už bolo demonštrované v laboratóriu, čo sa dá spoľahlivo prevádzkovať a čo by raz mohlo byť možné. Zodpovedný pohľad ich oddeľuje a pomenúva neistotu. Predikcia tvrdí, čo je najpravdepodobnejšie. Scenár opisuje konzistentnú možnosť a jej dôsledky. Rozhodnutie určuje, čo urobíme dnes napriek neistote. Pri rýchlom technologickom vývoji je scenárové myslenie robustnejšie než presný kalendár. Výrok „AGI príde v roku X“ bez merateľnej definície AGI a kalibrovanej neistoty nie je praktický plán. Organizácia potrebuje skôr vedieť, ktoré úlohy automatizovať, aké dáta pripraviť a kde ponechať zodpovedného človeka. Scaling laws ukázali pravidelné zlepšovanie tréningovej straty s rastom modelu, dát a výpočtu v skúmaných režimoch. Práca Chinchilla zároveň zdôraznila, že veľkosť modelu a množstvo tréningových tokenov treba vyvažovať. Z toho nevyplýva nekonečný automatický rast všetkých praktických schopností. Hrubý počet parametrov bude čoraz slabším opisom systému. Model s menej aktívnymi parametrami môže vďaka nástrojom a test-time compute prekonať väčší model na konkrétnej úlohe. Klasický chatbot vytvorí jednu trajektóriu tokenov.

Ťažisko tvoria časti „Predikcia, scenár a záväzné rozhodnutie“, „Smer 1: scaling pokračuje, ale mení tvar“ a „Smer 2: viac výpočtu počas odpovede“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť odlíšiť demonštráciu, produkčnú schopnosť a špekulatívnu predpoveď a sledovať merateľné signály vo výpočte, agentnosti, evaloch a infraštruktúre. Praktickým výsledkom bude schopnosť pripraviť stratégiu odolnú voči viacerým scenárom vývoja.

Kapitola odpovedá aj na otázku „Budú budúce modely iba väčšie?“ Nie nevyhnutne. Výkon môže rásť aj cez kvalitnejšie dáta, efektívnejšie architektúry, test-time compute, nástroje, verifikáciu a špecializované menšie modely.

Kapitola 15 · 52 min čítania Zadarmo po registrácii

Dôvera nepatrí logu ani plynulému štýlu. Patrí konkrétnej úlohe, verzii systému a dôkazom, že jeho kontroly zodpovedajú závažnosti, vratnosti, overiteľnosti, citlivosti dát a miere autonómie.

Otázka „môžem dôverovať tejto AI?“ je príliš široká. Tomu istému modelu možno primerane dôverovať pri návrhu desiatich titulkov a zároveň mu neslobodno prenechať rozhodnutie o diagnóze alebo prevode peňazí. Dôvera patrí konkrétnemu systému, úlohe, dôkazom a následku - nie značke. Model môže mať vysokú presnosť na testovacej množine a napriek tomu byť nevhodný pre konkrétne rozhodnutie. Dôveryhodnosť systému zahŕňa viac charakteristík. NIST uvádza validitu a spoľahlivosť, bezpečnosť, security a odolnosť, zodpovednosť a transparentnosť, vysvetliteľnosť, ochranu súkromia a riadenie škodlivého skreslenia. Tieto vlastnosti sa musia vyvažovať podľa kontextu. Presný systém, ktorý neoprávnene zverejní zdravotný údaj, nie je dôveryhodný. Súkromný systém, ktorý systematicky diskriminuje, tiež nie. Dôvera preto nevzniká jedným skóre. Najpresnejšia otázka znie: Je táto verzia systému pri tejto úlohe, s týmito dátami a kontrolami dostatočne spoľahlivá vzhľadom na následok chyby? Čo sa stane, ak je výstup nesprávny? Chybný návrh sloganu môže stáť čas. Chybná dávka lieku, právna lehota alebo odmietnutý úver môže poškodiť zdravie, práva či financie. Dá sa chyba lacno vrátiť?

Ťažisko tvoria časti „Dôvera je vlastnosť vzťahu a použitia“, „Päť osí rozhodnutia“ a „Zelená, žltá a červená zóna“. Nejde iba o vysvetlenie pojmov. Kapitola ich prepája s rozhodnutiami, príkladmi a hranicami, ktoré treba poznať pri reálnom použití.

Po prečítaní budete vedieť zaradiť použitie AI do zelenej, žltej alebo červenej zóny a zvoliť primeraný stupeň nezávislého overenia. Praktickým výsledkom bude schopnosť nastaviť stop pravidlá, ľudský dohľad a dôkazový záznam.

Kapitola odpovedá aj na otázku „Kedy možno výstup AI použiť s jednoduchou kontrolou?“ Pri nízkom dopade, vysokej vratnosti a ľahkom overení - napríklad pri brainstormingu alebo prvom návrhu textu, ktorý človek pred použitím prečíta.