zisky:
- Dokáže navrhnout, jak systémová výzva provede model celou konverzací
- Rozumí roli a dopadu na náklady adaptivního myšlení a parametrů úsilí
- implementuje výstupní ovládací prvky, jako jsou max_tokens, stop sekvence a strukturovaný výstup
Dva různé produkty stejného modelu se mohou chovat zcela odlišně. Rozdíl není v modelu samotném, ale v systémové výzvě a parametrech, které mu jsou dány. Systémová výzva je „pracovní smlouva“ modelu a parametry jsou „nastavení práce“. V této lekci se naučíte, jak navrhnout výkonnou systémovou výzvu, co dělá nastavení myšlení a úsilí v moderních modelech a jak ovládat výstup pro formát/délku. Správné nastavení těchto nastavení vám umožní řídit kvalitu i náklady současně.
Systémová výzva: Stálá směrnice modelu
Systémová výzva je instrukce na vysoké úrovni, která platí během celé konverzace. Tato pravidla zůstávají v platnosti bez ohledu na to, co uživatel zadá. Dobrá systémová výzva obsahuje následující součásti:
- Role/identita: Kdo je model? („Jste asistent podnikové podpory.“)
- Rozsah a hranice: Co dělá a co nedělá? („Vycházet pouze z poskytnutého dokumentu zásad.“)
- Pravidla formátu: Jak by měl vypadat výstup? ("Maximálně 3 články, úřední jazyk.")
- Chování v nejistotě: Co dělat, když si člověk není jistý? ("Pokud nejsou žádné informace, vymyslete je, nasměrujte je na příslušnou jednotku.")
- Zabezpečení/soukromí: Co nechce/nechce? ("Požádat o osobní údaje.")
Tip: Udržujte systémovou výzvu opravenou. Nevkládejte informace, které se mění s každým požadavkem (aktuální datum, uživatelské jméno, ID relace). To naruší konzistenci a zneplatní mezipaměť výzev na jednotce 6. Vložte informace o proměnné do uživatelské zprávy.
Příliš agresivní past na instrukce
Moderní modely velmi přesně dodržují pokyny. Agresivní fráze typu „MUSÍM“, „VŽDY“, „UDĚLEJTE TO“ atd., které fungovaly u starších modelů, dnes vedou k přepalování: model volá agenta, když není potřeba nebo běží zbytečně dlouho. Zmírněte pravidlo: Místo „MUSÍTE použít vyhledávací nástroj“ je přesnější „Pokud odpověď není v konverzaci, použijte vyhledávací nástroj“.
Parametry modelu: Myšlenka a úsilí
Klasické LLM měly teplotní parametr: nižší hodnota produkovala specifičtější/konzistentnější výstup, vyšší hodnota produkovala rozmanitější/kreativnější výstup. Modely moderní generace (jako Opus 4.8, Sonnet 5) nahrazují tento přístup dvěma výkonnějšími mechanismy a již neakceptují parametry vzorkování, jako je teplota.
- Adaptivní myšlení: Model zdůvodňuje krok za krokem ve své „hlavě“, než zareaguje. Model se rozhodne, jak moc bude přemýšlet na základě obtížnosti úkolu. Výrazně zlepšuje přesnost u složitých, vícekrokových problémů; Méně přemýšlí, aby se vyhnul zbytečným průtahům u jednoduchých otázek.
- Úsilí: Knoflík na vysoké úrovni, který upravuje, jak hluboko se model ponoří do úkolu a kolik žetonů celkem utratí. Typické úrovně: nízká, střední, vysoká a vyšší. Vysoké úsilí může zlepšit kvalitu, ale také zvyšuje zpoždění a náklady; Nízká námaha přináší rychlost a úspory.
Nastavení
Co dělá
kdy
Přemýšlení/malé úsilí
Rychlé, levné, povrchní
Jednoduchá klasifikace, krátká odezva, úlohy citlivé na zpoždění
Adaptivní myšlení + střední úsilí
Vyvážená kvalita/cena
Většina úkolů pro obecné účely
Adaptivní myšlení + velké úsilí
nejvyšší přesnost
Komplexní uvažování, kódování, práce agentů na dlouhé vzdálenosti
Pozor: Reflex „maximální úsilí bez ohledu na to“ zvyšuje náklady. Přizpůsobte úsilí úkolu; V jednoduchých úkolech poskytuje nízké úsilí často stejně přesný výsledek za mnohem nižší cenu. Jděte vysoko tam, kde je potřeba kritická přesnost.
Ovládání výstupu: Formát, Délka, Struktura
Kromě parametrů ovládáte také samotný výstup:
- max_tokens: Pevný strop výstupu (1. a 3. jednotka).
- Stop sekvence: Zastavení modelu, když vidí určitý řetězec. Užitečné pro nastavení bodů přerušení ve strukturované produkci.
- Strukturovaný výstup: Vynutíte, aby odpověď modelu odpovídala schématu JSON, které zadáte. Zajišťuje, že výstup je programově analyzovatelný a platný. Je to spolehlivější než říkat „jen vrátit JSON“ s výzvou.
{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "additionalProperties": false, "properties": { "category": { "type": "string", "enum": ["faktura", "technická", "return", "řetězec", ""] "enum": ["nízká", "střední", "vysoká"] } }, "požadováno": ["kategorie", "naléhavost"] } } }}
Kopírovatelné šablony systémových výzev
# Asistent podnikové podpory Jste asistent podnikové podpory.- Spolehněte se pouze na poskytnutý dokument o zásadách; Pokud to v dokumentu není, řekněte „Tyto informace nemám.“ - Uveďte formální a jasnou odpověď maximálně ve 3 větách. - Požádejte o osobní údaje (TC ID číslo, číslo karty) a neopakujte je v odpovědi. - Pokud si nejste jisti, nehádejte.
# Strukturovaný výstup vynucující klasifikátor Jste klasifikátor poptávky. Vstupem je zákaznická zpráva. Vraťte pouze požadovaná pole, nepište komentáře. Pokud si nejste jisti, použijte „jiné“.
# Analytik s definovaným chováním stojící v nejistotě Jste datový analytik. Z uvedené tabulky vyvozujte pouze ověřitelné závěry. Nikdy nevytvářejte závěr, který v datech neexistuje. Pokud je závěr nejasný, napište „data nedostatečná“.
# Autor obsahu s ovládáním tónu a délky Jste autorem obsahu. Použijte teplý, ale profesionální tón. Omezte každý text na 120 slov nebo méně. Vyhněte se klišé marketingovému jazyku.
Slabá výzva / Silná výzva
# SLABÉ Buďte nápomocní a dávejte dobré odpovědi. Udělejte to nejlepší.
# STRONGRole: Specialista technické podpory.Rozsah: Poskytuje se pouze produktová příručka.Formát: Krok za krokem, číslovaný seznam, maximálně 5 kroků.Limit: Doporučené řešení není v příručce; Řekněte: "Nemohl jsem to najít v příručce." Soukromí: Neopakujte sériové číslo sdílené uživatelem v odpovědi.
Výkonná verze; Samostatně určuje roli, rozsah, formát, hranice a důvěrnost. Konzistence výstupu vychází přímo z této jasnosti.
Tři mini pouzdra
Případ 1 – Snížení nákladů úpravou intenzity. Jeden tým řídil všechny své hovory s vysokým úsilím + přemýšlením; Dokonce i jednoduché e-mailové výtahy byly drahé a pomalé na výrobu. Přiřadili jednoduché úkoly, jako jsou souhrny s nízkým úsilím a analýza smlouvy s vysokým úsilím. Přesnost byla zachována, průměrná latence byla snížena na polovinu a měsíční náklady byly sníženy o třetinu.
Případ 2 — Záruka JSON. Operační tým požádal o výstup klasifikace s výzvou „stačí dát JSON“, ale model občas napsal „Zde je výsledek:“ a analyzátor se zhroutil. Když jsem připojil nakonfigurované výstupní schéma, výstup pokaždé vrátil platný JSON; chyby analýzy byly resetovány.
Případ 3 – Agresivní rychlý zpětný ráz. Výzva asistenta řekla: "MUSÍ hledat KAŽDOU OTÁZKU"; Model zbytečně hledal i jednoduché otázky, na které už znal odpověď, zpomaloval a zvyšoval náklady. Zmírnili pravidlo na „Pokud odpověď není v kontextu, hledejte“; Zbytečné hovory klesly o 70 % a zrychlily se odpovědi.
Časté chyby
- Vkládání proměnných dat do systémové výzvy: Naruší konzistenci a zruší platnost mezipaměti.
- Příliš agresivní instrukce: Nadměrné spouštění a zbytečné náklady u moderních modelů.
- Vysoké úsilí v každém úkolu: plýtvání v jednoduchých úkolech; přizpůsobit úsilí úkolu.
- Vyžadování JSON pouze prostřednictvím výzvy: Občas se přeruší; pokud je to kritické, použijte strukturovaný výstup.
- Nedefinování hraničního/nejednoznačného chování: Model zaplňuje mezeru výmyslem (halucinace).
- Starý `teplotní` zvyk: Moderní modely to neakceptují; Řídit chování s pohotovostí a úsilím.
Deeper: Psaní výzvy jako smlouvy
Zkušené týmy zacházejí se systémovou výzvou jako se smlouvou, nikoli s literárním textem: jasné klauzule, měřitelná pravidla, jednoznačné hranice. Tento přístup má tři konkrétní výhody. První je konzistence: stejný vstup poskytuje podobný výstup v různých časech. Druhým je testovatelnost: každou položku můžete otestovat samostatně pomocí vzorku. Za třetí je snadná údržba: pokud je chování nesprávné, víte, kterou položku vyměnit.
Dobrou praxí je vést pozitivními příklady. Spíše než poskytnout seznam „toto nedělej“, je v moderních modelech mnohem efektivnější uvést příklad, který říká „přesně tak vypadá požadovaný výstup“. Například v klasifikátoru přidání jednoho nebo dvou vzorků očekávaného JSON do výzvy výrazně snižuje chyby formátování.
Další účinnou technikou je napsat chování nejistoty explicitně. Klauzule jako "Pokud si nejste jisti, nehádejte; řekněte 'nedostatečná data'" potlačuje tendenci modelu vyplňovat prázdné místo výmysly (halucinace). Tato jediná věta odlehčuje ověřovací vrstvu, kterou pokryjeme v bloku 11: jakmile model již označil nejistotu, je snazší vést k lidskému ověření.
Nakonec zvažte úsilí a rychlost společně. Při velkém úsilí model více zkoumá a někdy dělá nechtěnou „práci navíc“ (zbytečné vysvětlování, dodatečný návrh). Výrok „poskytněte pouze požadovaný výstup, nepřidávejte další komentáře“ ve výzvě kompenzuje tento vedlejší efekt velkého úsilí.
V souhrnu
Systémová výzva je trvalou direktivou modelu: definuje roli, rozsah, formát, nejasné chování a důvěrnost. V moderních modelech je chování řízeno adaptivním myšlením a parametry úsilí spíše než teplotou; Přizpůsobení úsilí úkolu řídí kvalitu a náklady současně. Výstup zajistíte pomocí max_tokens, stop polí a strukturovaného výstupu.
Aplikační úkol
Vyberte úkol. (1) Napište systémovou výzvu s pěti komponentami (role, rozsah, formát, nejednoznačnost, důvěrnost). (2) Uveďte, jakou úroveň úsilí byste pro tento úkol zvolili a proč. (3) Pokud by měl být výstup strukturovaný, načrtněte malé schéma JSON. (4) Zkontrolujte, zda se ve výzvě nevyskytuje příliš agresivní vzor, a zjemněte jej.
kontrolní seznam
- [ ] Dokážu jmenovat pět součástí dobrého systémového promptu.
- [ ] Umím vysvětlit, co dělají parametry adaptivního myšlení a úsilí.
- [ ] Dokážu vyvážit kvalitu/náklady tím, že upravím úsilí podle úkolu.
- [ ] Vím, proč je strukturovaný výstup bezpečnější než žádat JSON přes výzvu.
- [ ] Dokážu rozpoznat riziko v moderních modelech příliš agresivních pokynů.