Jednotka 4 / 11

Systémová výzva a parametre modelu

zisky:

  • Dokáže navrhnúť, ako systémová výzva prevedie model počas celej konverzácie
  • Rozumie úlohe a nákladovému vplyvu adaptívneho myslenia a parametrov úsilia
  • implementuje ovládacie prvky výstupu, ako sú max_tokens, stop sekvencie a štruktúrovaný výstup

Dva rôzne produkty toho istého modelu sa môžu správať úplne odlišne. Rozdiel nie je v samotnom modeli, ale v systémovej výzve a parametroch, ktoré sú mu dané. Systémová výzva je „pracovná zmluva“ modelu a parametre sú „nastavenia práce“. V tejto lekcii sa naučíte, ako navrhnúť výkonnú systémovú výzvu, čo robí nastavenie myslenia a úsilia v moderných modeloch a ako ovládať výstup pre formát/dĺžku. Správne nastavenie týchto nastavení vám umožní riadiť kvalitu aj náklady súčasne.

Systémová výzva: Stála smernica modelu

Systémová výzva je pokyn na vysokej úrovni, ktorý platí počas celej konverzácie. Tieto pravidlá zostávajú v platnosti bez ohľadu na to, čo používateľ zadá. Dobrá systémová výzva obsahuje nasledujúce komponenty:

  1. Rola/identita: Kto je model? („Ste asistent podnikovej podpory.“)
  2. Rozsah a hranice: Čo robí a čo nerobí? („Vychádzajte len z poskytnutého dokumentu zásad.“)
  3. Pravidlá formátu: Ako by mal vyzerať výstup? ("Maximálne 3 články, úradný jazyk.")
  4. Správanie v neistote: Čo robiť, keď si človek nie je istý? („Ak neexistujú žiadne informácie, vymyslite si ich, nasmerujte ich na príslušnú jednotku.“)
  5. Bezpečnosť/súkromie: Čo nechce/nechce? ("Požiadať o osobné údaje.")
Tip: Udržujte systémovú výzvu opravenú. Nevkladajte informácie, ktoré sa menia s každou požiadavkou (aktuálny dátum, používateľské meno, ID relácie). Tým sa naruší konzistencia a zároveň sa zruší platnosť vyrovnávacej pamäte výziev na jednotke 6. Vložte informácie o premennej do správy používateľa.

Príliš agresívna pasca s pokynmi

Moderné modely veľmi prísne dodržiavajú pokyny. Agresívne frázy ako „MUSÍM“, „VŽDY“, „ROZHODNE to urob“ atď., ktoré fungovali v starších modeloch, dnes vedú k presýteniu: model volá agenta, keď ho netreba alebo beží zbytočne dlho. Zjemnite pravidlo: Namiesto „MUSÍTE použiť vyhľadávací nástroj“ je presnejšie „Ak odpoveď nie je v konverzácii, použite vyhľadávací nástroj“.

Parametre modelu: Myšlienka a úsilie

Klasické LLM mali teplotný parameter: nižšia hodnota produkovala špecifickejší/konzistentnejší výstup, vyššia hodnota produkovala rôznorodejší/kreatívnejší výstup. Modely modernej generácie (ako Opus 4.8, Sonnet 5) nahrádzajú tento prístup dvoma výkonnejšími mechanizmami a už neakceptujú parametre vzorkovania, ako je teplota.

  • Adaptívne myslenie: Model zdôvodňuje krok za krokom vo svojej „hlave“, než odpovie. Model sa rozhodne, koľko bude myslieť na základe náročnosti úlohy. Výrazne zlepšuje presnosť pri zložitých viackrokových problémoch; Menej rozmýšľa, aby sa vyhol zbytočným prieťahom pri jednoduchých otázkach.
  • Úsilie: Gombík vysokej úrovne, ktorý upravuje, ako hlboko sa model ponorí do úlohy a koľko žetónov celkovo minie. Typické úrovne: nízka, stredná, vysoká a vyššia. Vysoké úsilie môže zlepšiť kvalitu, ale tiež zvyšuje oneskorenie a náklady; Nízka námaha prináša rýchlosť a úsporu.

Nastavenie

Čo robí

kedy

Premýšľanie/malé úsilie

Rýchle, lacné, povrchné

Jednoduchá klasifikácia, krátka odozva, úlohy citlivé na oneskorenie

Adaptívne myslenie + stredné úsilie

Vyvážená kvalita/cena

Väčšina úloh na všeobecné účely

Adaptívne myslenie + veľké úsilie

najvyššia presnosť

Komplexné uvažovanie, kódovanie, práca agentov na veľké vzdialenosti

Pozor: Reflex „maximálne úsilie bez ohľadu na to“ zvyšuje náklady. Prispôsobte úsilie úlohe; Pri jednoduchých úlohách nízka námaha často poskytuje rovnaký presný výsledok za oveľa nižšiu cenu. Choďte vysoko tam, kde je potrebná kritická presnosť.

Ovládanie výstupu: formát, dĺžka, štruktúra

Okrem parametrov ovládate aj samotný výstup:

  • max_tokens: Pevný strop výstupu (1. a 3. jednotka).
  • Stop sekvencie: Zastavenie modelu, keď vidí určitý reťazec. Užitočné na nastavenie bodov zlomu v štruktúrovanej produkcii.
  • Štruktúrovaný výstup: Vynútite, aby sa odpoveď modelu prispôsobila schéme JSON, ktorú poskytnete. Zabezpečuje, že výstup je programovo analyzovateľný a platný. Je to spoľahlivejšie ako povedať „len vráťte JSON“ s výzvou.

{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "additionalProperties": false, "properties": { "category": { "type": "string", "enum": ["faktúra", "technická", "return", "reťazec", "other": "enum": ["nízka", "stredná", "vysoká"] } }, "povinné": ["kategória", "naliehavosť"] } } }}

Kopírovateľné šablóny systémových výziev

# Asistent podnikovej podporySte asistent podnikovej podpory.– Spoľahnite sa výlučne na poskytnutý dokument o zásadách; Ak to nie je v dokumente, povedzte „Nemám tieto informácie“. - Uveďte formálnu a jasnú odpoveď maximálne v 3 vetách. - Požiadajte o osobné údaje (IČO, číslo karty) a neopakujte ich v odpovedi. - Ak si nie ste istý, nehádajte.

# Štruktúrovaný výstup vynucujúci klasifikátorSte klasifikátor dopytu. Vstup je zákaznícka správa. Vráťte iba požadované polia, nepíšte komentáre. Ak si nie ste istý, použite „iné“.

# Analytik s definovaným správaním v neistote Ste dátový analytik. Z poskytnutej tabuľky vyvodzujte iba overiteľné závery. Nikdy nevytvárajte záver, ktorý v údajoch neexistuje. Ak je záver nejasný, napíšte „údaje nedostatočné“.

# Autor obsahu s ovládaním tónu a dĺžkySte autorom obsahu. Použite teplý, ale profesionálny tón. Obmedzte každý text na 120 slov alebo menej. Vyhnite sa klišé marketingovým jazykom.

Slabá výzva / Silná výzva

# SLABÉ Buďte nápomocní a dávajte dobré odpovede. Urob to najlepšie.

# STRONGÚloha: Špecialista na technickú podporu.Rozsah: Poskytuje sa len produktová príručka.Formát: Krok za krokom, očíslovaný zoznam, maximálne 5 krokov.Obmedzenie: Odporúčané riešenie nie je v príručke; Povedzte: "Nemohol som to nájsť v príručke." Ochrana osobných údajov: V odpovedi neopakujte sériové číslo zdieľané používateľom.

Výkonná verzia; Samostatne určuje úlohu, rozsah, formát, hranice a dôvernosť. Konzistencia výstupu pochádza priamo z tejto jasnosti.

Tri mini puzdrá

Prípad 1 – Zníženie nákladov úpravou úsilia. Jeden tím vykonával všetky svoje hovory s vysokým úsilím + myslením; Dokonca aj jednoduché e-mailové súhrny boli drahé a pomalé na výrobu. Jednoduché úlohy, ako sú súhrny pridelili nízkemu úsiliu a analýza zmlúv vysokému úsiliu. Presnosť sa zachovala, priemerná latencia sa znížila na polovicu a mesačné náklady sa znížili o tretinu.

Prípad 2 – záruka JSON. Operačný tím požiadal o výstup klasifikácie s výzvou „len dajte JSON“, ale model občas napísal „Tu je výsledok:“ a syntaktický analyzátor sa zrútil. Keď som pripojil nakonfigurovanú výstupnú schému, výstup zakaždým vrátil platný JSON; chyby analýzy boli vynulované.

Prípad 3 – Agresívny rýchly spätný ráz. Výzva asistenta povedala: "MUSÍ hľadať KAŽDÚ OTÁZKU"; Model zbytočne hľadal aj jednoduché otázky, na ktoré už poznal odpoveď, spomalil a zvýšil náklady. Zmiernili pravidlo na „Ak odpoveď nie je v kontexte, hľadaj“; Zbytočné hovory klesli o 70 % a reakcie sa zrýchlili.

Časté chyby

  • Vkladanie premenných údajov do systémovej výzvy: Naruší konzistenciu a zruší platnosť vyrovnávacej pamäte.
  • Príliš agresívne inštrukcie: Nadmerné spúšťanie a zbytočné náklady v moderných modeloch.
  • Vysoká námaha pri každej úlohe: plytvanie pri jednoduchých úlohách; prispôsobiť úsilie úlohe.
  • Žiadosť o JSON iba prostredníctvom výzvy: Občas sa pokazí; ak je to kritické, použite štruktúrovaný výstup.
  • Nedefinovanie hraničného/nejednoznačného správania: Model vypĺňa medzeru výmyslom (halucinácia).
  • Starý „teplotný“ zvyk: Moderné modely to neakceptujú; Usmerňujte správanie pohotovo a s námahou.

Deeper: Písanie výzvy ako zmluvy

Skúsené tímy zaobchádzajú so systémom prompt ako so zmluvou, nie s literárnym textom: jasné klauzuly, merateľné pravidlá, jednoznačné hranice. Tento prístup má tri konkrétne výhody. Prvým je konzistencia: rovnaký vstup poskytuje podobný výstup v rôznych časoch. Druhým je testovateľnosť: každú položku môžete otestovať samostatne pomocou vzorky. Po tretie, jednoduchosť údržby: ak je správanie nesprávne, viete, ktorú položku vymeniť.

Dobrou praxou je viesť pozitívnymi príkladmi. Skôr ako poskytnúť zoznam „toto nerob“, je v moderných modeloch oveľa efektívnejšie uviesť príklad, ktorý hovorí „presne takto vyzerá požadovaný výstup“. Napríklad v klasifikátore pridanie jednej alebo dvoch vzoriek očakávaného JSON do výzvy výrazne znižuje chyby formátovania.

Ďalšou účinnou technikou je explicitne zapísať správanie neistoty. Klauzula ako „Ak si nie ste istí, nehádajte, povedzte „nedostatočné údaje““ potláča tendenciu modelu vyplniť prázdne miesto výmyslom (halucinácie). Táto jediná veta uvoľňuje overovaciu vrstvu, ktorej sa budeme venovať v 11. bloku: keď už model označil neistotu, bude jednoduchšie viesť k overeniu človekom.

Nakoniec spolu zvážte snahu a pohotovosť. Pri veľkom úsilí model viac skúma a niekedy robí nechcenú „práci navyše“ (zbytočné vysvetľovanie, dodatočný návrh). Výrok „poskytnite len požadovaný výstup, nepridávajte ďalšie komentáre“ vo výzve kompenzuje tento vedľajší efekt veľkého úsilia.

V súhrne

Systémová výzva je stálou smernicou modelu: definuje rolu, rozsah, formát, nejasné správanie a dôvernosť. V moderných modeloch je správanie riadené skôr adaptívnym myslením a parametrami úsilia než teplotou; Zosúladenie úsilia s úlohou riadi kvalitu a náklady súčasne. Výstup zabezpečíte pomocou max_tokens, zastavovacích polí a štruktúrovaného výstupu.

Aplikačná úloha

Vyberte si úlohu. (1) Napíšte systémovú výzvu s piatimi komponentmi (rola, rozsah, formát, nejednoznačnosť, dôvernosť). (2) Uveďte, akú úroveň úsilia by ste si vybrali pre túto úlohu a prečo. (3) Ak by mal byť výstup štruktúrovaný, načrtnite malú schému JSON. (4) Skontrolujte, či sa vo vašej výzve nenachádza príliš agresívny vzor a zjemnite ho.

kontrolný zoznam

  • [ ] Dokážem vymenovať päť súčastí dobrej systémovej výzvy.
  • [ ] Viem vysvetliť, čo robia parametre adaptívneho myslenia a úsilia.
  • [ ] Dokážem vyvážiť kvalitu/náklady prispôsobením úsilia podľa úlohy.
  • [ ] Viem, prečo je štruktúrovaný výstup bezpečnejší ako vyžiadanie JSON cez výzvu.
  • [ ] Viem rozpoznať riziko v moderných modeloch príliš agresívnych pokynov.