Výstup nikdy neber jako hotovou věc. Model umí plynule a sebevědomě napsat něco, co je věcně špatně. Čísla, citace, jména, data a právní tvrzení si vždy ověřte jinde. Platí to i pro zdánlivě jednoduché věci, jako je převod jednotek nebo výpočet procent. Stejně tak si dejte pozor na to, že model nezná aktuální dění, pokud mu ho sami nedodáte. Když potřebujete informaci z tohoto týdne, vložte text nebo data přímo do zadání.
Každá firma, která zpracovává větší objem přijatých i vydaných faktur, dříve nebo později narazí na duplicitní doklad nebo platbu, která nesedí. Nejde o výjimečnou situaci — vzniká běžně při ručním přepisování, při importu z více zdrojů nebo když někdo omylem zaúčtuje stejnou fakturu dvakrát. Následky jsou nepříjemné: nadhodnocené náklady, zkreslený přehled o cash flow a komplikace při kontrole. Systematická kontrola ušetří hodiny dohledávání zpětně.
RAG (Retrieval-Augmented Generation) vypadá jednoduše: vezmeš dotaz, najdeš relevantní pasáže v datech a pošleš je modelu jako kontext. Jenže většina lidí skončí u jednoduchého skriptu, který po pár dotazech přestane fungovat. Aby systém vydržel, musíš vyřešit tři věci: jak data načíst a rozdělit, jak je vyhledávat a jak výsledky sestavit do promptu. Začni tím, že si sepíšeš, na jaké otázky má systém odpovídat. Podle toho zvolíš formát a granularitu chunků. Bez tohoto kroku budeš ladit naslepo.
Prompt sestavuj tak, že modelu dáš jen to, co prokazatelně souvisí s dotazem. Příliš mnoho kontextu vede k ignorování instrukcí a k halucinacím. Do promptu napiš, že má odpovídat pouze z dodaných pasáží a u nejistoty říct, že informace chybí. U každé odpovědi vracej i zdrojové chunky, aby se dal výsledek ověřit. Bez toho systém nikdo nebude používat pro reálnou práci.
Typické chyby: chunkování po pevném počtu znaků bez ohledu na věty, embeddingy z jednoho modelu a dotazy z jiného, ignorování metadat (datum, autor, verze) a chybějící evaluace. Vytvoř si sadu 50–100 otázek s očekávanými odpověďmi a měř přesnost a úplnost po každé změně. Bez měření budeš jen hádat, jestli je nová verze lepší. RAG není jednorázový skript, ale systém, který se musí udržovat.
U nákladů nepočítejte jen předplatné. Skutečná cena se skládá ze tří položek: licence nebo provoz, čas na zavedení a čas na údržbu. Zavedení znamená napojení zdrojů, nastavení přístupů a ověření, že čísla sedí s účetnictvím. Údržba znamená reagovat na změny v systémech a opravovat rozbitá napojení. Levné řešení s krátkým zavedením často znamená dražší údržbu, protože každá změna se dělá ručně znovu.
Vyhledávání a vektorový index Embeddingy vytvoř stejným modelem pro dotazy i dokumenty. Kombinuj je s klasickým fulltextovým vyhledáváním (BM25) přes reciproční rank fúzi — samotné vektory selhávají u přesných čísel, názvů a zkratek. Indexuj průběžně, ne jednorázově. Pokud data měníš, potřebuješ umět smazat staré vektory, jinak ti odpovědi zastarají. V produkci drž dvě kolekce: jednu pro aktivní data, druhou pro přestavbu, a přepínej mezi nimi. Vyhledávej top 20–50 kandidátů, pak je přerankuj cross-encoderem nebo alespoň rule-based skóre. Tím výrazně snížíš šum v promptu.
Před spuštěním nového postupu si připravte testovací sadu dokladů, ve které schválně bude faktura s překlepem v částce, duplicitní doklad a faktura bez objednávky. Prožeňte je systémem a sledujte, jestli je zachytí a jestli obsluha pozná, co má s každým případem dělat. Výsledek si zapište — po půl roce budete potřebovat důkaz, že kontrola funguje, ne jen dojem.
Začněte mapováním toho, co skutečně děláte. Sepište si u deseti faktur za sebou každý krok: odkud doklad přišel, kdo ho přepsal, kam se uložil a kdo ho zkontroloval. Většina firem zjistí, že tři kroky z pěti jsou jen přenos stejného čísla mezi dvěma místy. Právě ty se dají vypustit jako první. Není potřeba hned řešit rozpoznávání papíru — stačí, když dodavatelé posílají faktury v jednotném formátu a vy je ukládáte do jedné složky s předvídatelným názvem.
Pro textové dokumenty používej chunk velikost přibližně 300–600 tokenů s překryvem 10–20 %. Menší chunky zvyšují přesnost vyhledávání, ale model pak ztrácí širší souvislost. Větší chunky mají opačný problém. Překryv pomáhá, aby se informace nerozpadla na hranici. Pokud máš tabulky nebo kód, nech je celé, jinak o strukturu přijdeš. U PDF pozor na dvousloupcové sazby — text se při převodu často míchá a chunk pak nedává smysl.
Typická chyba je testovat nástroj na datech, která jsou pěkná a kompletní. Reálná data mají prázdné položky, duplicity a nekonzistentní názvy. Než cokoli nasadíte, prožeňte testovací sadu, která obsahuje právě tyto nepořádky. Druhá častá chyba je automatizovat report, aniž by někdo ověřoval správnost. Automatický výstup může být stejně chybný jako ruční, jen se chyba šíří rychleji a nikdo si jí nevšimne, dokud není pozdě.
If you have any sort of concerns concerning where and just how to use https://dawidwisniewski23.Bravejournal.net/ceske-e-Shopy-a-vraceni-zbozi-s-podporou-umele-inteligence, you could call us at our page.
