Průvodce modely Claude od Anthropic

Úvod

Anthropic je americká firma, která se zabývá vývojem bezpečné AI - jejich hlavní produkt je rodina jazykových modelů Claude, v současnosti jedny z nejpokročilejších AI asistentů na trhu, které mají tři hlavní úrovně: Opus, Sonnet a Haiku. Když jsem poprvé začal s těmito modely pracovat, upřímně jsem nevěděl který kdy použít - všechny vypadaly podobně, ale rozdíly v kvalitě výstupu a ceně byly obrovské. V tomhle článku si projdeme co který model umí, kdy ho použít a proč, a sdílím zkušenosti z reálných projektů kde jsem každý z nich testoval.

Architektura rodiny Claude

Anthropic postavil třístupňovou hierarchii modelů, kde každá úroveň má svoje místo:

Všechny modely používají Constitutional AI framework pro bezpečnost a mají kontextové okno 200 000 tokenů (zhruba 150 000 slov), což v praxi znamená že můžeš nahrát celou kódovou bázi menšího projektu nebo technickou knihu a model si pamatuje všechno. Novější verze Opus a Sonnet nabízejí experimentální podporu až 1 milion tokenů - zkoušel jsem to s kompletní dokumentací ESP-IDF frameworku a fungovalo to překvapivě dobře, i když latence byla znatelně vyšší.

Claude Opus — hluboký myslitel

Co je Opus?

Opus je top tier model od Anthropic - navržený pro úlohy kde potřebuješ hluboké analytické uvažování, komplexní vícekrokové plánování, pokročilé programování a refaktoring, nebo práci s rozsáhlými kontexty jako jsou celé knihy nebo velké kódové báze. Když jsem poprvé testoval Opus na code review komplexní Flask aplikace s asynchronními tasky a Celery workers, byl jsem fascinovaný tím, jak model dokázal propojit souvislosti mezi moduly které byly od sebe vzdálené stovky řádků kódu a identifikovat potenciální race condition, kterou jsem já sám přehlédl.

Kdy použít Opus?

Ideální scénáře:

1. Code review před nasazením — Opus zachytí subtilní chyby jako memory leaky, async bugy nebo chybějící dispose volání, které ostatní modely přehlédnou
2. Architektonická rozhodnutí — Při návrhu systémové architektury nebo rozsáhlém refaktoringu
3. Výzkum a analýza — Sumarizace celých knih, analýza právních dokumentů, finanční modelování
4. Agentické workflow — Dlouhodobé autonomní úlohy vyžadující vícekrokové uvažování

Praktický příklad

Scénář: Máš komplexní Flask aplikaci s 50+ soubory a potřebuješ identifikovat 
bezpečnostní zranitelnosti.

Proč Opus: Model dokáže udržet kontext celé aplikace, propojit souvislosti mezi 
moduly a identifikovat zranitelnosti typu race condition nebo injection attacks, 
které vyžadují pochopení toku dat napříč celým systémem.

Cena

Opus 4.5 přinesl výrazné zlevnění oproti předchozím verzím (Opus 4/4.1 stál $15/$75), což zpřístupnilo prémiovou inteligenci širšímu spektru uživatelů - upřímně, při těch starých cenách jsem Opus používal jen na kritické review před nasazením do produkce, protože každý delší prompt stál dost peněz. Teď s novými cenami je to mnohem dostupnější, i když pořád ne na každodenní použití pokud máš omezený budget.

Claude Sonnet — spolehlivý kolega

Co je Sonnet?

Sonnet je vyvážený model - kombinuje vysokou inteligenci s rozumnou rychlostí a cenou, což z něj dělá ideální volbu pro většinu každodenní práce. Většina vývojářů tráví s tímhle modelem nejvíc času, a já nejsem výjimka - odhadem 80 % mých promptů jde na Sonnet, protože pro běžné programování, refaktoring nebo psaní dokumentace je naprosto dostačující a odpovídá rychle.

Kdy použít Sonnet?

Ideální scénáře:

1. Každodenní programování — Vývoj funkcí, práce s více soubory, správa stavu, připojení k API
2. Analýza a reporting — Strukturované analýzy, Q&A s dokumenty, vytváření reportů
3. Kreativní úlohy — Psaní obsahu, copywriting, technická dokumentace
4. Orchestrace agentů — Sonnet vytvoří plán a rozdělí úkoly pro Haiku instance

Praktický příklad

Scénář: Vyvíjíš React aplikaci s Tailwind CSS a potřebuješ implementovat
autentizaci s Firebase.

Proč Sonnet: Model zvládne multi-file logiku, správu stavu (Riverpod, Redux),
připojení k Firebase a generuje čistý, použitelný kód. Má vynikající výkon
v oblasti frontend/UI vývoje a generuje „pixel-perfect layouts".

Osobní zkušenost: Když jsem dělal redesign jednoho projektu s Flutter a Material 3,
Sonnet mi vygeneroval kompletní theme configuration včetně custom color schemes
a typography - kód fungoval na první pokus, což mě docela překvapilo protože
Material 3 API je dost komplexní a čekal jsem že budu muset něco ladit.

Cena

Sonnet nabízí výkon blížící se Opusu za zlomek ceny, což z něj dělá optimální volbu pro 90 % produkčních úloh - a tady je důležité si uvědomit že rozdíl mezi Sonnetem a Opusem není vždycky tak velký jak by se podle ceny mohlo zdát, takže pokud nejdeš do opravdu komplexních analýz nebo kritického code review, Sonnet ti bude stačit.

Claude Haiku — rychlý sprinter

Co je Haiku?

Haiku je nejrychlejší a nejlevnější model v rodině Claude - optimalizovaný pro minimální latenci (odpovědi pod sekundu), vysoký objem dotazů a nákladovou efektivitu. Upřímně, nejdřív jsem Haiku podceňoval a myslel si že je to jen "levná verze" pro lidi co chtějí ušetřit, ale když jsem ho začal používat na rychlé prototypování UI komponent, zjistil jsem že pro tento konkrétní use case je vlastně lepší než Sonnet - odpovídá skoro okamžitě a pro jednoduchý layout kód je kvalita naprosto dostačující.

Kdy použít Haiku?

Ideální scénáře:

1. Chatboti a zákaznická podpora — Real-time odpovědi bez čekání
2. UI prototypování — Rychlé generování layoutů a komponent
3. Klasifikace a moderace obsahu — Vysokoobjemové úlohy
4. Paralelní provádění subtasků — V orchestrovaném workflow s Sonnetem

Praktický příklad

Scénář: Potřebuješ rychle vytvořit Flutter screen s Material 3 designem.

Proč Haiku: Model vygeneruje layout téměř okamžitě. Pro brainstorming a rychlé
prototypy je ideální volbou. Ale pozor — v delších sessions „ztrácí nit"
a není vhodný pro komplexní logické stavby.

Osobní zkušenost: Zkoušel jsem s Haiku dělat složitější state management
s Riverpod providers a po třech čtyřech iteracích začal generovat kód který
nedával smysl - zapomínal na kontext z předchozích promptů a navrhoval řešení
která byla v rozporu s tím co jsme dělali předtím. Pro jednoduché úlohy super,
ale na komplexní logiku radši Sonnet.

Cena

Haiku je 5× levnější než Opus na vstupních tokenech, což z něj dělá ekonomickou volbu pro vysokoobjemové scénáře - pokud děláš chatbota nebo zákaznickou podporu kde potřebuješ zpracovat tisíce dotazů denně, rozdíl v ceně mezi Haiku a Sonnetem se rychle nasčítá na stovky dolarů měsíčně.

Srovnávací tabulka modelů

Orchestrační workflow — jak modely kombinovat

Když pracuješ na větším projektu, dává smysl kombinovat modely podle jejich silných stránek - tohle je něco co jsem se naučil až po pár měsících práce s Claude, protože na začátku jsem používal jen Sonnet na všechno a nevěděl jsem že můžu ušetřit čas i peníze tím že rozdělím úlohy mezi modely strategicky.

Fáze 1: Plánování (Sonnet)

Sonnet analyzuje požadavky, navrhuje architekturu a rozděluje úkoly na paralelizovatelné podúlohy.

Fáze 2: Implementace (Haiku)

Více instancí Haiku provádí subtasky paralelně — scaffolding, komponenty, API integrace.

Fáze 3: Review (Opus)

Před mergem provede Opus hlubokou revizi — zachytí async bugy, memory leaky a subtilní logické chyby.

Příklad z praxe:

Developer pracuje na mobilní aplikaci:
1. Používá Haiku pro rychlé UI prototypy
2. Přepne na Sonnet pro implementaci business logiky
3. Před releasem nechá Opus udělat finální code review

Výsledek: Opus odhalil rebuild issues a chybějící disposes,
které Haiku i Sonnet přehlédly.

Moje zkušenost: Přesně tenhle workflow jsem použil na jednom Flutter projektu
kde jsem dělal aplikaci pro správu IoT zařízení. Haiku mi vygeneroval asi 15
různých screen layoutů za pár minut, Sonnet implementoval komunikaci s MQTT
brokerem a state management, a Opus pak při finálním review našel memory leak
v subscription handleru který by v produkci způsobil problémy - model si všiml
že StreamSubscription není správně disposed při dispose() widgetu, což by
vedlo k postupnému nárůstu paměti. Tohle by Sonnet pravděpodobně přehlédl.

Rozhodovací strom: Který model zvolit?

START
  │
  ├── Je úloha časově kritická (real-time)?
  │     └── ANO → HAIKU
  │
  ├── Je to rutinní práce (coding, analýza, psaní)?
  │     └── ANO → SONNET
  │
  ├── Vyžaduje hluboké uvažování nebo rozsáhlý kontext?
  │     └── ANO → OPUS
  │
  ├── Je to finální review před nasazením?
  │     └── ANO → OPUS
  │
  └── Nejste si jistí?
        └── Začněte se SONNET, eskalujte na OPUS při potřebě

Cenové předplatné pro běžné uživatele

Pro ty, kteří nepoužívají API, nabízí Anthropic předplatné:

Praktické tipy pro optimalizaci nákladů

1. Začni s Haiku, eskaluj nahoru

Pro většinu dotazů postačí Haiku - na Sonnet nebo Opus přepni pouze pro složitější úlohy, což ti ušetří peníze a zároveň nezpomalí workflow, protože Haiku odpovídá tak rychle že rozdíl v latenci je znatelný.

2. Využij Prompt Caching

Při opakovaném dotazování na stejný kontext (např. velký dokument) snížíš náklady až o 90 % - tohle je obrovská úspora pokud pracuješ s rozsáhlou kódovou bází nebo dokumentací, protože model si cachuje kontext a při dalších dotazech ho nemusí znovu zpracovávat. Zkoušel jsem to s dokumentací k ESP-IDF a rozdíl v ceně byl dramatický - první prompt stál normálně, ale následující dotazy byly skoro zadarmo.

3. Batch API pro neurgentní úlohy

Asynchronní zpracování přes Batch API poskytuje 50% slevu na tokeny.

4. Optimalizuj prompty

Každý token stojí peníze. Odstraň zbytečný kontext a buď konkrétní.

Závěr

Každý model v rodině Claude má svoje místo:

• Opus je senior architekt — pomalejší, ale nejspolehlivější pro kritické rozhodnutí a hluboké analýzy
• Sonnet je spolehlivý kolega — zvládne 90 % každodenní práce kvalitně a efektivně, což z něj dělá můj go-to model
• Haiku je rychlý junior — ideální pro opakované úlohy a prototypování, překvapivě schopný pokud víš jak ho použít

Nejde o to používat jeden model na všechno. Jde o to strategicky kombinovat jejich silné stránky podle toho, co zrovna potřebuješ - a tohle pochopení přišlo až s praxí, protože na začátku jsem dělal chybu že jsem používal Sonnet i na úlohy kde by Haiku stačil, nebo naopak jsem se snažil ušetřit a používal Sonnet na code review kde by Opus odvedl mnohem lepší práci. Teď po několika měsících práce s těmito modely mám docela dobrý cit kdy který použít, a doufám že tento článek ti pomůže zkrátit tu learning curve.

Zdroje a další čtení

• Anthropic dokumentace
• Claude.ai
• API cenový přehled

Pro opravu diakritiky a překlepů byl použit model Claude Sonnet 4.5.

Článek aktualizován: březen 2026

The post Průvodce modely Claude od Anthropic first appeared on Hard Wired.

Glosář AI a LLM termínů

Úvod

Svět a příslib umělé inteligence, zejména velkých jazykových modelů (LLM), přináší nadšení a možnosti. Přináší také novou terminologii, které je třeba porozumět.

Tento glosář se zaměřuje na AI, RAG a velké jazykové modely, aby vám pomohl rychle zvládnout koncepty strojového učení.

Agentic RAG

Agentic RAG je přístup k vytváření AI asistentů a agentů pomocí LLM, který zahrnuje komplexní uvažování, vícekrokové plánování, volání funkcí a používání nástrojů.

Hlavní výhoda Agentic RAG spočívá ve schopnosti volat nástroje pro vyhledávání informací a provádění úkolů.

Například pokud požádáte AI asistenta postaveného na Agentic RAG o porovnání příjmů Apple a Microsoft v roce 2022, může analyzovat dotaz a dvakrát zavolat nástroj pro finanční výkazy – jednou pro Apple a jednou pro Microsoft. Poté sloučí výsledky obou volání a vytvoří požadovanou odpověď.

Attention (Pozornost)

Mechanismy pozornosti ve velkých jazykových modelech (LLM) jsou základní komponenty, které těmto modelům umožňují efektivněji zpracovávat a rozumět textu. Byly představeny Vaswani et al. v článku "Attention is All You Need".

Klíčovou inovací je self-attention (sebe-pozornost), kde model vypočítává skóre pozornosti mezi každým párem tokenů ve vstupní sekvenci. Tato skóre určují, kolik pozornosti věnovat každému tokenu při generování výstupu.

Mechanismy pozornosti byly klíčové pro pokrok v NLP a pohánějí aplikace jako strojový překlad a chatboty.

ChatGPT

ChatGPT je konverzační chatbot vyvinutý společností OpenAI. Je založen na architektuře GPT (Generative Pre-trained Transformer), což je typ modelu hlubokého učení navržený k porozumění a generování textu podobného lidskému.

Základní technologií ChatGPT je neuronová síť typu transformer, která se vyznačuje mechanismem self-attention.

Jednou z výrazných vlastností ChatGPT je schopnost vést otevřené konverzace s uživateli. Na rozdíl od mnoha jiných chatbotů, které fungují na základě předdefinovaných pravidel, ChatGPT dynamicky generuje odpovědi na základě vstupu.

Je důležité poznamenat, že ChatGPT není neomylný – spoléhá na trénovací data a může někdy produkovat nepřesné odpovědi (tzv. halucinace).

Chunking (Dělení na části)

Chunking je proces používaný ke zvýšení efektivity a přesnosti vyhledávání informací v NLP úlohách. V RAG je vstupní text rozdělen na menší, zvládnutelné jednotky nazývané "chunky". Tyto chunky mohou být věty, odstavce nebo jiné specifické rozdělení většího textu.

Účel chunkingu:

• Efektivita: Práce s menšími chunky zrychluje proces vyhledávání a vyžaduje méně výpočetního výkonu.
• Přesnost: Chunky poskytují cílenější informace, snižují šum a zlepšují relevanci získaných dat.
• Škálovatelnost: Chunking umožňuje systému efektivněji zpracovávat větší dokumenty.

V RAG je po chunkování každý chunk indexován a uložen v retrieval systému (jako text i jako embedding vektor).

Embeddings (Vektorové reprezentace)

V kontextu LLM jsou vektorové embeddingy typem reprezentace, která zachycuje sémantický význam nebo kontext slov či vět v kompaktní formě. Jsou to v podstatě vektory reálných čísel, kde každá dimenze může reprezentovat jinou vlastnost zachycující něco o významu daného konceptu.

Vektorové embeddingy jsou také známé jako "husté reprezentace" (dense representations), na rozdíl od tradičnějších "řídkých reprezentací" (sparse representations).

Typy embeddingů:

• Word embeddings: mapují každé slovo na vektorový embedding
• Sentence embeddings: mapují celou větu, odstavec nebo jakýkoli textový chunk do vektorového embeddingu

Vektorové embeddingy slouží jako vstup pro různé NLP úlohy jako klasifikace textu, analýza sentimentu nebo strojový překlad.

Explainability (Vysvětlitelnost)

Ve světě RAG vysvětlitelnost znamená, že systém může ukázat přesně, jak dospěl ke své odpovědi, včetně odkazů na původní zdroje.

Namísto toho, abyste přemýšleli, odkud informace pochází, systém může poskytnout jasné reference nebo citace, podobně jako poznámky pod čarou, takže si můžete detaily ověřit sami.

Tento transparentní přístup buduje důvěru a pomáhá porozumět uvažování za odpovědí.

Few Shot Learning

V kontextu LLM se koncept few shot learning vztahuje na schopnost poskytnout LLM příklady úkolu, který chcete provést, a tím zlepšit jeho výkon.

Zero shot příklad:
"Přelož následující z angličtiny do francouzštiny: How are you today?"

Few shot příklad:
"Přelož následující z angličtiny do francouzštiny:

1. Hello → Bonjour
2. Goodbye → Au revoir
   Přelož: How are you today?"

V druhém případě poskytujeme dva příklady dobrého překladu, čímž pomáháme modelu lépe splnit požadovaný úkol.

Fine-tuning (Doladění)

Fine-tuning je způsob provádění transfer learningu. Při fine-tuningu vezmete předtrénovaný model a pokračujete v jeho trénování na specifickém (obvykle menším) datasetu.

Běžné techniky fine-tuningu:

• Pokračování v tréninku celé neuronové sítě na specifickém datasetu
• Zmrazení některých vrstev a trénování ostatních
• Přidání nové vrstvy pro nový typ úkolu a trénování pouze této vrstvy

Fine-tuning je mnohem méně komplikovaný a výrazně levnější úkol než plné trénování LLM.

Nedávno byly navrženy techniky jako LORA (low-rank-adaptation), které fine-tuning ještě zrychlují a zlevňují při zachování podobného výkonu.

GPTs (Vlastní GPT)

V listopadu 2023 OpenAI představila možnost uživatelů nebo vývojářů vytvářet vlastní verze ChatGPT. Tato schopnost je zaměřena na relativně malé přizpůsobení, umožňující konfigurovat vlastní GPT s určitým tónem hlasu, hledáním na webu a až 20 PDF dokumenty.

GPT jsou nejlepší pro malá přizpůsobení GPT a nejsou ideálním řešením pro enterprise případy s tisíci nebo miliony dokumentů, kde škálovatelná RAG řešení zůstávají doporučeným přístupem.

LLM Hallucinations (Halucinace LLM)

Když LLM generuje text, který je nesmyslný nebo nevěrný poskytnutému zdrojovému obsahu, často říkáme, že tento obsah je halucinace LLM (také nazývaná fabrication).

Halucinace LLM nastávají ze dvou hlavních důvodů:

1. Ptáte se na otázku, na kterou odpověď není LLM "známa" (tj. není dostupná v jeho trénovacích datech). V tomto případě LLM může odpovědět špatnou odpovědí.

2. Odpověď na vaši otázku je LLM "známa", ale obsahuje fiktivní obsah nebo obsah, který je subjektivní jako názory a přesvědčení.

HHEM

HHEM (Hughes Hallucination Evaluation Model) je open source klasifikační model dostupný na HuggingFace, který lze použít k detekci halucinací.

Je zvláště užitečný v kontextu budování RAG aplikací, kde je sada faktů sumarizována LLM, ale model lze použít i v jiných kontextech.

HHEM se také používá k hodnocení LLM podle jejich celkové pravděpodobnosti halucinovat tímto způsobem.

Hybrid Search (Hybridní vyhledávání)

Sémantické vyhledávání poskytuje fantastický přístup k získávání relevantních výsledků, ale není dokonalé. Existují případy, zejména u jednoslovných dotazů hledajících informace o konkrétním produktu, kde tradiční vyhledávání na základě klíčových slov funguje lépe.

Hybridní vyhledávání se pokouší kombinovat sémantické vyhledávání s tradičním vyhledáváním na základě klíčových slov, využívající přesnost keyword vyhledávání s kontextovým porozuměním sémantického vyhledávání.

Kombinací obou metod nabízí hybridní vyhledávání nuancovanější a efektivnější přístup k vyhledávání informací.

LLM Inference (Inference LLM)

Inference je operace, při které generujete text s generativním LLM. Vstupem je sekvence tokenů a výstupem je další předpovězený token. Pokud chcete generovat celou sekvenci, generujete jeden token po druhém.

Inference s LLM je stochastická operace a nemusí pokaždé generovat stejný výsledek.

Parametry ovládající inferenci:

• Temperature: Ovládá, jak randomizovaná je odpověď. Při temp=0 je odpověď deterministická (LLM vždy volí token s nejvyšší pravděpodobností), zatímco vyšší hodnoty vedou k více randomizovaným výsledkům.

• Top_p a top_k: Dva mechanismy pro výběr dalšího tokenu.

  • Top_k je celočíselná hodnota určující délku top tokenů k zvážení
  • Top_p pracuje podobně, ale vybírá top N tokenů tak, aby jejich kumulativní pravděpodobnost byla rovna nebo vyšší než hodnota top_p (0…1)

Large Language Model (LLM) - Velký jazykový model

Velký jazykový model (LLM) je neuronová síť trénovaná k porozumění jazyku a může být použita pro různé úkoly jako sumarizace, překlad, predikce a generování textu. LLM je trénován na masivních textových datasetech jako Common Crawl, WebText2, Books1, Books2 a Wikipedia.

Běžný typ LLM, nazývaný také auto-regresivní (AR) LLM, je ten, kde je model trénován k předpovídání dalšího tokenu podmíněného všemi předchozími tokeny. GPT-3 a GPT-4 patří do této kategorie.

Tyto modely se také nazývají generativní LLM.

MAMBA

Mamba je nová architektura pro modelování sekvencí, která nabízí slibnou alternativu k modelům Transformer. Využívá selektivní stavové prostory k dosažení modelování sekvencí v lineárním čase, což poskytuje významné zlepšení efektivity a škálovatelnosti ve srovnání s kvadratickou složitostí Transformerů.

Klíčová inovace Mamby spočívá v její schopnosti selektivně uchovávat nebo zapomínat informace prostřednictvím selekčního mechanismu, což jí umožňuje efektivně zpracovávat dlouhodobé závislosti.

Architektura Mamba demonstruje působivý výkon napříč různými úkoly včetně jazykového modelování, analýzy sekvencí DNA a generování audia. Nabízí 5x vyšší propustnost generování ve srovnání s Transformery podobné velikosti.

Max Marginal Relevance Ranking (MMR)

V kontextu RAG se MMR vztahuje na techniku, při které jsou relevantní fakta poskytnutá krokem vyhledávání přeuspořádána tak, aby vytvořila rozmanitější sadu faktů. Původně navržená v roce 1998, je tato technika kritická například tam, kde je mnoho odpovídajících textových chunků z více dokumentů ve skutečnosti velmi podobných nebo dokonce identických.

MMR je často implementován jako krok přeuspořádání po vyhledávání. Algoritmus má složitost O(N²), ale může být implementován efektivně pro nízkou latenci.

Open Source LLM

Termín "open source", často používaný pro zdrojový kód veřejně dostupný pod různými licencemi jako Apache 2.0 nebo MIT, byl nedávno použit v kontextu LLM pro označení modelů, jejichž váhy jsou veřejně dostupné.

Nejpozoruhodnější open source modely:

• LLAMA3 od Meta (verze 8B a 70B)
• Mistral
• Google Gemma
• Microsoft Phi4

Většina open source LLM je vydána za podmínek umožňujících komerční použití, ale některé mají dodatečná omezení.

Prompt Engineering

Proces vytváření, zdokonalování a optimalizace vstupních promptů zadávaných LLM za účelem dosažení požadovaných výstupů. Prompt engineering hraje klíčovou roli při určování výkonu a chování modelů jako GPT.

Specifické techniky prompt engineeringu:

• Přeformulování: Někdy může přeformulování promptu vést k lepším výsledkům.
• Specifikace formátu: Pro úkoly, kde záleží na formátu odpovědi, můžete jej specifikovat v promptu (např. "Poskytněte odpověď v odrážkách").
• Úvodní informace: Zahrnutí dodatečného kontextu může pomoci zúžit požadovanou odpověď.

Prompt engineering je důležitý i v kontextu RAG pro získání nejlepších výsledků.

RAG Evaluation (Evaluace RAG)

Při implementaci RAG ve vaší organizaci je důležité nasadit robustní rámec pro evaluaci RAG. To vám umožní měřit kvalitu odpovědí a určit "jak přesná a užitečná je odpověď na jakoukoli uživatelskou otázku".

Dva hlavní typy metrik:

1. Metriky vyhledávání (Retrieval metrics): Tyto metriky říkají, zda jsou fakta získaná ze zdrojových dat relevantní k otázce a mohou být úspěšně použita jako podkladová data pro odpověď.

2. Metriky generování (Generation metrics): Tyto metriky hodnotí samotnou odpověď podmíněnou fakty – je odpověď správně ukotvena ve faktech?

RAG evaluace může být velmi akční a pomoci vám nejen vidět problémy, ale také je opravit.

RAG Sprawl

RAG Sprawl označuje nekontrolované šíření implementací Retrieval-Augmented Generation (RAG) napříč vaší organizací – rostoucí problém způsobující bolesti hlavy CIO a IT oddělením při vyčerpávání zdrojů, ohrožování bezpečnosti a vytváření nekonzistentních uživatelských zkušeností.

S RAG Sprawl se organizace rychle ocitne ve správě více redundantních systémů, které v podstatě vykonávají stejnou základní funkci: vyhledávání relevantních informací a jejich použití k ukotvení odpovědí LLM.

Reranking (Přeuspořádání)

V RAG hraje reranker klíčovou roli při zvyšování relevance získaných dokumentů ve dvoustupňovém modelu vyhledávání.

Zpočátku zahrnuje proces vyhledávání široké hledání pro shromáždění velké sady potenciálně relevantních dokumentových chunků pomocí rychlé a efektivní metody jako vektorové embeddingy nebo hybridní vyhledávání. Počáteční sada dokumentů však může obsahovat mnoho irelevantních nebo okrajově relevantních položek.

Zde přichází reranker jako druhý stupeň procesu vyhledávání. Aplikuje sofistikovanější algoritmus pro přehodnocení a přeuspořádání původně získaných dokumentů.

Kategorie rerankerů:

• Relevance reranker
• MMR reranker
• UDF reranker

Retrieval Augmented Generation (RAG)

Retrieval Augmented Generation (RAG) je přístup, který poskytuje LLM dodatečné, kontextové informace k ukotvení jeho odpovědí a zamezení halucinacím.

Ingest flow (tok příjmu dat):
Data jsou rozdělena na věty nebo jiné chunky. Každý chunk je poté zakódován do vektorového embeddingu (pomocí Embeddings modelu) a uložen ve vektorovém úložišti.

Query flow (tok dotazu):
Když je vydán dotaz, je nejprve zakódován do vlastního vektorového embeddingu a ty jsou porovnány s daty ve vektorovém úložišti. Nejrelevantnější věty nebo fakta jsou získány. Tato fakta jsou poté poskytnuta sumarizačnímu LLM, aby mohl odpovědět na dotaz s tímto kontextem na mysli a poskytnout přesnou odpověď založenou na datech.

Semantic Search a Neural Search (Sémantické a neurální vyhledávání)

Sémantické vyhledávání je metoda používaná ve vyhledávacích algoritmech, která bere v úvahu záměr hledajícího a kontextový význam termínů v dokumentech. Namísto pouhého hledání klíčových slov se sémantický vyhledávač snaží porozumět základním konceptům, kontextu a významu pro přesnější výsledky.

Například při hledání "apple" by tradiční vyhledávání na základě klíčových slov jednoduše vrátilo výsledky obsahující slovo "apple" bez kontextu rozlišujícího mezi Apple Inc. a jablkem jako ovocem.

Sémantické vyhledávání je často založeno na modelu hlubokého učení a nazývá se "neurální vyhledávání". Při neurálním vyhledávání je text převeden na formu nazývanou "vektorové embeddingy" reprezentující jeho sémantický význam.

Tokenization (Tokenizace)

V kontextu LLM je tokenizace proces, při kterém je textový řetězec rozdělen na menší jednotky nazývané tokeny. Tokeny mohou být jednotlivé znaky, jednotlivá slova nebo dokonce subslova, a výběr strategie tokenizace závisí na případu použití.

U tradičního NLP byla tokenizace na úrovni slov. Například věta "How am I doing today?" by byla přeložena do 5 slov: ["how", "am", "I", "doing", "today?"]

Nejběžnější strategie tokenizace pro LLM:

• BPE (Byte Pair Encoding): Tato metoda tokenizace rozděluje text na subslova. Velmi běžně používaná v rodině modelů GPT.
• Wordpiece: Vyvinutý společností Google a používaný v původní implementaci BERT.
• Unigram: Používaný v algoritmu SentencePiece od Google.

Transformers

Transformery jsou typ architektury neuronové sítě široce používané v zpracování přirozeného jazyka a jazykovém modelování. Transformery aplikují mechanismus pozornosti (attention), který umožňuje modelu současně zvažovat důležitost všech slov ve větě. To vede k modelům, které lépe zachycují kontext a dlouhodobé závislosti v jazyce.

Architektura transformeru se skládá z enkodéru a dekodéru. Enkodér čte vstupní sekvenci a vytváří její reprezentaci. Dekodér pak používá tuto reprezentaci ke generování výstupní sekvence.

Typy implementací:

• Pouze enkodér (např. BERT)
• Pouze dekodér (např. GPT-3, Anthropic)
• Enkodér i dekodér (např. T5)

Modely jako BERT, GPT-3 a T5 jsou všechny založeny na architektuře transformer.

Transfer Learning (Přenosové učení)

V tradičním strojovém učení je cílem natrénovat model k provedení určitého úkolu jako klasifikace nebo regrese.

S transfer learningem vezmete předtrénovaný model a použijete ho (adaptujete) na nový úkol. Protože předtrénování modelu je poměrně nákladné, myšlenka transfer learningu je následující: můžeme znovu použít část znalostí naučených během procesu předtrénování a aplikovat ji na nový úkol, který z těchto znalostí těží?

Transfer learning není nová myšlenka, jen se stal běžnějším s moderními neuronovými sítěmi, které jsou velké a nákladné na předtrénování.

Vector Store / Vector Database (Vektorové úložiště / databáze)

Vektorové úložiště je typ databáze, která ukládá vysokodimenzionální vektorová data a poskytuje dotazovací schopnosti na těchto vektorech jako similarity search, kde cílem je najít nejpodobnější dokumenty nebo položky k danému dotazu.

Nejběžnější typy vektorových úložišť: FAISS, Annoy, NMSLib

Vektorová databáze je specializovanější typ vektorového úložiště optimalizovaný pro efektivní správu velkých datasetů vektorů. Vektorové databáze typicky nabízejí pokročilé funkce jako podpora více typů vektorů, efektivní indexování a vysoká škálovatelnost.

Dostupné vektorové databáze: Qdrant, Weaviate, Pinecone, Milvus, Chroma

Při budování GenAI aplikací od nuly vývojáři často kombinují různé komponenty jako LangChain nebo LlamaIndex, poskytovatele embeddingů jako OpenAI nebo Cohere, sumarizační nebo Chat LLM jako OpenAI, a vektorovou databázi.

The post Glosář AI a LLM termínů first appeared on Hard Wired.

Disclaimer (protože bez něj by se někdo určitě tvářil překvapeně):
Ano, v tomhle článku se detailně rozebírá, jak fungují útoky na platební technologie. A ano, skutečně existuje jistá pravděpodobnost, že si to přečte někdo, kdo z toho bude chtít vyrobit „návod k použití“. Jenže hádej co – pokud někdo opravdu touží hrát si na malého cyberkriminálníka, žádný disclaimer na světě ho nezastaví. Maximálně si připadáme morálně v bezpečí, že jsme řekli svoje.

Takže, aby bylo jasno: tenhle text má informační a vzdělávací charakter, teoretické shrnutí, bezpečnostní osvětu, říkejme tomu jakkoliv. Pokud tě ale napadne strčit skimmer na bankomat, koupit si čínskou NFC čtečku a pak fňukat, že tě někdo chytil – to je čistě tvoje osobní tragikomedie, ne naše zodpovědnost.

V současné době máme k dispozici několik různých platebních technologií - od tradičních magnetických pruhů přes čipové karty až po moderní NFC platby v telefonech. Každá z těchto technologií má svá specifická zranitelná místa a vyžaduje jiný přístup ze strany útočníků. Podívejme se detailně na to, jak fungují jednotlivé typy útoků a jak se jim můžeme bránit.

Magnetický pruh: Nejzranitelnější cíl

Anatomie magnetického pruhu

Magnetický pruh na zadní straně karty obsahuje tři stopy dat, přičemž pro platební účely jsou klíčové stopa 1 a 2:

Stopa 1 obsahuje:

%B1234567890123445^DOE/JOHN^25121011000062000000?

• Číslo karty (PAN): 1234567890123445
• Jméno držitele: DOE/JOHN
• Datum platnosti: 2512 (12/25)
• Servisní kód: 101
• Dodatečná data pro ověření

Stopa 2 obsahuje:

;1234567890123445=25121011000062000000?

• Komprimovaná verze dat ze stopy 1
• Stejné základní informace v kratším formátu

Skimming útok krok za krokem

Fáze 1: Instalace zařízení

1. Útočník si obstará skimming zařízení (lze koupit na internetu za 100-500 USD)
2. Vybere cílové místo - bankomat, čerpací stanice, nebo platební terminál
3. Nainstaluje tenký skimmer na slot pro karty (tloušťka často jen 2-3 mm)
4. Současně umístí miniaturní kameru nebo falešnou klávesnici pro zachycení PIN

Fáze 2: Sběr dat

1. Karta prochází přes skimmer při normálním používání
2. Magnetická hlava skimmeru čte a ukládá všechna data z magnetického pruhu
3. Kamera nebo falešná klávesnice zachytí PIN kód
4. Data se ukládají v interní paměti zařízení

Fáze 3: Zneužití dat

1. Útočník data stáhne (často bezdrátově nebo při opětovné návštěvě)
2. Pomocí card writeru zapíše data na prázdnou plastovou kartu
3. Vzniklá kopie obsahuje všechna původní data
4. S kopií karty a PIN kódem může vybírat hotovost nebo platit

Proč je skimming tak účinný:

• Data jsou uložena v plain textu bez šifrování
• Jedna kopie stačí pro úplnou repliku karty
• Technologie je stará a nemá moderní zabezpečení
• Funguje na všech starších terminálech

Detekce skimming zařízení

Vizuální indikátory:

• Neobvykle tlustý nebo výčnívající slot pro karty
• Jiná barva nebo materiál čtečky
• Uvolněné nebo špatně usazené části
• Podezřelé kamery nebo zrcátka

Fyzické testování:

• Pokuste se "zatřást" čtečkou karet
• Zkontrolujte, zda nejsou části pohyblivé
• Porovnejte s jinými terminály stejného typu

Čipové karty EMV: Pokročilejší, ale ne neprůstřelné

Jak funguje EMV čip

EMV čip je mikropočítač, který obsahuje:

• Kryptografické klíče pro ověřování
• Čítač transakcí (ATC - Application Transaction Counter)
• Aplikační data specifická pro každou banku
• Certifikáty pro ověření pravosti

Shimming útok na čipové karty

Technologie shimming zařízení:

1. Ultra-tenká konstrukce - tloušťka často jen 0.1 mm
2. Kontaktní body přesně odpovídající rozložení čipu
3. Mikropočítač pro zachycení komunikace
4. Bezdrátový modul pro vzdálené stahování dat

Průběh shimming útoku:

1. Útočník vloží shim do čtečky čipů (téměř neviditelný)
2. Při vložení karty se shim dostane mezi čip a čtečku
3. Zachytí komunikaci mezi kartou a terminálem
4. Zaznamená cryptogramy a další transakční data

Získaná data z chimmingu:

• Application Cryptogram - šifrovaná data transakce
• ATC (Application Transaction Counter) - počítadlo transakcí
• UN (Unpredictable Number) - náhodné číslo transakce
• Amount - částka transakce
• Terminal data - informace o terminalu

Limitace shimming útoku:

• Zachycená data obsahují časové razítko - nelze znovu použít
• Replay protection - každý cryptogram je unikátní
• Bez PIN kódu jsou data prakticky nepoužitelná
• Moderní EMV implementace mají dodatečné ochranné mechanismy

Pokročilé EMV útoky

Downgrade útok:

1. Útočník přinutí terminál používat magnetický pruh místo čipu
2. Zablokuje komunikaci s čipem pomocí šumu nebo hardware
3. Terminál přejde do "fallback" režimu
4. Transakce proběhne přes nezabezpečený magnetický pruh

SIM swap pro EMV:

1. Útočník získá kopii SIM karty obětí
2. Zachytí SMS s autorizačními kódy
3. Použije kombinaci EMV dat a SMS kódů pro neautorizované transakce

RFID/NFC karty: Bezkontaktní rizika

Struktura NFC platební karty

NFC karta obsahuje několik vrstev zabezpečení:

Aplikační vrstva:

• PPSE (Proximity Payment System Environment) - seznam aplikací
• AID (Application Identifier) - identifikátor platební aplikace
• Application data - šifrovaná data aplikace

Bezpečnostní vrstva:

• DDA/SDA klíče - pro digitální podpis
• AC (Application Cryptogram) - pro ověření transakcí
• CVN (Cryptogram Version Number) - verze kryptografického algoritmu

RFID Skimming - bezkontaktní kopírování

Vybavení pro RFID útok:

1. NFC čtečka s upraveným firmwarem (100-300 USD)
2. Anténa s vysokým ziskem pro čtení na větší vzdálenost
3. Software pro analýzu NFC protokolů
4. Power amplifier pro zesílení signálu

Proces RFID skimmingu:

1. Proximity detection - detekce karty do 10 cm
2. APDU commands - poslání standardních NFC příkazů
3. Data extraction - extrakce dostupných dat
4. Response analysis - analýza odpovědi karty

Co lze získat z NFC karty:

✓ PAN (Primary Account Number) - číslo karty
✓ Expiration Date - datum platnosti
✓ Cardholder Name - jméno držitele (ne vždy)
✓ Transaction Log - historie posledních transakcí
✓ Application Data - některá metadata
✗ CVV/CVC - není na čipu
✗ PIN - není uložen na kartě
✗ Static Authentication Data - jsou šifrovaná

Relay Attack - propojování signálů

Princip relay útoku:

1. Reader device - u oběti, zachytí NFC signál
2. Writer device - u platebního terminalu
3. Communication link - spojení mezi zařízeními (WiFi/4G)
4. Real-time relay - přenos signálu v reálném čase

Technické provedení:

1. Útočník s NFC čtečkou se přiblíží k oběti (metro, fronta)
2. Druhý útočník s NFC emulátorem je u platebního terminalu
3. Signál z oběťovy karty se v reálném čase přenese k terminalu
4. Transakce proběhne, jako by oběť platila osobně

Ochrana proti relay útokům:

• Time-based protection - měření času odpovědi
• Distance bounding - ověření vzdálenosti karty
• Motion detection - detekce pohybu karty během transakce

NFC platby v telefonu: Moderní zabezpečení

Tokenizace - základ bezpečnosti

Jak tokenizace funguje:

1. Enrollment - registrace karty do telefonu
2. Token request - požadavek na vytvoření tokenu
3. Token provisioning - vytvoření unikátního tokenu pro kartu
4. DPAN creation - Device PAN nahrazuje skutečné číslo karty

Struktura tokenu:

Původní PAN: 4532 1234 5678 9012
Device Token: 4532 4815 XXXX XXXX
Token Expiry: 12/26 (nezávislé na kartě)
Cryptogram Key: Unikátní pro každou transakci

Secure Element a Hardware Security Module

Secure Element (SE) architektúra:

• Embedded SE - čip přímo v telefonu
• SIM-based SE - využití zabezpečené SIM karty
• Cloud-based SE - Host Card Emulation (HCE)

Hardware Security Module funkce:

1. Key generation - generování kryptografických klíčů
2. Cryptographic operations - šifrování/dešifrování
3. Secure storage - bezpečné ukládání citlivých dat
4. Tamper resistance - ochrana proti fyzickým útokům

Biometrická autentifikace

Typy biometrického ověření:

• Fingerprint - otisk prstu (nejčastější)
• Face recognition - rozpoznání obličeje
• Iris scan - skenování duhovky
• Voice recognition - rozpoznání hlasu

Bezpečnostní protokol:

1. Biometric capture - zachycení biometrických dat
2. Template matching - porovnání s uloženým vzorem
3. Liveness detection - ověření živé osoby
4. Secure unlock - odemčení platební aplikace

Dynamic Cryptogram - revoluce v zabezpečení

Generování cryptogramu:

Input data:
- ATC (Application Transaction Counter): 0001
- UN (Unpredictable Number): A1B2C3D4
- Amount: 00000050000 (500,00 CZK)
- Terminal ID: 12345678

Processing:
Cryptogram = HMAC-SHA256(MasterKey, InputData + TimeStamp)
Result: 8F4A2B1C (unikátní pro tuto transakci)

Proč je to bezpečné:

• Každá transakce má jiný cryptogram
• Starý cryptogram nelze znovu použít
• Časové razítko zabraňuje replay útokům
• Master klíč není nikdy přenášen

Srovnání bezpečnosti platebních metod

Bezpečnostní matice

Technologie	Šifrování	Tokenizace	Biometrie	Replay ochrana	Celkové skóre
Magnetický pruh	Žádné	Ne	Ne	Ne	1/10
EMV čip	Základní	Částečné	Ne	Ano	6/10
NFC karta	Ano	Částečné	Ne	Ano	7/10
NFC telefon	Pokročilé	Úplné	Ano	Ano	9/10

Praktická rizika v realném světě

Pravděpodobnost úspěšného útoku:

• Skimming magnetického pruhu: 85% úspěšnost
• Shimming EMV čipu: 15% úspěšnost
• RFID skimming: 5% úspěšnost
• NFC telefon útok: <1% úspěšnost

Finanční dopad při kompromitaci:

• Magnetický pruh: Úplný přístup k účtu
• EMV čip: Omezené na bezkontaktní limit
• NFC karta: Omezené na bezkontaktní limit
• NFC telefon: Téměř nulový (tokenizace)

Obranné strategie pro jednotlivé technologie

Ochrana magnetického pruhu

Preventivní opatření:

• Preferujte terminály s čiprových čtečkou
• Vizuálně kontrolujte čtečku před každým použitím
• Zakrývejte PIN celou rukou, ne jen prsty
• Používejte bankomaty uvnitř bank
• Nastavte si SMS notifikace pro všechny transakce

Detekční techniky:

• Sledujte neobvyklé transakce v aplikaci banky
• Pravidelně kontrolujte výpisy účtu
• Nahlaste jakékoli podezřelé aktivity do 24 hodin

Ochrana EMV čipů

Technické postupy:

• Vždy preferujte čip před magnetickým pruhom
• Při chybě čipu požadujte jiný terminál
• Nepovolte "fallback" na magnetický pruh
• Používejte contactless místo vkládání čipu

Monitorování:

• Kontrolujte, zda terminál skutečně čte čip
• Sledujte proces ověření PIN na displeji
• Ověřte si částku před potvrzením transakce

Ochrana RFID/NFC karet

Fyzická ochrana:

• Používejte RFID blocking peněženky
• Nosice maximálně 2 bezkontaktní karty současně
• Udržujte karty v ochranných obalech
• Vypněte bezkontaktní funkci, pokud ji nepoužíváte

Behaviorální ochrana:

• Buďte si vědomi svého okolí při platbách
• Neplaťte bezkontaktně v přeplněných prostorách
• Sledujte vzdálenost od cizích osob s elektronickými zařízeními

Maximalizace bezpečnosti NFC telefonů

Nastavení zabezpečení:

• Aktivujte nejpřísnější biometrické ověření
• Nastavte krátký timeout pro uzamčení telefonu
• Používejte silné heslo/PIN pro telefon
• Pravidelně aktualizujte operační systém

Aplikační bezpečnost:

• Používejte pouze oficiální platební aplikace (Apple Pay, Google Pay)
• Nezkoušejte alternativní nebo upravené aplikace
• Pravidelně kontrolujte oprávnění aplikací
• Nastavte notifikace pro každou transakci

Pokročilá opatření:

• Aktivujte remote wipe pro případ krádeže
• Používejte VPN při připojení k veřejným WiFi
• Pravidelně měňte biometrické vzory
• Monitorujte aplikační logy bezpečnosti

Budoucnost platební bezpečnosti

Kvantová kryptografie

Vyvíjí se kvantové šifrování, které bude prakticky neprůstřelné:

• Quantum key distribution - distribuce kvantových klíčů
• Post-quantum cryptography - algoritmy odolné vůči kvantovým počítačům
• Quantum random number generators - skutečně náhodná čísla

Pokročilá biometrie

Nové biometrické technologie přinášejí vyšší bezpečnost:

• Vein recognition - rozpoznání žil v ruce
• Heartbeat analysis - analýza srdečního rytmu
• Brain-computer interfaces - přímé rozhraní mozek-počítač
• DNA verification - ověření DNA z pouhého dotyku

Blockchain a distribuované technologie

• Decentralized identity - distribuovaná správa identit
• Smart contracts - automatické ověřování transakcí
• Zero-knowledge proofs - ověření bez odhalení dat
• Distributed ledger - nehacknutelný záznam transakcí

Závěr: Evoluce zabezpečení vs. evoluce útoků

Bezpečnost platebních karet prošla dramatickou evolucí od jednoduchých magnetických pruhů po sofistikované biometrické systémy s kvantovou kryptografií. Každá nová technologie přinesla vyšší úroveň zabezpečení, ale současně vyvolala nové typy útoků.

Klíčové pozorování:

• Magnetický pruh zůstává nejzranitelnější a nejčastěji zneužívanou technologií
• EMV čipy poskytují významné zlepšení, ale nejsou imunní vůči pokročilým útokům
• NFC karty nabízejí dobrou rovnováhu mezi pohodlím a bezpečností
• NFC telefony představují současný vrchol platební bezpečnosti

Doporučení pro uživatele:

1. Migrujte na nejmodernější technologie - používejte NFC platby v telefonu kde to jde
2. Zůstaňte informovaní - sledujte nové typy útoků a obranné techniky
3. Implementujte vrstevnatou obranu - kombinujte technická opatření s opatrným chováním
4. Pravidelně monitorujte - kontrolujte transakce a nahlašte podezřelé aktivity

Budoucnost platební bezpečnosti bude závisit na našech schopnostech předvídat a předcházet novým typům útoků dříve, než se stanou rozšířenými. Kombinace pokročilých technologií s osvětou uživatelů zůstává naším nejlepším nástrojem v tomto neustálém boji mezi bezpečností a kriminalitou.

The post Kopírujeme aneb platební karty: Anatomie útoků na platební technologie first appeared on Hard Wired.