Gevinster:
- Kan designe hvordan systemprompten guider modellen gjennom hele samtalen
- Forstår rollen og kostnadseffekten av adaptiv tenkning og innsatsparametere
- implementerer utdatakontroller som max_tokens, stoppsekvenser og strukturert utdata
To forskjellige produkter av samme modell kan oppføre seg helt forskjellig. Forskjellen ligger ikke i selve modellen, men i systemmeldingen og parameterne som er gitt til den. Systemmeldingen er modellens "arbeidskontrakt" og parameterne er "arbeidsinnstillinger". I denne enheten lærer du hvordan du designer en kraftig systemmelding, hva tanke- og innsatsinnstillingene i moderne modeller gjør, og hvordan du kontrollerer utdataene for format/lengde. Ved å angi disse innstillingene riktig kan du administrere både kvalitet og kostnader samtidig.
Systemmelding: Permanent direktiv for modellen
Systemmeldingen er instruksjonen på høyt nivå som gjelder gjennom hele samtalen. Disse reglene forblir gyldige uansett hva brukeren skriver. En god systemforespørsel inkluderer følgende komponenter:
- Rolle/identitet: Hvem er modellen? ("Du er en bedriftsstøtteassistent.")
- Omfang og grense: Hva gjør det og hva gjør det ikke? ("Baser bare på policydokumentet som er oppgitt.")
- Formatregler: Hvordan skal utdataene se ut? ("Maksimalt 3 artikler, offisielt språk.")
- Atferd i usikkerhet: Hva gjør man når man er usikker? ("Hvis det ikke er informasjon, gjør det opp, send det til den aktuelle enheten.")
- Sikkerhet/personvern: Hva vil/vil ikke? ("Be om personopplysninger.")
Tips: Hold systemmeldingen fast. Ikke bygg inn informasjon som endres med hver forespørsel (gjeldende dato, brukernavn, økt-ID). Dette både bryter konsistensen og ugyldiggjør promptbufferen på enhet 6. Legg inn variabelinformasjonen i brukermeldingen.
Den altfor aggressive instruksjonsfellen
Moderne modeller følger instruksjonene veldig nøye. Aggressive fraser som «MÅ», «ALLTID», «DEFINITIVT gjøre dette» osv., som fungerte i eldre modeller, fører i dag til overtrigging: Modellen ringer en agent når den ikke er nødvendig eller kjører i unødvendig lang tid. Myk opp regelen: I stedet for «MÅ bruke søkeverktøyet» er «Hvis svaret ikke er i samtalen, bruk søkeverktøyet» mer nøyaktig.
Modellparametere: Tanke og innsats
Klassiske LLM-er hadde en temperaturparameter: en lavere verdi ga mer spesifikk/konsistent utgang, en høyere verdi ga mer variert/kreativ utgang. Moderne generasjonsmodeller (som Opus 4.8, Sonnet 5) erstatter denne tilnærmingen med to kraftigere mekanismer og godtar ikke lenger prøvetakingsparametere som temperatur.
- Adaptiv tenkning: Modellen resonnerer steg for steg i «hodet» før den svarer. Modellen bestemmer hvor mye man skal tenke basert på oppgavens vanskelighetsgrad. Forbedrer nøyaktigheten betydelig på komplekse, flertrinns problemer; Han tenker mindre for å unngå unødvendige forsinkelser på enkle spørsmål.
- Innsats: Høynivåknapp som justerer hvor dypt modellen dykker ned i en oppgave og hvor mange tokens den bruker totalt. Typiske nivåer: lavt, middels, høyt og over. Høy innsats kan forbedre kvaliteten, men det øker også forsinkelser og kostnader; Lav innsats gir hastighet og besparelser.
Innstilling
Hva gjør
når
Tenker av/lav innsats
Rask, billig, overfladisk
Enkel klassifisering, kort respons, forsinket sensitive oppgaver
Adaptiv tenkning + middels innsats
Balansert kvalitet/kostnad
De fleste generelle oppgaver
Adaptiv tenkning + høy innsats
høyeste nøyaktighet
Kompleks resonnement, koding, langtrekkende agentarbeid
Forsiktig: "maksimal innsats uansett hva"-refleksen øker kostnadene. Juster innsats til oppgave; I enkle oppgaver gir lav innsats ofte det samme nøyaktige resultatet til en mye rimeligere pris. Gå høyt der kritisk nøyaktighet er nødvendig.
Utgangskontroll: Format, Lengde, Struktur
I tillegg til parametrene, kontrollerer du også selve utgangen:
- max_tokens: Hardt tak på utgangen (1. og 3. enhet).
- Stoppsekvenser: Stopper modellen når den ser en bestemt streng. Nyttig for å sette bruddpunkter i strukturert produksjon.
- Strukturert utgang: Tving modellens respons til å samsvare med et JSON-skjema du oppgir. Det sikrer at utdataene er programmatisk parserbare og gyldige. Det er mer pålitelig enn å si "bare returner JSON" med en melding.
{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "objekt", "additionalProperties": false, "properties": { "category": { "type": "streng", "enum": ["faktura", "technical", "returgency":}, "other"type "enum": ["lav", "middels", "høy"] } }, "required": ["kategori", "haster"] } } }}
Kopierbare systempromptmaler
# BedriftsstøtteassistentDu er en bedriftsstøtteassistent.- Stol utelukkende på policydokumentet som følger med; Hvis det ikke er i dokumentet, si "Jeg har ikke denne informasjonen." - Gi et formelt og tydelig svar i maksimalt 3 setninger. - Be om personopplysninger (TC ID-nummer, kortnummer) og ikke gjenta det i svaret ditt. – Hvis du ikke er sikker, ikke gjett.
# Strukturert utgangstvingsklassifiserDu er en etterspørselsklassifiser. Innspillet er en kundemelding. Returner kun de forespurte feltene, ikke skriv kommentarer. Hvis du ikke er sikker, bruk "annet".
# Analytiker med definert atferd for å stå i usikkerhetDu er en dataanalytiker. Trekk kun verifiserbare slutninger fra tabellen som følger med. Kom aldri med en konklusjon som ikke finnes i dataene. Hvis en slutning er uklar, skriv "data utilstrekkelig."
# Innholdsforfatter med tone- og lengdekontrollDu er en innholdsforfatter. Bruk en varm, men profesjonell tone. Begrens hver tekst til 120 ord eller mindre. Unngå klisjémarkedsføringsspråk.
Svak forespørsel / Sterk forespørsel
# SVAKVær hjelpsom og gi gode svar. Gjør ditt beste.
# STERK Rolle: Spesialist for teknisk støtte. Omfang: Kun produktveiledning leveres. Format: Trinn-for-trinn, nummerert liste, maks. 5 trinn. Begrensning: Anbefaler løsning som ikke finnes i veiledningen; Si "Jeg fant det ikke i bruksanvisningen." Personvern: Ikke gjenta serienummeret som er delt av brukeren i svaret.
Kraftig versjon; Den bestemmer rolle, omfang, format, grenser og konfidensialitet separat. Utdatakonsistens kommer direkte fra denne klarheten.
Tre minivesker
Case 1 — Kostnadsreduksjon gjennom innsatsjustering. Ett team kjørte alle samtalene sine på høy innsats + tenkning; Selv enkle e-postsammendrag var dyre og trege å produsere. De tildelte enkle oppgaver som oppsummeringer til lav innsats og kontraktsanalyse til høy innsats. Nøyaktigheten ble opprettholdt, gjennomsnittlig ventetid ble halvert, og månedlige kostnader ble redusert med en tredjedel.
Tilfelle 2 — JSON-garanti. Et operasjonsteam ba om klassifiseringsutdata med en melding som sa "bare gi JSON", men modellen ville av og til skrive "Her er resultatet:" og parseren ville krasje. Da jeg koblet til det konfigurerte utgangsskjemaet, returnerte utgangen gyldig JSON hver gang; parsefeil er tilbakestilt.
Tilfelle 3 — Aggressiv hurtigrekyl. En assistentmelding sa: "MÅ søke etter HVER SPØRSMÅL"; Modellen gjorde unødvendige søk selv etter enkle spørsmål som den allerede visste svaret på, og sakte ned og økte kostnadene. De lempet regelen til "Hvis svaret ikke er i kontekst, søk"; Unødvendige anrop ble redusert med 70 % og svarene ble akselerert.
Vanlige feil
- Innbygging av variable data i systemledeteksten: Bryter konsistensen og ugyldiggjør hurtigbufferen.
- Altfor aggressiv instruksjon: Overdreven utløsning og unødvendige kostnader i moderne modeller.
- Høy innsats i hver oppgave: Sløsing med enkle oppgaver; tilpasse innsats til oppgave.
- Ber om JSON kun via ledetekst: Den bryter av og til; hvis det er kritisk, bruk strukturert utdata.
- Ikke definere grense-/tvetydighetsatferd: Modellen fyller gapet med fabrikasjon (hallusinasjon).
- Gammel `temperatur`-vane: Moderne modeller godtar ikke dette; Veilede oppførsel med rask og innsats.
Deeper: Skrive forespørselen som en kontrakt
Erfarne team behandler systemmeldingen som en kontrakt, ikke en litterær tekst: klare klausuler, målbare regler, entydige grenser. Denne tilnærmingen har tre konkrete fordeler. Den første er konsistens: den samme inngangen gir lignende utgang til forskjellige tider. For det andre er testbarhet: du kan teste hvert element separat med en prøve. For det tredje er enkel vedlikehold: hvis en oppførsel er feil, vet du hvilken vare du skal erstatte.
En god praksis er å gå foran med positive eksempler. I stedet for å gi en liste over "ikke gjør dette", er det mye mer effektivt i moderne modeller å gi et eksempel som sier "dette er nøyaktig hvordan den ønskede utgangen ser ut". For eksempel, i en klassifisering, vil det å legge til én eller to eksempler av den forventede JSON-en i ledeteksten redusere formateringsfeil betydelig.
En annen kraftig teknikk er å skrive usikkerhetsatferden eksplisitt. En klausul som "Hvis usikker, ikke gjett; si "utilstrekkelig data"" undertrykker modellens tendens til å fylle ut tomrommet med fabrikasjon (hallusinasjon). Denne enkeltsetningen avlaster verifikasjonslaget, som vi vil dekke i enhet 11: når modellen allerede har flagget usikkerhet, blir det lettere å føre til menneskelig validering.
Til slutt, vurder innsats og spør sammen. Ved høy innsats utforsker modellen mer og utfører noen ganger uønsket "ekstra arbeid" (unødvendig forklaring, tilleggsforslag). Å si "bare gi ønsket resultat, ikke legg til flere kommentarer" i ledeteksten oppveier denne bivirkningen av høy innsats.
Oppsummert
Systemmeldingen er det permanente direktivet til modellen: den definerer rollen, omfanget, formatet, uklarhetsadferd og konfidensialitet. I moderne modeller er atferd drevet av adaptiv tenkning og innsatsparametere snarere enn temperatur; Å tilpasse innsatsen til oppgaven styrer kvalitet og kostnader samtidig. Du sikrer utdataene med max_tokens, stoppmatriser og strukturert utdata.
Søknadsoppgave
Velg en oppgave. (1) Skriv en systemmelding med fem komponenter (rolle, omfang, format, tvetydighet, konfidensialitet). (2) Oppgi hvilket innsatsnivå du ville valgt for denne oppgaven og hvorfor. (3) Hvis utdataene skal være strukturert, skisser du et lite JSON-skjema. (4) Sjekk om det er et altfor aggressivt mønster i forespørselen, og myk den opp.
sjekkliste
- [ ] Jeg kan nevne fem komponenter i en god systemforespørsel.
- [ ] Jeg kan forklare hva adaptiv tenkning og innsatsparametere gjør.
- [ ] Jeg kan balansere kvalitet/kostnad ved å justere innsats i henhold til oppgaven.
- [ ] Jeg vet hvorfor strukturert utdata er tryggere enn å be om JSON via ledetekst.
- [ ] Jeg kan gjenkjenne risikoen i moderne modeller med altfor aggressive instruksjoner.