Tuotantokehotteiden suunnittelu: järjestelmä-, kehittäjä- ja käyttäjäkerrokset

Prototyyppi voi alkaa koodiin kirjoitetusta merkkijonosta. Tuotantopaine alkaa, kun kehote tarvitsee omistajan, katselmoinnin, palautuksen aiempaan versioon, tietojen käsittelysäännöt, useita ominaisuuksia tai kieliversioita tai mitattavaa toimintaa. Tämä voi tapahtua jo ennen julkaisua, eikä sille ole yleispätevää aikataulua.

Haluat muuttaa yhtä ohjeiden osaa mutta et muita. Haluat eri asiakastasoille erilaista toimintaa. Haluat A/B-testata versioita. Haluat palauttaa aiemman version, kun jokin rikkoutuu. Haluat tietää, milloin kehotetta muutettiin viimeksi ja miksi.

Tuotantokehotteen suunnittelu tekee nämä valinnat nimenomaisiksi. Kehoteteksti on yksi artefakti hallinnoidussa julkaisu- ja ajonaikaisessa järjestelmässä.

Tämä artikkeli selittää omistajuuden ja muutostahdin kolmen toimituksellisen kerroksen avulla ja osoittaa sitten, miten ne sovitetaan palveluntarjoajien API:ihin. Kyse on viitesuunnitelmasta, ei yleispätevästä siirtomuodosta. Tietoturvarajan osalta seuraa OWASPin kehoteinjektio-ohjetta: ohjeiden erottaminen tiedoista auttaa tarkistuksessa ja arvioinnissa, mutta mikään kehotemallipohja ei muodosta valtuutus- tai eristysrajaa.

Tuotantokehotteisiin liittyvässä työssä on kaksi erillistä artefaktia: uudelleenkäytettävät mallipohjat ja pyyntökohtaiset tiedot. Versioi mallipohjat kuten koodi. Käsittele muodostettuja kehotteita ja mallien vastauksia arkaluonteisina lokeina aina, kun ne sisältävät käyttäjä-, asiakas- tai sisäisiä tietoja.

Kolme toimituksellista kerrosta sovitettuna API:in

Tämä suunnitelma erottaa kolme toimituksellista näkökulmaa:

Järjestelmäkerros. Suhteellisen vakaa toiminta, identiteetti ja rajoitteet. Omistajana on ominaisuuksien rajat ylittävästä tekoälytoiminnasta vastuussa oleva tiimi.

Kehittäjäkerros. Ominaisuuskohtaiset ohjeet, työkalujen käyttökäytäntö ja tuotosvaatimukset. Omistajana on ominaisuudesta vastaava tiimi.

Käyttäjä- ja ajonaikainen kerros. Käyttäjän pyyntö sekä dynaaminen konteksti, kuten valtuutetut asiakastiedot, keskusteluhistoria ja haettu tieto. Se muodostetaan pyynnölle tai keskusteluvuorolle.

Omistajuuden, vakaan käytännön, ominaisuusohjeiden ja ajonaikaisten tietojen sekoittaminen voi vaikeuttaa muutoksen tarkistamista, arviointia, välimuistiin tallentamista ja palauttamista. Erota ne, kun se parantaa hallintaa. Älä pakota kolmea API-kenttää, jos palveluntarjoajan tai sovelluksen esitystapa on erilainen.

Ohjeiden auktoriteetti ja datan sijoittelu liittyvät toisiinsa, mutta ovat eri asioita. Luottamushierarkia kertoo, mikä ohje voittaa viestien ollessa ristiriidassa. Datan sijoittelu kertoo, missä sovellus kuljettaa dynaamista tai epäluotettavaa sisältöä. Haetun tekstin sijoittaminen käyttäjä- tai kontekstikenttään ei tee siitä valtuutettua, täsmällistä tai turvallista. Pakota identiteetti, asiakasympäristön pääsy, datan minimointi, työkalujen oikeudet ja tulosteen validointi mallin ulkopuolella.

Kerrosten erottaminen on perusta:

┌─────────────────────────────────────┐
│ Järjestelmäkerros (suhteellisen vakaa) │  Identiteetti, toiminta, käytännön tarkoitus
├─────────────────────────────────────┤
│ Kehittäjäkehote (per ominaisuus)    │  Ominaisuusohjeet, työkalut, muoto
├─────────────────────────────────────┤
│ Käyttäjäkehote (per kutsu)          │  Käyttäjän pyyntö, konteksti, keskustelu
└─────────────────────────────────────┘

Palveluntarjoajien API:t ilmaisevat ohje- ja sisältörajat eri tavoin:

• OpenAI: käytä Responses API:ssa sovelluksen ohjeisiin ylimmän tason instructions-parametria tai developer-viestiä ja käyttäjän syötteeseen user-viestiä. Älä oleta edellisen vastauksen ohjeiden siirtyvän mukana, kun hallitset monivuoroista keskustelua.
• Anthropic: sovita suunnitelma Clauden Messages API:in, sen järjestelmäohjemekanismiin, viestirooleihin ja työkalumäärittelyihin. Tuettu roolien sijoittelu voi vaihdella mallin ja alustan mukaan.
• Gemini: sovita suunnitelma system_instruction-kenttään ja pyyntösisältöön sekä valitun API:n erilliseen työkalukokoonpanoon.

Käytä palveluntarjoajakohtaista sovitinta ja integraatiotestejä. Älä kopioi roolinimiä API:sta toiseen ja oleta yhtäläistä ensisijaisuutta, pysyvyyttä tai työkalukäyttäytymistä.

Kerros 1: järjestelmäkehote

Tässä toimituksellisessa mallissa järjestelmäkerros määrittää ominaisuuksien rajat ylittävän roolin ja toiminnan. Pyri muuttamaan sitä ominaisuusohjeita harvemmin, mutta versioi ja arvioi se aina muutoksen yhteydessä.

Hyvä järjestelmäkehote käsittelee:

Identiteetin. Ilmaistu rooli. ”Olet [yrityksen] tekoälyavustaja, joka on erikoistunut [alaan].”

Äänensävyn ja tyylin. Miltä sen pitäisi kuulostaa. Käytä täsmällisiä ominaisuuksia epämääräisten kuvausten sijaan.

Vaaditut toimintarajoitteet. Mitä mallin pitäisi kieltäytyä tekemästä, siirtää tarkistukseen, ilmoittaa tai muotoilla. Pakota tietoturva, käyttöoikeudet ja peruuttamattomien toimien hallinta sovelluskoodissa ja myöhemmissä järjestelmissä pelkän tekstin sijaan.

Toimintamallit. Miten se käsittelee tavallisia tilanteita, kuten kieltäytymistä, eskalointia ja epävarmuutta.

Turvallisuuden ja vaatimustenmukaisuuden. Pakolliset ilmoitukset, sääntelyä koskevat säännöt ja sisältökäytännöt.

Mitä sen EI pitäisi sisältää:

• Ominaisuuskohtaisia ohjeita (”tee myyntisähköposteissa X”).
• Dynaamista kontekstia (”käyttäjän tilaushistoria on…”).
• Työkalukuvauksia, jotka kuuluvat muualle.
• Usein muuttuvia asioita.

Järjestelmäkehotteen pitäisi olla vain niin pitkä kuin arvioitu toiminta edellyttää. Lyhyt kehote voi riittää, ja pitkästäkin voi puuttua ratkaisevia sääntöjä. Mittaa ohjeiden ristiriitoja, tehtävän laatua, viivettä ja tokenikustannusta sen sijaan, että tavoittelisit tiettyä sanamäärää.

Viitemallipohja:

Olet [name], [company / context] tekoälyavustaja.

## Roolisi
[2-3 sentences on what you do]

## Äänensävy ja tyyli
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Älä [anti-pattern 1]
- Älä [anti-pattern 2]

## Ehdottomat rajoitteet
- Älä koskaan [hard rule 1]
- Älä koskaan [hard rule 2]
- Aina [hard rule 3]

## Miten käsittelet epävarmuutta
- Jos et tiedä jotakin asiatietoa: sano se suoraan.
- Jos käyttäjä pyytää jotakin rajauksen ulkopuolelta: kerro, missä voit auttaa.
- Jos pyyntö voi aiheuttaa haittaa: kieltäydy ja perustele miksi.

## Muotovaatimukset
- Oletuksena pelkkää tekstiä
- Käytä markdownia, kun näytät koodia tai rakenteista dataa
- Ole ytimekäs; älä täytä vastauksia turhalla

Tämä voi olla kehotesuunnitelman vakaa, käytäntöjä kantava osa. Varmista arvioinnilla ja telemetrialla, että sen tarkoitettu toiminta säilyy ominaisuusohjeiden, pitkien kontekstien, työkalutulosten ja vihamielisten syötteiden yhteydessä.

Kerros 2: kehittäjäkehote

Kehittäjäkehote on ominaisuuskohtainen. Eri ominaisuuksilla on eri kehittäjäkehotteet.

Tiivistysominaisuuden kehittäjäkehote:

Tehtävä: laadi tiivistelmä alla olevasta asiakirjasta.

Vaatimukset:
- 3-5 luetelmakohtaa
- Jokainen kohta on yksi kokonainen virke
- Keskity faktoihin ja konkreettisiin väitteisiin, älä vaikutelmiin
- Jos asiakirjassa on lukuja, sisällytä tärkeimmät niistä
- Älä käytä markkinointikieltä äläkä spekuloi
- Jos asiakirja on jostakin tärkeästä epäselvä, mainitse se

Muoto: pelkät markdown-luetelmakohdat, ei alkusanoja.

Koodikatselmointiominaisuuden kehittäjäkehote:

Tehtävä: katselmoi alla oleva koodiero.

Tuota JSON-objekti, jossa on:
- summary: 1-2 virkkeen yleiskuva muutoksesta
- concerns: taulukko täsmällisiä havaintoja (kussakin: file, line, severity, description)
- suggestions: taulukko parannuksia (kussakin: file, line, suggestion)
- approved: totuusarvo (true, jos estäviä havaintoja ei ole)

Vakavuustasot:
- "blocker": on korjattava ennen yhdistämistä
- "warning": pitäisi korjata, mutta ei estä yhdistämistä
- "nit": tyylillinen, valinnainen

Keskity näihin:
- Logiikkavirheet
- Tietoturvaongelmat
- Suorituskykyongelmat
- Puuttuva testikattavuus
- Epäselvä nimeäminen tai rakenne

Ohita nämä:
- Muotoilu (hoituu muotoilijalla)
- Subjektiiviset tyylimieltymykset

Jokaisella ominaisuudella on oma kehittäjäkehotteensa. Ne tallennetaan, versioidaan ja arvioidaan erikseen.

Kerros 3: käyttäjäkehote

Käyttäjäkerros on dynaaminen. Se sisältää tavallisesti:

Käyttäjän varsinaisen pyynnön. ”Tiivistä tämä asiakirja.”

Järjestelmän hakeman kontekstin. RAG-järjestelmän asiakirjat, asiakashistorian ja keskusteluhistorian.

Kutsukohtaiset muuttujat. Käyttäjän nimen, aikavyöhykkeen, kielivalinnan ja asiakastason.

Kerros muodostetaan ohjelmallisesti kutsun aikana. Rakenne näyttää tavallisesti tältä:

{conversation_history_summary}

{retrieved_context}

Käyttäjän pyyntö: {user_query}

Lisäkonteksti:
- Käyttäjän nimi: {name}
- Käyttäjän aikavyöhyke: {timezone}
- Käyttäjän taso: {tier}

Tarkka rakenne riippuu ominaisuudesta ja palveluntarjoajasta. Pidä muuttuvat, käyttäjäkohtaiset ja haetut tiedot poissa uudelleenkäytettävistä ohjemallipohjista, ellei API-sopimus vaadi muuta sijoittelua. Säilytä datan sijainnista riippumatta alkuperä, valtuutus, minimointi, rajaus ja validointi.

Mallipohjien hallinta

Tuotantokehotteiden kokoaminen hyötyy usein mallipohjista. Suora merkkijonojen yhdistäminen on vaikeampi tarkistaa ja testata, kun haarat, datakentät ja ominaisuudet lisääntyvät.

Yksinkertainen mallipohjajärjestelmä:

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Document to summarize:
$document

User's specific instructions: $user_instructions
""")

prompt = SUMMARIZE_TEMPLATE.substitute(
    conversation_summary=summarize_conversation(history),
    document=document_text,
    user_instructions=user_query,
)

Kehittyneempi vaihtoehto on ehtoja ja osamallipohjia tukeva mallipohjakirjasto, kuten Jinja2 tai Handlebars.

{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}

{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}

User's request: {{ user_query }}

Mallipohjat pitävät kehotteen rakenteen yhdenmukaisena, mahdollistavat ehdollisen logiikan ja helpottavat käyttäjän syötteen rajaamista tai suojaamista. Ne eivät itsessään estä kehoteinjektiota. Käsittele epäluotettavaa tekstiä tietona, älä koskaan ohjeena.

Valitse hallinnoitu ensisijainen lähde

Käsittele tuotantokehotteita versioituina julkaisuartefakteina. Ensisijainen lähde voi olla repositorio, omistettu rekisteri tai palvelu tai muokkauskäyttöliittymän sisältävä hallittu tuote. Valitse hallinta- ja operointitarpeiden perusteella, älä siksi, että yksi tallennustapa sopisi kaikille tiimeille.

Koodina hallittaville kehotteille repositorion prompts/-hakemisto ja oma tiedosto jokaiselle kehotteelle on selkeä lähtökohta:

prompts/
  system/
    main.txt
    customer-support.txt
    code-assistant.txt
  features/
    summarize.txt
    classify-ticket.txt
    generate-email.txt
  templates/
    base.j2

Jokaisella tiedostolla voi olla oma muutoshistoriansa ja PR-katselmointi, ja tuotantojulkaisut viittaavat tunnettuun koodiversioon.

Miksi tämä on tärkeää:

• Erojen näkyvyys. Kun kehote muuttuu, ero näkyy PR:ssä ja katselmoijat näkevät täsmälleen, mitä muuttui.
• Palautus. Kun muutos rikkoo jotakin, aiemman version voi palauttaa.
• Historia. Kysymyksiin ”milloin hyvityskäytäntöä muutettiin kehotteessa?” ja ”miksi tämä kappale on tässä?” voi vastata git blame -historian avulla.
• Työkalut. Lintterit, validaattorit ja arviointikokonaisuudet integroituvat kaikki tiedostopohjaisiin kehotteisiin.

Vertaa tärkeimpiä vaihtoehtoja nimenomaisesti:

Koodin sisäiset merkkijonot toimivat pienessä prototyypissä, mutta niitä on vaikeampi löytää ja julkaista erikseen. Muokkauskäyttöliittymä voi olla sopiva, kun sen oikeudet, tarkistus, alkuperä, julkaisu ja palautus vastaavat työnkulun riskiä. Keskusteluikkunoista kopioitujen kehotteiden tulee kulkea saman tarkistus-, puhdistus- ja arviointipolun kautta kuin muidenkin ehdokkaiden.

Älä tallenna versionhallintaan tuotantokeskusteluja, asiakastietueita, tukipyyntöjä, sisäisiä asiakirjoja tai arkaluonteisia muuttujia sisältäviä muodostettuja kehotteita. Lähdekoodin versionhallintaan kuuluvat uudelleenkäytettävät mallipohjat, testiaineistot ja puhdistetut arviointiesimerkit. Todelliset jäljitykset kuuluvat havainnoitavuustietovarastoon, jossa on säilytysajat, käyttöoikeuksien hallinta ja peittäminen.

Ajonaikaiset rekisterit ja palvelut

Kun kehotejulkaisujen on edettävä eri tahdissa kuin sovellusjulkaisujen tai valtuutetut toimittajat tarvitsevat hallitun käyttöliittymän, pelkkä repositorio ei välttämättä tarjoa oikeaa työnkulkua. Rekisteri tai palvelu voi valita hyväksytyn version ajon aikana.

Ratkaisumalli on tietokanta tai palvelu, joka tallentaa kehoteversiot metatietoineen.

prompt = prompt_service.get(
    name="summarize",
    version="v3",
    locale="en",
    user_tier="enterprise",
)

Palvelun tulee ylläpitää:

• Jokaisen kehotteen nykyisiä ja aiempia versioita.
• Metatietoja siitä, milloin, kuka ja miksi version lisäsi.
• Jokaiseen versioon liitettyjä arviointituloksia.
• Mahdollisuutta palauttaa aiempi versio.

Tallennusmoottori on vain yksi osa suunnitelmaa. Vertaa roolipohjaista pääsynhallintaa, tarkastushistoriaa, todennettua ajonaikaista pääsyä, ympäristöstä toiseen edistämistä, julkaisun johdonmukaisuutta, palautusta, vientimahdollisuuksia, salausta, datankäsittelyä, saatavuutta ja operointikustannuksia. Pieni tietokanta riittää vain, jos sitä ympäröivät hallintakeinot täyttävät vaatimukset.

Määritä, kuka saa luonnostella, tarkistaa, hyväksyä, julkaista, palauttaa ja lukea muodostettuja kehotteita. Muokkausoikeus ei tarkoita tuotantojulkaisuoikeutta. Arkaluonteiset työnkulut voivat vaatia erillisiä rooleja, peitettyjä esikatseluja, kahden henkilön hyväksyntää tai käyttöliittymää, joka ei koskaan näytä todellisia asiakastietoja.

Arvioinneilla rajatut muutokset

Käyttäjätuloksiin, työkalujen käyttöön, datankäsittelyyn, käytäntöjen noudattamiseen tai myöhempiin päätöksiin vaikuttavat kehotemuutokset on katselmoitava ja arvioitava riskiin suhteutetusti ennen käyttöönottoa. Vähäriskinen tekstimuutos voi tarvita pienen regressiojoukon. Maksuun, tiliin tai säänneltyyn päätökseen vaikuttava kehote tarvitsee vahvemmat offline-tapaukset, vihamieliset testit, hyväksynnän ja vaiheittaisen julkaisun. Määritä hätätilapolku, jossa on rajattu julkaisu, valvonta, hyväksyntä ja palautus, sen sijaan että portti ohitettaisiin huomaamatta.

Prosessi:

1. Insinööri tai muu asiantuntija luonnostelee kehotemuutoksen.
2. Muutos ajetaan arviointikokonaisuutta vasten.
3. Arviointitulokset katselmoidaan muutoksen rinnalla.
4. Jos arvioinnit läpäistään ilman regressioita ja mielellään parannuksin, muutos voidaan hyväksyä.
5. Hyväksytyt muutokset julkaistaan.
6. Julkaisun jälkeinen valvonta havaitsee arvioinneilta huomaamatta jääneet ongelmat.

Säilytä olennaisille kehotteille edustava arviointijoukko ja aja vakaat automatisoitavat tarkistukset CI:ssä, kun niiden signaali on riittävän luotettava muutoksen portittamiseen. Käytä asiantuntija- tai ihmistarkistusta, kun hyväksymiskriteeriä ei voi pelkistää automaattiseksi pistemääräksi. Kirjaa testattu asia, kynnysarvo, tarkistaja ja jäännösepävarmuus.

Portti ei todista oikeellisuutta. Se tekee julkaisupäätöksestä tarkistettavan ja antaa tiimille vertailutason käyttöönoton jälkeisten regressioiden tunnistamiseen.

Käytännöllinen julkaisun tarkistuslista

Vaadi lyhyt tarkistuslista ennen kehoteversion tuotantoon vientiä:

Artikkeliin linkitetty tarkistuslista muuttaa nämä tarkistukset toistettavaksi julkaisukatselmoinniksi.

A/B-testaus tuotannossa

Verkkokokeiluun sopivissa kehotteissa vaiheittainen vertailu nykyiseen versioon voi tuoda offline-arviointien lisäksi todellisen käytön signaalia. Älä käytä todellista liikennettä ensimmäisenä turvallisuustestinä äläkä altista ihmisiä olennaisesti riskialttiimmalle vaihtoehdolle vain datan keräämiseksi.

Havainnollistava malli, ei oletusjako:

• 95 % liikenteestä käyttää tuotantokehotetta v3.
• 5 % saa uuden ehdokkaan v4.
• Pidä mallin pääsy, työkalujen käyttöoikeudet ja toimintorajat enintään hyväksytyn tuotantorajan laajuisina.
• Mittaa tehtävässä onnistumista, turvallisuus- ja käytäntövirheitä, käyttäjäpalautetta, jatkomittareita sekä tarkistettuja arviointituloksia kelvollisesta liikenteestä.
• Määritä ennen aloitusta vähimmäisotos, pysäytysehdot, omistaja ja yhden vaiheen palautus.
• Päätä riittävän näytön jälkeen, laajennetaanko, korjataanko vai pysäytetäänkö ehdokas.

Toimitusmekanismeja ovat omat ominaisuusliput, julkaisukokoonpano, hyväksytty kehoterekisteri tai mukautettu reititys.

Varoitukset:

• A/B-testaus havaitsee vain mitattavat signaalit. Ilman käyttäjäpalautetta tai jatkovaiheiden konversiomittareita se kertoo vain vähän.
• Tilastollinen merkitsevyys vaatii riittävän volyymin. A/B-testaus on vaikeaa pienen volyymin ominaisuuksissa.
• Samanaikaiset kokeet voivat vaikuttaa toisiinsa ja sekoittaa syy-yhteyden arviointia. Hallitse päällekkäisyyksiä tarkoituksellisesti.
• Huomioi tuotetta, väestöä ja lainkäyttöaluetta koskevat ilmoitus-, suostumus-, poissulkemis- ja tarkistusvelvoitteet. Suuren vaikutuksen tai peruuttamattomat toiminnot vaativat tavallisesti liikennejakoa vahvemman hyväksynnän ja peruttavuuden.

Kehotteiden havainnoitavuus

Määritä jokaiselle tuotantotyönkululle tietosuojan säilyttävä telemetria. Tallenna olennaisiin tuloksiin vaikuttavista kutsuista riittävä osa seuraavista tiedoista, jotta julkaistu toiminta voidaan tunnistaa ja virheet palauttaa:

• Käytetty kehotemallipohja eli nimi ja versio.
• Korvatut muuttujat käyttäen sallittujen nimien luetteloa ja tarvittaessa peitettyjä arvoja.
• Lopullinen muodostettu kehote vain, jos käytäntö sallii sen. Muussa tapauksessa tallenna peitetty, otokseen valittu tai tiivisteenä esitetty versio.
• Mallin vastaus, joka peitetään tai poimitaan otoksena arkaluonteisissa työnkuluissa.
• Viive, tokenit ja kustannus.
• Jatkosignaalit, kuten käyttäjäpalaute ja onnistumismittarit.

Tavoitteena on vastata siihen, mikä versio suoritettiin, mitä valtuutettua näyttöä se sai, minkä validoidun tulosteen se tuotti, mitkä työkalut tai käytännöt liittyivät tapaukseen ja mitä myöhemmin tapahtui. Älä lokita piilotettua päättelyä näiden faktojen korvikkeena.

Tallennuspaikkana voi olla tietokantataulu tai havainnoitavuustyökalu. Kaiken lokittamisesta syntyy todellisia kustannuksia (kutsumäärä × tokenimäärä × tallennustila). Kaiken lokittaminen aiheuttaa myös todellisen tietosuojariskin. Päätä työnkulkukohtaisesti, mitä kenttiä on turvallista tallentaa, peitä salaisuudet ja henkilötiedot oletusarvoisesti ja pidä säilytysajat lyhyinä, ellei vaatimustenmukaisuus edellytä pidempää säilytystä. Jotkin tiimit käyttävät otantaa.

Aseta tarkistusrytmi ja otantamenetelmä määrän, riskin, muutosnopeuden, häiriöiden ja oikeudellisten rajoitteiden perusteella. Tarkista peitettyjä tai muuten hyväksyttyjä jäljityksiä, sisällytä tunnetut reunatapaukset ja lisää vahvistetut virheet arviointeihin. Viikoittainen otos voi sopia yhteen työnkulkuun ja olla toisessa sopimaton tai riittämätön.

Kehotteiden antimallit

Vältä seuraavia malleja:

Antimalli 1: omistajaton monikäyttökehote. Suuri järjestelmäkehote, joka yhdistää toisiinsa liittymättömiä ominaisuuksia, käytäntöjä, esimerkkejä ja ajonaikaisia oletuksia, voi olla vaikea tarkistaa, arvioida ja palauttaa. Pituus itsessään ei ole vika, vaan mittaamaton monimutkaisuus.

Korjaus: erota komponentit tarvittaessa omistajuuden ja muutosrajan perusteella, poista päällekkäiset tai vanhentuneet ohjeet ja vertaa uudistettua suunnitelmaa edustavissa arvioinneissa.

Antimalli 2: merkkijonojen yhdistäminen koodissa.

prompt = "You are helpful. " + (
    "The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...

Hauras ja vaikealukuinen. Merkkijonojen yhdistäminen myös vaikeuttaa ohjeiden ja tietojen rajojen tarkastamista, mutta samojen arvojen siirtäminen mallipohjaan ei neutraloi haitallisia ohjeita.

Korjaus: käytä mallipohjajärjestelmää.

Antimalli 3: sama kehote liian moneen käyttötapaukseen.

Yksi sähköpostien luonnosteluun, koodikatselmointiin, asiakastukeen ja tutkimukseen käytettävä ”yleisavustajan” kehote voi piilottaa tehtäväkohtaiset hyväksymiskriteerit ja omistajuuden.

Korjaus: käytä yhteisen järjestelmäkehotteen päällä ominaisuuskohtaisia kehittäjäkehotteita.

Antimalli 4: kovakoodatut kehotteet.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "You are a helpful assistant..."},
        {"role": "user", "content": query}
    ]
)

Kehote on haudattu koodiin. Sitä ei voi muokata ilman julkaisua, A/B-testata tai versioida itsenäisesti.

Korjaus: siirrä kehote tiedostoon tai palveluun.

Antimalli 5: ei arviointikattavuutta.

Ominaisuus julkaistaan kehotteella, jota ei ole koskaan testattu järjestelmällisesti. Laatu perustuu tuntumaan, eikä ajautumista voi havaita.

Korjaus: lisää riskiin suhteutettu arviointikattavuus olennaiselle toiminnalle, myös virhe- ja siirtotapauksille.

Antimalli 6: tietojen sekoittaminen järjestelmäkehotteeseen.

Olet avustaja Johnille, premium-asiakkaalle, joka liittyi vuonna 2023, asuu Tallinnassa ja jolla on 47 avointa tukipyyntöä.

Nyt uudelleenkäytettävä ohjealkuosa muuttuu jokaisella kutsulla, mikä voi heikentää välimuistin uudelleenkäyttöä ja hämärtää käytännön sekä asiakastiedon eroa.

Korjaus: kuljeta dynaamiset tiedot palveluntarjoajan ajonaikaisen syötteen tai kontekstin mekanismissa alkuperä-, valtuutus- ja minimointitietoineen. Älä päättele luotettavuutta viestin roolista.

Antimalli 7: ohjeet on haudattu keskelle.

Auta käyttäjää hänen pyynnössään. Ole kohtelias. Muotoile tuotos JSON-muotoon. Älä käytä markdownia. Käyttäjä kysyy hinnoittelusta, joten ole varovainen lukujen mainitsemisessa. Tuotoksen pitäisi olla 1-2 virkettä. Auta häntä nyt.

Kriittisiä vaatimuksia on vaikeampi löytää tarkistuksessa, ja ne voivat olla ristiriidassa viereisen tekstin kanssa.

Korjaus: ryhmittele kriittiset ohjeet selkeästi nimettyyn lohkoon, ilmaise kukin sääntö kerran ja testaa valitun mallin kyky noudattaa niitä edustavissa pitkän kontekstin ja vihamielisen syötteen tapauksissa.

Tavallisten ominaisuuksien erityismallit

Muutama ominaisuuskohtainen malli:

Luokittelu

Tehtävä: luokittele seuraava teksti yhteen näistä luokista:
- billing: maksu, hyvitys, tilaus
- technical: bugi, virhe, integraatio-ongelma
- account: kirjautuminen, salasana, profiilimuutokset
- feature_request: uusia toiminnallisuuksia koskevat pyynnöt
- complaint: yleinen tyytymättömyys ilman täsmällistä korjattavaa ongelmaa

Tuota JSON-objekti: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Luokiteltava teksti:
{text}

Mallit: määritelmillä varustetut luetellut luokat, rakenteinen tuotos sekä luottamus- ja perustelukentät.

Tietojen poiminta

Tehtävä: poimi alla olevasta asiakirjasta rakenteinen data.

Skeema:
- vendor_name: laskun lähettänyt yritys
- invoice_number: sellaisena kuin se on painettu asiakirjaan
- date: ISO 8601 -muodossa
- line_items: taulukko muotoa {description, quantity, unit_price, total}
- subtotal, tax, total: lukuja

Säännöt:
- Jos kenttää ei ole, käytä arvoa null
- Lukujen on oltava numeerisia, ei merkkijonoja
- Epäselvissä tapauksissa aseta "needs_review": true ja selitä

Asiakirja:
{document}

Mallit: yksiselitteinen skeema, tyyppiodotukset, puuttuvien tietojen käsittely ja epäselvien tapausten eskalointi.

Tyylin mukainen generointi

Tehtävä: kirjoita {format} aiheesta {topic} kohdeyleisölle {audience}.

Tyyli:
- {Täsmällinen tyylipiirre 1}
- {Täsmällinen tyylipiirre 2}
- Vältä: {antimalli 1}, {antimalli 2}

Rajoitteet:
- Pituus: {N} sanaa
- Sisällytä: {vaaditut osat}
- Jätä pois: {kielletyt osat}

Äänensävyn malli:
[Provide a sample of the desired voice]

Tuotos: pelkkä {format}, ilman alku- tai loppusanoja.

Mallit: täsmälliset tyylipiirteet yleisten sijaan, yksiselitteiset rajoitteet ja äänensävyn sitominen esimerkkitekstiin.

Agenttisilmukka

Käytettävissäsi ovat seuraavat työkalut:
{tool_descriptions}

Jokaisella vuorolla:
1. Mieti, mitä sinun pitää tehdä.
2. Päätä, tarvitsetko työkalua. Jos tarvitset, kutsu sitä.
3. Kun olet nähnyt tuloksen, päätä, tarvitsetko lisää työkaluja vai voitko vastata.
4. Kun sinulla on riittävästi tietoa, tuota lopullinen vastaus.

Rajoitteet:
- Enintään 5 työkalukutsua pyyntöä kohden.
- Jos et 5 kutsun jälkeen saa tehtävää valmiiksi, selitä mitä puuttuu.
- Älä koskaan keksi työkalujen nimiä tai argumentteja.
- Tarkista työkalujen tulokset ennen kuin toimit niiden perusteella.

Käyttäjän pyyntö:
{user_query}

Mallit: vaiheistettu työkalujen käyttö, työkalubudjetti, nimenomainen validointi ja rajattu virheenkäsittely.

Tiimin merkitys

Tuotantokehotteisiin osallistuu tavallisesti useita ihmisiä:

• Insinöörit yhdistävät kehotteet järjestelmään, ylläpitävät mallipohjia ja hallitsevat julkaisuja.
• Tuotetiimi määrittää, mitä kehotteilla pitäisi saavuttaa.
• Sisältö- ja markkinointitiimi omistaa äänensävyä ja tyyliä koskevat ohjeet.
• Toimiala-asiantuntijat tietävät, mikä on oikein tietyissä käyttötapauksissa, kuten oikeudellisessa kielessä tai lääketieteellisissä termeissä.

Hyödyllinen malli on koodikatselmointia vastaava kehotekatselmointi, jossa jokaiselle alalle valitaan oikeat katselmoijat. Sisältötiimi katselmoi äänensävyn muutokset, insinöörit logiikkamuutokset ja toimiala-asiantuntija alakohtaisen sisällön.

Arkaluonteisissa oikeudellisissa, lääketieteellisissä ja taloudellisissa käyttötapauksissa kehotteet voivat vaatia muodollisen katselmoinnin ja hyväksynnän. Rakenna prosessi sen mukaisesti.

Vaiheportteihin perustuva kehotteiden kypsytyssuunnitelma

Tiimeille, jotka siirtyvät ”kehotteet ovat merkkijonoja koodissa” -tilasta ”kehotteet ovat hallittua infrastruktuuria” -tilaan:

Vaihe 1: perusta.

• Inventoi kehotteet ja kehotteita kokoava koodi, jotka vaikuttavat toimintaan olennaisesti.
• Määritä ohjeiden auktoriteettimalli, ajonaikaisen datan raja, omistajat ja palveluntarjoajakohtainen sovitus.
• Valitse hallinnoitu ensisijainen lähde ja julkaisutyönkulkuun sopiva mallipohjatapa.
• Ota käyttöön tietosuojan säilyttävä telemetria, joka tunnistaa julkaistun version ja tuloksen säilyttämättä tarpeetonta arkaluonteista sisältöä.

Vaihe 2: arviointi.

• Rakenna arviointikokonaisuudet ensin riskialtteimmille ja eniten käytetyille kehotteille.
• Aja olennaisille kehotemuutoksille edustavat arvioinnit ja käytä tarvittaessa toimiala-arviointia.
• Sijoita vakaat automaattiset tarkistukset CI:hin ja pidä ei-automatisoitavat hyväksymispäätökset näkyvinä tarkistustietueessa.

Vaihe 3: operointi.

• Toteuta kehotteiden versiointi valitussa repositoriossa, rekisterissä tai palvelussa.
• Lisää vaiheittainen julkaisu- ja pysäytysmekanismi. Käytä A/B-testausta vain siihen soveltuvassa työnkulussa.
• Rakenna valvonta työnkulun edellyttämille laatu-, turvallisuus-, käytäntö-, viive-, kustannus- ja jatkosignaaleille.
• Luo kehotemuutosten katselmointiprosessi.

Älä lupaa lopputulosta kalenterin perusteella. Poistu vaiheistetusta jaksosta vasta, kun testit osoittavat kaikkien kehotteiden löytyneen, kriittisten muutosten olevan versioituja ja portitettuja, palautuksen toimivan, telemetrian yksilöivän julkaistun version ja omistajien osaavan harjoitella häiriötilanteen käsittelyä.

Kehotteet infrastruktuurina

Tuotantokehotteet voidaan tallentaa merkkijonoina, mutta ne toimivat versioituina järjestelmäkomponentteina, joita ympäröivät kokoamisen, arvioinnin, julkaisun, pääsyn ja havainnoitavuuden hallintakeinot.

Ohjehierarkia määrittää auktoriteetin, mutta ei suojaa ajonaikaista dataa tai työkalutoimintoja. Mallipohjat voivat vähentää kokoamisvirheitä, mutta eivät estä kehoteinjektiota. Hallinnoitu ensisijainen lähde tarjoaa versiohistorian. Riskiin suhteutetut arvioinnit tukevat julkaisupäätöksiä, ja telemetria testaa tarkoitetun toiminnan säilymistä arviointijoukon ulkopuolella.

Vaadittu kurinalaisuus riippuu riskistä ja laajuudesta, mutta jokainen pois jätetty hallintakeino tarvitsee kirjallisen perustelun. Julkaisuväitteiden pitäisi osoittaa, millainen versiointi, arviointi, vaiheittainen julkaisu, palautus ja telemetria todella toteutettiin.

Tavoiteltu hallittavuus on hypoteesi, kunnes arvioinnit ja tuotantotelemetria osoittavat valitun mallin, kehoteversion, datapolun, työkalujen ja käytäntöjen toimivan hyväksymisrajojen sisällä. Säilytä näyttö julkaisun mukana, tutki virheet versiokohtaisesti ja pidä palautus toimivana.

Aloita pienimmästä arkkitehtuurista, joka tekee omistajuuden, auktoriteetin, datankäsittelyn, arvioinnin, julkaisun, palautuksen ja näytön nimenomaisiksi.