AI bez halucinácií neexistuje. Dá sa však výrazne znížiť ich počet

Keď sme na prelome rokov 2025 a 2026 začali intenzívnejšie pracovať s AI nad odbornými dátami, predstava bola pomerne jednoduchá.

Ak jazykovému modelu dodáme kvalitné odborné podklady, správne ich spracujeme, uložíme do vyhľadateľnej znalostnej vrstvy a nastavíme prísne pravidlá odpovedania, výsledkom bude AI, ktorá si nebude vymýšľať.

Realita je komplikovanejšia.

Kvalitné zdroje, RAG, vektorové vyhľadávanie, dobré inštrukcie a systematické testovanie dokážu počet nesprávnych odpovedí výrazne znižovať.

Nemôžeme však z toho urobiť absolútny sľub:

„Táto AI nikdy nebude halucinovať.“

Takéto tvrdenie by samo osebe nebolo zodpovedné.

Presnejšie je povedať:

„Systém navrhujeme tak, aby minimalizoval priestor na vymýšľanie, odpovede opieral o overené zdroje a pri nedostatku informácií radšej priznal neistotu.“

A práve to je podľa našich skúseností správny cieľ pri profesionálnych firemných AI riešeniach.

Čo vlastne znamená, keď AI „halucinuje“?

Pod pojmom halucinácia sa pri jazykových modeloch zvyčajne myslí situácia, keď model vytvorí vierohodne znejúcu, ale nesprávnu alebo nepodloženú informáciu.

Problém je v tom, že nesprávna odpoveď nemusí vyzerať nesprávne.

Môže byť:

• gramaticky perfektná,
• logicky formulovaná,
• sebavedomá,
• doplnená vysvetlením,
• a napriek tomu fakticky chybná.

Pri firemnom použití je práve toto nebezpečné.

Zákazník často nedokáže na prvý pohľad rozlíšiť, či odpoveď pochádza zo skutočných firemných dát alebo ju model pravdepodobne doplnil.

Halucinácia nemusí znamenať úplne vymyslený príbeh

Často ide o oveľa jemnejší problém.

Napríklad:

Vymyslený údaj

„Pri objednávke nad 500 kusov poskytujeme zľavu 15 %.“

Hoci firma žiadnu takúto zľavu nemá definovanú.

Nesprávny detail

Dokument uvádza:

„30 dní“

AI odpovie:

„Lehota je 14 dní.“

Nepodložený záver

Produkt má výkon 1 100 W.

AI z toho vytvorí tvrdenie:

„Tento model je ideálny pre každú veľkú záhradu.“

Hoci takýto záver zo samotného výkonu nevyplýva.

Vymyslený zdroj

AI môže uviesť dokument, paragraf, štúdiu alebo webovú stránku, ktorá dané tvrdenie v skutočnosti nepodporuje alebo vôbec neexistuje.

Zastaraná pravda prezentovaná ako aktuálna

Agent má z minulého týždňa informáciu:

„Produkt je skladom.“

Dnes je vypredaný.

Ak AI použije starý údaj bez overenia, výsledná odpoveď je nesprávna, aj keď pôvodná informácia bola kedysi pravdivá.

Prečo sa to deje?

Veľký jazykový model nie je klasická databáza faktov.

Pri generovaní textu pracuje s pravdepodobnosťou ďalšieho obsahu na základe vzorov, ktoré získal počas tréningu a z aktuálneho kontextu.

To mu umožňuje mimoriadne dobre:

• rozumieť prirodzenému jazyku,
• vysvetľovať,
• sumarizovať,
• prepájať informácie,
• pracovať s neštruktúrovaným textom.

Zároveň to však znamená, že ak nemá dostatok spoľahlivých informácií, môže vytvoriť odpoveď, ktorá jazykovo dáva zmysel, ale fakticky nie.

Pre firemný systém preto nie je správne spoliehať sa iba na všeobecné znalosti modelu.

Veľmi dôležité pravidlo: AI nemusí vedieť všetko

Pri návrhu odborného agenta sa niekedy nevedomky snažíme dosiahnuť:

„Nech odpovie na každú otázku.“

To však môže byť zlý cieľ.

Profesionálnejší cieľ môže byť:

„Nech odpovie vždy, keď má dostatočné a overiteľné podklady. V ostatných prípadoch nech prizná, že informáciu nemá.“

Odpoveď:

„V dostupných podkladoch túto informáciu nemám.“

nie je zlyhaním AI.

V mnohých situáciách je to presne správny výsledok.

Sebavedomá nesprávna odpoveď je horšia než priznanie neistoty

Predstavme si odborného poradcu.

Používateľ sa opýta na údaj, ktorý v zdrojoch nie je.

Agent A

„Presná hodnota je 17,5 %.“

Číslo si však vymyslel.

Agent B

„V dostupných podkladoch presnú hodnotu nevidím. Ak chcete, môžem skúsiť nájsť súvisiaci zdroj alebo otázku odovzdať odborníkovi.“

Agent B pôsobí možno menej „magicky“.

Pre odborné použitie je však jeho správanie podstatne hodnotnejšie.

Ako teda halucinácie znižujeme?

Nie jedným promptom.

A nie jednou technológiou.

Je to kombinácia viacerých vrstiev.

KVALITNÉ ZDROJE
       |
       v
SPRÁVNE SPRACOVANIE DÁT
       |
       v
RETRIEVAL / RAG
       |
       v
PRAVIDLÁ ODPOVEDANIA
       |
       v
AKTUÁLNE FIREMNÉ DÁTA
       |
       v
VALIDÁCIA
       |
       v
EVALY A TESTOVANIE
       |
       v
MONITORING

Každá vrstva odstraňuje inú skupinu problémov.

1. Začína sa to zdrojovými dátami

Ak chceme AI, ktorá odpovedá pravdivo, potrebujeme najskôr kvalitný zdroj pravdy.

Ak firemná knowledge base obsahuje:

• zastarané dokumenty,
• rozporuplné pravidlá,
• nepresné produktové popisy,
• duplicity,
• nekvalitné prepisy,

AI z nich nedokáže spoľahlivo vytvoriť správnu odpoveď.

Dokonca môže nesprávnu informáciu formulovať tak dobre, že bude pôsobiť dôveryhodnejšie než pôvodný chybný dokument.

Preto je prvá otázka:

„Máme vôbec kvalitný a jednoznačný zdroj informácií?“

Garbage in, garbage out platí pri AI veľmi presne

Predstavme si dve smernice:

Smernica 2024:
lehota 14 dní

Smernica 2026:
lehota 30 dní

Obe sú vo vektorovej databáze.

Ak systém nevie, ktorá verzia je platná, môže nájsť nesprávny dokument.

Model potom odpovie podľa toho, čo dostal.

V takom prípade nepomôže ani dokonale formulovaný prompt.

Najskôr musíme vyriešiť správu zdrojov.

2. Definujeme source of truth

Pri každom type informácie by sme mali vedieť, ktorý systém je rozhodujúci.

Napríklad:

Informácia	Zdroj pravdy
Aktuálna cena	E-shop alebo ERP
Sklad	Skladový systém
Stav objednávky	Objednávkový systém
Technické parametre	Produktová databáza alebo schválená dokumentácia
Interný postup	Aktuálna verzia firemnej smernice
Odborné vysvetlenie	Schválená knowledge base

Agent potom nemusí rozhodovať podľa toho, ktorý text „znie najlepšie“.

Má jasne určený autoritatívny zdroj.

3. RAG: namiesto hádania najskôr nájdeme relevantné podklady

RAG – Retrieval-Augmented Generation – patrí medzi najpraktickejšie techniky na zníženie priestoru na vymýšľanie pri práci s firemnými dokumentmi.

Princíp je:

OTÁZKA
   |
   v
VYHĽADANIE RELEVANTNÝCH INFORMÁCIÍ
   |
   v
OVERENÉ FIREMNÉ PODKLADY
   |
   v
JAZYKOVÝ MODEL
   |
   v
ODPOVEĎ

Model teda nemusí odpovedať iba zo svojich všeobecných znalostí.

Dostane konkrétny firemný kontext.

RAG však halucinácie neodstraňuje

Toto je mimoriadne dôležité.

Niekedy sa RAG prezentuje skoro ako:

„Dáme dokumenty do vektorov a AI prestane halucinovať.“

Tak to nefunguje.

RAG môže zlyhať viacerými spôsobmi.

Retrieval nájde nesprávny dokument

Model následne správne interpretuje nesprávny zdroj.

Retrieval nájde iba polovicu odpovede

Chýbajúca výnimka spôsobí neúplný záver.

Zdroj je sám nesprávny

AI iba reprodukuje chybu v dokumentácii.

Model podklad nesprávne interpretuje

Zdroj je správny, retrieval je správny, ale výsledná formulácia obsahuje chybný záver.

Preto RAG výrazne pomáha, ale nie je absolútnou poistkou.

4. Chunking môže rozhodovať o pravdivosti odpovede

Predstavme si dokument:

„Službu je možné zrušiť do 14 dní. Toto pravidlo sa však nevzťahuje na prípady, keď bolo poskytovanie služby začaté za podmienok uvedených v ďalšej časti.“

Ak spracovanie dokumentu vytvorí:

CHUNK 1:
Službu je možné zrušiť do 14 dní.

CHUNK 2:
Toto pravidlo sa však nevzťahuje...

a retrieval vráti iba prvý chunk, AI môže vytvoriť zavádzajúcu odpoveď.

Nie preto, že by si úplne vymyslela údaj.

Ale preto, že dostala neúplný kontext.

Aj technické spracovanie dokumentov je teda súčasťou boja proti halucináciám.

5. Metadata pomáhajú vybrať správny zdroj

K dokumentom alebo ich častiam môžeme ukladať napríklad:

document_id

version

valid_from

valid_to

language

category

product_id

source

access_level

Následne vieme retrieval obmedziť.

Napríklad:

„Hľadaj iba v dokumentoch platných pre Slovensko a iba v aktuálnych verziách.“

Metadata tak môžu výrazne pomôcť odstrániť situácie, keď AI dostane síce významovo podobný, ale nesprávny dokument.

6. Aktuálne údaje nepatria vždy do RAG

Jedna z najčastejších architektonických chýb je snaha uložiť všetko do knowledge base.

Predstavme si:

• cenu produktu,
• sklad,
• stav objednávky,
• dostupný termín.

Tieto hodnoty sa môžu rýchlo meniť.

Ak ich importujeme raz denne do vektorovej databázy, AI môže pracovať so starým údajom.

Lepšie môže byť načítať ich priamo zo systému v momente otázky.

Namiesto pamäti použijeme nástroj

Používateľ:

„Máte produkt X skladom?“

Agent nepoužije údaj z minulého rozhovoru.

Použije napríklad:

get_product_stock(product_id)

A dostane aktuálny výsledok.

Takýmto spôsobom znižujeme priestor, v ktorom by model musel údaj odhadovať.

7. Tool use oddeľuje jazyk od faktickej operácie

Veľkou výhodou agentových nástrojov je možnosť oddeliť dve veci.

AI je dobrá v:

• pochopení otázky,
• práci s prirodzeným jazykom,
• vysvetlení výsledku.

Klasický softvér je dobrý v:

• databázových dotazoch,
• výpočtoch,
• business pravidlách,
• validácii,
• transakciách.

Namiesto toho, aby sme od AI žiadali:

„Odhadni sklad.“

necháme databázu vrátiť presný sklad.

AI výsledok iba zrozumiteľne odkomunikuje.

8. Business pravidlá nemajú existovať iba v prompte

Predstavme si pravidlo:

„Adresu objednávky nemožno meniť po expedícii.“

Môžeme ho zapísať do promptu.

Ale ak ide o dôležité obchodné pravidlo, má ho zároveň vynucovať samotná aplikácia.

Napríklad:

if OrderStatus == Shipped
{
    ChangeAddress = false;
}

Agent môže požiadať o operáciu.

Aplikácia rozhodne, či je povolená.

Tým znižujeme závislosť od toho, či model správne interpretoval textovú inštrukciu.

9. Structured outputs znižujú priestor na nejasnosti

Niekedy nechceme od modelu voľný text.

Potrebujeme konkrétnu štruktúru.

Napríklad:

{
  "product_id": 8247,
  "quantity": 2,
  "action": "check_stock"
}

Aplikácia môže následne:

• overiť dátové typy,
• povolené hodnoty,
• existenciu produktu,
• oprávnenie používateľa.

Ak model vráti neplatnú hodnotu, nemusíme ju slepo použiť.

Validácia ju môže odmietnuť.

10. Validácia odpovede nemusí končiť pri modeli

Niektoré údaje vieme skontrolovať programovo.

Napríklad:

AI tvrdí:
Cena produktu = 249 €

Databáza:
Cena produktu = 199 €

Ak je cena dostupná v databáze, nie je dôvod veriť vygenerovanej hodnote.

Aplikácia môže vždy používať databázový údaj.

Čím viac vieme overiť deterministicky, tým menej musíme veriť generovaniu

To je podľa nás veľmi dôležitý princíp.

Nie všetko má rozhodovať AI.

Ak dokážeme údaj:

• načítať z databázy,
• vypočítať,
• validovať,
• porovnať s pravidlom,

mali by sme to často urobiť klasickou aplikačnou logikou.

11. Prompt je dôležitý, ale nie je všemocný

Dobré systémové inštrukcie sú veľmi užitočné.

Môžeme napríklad definovať:

Odpovedaj iba z dostupných zdrojov.

Ak informácia v zdrojoch nie je,
nepokúšaj sa ju dopĺňať.

Ak si zdroje odporujú,
upozorni na konflikt.

Ak potrebuješ aktuálny údaj,
použi príslušný nástroj.

Takéto pravidlá môžu výrazne zlepšiť správanie.

Prompt však nevyrieši:

• zlý dokument,
• nesprávny retrieval,
• zastaranú databázu,
• chybné API,
• zle navrhnuté oprávnenia.

Preto profesionálny AI systém nie je iba „výborne napísaný prompt“.

12. Explicitne povoľte agentovi povedať „neviem“

Ak systém očakáva odpoveď za každú cenu, prirodzene vytvára tlak na dopĺňanie chýbajúcich informácií.

Oveľa bezpečnejšie môže byť definovať:

„Ak nemáš dostatočný podklad, odpoveď nevymýšľaj.“

A ponúknuť ďalší krok.

Napríklad:

• spresniť otázku,
• vyhľadať ďalší zdroj,
• kontaktovať človeka,
• vytvoriť ticket.

Priznanie neistoty však nesmie byť iba naučená fráza

Agent, ktorý pri každej trochu zložitejšej otázke odpovie:

„Neviem.“

nie je veľmi užitočný.

Musíme preto hľadať rovnováhu medzi:

• užitočnosťou,
• presnosťou,
• ochotou priznať neistotu.

A práve preto potrebujeme evaly.

13. Testujeme aj otázky, na ktoré odpoveď neexistuje

Jedna z najlepších skúšok odborného AI systému je úmyselne sa opýtať na niečo, čo v podkladoch nie je.

Napríklad:

„Akú presnú zľavu dostanem pri objednávke 12 000 kusov?“

Ak žiadne také pravidlo neexistuje, očakávaný výsledok je:

„V dostupných podkladoch nemám definovanú zľavu pre tento objem.“

Nie náhodné percento.

14. Testujeme aj veľmi podobné otázky

Predstavme si dve otázky:

„Aký je postup pri reklamácii spotrebiteľa?“

a:

„Aký je postup pri reklamácii firemného zákazníka?“

Ak má firma rozdielne procesy, agent ich nesmie zameniť.

Takéto testy veľmi dobre odhaľujú problémy v retrieval vrstve.

15. Evals: halucinácie musíme merať, nie iba cítiť

Pri vývoji AI sa dá ľahko skĺznuť k hodnoteniu:

„Mne sa zdá, že nová verzia odpovedá lepšie.“

To nestačí.

Potrebujeme referenčný dataset.

Napríklad:

200 testovacích otázok

- 80 jednoduchých faktických
- 40 komplikovanejších
- 30 bez odpovede
- 20 konfliktných
- 20 s nástrojmi
- 10 bezpečnostných

Čísla sú iba ilustračným príkladom.

Dôležité je pokrytie reálnych typov problémov.

Pri každej otázke môžeme hodnotiť viac vlastností

Napríklad:

Metrika	Čo kontrolujeme
Correctness	Je odpoveď fakticky správna?
Groundedness	Vyplývajú tvrdenia z dodaných zdrojov?
Retrieval	Našiel systém správny zdroj?
Completeness	Nechýba dôležitá časť odpovede?
Abstention	Vie systém správne neodpovedať?
Tool accuracy	Použil správny nástroj a parametre?

16. Regresné testovanie je mimoriadne dôležité

Predstavme si, že AI príliš často odpovedá:

„Nemám dostatok informácií.“

Upravíme prompt, aby bol agent aktívnejší.

Na pôvodných otázkach sa výsledok zlepší.

Ale pri otázkach bez odpovede začne viac hádať.

Ak testujeme iba problém, ktorý sme práve opravili, zmenu vyhodnotíme ako úspech.

Ak spustíme celý dataset, uvidíme regresiu.

Preto by mala každá významná zmena prejsť opakovaným testovaním.

17. Zmena modelu neznamená automaticky lepší výsledok

Novší alebo výkonnejší model môže byť pri niektorých úlohách lepší.

Môže však zároveň:

• odpovedať iným štýlom,
• používať nástroje inak,
• byť menej konzervatívny pri neistote,
• meniť dĺžku odpovedí.

Preto by sme pri zmene modelu mali spustiť rovnakú eval sadu a výsledky porovnať.

18. Citovanie zdrojov zvyšuje kontrolovateľnosť

Pri odborných systémoch môže byť veľmi užitočné zobraziť zdroj.

Napríklad:

Odpoveď: Žiadosť sa podáva do 30 dní.

Zdroj: Interná smernica X, verzia 4, časť 3.2.

Citácia sama osebe nezaručuje, že odpoveď je správna.

Ale výrazne zjednodušuje:

• kontrolu používateľom,
• kontrolu odborníkom,
• debugging,
• testovanie.

AI nesmie vymýšľať ani citácie

Ak systém ukazuje zdroje, odkazy by nemal generovať jazykový model iba z pamäte.

Lepšie je, ak aplikácia pracuje s konkrétnym identifikátorom zdroja.

Napríklad:

source_id = 8472

title = "Reklamačný poriadok"

version = "4.1"

Aplikácia následne zobrazí reálny dokument.

Tak znižujeme priestor na vymyslené názvy alebo odkazy.

19. Human in the loop zostáva veľmi silná ochranná vrstva

Nie každá operácia musí byť úplne autonómna.

Pri citlivých oblastiach môže agent:

1. vyhľadať informácie,
2. pripraviť návrh,
3. zhromaždiť podklady,
4. odovzdať ich človeku.

Človek vykoná finálne rozhodnutie.

Takýto model môže byť vhodný napríklad pre:

• zložité reklamácie,
• individuálne cenové ponuky,
• odborné stanoviská,
• citlivé zákaznícke prípady.

Autonómia má byť úmerná spoľahlivosti a riziku

Agent, ktorý vyhľadáva návod, môže mať vyššiu mieru autonómie.

Agent, ktorý má vrátiť zákazníkovi peniaze, má úplne inú úroveň rizika.

Preto sa nepýtame iba:

„Dokáže to AI?“

Ale aj:

„Aký bude následok, ak sa AI pomýli?“

20. Logovanie nám umožňuje zistiť, kde chyba vznikla

Ak používateľ oznámi:

„AI mi povedala nesprávny údaj.“

potrebujeme vedieť:

• akú otázku položil,
• aké dokumenty retrieval našiel,
• aké chunks dostal model,
• aké nástroje agent použil,
• aké výsledky nástroje vrátili,
• akú odpoveď model vytvoril.

Bez takéhoto pohľadu sa veľmi ťažko rozhoduje, čo treba opraviť.

Halucinácia nemusí byť chyba modelu

Pri analýze môžeme zistiť:

Model dostal nesprávny dokument

Problém je retrieval.

Dokument obsahoval chybu

Problém sú zdrojové dáta.

API vrátilo starý údaj

Problém je integrácia.

Model dostal správny údaj, ale zmenil ho

Problém je generovanie.

Ak všetko nazveme iba „AI halucinácia“, nenájdeme skutočnú príčinu.

21. Reálna prevádzka vytvára najhodnotnejšie testy

Programátor ani odborník nedokáže dopredu vymyslieť všetky otázky zákazníkov.

Po spustení preto potrebujeme sledovať najmä:

• otázky bez odpovede,
• slabé odpovede,
• nesprávne zdroje,
• neúspešné nástroje,
• eskalácie na človeka.

Každý reálny problém môže byť novým testovacím prípadom.

Vzniká cyklus priebežného zlepšovania

POUŽÍVATEĽ POLOŽÍ OTÁZKU
           |
           v
OBJAVÍ SA PROBLÉM
           |
           v
ANALÝZA PRÍČINY
           |
           v
OPRAVA DÁT / RETRIEVALU / PROMPTU / KÓDU
           |
           v
NOVÝ REGRESNÝ TEST
           |
           v
NOVÁ VERZIA

Takýmto spôsobom sa systém postupne stáva robustnejším.

Naše skúsenosti z projektu AI a RELIA.SK

Práve toto je jedna z najdôležitejších skúseností, ktoré sme získavali pri projekte RELIA.

Od decembra 2025 sme postupne pripravovali a dopĺňali odborné dáta, spracovávali ich pre vektorové vyhľadávanie a budovali nad nimi AI vyhľadávanie a systém otázok a odpovedí.

Na začiatku je veľmi jednoduché vytvoriť demo, pri ktorom položíte otázku, nájde sa relevantný text a AI vytvorí peknú odpoveď.

Skutočná práca začne pri ďalších stovkách otázok.

Postupne zisťujete:

• že rovnakú vec sa dá opýtať desiatimi spôsobmi,
• že jedna téma môže byť rozdelená medzi viac zdrojov,
• že retrieval niekedy vyhodnotí podobný text ako relevantnejší než správny,
• že príliš veľký kontext môže priniesť šum,
• že príliš malý kontext môže odstrániť dôležitú výnimku,
• že pravidlá odpovedania treba priebežne testovať.

Výsledkom preto nebola jedna „zázračná“ zmena promptu.

Išlo o postupné ladenie celého systému.

Od dokumentov k metapromptom a späť

Pri odbornom systéme nestačí riešiť iba technický retrieval.

Dôležité je aj to, ako má agent s podkladmi pracovať.

Napríklad:

• čo môže interpretovať,
• čo má citovať priamo,
• čo má označiť ako neisté,
• kedy má povedať, že odpoveď nemá,
• kedy má používateľa nasmerovať na ďalší zdroj.

Takéto pravidlá sme postupne dolaďovali spolu s testovaním reálnych otázok.

Nie preto, aby AI pôsobila „inteligentnejšie“ za každú cenu.

Ale aby bola konzervatívnejšia práve tam, kde by mohla používateľovi podať neoverené tvrdenie.

22. Vyššia inteligencia modelu sama osebe problém nerieši

Výkonnejšie modely môžu mať nižšiu mieru faktických chýb.

Napriek tomu nemá zmysel postaviť firemnú bezpečnosť na predpoklade:

„Používame výborný model, takže už nemusíme riešiť kontrolné mechanizmy.“

Aj veľmi schopný model môže dostať:

• nesprávny dokument,
• zastaraný údaj,
• neúplný kontext,
• nejasnú otázku.

Architektúra preto zostáva dôležitá bez ohľadu na kvalitu samotného modelu.

23. Webové vyhľadávanie môže pomôcť, ale nie je univerzálna pravda

Ak agent dokáže vyhľadávať aktuálne informácie na internete, môže tým znižovať riziko zastaraných znalostí.

Vzniká však nový problém:

Ktorému webovému zdroju má veriť?

Internet obsahuje:

• aktuálne zdroje,
• staré články,
• sekundárne interpretácie,
• marketingové tvrdenia,
• nesprávne informácie.

Aj web search preto potrebuje pravidlá práce so zdrojmi.

24. Pri firemných dátach je často lepší uzavretý svet

Ak budujeme odborného agenta pre konkrétnu firmu, môže byť vhodné povedať:

„Na túto tému používaj iba tieto schválené zdroje.“

To výrazne obmedzí priestor, v ktorom si systém vyberá medzi neznámymi zdrojmi.

Nie vždy potrebujeme, aby AI vedela všetko.

Často potrebujeme, aby veľmi dobre poznala presne definovanú oblasť.

25. Aj používateľ môže vložiť nesprávny údaj

Predstavme si:

„Mám produkt ABC, ktorý má výkon 2 000 W.“

Produktová databáza však uvádza:

1 200 W

Agent nemá automaticky považovať všetko, čo napíše používateľ, za overený fakt.

Pri relevantných údajoch môže byť potrebné porovnať ich so zdrojom pravdy.

26. Pamäť môže halucinácie dokonca konzervovať

Predstavme si, že agent v jednej konverzácii nesprávne usúdi:

„Zákazník používa model XYZ.“

A túto informáciu uloží do dlhodobej pamäte.

Neskôr ju začne používať ako fakt.

Jedna chyba sa tak môže prenášať do ďalších konverzácií.

Preto musíme kontrolovať aj to:

• čo sa do pamäte ukladá,
• odkiaľ informácia pochádza,
• či je potvrdená,
• kedy sa má aktualizovať.

27. Halucinácie pri tool use môžu byť iné než pri textových odpovediach

Agent nemusí iba vymyslieť fakt.

Môže napríklad:

• vybrať nesprávny nástroj,
• vymyslieť nesprávne product_id,
• použiť zlý argument,
• nesprávne interpretovať výsledok nástroja,
• oznámiť úspech skôr, než bol potvrdený.

Preto musíme pri agentoch testovať celý proces.

Príklad: vytvorenie ticketu

Agent navrhne:

create_support_ticket()

Aplikácia vráti:

ERROR

Agent nesmie povedať:

„Vaša požiadavka bola úspešne vytvorená.“

Musí pracovať so skutočným výsledkom operácie.

28. V kritických prípadoch môžeme vyžadovať potvrdenie človeka

Niektoré úlohy môžeme automatizovať úplne.

Iné iba čiastočne.

Napríklad:

AI pripraví odpoveď

        |
        v

ODBORNÍK JU SKONTROLUJE

        |
        v

ODPOVEĎ SA ODOŠLE

Postupne môžeme sledovať, ktoré typy prípadov sú natoľko spoľahlivé, že ľudskú kontrolu už nepotrebujú.

29. Monitoring musí pokračovať aj po spustení

Spustením produkčnej verzie projekt nekončí.

Práve vtedy dostávame najhodnotnejšie dáta.

Môžeme sledovať:

• otázky, na ktoré agent neodpovedal,
• odpovede označené používateľom ako zlé,
• neúspešné tool calls,
• časté eskalácie,
• nové typy otázok.

Tieto dáta následne používame na ďalšie zlepšovanie.

30. Cieľom nie je nulová chybovosť za každú cenu

Absolútna nulová chybovosť je pri otvorenom generatívnom systéme veľmi ambiciózny cieľ, ktorý nie je rozumné zákazníkovi garantovať.

Praktickejší cieľ je:

• minimalizovať chyby,
• znížiť ich dopad,
• vedieť ich odhaliť,
• umožniť systému bezpečne priznať neistotu,
• nepovoliť neoverenej odpovedi vykonať nebezpečnú operáciu.

Spoľahlivosť nevzniká z jedného modelu

Vzniká zo systému.

KVALITNÝ MODEL
       +
KVALITNÉ DÁTA
       +
RAG
       +
AKTUÁLNE FIREMNÉ SYSTÉMY
       +
TOOL USE
       +
VALIDÁCIA
       +
PRAVIDLÁ
       +
EVALY
       +
MONITORING
       +
ČLOVEK TAM, KDE JE POTREBNÝ

Žiadna z týchto vrstiev nie je samostatnou zárukou.

Spolu však dokážu riziko výrazne znižovať.

Čo by sme nikdy nesľubovali klientovi

Pri firemnom AI projekte by sme boli veľmi opatrní pri tvrdeniach typu:

„Naša AI nikdy nehalucinuje.“

alebo:

„Máme RAG, takže odpovede sú vždy správne.“

Takéto tvrdenia vytvárajú falošný pocit istoty.

Oveľa profesionálnejšie je klientovi vysvetliť:

• aké zdroje agent používa,
• ako sa kontroluje aktuálnosť,
• čo sa stane pri nedostatku informácií,
• ako sa systém testuje,
• kedy sa prípad eskaluje človeku.

Čo naopak vieme klientovi sľúbiť?

Vieme navrhnúť systém, ktorý:

• preferuje overené firemné zdroje pred domnienkami,
• načítava dynamické informácie zo zdrojových systémov,
• má jasné pravidlá práce s neistotou,
• dokáže citovať alebo identifikovať použitý zdroj,
• je systematicky testovaný,
• umožňuje sledovať problémové prípady,
• je priebežne zlepšovaný.

To je podľa nás realistický základ dôveryhodného AI produktu.

Najväčšia zmena myslenia: nesnažme sa vytvoriť vševediacu AI

Pri prvých AI projektoch je veľmi lákavé vytvoriť:

„Jedného asistenta, ktorý vie všetko o celej firme.“

V praxi môže byť oveľa lepšie vytvoriť agenta, ktorý:

• má jasne definovanú oblasť,
• pozná svoje zdroje,
• má obmedzené nástroje,
• pozná svoje hranice.

Takýto systém sa:

• ľahšie testuje,
• jednoduchšie zabezpečuje,
• lepšie monitoruje,
• spoľahlivejšie zlepšuje.

Najlepší agent nemusí byť ten, ktorý odpovie na všetko

Predstavme si dva systémy.

Agent A

Odpovie na 100 % otázok.

Pri časti z nich však háda.

Agent B

Na časť otázok odpovie:

„Na toto nemám dostatok overených informácií.“

A následne ponúkne človeka alebo ďalší postup.

Pri odbornom firemnom použití môže byť druhý systém oveľa hodnotnejší.

Dôvera nevzniká tým, že AI nikdy nepovie „neviem“

Práve naopak.

Dôvera vzniká tým, že používateľ postupne zistí:

Keď agent niečo tvrdí, má na to podklad.

A keď podklad nemá, nesnaží sa nedostatok zakryť presvedčivým textom.

Záver: cieľom nie je AI, ktorá nikdy neurobí chybu. Cieľom je AI, ktorá má čo najmenej priestoru na vymýšľanie.

Generatívne AI systémy nie sú klasické databázy faktov.

Ich veľká sila spočíva práve v schopnosti pracovať s prirodzeným jazykom, neštruktúrovanými dátami a komplikovanými otázkami.

Táto flexibilita však prináša aj riziko nesprávnych alebo nepodložených odpovedí.

Preto nestačí vybrať kvalitný model a napísať dobrý prompt.

Potrebujeme celý systém:

• kvalitné a aktuálne zdroje,
• jasný source of truth,
• správne spracovanie dokumentov,
• RAG a retrieval,
• aktuálne dáta cez nástroje,
• aplikačnú validáciu,
• pravidlá pre neistotu,
• evaly a regresné testovanie,
• monitorovanie reálnej prevádzky,
• človeka tam, kde následky chyby vyžadujú jeho kontrolu.

Na projekte RELIA sme od decembra 2025 postupne videli, že cesta k spoľahlivejšej AI nie je jednorazová konfigurácia.

Je to kombinácia práce s dátami, vektormi, retrievalom, metapromptmi, testovacími otázkami a priebežným vyhodnocovaním výsledkov.

A práve to je skúsenosť, ktorú považujeme za dôležitú aj pri vývoji ďalších firemných AI agentov.

AI bez rizika chyby dnes klientovi sľubovať nechceme.

Vieme však navrhovať AI systémy, v ktorých je priestor na nepodložené odpovede systematicky obmedzovaný, chyby sú merateľné a systém sa na základe reálnych prípadov postupne zlepšuje.

---

Potrebujete firemného AI agenta, ktorému chcete vedieť dôverovať?

Máte odborné dokumenty, interné know-how, produktový katalóg alebo firemné systémy a chcete nad nimi vytvoriť AI vyhľadávanie, poradcu alebo vlastného AI agenta?

V Consultee nepristupujeme k firemnej AI iba ako k chatovaciemu oknu. Spájame softvérový vývoj, databázy, RAG, vektorové vyhľadávanie, integrácie, testovanie a pravidlá práce s neistotou.

Prvým krokom nemusí byť rozsiahly projekt. Môžeme začať jedným konkrétnym use case, pripraviť pilotné riešenie a na reálnych otázkach zmerať, kde systém funguje spoľahlivo a kde potrebuje ďalšie obmedzenia alebo dáta.

Potrebujete vlastného AI agenta a neviete, kde začať? Kontaktujte nás a dohodnite si stretnutie.