Ak firma začne uvažovať nad vlastným AI asistentom, veľmi rýchlo narazí na jednoduchý problém:
AI síce vie veľa všeobecne, ale nepozná naše interné dokumenty, smernice, produktové podklady, školenia, manuály ani know-how.
Práve tu prichádza na rad pojem RAG.
Je to skratka z anglického Retrieval-Augmented Generation, teda zjednodušene:
AI najskôr nájde relevantné podklady a až potom z nich vytvorí odpoveď.
RAG patrí medzi najpraktickejšie spôsoby, ako vytvoriť firemného AI asistenta nad vlastnými dátami bez toho, aby sme museli jazykový model kompletne „učiť nanovo“.
V tomto článku si vysvetlíme, čo RAG je, ako funguje, čo sa deje s dokumentmi po nahratí, kde vznikajú najčastejšie chyby a prečo nestačí iba povedať:
„Nahrajme PDF do AI a ono si už poradí.“
Najprv jednoduchý príklad
Predstavme si firmu, ktorá má 300 strán interných dokumentov.
Sú medzi nimi:
- produktové manuály,
- servisné postupy,
- interné smernice,
- FAQ,
- školenia,
- technické podklady,
- obchodné informácie.
Zamestnanec sa opýta AI:
„Ako máme postupovať pri reklamácii produktu X?“
Bez RAG riešenia by mal model len dve možnosti.
Buď odpovie na základe svojich všeobecných znalostí, alebo dostane celý dokument priamo v kontexte otázky.
Prvá možnosť je riziková.
Druhá je pri väčších objemoch dát nepraktická.
RAG rieši problém inak.
Systém najprv vyhľadá iba tie časti dokumentov, ktoré sú relevantné k otázke, a až tieto časti poskytne jazykovému modelu.
Model potom vytvorí odpoveď na základe nájdených podkladov.
Veľmi zjednodušený princíp RAG
Používateľ položí otázku
|
v
Systém vyhľadá relevantné časti dokumentov
|
v
Vybrané podklady sa pošlú AI modelu
|
v
AI vytvorí odpoveď na základe nájdených informácií
Znie to jednoducho.
V princípe to jednoduché aj je.
Rozdiel medzi slabým a kvalitným RAG riešením však vzniká v detailoch.
RAG nie je „pamäť AI“
Veľmi časté nedorozumenie je predstava, že keď dokumenty spracujeme do vektorov, AI si ich nejako zapamätá.
Presnejšie je povedať:
AI model dokumenty nemusí poznať natrvalo. Systém mu pri každej otázke vyberie relevantné informácie a vloží ich do aktuálneho kontextu.
Teda:
dokumenty
|
v
spracovanie
|
v
vyhľadateľná knowledge base
...
otázka používateľa
|
v
vyhľadanie relevantných častí
|
v
AI model dostane iba potrebné podklady
|
v
odpoveď
Je to dôležitý rozdiel.
Dokumenty nie sú „natlačené do mozgu AI“.
Sú uložené v systéme, ktorý ich vie nájsť a správne doručiť modelu v čase, keď ich potrebuje.
Prečo nestačí nahrať dokument do promptu
Pri jednom krátkom PDF môže byť úplne postačujúce poslať celý dokument spolu s otázkou.
Problém vzniká, keď firma má:
- stovky dokumentov,
- tisíce strán textu,
- viac jazykov,
- rôzne verzie dokumentov,
- množstvo produktových informácií,
- archív školení a webinárov.
Posielať všetko pri každej otázke by bolo:
- zbytočne drahé,
- pomalé,
- neprehľadné,
- a často aj menej presné.
Veľký objem nerelevantného textu môže modelu skôr uškodiť než pomôcť.
RAG sa preto snaží vybrať len obsah, ktorý je k otázke dôležitý.
Krok 1: získanie zdrojových dát
RAG systém môže pracovať s rôznymi typmi zdrojov.
Napríklad:
- PDF dokumenty,
- Word dokumenty,
- HTML stránky,
- články,
- produktové texty,
- FAQ,
- technická dokumentácia,
- prepisy videí,
- prepisy webinárov,
- interné návody,
- školenia,
- exporty z databáz.
Úplne prvá úloha je dostať z týchto zdrojov kvalitný text.
A práve tu môžu začať problémy.
PDF nie je vždy pekný textový dokument
Niektoré PDF sú vytvorené priamo z textového dokumentu a ich spracovanie je relatívne jednoduché.
Iné môžu byť:
- naskenované obrázky,
- komplikovane zalomené dokumenty,
- tabuľky,
- prezentácie exportované do PDF,
- dokumenty s poznámkami alebo grafmi.
Pri extrakcii textu sa môže stať, že:
- sa zmení poradie viet,
- stratia sa nadpisy,
- tabuľka sa rozpadne,
- odseky sa spoja,
- alebo sa dôležitý význam stratí.
Pre AI je potom problém nie samotný jazykový model, ale nekvalitný vstup.
Rovnaký problém platí pri videu a webinári
Ak firma vlastní hodnotný webinár, AI z MP4 automaticky nepozná jeho obsah len preto, že súbor existuje.
Najprv potrebujeme dostať hovorený obsah do textovej podoby.
Typický proces môže vyzerať:
video
|
v
audio
|
v
transkript
|
v
čistenie a štruktúrovanie
|
v
kapitoly / bloky
|
v
knowledge base
A práve tento prístup dnes riešime aj pri projektoch, kde má jeden zdroj slúžiť nielen na prehratie videa, ale aj ako základ pre AI vyhľadávanie, otázky a odpovede, články alebo ďalšie obsahové výstupy.
Krok 2: čistenie a normalizácia
Predstavme si dokument s textom:
Strana 17
Spoločnosť ABC
Interný dokument
...
Strana 18
Spoločnosť ABC
Interný dokument
Ak takéto hlavičky a päty ostanú pri každej strane, môžu sa dostať do knowledge base desiatky až stovky krát.
To je zbytočný šum.
Pred spracovaním preto často potrebujeme odstrániť:
- opakujúce sa hlavičky,
- pätu stránky,
- číslovanie strán,
- duplicitný text,
- technické značky,
- neužitočné navigačné prvky.
Zároveň chceme zachovať veci, ktoré význam majú:
- nadpisy,
- podnadpisy,
- zoznamy,
- členenie tém,
- kapitoly,
- zdroj a dátum dokumentu.
Krok 3: dokument treba rozdeliť
Veľké dokumenty sa zvyčajne delia na menšie časti.
Týmto častiam sa často hovorí chunks.
Proces sa nazýva chunking.
Predstavme si odbornú knihu s 300 stranami.
Ak sa používateľ opýta na jednu konkrétnu tému, nepotrebujeme mu posielať všetkých 300 strán.
Potrebujeme nájsť dve alebo tri relevantné časti.
Príliš veľké chunks
Ak sú bloky príliš veľké, môžu obsahovať množstvo nerelevantného textu.
Napríklad jeden blok môže obsahovať:
- definíciu,
- výnimku,
- úplne inú tému,
- príklad,
- ďalšiu kapitolu.
Vyhľadávanie potom môže byť menej presné.
Príliš malé chunks
Ak sú bloky príliš malé, môže sa stratiť kontext.
Napríklad:
Chunk 1:
Zákazník môže odstúpiť od zmluvy do 14 dní.
Chunk 2:
Toto pravidlo sa nevzťahuje na prípady uvedené v ďalšom odseku.
Ak systém nájde iba prvý blok, odpoveď môže byť neúplná.
Chunking preto nie je iba technická operácia typu „rozdeľ text každých 500 slov“.
Pri odborných materiáloch je často dôležité zachovať významové celky.
Členenie podľa štruktúry dokumentu
Ak má dokument kvalitnú štruktúru, je výhodné ju využiť.
Napríklad:
H1: Reklamácie
H2: Kedy môže zákazník reklamovať produkt
H2: Potrebné dokumenty
H2: Lehoty
H2: Výnimky
Takéto členenie je pre knowledge base často hodnotnejšie než mechanické delenie textu podľa počtu znakov.
Krok 4: vytvorenie embeddingov
Teraz prichádza technickejšia časť.
Každú časť dokumentu môžeme pomocou embedding modelu previesť na číselnú reprezentáciu – vektor.
Nemusíme pritom riešiť samotnú matematiku.
Pre pochopenie stačí vedieť:
texty s podobným významom majú vo vektorovom priestore podobné reprezentácie.
Predstavme si dve vety:
„Ako môžem vrátiť produkt?“
a:
„Aký je postup pri odstúpení od zmluvy?“
Slová sú odlišné.
Význam však môže byť veľmi podobný.
Vektorové vyhľadávanie dokáže zachytiť práve takúto podobnosť.
Prečo to môže byť lepšie než obyčajné fulltextové vyhľadávanie
Klasické vyhľadávanie býva často postavené na slovách.
Používateľ napíše:
„pokazený motor“
Dokument však môže obsahovať:
„porucha pohonnej jednotky“
Klasický keyword search nemusí nájsť ideálny výsledok.
Semantické vyhľadávanie môže pochopiť, že obsah je významovo podobný.
To je jeden z hlavných dôvodov, prečo sa pri RAG systémoch často používajú embeddingy.
Krok 5: uloženie do vektorového úložiska
Vektory musíme niekam uložiť.
Môže ísť o:
- špecializovanú vektorovú databázu,
- databázu s podporou vektorového vyhľadávania,
- alebo inú vyhľadávaciu vrstvu.
Ku každému chunku sa zvyčajne ukladá:
- text,
- embedding,
- identifikátor zdroja,
- názov dokumentu,
- kapitola,
- dátum,
- typ dokumentu,
- ďalšie metadata.
Metadata sú oveľa dôležitejšie, než sa môže zdať
Predstavme si firmu, ktorá má dve smernice.
Jednu z roku 2024 a druhú z roku 2026.
Obsahujú podobný text.
Ak systém nevie, ktorá je aktuálna, môže nájsť nesprávnu verziu.
Preto môžeme ukladať metadata ako:
document_id
title
version
valid_from
valid_to
category
language
department
access_level
product_id
source_url
Následne môžeme vyhľadávanie filtrovať.
Napríklad:
nájdi relevantný obsah
ALE LEN
z aktuálnych dokumentov
A LEN
z oddelenia zákazníckej podpory
Krok 6: používateľ položí otázku
Teraz už máme spracovanú knowledge base.
Používateľ sa opýta:
„Čo potrebujem doložiť pri reklamácii produktu?“
Systém otázku spracuje a vytvorí jej embedding.
Následne hľadá bloky dokumentov s podobným významom.
Krok 7: retrieval – vyhľadanie správnych podkladov
To je samotná časť „Retrieval“ v skratke RAG.
Systém môže nájsť napríklad:
1. Reklamačný poriadok – Potrebné dokumenty
relevance: vysoká
2. FAQ – Reklamácia produktu
relevance: vysoká
3. Obchodné podmienky – Reklamácie
relevance: stredná
Vybrané časti sa následne vložia do kontextu jazykového modelu.
Krok 8: generation – AI vytvorí odpoveď
Model môže dostať inštrukciu v štýle:
Odpovedz používateľovi iba na základe dodaných zdrojov.
Ak odpoveď v zdrojoch nie je, povedz, že nemáš dostatok informácií.
Nevymýšľaj chýbajúce údaje.
A spolu s tým dostane relevantné pasáže dokumentov.
Následne vytvorí odpoveď.
To je časť „Generation“.
Prečo RAG pomáha znižovať halucinácie
Ak sa model pýtame iba:
„Aké sú pravidlá našej firmy pri reklamácii?“
nemá odkiaľ poznať interné pravidlá.
Ak mu však dodáme:
- konkrétny aktuálny dokument,
- relevantnú časť,
- jasné pravidlo odpovedať iba zo zdrojov,
výrazne znižujeme priestor na domýšľanie.
RAG však nie je zárukou absolútnej správnosti.
RAG môže nájsť nesprávny chunk
Predstavme si, že knowledge base obsahuje podobné dokumenty.
Napríklad:
- reklamácie pre B2C zákazníkov,
- reklamácie pre B2B zákazníkov.
Používateľ sa opýta všeobecnú otázku.
Systém môže nájsť text z nesprávnej skupiny.
Jazykový model potom pokojne vytvorí gramaticky perfektnú odpoveď z nesprávnych podkladov.
Preto kvalita retrieval vrstvy rozhoduje o kvalite výsledku.
Garbage in, garbage out
Ak knowledge base obsahuje nekvalitné dáta, RAG ich neopraví.
Ak do systému vložíme:
- staré dokumenty,
- rozporuplné informácie,
- duplicitný obsah,
- nepresné prepisy,
- nesprávne OCR,
AI môže tieto problémy len veľmi presvedčivo reprodukovať.
Preto je pri firemnej AI často najväčšou prácou nie samotné API, ale príprava kvalitných zdrojov.
Naše skúsenosti pri RELIA.SK
Veľmi praktickú skúsenosť s týmto typom práce sme získavali od decembra 2025 pri webe RELIA.SK.
Cieľom nebolo iba vytvoriť obyčajný chatbot.
Postupne sme spracovávali odborné podklady tak, aby bolo možné nad nimi vytvoriť:
- AI vyhľadávanie,
- otázky a odpovede,
- vyhľadávanie relevantných odborných informácií,
- odpovede opreté o dodané zdroje.
Práve tam sa ukázalo, že jednoduchý diagram:
text → vektor → AI
je síce technicky správny, ale pre kvalitný výsledok absolútne nedostatočný.
V praxi bolo potrebné postupne riešiť:
- aké zdroje do systému zaradiť,
- ako ich čistiť,
- ako ich rozdeliť,
- čo považovať za relevantný kontext,
- ako pracovať s podobnými témami,
- ako nastaviť pravidlá odpovedí,
- ako testovať reálne otázky.
A systém sa postupne dolaďoval podľa výsledkov.
RAG nie je jednorazový import
Knowledge base sa časom mení.
Vznikajú nové:
- dokumenty,
- verzie,
- produkty,
- webináre,
- odborné články,
- interné postupy.
Preto musí existovať proces aktualizácie.
Napríklad:
nový dokument
|
v
kontrola
|
v
extrakcia textu
|
v
chunking
|
v
embedding
|
v
indexácia
|
v
knowledge base
Čo so starou verziou dokumentu?
Veľmi dôležitá otázka.
Predstavme si smernicu:
- verzia 1 – január,
- verzia 2 – apríl,
- verzia 3 – september.
Ak všetky tri verzie ostanú aktívne vo vyhľadávaní, môže vzniknúť konflikt.
Preto môžeme staršie verzie:
- deaktivovať,
- archivovať,
- označiť ako historické,
- alebo ich povoliť iba pri explicitnej historickej otázke.
RAG a citovanie zdrojov
Veľkou výhodou dobre navrhnutého RAG systému je možnosť ukázať používateľovi zdroj.
Napríklad:
Odpoveď: Pri reklamácii je potrebné priložiť doklad o kúpe a popis závady.
Zdroj: Reklamačný poriadok, časť 4.2.
Takýto prístup je mimoriadne užitočný pri odborných a interných systémoch.
Používateľ si totiž môže odpoveď overiť.
Zdroj je zároveň veľmi dôležitý pri ladení systému
Ak používateľ oznámi:
„Táto odpoveď je nesprávna.“
vývojár potrebuje zistiť:
- akú otázku používateľ položil,
- aké dokumenty sa našli,
- aké chunks sa poslali modelu,
- čo model odpovedal.
Bez tohto logovania sa AI systém ladí oveľa ťažšie.
RAG a fulltext sa nemusia vylučovať
Niekedy je semantické vyhľadávanie ideálne.
Inokedy potrebujeme nájsť presný výraz.
Napríklad:
„Nájdi produkt s označením XZ-4100.“
Tu môže byť obyčajné keyword vyhľadávanie presnejšie než semantické.
Preto moderné systémy často kombinujú:
- fulltextové vyhľadávanie,
- vektorové vyhľadávanie,
- metadata filtre,
- ďalšie hodnotenie relevancie.
Takémuto prístupu sa často hovorí hybrid search.
Reranking: vyhľadať nestačí, treba vybrať najlepšie
Predstavme si, že systém nájde 30 potenciálne relevantných častí.
Do kontextu modelu však nechceme poslať všetkých 30.
Môžeme preto použiť ďalšiu vrstvu, ktorá výsledky znovu zoradí podľa relevantnosti.
Proces môže vyzerať:
100 000 chunkov
|
v
vyhľadávanie
|
v
20 kandidátov
|
v
reranking
|
v
5 najlepších zdrojov
|
v
AI model
Takéto vrstvy môžu pri väčšej knowledge base významne zlepšiť výsledok.
Top K neznamená „čím viac, tým lepšie“
Pri retrieval sa často určuje počet výsledkov, ktoré pošleme modelu.
Napríklad:
top_k = 5
To znamená, že vyberieme päť najrelevantnejších častí.
Mohlo by sa zdať, že ak pošleme 30 výsledkov, dostaneme lepšiu odpoveď.
Nemusí to tak byť.
Viac kontextu znamená aj:
- viac šumu,
- viac podobných informácií,
- vyššie náklady,
- vyššiu pravdepodobnosť konfliktov.
Aj toto sa preto musí testovať.
RAG nad webom
Zdrojom knowledge base nemusia byť iba interné dokumenty.
Môže to byť aj vlastný web.
Napríklad:
- produktové stránky,
- blog,
- centrum pomoci,
- FAQ,
- technická dokumentácia.
Tu však musíme riešiť aj aktualizácie.
Ak firma upraví stránku, knowledge base by mala vedieť, že sa zdroj zmenil.
RAG nad produktovým katalógom
Pri e-shopoch môže byť knowledge base mimoriadne zaujímavá.
AI poradca môže vyhľadávať napríklad podľa:
- popisov produktov,
- parametrov,
- návodov,
- kategórií,
- porovnávacích podkladov.
Tu však vzniká dôležitá hranica.
Nie všetky produktové údaje majú ísť do RAG vrstvy.
Napríklad:
- dostupnosť,
- aktuálna cena,
- stav skladu,
- individuálna cena zákazníka,
je často lepšie načítať priamo zo systému.
RAG + nástroje
Najpraktickejšie riešenia preto často vyzerajú takto:
Otázka:
„Je tento model vhodný na čerpanie vody zo studne
a máte ho skladom?“
|
v
RAG:
nájde technické vlastnosti produktu
+
Tool:
get_stock(product_id)
|
v
AI:
spojí technické vysvetlenie
s aktuálnou skladovou informáciou
Toto je veľmi dôležitý koncept.
RAG nie je náhrada databázy, API ani firemného systému.
Je to jedna vrstva celého riešenia.
Nie všetky otázky majú ísť cez RAG
Predstavme si otázku:
„Koľko objednávok sme prijali dnes?“
Na to nepotrebujeme vektorovú databázu.
Potrebujeme spoľahlivý dotaz do databázy.
Podobne:
„Aká je dnešná cena produktu?“
je lepšie riešiť cez aktuálny produktový systém.
Naopak otázka:
„Aké sú hlavné rozdiely medzi týmito dvoma typmi zariadení?“
môže byť ideálnym kandidátom pre RAG nad produktovou dokumentáciou.
RAG môže rešpektovať prístupové práva
Pri interných systémoch je to kritické.
Predstavme si knowledge base obsahujúcu:
- verejnú dokumentáciu,
- obchodné podklady,
- manažérske reporty,
- personálne dokumenty.
Nemôžeme povoliť každému používateľovi vyhľadávanie vo všetkých zdrojoch.
Preto môže mať každý chunk uloženú informáciu o oprávneniach.
Vyhľadávanie následne pracuje iba s obsahom, ktorý môže používateľ vidieť.
AI nesmie obísť bezpečnosť systému
Ak zamestnanec nemá prístup k dokumentu v klasickom systéme, AI by mu ho nemala sprístupniť len preto, že vie položiť správnu otázku.
RAG preto musí byť súčasťou celej bezpečnostnej architektúry.
Multijazyčné dokumenty
Pri firmách pôsobiacich vo viacerých krajinách môže knowledge base obsahovať viac jazykov.
Napríklad:
- slovenčinu,
- češtinu,
- angličtinu,
- nemčinu.
Systém musí vedieť:
- v akom jazyku používateľ položil otázku,
- v akom jazyku sú dostupné zdroje,
- ktorá verzia dokumentu je relevantná.
Aj tu pomáhajú metadata.
RAG a tabuľky
Tabuľky patria medzi problematickejšie typy obsahu.
Napríklad:
| Model | Výkon | Prietok |
|---|---|---|
| A | 750 W | 80 l/min |
| B | 1100 W | 120 l/min |
Ak sa tabuľka pri extrakcii zmení na:
A 750 W 80
B 1100 W 120
stále môže byť použiteľná.
Ak sa však poradie rozbije, význam sa môže stratiť.
Pri technických produktoch preto niekedy dáva väčší zmysel ukladať parametre aj štruktúrovane v databáze.
Knowledge base nemusí znamenať iba vektory
Reálna knowledge vrstva môže kombinovať:
- vektorové vyhľadávanie,
- fulltext,
- SQL databázu,
- API,
- grafové vzťahy,
- cache,
- metadata filtre.
Správna otázka preto nie je:
„Použijeme vektory?“
Ale:
„Ako najspoľahlivejšie dostaneme správne dáta ku konkrétnej otázke?“
Čo sa stane, ak sa nič relevantné nenájde?
Toto je jedna z najdôležitejších situácií.
Systém by nemal automaticky povedať:
„Nenašiel som nič, tak si niečo vymyslím.“
Správnejší postup môže byť:
- povedať, že informácia v dostupných zdrojoch nie je,
- požiadať o spresnenie otázky,
- ponúknuť podobný dokument,
- odovzdať otázku človeku.
Threshold: kedy už výsledok nie je dostatočne relevantný?
Systém môže pracovať aj s prahom relevantnosti.
Napríklad:
ak similarity_score < threshold
→ nepouži zdroj ako dostatočne relevantný
Nie je však možné nastaviť jedno univerzálne číslo pre každý projekt.
Threshold treba vyhodnocovať na reálnych dátach.
Testovacia sada otázok
Pri profesionálnom RAG projekte je veľmi užitočné pripraviť si testovacie otázky.
Napríklad:
- jednoduché otázky,
- zložité otázky,
- otázky s synonymami,
- otázky s preklepmi,
- otázky, kde existuje viac zdrojov,
- otázky bez odpovede,
- otázky so zastaraným dokumentom,
- otázky kombinujúce viac tém.
Potom môžeme vyhodnocovať:
- či systém našiel správny zdroj,
- či našiel správnu časť,
- či odpoveď obsahuje všetky potrebné fakty,
- či nevytvoril nič navyše.
Pri RAG testujeme dve veci naraz
To je veľmi dôležité.
Ak je odpoveď nesprávna, musíme zistiť, kde vznikla chyba.
Retrieval chyba
Systém našiel nesprávne podklady.
Generation chyba
Systém našiel správne podklady, ale AI ich nesprávne interpretovala.
Bez tohto rozdelenia sa systém veľmi ťažko zlepšuje.
Príklad
Otázka:
„Koľko dní má zákazník na podanie žiadosti?“
Správny dokument hovorí:
„Žiadosť musí byť podaná do 30 dní.“
Ak retrieval vyberie iný dokument s hodnotou 14 dní, problém je vo vyhľadávaní.
Ak retrieval vyberie správnych 30 dní a AI odpovie 14, problém je v generovaní.
RAG systém sa musí priebežne vyhodnocovať
Firma časom zistí, na čo sa ľudia skutočne pýtajú.
Možno používajú iné výrazy než autori dokumentácie.
Možno sa často pýtajú na informáciu, ktorá vôbec nie je v knowledge base.
Možno existuje dokument, ktorý systém nachádza príliš často, hoci nie je najlepší.
Takéto poznatky sú veľmi cenné.
RAG môže pomôcť aj odhaliť slabé miesta firemnej dokumentácie
Ak AI opakovane nevie odpovedať na podobné otázky, môže to znamenať:
- že dokumentácia chýba,
- že je nejasná,
- že je zastaraná,
- alebo že existuje na viacerých miestach v rôznych verziách.
AI projekt tak niekedy nepriamo vedie aj k uprataniu interného know-how.
RAG pre zákazníkov a RAG pre zamestnancov nie je to isté
Verejný AI poradca na webe môže mať knowledge base len z verejných zdrojov.
Interný agent môže pracovať aj s internými dokumentmi.
To znamená, že rovnaká technológia môže podporovať viac scenárov.
Napríklad:
- zákaznícky chatbot,
- interný vyhľadávač,
- produktový poradca,
- servisný asistent,
- asistent obchodníka,
- odborný Q&A systém.
Jedna knowledge base môže mať viac vrstiev
Napríklad:
PUBLIC
- web
- blog
- FAQ
CUSTOMER
- zákaznícke návody
- produktové dokumenty
INTERNAL
- interné smernice
- servisné postupy
MANAGEMENT
- citlivé interné materiály
Systém môže podľa identity používateľa rozhodnúť, ktoré vrstvy môže vyhľadávať.
Ako vyzerá celý proces v praxi
ZDROJE
PDF / web / článok / video / databázový export
|
v
EXTRAKCIA
získanie čistého textu
|
v
ČISTENIE
odstránenie šumu
|
v
ŠTRUKTÚRA
nadpisy, kapitoly, metadata
|
v
CHUNKING
rozdelenie na významové bloky
|
v
EMBEDDINGS
číselná reprezentácia významu
|
v
INDEX
uloženie a vyhľadávanie
|
v
OTÁZKA
|
v
RETRIEVAL
nájdenie relevantných zdrojov
|
v
AI MODEL
|
v
ODPOVEĎ
|
v
ZDROJE / CITÁCIE / LOGY
Kedy RAG dáva veľký zmysel
RAG je veľmi vhodný tam, kde firma má veľa textového know-how.
Napríklad:
- odborné poradenstvo,
- technická dokumentácia,
- zákaznícka podpora,
- interné smernice,
- produktové katalógy,
- servisné postupy,
- školenia,
- webináre,
- legislatívne a odborné materiály.
Kedy RAG nie je správny nástroj
Ak odpoveď vyžaduje presný aktuálny údaj, RAG nemusí byť vhodný.
Napríklad:
- dnešná skladová zásoba,
- aktuálny stav objednávky,
- aktuálny zostatok,
- dnešná cena,
- počet objednávok za poslednú hodinu.
Tu potrebujeme API, databázový dotaz alebo inú priamu integráciu.
Najlepšie výsledky vznikajú kombináciou
Praktický firemný AI agent môže kombinovať:
RAG
+
SQL
+
API
+
tool use
+
prístupové práva
+
business logiku
A práve v tom je rozdiel medzi jednoduchým chatbotom a plnohodnotnou AI aplikáciou.
RAG nie je produkt, ale stavebný blok
RAG sám osebe nie je celý AI agent.
Je to technika, ktorá rieši jednu veľmi dôležitú časť:
ako dostať relevantné znalosti z dokumentov k jazykovému modelu v momente, keď ich potrebuje.
Okolo toho však stále potrebujeme:
- aplikačnú logiku,
- bezpečnosť,
- autentifikáciu,
- API,
- správu dát,
- testovanie,
- monitorovanie.
Najväčšia výhoda RAG: know-how firmy nemusí zostať zamknuté v dokumentoch
Vo firmách často existuje obrovské množstvo hodnotných informácií.
Problém je, že sú roztrúsené v:
- PDF,
- zložkách,
- e-mailoch,
- intranete,
- prezentáciách,
- videách,
- starých školeniach.
Človek musí vedieť, kde ich hľadať.
Dobre postavený RAG systém umožňuje zmeniť spôsob práce.
Namiesto:
„V ktorom dokumente sa o tom píše?“
môže používateľ jednoducho položiť otázku.
A systém mu nájde správny zdroj.
To je podľa nás hlavná hodnota RAG
Nie je to len „chatovanie s PDF“.
Je to spôsob, ako vytvoriť vrstvu medzi človekom a firemným know-how.
Vrstva, ktorá dokáže:
- vyhľadať relevantný obsah,
- spojiť informácie z viacerých dokumentov,
- vysvetliť ich zrozumiteľným jazykom,
- a ideálne ukázať aj zdroj.
Záver: AI nemusíme učiť všetko. Musíme jej vedieť správne podať to, čo potrebuje
RAG je veľmi praktická odpoveď na otázku:
„Ako naučíme AI odpovedať z našich dokumentov?“
Presnejšia odpoveď však znie:
Nemusíme ju všetko naučiť. Potrebujeme vytvoriť systém, ktorý jej pri každej otázke nájde správne podklady.
Kvalitný RAG preto nie je iba:
PDF → vektor → ChatGPT
Je to celý proces:
- výber zdrojov,
- extrakcia,
- čistenie,
- štruktúra,
- chunking,
- embeddingy,
- vyhľadávanie,
- filtre,
- pravidlá odpovedania,
- testovanie,
- aktualizácia.
Až keď tieto vrstvy fungujú spolu, vzniká systém, ktorému možno postupne dôverovať aj pri reálnom firemnom použití.
Máte vo firme dokumenty, ale nikto v nich nevie rýchlo nájsť správnu odpoveď?
PDF, manuály, školenia, webináre, produktové podklady alebo interné smernice môžu byť základom vlastného AI vyhľadávania alebo firemného AI agenta.
V Consultee spájame skúsenosti so softvérovým vývojom, databázami a praktickým spracovaním dát pre AI riešenia.
Nemusíte hneď budovať veľký systém. Dá sa začať jednou konkrétnou skupinou dokumentov a overiť, či nad nimi vie AI priniesť reálnu hodnotu.
Komentáre
Zverejnenie komentára