Reasoning modely: co se skutečně děje, když model „přemýšlí“

Reasoning model (model s rozšířeným uvažováním) během inference generuje pracovní kroky navíc a teprve potom vytvoří odpověď. Tento výpočet při inferenci (test-time compute) může zlepšit matematiku, kód i plánování — nebo jen zvýšit cenu a latenci. V článku rozlišujeme, kdy výpočet přidat a jak výsledek nezávisle ověřit.

Nejdřív slovník: pět různých věcí pod slovem „myšlení“

Výrobci často používají pojmy thinking, reasoning a chain of thought téměř zaměnitelně. Technicky ale označují různé mechanismy. Bez tohoto rozlišení snadno zaměníme text pro uživatele za vnitřní stav modelu nebo volání nástroje za introspekci.

Reasoning model je model dodatečně trénovaný tak, aby pracovní kroky používal účelně a dokázal využít větší výpočetní rozpočet. Běžný instrukční model může po výzvě „postupuj krok za krokem“ také vytvořit CoT, ale nemusel být trénovaný na dlouhé řešitelské trajektorie. Rozlišujme také výpočet při tréninku, který mění váhy, a výpočet při inferenci, který přidává práci jen konkrétnímu požadavku.

Co se děje krok za krokem: žádná pauza, ale další dekódování

U decoder-only Transformeru začne požadavek fází prefill. Server zpracuje prompt paralelně, v každé vrstvě vytvoří aktivace a uloží klíče a hodnoty attention do KV cache. Pak přejde do autoregresivního decode: předpoví další token, připojí jeho K/V do cache a opakuje. U typického textového reasoning modelu první část dekódování míří do interního reasoning kanálu r1 … rn; až speciální přechod přepne generování do final-answer kanálu.

Pracovní tokeny nejsou nečinná prodleva ani druhá neuronová síť. Každý z nich vyžaduje další průchod vrstvami modelu nad KV cache. Dlouhý pracovní postup proto zvyšuje hlavně čas do prvního viditelného tokenu: uživatel nic nevidí, zatímco server generuje skrytou sekvenci.

Přesná implementace proprietárních modelů není veřejná. Konkrétní systém může kombinovat jeden základní model, specializované ověřovače, prohledávání i latentní kroky. Dokumentace popisuje rozhraní a účtování, nikoli celý výpočetní graf.

Proč pracovní tokeny modelu nejsou vidět

OpenAI u hostovaných reasoning modelů neposkytuje neupravený CoT a nabízí jen jeho shrnutí. Gemini vrací shrnutí a šifrovaný podpis. U Anthropicu se chování liší podle generace modelu: starší modely mohly vracet celé bloky pracovního textu, novější často vracejí pouze shrnutí nebo podpis.

U otevřených modelů, například DeepSeek nebo gpt-oss, může provozovatel pracovní text zpřístupnit. Jeho skrytí tedy není vlastností Transformeru, ale produktovým a bezpečnostním rozhodnutím poskytovatele API.

• Bezpečnost a leakage: raw scratchpad může opakovat system/developer instrukce, citlivá data, interní policy nebo škodlivé varianty zvažované před odmítnutím.
• Jailbreak surface: útočník by dostal detailní feedback, která obcházení policy model zvažuje a proč je odmítl. To zrychluje adaptaci útoku.
• UX: pracovní text obsahuje slepé uličky, sebekorekce a neověřená tvrzení. Zobrazit jej jako autoritativní vysvětlení by uživatele mátlo.
• IP a training leakage: trajectory může odhalovat interní prompty, syntetická data nebo charakter post-trainingu.
• Monitorability: paradoxně je raw CoT cenný providerovi. OpenAI ukázalo, že monitor nad CoT dokáže odhalit reward hacking; silná přímá optimalizace „špatných myšlenek“ ale model naučí záměr skrývat. Laboratoř proto chce kanál zachovat jako citlivý safety signal.

To jsou legitimní důvody, ne úplná výhra. Skrytí CoT snižuje auditovatelnost pro zákazníka a koncentruje důvěru u providera. Summary tento problém neřeší: sumarizátor vybírá, zkracuje a filtruje. Může být věcně užitečný, ale nesmí se ukládat jako důkaz, že model skutečně postupoval popsaným způsobem. Audit produkčního systému má stát na inputs, tool calls, zdrojích, outputs, usage a výsledku verifieru.

Jak se model učí uvažovat: od ukázek k ověřitelné odměně

Předtrénovaný Transformer umí generovat postupy, protože je viděl v textu, ale nemá důvod utrácet tisíce tokenů za kontrolu jednoho výsledku. Supervised fine-tuning (SFT) na kvalitních reasoning traces naučí formát, rozklad a čitelnost. Má však strop: model imituje délku a styl demonstrace, včetně chyb, a lidské CoT je drahé.

Reasoning post-training proto využívá reinforcement learning s ověřitelnou odměnou. U matematiky lze porovnat finální číslo, u kódu spustit testy, u formálního důkazu checker. Model vzorkuje celé trajektorie; ty, které skončí správně, dostanou odměnu. Gradient neurčuje větu „teď proveď substituci“, ale zvyšuje pravděpodobnost všech rozhodnutí na úspěšných trajektoriích. Delší rozklad, backtracking, self-check nebo změna strategie mohou vzniknout, protože pomáhají výsledku.

DeepSeek-R1-Zero: silný experiment, ne důkaz lidského myšlení

DeepSeek použil metodu Group Relative Policy Optimization přímo na základní model DeepSeek-V3-Base, bez předchozího SFT na ukázkách postupů. Během RL začal R1-Zero generovat delší odpovědi, kontrolovat vlastní kroky a vracet se k předchozím rozhodnutím. Odměna hodnotila správnost i formát; autoři se záměrně vyhnuli neuronovému hodnoticímu modelu, který by šlo obejít.

Výsledek řešil úlohy dobře, ale opakoval se, míchal jazyky a špatně se četl. Produkční R1 proto doplnil kvalitní počáteční CoT ukázky, výběr úspěšných vzorků a další fáze SFT a RL zaměřené na užitečnost i bezpečnost.

Důležitější než „aha moment“ v ukázce je mechanismus výběru. RL našlo trajektorie, které získávají odměnu. To může být skutečná korekce, ale také shortcut, exploit checkeru nebo styl, který vypadá jako reasoning. Distillation pak přenáší úspěšné traces do menších Qwen/Llama modelů; neučí je nutně stejný interní algoritmus, učí je reprodukovat distribuci učitelových řešení.

Zásadní je rozdíl mezi odměnou za výsledek (outcome reward) a odměnou za postup (process reward). První varianta hodnotí jen konec. Je levná, ale může odměnit chybný postup, který náhodou skončil správně. Process Reward Model (PRM) naopak hodnotí jednotlivé kroky.

OpenAI ve studii Let’s Verify Step by Step ukázalo na datasetu MATH lepší výběr řešení pomocí PRM. Uváděných 78,2 % ale platí pro konkrétní modely a podmnožinu dat, nikoli jako obecný důkaz, že hodnocení postupu vždy vítězí.

Výpočet při inferenci není jedna technika

Po dokončení tréninku lze dodatečný výpočet využít čtyřmi způsoby. Jejich náklady nejsou zaměnitelné. Osm tisíc tokenů generovaných za sebou má výrazně vyšší dobu odezvy než osm paralelních kandidátů po tisíci tokenech, i když je jejich celkový počet stejný.

Snell et al. na datasetu MATH ukázali, že vhodný poměr postupných oprav a paralelních kandidátů závisí na obtížnosti úlohy. Adaptivní politika téměř dorovnala best-of-N se čtvrtinovým výpočetním rozpočtem. V jednom režimu dokonce menší model s adaptivním rozpočtem překonal přibližně 14× větší model.

Podmínkou bylo, že menší model už měl reálnou šanci problém vyřešit. Pokud je úloha mimo jeho schopnosti, více vzorků pouze vytvoří více různých chyb.

Kdy více výpočtu skutečně pomáhá

Největší přínos vidíme u úloh s několika závislými kroky, jejichž výsledek lze levně ověřit: v matematice, kódu s testy, formálních důkazech nebo plánování s pevnými omezeními. Model může vyzkoušet více cest a test či jiný ověřovač oddělí správné řešení od řešení, které pouze působí přesvědčivě. U dlouhého plánování s nástroji navíc část zlepšení přinášejí nově získaná data, nikoli delší vnitřní monolog.

Stejná studie našla na SWE-bench Lite u DeepSeek-Coder-V2-Instruct růst coverage z 15,9 % při jednom sample na 56 % při 250 samples. Tam lze kandidáty spustit proti testům, takže coverage je prakticky využitelnější. Na MATH se majority vote a reward models po stovkách vzorků saturovaly: generátor správné řešení občas vyrobil, selector jej v záplavě věrohodných chyb nenašel. To je nejdůležitější zákon inference scalingu: generování optionality nestačí, potřebujete diskriminační signál.

Projekt s1 ukázal, že délku postupu lze řídit i za běhu. Model Qwen2.5-32B-Instruct dotrénovaný na pouhých 1 000 pečlivě vybraných postupech používal vynucení rozpočtu (budget forcing): při pokusu o ukončení runtime potlačil koncový token a přidal slovo „Wait“. Skóre na AIME24 vzrostlo z 50 na 57 %.

Jde o ukázku kontrolovatelného rozpočtu, ne o obecné doporučení. Násilně prodloužený CoT může hotové řešení také rozbít a hostované API navíc interní koncové tokeny obvykle neumožňuje řídit.

Kdy je delší uvažování jen drahý šum

Delší uvažování modelu nedoplní datum vydání knihovny ani obsah vašeho dokumentu. U otázek na fakta je správným řešením načíst zdroj nebo použít vyhledávání. Pro klasifikaci, extrakci do schématu, jednoduchý překlad a chat citlivý na odezvu často stačí levnější model bez rozšířeného uvažování. Přesný výpočet je lepší spustit jako kód. A u subjektivní preference bez správné odpovědi nemá metoda best-of-N spolehlivého rozhodčího.

Přemíra uvažování (overthinking) není jen zbytečně dlouhá odpověď. Model může nejprve najít správný výsledek, pak pokračovat, vytvořit pochybnou námitku a původní závěr opustit. Čím delší je postup, tím více příležitostí vzniká pro chybu a následnou racionalizaci.

Studie Inverse Scaling in Test-Time Compute (Anthropic, 2025) připravila cílené úlohy, v nichž delší uvažování výkon snižovalo. Neříká, jak často se to stává v běžném provozu, ale vyvrací představu, že více tokenů nemůže uškodit.

Slabší nebo neověřitelná úloha má ještě jeden problém: verifier může být horší než generátor. LLM judge preferuje delší, sebejistější a stylisticky známé odpovědi; reward model lze optimalizovat proti jeho slepým místům. Proto platí pořadí důvěry: executable test či formální constraint, ověření citace proti zdroji, nezávislý specializovaný verifier, a až nakonec stejné LLM požádané „zkontroluj se“. Verbosity není accuracy a critique není důkaz.

Věrnost vysvětlení: CoT není záznam vnitřního uvažování

Ani viditelný CoT není přímým výpisem vnitřních aktivací modelu. Je to další generovaný text. Model může dojít ke správnému výsledku přes chybné vysvětlení, nebo naopak pokazit správný postup při posledním přepisu. Výkon říká, zda odpověď vyšla. Věrnost vysvětlení (faithfulness) říká, zda popsaný postup skutečně odpovídá faktorům, které výsledek ovlivnily. Jde o dvě různé vlastnosti.

Turpin et al. vložili do promptů skryté nápovědy, například ukázkové volby posunuté směrem k odpovědi A. GPT-3.5 a Claude 1 tuto nápovědu často následovaly, ale v CoT ji nepřiznaly. Místo toho vytvořily přesvědčivé zdůvodnění chybné volby; přesnost na 13 úlohách BIG-Bench Hard klesla až o 36 %.

Novější studie Anthropicu zjistila podobný jev u Claude 3.7 Sonnet a DeepSeek-R1. Když nápověda odpověď skutečně ovlivnila, Claude ji zmínil jen ve 25 % a R1 ve 39 % případů. Popsaný CoT tedy často zamlčí faktor, který měl na výsledek měřitelný vliv.

To neznamená, že CoT monitoring nemá cenu. Provider může v interních traces najít reward hacking, záměr obejít test nebo vzdání úlohy dříve, než se projeví ve final answer. Znamená to, že absence špatného záměru v CoT nic nedokazuje. Summary je ještě o krok dál od kauzálního procesu. V produkci ji používejte jako navigační vysvětlení, nikdy jako compliance evidence.

Výzkum latentního uvažování ukazuje tři odlišné způsoby, jak přidat výpočet bez dlouhého viditelného CoT:

• Quiet-STaR: vytváří interní textové mezikroky před predikcí obtížných tokenů.
• Coconut: pracuje přímo s latentními vektory a nepřevádí každý krok na slova.
• Pause tokens: přidávají výpočetní kroky bez významového textu.

Tyto přístupy dokazují, že více výpočtu nemusí mít lidsky čitelnou podobu. Nedokazují však, že je používá konkrétní proprietární model ani že latentní stav věrněji vysvětluje výsledek. Auditovatelnost může být naopak horší.

Ekonomika a latence: skrytý text není bezplatný

Pracovní tokeny vznikají po zpracování promptu jeden za druhým. Pokud model před 300tokenovou odpovědí vytvoří 6 000 skrytých tokenů, GPU provede přibližně 6 300 kroků dekódování. Viditelná odpověď se nezačne streamovat, dokud interní fáze neskončí, takže první token může přijít až za desítky sekund. Cache promptu sice lze znovu použít, ale nesnižuje cenu pracovních tokenů, které už model vygeneroval.

Pro výpočet ceny používejte údaje usage z odpovědi API a aktuální ceník: cost = input × input_rate + (visible_output + reasoning) × output_rate. Pokud požadavek spotřebuje 1 000 vstupních, 4 000 pracovních a 500 viditelných výstupních tokenů, výstupní sazba se počítá ze 4 500 tokenů, nikoli z 500.

Je-li výstupní sazba P za milion tokenů, tato část stojí 0.0045 × P. Vzorec je užitečnější než konkrétní částka, protože ceny se mohou změnit.

U paralelního best-of-N roste spotřeba téměř N-krát, ale celková doba může zůstat blízko nejpomalejší větvi, pokud máte dost kapacity. V praxi ji zvyšují limity API, fronty a pomalé odlehlé požadavky. Dlouhý sériový CoT naopak drží jeden dekódovací slot po delší dobu.

Měřte alespoň p50/p95 latenci, vstupní, výstupní a pracovní tokeny, cenu nástrojů, úspěšnost ověřovače a cenu za ověřeně správný úkol.

Praktický rozhodovací rámec: výpočetní rozpočet podle úlohy

1. Určete typ úlohy. Jde o načtení faktu, transformaci, extrakci, výpočet, nebo skutečnou vícekrokovou dedukci? Začněte levnou základní variantou.
2. Měřte kvalitu, cenu a latenci společně. Samotná přesnost skryje drahé malé zlepšení; samotná cena zase skryje opakované pokusy po chybě.
3. Směrujte požadavky adaptivně. none/minimal pro klasifikaci a extrakci, low pro běžný chat, medium pro omezený rozklad a high jen pro těžký kód, matematiku a hodnotné plánování.
4. Pro fakta načtěte zdroj. Delší introspekce nedoplní chybějící nebo aktuální znalost; použijte RAG či vyhledávání.
5. Přesný výpočet předejte nástroji. Model má formulovat postup a interpretovat výsledek, ne emulovat kalkulačku tisíci tokeny.
6. Přidejte nezávislý ověřovač. Sada testů, JSON Schema, databázové omezení, SAT solver nebo kontrola citací jsou silnější než výzva „zkontroluj se“.
7. Nastavte limity a záložní cestu. Tokenový a časový rozpočet, maximum volání nástrojů, circuit breaker a eskalace na člověka patří do návrhu algoritmu.
8. Nepožadujte ani nelogujte neupravený CoT. Ukládejte model, úroveň výpočtu, volání nástrojů, finální výstup, spotřebu, latenci a výsledek ověření. Shrnutí postupu není důkaz správnosti.

Implementace: router nad OpenAI Responses API

Responses API přijímá parametr reasoning.effort a volitelné summary; konkrétní hodnoty závisejí na modelu. Následující ukázka nejprve určí typ a složitost úlohy. Vyšší úroveň výpočtu zkusí jen jednou a pouze tehdy, když externí ověřovač předchozí odpověď odmítne. Aplikace nepožaduje raw CoT a neukládá shrnutí postupu do telemetrie.

from dataclasses import dataclass
from time import perf_counter
from openai import OpenAI

client = OpenAI()

@dataclass(frozen=True)
class TaskPolicy:
    effort: str
    needs_search: bool
    max_latency_s: float

def route_task(kind: str, complexity: int) -> TaskPolicy:
    if kind in {"extract", "classify", "translate"}:
        return TaskPolicy("none", False, 4.0)
    if kind == "factual":
        return TaskPolicy("low", True, 8.0)
    if kind in {"math", "code", "planning"} and complexity >= 7:
        return TaskPolicy("high", False, 45.0)
    return TaskPolicy("medium", False, 20.0)

def solve(prompt: str, policy: TaskPolicy, verify) -> str:
    tools = [{"type": "web_search"}] if policy.needs_search else []
    attempts = [policy.effort]
    if policy.effort not in {"high", "xhigh"}:
        attempts.append("high")

    for effort in attempts:
        started = perf_counter()
        response = client.responses.create(
            model="gpt-5.5",
            input=prompt,
            reasoning={"effort": effort, "summary": "auto"},
            tools=tools,
        )
        latency_s = perf_counter() - started
        answer = response.output_text

        usage = response.usage
        telemetry = {
            "model": response.model,
            "effort": effort,
            "latency_s": latency_s,
            "input_tokens": usage.input_tokens,
            "output_tokens": usage.output_tokens,
            "verified": False,
        }

        ok = verify(answer)
        telemetry["verified"] = ok
        emit_metrics(telemetry)  # Never log raw CoT or reasoning summary.
        if ok:
            return answer
        if latency_s > policy.max_latency_s:
            break

    raise RuntimeError("No verified answer within budget")

V ostré aplikaci musí být verify doménový: testy pro patch, schema a business pravidla pro extrakci, citace proti načteným dokumentům pro factual QA. Eskalace effort po každém neúspěchu dává smysl jen tehdy, když verifier poskytuje nový signál. Bez něj je retry další los ze stejné distribuce. Modelové názvy a podporované effort levels ověřujte při upgradu proti dokumentaci; API surface není univerzální napříč providery.

Závěr: výpočetní rozpočet je zdroj, ne známka inteligence

Reasoning model před odpovědí obvykle generuje další pracovní kroky a spotřebovává na ně proměnlivý výpočetní rozpočet. Jde o skutečnou práci GPU, nikoli však o důkaz lidské introspekce. Obsah pracovních tokenů může zůstat skrytý a jejich shrnutí není důkazem, že model postupoval právě popsaným způsobem. O proprietárních modelech navíc víme jen to, co jejich výrobci zveřejní.

Rozšiřování výpočtu při inferenci funguje nejlépe tehdy, když model už má reálnou šanci řešení najít a systém má silný ověřovač. Bez něj nestačí, že se správný kandidát někde mezi vzorky objeví — systém jej musí umět také poznat.

U jednoduchých nebo znalostních úloh může delší CoT přidat jen cenu, latenci a nové chyby. Praktické pravidlo proto zní: začněte levnou základní variantou, výpočet přidávejte podle obtížnosti, fakta načítejte ze zdrojů, výpočty spouštějte jako nástroje a správnost ověřujte mimo vlastní text modelu.

Autor článku

Zdeněk Vais

Zakladatel Turing Institutu · Senior Principal Software Engineer, Oracle

Zdeněk prošel cestou od programátora přes team leadera až k softwarovému architektovi. V Oracle staví cloudové služby pro média a v Turing Institutu propojuje vývoj softwaru s praktickým využitím AI.

Poznat náš tým →

← Zpět na blog