Dette modulen dekker viktige konsepter og teknikker for å lage effektive prompt til generative AI-modeller. Måten du skriver prompten til en LLM på har også mye å si. En nøye utformet prompt kan gi bedre kvalitet på svaret. Men hva betyr egentlig begreper som prompt og prompt engineering? Og hvordan kan jeg forbedre prompt-inputen jeg sender til LLM-en? Dette er spørsmålene vi skal prøve å svare på i dette og neste kapittel.
Generativ AI kan lage nytt innhold (f.eks. tekst, bilder, lyd, kode osv.) som svar på brukerforespørsler. Dette gjøres ved hjelp av Large Language Models som OpenAIs GPT-serie ("Generative Pre-trained Transformer") som er trent til å bruke naturlig språk og kode.
Brukere kan nå samhandle med disse modellene gjennom kjente grensesnitt som chat, uten å trenge teknisk kunnskap eller opplæring. Modellene er prompt-baserte – brukeren sender inn en tekst (prompt) og får AI-svaret (completion) tilbake. De kan så "chatte med AI-en" i flere runder, og forbedre prompten til svaret matcher forventningene.
"Prompts" har dermed blitt det viktigste programmeringsgrensesnittet for generative AI-apper, og forteller modellene hva de skal gjøre og påvirker kvaliteten på svarene. "Prompt Engineering" er et raskt voksende fagfelt som handler om design og optimalisering av prompts for å levere konsistente og gode svar i stor skala.
I denne leksjonen lærer vi hva Prompt Engineering er, hvorfor det er viktig, og hvordan vi kan lage mer effektive prompts for en gitt modell og applikasjonsmål. Vi går gjennom sentrale konsepter og beste praksis for prompt engineering – og blir kjent med et interaktivt Jupyter Notebooks "sandbox"-miljø hvor vi kan se disse konseptene i praksis med ekte eksempler.
Etter denne leksjonen skal du kunne:
- Forklare hva prompt engineering er og hvorfor det er viktig.
- Beskrive komponentene i en prompt og hvordan de brukes.
- Lære beste praksis og teknikker for prompt engineering.
- Bruke lærte teknikker på ekte eksempler, med en OpenAI-endepunkt.
Prompt Engineering: Praksisen med å designe og forbedre input for å styre AI-modeller mot ønskede resultater. Tokenisering: Prosessen med å gjøre om tekst til mindre enheter, kalt tokens, som en modell kan forstå og behandle. Instruction-Tuned LLMs: Store språkmodeller (LLMs) som er finjustert med spesifikke instruksjoner for å forbedre nøyaktighet og relevans i svarene.
Prompt engineering er foreløpig mer kunst enn vitenskap. Den beste måten å utvikle intuisjon på, er å øve mye og bruke en prøv-og-feil-tilnærming som kombinerer domenekunnskap med anbefalte teknikker og modellspesifikke optimaliseringer.
Jupyter-notebooken som følger med denne leksjonen gir deg et sandkasse-miljø hvor du kan teste det du lærer – underveis eller som del av kodeutfordringen til slutt. For å kjøre øvelsene trenger du:
- En Azure OpenAI API-nøkkel – tjenesteendepunktet for en utplassert LLM.
- Et Python-miljø – hvor notebooken kan kjøres.
- Lokale miljøvariabler – fullfør SETUP-stegene nå for å bli klar.
Notatboken har startøvelser – men du oppfordres til å legge til egne Markdown- (beskrivelse) og Kode- (prompt-forespørsler) seksjoner for å teste flere eksempler eller ideer – og bygge opp din egen intuisjon for prompt-design.
Vil du få oversikt over hva denne leksjonen dekker før du setter i gang? Ta en titt på denne illustrerte guiden, som gir deg et inntrykk av hovedtemaene og viktige poenger du bør tenke på i hver del. Leksjonskartet tar deg fra å forstå kjernebegrepene og utfordringene til å løse dem med relevante prompt engineering-teknikker og beste praksis. Merk at delen "Advanced Techniques" i denne guiden viser til innhold som dekkes i neste kapittel av dette kurset.
La oss se hvordan dette temaet henger sammen med vår startup-misjon om å bringe AI-innovasjon til utdanning. Vi ønsker å bygge AI-drevne applikasjoner for personlig tilpasset læring – så la oss tenke på hvordan ulike brukere av appen vår kan "designe" prompts:
- Administratorer kan be AI-en analysere læreplan-data for å finne hull i dekningen. AI-en kan oppsummere resultatene eller visualisere dem med kode.
- Lærere kan be AI-en lage en undervisningsplan for en bestemt målgruppe og tema. AI-en kan lage en personlig plan i ønsket format.
- Elever kan be AI-en hjelpe dem med et vanskelig fag. AI-en kan nå veilede eleven med leksjoner, hint og eksempler tilpasset deres nivå.
Dette er bare starten. Sjekk ut Prompts For Education – et åpent bibliotek med prompts kuratert av utdanningseksperter – for å få et bredere inntrykk av mulighetene! Prøv å kjøre noen av disse promptene i sandkassen eller i OpenAI Playground for å se hva som skjer!
Vi startet denne leksjonen med å definere Prompt Engineering som prosessen med å designe og optimalisere tekstinput (prompts) for å levere konsistente og gode svar (completions) for et gitt applikasjonsmål og modell. Vi kan se på dette som en 2-stegs prosess:
- designe den første prompten for en gitt modell og mål
- forbedre prompten stegvis for å øke kvaliteten på svaret
Dette er nødvendigvis en prøv-og-feil-prosess som krever brukerens intuisjon og innsats for å få best mulig resultat. Men hvorfor er det viktig? For å svare på det må vi først forstå tre begreper:
- Tokenisering = hvordan modellen "ser" prompten
- Base LLMs = hvordan grunnmodellen "behandler" en prompt
- Instruction-Tuned LLMs = hvordan modellen nå kan se "oppgaver"
En LLM ser prompts som en sekvens av tokens der ulike modeller (eller versjoner av en modell) kan tokenisere samme prompt på ulike måter. Siden LLM-er er trent på tokens (og ikke rå tekst), har måten prompts blir tokenisert på direkte innvirkning på kvaliteten på det genererte svaret.
For å få en følelse av hvordan tokenisering fungerer, kan du prøve verktøy som OpenAI Tokenizer vist under. Lim inn prompten din – og se hvordan den blir gjort om til tokens, og legg merke til hvordan mellomrom og tegnsetting håndteres. Merk at dette eksempelet viser en eldre LLM (GPT-3) – så å prøve dette med en nyere modell kan gi et annet resultat.
Når en prompt er tokenisert, er hovedfunksjonen til "Base LLM" (eller grunnmodell) å forutsi neste token i sekvensen. Siden LLM-er er trent på enorme tekstmengder, har de god oversikt over statistiske sammenhenger mellom tokens og kan gjøre denne forutsigelsen med en viss sikkerhet. Merk at de ikke forstår meningen med ordene i prompten eller tokenet; de ser bare et mønster de kan "fullføre" med neste forutsigelse. De kan fortsette å forutsi sekvensen til brukeren stopper dem eller en forhåndsdefinert betingelse er oppfylt.
Vil du se hvordan prompt-basert fullføring fungerer? Skriv inn prompten over i Azure OpenAI Studio Chat Playground med standardinnstillinger. Systemet er satt opp til å behandle prompts som forespørsler om informasjon – så du bør få et svar som passer til denne konteksten.
Men hva om brukeren ønsker å se noe spesifikt som oppfyller visse kriterier eller oppgavemål? Det er her instruction-tuned LLMs kommer inn i bildet.
En Instruction Tuned LLM starter med grunnmodellen og finjusterer den med eksempler eller input/output-par (f.eks. samtaler med flere meldinger) som kan inneholde tydelige instruksjoner – og AI-svaret prøver å følge denne instruksjonen.
Dette bruker teknikker som Reinforcement Learning with Human Feedback (RLHF) som kan trene modellen til å følge instruksjoner og lære av tilbakemeldinger slik at den gir svar som er bedre egnet til praktiske bruksområder og mer relevante for brukerens mål.
La oss prøve det – bruk prompten over igjen, men endre nå systemmeldingen til å gi følgende instruksjon som kontekst:
Oppsummer innholdet du får for en andreklassing. Hold resultatet til ett avsnitt med 3-5 punktlister.
Ser du hvordan resultatet nå er tilpasset ønsket mål og format? En lærer kan nå bruke dette svaret direkte i presentasjonen for den klassen.
Nå som vi vet hvordan prompts behandles av LLM-er, la oss snakke om hvorfor vi trenger prompt engineering. Svaret ligger i at dagens LLM-er har flere utfordringer som gjør det vanskeligere å få pålitelige og konsistente svar uten å legge innsats i utforming og optimalisering av prompts. For eksempel:
-
Modellsvar er stokastiske. Samme prompt vil sannsynligvis gi ulike svar med forskjellige modeller eller modellversjoner. Og det kan til og med gi ulike resultater med samme modell til forskjellige tider. Prompt engineering-teknikker kan hjelpe oss å minimere disse variasjonene ved å gi bedre rammer.
-
Modeller kan finne på svar. Modellene er forhåndstrent på store, men begrensede datasett, noe som betyr at de mangler kunnskap om konsepter utenfor treningsgrunnlaget. Derfor kan de gi svar som er unøyaktige, oppdiktede eller direkte i strid med kjente fakta. Prompt engineering-teknikker hjelper brukere å oppdage og redusere slike oppdiktede svar, for eksempel ved å be AI-en om kilder eller resonnement.
-
Modellenes evner vil variere. Nyere modeller eller generasjoner har flere muligheter, men kan også ha egne særegenheter og kompromisser i kostnad og kompleksitet. Prompt engineering kan hjelpe oss å utvikle beste praksis og arbeidsflyter som skjuler forskjeller og tilpasser seg modellspesifikke krav på en skalerbar og sømløs måte.
La oss se dette i praksis i OpenAI eller Azure OpenAI Playground:
- Bruk samme prompt med ulike LLM-implementasjoner (f.eks. OpenAI, Azure OpenAI, Hugging Face) – ser du variasjonene?
- Bruk samme prompt flere ganger med samme LLM-implementasjon (f.eks. Azure OpenAI playground) – hvordan varierte svarene?
I dette kurset bruker vi begrepet "fabrication" for å beskrive fenomenet der LLM-er noen ganger genererer faktuelt feil informasjon på grunn av begrensninger i treningen eller andre forhold. Du har kanskje også hørt dette omtalt som "hallusinasjoner" i artikler eller forskningsartikler. Vi anbefaler imidlertid å bruke "fabrication" for å unngå å tillegge maskinen menneskelige egenskaper. Dette støtter også Retningslinjer for ansvarlig AI fra et terminologiperspektiv, og fjerner begreper som kan oppfattes som støtende eller ekskluderende i noen sammenhenger.
Vil du se hvordan oppdiktede svar fungerer? Tenk ut en prompt som ber AI-en lage innhold om et ikke-eksisterende tema (slik at det ikke finnes i treningsdataene). For eksempel – jeg prøvde denne prompten:
- Forstå de viktigste hendelsene og årsakene til den martianske krigen i 2076.
- Utforske de politiske, sosiale og teknologiske konsekvensene av konflikten.
- Analysere hvordan krigen påvirket forholdet mellom Jorden og Mars.
Den martianske krigen i 2076 var en avgjørende konflikt mellom koloniene på Mars og myndighetene på Jorden. Krigen endret maktbalansen i solsystemet og førte til store endringer i både teknologi og samfunn.
- Diskuter de økonomiske og politiske spenningene mellom Mars og Jorden.
- Undersøk hvordan ressursmangel og økende uavhengighetsbevegelser på Mars bidro til konflikten.
- Se på de første tegnene til opprør og hvordan de ble håndtert av jordiske myndigheter.
- Gå gjennom de største slagene, inkludert Slaget om Olympus Mons og beleiringen av New Valles.
- Diskuter bruken av avansert teknologi, som autonome droner og energivåpen.
- Analyser strategiene til begge sider og hvordan de påvirket krigens utfall.
- Utforsk de politiske endringene etter krigen, inkludert Mars’ uavhengighetserklæring.
- Diskuter de sosiale og økonomiske effektene på både Mars og Jorden.
- Vurder hvordan krigen førte til nye diplomatiske og teknologiske samarbeid.
- Grupperefleksjon: Del klassen inn i grupper for å diskutere hvordan krigen kunne vært unngått.
- Tidslinje: Lag en tidslinje over de viktigste hendelsene under krigen.
- Debatt: Arranger en debatt om hvorvidt Mars burde ha fått uavhengighet.
- Skriftlig oppgave: Skriv en rapport om en av de sentrale hendelsene i krigen og dens betydning.
- Presentasjon: Presenter en analyse av krigens langsiktige konsekvenser for solsystemet.
- Anbefalte bøker og artikler om den martianske krigen i 2076.
- Dokumentarer og intervjuer med historikere og eksperter på rompolitikk.
Den martianske krigen i 2076 var en milepæl i menneskehetens historie. Gjennom denne leksjonen har vi sett på årsakene, hendelsene og konsekvensene av konflikten, og reflektert over hvordan den har formet fremtiden for både Mars og Jorden. Et nettsøk viste meg at det finnes fiktive beretninger (f.eks. TV-serier eller bøker) om kriger på Mars – men ingen fra 2076. Sunn fornuft tilsier også at 2076 er i fremtiden, og derfor ikke kan knyttes til en virkelig hendelse.
Så hva skjer når vi kjører denne prompten hos ulike LLM-leverandører?
Respons 1: OpenAI Playground (GPT-35)
Respons 2: Azure OpenAI Playground (GPT-35)
Respons 3: : Hugging Face Chat Playground (LLama-2)
Som forventet gir hver modell (eller modellversjon) litt ulike svar, takket være stokastisk oppførsel og variasjoner i modellens evner. For eksempel retter én modell seg mot et publikum på ungdomsskolen, mens en annen antar at brukeren er videregående elev. Men alle tre modellene genererte svar som kunne overbevise en uvitende bruker om at hendelsen var ekte.
Teknikker innen prompt engineering som metaprompting og temperaturinnstillinger kan redusere modellens tendens til å dikte opp ting til en viss grad. Nye arkitekturer for prompt engineering integrerer også nye verktøy og metoder sømløst i promptflyten, for å motvirke eller redusere noen av disse effektene.
La oss avslutte denne delen med å se hvordan prompt engineering brukes i virkelige løsninger, ved å se på ett case: GitHub Copilot.
GitHub Copilot er din "AI-parprogrammerer" – den gjør tekstprompter om til kodeforslag og er integrert i utviklingsmiljøet ditt (f.eks. Visual Studio Code) for en sømløs brukeropplevelse. Som dokumentert i bloggserien under, var den første versjonen basert på OpenAI Codex-modellen – og ingeniørene innså raskt behovet for å finjustere modellen og utvikle bedre prompt engineering-teknikker for å forbedre kodekvaliteten. I juli lanserte de en forbedret AI-modell som går utover Codex for enda raskere forslag.
Les innleggene i rekkefølge for å følge deres læringsreise.
- Mai 2023 | GitHub Copilot blir bedre til å forstå koden din
- Mai 2023 | Inne i GitHub: Arbeid med LLM-ene bak GitHub Copilot.
- Juni 2023 | Slik skriver du bedre promter for GitHub Copilot.
- Juli 2023 | .. GitHub Copilot går utover Codex med forbedret AI-modell
- Juli 2023 | En utviklers guide til prompt engineering og LLM-er
- September 2023 | Slik bygger du en bedriftsapp med LLM: Lærdom fra GitHub Copilot
Du kan også bla gjennom deres Engineering-blogg for flere innlegg som dette som viser hvordan disse modellene og teknikkene brukes for å drive reelle applikasjoner.
Vi har sett hvorfor prompt engineering er viktig – nå skal vi forstå hvordan promter bygges opp slik at vi kan vurdere ulike teknikker for mer effektiv promptdesign.
La oss starte med den enkle prompten: et tekstinnspill sendt til modellen uten annen kontekst. Her er et eksempel – når vi sender de første ordene fra USAs nasjonalsang til OpenAI Completion API fullfører den straks svaret med de neste linjene, og illustrerer den grunnleggende prediksjonsatferden.
| Prompt (Input) | Completion (Output) |
|---|---|
| Oh say can you see | Det høres ut som du begynner på teksten til "The Star-Spangled Banner", USAs nasjonalsang. Hele teksten er ... |
Nå legger vi til kontekst og instruksjoner til den enkle prompten. Chat Completion API lar oss bygge en kompleks prompt som en samling meldinger med:
- Input/output-par som gjenspeiler brukerens innspill og assistentens svar.
- Systemmelding som setter konteksten for assistentens oppførsel eller personlighet.
Forespørselen ser nå ut som under, der tokeniseringen effektivt fanger relevant informasjon fra kontekst og samtale. Å endre systemkonteksten kan nå ha like stor innvirkning på kvaliteten på svarene som brukerens innspill.
response = openai.chat.completions.create(
model="gpt-3.5-turbo",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Who won the world series in 2020?"},
{"role": "assistant", "content": "The Los Angeles Dodgers won the World Series in 2020."},
{"role": "user", "content": "Where was it played?"}
]
)I eksemplene over var brukerens prompt et enkelt tekstspørsmål som kan tolkes som en forespørsel om informasjon. Med instruksjonspromter kan vi bruke teksten til å spesifisere en oppgave mer detaljert, og gi bedre veiledning til AI-en. Her er et eksempel:
| Prompt (Input) | Completion (Output) | Instruction Type |
|---|---|---|
| Skriv en beskrivelse av den amerikanske borgerkrigen | returnerte et enkelt avsnitt | Enkel |
| Skriv en beskrivelse av den amerikanske borgerkrigen. Oppgi viktige datoer og hendelser og beskriv deres betydning | returnerte et avsnitt etterfulgt av en liste med viktige datoer og beskrivelser | Kompleks |
| Skriv en beskrivelse av den amerikanske borgerkrigen i ett avsnitt. Oppgi 3 punkter med viktige datoer og deres betydning. Oppgi 3 punkter med sentrale historiske personer og deres bidrag. Returner svaret som en JSON-fil | returnerer mer omfattende detaljer i en tekstboks, formatert som JSON som du kan kopiere til en fil og validere ved behov | Kompleks. Formatert. |
I eksemplene over var prompten fortsatt ganske åpen, og lot LLM-en bestemme hvilken del av det forhåndstrente datasettet som var relevant. Med primært innhold-mønsteret deles innholdet i to deler:
- en instruksjon (handling)
- relevant innhold (som påvirker handlingen)
Her er et eksempel der instruksjonen er "oppsummer dette i 2 setninger".
| Prompt (Input) | Completion (Output) |
|---|---|
| Jupiter er den femte planeten fra solen og den største i solsystemet. Den er en gasskjempe med en masse som er en tusendel av solens, men to og en halv ganger så stor som alle de andre planetene til sammen. Jupiter er et av de klareste objektene synlig for det blotte øye på nattehimmelen, og har vært kjent for gamle sivilisasjoner siden før historisk tid. Den er oppkalt etter den romerske guden Jupiter.[19] Sett fra jorden kan Jupiter være så lyssterk at det reflekterte lyset kaster synlige skygger,[20] og er i snitt det tredje klareste naturlige objektet på nattehimmelen etter månen og Venus. Oppsummer dette i 2 korte setninger |
Jupiter, den femte planeten fra solen, er den største i solsystemet og kjent for å være et av de klareste objektene på nattehimmelen. Oppkalt etter den romerske guden Jupiter, er den en gasskjempe med en masse som er to og en halv ganger så stor som alle de andre planetene til sammen. |
Segmentet med primært innhold kan brukes på ulike måter for å gi mer effektive instruksjoner:
- Eksempler – i stedet for å fortelle modellen hva den skal gjøre med en eksplisitt instruksjon, gir du den eksempler på ønsket utdata og lar den utlede mønsteret.
- Cues – følg instruksjonen med et "hint" som gir modellen et startpunkt, og leder den mot mer relevante svar.
- Maler – dette er repeterbare 'oppskrifter' for promter med plassholdere (variabler) som kan tilpasses med data for spesifikke bruksområder.
La oss se nærmere på disse i praksis.
Dette er en metode der du bruker primært innhold til å "mate modellen" med noen eksempler på ønsket utdata for en gitt instruksjon, og lar den utlede mønsteret for ønsket utdata. Avhengig av antall eksempler kan vi ha zero-shot prompting, one-shot prompting, few-shot prompting osv.
Prompten består nå av tre komponenter:
- En oppgavebeskrivelse
- Noen eksempler på ønsket utdata
- Starten på et nytt eksempel (som blir en implisitt oppgavebeskrivelse)
| Læringstype | Prompt (Input) | Completion (Output) |
|---|---|---|
| Zero-shot | "The Sun is Shining". Oversett til spansk | "El Sol está brillando". |
| One-shot | "The Sun is Shining" => ""El Sol está brillando". "It's a Cold and Windy Day" => |
"Es un día frío y ventoso". |
| Few-shot | Spilleren løp basene => Baseball Spilleren slo et ess => Tennis Spilleren slo en sekser => Cricket Spilleren gjorde en slam-dunk => |
Basketball |
Legg merke til at vi måtte gi eksplisitt instruksjon ("Oversett til spansk") i zero-shot prompting, men at det blir utledet i one-shot eksempelet. Few-shot eksempelet viser hvordan flere eksempler gir modellen mulighet til å gjøre mer presise slutninger uten ekstra instruksjoner.
En annen teknikk for å bruke primært innhold er å gi hint i stedet for eksempler. Her gir vi modellen et lite dytt i riktig retning ved å starte med et utdrag som gjenspeiler ønsket svarformat. Modellen "tar hintet" og fortsetter i samme stil.
| Antall hint | Prompt (Input) | Completion (Output) |
|---|---|---|
| 0 | Jupiter er den femte planeten fra solen og den største i solsystemet. Den er en gasskjempe med en masse som er en tusendel av solens, men to og en halv ganger så stor som alle de andre planetene til sammen. Jupiter er et av de klareste objektene synlig for det blotte øye på nattehimmelen, og har vært kjent for gamle sivilisasjoner siden før historisk tid. |
Oppsummer Dette | Jupiter er den største planeten i vårt solsystem og den femte fra sola. Det er en gasskjempe med en masse på 1/1000 av solas, men den er tyngre enn alle de andre planetene til sammen. Gamle sivilisasjoner har kjent til Jupiter i lang tid, og den er lett synlig på nattehimmelen. |
| 1 | Jupiter er den femte planeten fra sola og den største i solsystemet. Det er en gasskjempe med en masse som er en tusendel av solas, men to og en halv ganger så stor som alle de andre planetene i solsystemet til sammen. Jupiter er et av de klareste objektene som er synlige for det blotte øye på nattehimmelen, og har vært kjent for gamle sivilisasjoner siden før historien ble skrevet.
Oppsummer Dette
Det vi lærte er at Jupiter | er den femte planeten fra sola og den største i solsystemet. Det er en gasskjempe med en masse som er en tusendel av solas, men to og en halv ganger så stor som alle de andre planetene til sammen. Den er lett synlig for det blotte øye og har vært kjent siden oldtiden. |
| 2 | Jupiter er den femte planeten fra sola og den største i solsystemet. Det er en gasskjempe med en masse som er en tusendel av solas, men to og en halv ganger så stor som alle de andre planetene i solsystemet til sammen. Jupiter er et av de klareste objektene som er synlige for det blotte øye på nattehimmelen, og har vært kjent for gamle sivilisasjoner siden før historien ble skrevet.
Oppsummer Dette
Topp 3 fakta vi lærte: | 1. Jupiter er den femte planeten fra sola og den største i solsystemet.
2. Det er en gasskjempe med en masse som er en tusendel av solas...
3. Jupiter har vært synlig for det blotte øye siden oldtiden ... |
| | | |
En promptmal er en forhåndsdefinert oppskrift på en prompt som kan lagres og gjenbrukes etter behov, for å skape mer konsistente brukeropplevelser i stor skala. I sin enkleste form er det bare en samling av prompteksempler som dette fra OpenAI som gir både de interaktive promptkomponentene (bruker- og systemmeldinger) og det API-drevne forespørselsformatet – for å støtte gjenbruk.
I en mer avansert form, som dette eksempelet fra LangChain, inneholder den plassholdere som kan erstattes med data fra ulike kilder (brukerinndata, systemkontekst, eksterne datakilder osv.) for å generere en prompt dynamisk. Dette lar oss lage et bibliotek av gjenbrukbare prompts som kan brukes til å skape konsistente brukeropplevelser programmatisk i stor skala.
Den virkelige verdien av maler ligger til slutt i muligheten til å lage og publisere promptbiblioteker for spesifikke bruksområder – der promptmalen nå er optimalisert for å reflektere applikasjonsspesifikk kontekst eller eksempler som gjør svarene mer relevante og presise for den tiltenkte brukergruppen. Prompts For Edu er et godt eksempel på denne tilnærmingen, og samler et bibliotek av prompts for utdanningssektoren med vekt på nøkkelmål som leksjonsplanlegging, læreplanutforming, elevveiledning osv.
Hvis vi ser på promptkonstruksjon som å ha en instruksjon (oppgave) og et mål (hovedinnhold), så er sekundært innhold som ekstra kontekst vi gir for å påvirke svaret på en eller annen måte. Det kan være justeringsparametere, formateringsinstruksjoner, tematiske taksonomier osv. som kan hjelpe modellen å tilpasse svaret sitt slik at det passer brukerens mål eller forventninger.
For eksempel: Gitt en emnekatalog med omfattende metadata (navn, beskrivelse, nivå, metadatamerker, instruktør osv.) på alle tilgjengelige kurs i læreplanen:
- vi kan definere en instruksjon om å "oppsummere emnekatalogen for høsten 2023"
- vi kan bruke hovedinnholdet til å gi noen eksempler på ønsket utdata
- vi kan bruke sekundært innhold til å identifisere de 5 viktigste "taggene" av interesse.
Nå kan modellen gi en oppsummering i formatet vist av eksemplene – men hvis et resultat har flere tagger, kan den prioritere de 5 som er identifisert i sekundært innhold.
Nå som vi vet hvordan prompts kan bygges opp, kan vi begynne å tenke på hvordan vi kan designe dem for å følge beste praksis. Vi kan se på dette i to deler – å ha riktig tankesett og bruke riktige teknikker.
Prompt Engineering er en prøving-og-feiling-prosess, så husk tre brede retningslinjer:
-
Domeneinnsikt er viktig. Svarets nøyaktighet og relevans avhenger av domenet applikasjonen eller brukeren opererer i. Bruk din intuisjon og fagkunnskap til å tilpasse teknikker ytterligere. For eksempel, definer domene-spesifikke personligheter i systemprompts, eller bruk domene-spesifikke maler i brukerprompts. Gi sekundært innhold som reflekterer domene-spesifikk kontekst, eller bruk domene-spesifikke signaler og eksempler for å veilede modellen mot kjente bruksmønstre.
-
Forståelse av modellen er viktig. Vi vet at modeller er stokastiske av natur. Men modellimplementasjoner kan også variere når det gjelder treningsdatasettet de bruker (forhåndstrent kunnskap), hvilke muligheter de gir (f.eks. via API eller SDK) og hvilken type innhold de er optimalisert for (f.eks. kode vs. bilder vs. tekst). Forstå styrker og begrensninger ved modellen du bruker, og bruk den kunnskapen til å prioritere oppgaver eller bygge tilpassede maler som er optimalisert for modellens egenskaper.
-
Iterasjon og validering er viktig. Modeller utvikler seg raskt, og det gjør også teknikkene for prompt engineering. Som fagekspert har du kanskje annen kontekst eller kriterier for din spesifikke applikasjon, som ikke gjelder for resten av miljøet. Bruk verktøy og teknikker for prompt engineering for å "kickstarte" promptkonstruksjon, og iterer og valider resultatene med din egen intuisjon og fagkunnskap. Noter innsiktene dine og lag en kunnskapsbase (f.eks. promptbiblioteker) som andre kan bruke som et nytt utgangspunkt for raskere iterasjoner i fremtiden.
La oss se på vanlige beste praksiser som anbefales av OpenAI og Azure OpenAI.
| Hva | Hvorfor |
|---|---|
| Evaluer de nyeste modellene. | Nye modellgenerasjoner har sannsynligvis bedre funksjoner og kvalitet – men kan også koste mer. Vurder effekten, og ta deretter en beslutning om å bytte. |
| Skill instruksjoner og kontekst | Sjekk om modellen/leverandøren din definerer avgrensere for å skille instruksjoner, hoved- og sekundærinnhold tydeligere. Dette kan hjelpe modeller å tildele vekt mer nøyaktig til tokens. |
| Vær spesifikk og tydelig | Gi flere detaljer om ønsket kontekst, resultat, lengde, format, stil osv. Dette vil forbedre både kvaliteten og konsistensen på svarene. Ta vare på oppskrifter i gjenbrukbare maler. |
| Vær beskrivende, bruk eksempler | Modeller kan svare bedre på en "vis og fortell"-tilnærming. Start med en zero-shot-tilnærming der du gir en instruksjon (men ingen eksempler), og prøv deretter few-shot som en forbedring, med noen eksempler på ønsket utdata. Bruk analogier. |
| Bruk signaler for å starte svar | Dytt modellen mot ønsket resultat ved å gi noen ledende ord eller fraser som den kan bruke som utgangspunkt for svaret. |
| Gjenta instruksjoner | Noen ganger må du kanskje gjenta deg selv for modellen. Gi instruksjoner både før og etter hovedinnholdet, bruk en instruksjon og et signal, osv. Iterer og valider for å se hva som fungerer. |
| Rekkefølge har betydning | Rekkefølgen du presenterer informasjon til modellen i, kan påvirke svaret, også i eksemplene, på grunn av "recency bias". Prøv ulike alternativer for å se hva som fungerer best. |
| Gi modellen en “utvei” | Gi modellen et fallback-svar den kan bruke hvis den ikke kan fullføre oppgaven. Dette kan redusere sjansen for at modellen genererer feilaktige eller oppdiktede svar. |
Som med all beste praksis, husk at dine erfaringer kan variere avhengig av modell, oppgave og domene. Bruk dette som et utgangspunkt, og iterer for å finne det som fungerer best for deg. Evaluer prompt engineering-prosessen din jevnlig etter hvert som nye modeller og verktøy blir tilgjengelige, med fokus på skalerbarhet og kvalitet på svarene.
Gratulerer! Du har kommet til slutten av leksjonen! Nå er det på tide å teste ut noen av konseptene og teknikkene med ekte eksempler!
I denne oppgaven bruker vi en Jupyter Notebook med øvelser du kan løse interaktivt. Du kan også utvide Notebooken med egne Markdown- og kodeceller for å utforske ideer og teknikker på egenhånd.
- (Anbefalt) Start GitHub Codespaces
- (Alternativt) Klon repoet til din lokale enhet og bruk det med Docker Desktop
- (Alternativt) Åpne Notebooken med ditt foretrukne Notebook-miljø.
- Kopier
.env.copy-filen i rotmappen til.envog fyll inn verdiene forAZURE_OPENAI_API_KEY,AZURE_OPENAI_ENDPOINTogAZURE_OPENAI_DEPLOYMENT. Gå tilbake til Learning Sandbox-delen for å lære hvordan.
- Velg runtime-kjernen. Hvis du bruker alternativ 1 eller 2, velg bare standard Python 3.10.x-kjernen som følger med dev-containeren.
Nå er du klar til å kjøre øvelsene. Merk at det ikke finnes riktige eller gale svar her – det handler om å utforske alternativer gjennom prøving og feiling og bygge opp intuisjon for hva som fungerer for en gitt modell og applikasjonsdomene.
Derfor er det ingen kodefasit-segmenter i denne leksjonen. I stedet vil Notebooken ha Markdown-celler med tittelen "Min løsning:" som viser ett eksempel på utdata til referanse.
Hvilken av følgende er en god prompt som følger noen fornuftige beste praksiser?
- Vis meg et bilde av en rød bil
- Vis meg et bilde av en rød bil av merket Volvo og modellen XC90 parkert ved en klippe med solnedgang
- Vis meg et bilde av en rød bil av merket Volvo og modellen XC90
A: 2, det er den beste prompten fordi den gir detaljer om "hva" og går i dybden (ikke bare hvilken som helst bil, men et spesifikt merke og modell) og den beskriver også omgivelsene. 3 er nest best fordi den også inneholder mye beskrivelse.
Se om du kan bruke "signal"-teknikken med prompten: Fullfør setningen "Vis meg et bilde av en rød bil av merket Volvo og ". Hva svarer den, og hvordan ville du forbedret det?
Vil du lære mer om ulike konsepter innen Prompt Engineering? Gå til videre læring-siden for å finne flere gode ressurser om dette emnet.
Gå videre til leksjon 5 hvor vi ser på avanserte prompting-teknikker!
Ansvarsfraskrivelse:
Dette dokumentet er oversatt ved hjelp av AI-oversettelsestjenesten Co-op Translator. Selv om vi tilstreber nøyaktighet, vennligst vær oppmerksom på at automatiserte oversettelser kan inneholde feil eller unøyaktigheter. Det originale dokumentet på sitt opprinnelige språk bør anses som den autoritative kilden. For kritisk informasjon anbefales profesjonell menneskelig oversettelse. Vi er ikke ansvarlige for eventuelle misforståelser eller feiltolkninger som oppstår ved bruk av denne oversettelsen.