Shrnutí: New York jako první americký stát přijal zákon, který nařizuje výrobcům 3D tiskáren, CNC frézek a dalších digitálních výrobních strojů zabudovat do jejich zařízení software, jenž před každým tiskem nebo obráběním prohledá soubor se vzorem a porovná ho s databází zbrojních plánů. Pokud algoritmus vyhodnotí soubor jako podezřelý, stroj se nespustí. Zákon byl přijat jako součást státního rozpočtu na fiskální rok 2026–2027 a podepsán guvernérkou Kathy Hochul.

1. Jak zákon vznikl a co přesně říká

Příslušná ustanovení jsou součástí rozpočtového zákona S.9005 / A.10005C (New York State Budget 2026–2027). Klíčová část je skryta v Part C, která obsahuje dva podčástky:

• Subpart A — trestněprávní ustanovení týkající se výroby nelegálních zbraní na 3D tiskárnách a sdílení digitálních plánů.
• Subpart B — technický mandát: povinné zabudování tzv. blocking technology do všech 3D tiskáren a CNC strojů prodávaných v New Yorku.

Zákon definuje „3D tiskárnu" extrémně široce — jako:

jakýkoliv stroj schopný vyrobit trojrozměrný objekt z digitálního návrhového souboru metodou přídavné výroby (additive manufacturing) nebo trojrozměrných úprav objektu metodou subtraktivní výroby (subtractive manufacturing).

Tato definice tedy pokrývá nejen klasické FDM/SLA 3D tiskárny, ale i CNC frézy, CNC routery, soustruhy, laserové řezačky a v důsledku i hobbyistické plotry jako je Cricut. Jednoduše: pokud stroj převádí digitální soubor na fyzický objekt, zákon se na něj vztahuje.

2. Co je "blocking technology" a jak má fungovat

Zákon definuje blocking technology jako hardware, software, firmware nebo jiná integrovaná technická opatření, která zajistí, že stroj nezahájí zpracování žádné zakázky, dokud nebude příslušný soubor vyhodnocen algoritmem detekce zbrojních plánů (firearms blueprint detection algorithm).

Algoritmus má za úkol:

1. Vyhodnotit soubor (STL, G-code nebo jiný CAD formát).
2. Zjistit, zda lze soubor použít k výrobě střelné zbraně nebo nelegálního dílu.
3. Podezřelý soubor zablokovat — stroj se nespustí.

Zákon nevyžaduje jen software. Vyžaduje, aby byl tento mechanismus přítomen přímo v každém prodávaném zařízení. Zároveň ruší možnost online prodeje a zásilkového doručení — veškerý prodej a přenos 3D tiskáren musí probíhat osobně (in-person). Pokuty za porušení dosahují až 10 000 USD za incident.

Zákon neobsahuje žádné výjimky pro:

• komerční výrobce (automobilový, letecký, medicínský průmysl),
• výzkumné instituce,
• federálně licencované zbrojíře (federally licensed gunsmiths),
• školy a vzdělávací instituce.

3. Trestný čin za digitální soubor

Subpart A zavádí nový typ trestného činu: distribuci nebo držení digitálního návrhového souboru, který by mohl sloužit k výrobě dílu střelné zbraně, je nově zločinem třídy E (Class E felony), pokud jej sdílíte s kýmkoliv, kdo není federálně licencovaným zbrojířem registrovaným v New Yorku.

Podle výkladu zákona se tato definice teoreticky vztahuje na:

• novináře reportující o dané problematice,
• výzkumné pracovníky studující 3D tisk a bezpečnost,
• designéry a umělce pracující s tvarovými soubory.

Trestní třída E v New Yorku odpovídá trestu odnětí svobody až na 4 roky.

4. Technický problém: proč to pravděpodobně nefunguje

Zákon naráží na zásadní technické překážky, na které upozornily firmy i nezávislí experti.

4a. Algoritmus čte geometrii, ne záměr

Detekční algoritmus porovnává tvary — geometrii objektu. Problém je, že běžné průmyslové díly sdílejí geometrii se součástkami zbraní. Trubka vypadá jako hlaveň, konzola jako rám zbraně, konektor jako spoušťový mechanismus. Jeden výrobce otestoval svůj firmware na navrhovaném algoritmu ještě před přijetím zákona: systém označil 17 % zcela legitimních tisků jako podezřelých — šlo o díly motorů, jígy, nástroje.

Firma Adafruit a její spoluzakladatel Philip Torrone to shrnuli lapidárně:

„Nevyžadujeme, aby stolní pily skenovaly dřevo kvůli zbraňovým tvarům. Nevyžadujeme, aby soustruhy volaly domů, než začnou obrábět kov. Ale přesně to tento zákon dělá s každým strojem, každým souborem a každou zakázkou."

4b. Open-source firmware — Marlin, Klipper, RepRap

Drtivá většina desktopových 3D tiskáren a CNC strojů běží na open-source firmwaru — primárně Marlin a Klipper. Tento software vyvíjejí dobrovolníci a komunity, není připojen ke státní databázi a není navržen pro compliance infrastrukturu. Stroje jsou navíc velmi často offline — záměrně nepřipojeny k internetu. Implementace zákonného požadavku by vyžadovala kompletní přepis firmwaru, což je technicky i kapacitně mimo možnosti komunitních projektů.

EFF (Electronic Frontier Foundation) zákon veřejně oponovala a označila blocking technology za "cenzurní software sledující každý tisk".

5. Software ThreeDGunT a role manhattanského státního zástupce

Zákon nevznikl ve vzduchoprázdnu. Španělská firma Print&Go se sídlem v Lleida (Katalánsko) již dříve vyvinula software nazvaný 3D GUN'T. Tento systém:

• porovnává každou tiskovou zakázku s databází zbrojních plánů,
• používá AI k rozpoznávání tvarů typických pro součástky zbraní,
• v případě shody automaticky blokuje tisk a upozorní správce.

Print&Go má přes 420 000 uživatelů a software je integrován přímo do firmwaru zařízení při výrobě.

Manhattanský okresní státní zástupce Alvin Bragg začal tento software prosazovat u výrobců 3D tiskáren ještě před tím, než zákon existoval. V roce 2025 zaslal dopisy firmám Creality a Flashforge s hrozbou právní odpovědnosti, pokud software 3D GUN'T neadoptují. Vyzval rovněž k odstranění zbrojních CAD souborů z cloudových platforem výrobců.

Jinými slovy: vymáhací mechanismus byl postaven dříve, než byl zákon napsán. Zákon pak byl upraven tak, aby odpovídal již existujícímu řešení.

6. Chystané zákony: prověrka před koupí tiskárny

Paralelně se v zákonodárném sboru New Yorku projednává Assembly Bill A2228 (a jeho senátní protějšek S3562), který dosud nebyl přijat, ale je aktivní v komisích obou komor. Tento návrh by zavedl povinnou prověrku trestní minulosti při koupi 3D tiskárny — stejný typ prověrky jako při koupi střelné zbraně. Prodejce by musel žádat státní divizi trestního soudnictví, která má 15 pracovních dní na rozhodnutí.

Zákon sponzoruje assembleymemberka Jenifer Rajkumar a v různých podobách koluje v zákonodárném sboru od roku 2023.

7. Šíření do dalších států

New York není jediný. Washington State projednával HB 2321 — prakticky identický zákon vyžadující blocking technology v 3D tiskárnách. Podle návrhu by washingtonský generální prokurátor vytvořil a průběžně aktualizoval databázi zakázaných zbrojních souborů. Zákon byl v lednu 2026 postoupen do komise pro občanská práva a soudnictví.

Vzorový zákon, jakmile projde v jednom státě, mají ostatní tendenci kopírovat — a výrobci, kteří chtějí prodávat v celých USA, si nemohou dovolit vyrábět dvě různé verze produktu. V praxi tedy regulace jednoho státu de facto ovlivní zboží prodávané v celé zemi.

Přehled klíčových faktů

Zdroje

• New York State Legislature — S.9005 / A.10005C text zákona
• The Reload — New York Bans Digital Gun Files, Aims at 3D Printers
• Electronic Frontier Foundation — Stop New York's Attack on 3D Printing
• Reclaim the Net — New York Budget Bill Mandates File Scans for 3D Printers
• 3D Printing Industry — Adafruit Warns of Flaws in the New Firearm Screening Bills
• Manhattan DA — D.A. Bragg Calls On 3D-Printing Companies To Address Proliferation Of Illegal Firearms
• Print&Go — 3D GUN'T: Print&Go's solution to prevent 3D printed Ghost Guns
• Fabbaloo — Washington Bill Would Require Weapon-Blocking Software in 3D Printers
• NY State Assembly — A2228 — background check bill
• NYS Focus — What's in the 2026 NY State Budget
• Times Union — Hochul pushes ban on 3D technology used to make guns

The post New York schválil zákon o sledování 3D tiskáren a CNC strojů first appeared on Hard Wired.

Nálepka za pár korun, telefon, a najednou Vám URL otevírá samo. NFC tagy z rodiny NTAG patří k nejlevnějším způsobům, jak fyzickému světu přidat softwarovou vrstvu — a přitom na to nepotřebujete pájku, kompilátor ani Arduino. Tenhle článek je hands-on návod, jak zapsat URL na NTAG215 přímo z iPhonu pomocí aplikace NFC Tools. Po cestě vysvětlím, co se v čipu při zápisu skutečně děje, protože pochopit, co máte v ruce, je polovina úspěchu příštího projektu.

Co je NTAG a proč by Vás měl zajímat

NTAG je rodina pasivních NFC čipů od firmy NXP Semiconductors. Pracují na 13,56 MHz, splňují standard NFC Forum Type 2 a ISO/IEC 14443-A, a nemají vlastní napájení — energii i hodinový signál si berou z magnetického pole čtečky (typicky Vašeho telefonu). To je důvod, proč Vám tag vydrží roky bez údržby a proč stojí v řádu korun.

Pro makery jsou zajímavé tři varianty:

Čísla v praxi: do NTAG213 se vejde URL do zhruba 130 znaků (po odečtení NDEF režie), do 215 přibližně jeden plnohodnotný kontakt s telefonem a e-mailem, do 216 i krátká Wi-Fi konfigurace plus URL bokem. Nálepky se prodávají od 5 Kč za kus, kvalitní plastové karty od 15 Kč, klíčenky od 20 Kč. Pro experimenty se hodí balíček deseti kusů od českého dodavatele (neven.cz) nebo dvacet kusů z AliExpressu — cenový rozdíl je marginální, ale dodací doba zásadní.

Potkáte je všude. Marketingové nálepky v obchodech, vstupenky na lyžovačku, visačky na zboží proti padělání, Amiibo figurky od Nintenda, párovací tagy bezdrátových sluchátek. NXP udává životnost 10 let retence dat a 100 000 zápisových cyklů, což pro většinu maker projektů znamená „vydrží to déle než zájem o projekt".

Anatomie čipu

Vnitřek NTAG215 si lze představit jako sešit rozdělený na 135 stránek po 4 bajtech. Některé stránky jsou Vaše hřiště, jiné jsou výrobní data, která nezměníte ani kdybyste chtěl.

Page 0x00 – 0x02   UID a system bytes      (read-only)
Page 0x03          Capability Container    (jednou píšete, OR-uje se)
Page 0x04 – 0x81   User memory             (504 B, zde žije Vaše data)
Page 0x82          Dynamic Lock Bytes
Page 0x83 – 0x84   Konfigurace (AUTH0, ACCESS)
Page 0x85          PWD (heslo, 4 bajty)
Page 0x86          PACK (potvrzení, 2 bajty)

UID (Unique Identifier) má 7 bajtů a je z výroby spálené v křemíku — žádná aplikace ho nepřepíše. Slouží mimo jiné jako sůl pro výpočet hesla u Amiibo (ale o tom zase jindy).

User memory je oblast, kam píšete přes NFC Tools. Data se ukládají ve formátu NDEF (NFC Data Exchange Format), což je standardizovaná obálka NFC Fora. Bez NDEF by si Váš iPhone se zápisem na Android tagem nerozuměl — díky NDEF rozumí oba.

Configuration pages určují, jestli je čip chráněn heslem (registry PWD a AUTH0), jestli a od které stránky platí ochrana (AUTH0), a jestli má heslo limit neúspěšných pokusů (ACCESS bit AUTHLIM). Když na ně narazíte v NFC Tools, většinou se jim chcete vyhnout, dokud nevíte, co děláte — špatně nastavený AUTHLIM dokáže udělat z funkčního tagu drahou nálepku natrvalo.

NTAG215 navíc umí pár chytrostí navíc oproti staršímu NTAG203: 32-bitové heslo (PWD_AUTH), digitální podpis pravosti od NXP (ECC originality signature, který odlišuje pravé NTAG od čínských klonů) a tzv. UID mirror, kdy si do NDEF zprávy můžete nechat automaticky zrcadlit UID čipu — užitečné pro per-tag analytiku bez nutnosti programovat každý kus zvlášť.

Co budete potřebovat

K tomu, co budeme dělat, stačí překvapivě málo:

• iPhone 7 nebo novější s iOS 13 a výš. Starší modely NFC sice mají, ale nepodporují třetí stranou ovládaný zápis. Pokud máte iPhone 13 a novější, bude čtení a zápis jednoznačně rychlejší a spolehlivější díky lepší anténě.
• NFC Tools od vývojáře Wakdev, zdarma z App Store. Existuje i placená „Pro Edition", ale pro zápis jednoduché URL ji nepotřebujete. Pro varianty jsou navíc plánovací funkce a profily — užitečné, až budete chtít sériově programovat víc tagů najednou.
• NTAG215 nálepku, kartu nebo klíčenku. Pro tento návod používám NTAG215, ale postup je identický pro NTAG213 i NTAG216, lišit se bude jen kapacita.

Jedna technická poznámka k platformě: iPhone má NFC anténu v horní části zařízení, kolem objektivu kamery. Android telefony ji mívají vzadu uprostřed nebo dole. Pokud jste zvyklý držet Android telefon plochou stranou na tag, s iPhonem to nepůjde — musíte přiložit horní hranu. Začátečníci se tady často zaseknou na tom, že „tag prostě nefunguje", přitom jen čtou špatnou částí telefonu.

Druhá poznámka, méně příjemná: iOS je v NFC schopnostech rok zpátky oproti Androidu. Pro zápis NDEF a čtení standardních tagů je vše v pořádku, ale na low-level operace (přímý přístup k jednotlivým stránkám, práce s MIFARE Classic, dump celé paměti) potřebujete buď Android, nebo specializovaný hardware jako Proxmark3 či Flipper Zero. Pro náš úkol je iPhone naprosto dostatečný.

Hands-on: zápis URL hardwired.dev

Konečně k věci. Předpokládám, že máte NFC Tools nainstalovanou a v ruce prázdný NTAG215. Postup má pět kroků.

Krok 1: Přečtěte tag

Otevřete NFC Tools a v dolním menu zvolte záložku Read. Telefon se přepne do skenovacího režimu a nahoře vyskočí systémový dialog „Připraveno ke skenování". Přiložte horní hranu iPhonu k tagu a držte ji nehnutě zhruba sekundu. Telefon zavibruje a vrátí Vám informace o čipu.

V odpovědi uvidíte něco jako:

Serial Number: 04:A3:B7:12:5F:80:C1
Tag type: ISO 14443-3A (NXP - NTAG215)
Technologies available: NFC A
Manufacturer: NXP Semiconductors
Maximum data size: 504 bytes
NDEF: Yes (writable, 0/504 bytes used)

Tohle je výchozí stav nového čipu. UID začínající 04 je typické pro NXP. NDEF je deklarováno jako prázdné a zapisovatelné.

Krok 2: Vytvořte záznam

Přepněte se na záložku Write. Klepněte na Add a record. Otevře se seznam typů — vCard, Wi-Fi, Bluetooth pairing, e-mail, telefon, geolokace, a další. Vás zajímá první položka: URL / URI.

V dalším okně vyberte schéma. NFC Tools má rozbalovací menu s běžnými prefixy (http://, https://, tel:, mailto: a další), a zbytek URL napíšete do textového pole. Pro náš účel:

• Schéma: https://
• URL: hardwired.dev

Aplikace Vám pod políčkem ukáže, kolik bajtů záznam zabere — pro https://hardwired.dev to bude méně než 20 bajtů. Klepněte na OK. Vrátíte se na obrazovku Write, kde teď uvidíte jeden NDEF záznam typu URI připravený k zápisu.

Krok 3: Zapište na tag

Klepněte na velké tlačítko Write. Telefon znovu otevře skenovací dialog. Přiložte horní hranu iPhonu k tagu a držte. Zápis NDEF zprávy o 20 bajtech trvá zhruba 200 milisekund — celý dialog ale obvykle zmizí až po vteřině, protože iOS si dává malou rezervu na ověření.

Po úspěšném zápisu uvidíte zelenou hlášku Write complete. Pokud místo toho dostanete chybu, nejčastější příčiny jsou tři: tag je zamčený lock bytes (nelze nic dělat), tag má heslo (potřebujete ho zadat ve Security menu), nebo jste ho odtrhli moc rychle (zkuste znovu).

Krok 4: Ověřte zápis

Vraťte se na záložku Read a tag přečtěte znovu. Tentokrát uvidíte v odpovědi přibyl řádek navíc:

NDEF: Yes (writable, 17/504 bytes used)

Record 0
  Type: URI
  URI: https://hardwired.dev

Tag teď nese Vaši URL. 17 z 504 bajtů využito — zbytek paměti je stále volný a Vy můžete přidat další záznamy (např. WhatsApp link, kontakt, Wi-Fi heslo) bez omezení, dokud nevyplníte kapacitu.

Krok 5: Otestujte v reálném světě

A teď to nejlepší. Zamkněte iPhone (jen stisk power tlačítka, do podivných stavů ho dávat nemusíte) a přiložte ho horní hranou k tagu. Na zamčené obrazovce se objeví banner s URL hardwired.dev. Klepnutím se otevře Safari.

Tohle je důležitý moment: na iPhonu funguje background NFC scanning pouze pro NDEF záznamy standardních typů — URL, telefonní číslo, e-mail, geolokace a několik dalších. Wi-Fi konfigurace nebo vCard se zamčené obrazovce neobjeví, protože iOS je nevyhodnocuje na pozadí (z bezpečnostních důvodů). Pokud chcete, aby tag spustil Wi-Fi připojení, musíte mít NFC Tools otevřenou, nebo využít Shortcuts Automation, kterou iOS k NFC tagům umí přivázat (ale to je téma na samostatný článek).

Gratuluji — máte první funkční NTAG.

The post NTAG čipy a jak je naprogramovat z iPhonu first appeared on Hard Wired.

15. dubna 2026 prolomil bezpečnostní výzkumník Paul Moore oficiální evropskou aplikaci pro ověřování věku za dvě minuty. Snímky obličejů z dokladů ukládala nešifrované. Biometrickou autentizaci šlo obejít přepnutím jednoho booleanu v config souboru. Francouzský výzkumník Baptiste Robert to nezávisle potvrdil.

O necelý měsíc později, 6. května, sdílela Výzkumná služba Evropského parlamentu na sociálních sítích lednový briefing o VPN. Označila je za „loophole in the legislation that needs closing". Tedy mezeru, kterou je třeba zacelit, protože děti přes VPN obcházejí ten samý systém ověřování věku, který jiný hacker prolomil v podivně krátkém čase.

A v tuhle chvíli česká média ztratila nervy.

Anatomie titulkové paniky

cnews.cz: „Konec anonymního surfování přes VPN". tiscali.cz: „EU jde po soukromém internetu". centrum.cz/cdr.cz: „Závažný útok na soukromí". V překladu: Brusel zítra zatne.

Reálně? EPRS je think-tank Evropského parlamentu. Píše analytické briefy pro poslance, ne zákony. Materiál ze 6. května není legislativní návrh, je to shrnutí debaty, ve které někdo nahodil tezi a publicistika ji zachytila jako fakt.

Nejstřízlivější hlas v ČR má v tomhle Petr Koubský v rozhlasovém Online Plus. „Orgán demokratické Evropy to udělat nemůže," říká k případnému zákazu. „Drtivá většina podobně radikálních návrhů skončí pod stolem."

Koubský má pravdu v jedné věci. Plošný zákaz VPN je v EU politicky neprůchodný. Naráží na DSA, GDPR, na ekonomický fakt, že VPN potřebují všechny korporace s remote workery. A pokud by k němu náhodou došlo, technicky by ho šlo vynutit jedině přes deep packet inspection na úrovni ISP. Což je infrastruktura, kterou dnes provozují Čína, Rusko a Írán. EU ne. A nikdo soudný nechce, aby ji EU začala stavět.

Jenže Koubský upozorňuje ještě na něco. Pracovní materiál Rady EU z roku 2025 zmiňuje, že členské státy zvažují přidat VPN na seznam služeb spadajících pod data retention. Čili povinné ukládání metadat o připojení. Kdo se kdy odkud kam připojil. Bez obsahu, ale s identitou.

A o tom by se mělo psát. Ne o zákazu, který nepřijde.

Goodhartův zákon pro internetovou regulaci

Když cíl regulace prochází přes proxy ukazatel, ten proxy ukazatel se sám stane cílem a celý smysl regulace se rozpadne. Britský Online Safety Act platí od července 2025. Měl chránit děti před pornografickým obsahem. Reálný výstup? Po jeho zavedení vyletěla stahování VPN aplikací v UK o 1 800 % během prvního měsíce. Proton VPN hlásil nárůst registrací o 1 400 až 2 000 procent v hodinách po zapnutí kontrol. Děti se nepřestaly dívat na porno. Naučily se obcházet věkové kontroly v devíti letech místo třinácti. A jejich rodiče si nainstalovali NordVPN spolu s nimi, protože měli pocit, že British Telecom je sleduje.

Britská Children's Commissioner Rachel de Souza na to v BBC Newsnight reaguje předvídatelně. VPN označuje za „absolutely a loophole that needs closing". Volá po věkovém ověřování pro samotné VPN služby. House of Lords v lednu odhlasoval 207 ku 159 dodatek k Children's Wellbeing and Schools Bill, který by zakázal poskytování VPN dětem. Vrátilo se to do Dolní sněmovny. Není to zákon.

Ale logika je tady jasná. Když ověřování věku funguje špatně, přidej další vrstvu ověřování. Když ani ta nefunguje, přidej třetí. Až nakonec stojí mezi devítiletým dítětem a kdejakým webem tři biometrické skeny, dva systémy national ID a jeden požadavek na verifikaci VPN klienta. Devítileté dítě mezitím používá Tor přes Tails na flash disku, který si vyrobilo podle YouTube návodu.

Goodhart by se bavil.

Děti budou.

Bezpečnost přes obscurantismus, jen obráceně

Co EU reálně řeší, není dětská pornografie. Je to nepříjemný fakt, že po dvou desetiletích politiky „internet pro všechny" se objevuje cosi jako digitální nepřehlednost. Lidé používají Signal. Šifrovaný DNS. WireGuard běžící na vlastní VPS za pět euro měsíčně. Self-hosted instance Nextcloudu. Místo Chromu Brave nebo Mullvad Browser. A státní aparát, který si zvykl, že webový provoz teče přes pět velkých korporací s funkčním legal interface, najednou neví, co se mu děje pod nosem.

Místopředsedkyně Evropské komise Henna Virkkunen to 29. dubna 2026 řekla na tiskové konferenci nahlas. VPN by neměly sloužit k obcházení age verification. Tečka. Že VPN ale slouží primárně k něčemu úplně jinému, třeba k tomu, abych se z hotelové WiFi v Bangkoku připojil bezpečně do firemní infrastruktury, to v jejím prohlášení nezaznělo. Já sám používám WireGuard denně pro připojení k vlastní laboratoři přes Tailscale. Sto procent provozu jde tunelem. A je mi naprosto jedno, jestli tam někde v paketu plave packet, který by někoho v Bruselu naštval.

Tedy bylo mi to jedno. Dokud jsem nečetl Council Working Paper, který Koubský zmiňuje.

Data retention je tichý jed

Logování metadat má jednu vlastnost, kterou plošný zákaz nemá: nedělá rozruch. NordVPN, Mullvad, Proton, všichni budou dál fungovat. Reklama bude dál slibovat anonymitu. Logo zámku v rohu obrazovky bude dál uklidňovat uživatele. Jenom v server room v Bukurešti nebo v Zürichu poběží daemon, který do databáze ukládá: IP X se v 14:23:11 připojila k serveru Y, který má ven adresu Z. Trvalo to 4 hodiny. Přeneslo se 12 GB.

Žádný obsah. Žádné dešifrované zprávy. Jen kdo, kdy, odkud, kam. Což je v digitální stopě často víc, než je obsah samotný. Metadata mají tu nepříjemnou vlastnost, že přežijí všechno end-to-end šifrování světa. Vědí to v NSA. Vědí to vyšetřovatelé. A teď to ví Rada EU.

Pro VPN poskytovatele to znamená dvě možnosti.

Buď vyhoví, a celá jejich marketingová narativa o no-logs policy se stane fikcí. Mullvad dnes hrdě tvrdí, že nezná IP svých uživatelů. V regulovaném scénáři by ji znát museli. Nebo se z EU stáhnou. Což udělá ten lepší kus z nich, jenže pak zbude uživateli volba mezi statně registrovaným provozovatelem s povinným logováním a turkmenstánskou společností s pochybným whois záznamem. Nebudu hádat, co si vybere medián českého uživatele.

A k tomu se přidá ještě jeden detail, který se v české debatě skoro neobjevuje. Open Dialogue Foundation prezidentka Lyudmyla Kozlovska upozorňuje, že přesně tímhle jazykem se argumentuje v autoritářských režimech. „VPN slouží k obcházení zákonů" je rétorická figura, kterou používá Roskomnadzor v Rusku, Ministerstvo informací v Bělorusku a regulátoři v Číně už dvacet let. Když ji začne používat Brusel, nezíská tím morální převahu. Ztrácí ji.

Co s tím

Devatenáct organizací (Mozilla, EFF, Proton, Tor Project, Mullvad a další) poslalo 5. května 2026 britským ministrům otevřený dopis. Cituji volně, protože stojí za to: omezení nástrojů pro ochranu soukromí podkopává schopnost uživatelů pohybovat se po síti bezpečně a budovat digitální gramotnost. Přeloženo do hardwired řeči: vyrobíte děti, které neumí používat HTTPS, ale umí obcházet státní DPI.

V Bruselu se zatím nic neděje. Formálně. EPRS briefing je analytický papír. Council Working Paper je interní pracovní materiál. Henna Virkkunen na jedné tiskovce vyslovila jednu větu. Komise zatím nepředstavila konkrétní návrh.

Jenže když se podíváš na vektory tlaku, na Online Safety Act v UK, Senate Bill 73 v Utahu, australský zákaz sociálních sítí pro děti do šestnácti let, French double-blind verification system, vidíš, že západní demokracie se v posledních dvou letech pomalu přesouvají od regulace obsahu k regulaci samotné infrastruktury anonymity. Není to konspirace. Je to inercie. Každý regulátor řeší svůj malý problém. Skleníkový efekt vznikne sám.

Pokud nás v ČR něco potká, nebude to oznámení „VPN je od dnešního dne zakázána". Bude to novela zákona o elektronických komunikacích, která rozšíří povinnost ukládání provozních a lokalizačních údajů na poskytovatele VPN služeb. Předloženo poslancem, kterého nikdo nezná. Schválena ve třetím čtení v pátek odpoledne. A v pondělí budeš mít metadata svého WireGuard tunelu uložená v centrální databázi po dobu šesti měsíců.

A teď zkus někomu na Twitteru vysvětlit, proč tě to štve.

The post EU nezakáže VPN. Donutí poskytovatele logovat metadata first appeared on Hard Wired.

Na střeše budovy Red Hatu v Brně-Medlánkách stojí krabička za pár tisíc, která dokáže to, co před dvěma lety zvládla jen profesionální infrastruktura: spolehlivě doručit zprávu přes půl republiky bez jediného mobilního operátora. Jmenuje se techpark.meshcore.cz a je to jeden z uzlů, na kterých teď stojí česká MeshCore síť.

V minulém článku jsme si vysvětlili, proč MeshCore existuje. Tohle je díl o tom, jak se do něj reálně připojit, co koupit, čeho se v české komunitě vyvarovat a proč není dobrý nápad nechávat na síti běžet vlastního pingovacího bota.

Co se za poslední čtyři měsíce změnilo

Když jsme o MeshCore psali loni v červenci, byla to spíš čerstvá zajímavost než infrastruktura. Mapa repeaterů byla řídká, návody chyběly, lidi tipovali, jestli se z toho stane další zaprášený meshtasticový pokus, nebo něco trvalejšího.

Stalo se to druhé. Mezi únorem a dubnem 2026 česká síť přerostla sama sebe. Jiří Eischmann, který má na blogu jeden z nejčtenějších českých textů o MeshCore, to popisuje jednoduše: sever Brna je tak hustě pokrytý, že mu na jednu zprávu odpoví klidně šest repeaterů najednou. Spojení Brno–Hradec Králové, které ještě v únoru chodilo jen přes jižní trasu Děvín–Hostýnské vrchy–Praděd, teď chodí severní cestou Babí lom–Orlické hory a zprávu i s potvrzením doručí během několika sekund. A když je někdo na Ještědu, dokáže paket skočit až přes Brdy – jeden hop na víc než sto kilometrů.

Síť se za tu dobu posunula i na úrovni firmwaru. Verze 1.15 vyšla 19. dubna 2026 a přinesla podporu pro Heltec V4.3, OTA aktualizace pro nRF52 desky přes mobilní aplikaci a pár změn chování, které stojí za přečtení, než člověk začne flashovat. Heltec V4.3 navíc umí ovládat FEM hardware, což komunitní buildy jako EasySkyMesh 14.1 dovedly až na 5,5 mA klidového proudu. Pro solární repeater je to zásadní detail.

A pak je tu jedna věc, která komunitu poslední tři měsíce zaměstnává nejvíc.

Kampaň 2-byte: proč si po prvním flashi musíš změnit jednu položku v menu

Když dva uzly v síti vygenerují klíče, jejichž první bajt náhodou koliduje, je problém. Cesty (path) v MeshCore se počítají z hashe veřejného klíče a jednobajtová verze umí adresovat jen 256 unikátních prefixů.

V březnu 2026 už v české síti žádné úplně volné prefixy nebyly. Síť rostla rychleji, než byl protokol původně navržený.

Řešení přišlo s firmwarem 1.14. Dvoubajtový hash sníží počet možných hopů (z 64 na 32), ale dá síti 65 535 unikátních prefixů – tedy řádově dost na to, aby kolize přestaly být problém. Česká komunita to vzala jako koordinovanou kampaň. Provozovatelé repeaterů jeden po druhém aktualizovali firmware a od konce dubna je 2B nastavení reálným standardem.

Pro koncového uživatele to znamená jednu položku v menu. Po prvním flashi otevřeš v aplikaci MeshCore Experimental Settings a Default Path Hash Size přepneš na 2 bytes. „V experimentálním nastavení si teď nastavte Výchozí velikost hashe cesty na 2b," stojí přímo na meshcore.cz. Když to zapomeneš, fungovat to bude, ale tvoje zprávy budou v menšině a u některých starších repeaterů by mohly zmizet úplně.

Takhle prozaicky se v praxi řeší škálování decentralizované sítě. Žádný governance token, žádné hlasování přes blockchain. Telegramová skupina, hlasování na Facebooku, postupný rollout.

Tři role, tři firmwary

Na rozdíl od Meshtasticu, kde přeposílá víceméně každý uzel, MeshCore strukturu sítě rozdělil na tři role. To je hlavní rozdíl mezi oběma sítěmi a důvod, proč se v reálném provozu chovají úplně jinak.

Companion je uzel, který si dáš do kapsy nebo na stůl. Přes Bluetooth (případně USB nebo WiFi, podle toho, jaký firmware nahraješ) ho spojíš s mobilem a posíláš a přijímáš zprávy. Provoz ostatních uživatelů nepřeposílá – pokud zpráva není určená tobě, companion ji ignoruje. Tím šetří éter i baterii.

Repeater je naopak součást infrastruktury, ne relé navíc. Jeho jediným úkolem je předávat pakety smysluplným směrem. Bez Bluetooth, bez displeje, často bez krytu kromě 3D tištěné krabičky. Patří na střechu, komín, vysílač nebo kopec. Solární panel, 18650 nebo LiFePO4 baterie, anténa s rozumným výhledem. Operátor si ho nakonfiguruje přes web config tool ještě před tím, než ho někam pověsí, protože jakmile je nahoře, není kam strčit USB-C.

Room Server je třetí typ. Něco jako lokální BBS pro region – uzel, který umí ukládat zprávy, sdružovat uživatele do tematických kanálů a fungovat jako store-and-forward, když je adresát zrovna mimo dosah sítě.

Role nejde přepnout konfigurací. Když chceš ze svého companionu udělat repeater, musíš ho znovu flashnout. To zní jako omezení, ale dává smysl: firmware pro každou roli je jinak optimalizovaný a komunita má jistotu, že když má někdo v síti repeater, je to opravdu repeater, a ne mobil, kterému zrovna umřela baterka.

Hardware: co reálně koupit v polovině roku 2026

Tabulka, kterou bych si přál mít, když jsem s MeshCore začínal.

K hardwaru pár poznámek z praxe, protože tabulka neřekne všechno.

Heltec V3 je pořád nejrozšířenější deska v české síti. Funguje, je levný, návodů na něj je plný Telegram. Pokud začínáš a nechceš řešit detaily, vezmi Heltec V3 nebo V4 v EU variantě (868 MHz, ne 915 MHz – ten je pro USA a v české síti nezachytí nic).

T-Deck je jiná liga. Pro lidi, co chtějí mít komunikaci úplně mimo telefon – na hory, do auta na dlouhé tahy, nebo prostě jako koncept „vlastní pager bez internetu". Pořád stojí kolem 3500 Kč, ale když k tomu přidáš baterii a pořádnou anténu, cena se snadno přehoupne přes pět litrů.

A SenseCAP Solar Node P1 Pro je teď v české komunitě nejcitovanější volba pro hotový repeater. Eischmann o něm píše: „Úplně se mi nechtělo bastlit vlastní řešení, takže jsem zvolil ověřené hotové řešení SenseCAP Solar Node P1 Pro." Pět tisíc je dost peněz na to, aby ses k nákupu rozhoupal, ale když jde o střechu rodinného domu, kde má mít spojení tvůj soused i ty, je to investice, která se vrátí.

BOM pro vlastní solární repeater (DIY varianta, ~1700 Kč)

Pro úplnost, kdyby ti to nedalo a chtěl bys ho postavit.

Zhruba takhle vypadá rozumný DIY repeater postavený na Heltecu, který přežije i bez sítě:

• Heltec V3 (EU 868 MHz) – 750 Kč
• LiFePO4 článek 18650, 1500 mAh – 250 Kč (pozor na firmware ≥ 1.12, kde byly s LFP/LTO články hlášené problémy s napěťovou křivkou)
• TP4056 modul s ochranou – 30 Kč
• 6V/5W solární panel – 200 Kč (zimní slunce v ČR je nízké a krátké, dimenzuj radši s rezervou)
• LoRa anténa 868 MHz, zisk 3–5 dBi – 200 Kč
• Pigtail SMA / IPEX – 60 Kč
• 3D tištěná krabička – pár desítek korun za filament
• IP65 průchodka pro anténní kabel – 80 Kč
• Spojovací materiál, dlaždice, držák – podle situace

Cena pohodlně pod dva tisíce, pokud máš tiskárnu doma. Když kupuješ všechno nové a tiskneš v servisu, přidej k tomu pár stovek za filament a držák antény.

Frekvence a nastavení regionu pro ČR

Tohle bývá první past pro lidi, co začínají. MeshCore v Evropě obecně jede na pásmu 868 MHz, ale česká komunita se sjednotila na konkrétním presetu, který se ne vždycky shoduje s výchozím nastavením „EU" v aplikaci. Konkrétně: frekvence 869,432 MHz, šířka pásma 62,5 kHz, spreading factor 7, coding rate 5, vysílací výkon 22 dBm.

Co to znamená v praxi: vysíláš na bezlicenčním pásmu, žádné poplatky, žádná registrace. Ale musíš respektovat duty cycle limit 1 % – tedy ze sta sekund vysílat nejvýš jednu. Firmware to hlídá sám, ale když si pustíš na síti bota, který každé tři minuty odešle status update, ten limit ti tiše vyžere a tvoje skutečné zprávy se přes něj nedostanou.

A teď k tomu botovi.

Etiketa: žádné automaty, žádné scrapery

Česká MeshCore komunita má jedno pravidlo, které visí přímo na úvodní stránce meshcore.cz a v každém druhém příspěvku na Telegramu. „Síť budujeme striktně pro komunikaci mezi lidmi (keyboard to keyboard). Vyvarujte se automatizovanému posílání zpráv, vyčítání repeaterů nebo jiné komunikaci, která není mezi lidmi!"

Důvod je matematický. LoRa síť má reálnou propustnost zhruba tří kilobitů za sekundu. To není opomenutí, to je fyzika daná modulací. Komunita po hlasování konstatovala, že 75 % generovaného provozu tvořili boti, což snižuje pravděpodobnost doručení skutečných zpráv. Vznikla z toho samostatná kampaň: provozovatelé botů se mají vypnout. Jediný, kdo tam má povolení zůstat, je El Pong – komunitní bot s AI a emailem, který si komunita schválně nechala jako experiment.

Když si tedy zapneš svůj první uzel a napadne tě napsat skript, který bude každou hodinu pingovat dosah, prostě to nedělej. Není to vůči nikomu fér.

Totéž platí pro scrapery a „monitory pokrytí". Existuje veřejná mapa i analyzer, oba běží na backendu, kde tu zátěž nese server, ne LoRa éter. Když si chceš zmapovat vlastní dosah, projdi se s companionem a koukej do aplikace. Žádný autopilot.

Krok za krokem: od krabičky k první zprávě

Předpokládejme Heltec V3 v EU 868 MHz verzi, Android telefon a Chrome v notebooku.

Připoj desku přes USB-C k počítači. Pozor na kabel – některé „nabíjecí" mají jen napájení a žádná data, a flasher se ti k čipu nedostane. Když to nepřipojí, zkus jiný kabel dřív, než začneš googlovat ovladače.

Otevři flasher.meshcore.co.uk v Chromu (nebo jiném prohlížeči postaveném na Chromiu – Edge funguje, Firefox bohužel ne, protože nemá Web Serial API). Po načtení vyber model desky. Pro Heltec V3 zvol Community Firmware a roli Companion Bluetooth. Stiskni Flash. Asi po půl minutě má deska firmware.

Stáhni si aplikaci MeshCore – existuje pro Android i iOS. Po spuštění klepni na „přidat zařízení" a aplikace najde tvůj uzel přes Bluetooth. Spárování chce PIN, který se ti zobrazí na OLED displeji.

První věc, kterou pak v aplikaci uděláš (ano, ještě před tím, než pošleš první zprávu): otevři Experimental Settings a přepni Default Path Hash Size na 2 bytes. To je ta kampaň, o které jsem psal výš. Pak nastav region – pro Česko buď použij preset EU Recommended, nebo manuálně nastav 869,432 MHz / BW 62,5 kHz / SF 7 / CR 5.

Teď klepni v aplikaci na ikonu vlny (advert) a pošli Flood Routed Advert. To je signál „jsem tady, kdo mě slyší". V Contacts by se ti během následujících sekund až minut měly začít objevovat repeatery a uživatelé v dosahu. Když ne, vystup na balkon nebo zkus jít k oknu. LoRa není WiFi a na úrovni ulice mezi paneláky se jí obvykle moc nedaří.

Pošli testovací zprávu do kanálu #test. Pokud uvidíš v aplikaci „Heard X repeat(s)", jsi v síti. Hotovo.

Linuxový klient Meshy: alternativa pro lidi, co nechtějí mobil

Pokud jsi typ člověka, co radši pracuje na notebooku než na mobilu, je tu pro tebe Meshy. Linuxový klient pro MeshCore, který od února 2026 píše Jiří Eischmann. Aplikace má dokonce funkce, které oficiální klient zatím nemá – třeba vykreslení trasy poslední úspěšné zprávy přímo na mapě v chatu.

Meshy se aktuálně distribuuje přes Flatpak repozitář a každý commit do gitu spouští nový build pro x86_64 i aarch64 (díky Roští.cz za poskytnutí builderu). Eischmann teď cílí na publikaci ve Flathubu – hlavní překážka prý je, že kvůli udev pravidlu pro připojení companionu přes USB potřebuje obejít sandbox pomocí flatpak spawn. Časem to vyřeší. Komunita kolem linuxového klienta roste a Meshy je teď nejstabilnější varianta, pokud chceš MeshCore používat z laptopu.

Pro lidi z radioamatérské scény, kteří už znají RTL-SDR, gpredict a další unixové utility, je Meshy přirozenější než přepínání mezi mobilem a notebookem. V brněnské komunitě je to čím dál jasnější volba.

Brno jako centrum české MeshCore scény

Když si zmapuješ aktivitu české komunity, jihomoravský trojúhelník vyčnívá. Většina nejaktivnějších provozovatelů sítě sedí v Brně. Jindřich Skácel měl v únoru 2026 přednášku na 216. srazu spolku OpenAlt na FIT VUT, ukazoval klientská zařízení a praktické nasazení repeateru, video je na vhsky.cz. Na budově Red Hatu v Medlánkách přímo běží repeater techpark.meshcore.cz, který kryje větší část severu Brna.

Není to náhoda. Brno má kombinaci, která MeshCore přeje: hustá technická komunita (Red Hat, FIT VUT, SUSE, NIC.CZ), aktivní open-source scéna kolem OpenAltu, prolínání ham a maker komunity a topologie s viditelností na okolní kopce (Babí lom, Děvín, Hostýn).

Eischmann to v jednom blogu trefil přirovnáním ke CZFree.Netu z přelomu nultých let – komunita, která bere infrastrukturu do svých rukou, protože ji to baví, ne protože musí.

Pokud bydlíš v Brně nebo okolí a chceš se připojit, je to teď nejjednodušší. Telegramová skupina meshcore_cz má aktivní topic Wiki a Repeatery, srazy OpenAltu v Red Hat Labu na FIT VUT chodí pravidelně každý třetí pátek v měsíci (i když ne každý je o MeshCore) a v Brně máš největší šanci potkat lidi, kteří síť reálně staví.

Jiné regiony pochopitelně taky fungují. Praha má pokrytí, Hradec a Liberec mají své sysopy, jižní Čechy mají svou skupinku. Ale hustota brněnské sítě v polovině roku 2026 je v republice unikum a kdyby ses chtěl podívat, jak vypadá MeshCore, když má kritickou masu, stojí za to si sem na jeden pátek vyrazit a vidět to z první ruky.

Co dál

Když máš companion v kapse a fungující spojení do sítě, je to první krok. Logické pokračování je vlastní repeater. Pokud bydlíš výš nebo máš střechu, je to nejspíš něco, co tvoje okolí ocení. Eischmannovi přes zimu umřely baterky na repeateru ivanovice.meshcore.cz, který byl 300 metrů od něj, a najednou byl bez spojení. Jeho ponaučení: „když závisíte na repeaterech ostatních, měli byste mít spojení alespoň na dva. Nebo mít vlastní." Síť odolnou proti blackoutu nepostavíš tím, že čekáš na sysopa o tři ulice dál.

Před tím, než si pořídíš hardware na repeater, vygeneruj si přes Key Generator vlastní prefix klíče. V březnu 2026 už volné jednobajtové prefixy nebyly. Při 2-byte hashi je situace lepší, ale stejně si zkontroluj v analyzeru, jestli zrovna tvůj generovaný prefix neběží už ten den někomu přes ulici.

A pokud chceš jít dál než ke klasickým textovkám – existuje GROUP_DATA, binární typ paketu, který firmware 1.15 přinesl pro pokročilejší aplikace. Telemetrie, řízení vzdálených zařízení, integrace s domácí automatizací. Část komunity tudy už šlape, v Brně víc, v ostatních městech méně.

Co MeshCore není a co se nestane: nikdy z toho nebude bezdrátový internet, nikdy nebude pohánět videohovory, nikdy nezvládne přenášet fotky v rozumném čase. To je v pořádku. Stačí, že umí to, co lidi v Karpatech, na chatě v Beskydech nebo v zatopeném Bohumíně skutečně potřebují: krátkou textovku, která projde, i když všechno ostatní leží.

A taková síť se buduje úplně stejně, jako se před třiceti lety budoval CZFree.Net. Po jednom uzlu, po jedné krabičce, po jedné neděli na střeše.

The post MeshCore v praxi: jak v Česku postavit vlastní LoRa uzel a nezapadnout first appeared on Hard Wired.

Představte si scénář: pošlete přes Telegram zprávu „dej mi vědět, když teplota čipu překročí 28 stupňů". Bot odpoví, že rozumí. Od té chvíle ESP32 hlídá teplotu sám. Bez cloudu, bez LLM volání, bez WiFi. Spadne vám internet? Hlídá dál. Restartujete ho? Po naběhnutí hlídá dál.

Tohle je WireClaw, open-source firmware od Maria Schallnera (na GitHubu M64GitHub), který vyšel poprvé veřejně 25. února 2026. Z hardware-first myšlení vznikla jedna z mála implementací AI agenta na MCU, která bere vážně otázku, co se stane, když AI selže. Tady si projdeme, jak to funguje, proč to vzniklo a kde to narazí.

Dvě smyčky, jeden čip

Klíčový designový trik: WireClaw na ESP32 logicky rozděluje práci na dvě nezávislé části.

Rule loop běží neustále a nedotýká se sítě. Čte senzory, vyhodnocuje uložená pravidla, spouští akce. Žádný HTTP request, žádná LLM inference. Když teplota přeleze práh, rozsvítí se LED nebo přijde Telegram zpráva, to celé v řádu milisekund, lokálně.

AI loop se probudí, jen když přijde zpráva přes Telegram, USB sériovku nebo NATS. Tehdy WireClaw udělá HTTPS na OpenRouter (nebo HTTP na lokální Ollamu), nechá LLM zformulovat odpověď a případně vytvořit nové pravidlo. Maximum je pět iterací s nástroji na jednu zprávu, pak se vše zabalí.

„The AI creates the rules. The rules run without the AI."

Tahle věta z dokumentace shrnuje celou filozofii. LLM se používá jako kompilátor lidského záměru do embedded logiky. Pravidlo, které vznikne, jde do flash paměti a od té chvíle žije svým životem. Reboot? Po načtení z flashe pokračuje, jako by se nic nestalo.

Pro někoho, kdo zkoušel postavit IoT s ChatGPT v hot loopu, je to úleva. Žádný API výpadek vám neshodí topení.

Co se vejde do ESP32

WireClaw potřebuje 4 MB flash a tři typy čipů: ESP32-C3, C6 nebo S3. Klasický ESP32 s Tensilica jádrem není podporován, kvůli OTA partition table requirementům. ESP8266 je mimo hru kvůli paměti.

Reálná spotřeba zdrojů podle oficiální dokumentace:

RAM:   59,7 %  (196 KB z 320 KB)
Flash: 51,4 %  (1,3 MB z 2,5 MB)

To je dost, ale ne na hraně. Zhruba 40 % RAM zbývá pro vaše vlastní rozšíření. Setup portal a webové GUI sedí v PROGMEM, takže RAM nežerou.

Doporučená volba je ESP32-C6 DevKit. Cena se v Číně pohybuje kolem 5–10 dolarů, RISC-V jádro je rychlé a WS2812B onboard LED rovnou slouží jako vestavěný actuator. ESP32-S3 dává smysl tam, kde plánujete složitější rule chains a chcete víc paměti.

Pravidla v praxi

Rule engine je dost expresivní. Pravidlo se skládá ze senzoru, podmínky (gt, lt, eq a další), prahu a akce. Vestavěných virtuálních senzorů je hned několik: chip_temp z interního čidla, clock_hour, clock_minute a chytrý clock_hhmm. Posledně jmenovaný kóduje čas jako hodina × 100 + minuta, takže 10:12 = 1012. Najednou jde plánovat přes prostou eq podmínku bez nutnosti řešit dvě pole zvlášť. Elegantní hack.

Akce zahrnují led_set (RGB LED), gpio_write, telegram, nats_publish a serial_send. V textových akcích funguje placeholder substituce: do zprávy můžete napsat "Teplota čipu: {chip_temp}°C" a engine to vyrenderuje z živých dat. Bez LLM, přímo v rule loopu.

Pokročilejší trik je rule chaining: jedno LLM volání může vytvořit multi-step sekvenci s non-blocking delays. Spustí se Telegram alert, po pěti sekundách se rozsvítí červená LED, po deseti se zhasne a publikuje se zpráva na NATS. Mezitím engine paralelně vyhodnocuje ostatní pravidla.

Co u všech těchto testovaných modelů funguje, a co ne, stojí za pozornost. Gemini 2.5 Flash zvládá chains excelentně za zhruba 4 sekundy. Claude Sonnet 4.5 taky, ale potřebuje 10 sekund. Qwen 2.5 7B selhává: chybějící kroky, špatné delays, někdy přímo syntax errors. Pokud vás zajímá cost/perf pro běžný hobby use, Gemini Flash přes OpenRouter je sweet spot.

NATS jako páteř

Tady WireClaw zachází dál než většina podobných projektů. NATS, lehký pub/sub broker, je integrovaný ve třech vrstvách.

První vrstva: virtuální senzory. Vytvoříte senzor typu nats_value se subscribe na subject, třeba home.room.temp. Cokoliv, co umí na NATS publishovat (Python skript, Home Assistant, jiný WireClaw, průmyslový PLC), najednou dodává data do rule enginu.

Druhá vrstva: tool-call protokol. Externí AI agent (nemusí to být OpenClaw, stačí jakýkoli NATS klient) může volat 19 dostupných nástrojů přímo na ESP32, bez nutnosti budit lokální LLM. Latence se podle landing page pohybuje kolem 30 milisekund. Číslo z marketingu, ale architekturou to dává smysl.

Třetí vrstva, HAL (Hardware Abstraction Layer), je nejnižší. Žádný LLM, žádný JSON. Pevně definované subjects typu {device}.hal.gpio.5.set s payloadem "1" a odpovědí "ok". Pro programy v Pythonu nebo Go, které potřebují deterministickou latenci, je tohle správná vrstva. Tight loop přes ESP32 z notebooku, žádný overhead.

A pak je tu remote_chat — tool, kterým se jeden WireClaw může ptát druhého, jako by si chatovali. Edge AI mesh s federovaným reasoningem. Trochu sci-fi, ale funkční.

Kde to narazí

Žádný projekt není bez háčků a u WireClawa stojí za to vědět o pár věcech předem.

Tu hlavní jsem už zmínil: klasický ESP32 ne. Pokud máte zásobu starších DevKitů, smůla. Buď port, nebo nákup nových C3/C6/S3 boardů.

Bezpečnost. Setup portal je captive portal bez autentizace. Web GUI po setup taky bez autentizace. Kdokoli v LAN si může změnit system prompt (čili jailbreak agenta), upravit persistent memory nebo smazat pravidla. API key sedí na flashi v plaintextu. Pro lab a hobby OK, pro produkci to chce VLAN izolaci a u Telegram bota strict spending limit na OpenRouter účtu.

Conversation history je čtyřtahový kruhový buffer plus 512 bytů persistent memory. Agent si nepamatuje hlubší kontext, jen poslední pár výměn. Pro chat o teplotě dobré, pro komplexnější dialog málo.

A poslední věc: rule loop běží "každou iterací loop()". Frekvence není v dokumentaci uvedená. Pro motorické řízení, audio nebo cokoli, kde záleží na sub-milisekundové determinističnosti, sáhněte po přímém low-level firmware. WireClaw je orchestrátor, ne real-time kontrolér.

Komu to dává smysl

WireClaw cílí na úzkou komunitu: bastlíře, kteří mají ESP32 v šuplíku a chtějí experimentovat s AI agenty bez nutnosti stavět cloudovou infrastrukturu. Pro lab automatizaci, kde Home Assistant je overkill, pro distribuovanou senzor mesh, pro vzdělávací demo.

Komunita je zatím malá. Patnáct hvězdiček, čtyři forky, žádné formální release. Záleží na jediném vývojáři. To se časem může změnit, ale dneska to ovlivňuje, jak hluboko se do toho pouštět.

Pokud máte ESP32-C6 v šuplíku a hodinu času, web flasher na wireclaw.io/flash.html udělá zbytek. Chrome nebo Edge kvůli WebSerial API, kabel, OpenRouter API key, a za pár minut si můžete přes Telegram říct prvnímu vlastnímu edge agentovi, co má sledovat.

The post WireClaw: ESP32 jako AI agent, který vám neshodí topení, když spadne internet first appeared on Hard Wired.

Jak mixed-signal SoC nechtěně vysílá kryptografická tajemství a jak to reprodukovat s HackRF za odpoledne

Sedíte v autě, zaparkovaní u továrny. Výrobní hala je dvacet metrů za zdí. Spustíte skript na laptopu, nasměrujete anténu a čekáte. Za pár hodin máte AES-128 klíč z komunikace zámkového modulu uvnitř.

Žádné hackování sítě. Žádný fyzický kontakt. Žádné stopy.

Tohle není filmový scénář - je to zdokumentovaný útok, publikovaný akademicky v roce 2018, rozšiřovaný výzkumy až do roku 2024, spustitelný na fakt běžném SDR hardware. Jmenuje se Screaming Channels a má přímou relevanci pro každý automotive modul, který na sobě nese BLE čip od Nordic Semiconductor.

Čip, který si sám zesílí vlastní únik

Mixed-signal SoC je čip, kde digitální logika a rádiový transceiver sdílejí jeden křemíkový die. Zní to jako detail z datasheetu. Ve skutečnosti je to bezpečnostní časovaná bomba.

Digitální logika při výpočtech generuje elektromagnetický šum. Na izolovaném mikrokontroléru to není velký problém - šum je slabý, slyšitelný jen z milimetrů. Ale na mixed-signal čipu se ten šum šíří do analogové části: přes sdílené napájení, substrátové vazby, kapacitní přeslech mezi bloky na die. A v analogové části je PA - výkonnostní zesilovač rádiového vysílače.

Čip si vlastní kryptografický únik zesílí a vyšle anténou do prostoru.

Giovanni Camurati a jeho kolegové z EURECOM tohle v roce 2018 pojmenovali "screaming channels" - v kontrastu ke klasickým EM side-channels, které "šeptají" z centimetrů. Tady čip doslova křičí.

Konkrétní cíl výzkumu: nRF52832 od Nordic Semiconductor. ARM Cortex-M4 na 64 MHz, integrovaný BLE/ANT transceiver na 2,4 GHz. Používaný v milionech zařízení - wearables, průmyslový IoT, smart home. A automotive.

Proč 2,464 GHz a ne 2,400 GHz

Tady je fyzika, která útok umožňuje.

CPU nRF52832 taktuje na 64 MHz. Při AES výpočtu generuje harmonické tohoto taktu - šum s komponentami na 64 MHz, 128 MHz, 192 MHz atd. Ten šum vstoupí do IQ mixeru v rádiovém řetězci, kde se amplitudově namoduluje na nosnou BT kanálu.

Výsledek: útočník neladí na 2,400 GHz (BT kanál 0), ale na 2,464 GHz:

f(screaming channel) = f(BT kanál) + f(CPU clock)
                     = 2,400 GHz  + 0,064 GHz
                     = 2,464 GHz

V spektrogramu to vypadá jako tenký proužek vedle hlavního BT signálu - vizuálně nenápadný, statisticky informativní. Každé jedno AES šifrování zanechá v zachyceném signálu "otisk" - trace. Jedna trace toho moc neřekne. Ale po 90 000 tracích jde z korelace vytáhnout celý 128bitový klíč.

Zpátky k tomu autu na parkovišti: útočník nepotřebuje dekódovat Bluetooth provoz. Jen passivně naslouchá vedlejšímu šumu. Zařízení ani netuší, že je sledováno.

Sedm let výzkumu v pěti minutách

Projekt Screaming Channels není jednorázová akademická kuriozita. Vyvíjí se.

CCS 2018 (Camurati et al., EURECOM): Původní demonstrace. Útok na tinyAES implementaci na nRF52832, vzdálenost 10 metrů v anechoické komoře, vzdálenost 1 metr v kancelářském prostředí. Korelační analýza, 180 000 traces. Tři místo na CSAW Europe 2018.

CHES 2020: Podrobnější analýza kanálu, útok na Google Eddystone beacony (reálný produkt, ne lab firmware), vzdálenost 15 metrů v kancelářské chodbě, spatial diversity s dvěma přijímači, reuse profilu postaveného na jiném zařízení měsíce předem.

ACSAC 2024 (BlueScream, Ayoub et al., EURECOM + Univ. Lille + CNRS + Inria): Útok na reálný BLE stack bez modifikace firmware. Útočník manipuluje BLE protokol tak, aby zařízení leaked Long Term Key při standardní komunikaci. Tohle je z mého pohledu nejzásadnější posun - předchozí práce vyžadovaly speciální firmware na target zařízení. BlueScream funguje na produkčním zařízení s factory firmware.

Musím ale říct, že "funguje na produkčním zařízení" je trochu zjednodušení. BlueScream stále potřebuje, aby útočník mohl ovlivnit BLE session - tedy aby byl v dosahu a mohl komunikovat. Vzdálený pasivní útok bez jakékoliv interakce to zatím není. Ale hranice se posouvají každý rok.

Mimochodem: vedle toho v roce 2025 publikovali Ji et al. ze Stockholm University útok na hardwarový AES akcelerátor (ne softwarovou implementaci) na stejném čipu, s ML-assisted analýzou a 90 000 traces z 1 metru. Hardwarový akcelerátor se dřív považoval za odolnější. Ukázalo se, že ne.

Jak to reprodukovat: hardware

Celý projekt je open-source. EURECOM zveřejnil firmware, kód, GNURadio bloky a naměřené datasety. Není potřeba nic vymýšlet od nuly.

Minimální setup pro laboratorní validaci:

PCA10040 má onboard J-Link debugger - žádný extra programátor nepotřebujete, stačí USB kabel.

HackRF zvládne útok z 1 až 3 metrů v tichém RF prostředí. Pro 10+ metrů (publikované výsledky) potřebujete USRP N210 s SBX daughterboard a paraboliku s 24 dBi - to je jiný cenový segment (~150 000 Kč za USRP). Pro automotive bezpečnostní testování v laboratoři ale 1 metr odpovídá realistickému scénáři technická diagnostiky u vozidla.

Jak to reprodukovat: software a postup

1. Instalace

sudo apt install gnuradio gr-osmosdr hackrf minicom gcc-arm-none-eabi

git clone https://github.com/eurecom-s3/screaming_channels
cd screaming_channels
git checkout ches20

cd experiments/src
python2 setup.py develop
pip3 install gatt==0.2.7 pyzmq==17.1.2

Repo obsahuje i Dockerfile pro izolované prostředí - doporučuji, závislosti jsou trochu starší:

docker build -t screaming docker/
docker run -it --privileged screaming

2. Flash firmware

cd screaming_channels/firmware

# mbedTLS varianta (doporučená pro první pokus)
make GNU_INSTALL_ROOT=$GCC_PATH/gcc-arm-none-eabi-7-2017-q4-major/bin/ \
  -C blenano2_mbedtls/blank/armgcc/

# Flashnout přes J-Link (automaticky při připojení PCA10040 přes USB)
cp blenano2_mbedtls/blank/armgcc/_build/nrf52832_xxaa.hex /media/$USER/DAPLINK/

Po flashnutí se připojte přes UART (minicom -b 115200 -D /dev/ttyACM0) a stiskněte h - uvidíte menu s dostupnými módy.

3. Vizualizace úniku - první krok

Než začnete sbírat traces, ověřte, že leak vůbec vidíte.

Naladíte HackRF na offset frekvenci:

# Přímý přístup přes hackrf_transfer (jen pro rychlý test)
hackrf_transfer -r /dev/null -f 2464000000 -s 8000000 -l 40 -g 40

Lépe otevřete GQRX nebo GNURadio Companion, nastavte:

• Frekvence: 2 464 MHz
• Sample rate: 8 MSPS
• FFT size: 4096
• Gain: začněte na 30 dB, dolaďte

Ve firmware spusťte AES smyčku: n (TinyAES mód), n2000 (2000 opakování), r (spustit). Ve spektrogramu by se měl objevit periodický proužek kolem +64 MHz offsetu od BT nosné. Když ho vidíte, jste na správné stopě.

4. Sběr traces

sc-experiment \
  --radio=HackRF \
  --device=/dev/ttyACM0 \
  collect \
  config/example_collection_plot.json \
  ../traces/ \
  --plot

--plot zobrazí live vizualizaci každé trace. Hledáte konzistentní tvar signálu korelovaný se šifrováním - pokud každá trace vypadá jinak a chaoticky, SNR je příliš nízké (zkuste zkrátit vzdálenost nebo zvýšit gain).

5. Analýza - bez vlastního hardware

Pokud chcete nejdřív ověřit celý analytický pipeline, EURECOM poskytl veřejné datasety:

• Small sample set (56 MB) - útok na 20 cm
• CCS18 traces (2,6 GB) - útok na 10 m v anechoické komoře, útok na 1 m v kanceláři
• CHES20 traces (15 GB) - vše od 55 cm doma přes 15 m v chodbě po T-test na 34 m

export TRACES_SAMPLE="/cesta/k/datum"

sc-attack \
  --norm \
  --plot \
  attack config/example_attack.json \
  $TRACES_SAMPLE/sample/

6. Dvě metody key recovery

Korelační analýza (CPA) - bez profilování, ~180 000 traces, deterministická. Dobrá pro první pokus, nevyžaduje referenční zařízení se známým klíčem.

Template attack s ML - vyžaduje profilování (traces se známým klíčem na tom samém modelu čipu), útok pak z ~90 000 traces. Přibližně dvakrát efektivnější.

# Profilování (coaxiální připojení, plný SNR, známý klíč)
sc-attack --norm \
  --data-path ./traces/profile \
  --num-traces 5000 \
  profile \
  --variable p_xor_k \
  --pois-algo r \
  --num-pois 1 \
  /tmp/profile_output/

# Útok (vzdálené traces, neznámý klíč)
sc-attack --norm \
  --data-path ./traces/attack \
  --num-traces 90000 \
  attack \
  --attack-algo pcc \
  --profile /tmp/profile_output/ \
  /tmp/attack_output/

Co s tím dělat: mitigace, která nestačí, a ta, která pomáhá

Softwarová oprava neexistuje. Problém je fyzický.

Maskovací schémata v AES implementaci (Rivain-Prouff a podobné) zvýší počet potřebných traces, ale útok neumožní - Ji et al. (2025) demonstrovali průlom i přes masking. Jitter v časování šifrování komplikuje synchronizaci traces. Žádná sláva.

Fakticky fungující opatření jsou hardwarová:

RF stínění modulu - faradayova klec kolem čipu ořízne leak na přijatelnou úroveň. Přidá ale hmotnost, rozměry a cenu.

Čipy s integrovanou ochranou - Nordic nRF54 série (nástupce nRF52) obsahuje dedikovanou side-channel leakage protection v kryptoakcelerátoru. Pokud navrhujete nový modul, tohle je relevantní volba.

Oddělit napájení - digitální a RF napájení na PCB oddělené ferritovými korálky a LC filtry sníží substrátovou vazbu, ale neodstraní ji úplně. Pomáhá SNR útoku poškodit, ale nestačí jako jediné opatření.

Pro firemní kontext: výsledky testování vlastních modulů zdokumentujte jako součást threat modelu a bezpečnostní dokumentace. Pokud modul projde CPA testem bez key recovery do 200 000 traces v laboratorních podmínkách, máte datový podklad pro rozhodování.

Zdroje

Akademické práce (primární zdroje):

• Camurati et al. (CCS 2018): Screaming Channels: When EM Side Channels Meet Radio Transceivers
• Camurati et al. (CHES 2020): Understanding Screaming Channels
• Ayoub et al. (ACSAC 2024): BlueScream: Screaming Channels on Bluetooth Low Energy
• Ji, Dubrova, Wang (IACR ePrint 2025): Is Your Bluetooth Chip Leaking Secrets via RF Signals?

Kód a datasety:

• github.com/eurecom-s3/screaming_channels - firmware, experimenty, datasety, Docker
• github.com/pierreay/bluescream - BlueScream (reálný BLE stack, ACSAC 2024)
• eurecom-s3.github.io/screaming_channels - dokumentace, download datasety

Prezentace:

• Black Hat USA 2018 - video
• CHES 2020 - video

Testování technik popsaných v tomto článku proveďte výhradně na vlastním hardware nebo s písemným souhlasem vlastníka zařízení. Útoky na cizí zařízení jsou trestné.

The post Váš Bluetooth čip křičí šifrovací klíče. Slyšet ho jde z parkoviště. first appeared on Hard Wired.

O čem je řeč

V únoru 2026 tým Samsung Research (Hyochan Chong, Dongkyu Kim, Changdong Kim, Minseop Choi) publikoval paper popisující NanoQuant — metodu post-training kvantizace (PTQ), která dokáže komprimovat váhy velkých jazykových modelů na 1 bit a méně. Ne jako marketingový trik s hvězdičkou a poznámkou pod čarou, ale jako funkční framework s měřitelnými výsledky na standardních benchmarcích.

Proč je to zajímavé: dosavadní PTQ metody (GPTQ, AWQ, QuIP, AQLM) fungují spolehlivě na 3–4 bitech na váhu. Pod touto hranicí se rozpadají. Kdo chtěl jít níže, musel sáhnout po QAT (quantization-aware training) metodách jako LittleBit nebo DBF, které ale vyžadují výrazně víc dat, výpočetního času a často i přístup k trénovacímu pipeline modelu. NanoQuant tuhle mezeru překlenuje — dosahuje komprese srovnatelné s QAT, ale s efektivitou a jednoduchostí PTQ.

NanoQuant jednoduše: 70B model na herní grafice

Co je sub-1-bit kvantizace a proč na tom záleží

Představ si, že máš knihu, která má 138 000 stránek. Je v ní všechno — umí odpovídat na otázky, překládat, psát texty. Problém je, že potřebuješ obrovskou knihovnu, aby se ti tam vešla. Normální člověk si ji domů nedá.

Kvantizace je v podstatě způsob, jak tu knihu přepsat menším písmem. Místo toho, aby každé číslo v modelu (a těch jsou miliardy) zabíralo 16 pozic přesnosti, řeknete — stačí mi 4. Nebo 2. Model je pak menší, ale pořád rozumně funguje. Tohle se dělá běžně a funguje to dobře až do určité hranice.

NanoQuant jde dál. Řekne — stačí mi méně než jedna pozice na číslo. To zní absurdně, protože jedna pozice znamená jen dvě možnosti: plus nebo minus. Méně než jedna pozice by znamenalo, že ani to plus/minus nemáte pro každé číslo zvlášť.

Jak to udělají? Místo toho, aby každé číslo komprimovali samostatně, vezmou celou tabulku čísel a rozloží ji na několik menších tabulek, kde jsou jen jedničky a minus jedničky. Ty menší tabulky se pak vynásobí a dají dohromady přibližně totéž co originál. A protože ty menší tabulky jsou menší než originál, průměrně vychází méně než jeden bit na původní číslo.

Výsledek: model, který normálně zabírá 138 GB a potřebuje dvě profesionální grafické karty za statisíce, se smrskne na 5,35 GB a běží na běžné herní grafice za pár tisíc. A pořád dává rozumné odpovědi.

Háček je v tom, že tohle zatím existuje jen jako vědecký článek. Kód není veřejný, nemůžete si to stáhnout a zkusit. Ale ukazuje to směr — modely, které dnes potřebují serverovnu, by za rok nebo dva mohly běžet na normálním počítači nebo i na telefonu.

Zdroj: NanoQuant — arxiv.org/abs/2602.06694

Problém: proč je sub-1-bit komprese těžká

Standardní kvantizace funguje tak, že se každá váha zaokrouhlí na nejbližší hodnotu z omezeného počtu úrovní. Při 4 bitech máte 16 úrovní, při 2 bitech 4 úrovně. Při 1 bitu máte dvě: +1 a −1. To je brutální ztráta informace.

Existující PTQ metody na tomhle selhávají ze dvou důvodů:

1. Nemají dostatečně sofistikovaný způsob, jak rozhodnout, která váha bude +1 a která −1, aby výsledný model stále dával smysl.
2. Některé metody technicky tvrdí, že komprimují na 1 bit, ale pak si "berou zpět" paměť přes pomocné struktury — škálovací faktory, lookup tabulky, metadata — takže skutečný paměťový otisk je výrazně vyšší.

QAT metody tenhle problém řeší přetrénováním modelu s kvantizačním šumem jako součástí tréninkového procesu. Funguje to, ale vyžaduje to stovky tisíc až miliony kalibračních tokenů, desítky GPU hodin a přístup k tréninkovému pipeline.

Jak NanoQuant funguje

NanoQuant reformuluje celý problém kvantizace. Místo zaokrouhlování jednotlivých vah na binární hodnoty rozkládá váhovou matici na součin nízko-rankových binárních matic a škálovacích faktorů. Matematicky: matice vah W se aproximuje jako součin binárních matic (obsahujících pouze +1 a −1) a diagonálních škálovacích vektorů.

Pokud má původní matice rozměr m×n a rank rozkladu je r, potřebujete r×(m+n) binárních hodnot plus škálovací parametry. Při dostatečně nízkém r klesne průměrný počet bitů na váhu pod 1.0.

Tříkrokový pipeline

Komprese probíhá po blocích modelu (transformer block po bloku) ve třech krocích:

Krok 1 — Mitigace propagace chyb. Kvantizační chyba se akumuluje, jak rekonstrukce postupuje sítí. Před kvantizací aktuálního bloku se jeho full-precision váhy doladí tak, aby kompenzovaly chyby zavedené kvantizací předchozích bloků. Tohle není nový nápad — podobný přístup používají i AQLM nebo QuIP — ale NanoQuant ho aplikuje na všechny lineární vrstvy v bloku, ne jen na vybrané.

Krok 2 — Inicializace binární faktorizace (LB-ADMM). Tady je jádro celé metody. NanoQuant používá ADMM (Alternating Direction Method of Multipliers) pro řešení kombinatorického problému: jaká kombinace binárních matic a škálovacích faktorů nejlépe aproximuje původní váhy? ADMM iterativně střídá řešení dvou podproblémů — optimalizaci spojitých škálovacích parametrů (uzavřená forma, least-squares) a projekci na binární omezení (sign operace). Celý postup je "Hessian-aware", tedy bere v úvahu citlivost výstupu na jednotlivé váhy.

Autoři experimentálně ukázali, že LB-ADMM inicializace překonává inicializační schémata z LittleBit i DBF. Jejich hypotéza: vyřešit kombinatorický problém binární faktorizace před fine-tuningem poskytuje stabilnější optimalizační krajinu než přístupy, které inicializaci řeší přibližně a spoléhají na to, že ji gradientová optimalizace dotáhne.

Po ADMM následuje magnitude balancing — vyrovnání škálovacích faktorů, aby binární matice měly vyvážený rozsah.

Krok 3 — Zpřesnění faktorizovaných komponent. Po inicializaci se binární matice a škálovací faktory dolaďují pomocí Straight-Through Estimatorů (STE). STE je standardní trik pro gradientovou optimalizaci přes diskrétní operace — při zpětném průchodu se gradient sign funkce nahradí identitou. Toto zpřesnění probíhá lokálně na úrovni bloku, ne globálně.

Na závěr celého procesu přichází model-level rekonstrukce: lehká kalibrace škálovacích faktorů přes celý model pro lepší globální zarovnání aktivací.

Co znamená "sub-1-bit"

Pojem sub-1-bit může znít jako protimluv — jak můžete mít méně než jeden bit informace na váhu? Odpověď je v tom, že nízko-rankový rozklad sdílí informaci mezi váhami. Binární matice v rozkladu jsou menší než původní váhová matice, takže celkový průměrný počet bitů na váhu (bits per weight, BPW) klesne pod 1.0.

NanoQuant demonstroval výsledky na 0.8 BPW, tedy méně než jeden bit na váhu v průměru. Při tomhle kompresním poměru samozřejmě dochází k degradaci kvality — ale ta je měřitelná a v kontextu 70B modelů stále překvapivě nízká.

Čísla

Tady to přestává být akademické cvičení a začíná to být prakticky relevantní:

• Llama2-70B: komprese ze 138,04 GB na 5,35 GB — kompresní poměr 25,8×
• Inference: kvantizovaný 70B model běží na spotřebitelské 8GB GPU rychlostí až 20,11 tokenů/s
• Kalibrace: 128 vzorků (~0,26M tokenů), 1 GPU
• Čas komprese: ~13 hodin na jednom H100 pro Llama2-70B
• CUDA kernely: autoři implementovali vlastní binární GEMV/GEMM kernely optimalizované pro datacenter, spotřebitelské i edge GPU

Pro srovnání: Llama2-70B v FP16 vyžaduje minimálně 140 GB VRAM, tedy dvě A100 80GB. NanoQuant ho nacpe na jednu RTX 4060 s 8 GB.

Autoři testovali na rodinách modelů Llama2, Llama3, Qwen3 a dalších. Napříč modely NanoQuant vytváří novou Pareto frontu v prostoru komprese vs. kvalita — tedy pro danou úroveň komprese dosahuje lepší kvality než kterákoliv jiná PTQ metoda.

Kontext: co existuje kolem

NanoQuant není v izolaci. Celá oblast sub-1-bit kvantizace LLM se v posledním roce výrazně zahustila:

LittleBit (Samsung Research / NeurIPS 2025) — QAT metoda, která jde až na 0.1 BPW. Používá SVD-inspirovanou latentní faktorizaci s multi-scale kompenzací. Dosahuje skvělých výsledků, ale vyžaduje přetrénování.

DBF / Double Binary Factorization (Boža & Macko, 2025) — Rozkládá váhové matice na součin dvou binárních matic s diagonálním škálováním. Inference je efektivní (jen sčítání místo násobení), ale škálovací parametry jsou příliš omezené — všechny rankové komponenty sdílejí stejný magnitudový profil.

MDBF / Multi-Envelope DBF (prosinec 2025) — Rozšíření DBF, které nahrazuje jednoduché škálování rank-l obálkou. Zlepšuje perplexitu i zero-shot přesnost oproti DBF při stejném BPW.

BTC-LLM (květen 2025) — Používá naučitelné transformace a binární codebooky místo přímé binarizace.

HBLLM — Waveletová dekompozice pro vylepšenou 1-bit kvantizaci s frekvence-aware seskupováním.

NanoQuant se od těchto metod odlišuje tím, že je čistě PTQ — nepotřebuje přetrénování — a přesto dosahuje konkurenceschopné kvality. To je prakticky zásadní rozdíl, protože PTQ můžete aplikovat na libovolný model bez přístupu k trénovacím datům nebo pipeline.

Současný stav projektu

Na rovinu: k dnešnímu dni (duben 2026) je NanoQuant čerstvý research paper bez veřejně dostupného kódu.

• Paper: publikován 6. února 2026 na arXiv, necelé dva měsíce starý
• Kód: zatím nevydaný. Autor na Hugging Face napsal: "We are working on open-sourcing the code, so please stay tuned!"
• Kvantizované modely / checkpointy: nejsou k dispozici. Na otázku po checkpointech autor zatím neodpověděl.
• Vlastní CUDA kernely: zmíněny v paperu, ale rovněž nejsou veřejné

Jde o výzkum Samsung Research, takže open-source release může trvat déle kvůli interním schvalovacím procesům. Autor Hyochan Chong se v únoru 2025 vrátil do Samsung Research po dokončení studia a NanoQuant je jeden ze dvou paperů, které publikoval v únoru 2026 (druhý je RaBiT — 2-bit QAT metoda).

Co to znamená pro praxi

Než se kód uvolní, NanoQuant zůstává akademický výsledek. Ale i jako takový naznačuje směr:

Pro edge nasazení: Pokud se sub-1-bit formáty dostanou do mainstreamových inference frameworků (llama.cpp, vLLM, TensorRT-LLM), otevírá se možnost provozovat modely třídy 70B na hardware, kde dnes sotva běží 7B. To je relevantní pro kohokoliv, kdo provozuje lokální LLM inference na omezeném hardware — Raspberry Pi, jednočipové GPU, mobilní zařízení.

Pro GGUF ekosystém: Zatím žádná podpora. NanoQuant vyžaduje vlastní binární CUDA kernely, takže integrace do llama.cpp by znamenala portovat tyhle kernely na CPU/Metal/Vulkan backendy. To není triviální, ale komunita kolem llama.cpp už v minulosti portovala i složitější formáty.

Pro kvalitu vs. komprese trade-off: NanoQuant ukazuje, že Pareto fronta se posouvá. Před rokem byl sub-1-bit režim terra incognita pro PTQ. Teď máme měřitelné výsledky, které říkají, že 70B model komprimovaný na 5,35 GB stále dává rozumné výstupy. To mění kalkulaci pro deployment.

Stojí za to sledovat autorův profil a Samsung Research na Hugging Face. Jakmile se kód uvolní, bude to jeden z nejzajímavějších frameworků k otestování.

Reference a zdroje

• NanoQuant paper (arXiv): arxiv.org/abs/2602.06694
• Hugging Face paper page: huggingface.co/papers/2602.06694
• Samsung Research na Hugging Face: huggingface.co/SamsungResearch
• Profil autora (Hyochan Chong): d7chong.github.io
• Blog-style summary (alphaXiv): alphaxiv.org/overview/2602.06694v1
• LittleBit (Samsung Research): research.samsung.com/blog/LittleBit-Ultra-Low-Bit-Quantization-via-Latent-Factorization
• DBF — Double Binary Factorization: arxiv.org/abs/2505.11076
• MDBF — Multi-Envelope DBF: arxiv.org/abs/2512.24545
• BTC-LLM: arxiv.org/abs/2506.12040
• RaBiT (další paper od stejného autora): huggingface.co/papers — RaBiT: Residual-Aware Binarization Training

Dokument vytvořen: Duben 2026

The post NanoQuant: Post-training kvantizace LLM pod hranici jednoho bitu first appeared on Hard Wired.

Phreaking: Vzpomínky ze zlaté éry analogových linek

Autor: 3qeX - Hesse Valentino

Jsou věci, co se prostě nevytratí. Ani po dvaceti letech. Vůně maziva z rozvaděče telefonní budky. Chlad kovu na šlicu. A ten moment, když po spojení žárovky s linkovými svorkami uslyšíš v improvizovaném sluchátku čistý oznamovací tón SPT Telecom.

Byl jsem phreaker. Tehdy jsem o tom věděl kulový - pár triků z pochybných webů s černým pozadím a bílým textem. Přesto to bylo dobrodružství, jaké dnešní generace asi nikdy nezažije.

Tohle není návod. Je to vzpomínka. Popis historických technik z doby, kdy analogová telefonní síť ještě žila a kdy výzvou bylo přelstít obří státní kolos jménem SPT Telecom.

Co je phreaking a kde se vzal

Phreaking je manipulace s telefonními sítěmi - zneužívání technických vlastností analogové infrastruktury za účelem bezplatného volání, odposlechu nebo průzkumu skrytých funkcí ústředen. Termín vznikl v USA někdy kolem roku 1957 a jeho kořeny jsou propojeny s postavami, které se staly legendami hackerské kultury.

První slavný phreaker byl Joe Engressia, přezdívaný Joybubbles - nevidomý kluk se schopností dokonalé výšky sluchu. Zjistil, že když zapíská tón 2600 Hz do telefonního sluchátka, resetuje dálkové linkové spoje. Na tohle navázal John Draper - Captain Crunch - který přišel na to, že plastová píšťalka z cornflakes kapsy generuje přesně ten tón. Dálkové volání zdarma kamkoliv po světě bylo najednou možné za cenu cereálií. Absurdní, ale fungovalo to.

Z toho se zrodily legendární "barevné krabičky" - phreakerské přístroje pojmenované podle barev. Systém zavedli američtí phreakeři v 60. a 70. letech. Barvy sloužily jako kódové označení funkce v textových souborech šířených tajně na disketách a přes BBS sítě. Jména jako Steve Wozniak nebo Steve Jobs se v phreakerském undergroundu pohybovala dávno před tím, než spoluzaložili Apple.

Česká scéna: SPT Telecom a divoké devadesátky

Do Česka phreaking přišel s jistým zpožděním, ale o to živěji. V 90. letech procházela naše telefonní síť schizofrenním stavem - část byla moderní digitální, ale obrovská část, zejména na menších městech a vesnicích, jela na starých analogových systémech Křemíková.

SPT Telecom vlastnil prakticky veškerou infrastrukturu a jeho ceny byly podle tehdejších standardů astronomické. Minuta hovoru do zahraničí stála majlant. Minuty na tehdy čerstvě spuštěné mobilní sítě NMT nebo GSM byly pro kluka ze základní školy naprosto nedostupné.

To byl živný půdorys pro phreaking. Fascinace systémem nebyla jen touha volat zadarmo - byl to pocit, že víte o síti něco, co by neměl vědět nikdo mimo telefonní techniky. Klíč k systému.

Za průkopníka české phreakerské scény se v undergroundu považoval "Subber", který kolem roku 2006 provozoval weby věnované problematice. Ještě dříve, na přelomu milénia, kolovala jména jako "Flash" nebo "Morpheus", kteří psali dlouhé manuály - tzv. Guides - formátem naprosto typickým pro dobu: bílý text na černém pozadí, spousta ASCII artu, žádné obrázky.

Zmínit se musí i Zdeněk Adamec, vystupující online pod nickem Satan nebo Satanic. Jeho webové stránky na tehdejším freehostingu byly rozcestníkem pro zájemce o "zakázané vědomosti" - ale jeho těžiště leželo primárně v darkingu, ne v phreakingu. O phreakingu publikoval jen několik málo článků, většinou překlady zahraničních manuálů.

Komunita se sdružovala v různě pojmenovaných skupinách - v undergroundu tehdy figurovala CIA (Czech Illegal Alliance) vedená Kill3rem a Subberem, ale i skupiny navázané na darkerskou scénu jako Darkers Group nebo RJ-11 Security Alliance. SOOM.cz pak od roku 2003 fungoval jako hlavní česky psaný portál věnující se bezpečnosti a phreakingu, a jeho fórum z roku 2005 je dnes historickým dokumentem živé komunity.

Boxy: barevná abeceda phreakingu

Ústředním nástrojem světového phreakingu byly tzv. boxy - malá elektronická zařízení pojmenovaná podle barev. V Česku se většina z nich přizpůsobovala místní síti, nebo zůstávala spíše teorií. Přesto stojí za to si je projít.

Blue Box (modrá krabička)

Nejslavnější phreakerský nástroj vůbec. Generoval tón 2600 Hz, který v americké síti Ma Bell signalizoval volnou dálkovou linku. Po vyslání tohoto tónu do sluchátka mohl phreaker linku "shodit" a pomocí dalších MF tónů řídit přepojení kamkoliv na světě - zdarma.

V Česku fungovalo modré krabičce analogicky na starých tranzitních ústřednách, zejména u mezinárodních hovorů. Vytočilo se bezplatné číslo (linka poruch, operátora), vysílal se tón - a otevřenou linku šlo dále řídit. Se začátkem digitalizace ústředen na systémech EWSD a S12 přestala tato technika fungovat definitivně.

Red Box (červená krabička)

Zatímco modrá krabička útočila na dálkové linky, červená mířila na mincovní automaty. Telefonní automat komunikoval s ústřednou sériemi tónů signalizujících vhozené mince - každá nominální hodnota mince měla svou frekvenční signaturu. Červená krabička tyto tóny emulovala.

V praxi stačilo přiložit malý reproduktor ke sluchátku a přehrát nahrávku odpovídajících tónů. Ústředna si myslela, že automat přijal mince, a hovor povolila. SPT Telecom tento problém řešil filtrací - signály z mincovníku přestaly být přenášeny přes sluchátkový okruh a šly přímou servisní linkou.

Black Box (černá krabička)

Černá krabička se instalovala u příjemce hovoru, ne u volajícího. Fungovala na principu manipulace s napětím na lince.

Analogové ústředny detekovaly zvednuté sluchátko poklesem napětí na lince: v klidu bylo napětí zhruba -48 V, po zvednutí sluchátka kleslo pod -10 V - to byl signál pro zahájení účtování. Černá krabička vkládala do série s linkou rezistor nebo Zenerovu diodu tak, aby napětí nekleslo pod práh účtování (udržovalo se kolem -36 V). Zvonění se zastavilo, hovor byl navázán, ale ústředna ho nevyhodnotila jako přijatý - volající neplatil nic.

Tato technika fungovala výhradně na ústřednách řízených mechanickými relé. V Česku a ve střední Evropě obecně černé krabičky přežívaly až hluboko do 90. let díky pomalejší digitalizaci sítě.

Beige Box (béžová krabička) - servisní sluchátko

Toto byl v českém undergroundu prakticky nejpoužívanější nástroj a ten, se kterým jsem měl osobní zkušenost. Beige box je v podstatě to, co telefonní technici nazývají lineman's handset - servisní sluchátko s krokosvorkami.

Konstrukce byla prostá: starý telefon (ideálně vykuchaný fax), dva krokodýlci připojeni na červený a zelený vodič. Někdy se přidával přepínač mikrofonu pro tichý odposlech. Výsledkem byl přístroj za cenu šrotu, který vám umožnil připojit se přímo na svorkovnici telefonní linky kdekoliv v rozvaděči - bez ohledu na to, co na lince viselo za přístroj.

Výhoda sluchátka z faxu oproti běžnému telefonu: faxy měly v sobě kompletní elektroniku pro vytáčení a přepínač mezi pulzní (analogovou) a tónovou (DTMF) volbou, což bylo v devadesátkách klíčové - mnoho přístrojů ještě umělo jen pulzní volbu, ale ústředny nebo bankovní automaty vyžadovaly DTMF.

Mauve Box (fialová krabička) - hudba do linky

Méně známý, ale technicky zajímavý byl tzv. mauve box. Sloužil k přimíchání externího audio signálu - hudby nebo jiného zvuku - do probíhajícího hovoru. Zapojoval se do série s linkou a obsahoval oddělovací transformátor zabraňující poškození elektroniky.

Praktické využití v českém undergroundu bylo dvojí: vytváření primitivních konferenčních hovorů přes propojení kazeťáku s linkou, nebo pouštění hudby do sluchátka volané osoby. Zvláštní využití spočívalo v maskování prostředí - přehrávání nahrávky hluku ulice mělo zakrýt, že voláte z místa, ze kterého volat nemáte.

Žárovka a šlic: technika z telefonní budky

Tohle byl trik, který mi nedal spát. Přečetl jsem o něm kdesi na webu a nedalo mi to, dokud jsem ho nevyzkoušel.

Spodní část telefonní budky SPT Telecom - tzv. šlic nebo rozvaděč - obsahovala svorkovnici, na které končily linkové vodiče budky ještě před samotným mincovním automatem.

Telefonní linka v klidu nesla stejnosměrné napětí přibližně 48 V. Ve chvíli, kdy ústředna zaregistrovala pokles napětí způsobený zdvižením sluchátka (off-hook stav), otevřela linku a poslala oznamovací tón. Mincovní automat přitom ale měl vlastní elektroniku, která řídila účtování - čekala na vhození karty nebo mince, teprve pak povolila vytáčení.

Trik spočíval v připojení žárovky na 24 V přímo na svorky a a b linky v rozvaděči. Proč zrovna 24V žárovka? Žhavicí vlákno takové žárovky má při provozu odpor přizpůsobený napájení 24 V - při 48 V na telefonní lince jím protéká proud, který způsobí pokles napětí do rozmezí přibližně 20-30 V. Tento pokles byl pro starší analogové ústředny dostačující k detekci off-hook stavu, takže ústředna linku otevřela a zaslala oznamovací tón.

Klíčový detail: automat zůstával fyzicky zavěšen. Jeho vlastní elektronika vůbec nevěděla, že na lince cosi probíhá. Žárovka simulovala zátěž "pro ústřednu" - ale mincovní mechanismus zůstával zcela mimo hru.

Žárovka navíc poskytovala velmi praktickou vizuální zpětnou vazbu: ve chvíli, kdy se linka správně otevřela, začala mírně svítit. To byl váš signál připojit beige box - servisní sluchátko s krokosvorkami - přímo ke svorkám vedle žárovky. Oznamovací tón v sluchátku potvrdil, že máte přístup k lince a můžete vytáčet libovolné číslo. Volal jste přímo přes ústřednu SPT Telecom - na účet té konkrétní linky budky.

Tato technika zanikla s přechodem ústředen na digitální přepínaní (EWSD, S12). Digitální ústředny nestačí oklamat pouhým poklesem napětí - aktivně monitorují stav linky a rozlišují typ připojeného zařízení. Navíc fyzická ochrana šliců se v pozdějších 90. letech výrazně zlepšila.

DTMF dialery a další triky

Paralelně s hardwarovými boxy existovaly i jednodušší, ale neméně užitečné nástroje.

DTMF dialer - malý kapesní přístroj s klávesnicí - byl původně legální pomůcka pro dálkové ovládání záznamníků. Phreakeři ho přeložili ke sluchátku a pomocí tónové volby ovládali hlasová menu ústředen nebo systémy, které vyžadovaly DTMF, ale dostupný telefon uměl jen pulzní volbu.

Telefonní karty SPT Telecom přinesly vlastní podmnožinu phreakingu. Čipové karty byly terčem pokusů o obejití zápisového kontaktu - fyzickým naříznutím nebo přelepením určitého kontaktu na čipu se znemožnil zápis spotřeby, zatímco čtení jednotek fungovalo normálně. Pokročilejší varianta: mikrokontrolerové emulátory na bázi PIC čipů, schopné simulovat chování originální karty s neomezeným kreditem.

Přesměrování přes firemní ústředny (PBX hacking) bylo kapitolou pro sebe. Špatně zabezpečené firemní ústředny - zejména ty staršího data - umožňovaly přístup z veřejné linky přes servisní tónové příkazy. Phreaker se "vloupat" do ústředny a skrze ni volat na libovolné zahraniční číslo - na účet dané firmy.

Darking: ryze česká odnož

Phreaking v České republice nelze vyprávět bez zmínky o darkingu - fenoménu, který je ryze českou specialitou a v okolních zemích prakticky neexistoval.

Darking vznikl kolem roku 2001 v prostředí, kde se phreaking prolínal s průzkumem technické infrastruktury. Darkeři se zaměřovali na rozvaděče elektrického vedení, vypínání veřejného osvětlení, průzkum podzemních prostor a obecně na technický vandalismus v hraničních zónách zákona. Výraznou postavou byl Zdeněk Adamec (online alias Satan), jehož web byl komunitním rozcestníkem.

Darkerská komunita se sdružovala ve skupinách jako Darkers Group No. 1 (s buňkami v Ústí nad Labem a Kutné Hoře) nebo RJ-11 Security Alliance. Adamcova tragická smrt v březnu 2003 - sebevražda upálením u Národního muzea jako protest proti stavu světa - symbolicky uzavřela nejintenzivnější kapitolu tohoto hnutí.

Zánik scény a právní aspekty

Konec tradičního phreakingu přišel ze dvou stran najednou.

Za prvé: technologie. Digitalizace ústředen na systémech EWSD a S12 postupně eliminovala techniky závislé na analogovém chování linek. Čipové telefonní karty s kryptografickým zabezpečením nahradily starší zranitelné typy. Mobilní telefony s předplacenými kartami (Twist, Go, Oskarta) udělaly z hledání funkčních budek naprostou zbytečnost - proč trávit hodinu u rozvaděče, když máte předplacenou kartu za stokorunu?

Za druhé: legislativa. Phreaking je v České republice trestná činnost. Podle §230 trestního zákoníku se jedná o neoprávněný přístup k počítačovému systému a nosiči informací, v širším smyslu pak pod porušení tajemství dopravovaných zpráv (§182). Přesto je zajímavé, že dle dostupných informací nebyl v ČR nikdo za phreaking formálně odsouzen - scéna byla příliš malá (Subber odhadoval počet aktivních phreakerů na cca 50), příliš rozptýlená a způsobené škody nikdy nedosáhly astronomických čísel.

Závěr: klíč, který přestal pasovat

Pamatuji si ten pocit. Stát u telefonní budky, v kapse mít sluchátko vyrobené ze starého faxu, v druhé ruce žárovku s dvěma vodiči zakončenými krokosvorkami. Celá situace vypadala absurdně - a přece fungovala.

Fascinace phreakingem nikdy nebyla jen o bezplatném volání. Byl to průzkum systému, touha pochopit, jak věci skutečně fungují pod povrchem toho, co běžný uživatel vůbec nevidí. Telefonní síť tehdy působila jako černá skříňka - a přijít na to, jak se dovnitř podívat, byl svým způsobem malý triumf.

Dnes ta síť neexistuje. Měděné páry v zemi stále jsou, ale hovory dávno cestují jako datové pakety přes optiku a internet. Žárovka na 24 V by v šlicu moderní budky způsobila leda poplach v monitorovacím centru operátora. SPT Telecom se proměnil v O2, budky z ulic prostě zmizely.

Zůstávají jen vzpomínky. A možná tenhle článek.

— 3qeX

Poznámka: Tento článek popisuje historické techniky z dob analogové telefonní sítě. Phreaking je v České republice nelegální činnost dle §230 a §182 trestního zákoníku. Veškeré popisované techniky jsou dnes nefunkční nebo obtížně aplikovatelné na moderní digitální infrastrukturu.

The post Phreaking: Vzpomínky ze zlaté éry analogových linek first appeared on Hard Wired.

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.