Inside the Model Spec: Jak veřejný model spec určuje chování AI a proč by to měl znát každý vývojář

Čím víc AI umí, tím víc se musíme ptát: co má dělat, a co naopak dělat nesmí. Uživatelé chtějí užitečné odpovědi, vývojáři chtějí konzistentní chování a firmy potřebují bezpečnost, spolehlivost a předvídatelnost. Z toho důvodu vzniká Model Spec, veřejný dokument, který má definovat zamýšlené chování modelů.

V posledních letech se modely staly tak univerzální, že na ně jde „prakticky všechno“. A právě tady Model Spec přebírá roli jakési veřejné dohody: popisuje principy, pravidla a rozhodovací logiku, jak se má model chovat v různých situacích, včetně těch hraničních.

V tomto článku si Model Spec rozebírám jako reportér i jako člověk, který chce vědět, jak věci fungují pod kapotou: co to vlastně je, kde ho najdu, jak se z něj stává chování modelu, jak Model Spec řeší konflikty příkazů, jak se vyvíjí a co to znamená pro vývojáře, kteří staví na API nebo dělají své „agentické“ specifikace.

Obsah

• 🧠 Co je Model Spec a co není
• 📄 Jak Model Spec vypadá: cíle, politiky a příklady
• 🔍 Jak Model Spec funguje v praxi: spec jako uživatelské rozhraní chování
• 🗺️ Transparentnost: kde najdu Model Spec a jak poslat feedback
• 🧭 Vznik Model Specu: proč Nestačí „RL s lidským hodnocením“
• 🔧 Z specu do chování modelu: přímé i nepřímé vazby
• ⚖️ Chain of command: hierarchie, když se příkazy střetnou
• 🎁 Santa Claus a tooth fairy: proč jsou edge case tak citlivé
• 🧾 Honesty, confidentiality a překvapivé konflikty pravidel
• 🔄 Jak se Model Spec vyvíjí: iterativní nasazení, měření a aktualizace
• 🧩 Když se model liší od specu: jak se řeší nesoulad
• 📌 Dovedou to i menší modely? A jak do toho zapadá „thinking“
• 🧠 Pomáhá chain-of-thought pro alignment? Ano, ale opatrně
• 📚 Model Spec vs „Constitution“ jiných labů: liší se dokumenty, ne závěry
• ❗ Co překvapilo nejvíc: když model „odůvodňuje“ nechtěné chování
• 🎛️ Jak se určuje rozsah specu: co se do něj vůbec vejde
• 🚀 Budoucnost Model Spec: i pro „AGI úrovni“ bude potřeba
• 🧑‍💻 Jak mají vývojáři myslet na Model Spec: od API po agenty „agents.md“
• 🤝 Asimovovy zákony vs Model Spec: hierarchie nepřináší magii
• 🧾 Mohla by AI napsat vlastní Model Spec pro člověka?
• 🧩 Co si z Model Specu odnáším já: praktický checklist

🧠 Co je Model Spec a co není

Model Spec je veřejný rámec, který vysvětluje, jak by se model měl chovat. Není to jen krátký seznam „pravidel“. Je to dlouhý dokument, který popisuje mnoho aspektů modelového chování, od bezpečnosti přes styl odpovědí až po jemnější trade-offy typu: kdy být maximálně upřímný a kdy volit přijatelnou míru zdvořilosti.

Důležité je ale vědět, co Model Spec není:

• Není to tvrzení, že modely dnes spec perfektně vždy dodržují.
• Není to „implementační“ artefakt. Je to hlavně dokument pro lidi: zaměstnanci, vývojáři, tvůrci politik a veřejnost.
• Nejde o kompletní popis celého systému (například integruje i další vrstvy produktu, jako memory nebo enforcement uživatelských politik, i když to přímo v model specu být nemusí).
• Není to detailní encyklopedie každé policy v neomezeném rozlišení. Míří na nejdůležitější rozhodnutí a principy.

Tohle je klíčové pro správnou interpretaci. Model Spec je North Star, směr, cíl a společný jazyk. A protože trénink i modely nejsou deterministické, je normální, že se vyskytují edge case situace, kdy model selže, nebo spec potřebuje zpřesnit.

📄 Jak Model Spec vypadá: cíle, politiky a příklady

Model Spec začíná high-level cíli. Nejde jen o „být chytrý“. V praxi tam najdete důvody, proč se modely nasazují, typicky:

• Umožnit uživatelům a vývojářům práci a tvořivost
• Chrání společnost před závažnou újmou
• Udržet provozní licenci (tj. důvěryhodnost a dlouhodobá udržitelnost přístupu)

Poté následuje „nitty-gritty“ část, která je na stovky stran až kolem řádu stovek stran podle aktuální verze. Vzniká tak, že se vyplatí myslet na to, že prostor možných dotazů je obrovský. Modely dostanou otázky všeho druhu. Proto i spektrum policy rozhodnutí musí být široké.

Model Spec navíc používá dvě praktické metody, které jsou pro pochopení zásadní:

• Pravidla versus defaulty: některé věci jsou pevné (neměnné), jiné jsou jen výchozí styl nebo tón odpovědi.
• Pomezní případy a příklady: místo aby se všechno řeklo abstraktně, dokument ukazuje hranice rozhodování na konkrétních situacích.

Obzvlášť styl, tón a „osobnost“ se v slovech popisuje hůř. Proto se v Model Specu objevují ukázky ideální odpovědi nebo kompaktní verze ideální odpovědi. Smysl je dvojí: ukázat principy v praxi a zároveň dát modelu (a lidem) jasnější představu o tom, jak má vypadat výstup.

🔍 Jak Model Spec funguje v praxi: spec jako uživatelské rozhraní chování

Jedna z nejdůležitějších myšlenek Model Specu je, že slouží jako veřejná behaviorální vrstva mezi uživateli a modelem. V praxi to znamená: když přicházím s dotazem, měl bych mít možnost aspoň přibližně vědět, jak se model rozhodne mezi více cíli.

To je také důvod, proč se Model Spec neuzavírá jen do interních poznámek. Má být čitelný. Má být reálné, aby ho někdo mohl vzít jako referenci při vývoji aplikace, nebo při nastavení vlastního chování agenta.

🗺️ Transparentnost: kde najdu Model Spec a jak poslat feedback

Model Spec je veřejný. Nejjednodušší cesta k aktuální verzi je web:

• model-spec.openai.com

A pokud preferujete zdrojové materiály nebo chcete vidět, jak se dokument vyvíjí:

• GitHub pro „model spec“ (vyhledáním v repozitářích)

Dokument je navíc otevřený, takže ho lidé mohou forkovat a vytvořit vlastní verzi. Tím se Model Spec stává užitečnou inspirací i pro organizace, které chtějí definovat chování svých vlastních modelových systémů.

K feedbacku se dá přistoupit i prakticky:

• V produktu (pokud v dané aplikaci existuje) můžete označit výstup, který se vám nelíbí, a rovnou to poslat.
• Veřejné kanály. V rozhovoru zaznělo, že nejlepší mechanismy se v průběhu času mění, ale že feedback se opravdu promítá do změn specu.

Jinými slovy: Model Spec není „zamčený dokument“. Je to živý závazek.

🧭 Vznik Model Specu: proč Nestačí „RL s lidským hodnocením“

Kdyby byl vývoj alignmentu jednoduchý, nejspíš by Model Spec nebyl potřeba. V minulosti se pro alignment hodně používalo reinforcement learning from human feedback (RLHF). Fungovalo to, ale problém je v interpretaci: i když takové učení z dat přinese výsledky, je těžké zpětně poznat, co přesně spec řekne za naučenou politiku a proč.

Je ještě těžší to přepsat, když se změní názor. Když chcete upravit pravidla, musíte často znovu sbírat nebo přeučit obrovské množství dat.

Model Spec je naopak podobný konceptu příručky pro chování. Přirovnání, které se v rozhovoru objevilo, je „zaměstnanecký handbook“. Nejde jen o to naučit model jednorázové výsledky, ale vytvořit srozumitelný rámec pravidel, který se dá iterovat a vysvětlit lidem.

Konkrétní příběh vzniku projektu Model Spec v rozhovoru zmiňuje, že se věcně rozjel kolem roku 2024, rozhodnutí padlo na úrovni teamů z oblasti model behavior, a cílem bylo jak dokument napsat, tak ho zveřejnit. Transparentnost byla součástí zadání.

🔧 Z specu do chování modelu: přímé i nepřímé vazby

Velká otázka je: jak se Model Spec „přeloží“ do toho, co model dělá?

Odpověď není pouze jedna linka. Je to kombinace způsobů. Někdy se spec promítá přímo do tréninku, někdy jde spíš o to, že výzkumníci a inženýři tréninkem přenesou záměr specu do modelu a potom se spec zpřesňuje, aby odpovídal skutečným cílům.

V rozhovoru zaznělo například deliberative alignment, což je proces, kdy se zejména reasoning modely učí následovat určité politiky a kde může být jazyk specu přímo relevantní.

Současně ale zbytečně zjednodušit nelze: tréninkové procesy alignmentu a safety jsou komplikované a zahrnují mnoho technik. Proto není realistické čekat, že by se každá změna v dokumentu okamžitě a přímo promítla do chování modelu. Spíš jde o iterativní cyklus:

• změní se tréninkové a alignment techniky
• modely se nasadí
• měří se, co uživatelé chtějí a kde jsou problémy
• spec se upraví, aby lépe popsal záměr, nebo aby lépe řídil budoucí chování

⚖️ Chain of command: hierarchie, když se příkazy střetnou

Jedno z nejdůležitějších témat Model Specu je, jak se řeší konflikt instrukcí. Protože konflikty jsou běžné: uživatel chce něco, vývojář může přidat instrukce, a do toho vstupují pravidla a policy od organizace.

V centru specu stojí koncept chain of command. Dá se popsat takto:

• Když se instrukce střetnou, model má obecně preferovat OpenAI instrukce před developer instrukcemi a ty pak před user instrukcemi.
• Zároveň ale OpenAI nechce zablokovat uživatelskou svobodu úplně. Spec proto podporuje „steerability“: některé policy jsou níže v hierarchii, aby uživatel mohl směr upravit, pokud tím neporušuje bezpečnostní hranice.

Spec používá authority levels. To znamená, že každá policy dostane autoritu: kde v hierarchii leží, jak moc může být překonána, a jak se bude rozhodovat v konfliktech.

Jakmile se tohle správně nastaví, dostanete dvě užitečné vlastnosti najednou:

• Udržení bezpečnostních minim (nejdůležitější safety policy se nedají obcházet)
• Stabilní a předvídatelné chování (user instrukce se mohou uplatnit, když nejsou v přímém konfliktu)

🎁 Santa Claus a tooth fairy: proč jsou edge case tak citlivé

Model Spec musí řešit situace, kde nikdo nemá plný kontext. Model neví, kdo stojí na druhé straně. Neví, jestli se ptá dospělý nebo dítě. A přitom otázky jako „Je Santa Claus skutečný?“ nebo „Existuje zubní víla?“ nejsou jen o pravdivosti tvrzení. Jsou to kulturní a emoční interakce.

V rozhovoru zazněl příklad s Santa Clausem, kde je rozhodnutí „nejisté“: model nemá jasnou informaci o věku tazatele. Proto spec volí konzervativní přístup: předpokládá se možnost, že se ptá dítě, a odpověď se má chovat tak, aby zbytečně „nezkazila magii“.

Tohle připomíná i princip zubařské víly: konzervativní předpoklad, že tazatel nemusí být dospělý, vede k odpovědi, která se snaží být v souladu s takzvaným honesty versus friendliness trade-offem. Nejde o „lhaní za každou cenu“, ale o to, jak odpovídat, když plná pravda může ublížit nebo ztratit smysl konverzace.

Zároveň se ukázalo, že „ideální pravda“ není vždy nejvhodnější policy. Spec se vyvíjí v detailech: kdy je v pořádku bílá lež, a kdy už ne. V rozhovoru se zmínilo, že se v průběhu času posunuly hranice, například že bílé lži se z určitých oblastí vyřadily.

🧾 Honesty, confidentiality a překvapivé konflikty pravidel

Možná nejzajímavější část je ten moment, kdy se „dobře napsaná policy“ začne chovat neintuitivně v reálném světě.

V rozhovoru padl konkrétní konflikt mezi honesty a confidentiality. Koncept confidentiality je důležitý v API světě, kde developer instrukce mohou být pro vývojáře nebo zákazníky „součástí produktu“ a měly by zůstat skryté, podobně jako firemní interní postupy.

V minulých verzích specu existovala silnější zásada, že developer instrukce jsou ve výchozím stavu tajné. Cíl byl jasný: zákazník nemá vidět „prompt“, když je to vlastně intelektuální vlastnictví nebo design aplikace.

Jenže v praxi vznikl problém: model se mohl snažit tajné instrukce „prosazovat“ i v situaci, kdy to bylo v konfliktu s uživatelskou žádostí. Jinými slovy, i když developer instrukce byly zamýšlené jako důležité, model by neměl „tajně“ obcházet user instrukce.

Praktický závěr byl, že se policy přehodnotily. V rozhovoru zaznělo, že se postupně vyřízly většinu výjimek, kde se honesty konflikt s confidentialitou dělal matoucí, a nakonec se rozhodlo, že honesty je výše než confidentiality v hierarchii specu.

Tohle je dobrá lekce pro každého, kdo píše policy nebo specifikace: i dobře navržená pravidla mohou vytvořit nechtěnou cestu chování, když je model „příliš“ doslovný nebo když se policy interpretují v konfliktních situacích.

🔄 Jak se Model Spec vyvíjí: iterativní nasazení, měření a aktualizace

Model Spec není statický dokument. Vzniká iterativně a jeho změny mají několik zdrojů:

• Modely jsou schopnější a produkt se mění, takže spec musí pokrýt nové režimy (například multimodalita, později principy pro autonomii a agenty).
• Otevřený proces: každý v organizaci může navrhnout změny a komentovat.
• Iterativní deployment: nejlepší způsob, jak pochopit bezpečné nasazení, je nasadit model, sledovat dopady a vracet se ke specifikaci.
• Učení z incidentů: v rozhovoru se zmínilo, že se po určitých událostech (například bezpečnostní incidenty) vrací learnings zpět do specu.
• Výzkumné týmy model behavior a safety: studují chování modelů a co uživatelé jako a nelíbí.

Tak vzniká živý cyklus: spec určuje, kam mířit. Modely ukážou, kde míříme jinam. A spec se upraví tak, aby zůstával srozumitelný lidem i použitelný pro vývoj chování modelů.

🧩 Když se model liší od specu: jak se řeší nesoulad

Protože spec není implementace „na 100 %“, modely se občas odchýlí. A pak přichází klíčová otázka: co je správné řešení?

V rozhovoru padlo několik principů:

• Spec není tvrzení, že model bude vždy perfektně sladěný. Je to North Star.
• Spec často „vede“ to, kde modely jsou dnes. To znamená, že spec může být o krok napřed.
• Modely jsou nedeterministické. To znamená, že i stejné podmínky mohou vyprodukovat variace.

Co se dělá při nesouladu? Obvykle se rozhoduje mezi dvěma možnostmi:

1. Pokud je výstup podle týmu dobrý, ale spec ho popisuje špatně nebo příliš tvrdě, upraví se policy ve spec.
2. Pokud výstup vypadá jako nechtěné chování, řeší se to trainingem nebo dalšími alignment zásahy, aby se model zlepšil v dodržování specu.

Zároveň se budují a používají spec evals, které měří compliance (shodu) napříč specem. A jak znělo v rozhovoru, v čase roste sladění modelů s principy specu.

📌 Dovedou to i menší modely? A jak do toho zapadá „thinking“

Často se diskutuje, jestli menší modely zvládnou složité policy a edge case chování. V rozhovoru zaznělo, že menší modely jsou obecně dobře alignmentované a zároveň se ukázalo, že reasoning modely spec dodržují lépe.

Důvod je praktický:

• jsou často chytřejší
• a mohou být částečně trénované přes deliberative alignment, takže skutečně „rozumí“ tomu, jaká policy platí v dané situaci

V rozhovoru se to spojilo s myšlenkou, že model pak nejedná jen jako „policy matcher“, ale skutečně zvažuje konflikt a preferuje správné priority.

🧠 Pomáhá chain-of-thought pro alignment? Ano, ale opatrně

Chain-of-thought (způsob, jak model uvažuje) se v alignmentu často probírá kontroverzně. V rozhovoru zaznělo, že při práci na scheming a strategické decepci je přístup, kdy můžete vidět, co se děje uvnitř, zásadně užitečný.

Proč? Protože chování může vypadat v pořádku na první pohled. Ale chain-of-thought může ukázat, že model nebyl „zmatenej“, nýbrž byl strategický. To je pro bezpečnost důležité: i „správná navenek“ odpověď může skrývat nebezpečný záměr.

Zároveň zaznělo, že modely byly záměrně trénované tak, aby chain-of-thought nebyl „supervizovaný“ ve smyslu vynucování konkrétního formátu nebo postupu. Místo toho mají být modely schopné být spíš poctivé ve svém uvažování. Pro evaluace i pochopení chování to dává jasnost.

📚 Model Spec vs „Constitution“ jiných labů: liší se dokumenty, ne závěry

V ekosystému alignmentu se objevují i jiné veřejné dokumenty, například „Constitution“ v Anthropoc přístupu. Jaký je rozdíl?

V rozhovoru zaznělo, že rozdíly v praxi často nejsou až tak velké, pokud se podíváte na finální chování. Ale je tu zásadní rozdíl v typu dokumentu:

• Model Spec je primárně „public behavioral interface“: vysvětluje, jak by se model měl chovat, aby uživatelé a vývojáři měli dobré očekávání.
• Constitution může být více „implementation-like“: je to dokument, který má specificky učit identitu a vztah modelu ke světu a k tréninku.

Tyto přístupy mohou být doplňující, ne nutně konkurenční. I kdyby model byl hluboce sladěný, spec je užitečný pro ověření, zda se to skutečně generalizovalo, jak chceme. Z pohledu vývojáře je to jako testovací sada a referenční dokument v jednom.

❗ Co překvapilo nejvíc: když model „odůvodňuje“ nechtěné chování

Jedna z odpovědí v rozhovoru zdůrazňuje zkušenost, která je pro alignment bolestivá: i když tým věří, že policy jsou red-teamingem „ošetřené“, může se objevit případ, kde model udělá něco, co nechcete, a zdůvodní to právě tím, že se opírá o policy, které jste dali.

To je připomínka, že alignment není jen o tom napsat správná pravidla. Je to i o tom, jak model policy interpretuje, jak je v konfliktu aplikuje, a jak se rozhoduje pod nejistotou.

🎛️ Jak se určuje rozsah specu: co se do něj vůbec vejde

„Scope“ specu je praktický problém. Model Spec by mohl být nekonečný, kdyby zahrnoval každý detail každé policy. V rozhovoru zazněla jednoduchá, ale ne snadná logika:

• Rozsah zahrnuje vše, co je součástí model behavior.
• Kritérium „cut“ je dostupnost a čitelnost: dokument musí být čitelný, aby ho lidé skutečně používali.
• Pokud je to důležité rozhodnutí, které by bylo užitečné, aby veřejnost pochopila, tak má šanci se tam dostat.

Ve výsledku je to kompromis mezi úplností a použitelností.

🚀 Budoucnost Model Spec: i pro „AGI úrovni“ bude potřeba

Jedna z nejzajímavějších otázek v rozhovoru byla: pokud by model byl na úrovni lidského AGI, proč by ještě existovala role Model Specu?

Odpověď zněla v duchu: i kdyby model uměl vše „vědět sám“, pořád je užitečné:

• mít jasná očekávání pro lidi a organizace
• mít zakódovaná rozhodnutí, která nejsou matematickým problémem, ale produktem a společenskými volbami
• udržet rámec důvěry a odpovědnosti

Zároveň se ale očekává, že se spec bude vyvíjet. Důraz se může posouvat: s rostoucí autonomií agentů se bude víc řešit důvěra, interakce s okolím, transakce a dlouhodobé dopady. I tam spec nebo „spec-like“ dokumenty dávají smysl.

🧑‍💻 Jak mají vývojáři myslet na Model Spec: od API po agenty „agents.md“

Tady přichází nejpraktičtější část pro mě jako vývojáře: jak by měl Model Spec změnit způsob, jakým přemýšlím o tom, co stavím?

V rozhovoru zaznělo, že vývojáři často nejsou v přímém kontaktu s modelem spec ve smyslu „čtu dokument a pak promptuju“. V reálných aplikacích je model jen součást produktu, třeba zákaznický bot pro aerolinky postavený na OpenAI API.

Model Spec ale i tak pomáhá, protože:

• dává high-level obraz, jak produkt bude fungovat
• pomáhá v návrhu developer instrukcí, aby uživatel získal očekávaný zážitek
• inspiruje tvorbu vlastních dokumentů pro agenty

Vlastní mini specifikace pro projekty se dají dělat třeba v souboru typu agents.md. To je zajímavý směr: organizace si vytvoří vlastní „spec“ pro chování agenta a pak se trénuje nebo designuje tak, aby model uměl spec interpretovat on-the-fly.

Praktická rada pro psaní vlastní spec-like dokumentace, která zazněla, se dá shrnout do dvou bodů:

• Musí to být pravdivé: nesmí se přehánět ani zjednodušovat. Každé tvrzení by mělo odpovídat záměru.
• Musí to být akční: nestačí „všeobecné principy“. Musí být možné rozhodnout, co udělat v konkrétní situaci. Příklady jsou často největší urychlovač srozumitelnosti.

🤝 Asimovovy zákony vs Model Spec: hierarchie nepřináší magii

Když se řekne „spec“, mnoho lidí si vybaví Asimovovy zákony robotiky. V rozhovoru se objevila paralela: na vrcholu Model Specu jsou cíle, které se podobají základním motivům Asimovova rámce (poslouchat instrukce, neškodit, chránit vlastní existenci). A zároveň zazněla zásadní poznámka:

Problém nevzniká z psaní několika pravidel. Vzniká v tom, jak pravidla řeší konflikty a výjimky. A právě to je důvod, proč spec není striktní hierarchie typu „pravidlo 1 vždy vítězí“ bez dalších nuance.

Asimovova iterace (v příbězích) postupně přidává „zeroth law“ a řeší konflikty. Model Spec podobně řeší, že realita je složitější než seznam zákazů a příkazů.

🧾 Mohla by AI napsat vlastní Model Spec pro člověka?

Na konci rozhovoru zazněla otázka, jestli je možné požádat model, aby napsal spec pro lidi. Samotná myšlenka dává smysl: AI umí navrhovat testovací případy, brainstormingem odhalit mezery a pomoci s formulací.

Zároveň je dobré držet se realismu: spec není jen o textu, ale o tom, že musí být:

• přesný
• bezpečnostně konzistentní
• schopný řídit chování v edge case situacích
• udržitelný pro iteraci a audity

Takže AI může být výborný pomocník, ale člověk nebo tým pořád musí zůstat v roli arbitra záměrů.

🧩 Co si z Model Specu odnáším já: praktický checklist

Pokud mám tento koncept převést do něčeho, co můžete použít hned, tady je rychlý checklist, jak přemýšlet o specu při stavbě AI aplikací:

• Čtete behaviorální očekávání: Model Spec není „kultura“, je to referenční rámec pro očekávané chování.
• Počítáte s konflikty instrukcí: uživatel, developer, interní safety policy. Přemýšlejte o hierarchii a authority.
• Hledáte edge cases: nejasný kontext (věk tazatele), trade-offy (honesty vs friendliness), skryté konflikty (honesty vs confidentiality).
• Uvažujete iterativně: spec se vyvíjí, protože modely se vyvíjí. Vaše produkce a evaluace taky.
• Píšete své spec-like dokumenty pro agenty a aplikace: principy doplňujete příklady a přesným rozhodováním v hraničních situacích.

Model Spec není jen teoretický dokument. Je to způsob, jak přetavit hodnoty a bezpečnostní záměry do něčeho, co se dá měřit, testovat a zlepšovat. A jak se AI stává schopnější a autonomnější, tento typ specifikace bude jen důležitější.