Článek
V listopadu 2024 přidal Elasticsearch ve verzi 8.16 funkci s nenápadnou zkratkou BBQ, Better Binary Quantization. Dělá jedinou věc: každé číslo v uloženém vektoru zmenší z dvaatřiceti bitů na jeden, takže paměť, kterou prohledávané vektory zabírají, klesne zhruba na dvaatřicetinu. Původní vektory zůstávají na disku a po hrubém binárním hledání se kandidáti přeřadí podle plné přesnosti. Na milionu 1024rozměrných embeddingů Cohere si takový index drží přes 90 % recall@100 - stačí k tomu trojnásobný oversampling, který je ostatně dnes výchozím nastavením. Na první pohled to vypadá jako podvod na informační teorii.
Není. Je to opravný účetní doklad. Ukazuje, že float32 embedding, tak jak ho většina z nás bez přemýšlení ukládá, je z velké části prázdné místo. A platíme ho diskem i operační pamětí pokaždé, když provozujeme sémantické hledání nebo RAG nad stamiliony dokumentů.
Tvrdím, že u ukládání embeddingů se vyplatí snižovat přesnost čísla, ne počet dimenzí. A že Matryoshka, po které řada týmů sáhne jako po první možnosti, řeší jiný problém, než si myslí. Abych to obhájil, musím nejdřív odpovědět na otázku, kterou si skoro nikdo neklade: kolik užitečné informace vlastně jedno číslo v embeddingu nese?
Odpověď se dá odečíst z toho, co přežije kvantizaci. Snížení na int8, tedy na 256 úrovní místo plné plovoucí čárky, vychází v průmyslových benchmarcích i nezávislých měřeních téměř bezztrátově; studie z listopadu 2025 na retrieval benchmarku BEIR SciFact naměřila u int8 čtyřnásobnou úsporu za pokles nDCG@10 o jedno až dvě procenta - a to na malém, 384rozměrném modelu. Kvalita přitom drží i hlouběji: rozsáhlejší srovnání ukazují, že u většiny modelů obstojí int4 či int2 a v mnoha nasazeních dokonce jediný bit na dimenzi. Když se signál nezhroutí ani po zaokrouhlení na osmi, čtyřech, místy na jednom bitu, znamená to, že šestnáct bitů float16 nebo dvaatřicet u float32 nese sotva dvě platné číslice; zbytek mantisy je v kosinové podobnosti šum, který se rozpustí v součtu přes stovky souřadnic. Uložený embedding tedy z velké části není informace. Je to místo navíc, které jsme si zvykli považovat za samozřejmé.
Jakmile člověk přijme, že zmenšit vektor znamená odebrat bity, které nic nenesou, vyjdou najevo dvě páky, ne jedna. První snižuje přesnost každé dimenze - to je kvantizace. Druhá snižuje počet dimenzí a přesnost nechává - to dělá Matryoshka Representation Learning, model natrénovaný tak, aby prvních 256 nebo 512 souřadnic embeddingu bylo samo o sobě použitelným vektorem, který lze uříznout a dál nepočítat. Obě páky dělají v jádru totéž, liší se jen osou. A tady se rozhoduje.
Kde ta osa má být, závisí na tom, kam model svůj signál uložil. Model trénovaný nativně, bez matrjoškovského omezení, rozprostírá informaci zhruba rovnoměrně přes všechny dimenze; jeho spektrum singulárních hodnot je ploché a každá souřadnice nese svůj díl. Matryoshka dělá pravý opak: trénink ji nutí nahustit co nejvíc dopředu, aby uříznutí ocasu bolelo co nejmíň. Její spektrum je proto strmé, přední dimenze přetížené, zadní skoro prázdné. Pro nativní vektor je přirozená komprese kvantizace - zbytečné bity sedí v přesnosti, ne v počtu os, takže zkracování by mu bralo skutečnou informaci. Pro matrjošku je to obráceně.
Právě u nativního modelu funguje jednobitová kvantizace nečekaně dobře a existuje k tomu tvrdá teorie. Metoda RaBitQ, kterou v roce 2024 publikovali Jianyang Gao a Cheng Long z NTU v Singapuru a z níž Elastic své BBQ odvodil, kvantizuje D-rozměrný vektor do D bitů a poskytuje nestranný odhad podobnosti s ostrou mezí chyby; ta chyba klesá nepřímo úměrně odmocnině dimenze. Čím víc informativních souřadnic signál má, tím spolehlivěji se jednobitový šum vyprůměruje. Vysoká dimenze kvantizaci nepřekáží, ona jí pomáhá. Totéž z druhé strany: jakmile spadneme pod zhruba 384 dimenzí, binární kvantizace se láme - zmíněná studie ze SciFactu ji na svých krátkých vektorech označuje za nepoužitelnou a opatrnost pod touto hranicí připouští i dokumentace Elasticu. Malá dimenze škodí i kvantizaci.
Matryoshka není úspora, je to pružnost
Tady se dostáváme k záměně, kvůli které jsem tenhle text napsal. Matryoshka se prodává jako komprese: natrénuješ jednou, uřízneš na 256 dimenzí, index je menší. Jenže sama možnost uříznout je přiznání, že zadní dimenze skoro nic nenesou. Nač mít tisíc souřadnic, když tři čtvrtiny z nich lze zahodit a skoro nic se nestane? Ta zahoditelnost není ctnost. Je to saturace zabudovaná do modelu už při tréninku - jemné rozlišení, které by u nativního modelu leželo v ocasu spektra, matrjoškový trénink prostě obětoval.
Odtud plyne i vyvrácení nejčastější námitky, kterou proti tomuhle uvažování slyším: že strmé spektrum je ke kvantizaci odolnější, protože informace sedí ve velkých, robustních komponentách, zatímco plochý nativní vektor ji má i v malých hodnotách, které utopí kvantizační šum. Ta úvaha zní dobře a v jednom kontextu i platí - jenže je to kontext tréninku jazykových modelů na nízké přesnosti. Práce, která pro embeddingové vrstvy GPT-2 a TinyLlama formalizuje, jak kvantizační šum utíná drobné složky spektra, o vektorovém hledání ani o Matryoshce nemluví; přenášet její závěr na ukládání retrieval vektorů je záměna domény. A i kdyby platil: „přežije to líp“ tu znamená jen „už nemá co ztratit“. Matryoshka svou odolnost koupila předem tím, že nuanci zahodila při tréninku. To není kvalita, to je ztráta v převleku za robustnost.
Nechci Matryoshku odepsat, to by byl slaměný panák. Řeší reálný problém, který kvantizace neumí: pružnost dimenze za běhu. Jeden nasazený model, ze kterého si podle rozpočtu vezmete 256 souřadnic, nebo celých 1024, aniž byste přepočítávali korpus - to je legitimní a užitečné. Google loni ukázal, že matrjoškovský princip jde u vah modelů přenést dokonce na samotné bity: celočíselné typy mají vnořenou strukturu, int4 sedí v horních bitech int8, a jeden natrénovaný model pak obsloužíte na několika přesnostech najednou. Jenže tohle všechno je flexibilita nasazení, ne komprese indexu. Kdo po Matryoshce sahá kvůli úložišti, vzal nástroj na jiný problém - a rozsáhlé srovnání CoRECT z Univerzity v Pasově z konce roku 2025 mu to vyčíslí: při stejném kompresním poměru poráží kvantizace prosté zkrácení i u matrjoškovsky trénovaných modelů. Jediné, co si z matrjošky při ukládání vzít lze, je mírný ořez jako doplněk - u tří ze čtyř testovaných modelů vyšla nejlépe kombinace mírného zkrácení s kvantizací, nikoli zkrácení samotné.
V praxi z toho plyne pořadí, které jde proti intuici mnoha týmů. Nechte dimenzi na pokoji a jděte po přesnosti. int8 je rozumný default, u velkých modelů skoro bez ztráty. Když tlačí místo, int4 nebo rovnou binární RaBitQ/BBQ s oversamplingem a přeřazením podle plné přesnosti; jeden bit na dimenzi u tisícirozměrného modelu drží kvalitu, jakou by čtyřiašedesátirozměrná float16 verze při stejném rozpočtu bitů nikdy nedala. Jen si to změřte na vlastních datech, ne v cizí tabulce - totéž pasovské srovnání osmi typů kompresních metod na korpusech až do sta milionů pasáží končí závěrem, že nejlepší volba se model od modelu liší. A to je jediná pointa, kterou lze zobecnit bezpečně.
A float32? Milion embeddingů z modelu BGE-M3, který na začátku zabíral čtyři gigabajty, se po binární kvantizaci vejde do sto osmadvaceti megabajtů operační paměti. Rozdíl nebyla informace. Byl to prostor, který jsme dopláceli na číslo předstírající dvaatřicet bitů, zatímco neslo dva.
Zdroje (ověřeno k 5. 7. 2026): J. Gao, C. Long, „RaBitQ“, SIGMOD 2024 (arXiv:2405.12497). Elastic Search Labs, „Better Binary Quantization (BBQ) in Lucene and Elasticsearch“ (2024) a dokumentace Elasticsearch k BBQ; Elasticsearch 8.16, listopad 2024. „Dimension vs. Precision“, arXiv:2511.13057 (2025). A. Kusupati a kol., „Matryoshka Representation Learning“, NeurIPS 2022. P. Nair a kol., „Matryoshka Quantization“, arXiv:2502.06786 (Google DeepMind, 2025). L. Caspari a kol., „CoRECT: A Framework for Evaluating Embedding Compression Techniques at Scale“, arXiv:2510.19340 (Univerzita Pasov, 2025; v3 leden 2026). Protiargument o spektru: „On the Spectral Flattening of Quantized Embeddings“, arXiv:2602.00969 (2026).
Transparentnost tvorby:
Koncepce, struktura a redakční linie článku jsou dílem autora, který vypracoval obsahovou skicu, stanovil klíčové teze a řídil celý proces tvorby. Generativní AI (Claude, Anthropic) byla využita jako nástroj pro rešerši, vyhledávání primárních zdrojů a formulační rozpracování autorovy obsahové skici.
Autor výstupy průběžně redigoval, ověřil klíčová zjištění a schválil finální znění. Žádná část textu nebyla publikována bez lidské kontroly. Všechny faktické údaje byly ověřeny proti veřejně dostupným zdrojům uvedeným v textu.
Postup je v souladu s požadavky čl. 50 Nařízení EU 2024/1689 (AI Act) na transparentnost AI-generovaného obsahu. #poweredByAI
