AI v prodeji: Srovnání Llama, Mistral, Qwen

KI & Automatisierung · 5. Oktober 2026 · Ohiku Mose Guy

AI v prodeji: Porovnejte modely Llama, Mistral, Qwen a API pro prodejní pipeline ve středních podnicích – s náklady, latencí a kritérii.

Cloudflare Clef potřebuje podle aktuální zprávy 2,2 sekundy na klasifikaci; GPT-OSS-120B je tam uváděn s 4,7 sekundami, přičemž vypovídací hodnota samotného benchmarku je zpochybňována (Zdroj: zpráva Cloudflare-Clef, reference [15], získáno 5. října 2026). Toto číslo je malé. A je nebezpečné. Protože na prodejní schůzce okamžitě zní jako telefonní agent, dialog v reálném čase a „AI v prodeji teď umí všechno“, ačkoli klasifikace není totéž co čistý tok konverzace s akcí v CRM, souhlasem, přerušením a protokolem.

Přesně proto je toto srovnání nutné. Za posledních 7 až 14 dní neexistovala podle dostupných výsledků žádná spolehlivá oficiální vlna zveřejnění nových modelů Llama nebo Mistral, která by čistě spojovala ceny, latence, kontextová okna a nezávislé benchmarky. Ollama 0.40.0 byla zveřejněna 5. října 2026, ano, ale dostupný výsledek neposkytuje spolehlivé informace o nových verzích modelů, cenách tokenů nebo latencích inference (Zdroj: AIML UpToDate Releases [1]). No, skoro. Existují jednotlivá měření třetích stran, například Mistral Small 4 119B s přibližně 56,6 GiB velikosti vah FP8 a asi 49 tokeny za sekundu na konfiguraci GB10, ale to není oficiální benchmark Mistralu a není to slib Cloud API.

Píšu to jako inženýr v Amplifa, ne jako analytik s krásnou maticí. Můj každodenní život je méně „který model vyhraje na MMLU?“ a více: Proč se RAG úloha zasekla ve 3:17 ráno na PDF tabulce od Phoenix Contact? Proč má prodejní tým Kärcher najednou o 18 procent více manuální dodatečné práce, ačkoli e-mailové texty zní lépe? Proč lokální inference po třech týdnech pilotního provozu nestojí polovinu, ale dvojnásobek, protože nikdo nezapočítal využití GPU, embeddingy, reranking a logiku opakování?

Otázka pro obchodního ředitele ve středním podniku nezní: „Je Llama lepší než Mistral?“ Lepší otázka zní: Která rodina modelů se v kterém bodě mé prodejní pipeline zlomí jako první? Průzkum potenciálních zákazníků se zlomí jinak než personalizace e-mailů. Hlasové volání se zlomí jinak než RAG pro znalosti o produktech. A generální ředitel z Heilbronnu, který prodává stroje pro balicí linky, nepotřebuje modelovou náboženskou víru. Potřebuje pipeline, ovladatelnost a nákladovou křivku, která ve druhém čtvrtletí neexploduje.

AI v prodeji – kritéria hodnocení pro vydání modelů

Llama, Mistral, Qwen a proprietární API modely zde nehodnotím podle fanouškovského klubu. Hodnotím je podle produkčního chování. Zní to suše. A taky to tak je. Ale přesně tam se rozhoduje, zda pilotní projekt u DMG Mori, Trumpf nebo u skrytého šampiona ve Východním Vestfálsku dostane po šesti týdnech rozpočet, nebo skončí ve složce inovací.

Pro B2B prodej jsou z mého pohledu důležitá tato kritéria:

• Profil latence namísto průměrné rychlosti: Time-to-First-Token, propustnost dekódování, latence ocasu a chování streamování jsou pro hlas a chat důležitější než pěkné číslo tokenů za sekundu.
• Kontextové okno a náklady na předběžné načtení: Dlouhé historie CRM, tendry, datové listy produktů a e-mailové vlákna stojí především při předběžném načtení. Velké kontextové okno bez kontroly nákladů je otevřený kohoutek.
• Faktická správnost se zdroji: Pro průzkum potenciálních zákazníků a RAG je důležité, zda model správně extrahuje firemní data, uvádí zdroje a v případě chybějících důkazů odmítá. Ne, zda napíše elegantní odstavec.
• Použití nástrojů a strukturovaný výstup: Akce CRM, JSON schémata, validační pravidla, strategie opakování a oprávnění rozhodují v produkci více než obecná kvalita jazyka.
• Model nasazení: Open weights lokálně s vLLM, Ollama nebo TGI se provozuje jinak než API od OpenAI, Anthropic, Mistral nebo poskytovatele cloudu. Ochrana dat není záležitostí zaškrtávacího políčka.
• Náklady na prodejní objekt: Raději počítám náklady na 1 000 potenciálních zákazníků, na schválený e-mail a na minutu hovoru než náklady na milion tokenů, protože prodej nekupuje tokeny, ale příležitosti.
• Správa a auditovatelnost: Role, oddělení klientů, ochrana proti prompt injection, logování, koncepce mazání a schvalovací procesy nejsou sexy. To je pravda. Bez nich nic neškáluje.

Andrea, vedoucí prodeje u dodavatele automatizace v Bielefeldu, mi v září 2026 řekla větu, která mi utkvěla v paměti: „Pokud AI napíše do e-mailu špatnou referenci, není to ostuda AI. Pak je to moje ostuda.“ Přesně v tom je rozdíl mezi demo a prodejním systémem. Demo se může blýsknout. Prodejní systém se musí chovat slušně.

Pokud AI napíše do e-mailu špatnou referenci, není to ostuda AI. Pak je to moje ostuda.

— Andrea, vedoucí prodeje u dodavatele automatizace v Bielefeldu

Kandidát 1 – Llama pro AI v prodeji

Llama zůstává pro mnoho středně velkých prodejních týmů zřejmým výchozím bodem, pokud se počítá s lokální kontrolou, širokým ekosystémem a mnoha možnostmi inference. Open weights, mnoho kvantizací, široká podpora nástrojů, provoz přes vLLM, TGI, Ollama nebo poskytovatele cloudu. To je síla. Ne nutně jednotlivý model. Ekosystém.

Pro obchodního ředitele to znamená: Llama je zajímavá, pokud interní IT nebo poskytovatel služeb již umí provozovat GPU, pokud data nemají jít do externího API nebo pokud běží mnoho malých klasifikačních a extrakčních úloh. Příklad: Tým extrahuje z webových stránek, PDF a dat z obchodního rejstříku názvy firem, role, lokality, informace o obratu a nákupní signály. K tomu nepotřebuji maximálně velký model, ale stabilní extrakci, deterministický výstup, nízké náklady a dobré chybové zprávy. U zákazníka s dodavatelskou strukturou podobnou Schaeffler jsme na jaře 2026 viděli, že menší lokální model s přísným schématem byl spolehlivější než větší model bez validace. Zní to banálně. Ale byl to rozdíl mezi 7 procenty a 23 procenty dodatečné práce při ověřování dat.

Slabost Llama zřídka spočívá v prvním testu. Slabost spočívá v provozu. Kdo říká „open source“ a myslí „zdarma“, neviděl účet. Pronájem nebo odpisy GPU, elektřina, úložiště, monitoring, aktualizace modelů, verzování promptů, bezpečnostní kontroly, embeddingy, reranking, záložní cesty při přetížení, noční prohledávání s poškozenými PDF z roku 2017. To nevoní jako výzkumná laboratoř, ale jako teplá serverovna a zaprášená dokumentace. A přesně tam se rozhoduje, zda je lokální inference levnější.

Pro personalizaci e-mailů může Llama fungovat dobře, pokud skutečná hodnota pochází z retrievalu a guardrails. Model by neměl volně vyhledávat. Měl by psát z povolených zdrojů: poznámka z CRM, poslední dotaz, zájem o produkt, odvětví, role, povolené reference. Líbí se mi Llama v takových nastaveních, protože lze hodně kontrolovat. Méně důvěřuji Llama, pokud s ní chce někdo bez evaluace postavit autonomního prodejního agenta, který vybírá kontakty, formuluje e-maily, plánuje follow-upy a přepisuje pole CRM. Kdo to spustí bez lidského schválení, nestaví prodej. Staví multiplikátor škod.

Kandidát 2 – Mistral pro evropské prodejní stacky

Mistral je pro evropské společnosti zajímavý z jednoduchého důvodu: pořízení, umístění dat, vnímání dodavatele a kompaktní varianty modelů často lépe odpovídají realitě ve středních podnicích než čistě americky orientovaný stack. To automaticky neznamená, že Mistral vyhraje v každém případě použití. Není to tak úplně pravda. V některých prodejních pracovních postupech Mistral vyhrává právě proto, že nechce být největším modelem v místnosti.

Aktuální test třetí strany pro Mistral Small 4 119B uvádí přibližně 56,6 GiB lokální velikosti vah FP8 a asi 49 tokenů za sekundu na popsané konfiguraci GB10 (Reference [10]). Toto číslo bych nikdy neprodával jako obecnou cloudovou latenci. Neříká, jak vysoká je Time-to-First-Token v API. Neříká, jak se model chová při 30 paralelních uživatelích. Neříká ani, jak stabilní jsou volání nástrojů v procesu CRM. Ale ukazuje něco, co je pro obchodní ředitele důležité: Kompaktní, kvantizované modely se mohou stát dostatečně ekonomickými pro konkrétní úkoly, pokud je proces kolem nich čistě postaven.

Při návrzích e-mailů, překladu, úpravě tónu a shrnutí předchozích kontaktů může být Mistral silný. Zvláště bych ho zvážil, pokud se mísí německý a francouzský obsah, například u strojírenských firem s prodejem v DACH a Francii nebo u dodavatelů v pohraničních oblastech. Webasto, Brose, Festo, Wittenstein – takové společnosti nežijí v čistě anglickém SaaS světě. Produktové termíny, role, právní forma, pobočky a staré poznámky z CRM jsou vícejazyčné a neuspořádané. Model se s tím musí vypořádat, aniž by z „dotazu na náhradní díl těsnění“ udělal strategickou transformační příležitost (ano, to jsem viděl).

Slabost: I u Mistralu platí, že modely s otevřenými vahami nejsou automaticky otevřeným softwarem v přísném smyslu. Licence, komerční využití, reprodukovatelnost, transparentnost tréninkových dat a model hostingu musí být čteny odděleně. „Otevřený“ může znamenat: váhy jsou k dispozici. Nemůže to znamenat: bez omezení, auditovatelný až do tréninku, libovolně komerčně využitelný. Pro CSO není toto rozlišení akademické. Pokud se právní oddělení v prosinci 2026 zeptá, proč zákaznická data prošla určitou pipeline, nepomůže žádný snímek obrazovky z benchmarkového vlákna.

Kandidát 3 – Qwen pro velké kontexty a tvrdé kompromisy

Qwen patří do tohoto srovnání, protože se již dlouho objevuje v technických týmech, i když na německých zasedáních představenstva je zmiňován méně často než Llama nebo Mistral. Aktuální srovnání hardwaru uvádí pro Qwen3-235B-A22B v NVFP4 přibližně 24 tokenů za sekundu na testovaném hardwaru (Reference [10]). To není standardizovaný žebříček. Ale ukazuje to kompromis: velký model, jiná kvantizace, větší nároky na paměť, jiná propustnost. Pro prodej to znamená: Qwen může být zajímavý, pokud se počítá s komplexní extrakcí, dlouhými dokumenty nebo vícejazyčnými úkoly. Ale kdo nemá silnou MLOps infrastrukturu, ten se na velikosti modelu, provozu a správě zadusí.

Qwen bych ve středním podniku nepoužil jako první reflex. Ne proto, že by byl špatný. Ale proto, že organizace často nemá ani čisté verzování dokumentů, hygienu CRM a evaluační sady. U výrobce zařízení z Augsburgu voněla v červnu 2026 projektová místnost po laserové tiskárně a kabelovém kanálu; na SharePointu byly ceníky s „final“, „finalneu“ a „finalKopie“. V takovém prostředí je větší model zřídka řešením. Nejprve musí být jasné, který soubor je pravda.

Kandidát 4 – Proprietární API modely pro řízenou automatizaci prodeje

Proprietární modely od OpenAI, Anthropic, Google nebo specializovaných cloudových poskytovatelů zůstávají v prodeji silné, protože abstrahují provoz. Žádné pořizování GPU. Žádné problémy s ovladači. Většinou lepší API pro použití nástrojů, stabilnější streamovací rozhraní, rychlejší integrace do hlasových stacků. Pro střední podnik, který chce za 90 dní spustit pilotní projekt pro Account Intelligence a návrhy e-mailů, je to často pragmatická cesta.

Ale jsem skeptický, když někdo řekne: „Prostě vezmeme ten nejlepší API model.“ Nejlepší pro co? Pro německé první oslovení nákupních manažerů? Pro extrakci z naskenovaných datových listů? Pro telefonování s přerušením po 450 milisekundách? Pro aktualizaci Salesforce s oprávněními rolí? Proprietární modely jsou pohodlné, ale nákladová křivka se může stát ošklivou, pokud se dlouhé kontexty nefiltrovaně vkládají do každého promptu. 80stránkové PDF produktu nepatří slepě do kontextu. Patří do retrieval systému s chunkingem, BM25, vektorovým vyhledáváním, rerankingem, citacemi a verzováním.

Při hlasovém volání jsou API modely často vpředu, protože telefonování je řetězec: převod řeči na text, dialogový model, připojení nástrojů, převod textu na řeč, logika přerušení, protokol hovoru, souhlas. Rozhodující je end-to-end latence. Ne skóre MMLU. Ne doba klasifikace 2,2 sekundy. Pro přirozené telefonování je důležité, kdy přijde první zvuk, jak dobře agent zastaví při přerušení a zda po hovoru skutečně nastaví správný stav v CRM. Markus, CSO strojírenské firmy z Norimberku, to v srpnu 2026 formuloval docela suše: „Pokud bot tři sekundy mlčí, můj zákazník zavěsí.“

Pokud bot tři sekundy mlčí, můj zákazník zavěsí.

— Markus, CSO strojírenské firmy z Norimberku

Co konkrétně vidíme v Amplifa

Co konkrétně vidíme v Amplifa: Za posledních 12 měsíců jsme u B2B prodejních týmů ve strojírenství a technickém velkoobchodě pozorovali opakující se vzorec. Výběr modelu zřídka vysvětluje více než polovinu výsledku. Při průzkumu potenciálních zákazníků se manuální dodatečná práce znatelně snižuje až tehdy, když se spojí tři věci: extrakce zdrojů před voláním modelu, přísná JSON schémata po volání modelu a testovací sada se skutečnými negativními případy. V nastavení s přibližně 42 000 firemními profily snížil zákazník manuální dobu ověřování na kvalifikovaný účet z přibližně 4 minut na necelých 90 sekund. To nebylo způsobeno větším modelem. Bylo to způsobeno tím, že systém přestal hádat při chybějících datech.

Další vzorec: Kvalita e-mailů je na workshopech přeceňována, kvalita dat v CRM podceňována. Pokud jsou odvětví, role, poslední kontakt a zájem o produkt čisté, středně velký model často poskytuje použitelné návrhy. Pokud tato pole chybí nebo jsou rozporuplná, i špičkový model zdvořile halucinuje. Pak e-mail zní dobře a je přesto špatný. To je nejhorší varianta, protože projde schválením.

Konkrétní zjištění z implementací: Pro RAG v prodeji jsou embeddingy a reranking často tajnými pákami. Ne chatovací model. Hybridní přístup vektorového vyhledávání, BM25 a rerankingu je zmiňován i v aktuálních přehledech odvětví (Reference [13]), ale praxe je špinavější: názvy produktů se mění, PDF tabulky se lámou, ceníky mají práva klientů a staré školicí materiály obsahují prohlášení, která prodej nesmí od roku 2024 používat. Pokud na to model odpoví, neselhal model. Architektura znalostí byla děravá.

Velké srovnání – Llama, Mistral, Qwen, API modely

Tuto tabulku bych nečetl jako žebříček. Žebříčky jsou pohodlné. Bohužel dělají líné. Pro prodejní systémy je lepší architekturou často router: malý model pro klasifikaci, retrieval pro znalosti, silnější model pro finální návrh, soubor pravidel pro shodu, člověk pro schválení při vysokém riziku. Jeden model pro všechno je zřídka architektura. Většinou je to únava z rozpočtu.

Srovnání cen – ceny tokenů nejsou celá pravda

Aktuální výsledky vyhledávání neposkytují ověřené oficiální ceny tokenů pro nové modely Llama nebo Mistral v období do 5. října 2026. Proto nebudu uvádět fiktivní ceny za milion tokenů. To by bylo neseriózní. Zvláště v prodeji, kde se špatný výpočet později projeví v 300 000 vygenerovaných e-mailech nebo 50 000 minutách hovoru.

U samo-hostovaných modelů stejně neexistuje jednotná cena tokenu. Efektivní náklady se přibližně vypočítají z: Náklady na 1 milion tokenů = náklady na GPU, elektřinu, úložiště a provoz za hodinu děleno zpracovanými tokeny za hodinu, vynásobeno 1 000 000. Zní to čistě. Je to jen z poloviny. Propustnost předběžného načtení pro dlouhé kontexty CRM a propustnost dekódování pro chat nebo telefonování je třeba posuzovat odděleně. Velikost dávky, kvantizace, využití a latence ocasu mění výpočet více, než mnoho excelových modelů připouští.

Srovnání cen bez procesních dat je divadlo. Raději počítám s jednotkami, kterým CSO rozumí: náklady na 1 000 obohacených účtů, náklady na schválený e-mail, náklady na sjednanou schůzku, náklady na minutu hovoru s platným výsledkem. U dodavatele Festo s 12 prodejci není úzké hrdlo stejné jako u SaaS týmu s 80 SDR. Takže ani výpočet modelu nesmí být stejný.

Amplifa Produkt – AI prodejní systémy pro B2B Jak Amplifa propojuje průzkum potenciálních zákazníků, Account Intelligence, personalizaci e-mailů a automatizaci prodeje s kontrolovanými AI pipeline.

RAG pro prodejní znalosti – proč model zřídka stačí

RAG stack pro prodej vhodný pro střední podniky musí umět více než jen házet dokumenty do vektorové databáze. Musí verzovat produktová data, ceníky, technickou dokumentaci a staré školicí materiály. Musí znát oprávnění na úrovni dokumentů a klientů. Musí vydávat zdroje a stránky. Musí rozpoznávat zastaralý obsah. Musí odmítat v případě chybějících důkazů.

Zní to jako spousta infrastruktury pro pár návrhů e-mailů. Ale není. Prodej žije z příslibů. Pokud Account Executive řekne nákupčímu u Trumpf nebo dodavateli ze Stuttgartu špatnou kompatibilitu, špatnou dodací lhůtu nebo špatnou referenci, škoda není abstraktní. Pak někdo zavolá. Hlasem. Většinou ne přátelsky.

Můj tvrdý názor: Pro prodej je menší model s dobrým RAG a přísnou validací výstupu téměř vždy lepší než velmi velký model bez kontroly zdrojů. Ne někdy. Téměř vždy. Výjimkou jsou velmi volné kreativní úkoly, ale ty jsou v B2B outboundu přeceňovány. Většina dobrých prodejních textů není kreativní. Jsou správné, relevantní a dostatečně krátké, aby neotravovaly.

Personalizace e-mailů – co benchmarky neměří

BLEU, MMLU, Arena-Rankings, obecné hodnocení jazyka – hezké. Pro B2B návrhy e-mailů často měří mimo problém. Mě zajímají jiné hodnoty: faktická správnost firemních dat, vymyšlené reference na 100 e-mailů, míra schválení prodejem, doba zpracování, míra odpovědí, míra sjednaných schůzek v A/B testu a stížnosti na špatné oslovení.

V březnu 2026 jsme u technického prodejce s pobočkami v Kolíně nad Rýnem a Ulmu viděli test, který se interně zpočátku zdál frustrující. Větší model psal krásnější e-maily. Menší model získal více schválení. Proč? Zůstal blíže materiálu, používal méně volných formulací a držel se seznamu referencí. Prodejcům se texty líbily méně. Zákazníci reagovali lépe. Upřímně? Nevím to v každém případě. Ale více důvěřuji metrikám z reálných testů odesílání než porotě, která čte odpovědi na prompty.

Hlasové volání – proč 2,2 sekundy není telefonní agent

2,2 sekundy z zprávy Cloudflare-Clef se vztahují na klasifikaci. Pro hlasové volání je to nanejvýš stavební kámen. Hlasový agent potřebuje převod řeči na text, dialogový model, připojení nástrojů a CRM, převod textu na řeč, logiku přerušení, eskalaci, protokolování a mechanismy souhlasu. Pokud je některý článek tohoto řetězce pomalý, hovor zní rozbitě.

1. Nejprve změřte Time-to-First-Audio namísto pouze tokenů za sekundu. Zákazník neslyší rychlost tokenů, slyší ticho.
2. Testujte přerušení s reálnými větami: „Moment“, „Ne, to není pravda“, „Pošlete mi to e-mailem“. Mnoho demo verzí se přesně tam zlomí.
3. Zkontrolujte volání nástrojů pod zatížením: kontakt nalezen, odhlášení rozpoznáno, výsledek hovoru zapsán, follow-up není duplicitně vytvořen.
4. Změřte Tail-Latency, nejen průměr. Agent, který je v 95 procentech případů rychlý a v 5 procentech zamrzne, je v prodeji riskantní.
5. Zahrňte eskalaci. Pokud je nejistota vysoká, musí agent čistě předat člověku nebo zrušit.

Pro hlas bych v roce 2026 spíše začal s proprietárními API nebo specializovanými stacky, pokud tým nemůže provozovat vlastní inferenci v reálném čase. Lokální Open-Weight modely mohou fungovat, ale pak mluvíme o streamování, audio latencích, rezervaci GPU, špičkách zatížení a pozorovatelnosti. To není vedlejší projekt pro studenta na brigádě, i když LinkedIn slibuje něco jiného.

FAQ – Který model je nejlepší pro AI v prodeji?

Nejlepší model pro AI v prodeji neexistuje jako obecná odpověď. Pro klasifikaci potenciálních zákazníků může stačit malý lokální model. Pro návrhy e-mailů může být Mistral nebo Llama s dobrým RAG silný. Pro hlasové volání jsou řízené API často pragmatičtější. Pro komplexní analýzu dokumentů může být Qwen zajímavý, pokud funguje provoz a správa. Kdo hledá jedinou odpověď, ještě si nepoložil otázku architektury.

Osobní doporučení – mé pořadí pro střední podniky

Když začínám u středně velkého B2B podniku, nezačínám s největším modelem. Začínám s procesním řezem. Jaká data přicházejí? Jaké rozhodnutí má být učiněno? Jaký výstup se smí automaticky dít? Jaký výstup potřebuje schválení? Jaké chyby jsou trapné, jaké drahé, jaké právně nebezpečné? Teprve poté vybírám rodinu modelů a nasazení.

Moje pořadí pro většinu prodejních pilotních projektů: Nejprve vybudovat datovou a zdrojovou pipeline. Poté otestovat malý nebo střední model pro klasifikaci a extrakci. Poté RAG s povinností uvádět zdroje. Poté návrhy e-mailů se schválením a A/B testem. Hlas až tehdy, když je nastaveno logování, souhlas, akce CRM a eskalace. Kdo začne přímo s autonomním hlasovým agentem, protože benchmark vypadá rychle, zaměňuje výkon motoru s brzdnou dráhou.

U Llama vidím výhodu v kontrole a ekosystému. U Mistralu vidím výhodu v evropské konektivitě a kompaktních pracovních postupech. U Qwen vidím potenciál pro technicky silné týmy s dokumentovou zátěží. U proprietárních API vidím nejrychlejší cestu k pilotním projektům a hlasu. Žádnou z těchto cest bych z principu nevyloučil. Ale odmítl bych každou, která začne bez evaluační sady, nákladového modelu a správy.

Amplifa Sales Audit – prověřte potenciál AI v prodeji Zkontrolujte, které prodejní procesy jsou vhodné pro AI, kde chybí data a která automatizace má ekonomický smysl.

Pomoc při rozhodování – 3 otázky před výběrem modelu

1. Jaký prodejní úkol má model skutečně řešit: průzkum potenciálních zákazníků, návrh e-mailu, RAG, hlas nebo akce CRM? Pokud je odpověď „všechno“, je rozsah příliš velký.
2. Jaké chyby se nesmí stát: chybná firemní data, vymyšlené reference, nepřípustná prohlášení, únik dat nebo duplicitní akce CRM? Odpověď určuje guardrails a schválení.
3. Jak měříme úspěch v pilotním projektu: náklady na 1 000 potenciálních zákazníků, míra schválení, míra odpovědí, sjednání schůzky, Time-to-First-Audio, míra halucinací nebo doba zpracování? Bez cílové metriky bude každý model vypadat nějak dobře.

Tyto tři otázky jsou nepříjemné, protože odkouzlují debatu o modelech. Ale přesně to střední podniky potřebují. Ne více magie. Více měření.

Praktický pilotní plán – 30 dní namísto modelové náboženské víry

Když se mě obchodní ředitel zeptá, jak začít, obvykle načrtnu 30denní pilotní projekt. Ne proto, že 30 dní vždy stačí. Ale proto, že dlouhé strategické dokumenty zřídka najdou poškozená pole CRM. Krátký pilotní projekt s reálnými daty je najde okamžitě. Vůně pravdy je někdy exportovaný CSV s 17 způsoby psaní stejného odvětví.

1. Vyberte 500 až 2 000 reálných účtů z CRM a v případě potřeby anonymizujte citlivá pole.
2. Definujte Golden Set s lidsky ověřenými štítky: odvětví, ICP-Fit, role, nákupní signál, důvod vyloučení.
3. Otestujte dvě cesty modelu: Open-Weight nastavení s Llama nebo Mistral a API model jako referenci.
4. Změřte přesnost, recall, halucinace, náklady na účet a dobu manuální dodatečné práce.
5. Teprve poté na ověřená data postavte návrhy e-mailů, ne dříve.
6. Proveďte malý A/B test s lidským schválením a porovnejte míru odpovědí a sjednaných schůzek.
7. Nerozhodujte se podle nejkrásnějšího textu, ale podle nákladů, míry chyb a přijatelnosti prodejem.

U pilotního projektu se skrytým šampionem z oblasti Stuttgartu jsme před třemi týdny přesně toto pořadí diskutovali. První přání byl Copilot, který okamžitě píše e-maily. Po prohlédnutí dat bylo jasné: Nejprve bylo třeba vyčistit pole odvětví, duplicity a role kontaktních osob. Model nebyl úzkým hrdlem. Byly to vstupní data. To není elegantní, ale šetří to peníze.

Amplifa Zdroje & Nástroje Bezplatné nástroje a audity pro analýzu pipeline, automatizaci prodeje a smysluplné využití AI v B2B prodeji.

Můj závěr k porovnání modelů v říjnu 2026

Aktuální důkazy nestačí na čistý žebříček „Llama proti Mistralu proti Qwen proti Proprietárnímu“. Kdo takový žebříček přesto zveřejní, prodává jistotu, která neexistuje. Za posledních 7 až 14 dní chybí spolehlivá oficiální vydání Llama nebo Mistral s úplnými údaji o cenách, latencích, kontextových oknech a nezávislých benchmarcích. Ollama 0.40.0 je relevantní vodítko, ale ne spolehlivé srovnání modelů. Čísla Mistralu a Qwen z testů třetích stran jsou zajímavá, ale závislá na hardwaru. Cloudflare Clef ukazuje rychlost při klasifikaci, ale ne vhodnost pro telefonování.

Pro střední podniky z toho neplyne stagnace. Naopak. Plyne z toho střízlivá nákupní logika: zkontrolovat oficiální modelové karty, přečíst licenci a datové toky, provést vlastní testy s anonymizovanými prodejními úkoly, počítat náklady na prodejní objekt, ne podle pocitu. Pak se rozhodne, zda se hodí Llama, Mistral, Qwen, malý specialista nebo proprietární API.

Nejlepší srovnání modelů se nekoná na webové stránce benchmarku. Koná se v pipeline, mezi exportem CRM, produktovým PDF, schvalovací maskou a prvním zákazníkem, který odpoví na e-mail podporovaný AI. Někdy je odpovědí schůzka. Někdy je to upozornění na chybné datové pole. Obojí je cenné. Jen jedno z toho je v benchmarku.