Kolibri-1: německé firemní dokumenty a AI, která má umět říct „nevím“

U dodavatelské reklamace nechci, aby AI doplnila pravděpodobnou záruční lhůtu. Chci vědět, ve kterém dokumentu ji našla. A když chybí příloha smlouvy, potřebuji dostat případ k člověku.

Právě tím je zajímavý Kolibri-1 od Aleph Alpha. Vyšel 3. října 2026, zaměřuje se na němčinu a angličtinu a jeho váhy jsou dostupné pod Apache 2.0. Výrobce uvádí trénování na odmítnutí odpovědi, kterou dodaný kontext nepodporuje. To je důvod k testu, nikoli záruka správnosti. Oznámení Aleph Alpha.

Kam bych ho ve firmě zařadil

Můj první pilot by byl interní asistent pro českou firmu s německými dodavateli. Vstupem jsou e-maily, objednávky a technické podklady. Výstupem návrh odpovědi s odkazy na konkrétní pasáže. Ne automaticky odeslaný e-mail.

Pilot bych vedl v němčině. Kvalitu češtiny a slovenštiny bych změřil odděleně; schopnosti v jednom jazyce nelze považovat za výsledek testu v jiném. Ani překlad vstupu není zadarmo: přidává další místo, kde se může změnit význam technického termínu.

Téma navazuje na kontrolu nad provozem firemní AI. Tady ale řešíme konkrétní nový model a způsob, jak ověřit práci s chybějícími důkazy.

Aktivní parametry nejsou velikost serveru

Podle modelové karty jde o MoE s přibližně 78 miliardami parametrů, z nichž je aktivních 3,46 miliardy na token. FP8 váhy zabírají přibližně 78 GB. Maximum kontextu je 1 048 576 tokenů; výrobce pro efektivní provoz a složité úlohy doporučuje nejvýše 262 144. Nasazení používá plugin Aleph Alpha pro vLLM.

Z toho pro mě plyne jednoduché rozpočtové pravidlo: nákup infrastruktury nepočítat z aktivních parametrů. Do pilotu započítat paměť pro souběžné požadavky, délku dokumentů, provozní rezervu i čas člověka, který server spravuje. Konkrétní GPU konfiguraci bych vybral až podle zátěžového testu.

Návrh workflow v n8n

Následující postup je návrh pilotu, ne zde otestovaná integrace:

1. Interně provozované n8n převezme e-mail a přiřadí mu ID případu. OCR případných skenů zůstane samostatným krokem.
2. Vyhledávání vrátí jen pasáže dokumentů, ke kterým má daný uživatel přístup. Ke každé přidá ID a verzi.
3. Model navrhne odpověď, seznam použitých podkladů a chybějící informace. Vynucený výstupní formát musí projít validací aplikace.
4. Samostatný krok ověří existenci citovaných pasáží. Člověk posoudí, zda skutečně dokládají závěr; samotná platná citace nestačí.
5. Návrh se uloží do fronty ke schválení. Opakovaný běh se stejným ID nesmí vytvořit druhý případ ani znovu odeslat odpověď.

Pokud je cílem držet data uvnitř firmy, zkontroloval bych také OCR, vyhledávání, logy a zálohy. Lokální model neřeší cestu dokumentu ostatními službami.

Otestujte i cenu příliš častého „nevím“

Připravil bych 60 ručně vyhodnocených případů: 20 s úplnými podklady, 20 s chybějící rozhodující informací a 20 s rozporem mezi dokumenty. Tato čísla jsou návrh malé úvodní sady, nikoli statistická záruka.

Měřil bych nepodložené odpovědi, zbytečná odmítnutí u řešitelných případů, správnost citací, čas opravy a náklad na schválený výsledek. Model, který odmítne všechno, může působit bezpečně a přesto týmu nepomoci.

Začal bych vedle současného řešení bez automatických zápisů do CRM či ERP. Teprve pokud klesne množství oprav při přijatelné latenci a provozních nákladech, rozšířil bych pilot. Hodnota Kolibri se pro takovou firmu ukáže v konkrétní odpovědi nad německým podkladem, ne v samotné délce kontextu.

Zdroje: původní oznámení, 3. 10. 2026, modelová karta a návod k nasazení. Vlastní benchmark modelu jsem pro tento článek neprováděl.