Voitot:
- Osaa suunnitella kuinka järjestelmäkehote ohjaa mallia koko keskustelun ajan
- Ymmärtää mukautuvan ajattelun ja työparametrien roolin ja kustannusvaikutuksen
- toteuttaa ulostulon ohjaimia, kuten max_tokens, stop-sekvenssit ja strukturoidut lähdöt
Saman mallin kaksi eri tuotetta voivat käyttäytyä täysin eri tavalla. Ero ei ole itse mallissa, vaan järjestelmäkehotteessa ja sille annetuissa parametreissa. Järjestelmäkehote on mallin "työsopimus" ja parametrit ovat "työasetukset". Tässä osiossa opit suunnittelemaan tehokkaan järjestelmäkehotteen, mitä nykyaikaisten mallien ajattelu- ja ponnisteluasetukset tekevät ja kuinka ohjata tulosteen muotoa/pituutta. Asettamalla nämä asetukset oikein voit hallita sekä laatua että kustannuksia samanaikaisesti.
Järjestelmäkehote: Mallin pysyvä ohje
Järjestelmäkehote on korkean tason ohje, joka pätee koko keskustelun ajan. Nämä säännöt pysyvät voimassa riippumatta siitä, mitä käyttäjä kirjoittaa. Hyvä järjestelmäkehote sisältää seuraavat osat:
- Rooli/identiteetti: Kuka on malli? ("Olet yrityksen tukiassistentti.")
- Laajuus ja raja: Mitä se tekee ja mitä se ei tee? ("Perustuu vain toimitettuun käytäntöasiakirjaan.")
- Muotosäännöt: Miltä tulosteen tulee näyttää? ("Enintään 3 artikkelia, virallinen kieli.")
- Käyttäytyminen epävarmuudessa: Mitä tehdä, kun on epävarma? ("Jos tietoa ei ole, tee se, ohjaa asianomaiseen yksikköön.")
- Turvallisuus/tietosuoja: Mitä ei halua/ei halua? ("Pyydä henkilötietoja.")
Vihje: Pidä järjestelmäkehote kunnossa. Älä upota tietoja, jotka muuttuvat jokaisen pyynnön yhteydessä (nykyinen päivämäärä, käyttäjätunnus, istunnon tunnus). Tämä sekä rikkoo johdonmukaisuuden että mitätöi kehotteen välimuistin yksikössä 6. Laita muuttujan tiedot käyttäjäviestiin.
Liian aggressiivinen ohjeloukku
Nykyaikaiset mallit noudattavat ohjeita erittäin tarkasti. Vanhemmissa malleissa toimineet aggressiiviset lauseet, kuten "TÄYTYY", "AINA", "TEhdä tämä" jne., johtavat nykyään yliliipaisuun: malli kutsuu agenttia, kun sitä ei tarvita tai toimii tarpeettoman pitkään. Pehmennä sääntöä: "PITÄÄ käyttää hakutyökalua" sijaan "Jos vastaus ei ole keskustelussa, käytä hakutyökalua" on tarkempi.
Mallin parametrit: Ajatus ja vaiva
Klassisilla LLM:illä oli lämpötilaparametri: pienempi arvo tuotti spesifisemmän/yhdenmukaisemman tuloksen, korkeampi arvo tuotti vaihtelevampaa/luovaa tulosta. Nykyaikaiset mallit (kuten Opus 4.8, Sonnet 5) korvaavat tämän lähestymistavan kahdella tehokkaammalla mekanismilla eivätkä enää hyväksy näytteenottoparametreja, kuten lämpötilaa.
- Mukautuva ajattelu: Malli pohtii askel askeleelta "päässään" ennen vastaamista. Malli päättää, kuinka paljon ajatella tehtävän vaikeuden perusteella. Parantaa merkittävästi tarkkuutta monimutkaisissa, monivaiheisissa ongelmissa; Hän ajattelee vähemmän välttääkseen tarpeettomia viivytyksiä yksinkertaisissa kysymyksissä.
- Effort: Korkean tason nuppi, joka säätää kuinka syvälle malli sukeltaa tehtävään ja kuinka monta rahaketta se käyttää yhteensä. Tyypilliset tasot: matala, keskitaso, korkea ja korkeampi. Suuri työ voi parantaa laatua, mutta se lisää myös viivettä ja kustannuksia; Pieni vaiva tuo nopeutta ja säästöjä.
Asetus
Mitä tekee
milloin
Ajattelee pois/vähän vaivaa
Nopea, halpa, pinnallinen
Yksinkertainen luokittelu, lyhyt vastaus, viiveherkät tehtävät
Mukautuva ajattelu + keskipitkä vaiva
Tasapainoinen laatu/hinta
Useimmat yleiskäyttöiset tehtävät
Mukautuva ajattelu + kova ponnistus
korkein tarkkuus
Monimutkainen päättely, koodaus, pitkän kantaman agenttityö
Varoitus: "Maksimaalinen ponnistus mitä tahansa" -refleksi lisää kustannuksia. Säädä ponnistelu tehtävään; Yksinkertaisissa tehtävissä pieni vaiva antaa usein saman tarkan tuloksen paljon halvemmalla. Mene korkealle siellä, missä tarvitaan kriittistä tarkkuutta.
Lähtöohjaus: muoto, pituus, rakenne
Parametrien lisäksi ohjaat myös itse lähtöä:
- max_tokens: Lähdön kova katto (1. ja 3. yksikkö).
- Pysäytä jaksot: Mallin pysäyttäminen, kun se näkee tietyn merkkijonon. Hyödyllinen strukturoidun tuotannon rajapisteiden asettamiseen.
- Strukturoitu tulos: Pakota mallin vastaus antamaasi JSON-skeeman mukaiseksi. Se varmistaa, että tulos on ohjelmallisesti jäsennettävä ja kelvollinen. Se on luotettavampaa kuin sanomalla "vain palauta JSON" kehotteen kanssa.
{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "additionalProperties": false, "properties": { "category": { "type": "string", "enum": ["lasku", "tekninen", {other "turnaus"]:} "string", "enum": ["matala", "keskikokoinen", "korkea"] } }, "pakollinen": ["luokka", "kiireellinen"] } } }}
Kopioitavissa olevat järjestelmäkehotemallit
# YritystukiassistenttiOlet yrityksen tukiassistentti. - Luota vain toimitettuun käytäntöasiakirjaan; Jos sitä ei ole asiakirjassa, sano "Minulla ei ole näitä tietoja". - Anna muodollinen ja selkeä vastaus enintään 3 lauseella. - Pyydä henkilötietoja (TC ID numero, kortin numero) äläkä toista niitä vastauksessasi. - Jos et ole varma, älä arvaa.
# Strukturoitu tulosten pakottava luokitinOlet kysynnän luokittelija. Syöte on asiakkaan viesti. Palauta vain pyydetyt kentät, älä kirjoita kommentteja. Jos et ole varma, käytä "muu".
# Analyytikko, jolla on määritelty käyttäytyminen epävarmuudessa. Olet dataanalyytikko. Tee vain todennettavissa olevia päätelmiä toimitetusta taulukosta. Älä koskaan tee johtopäätöstä, jota tiedoissa ei ole. Jos päätelmä on epäselvä, kirjoita "tiedot riittämättömät".
# Sisällön kirjoittaja sävy- ja pituussäädöllä Olet sisällön kirjoittaja. Käytä lämmintä mutta ammattimaista sävyä. Rajoita jokainen teksti 120 sanaan tai vähemmän. Vältä kliseistä markkinointikieltä.
Heikko kehote / Vahva kehote
# HEIKKOOle avulias ja anna hyviä vastauksia. Tee parhaasi.
# STRONGRooli: Teknisen tuen asiantuntija.Soveltamisala: Vain tuoteopas.Muoto: Vaiheittainen, numeroitu luettelo, enintään 5 vaihetta.Raja: Suosittele ratkaisua, joka ei ole oppaassa; Sano "En löytänyt sitä käsikirjasta". Yksityisyys: Älä toista käyttäjän vastauksessa jakamaa sarjanumeroa.
Tehokas versio; Se määrittelee roolin, laajuuden, muodon, rajat ja luottamuksellisuuden erikseen. Tulostuksen johdonmukaisuus tulee suoraan tästä selkeydestä.
Kolme minikoteloa
Tapaus 1 — Kustannusten alentaminen ponnistuksen säädön avulla. Yksi joukkue suoritti kaikki kutsunsa suurella ponnistelulla + ajattelulla; Jopa yksinkertaiset sähköpostitiivistelmät olivat kalliita ja hitaita tuottaa. He antoivat yksinkertaisia tehtäviä, kuten yhteenvedot vähäisille vaivoille ja sopimusanalyysit suurille vaivoille. Tarkkuus säilyi, keskimääräinen latenssi puolitettiin ja kuukausikustannukset pienenivät kolmanneksella.
Tapaus 2 – JSON-takuu. Operaatiotiimi pyysi luokittelutulosta kehotteessa "anna vain JSON", mutta malli kirjoitti toisinaan "Tässä on tulos:" ja jäsentäjä kaatui. Kun liitin määritetyn lähtöskeeman, lähtö palautti kelvollisen JSON:n joka kerta; jäsennysvirheet on nollattu.
Tapaus 3 – Aggressiivinen nopea rekyyli. Avustajakehote sanoi: "TÄYTYY etsiä JOKAINEN KYSYMYS"; Malli teki tarpeettomia hakuja yksinkertaisistakin kysymyksistä, joihin se tiesi vastauksen, mikä hidasti ja nosti kustannuksia. He lievensivät sääntöä "Jos vastaus ei ole kontekstissa, etsi"; Tarpeettomat puhelut vähenivät 70 % ja vastaukset nopeutuivat.
Yleisiä virheitä
- Muuttujien tietojen upottaminen järjestelmäkehotteeseen: rikkoo johdonmukaisuuden ja mitätöi välimuistin.
- Liian aggressiivinen ohje: Liiallinen laukaisu ja tarpeettomat kustannukset nykyaikaisissa malleissa.
- Suuri vaiva jokaisessa tehtävässä: Hukkaa yksinkertaisissa tehtävissä; sovittaa ponnistelut tehtävään.
- JSON:n pyytäminen vain kehotteen kautta: Se katkeaa ajoittain; jos kriittinen, käytä strukturoitua tulosta.
- Ei määrittele rajaa/epäselvyyttä: Malli täyttää aukon fiktiolla (hallusinaatioilla).
- Vanha "lämpötila" tapa: Nykyaikaiset mallit eivät hyväksy tätä; Ohjaa käyttäytymistä nopeasti ja vaivalla.
Deeper: kehotteen kirjoittaminen kuin sopimus
Kokeneet tiimit kohtelevat järjestelmäkehotetta kuin sopimusta, eivät kirjallista tekstiä: selkeät lausekkeet, mitattavissa olevat säännöt, yksiselitteiset rajat. Tällä lähestymistavalla on kolme konkreettista etua. Ensimmäinen on johdonmukaisuus: sama tulo antaa samanlaisen tulosteen eri aikoina. Toinen on testattavuus: voit testata jokaista tuotetta erikseen näytteellä. Kolmanneksi huollon helppous: jos käyttäytyminen on väärin, tiedät, mikä esine on vaihdettava.
Hyvä käytäntö on johtaa positiivisilla esimerkeillä. Sen sijaan, että tarjottaisiin luettelo "älä tee tätä", nykyaikaisissa malleissa on paljon tehokkaampaa antaa esimerkki, jossa sanotaan "tältä näyttää juuri haluttu tulos". Esimerkiksi luokittimessa yhden tai kahden odotetun JSON-näytteen lisääminen kehotteeseen vähentää muotoiluvirheitä merkittävästi.
Toinen tehokas tekniikka on kirjoittaa epävarmuuskäyttäytyminen eksplisiittisesti. Lause, kuten "Jos olet epävarma, älä arvaa; sano 'riittämätöntä tietoa'" estää mallin taipumuksen täyttää tyhjää kohtaa tekaistulla (hallusinaatiolla). Tämä yksittäinen lause kuormittaa varmennuskerroksen, jota käsittelemme yksikössä 11: kun malli on jo ilmoittanut epävarmuudesta, on helpompi johtaa ihmisen validointiin.
Lopuksi, harkitse yhdessä vaivaa ja kehotusta. Suurella vaivalla malli tutkii enemmän ja tekee joskus ei-toivottua "ylimääräistä työtä" (turha selitys, lisäehdotus). Sanonta "anna vain haluttu tulos, älä lisää muita kommentteja" kompensoi tätä suuren vaivannäön sivuvaikutusta.
Yhteenvetona
Järjestelmäkehote on mallin pysyvä ohje: se määrittelee roolin, laajuuden, muodon, epäselvyyden ja luottamuksellisuuden. Nykyaikaisissa malleissa käyttäytymistä ohjaavat adaptiivinen ajattelu ja ponnisteluparametrit lämpötilan sijaan; Työn sovittaminen tehtävään hallitsee laatua ja kustannuksia samanaikaisesti. Suojaat lähdön max_tokens-, stop-taulukoilla ja strukturoidulla lähdöllä.
Sovellustehtävä
Valitse tehtävä. (1) Kirjoita järjestelmäkehote, jossa on viisi osaa (rooli, laajuus, muoto, moniselitteisyys, luottamuksellisuus). (2) Kerro, minkä tason vaivaa valitsisit tähän tehtävään ja miksi. (3) Jos tulosteen pitäisi olla jäsennelty, piirrä pieni JSON-skeema. (4) Tarkista, onko kehotteessa liian aggressiivinen kuvio ja pehmennä sitä.
tarkistuslista
- [ ] Voin nimetä viisi hyvän järjestelmäkehotteen osaa.
- [ ] Osaan selittää, mitä mukautuva ajattelu ja ponnistusparametrit tekevät.
- [ ] Pystyn tasapainottamaan laatua ja kustannuksia säätämällä työtä tehtävän mukaan.
- [ ] Tiedän, miksi strukturoitu tulostus on turvallisempaa kuin JSON-pyynnön pyytäminen kehotteen kautta.
- [ ] Tunnistan riskin nykyaikaisissa malleissa liian aggressiivisista ohjeista.