Enota 4 / 11

Sistemski poziv in parametri modela

Dobički:

  • Lahko oblikuje, kako sistemski poziv vodi model skozi celoten pogovor
  • Razume vlogo in stroškovni učinek prilagodljivega razmišljanja in parametrov napora
  • implementira izhodne kontrole, kot so max_tokens, zaustavitvena zaporedja in strukturiran izhod

Dva različna izdelka istega modela se lahko obnašata popolnoma različno. Razlika ni v samem modelu, ampak v sistemskem pozivu in parametrih, ki so mu dani. Sistemski poziv je "delovna pogodba" modela, parametri pa "delovne nastavitve". V tej enoti se boste naučili, kako oblikovati močan sistemski poziv, kaj počnejo nastavitve razmišljanja in truda v sodobnih modelih in kako nadzorovati izhod za format/dolžino. Pravilna nastavitev teh nastavitev vam omogoča upravljanje kakovosti in stroškov hkrati.

Sistemski poziv: Stalna direktiva modela

Sistemski poziv je navodilo na visoki ravni, ki velja skozi celoten pogovor. Ta pravila ostanejo veljavna ne glede na to, kaj uporabnik vnese. Dober sistemski poziv vključuje naslednje komponente:

  1. Vloga/identiteta: Kdo je model? (»Ste pomočnik za podporo podjetju.«)
  2. Obseg in meja: kaj počne in česa ne? (»Temelji samo na predloženem dokumentu politike.«)
  3. Pravila oblikovanja: Kako naj izgleda izhod? ("Največ 3 članki, uradni jezik.")
  4. Vedenje v negotovosti: kaj storiti, ko ni prepričan? ("Če ni podatka, si ga izmislite, ga usmerite na ustrezno enoto.")
  5. Varnost/zasebnost: Kaj noče/noče? ("Zahtevaj osebne podatke.")
Namig: sistemski poziv naj bo popravljen. Ne vdelajte informacij, ki se spreminjajo z vsako zahtevo (trenutni datum, uporabniško ime, ID seje). To prekine doslednost in onemogoči predpomnilnik pozivov na enoti 6. Vnesite informacije o spremenljivki v uporabniško sporočilo.

Past preveč agresivnih navodil

Sodobni modeli zelo natančno sledijo navodilom. Agresivni stavki, kot so »MORAJ«, »VEDNO«, »DEFINITIVNO narediti to« ipd., ki so delovali v starejših modelih, danes vodijo v pretiravanje: model pokliče agenta, ko ni potreben ali teče nepotrebno dolgo. Omehčajte pravilo: Namesto »OBVEZNO uporabite iskalnik« je bolj natančno »Če odgovora ni v pogovoru, uporabite iskalnik«.

Parametri modela: razmišljanje in trud

Klasični LLM-ji so imeli temperaturni parameter: nižja vrednost je proizvedla bolj specifičen/dosleden rezultat, višja vrednost pa bolj raznolik/ustvarjalni rezultat. Modeli sodobne generacije (kot je Opus 4.8, Sonnet 5) nadomeščajo ta pristop z dvema zmogljivejšima mehanizmoma in ne sprejemajo več parametrov vzorčenja, kot je temperatura.

  • Prilagodljivo razmišljanje: model razmišlja korak za korakom v svoji "glavi", preden se odzove. Model se glede na težavnost naloge odloči, koliko bo razmišljal. Bistveno izboljša natančnost pri zapletenih problemih z več koraki; Manj razmišlja, da se izogne ​​nepotrebnemu odlašanju pri preprostih vprašanjih.
  • Napor: gumb na visoki ravni, ki prilagodi, kako globoko se model poglobi v nalogo in koliko žetonov skupaj porabi. Tipične ravni: nizka, srednja, visoka in višja. Velik napor lahko izboljša kakovost, vendar tudi poveča zamudo in stroške; Majhen napor prinaša hitrost in prihranke.

Nastavitev

Kaj počne

kdaj

Ne razmišljanje/malo truda

Hitro, poceni, površno

Enostavna klasifikacija, kratek odziv, zakasnitev občutljivih nalog

Prilagodljivo razmišljanje + srednji napor

Uravnotežena kakovost/cena

Večina splošnih nalog

Prilagodljivo razmišljanje + velik napor

najvišja natančnost

Kompleksno sklepanje, kodiranje, dolgoročno delo agentov

Pozor: refleks "maksimalni napor ne glede na vse" poveča stroške. Prilagodite trud nalogi; Pri preprostih opravilih majhen napor pogosto daje enako natančen rezultat po veliko nižji ceni. Pojdite visoko, kjer je potrebna kritična natančnost.

Izhodni nadzor: format, dolžina, struktura

Poleg parametrov nadzorujete tudi sam izhod:

  • max_tokens: Trd strop izhoda (1. in 3. enota).
  • Zaustavitev zaporedij: Zaustavitev modela, ko vidi določen niz. Uporabno za nastavitev prelomnih točk v strukturirani proizvodnji.
  • Strukturiran izhod: Prisilite odziv modela, da se ujema s shemo JSON, ki jo podate. Zagotavlja, da je izhod programsko razčlenljiv in veljaven. To je bolj zanesljivo kot reči "samo vrni JSON" s pozivom.

{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "additionalProperties": false, "properties": { "category": { "type": "string", "enum": ["invoice", "technical", "return", "other"] }, "urency": { "type": "niz", "enum": ["nizko", "srednje", "visoko"] } }, "zahtevano": ["kategorija", "nujnost"] } } }}

Kopirane predloge sistemskih pozivov

# Pomočnik pri podpori podjetja Ste pomočnik pri podpori podjetja.- Zanašajte se izključno na predloženi dokument pravilnika; Če tega ni v dokumentu, recite "Nimam teh podatkov." - Podajte formalen in jasen odgovor v največ 3 stavkih. - Zahtevajte osebne podatke (ŠTK, številka kartice) in jih v odgovoru ne ponavljajte. - Če niste prepričani, ne ugibajte.

# Klasifikator za vsiljevanje strukturiranega izhoda Ste klasifikator povpraševanja. Vnos je sporočilo stranke. Vrnite samo zahtevana polja, ne pišite komentarjev. Če niste prepričani, uporabite "drugo".

# Analitik z definiranim vedenjem stanja v negotovosti Ste podatkovni analitik. Iz priložene tabele potegnite samo preverljive sklepe. Nikoli ne naredite sklepa, ki ne obstaja v podatkih. Če je sklep nejasen, napišite "podatki niso zadostni".

# Pisec vsebine z nadzorom tona in dolžine Ste pisec vsebine. Uporabite topel, a profesionalen ton. Vsako besedilo omejite na 120 besed ali manj. Izogibajte se trženjskemu jeziku klišejev.

Šibek poziv/močan poziv

# WEAK Bodite koristni in dajte dobre odgovore. Potrudite se.

# STRONGVloga: strokovnjak za tehnično podporo. Obseg: na voljo samo vodnik za izdelke. Oblika: korak za korakom, oštevilčen seznam, največ 5 korakov. Omejitev: Priporočite rešitev, ki ni v vodniku; Recite "Nisem ga našel v priročniku." Zasebnost: Ne ponavljajte serijske številke, ki jo je uporabnik delil v odgovoru.

Zmogljiva različica; Ločeno določa vlogo, obseg, obliko, meje in zaupnost. Doslednost izhoda izhaja neposredno iz te jasnosti.

Trije mini kovčki

Primer 1 – Zmanjšanje stroškov s prilagoditvijo napora. Ena ekipa je izvajala vse svoje klice z velikim naporom + razmišljanjem; Tudi preprosti izvlečki e-pošte so bili dragi in počasni za izdelavo. Preprostim nalogam, kot so povzetki, so dodelili malo truda in analizo pogodb, ki so bili zelo naporni. Ohranjena je bila natančnost, povprečna zakasnitev je bila prepolovljena, mesečni stroški pa za tretjino.

Primer 2 — jamstvo JSON. Operacijska ekipa je zahtevala izhod klasifikacije s pozivom »samo daj JSON«, vendar je model občasno napisal »Tukaj je rezultat:« in razčlenjevalnik bi se zrušil. Ko sem povezal konfigurirano izhodno shemo, je izhod vsakič vrnil veljaven JSON; napake pri razčlenjevanju so bile ponastavljene.

Primer 3 – Agresiven takojšen odboj. Poziv pomočnika je rekel: "MORAM iskati VSAKO VPRAŠANJE"; Model je po nepotrebnem iskal tudi preprosta vprašanja, na katera je že vedel odgovor, kar je upočasnilo in povečalo stroške. Pravilo so omilili na "Če odgovor ni v kontekstu, poišči"; Nepotrebni klici so se zmanjšali za 70 % in odzivi so se pospešili.

Pogoste napake

  • Vdelava spremenljivih podatkov v sistemski poziv: prekine doslednost in razveljavi predpomnilnik.
  • Preveč agresivno navodilo: pretirano proženje in nepotrebni stroški pri sodobnih modelih.
  • Velik napor pri vsakem opravilu: Zapravljanje pri preprostih opravilih; prilagoditi napor nalogi.
  • Zahteva JSON samo prek poziva: občasno se prekine; če je kritično, uporabite strukturiran izhod.
  • Nedefiniranje meja/vedenje dvoumnosti: Model zapolni vrzel z izmišljotino (halucinacija).
  • Stara `temperaturna` navada: Sodobni modeli tega ne sprejemajo; Vodite vedenje hitro in s trudom.

Deeper: Pisanje poziva kot pogodbe

Izkušene ekipe obravnavajo sistemski poziv kot pogodbo, ne literarno besedilo: jasne klavzule, merljiva pravila, nedvoumne meje. Ta pristop ima tri konkretne prednosti. Prvi je doslednost: isti vnos daje podoben izhod ob različnih časih. Drugič, preizkušljivost: z vzorcem lahko preizkusite vsak izdelek posebej. Tretjič je enostavno vzdrževanje: če je vedenje napačno, veste, kateri element morate zamenjati.

Dobra praksa je voditi s pozitivnimi zgledi. Namesto da bi ponudili seznam "ne delaj tega", je pri sodobnih modelih veliko učinkoviteje zagotoviti primer, ki pravi, da "točno tako izgleda želeni rezultat". Na primer, v klasifikatorju dodajanje enega ali dveh vzorcev pričakovanega JSON v poziv znatno zmanjša napake pri oblikovanju.

Druga močna tehnika je eksplicitno pisanje negotovega vedenja. Klavzula, kot je "Če niste prepričani, ne ugibajte; recite 'nezadostni podatki'", zavira težnjo modela, da zapolni praznino z izmišljotinami (halucinacija). Ta en sam stavek razbremeni plast preverjanja, ki jo bomo obravnavali v 11. enoti: ko je model že označil negotovost, postane lažje pripeljati do človeške validacije.

Končno razmislite o trudu in pozivu skupaj. Pri velikem naporu model raziskuje več in včasih opravi neželeno »dodatno delo« (nepotrebna razlaga, dodaten predlog). Če v pozivu rečete "daj samo želeni rezultat, ne dodajajte dodatnih komentarjev", se ta stranski učinek velikega truda izravna.

Če povzamem

Sistemski poziv je stalna direktiva modela: opredeljuje vlogo, obseg, obliko, prikrito obnašanje in zaupnost. V sodobnih modelih vedenje poganjajo prilagodljivo razmišljanje in parametri napora in ne temperatura; Usklajevanje truda z nalogo obvladuje kakovost in stroške hkrati. Izhod zavarujete z max_tokens, zaustavitvenimi nizi in strukturiranim izhodom.

Aplikacijska naloga

Izberite nalogo. (1) Napišite sistemski poziv s petimi komponentami (vloga, obseg, oblika, dvoumnost, zaupnost). (2) Navedite, kakšno stopnjo truda bi izbrali za to nalogo in zakaj. (3) Če naj bo izhod strukturiran, skicirajte majhno shemo JSON. (4) Preverite, ali je v vašem pozivu preveč agresiven vzorec in ga ublažite.

kontrolni seznam

  • [ ] Navedem lahko pet komponent dobrega sistemskega poziva.
  • [ ] Lahko razložim, kaj počnejo parametri prilagodljivega razmišljanja in napora.
  • [ ] Lahko uravnotežim kakovost/ceno s prilagajanjem truda glede na nalogo.
  • [ ] Vem, zakaj je strukturiran izpis varnejši od zahtevanja JSON prek poziva.
  • [ ] Prepoznam tveganje v sodobnih modelih preveč agresivnih navodil.