Dette modul dækker væsentlige begreber og teknikker til at skabe effektive prompts i generative AI-modeller. Måden, du skriver din prompt til en LLM på, har også betydning. En omhyggeligt udformet prompt kan opnå en bedre kvalitet i svaret. Men hvad betyder begreber som prompt og prompt engineering egentlig? Og hvordan forbedrer jeg det prompt-input, jeg sender til LLM’en? Det er de spørgsmål, vi vil forsøge at besvare i dette kapitel og det næste.
Generativ AI kan skabe nyt indhold (f.eks. tekst, billeder, lyd, kode osv.) som svar på brugerforespørgsler. Det opnås ved hjælp af Large Language Models som OpenAI’s GPT ("Generative Pre-trained Transformer") serie, der er trænet til at bruge naturligt sprog og kode.
Brugere kan nu interagere med disse modeller via velkendte paradigmer som chat, uden at have teknisk ekspertise eller træning. Modellerne er prompt-baserede – brugere sender en tekstinput (prompt) og får AI’s svar (completion) tilbage. De kan derefter "chatte med AI’en" iterativt i samtaler med flere runder, hvor de finjusterer deres prompt, indtil svaret matcher deres forventninger.
"Prompts" bliver nu den primære programmeringsgrænseflade for generative AI-apps, der fortæller modellerne, hvad de skal gøre, og påvirker kvaliteten af de returnerede svar. "Prompt Engineering" er et hurtigt voksende studieområde, der fokuserer på design og optimering af prompts for at levere konsistente og kvalitetsmæssige svar i stor skala.
I denne lektion lærer vi, hvad Prompt Engineering er, hvorfor det er vigtigt, og hvordan vi kan skabe mere effektive prompts til en given model og applikationsformål. Vi vil forstå kernebegreber og bedste praksis for prompt engineering – og lære om et interaktivt Jupyter Notebooks "sandbox"-miljø, hvor vi kan se disse koncepter anvendt på virkelige eksempler.
Ved slutningen af denne lektion vil vi kunne:
- Forklare, hvad prompt engineering er, og hvorfor det er vigtigt.
- Beskrive komponenterne i en prompt og hvordan de bruges.
- Lære bedste praksis og teknikker til prompt engineering.
- Anvende lærte teknikker på virkelige eksempler ved brug af en OpenAI-endpoint.
Prompt Engineering: Praksissen med at designe og forfine input for at styre AI-modeller mod at producere ønskede output.
Tokenization: Processen med at omdanne tekst til mindre enheder, kaldet tokens, som en model kan forstå og behandle.
Instruction-Tuned LLMs: Store sprogmodeller (LLMs), der er finjusteret med specifikke instruktioner for at forbedre deres svarnøjagtighed og relevans.
Prompt engineering er i øjeblikket mere en kunst end en videnskab. Den bedste måde at forbedre vores intuition for det på er at øve sig mere og anvende en trial-and-error tilgang, der kombinerer domæneekspertise med anbefalede teknikker og model-specifikke optimeringer.
Jupyter Notebook, der følger med denne lektion, giver et sandbox-miljø, hvor du kan prøve det, du lærer – løbende eller som en del af kodeudfordringen til sidst. For at kunne udføre øvelserne skal du bruge:
- En Azure OpenAI API-nøgle – service-endpoint for en implementeret LLM.
- Et Python-runtime – hvor Notebook’en kan køres.
- Lokale miljøvariabler – fuldfør SETUP trin nu for at være klar.
Notebook’en indeholder startøvelser – men du opfordres til at tilføje dine egne Markdown (beskrivelser) og Code (prompt-forespørgsler) sektioner for at prøve flere eksempler eller idéer – og opbygge din intuition for promptdesign.
Vil du have et overblik over, hvad denne lektion dækker, inden du går i gang? Tjek denne illustrerede guide, som giver dig en fornemmelse af hovedemnerne og de vigtigste pointer, du kan tænke over i hver del. Lektionens køreplan tager dig fra forståelsen af kernebegreber og udfordringer til at håndtere dem med relevante prompt engineering-teknikker og bedste praksis. Bemærk, at afsnittet "Avancerede teknikker" i denne guide henviser til indhold, der dækkes i det næste kapitel i dette kursusforløb.
Lad os nu tale om, hvordan dette emne relaterer sig til vores startup-mission om at bringe AI-innovation til uddannelse. Vi ønsker at bygge AI-drevne applikationer til personlig læring – så lad os tænke over, hvordan forskellige brugere af vores applikation kunne "designe" prompts:
- Administratorer kunne bede AI’en om at analysere læseplansdata for at identificere huller i dækningen. AI’en kan opsummere resultater eller visualisere dem med kode.
- Undervisere kunne bede AI’en om at generere en lektionsplan for en målgruppe og et emne. AI’en kan bygge den personlige plan i et specificeret format.
- Studerende kunne bede AI’en om at vejlede dem i et svært fag. AI’en kan nu guide elever med lektioner, hints og eksempler tilpasset deres niveau.
Det er kun toppen af isbjerget. Tjek Prompts For Education – et open source prompt-bibliotek kurateret af uddannelseseksperter – for at få en bredere fornemmelse af mulighederne! Prøv at køre nogle af disse prompts i sandboxen eller brug OpenAI Playground for at se, hvad der sker!
Vi startede denne lektion med at definere Prompt Engineering som processen med at designe og optimere tekstinput (prompts) for at levere konsistente og kvalitetsmæssige svar (completions) til et givent applikationsformål og model. Vi kan tænke på det som en 2-trins proces:
- designe den oprindelige prompt til en given model og formål
- forfine prompten iterativt for at forbedre kvaliteten af svaret
Dette er nødvendigvis en trial-and-error proces, der kræver brugerintuiton og indsats for at opnå optimale resultater. Så hvorfor er det vigtigt? For at besvare det spørgsmål skal vi først forstå tre begreber:
- Tokenization = hvordan modellen "ser" prompten
- Base LLMs = hvordan grundmodellen "behandler" en prompt
- Instruction-Tuned LLMs = hvordan modellen nu kan se "opgaver"
En LLM ser prompts som en sekvens af tokens, hvor forskellige modeller (eller versioner af en model) kan tokenisere den samme prompt på forskellige måder. Da LLM’er er trænet på tokens (og ikke rå tekst), har måden, prompts tokeniseres på, direkte indflydelse på kvaliteten af det genererede svar.
For at få en fornemmelse af, hvordan tokenization fungerer, kan du prøve værktøjer som OpenAI Tokenizer vist nedenfor. Kopiér din prompt ind – og se, hvordan den bliver omdannet til tokens, med særlig opmærksomhed på, hvordan mellemrum og tegnsætning håndteres. Bemærk, at dette eksempel viser en ældre LLM (GPT-3) – så prøv med en nyere model for at se, om resultatet bliver anderledes.
Når en prompt er tokeniseret, er hovedfunktionen for "Base LLM" (eller grundmodellen) at forudsige det næste token i sekvensen. Da LLM’er er trænet på enorme tekstdatasæt, har de en god fornemmelse af de statistiske sammenhænge mellem tokens og kan lave denne forudsigelse med en vis sikkerhed. Bemærk, at de ikke forstår meningen med ordene i prompten eller tokenet; de ser blot et mønster, de kan "fuldføre" med deres næste forudsigelse. De kan fortsætte med at forudsige sekvensen, indtil brugeren afbryder eller en forudbestemt betingelse opfyldes.
Vil du se, hvordan prompt-baseret completion fungerer? Indtast ovenstående prompt i Azure OpenAI Studio Chat Playground med standardindstillingerne. Systemet er konfigureret til at behandle prompts som informationsforespørgsler – så du bør se et svar, der opfylder denne kontekst.
Men hvad hvis brugeren ønskede at se noget specifikt, der opfylder visse kriterier eller et opgaveformål? Her kommer instruction-tuned LLM’er ind i billedet.
En Instruction Tuned LLM starter med grundmodellen og finjusterer den med eksempler eller input/output-par (f.eks. multi-turn "beskeder"), der kan indeholde klare instruktioner – og AI’ens svar forsøger at følge disse instruktioner.
Dette bruger teknikker som Reinforcement Learning with Human Feedback (RLHF), der kan træne modellen til at følge instruktioner og lære af feedback, så den producerer svar, der er bedre tilpasset praktiske anvendelser og mere relevante for brugerens mål.
Lad os prøve det – gå tilbage til prompten ovenfor, men skift nu systembeskeden til at give følgende instruktion som kontekst:
Opsummer det indhold, du får, for en elev i 2. klasse. Hold resultatet til et afsnit med 3-5 punktopstillinger.
Kan du se, hvordan resultatet nu er tilpasset det ønskede mål og format? En underviser kan nu direkte bruge dette svar i deres slides til den klasse.
Nu hvor vi ved, hvordan prompts behandles af LLM’er, lad os tale om hvorfor vi har brug for prompt engineering. Svaret ligger i, at nuværende LLM’er har en række udfordringer, der gør det sværere at opnå pålidelige og konsistente svar uden at lægge indsats i promptkonstruktion og optimering. For eksempel:
-
Model-svar er stokastiske. Den samme prompt vil sandsynligvis give forskellige svar med forskellige modeller eller modelversioner. Og den kan endda give forskellige resultater med den samme model på forskellige tidspunkter. Prompt engineering-teknikker kan hjælpe os med at minimere disse variationer ved at give bedre rammer.
-
Modeller kan finde på svar. Modeller er fortrænet med store, men begrænsede datasæt, hvilket betyder, at de mangler viden om begreber uden for træningsområdet. Som følge heraf kan de producere svar, der er unøjagtige, opdigtede eller direkte modstridende med kendte fakta. Prompt engineering-teknikker hjælper brugere med at identificere og afbøde sådanne opdigtninger, f.eks. ved at bede AI om kildehenvisninger eller begrundelser.
-
Modellers kapaciteter vil variere. Nyere modeller eller modelgenerationer vil have rigere kapaciteter, men også bringe unikke særheder og kompromiser i omkostninger og kompleksitet. Prompt engineering kan hjælpe os med at udvikle bedste praksis og arbejdsgange, der abstraherer forskelle og tilpasser sig model-specifikke krav på skalerbare og sømløse måder.
Lad os se dette i praksis i OpenAI eller Azure OpenAI Playground:
- Brug den samme prompt med forskellige LLM-implementeringer (f.eks. OpenAI, Azure OpenAI, Hugging Face) – så du variationerne?
- Brug den samme prompt gentagne gange med den samme LLM-implementering (f.eks. Azure OpenAI playground) – hvordan adskilte disse variationer sig?
I dette kursus bruger vi begrebet "fabrication" til at referere til fænomenet, hvor LLM’er nogle gange genererer faktuelt ukorrekte oplysninger på grund af begrænsninger i deres træning eller andre forhold. Du har måske også hørt dette omtalt som "hallucinationer" i populære artikler eller forskningspapirer. Vi anbefaler dog kraftigt at bruge "fabrication" som betegnelse, så vi undgår at antropomorfisere adfærden ved at tillægge en menneskelig egenskab til et maskindrevet resultat. Dette understøtter også Responsible AI-retningslinjer fra et terminologisk perspektiv ved at fjerne termer, der i visse sammenhænge kan opfattes som stødende eller ikke inkluderende.
Vil du have en fornemmelse af, hvordan fabrication fungerer? Tænk på en prompt, der instruerer AI’en til at generere indhold om et ikke-eksisterende emne (for at sikre, at det ikke findes i træningsdatasættet). For eksempel – jeg prøvede denne prompt:
I denne lektion vil vi udforske den Marsianske Krig, der fandt sted i 2076. Vi vil undersøge årsagerne til konflikten, de vigtigste begivenheder og dens konsekvenser for både Jorden og Mars.
- Forstå baggrunden for den Marsianske Krig
- Identificere nøgleaktører og begivenheder i krigen
- Analysere krigens indvirkning på fremtidige interplanetariske relationer
- Historiske dokumenter og rapporter om Marsianske Krig
- Kort over Mars og Jorden under konflikten
- Videoer og øjenvidneberetninger
- Diskuter de politiske og økonomiske spændinger mellem Jorden og Mars
- Gennemgå de vigtigste begivenheder, der førte til krigen
- Gennemgå de vigtigste slag og strategier brugt af begge sider
- Analyser teknologier og våben, der blev anvendt
- Diskuter krigens indvirkning på Mars' kolonisering og Jordens politik
- Overvej hvordan krigen har formet nutidens interplanetariske samarbejde
- Lad eleverne diskutere, hvad de mener kunne have forhindret krigen
- Reflekter over betydningen af fred og samarbejde i rummet
Opsummer de vigtigste punkter fra lektionen og opfordr eleverne til at læse yderligere materiale om emnet.
- Links til dokumentarer og artikler om den Marsianske Krig
- Forslag til projekter og opgaver relateret til emnet Et web-søg viste mig, at der fandtes fiktive beretninger (f.eks. tv-serier eller bøger) om marskrige – men ingen i 2076. Sund fornuft fortæller os også, at 2076 er i fremtiden og derfor ikke kan forbindes med en virkelig begivenhed.
Så hvad sker der, når vi kører denne prompt med forskellige LLM-udbydere?
Response 1: OpenAI Playground (GPT-35)
Response 2: Azure OpenAI Playground (GPT-35)
Response 3: : Hugging Face Chat Playground (LLama-2)
Som forventet producerer hver model (eller modelversion) lidt forskellige svar takket være stokastisk adfærd og variationer i modelkapacitet. For eksempel retter én model sig mod et 8. klasses publikum, mens en anden antager en gymnasieelev. Men alle tre modeller genererede svar, der kunne overbevise en uinformeret bruger om, at begivenheden var ægte.
Prompt engineering-teknikker som metaprompting og temperature configuration kan til en vis grad reducere model-fabrikationer. Nye prompt engineering-arkitekturer integrerer også nye værktøjer og teknikker problemfrit i prompt-flowet for at afbøde eller mindske nogle af disse effekter.
Lad os afslutte dette afsnit med at få en fornemmelse af, hvordan prompt engineering bruges i virkelige løsninger ved at se på et Case Study: GitHub Copilot.
GitHub Copilot er din "AI Pair Programmer" – den omsætter tekstprompter til kodeforslag og er integreret i dit udviklingsmiljø (f.eks. Visual Studio Code) for en problemfri brugeroplevelse. Som dokumenteret i blogserien nedenfor, var den tidligste version baseret på OpenAI Codex-modellen – hvor ingeniører hurtigt indså behovet for at finjustere modellen og udvikle bedre prompt engineering-teknikker for at forbedre kodekvaliteten. I juli præsenterede de en forbedret AI-model, der går ud over Codex for endnu hurtigere forslag.
Læs indlæggene i rækkefølge for at følge deres læringsrejse.
- Maj 2023 | GitHub Copilot bliver bedre til at forstå din kode
- Maj 2023 | Indenfor GitHub: Arbejde med LLM’erne bag GitHub Copilot
- Jun 2023 | Sådan skriver du bedre prompts til GitHub Copilot
- Jul 2023 | .. GitHub Copilot går ud over Codex med forbedret AI-model
- Jul 2023 | En udviklers guide til prompt engineering og LLM’er
- Sep 2023 | Sådan bygger du en enterprise LLM-app: Læringer fra GitHub Copilot
Du kan også bladre i deres Engineering blog for flere indlæg som dette, der viser, hvordan disse modeller og teknikker anvendes til at drive virkelige applikationer.
Vi har set, hvorfor prompt engineering er vigtigt – nu skal vi forstå, hvordan prompts konstrueres, så vi kan evaluere forskellige teknikker for mere effektiv promptdesign.
Lad os starte med den grundlæggende prompt: en tekstinput sendt til modellen uden anden kontekst. Her er et eksempel – når vi sender de første par ord af den amerikanske nationalsang til OpenAI Completion API, fuldfører den straks svaret med de næste linjer, hvilket illustrerer den grundlæggende forudsigelsesadfærd.
| Prompt (Input) | Completion (Output) |
|---|---|
| Oh say can you see | Det lyder som om, du starter teksten til "The Star-Spangled Banner," USA’s nationalsang. Hele teksten er ... |
Lad os nu tilføje kontekst og instruktioner til den grundlæggende prompt. Chat Completion API giver os mulighed for at konstruere en kompleks prompt som en samling af beskeder med:
- Input/output-par, der afspejler bruger-input og assistent-svar.
- Systembesked, der sætter konteksten for assistentens adfærd eller personlighed.
Anmodningen er nu i nedenstående form, hvor tokeniseringen effektivt fanger relevant information fra kontekst og samtale. At ændre systemkonteksten kan nu have lige så stor indflydelse på kvaliteten af fuldførelser som de givne brugerinput.
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 ovenstående eksempler var brugerprompten en simpel tekstforespørgsel, der kan tolkes som en anmodning om information. Med instruktionsprompter kan vi bruge den tekst til at specificere en opgave mere detaljeret og give AI’en bedre vejledning. Her er et eksempel:
| Prompt (Input) | Completion (Output) | Instruktionstype |
|---|---|---|
| Write a description of the Civil War | returnerede et simpelt afsnit | Simpel |
| Write a description of the Civil War. Provide key dates and events and describe their significance | returnerede et afsnit efterfulgt af en liste med nøglebegivenheder og beskrivelser | Kompleks |
| Write a description of the Civil War in 1 paragraph. Provide 3 bullet points with key dates and their significance. Provide 3 more bullet points with key historical figures and their contributions. Return the output as a JSON file | returnerer mere omfattende detaljer i en tekstboks, formateret som JSON, som du kan kopiere og indsætte i en fil og validere efter behov | Kompleks. Formateret. |
I ovenstående eksempler var prompten stadig ret åben, hvilket tillod LLM’en at afgøre, hvilken del af dens fortrænede datasæt der var relevant. Med designmønsteret primært indhold opdeles inputteksten i to dele:
- en instruktion (handling)
- relevant indhold (der påvirker handlingen)
Her er et eksempel, hvor instruktionen er at "opsummere dette i 2 sætninger".
| Prompt (Input) | Completion (Output) |
|---|---|
| Jupiter er den femte planet fra Solen og den største i solsystemet. Det er en gasgigant med en masse, der er en tusindedel af Solens, men to og en halv gang så stor som alle de andre planeter i solsystemet tilsammen. Jupiter er et af de klareste objekter, der kan ses med det blotte øje på nattehimlen, og har været kendt af gamle civilisationer siden før den skrevne historie. Den er opkaldt efter den romerske gud Jupiter.[19] Når man ser på Jupiter fra Jorden, kan den være så lysstærk, at dens reflekterede lys kaster synlige skygger,[20] og den er i gennemsnit det tredje mest lysstærke naturlige objekt på nattehimlen efter Månen og Venus. Opsummer dette i 2 korte sætninger |
Jupiter, den femte planet fra Solen, er den største i solsystemet og kendt for at være et af de mest lysstærke objekter på nattehimlen. Opkaldt efter den romerske gud Jupiter, er det en gasgigant med en masse, der er to og en halv gang så stor som alle de andre planeter i solsystemet tilsammen. |
Segmentet med primært indhold kan bruges på forskellige måder til at skabe mere effektive instruktioner:
- Eksempler – i stedet for at fortælle modellen, hvad den skal gøre med en eksplicit instruktion, giver man den eksempler på, hvad den skal gøre, og lader den udlede mønsteret.
- Signaler – følg instruktionen med et "signal", der forbereder fuldførelsen og guider modellen mod mere relevante svar.
- Skabeloner – disse er gentagelige ’opskrifter’ til prompts med pladsholdere (variabler), der kan tilpasses med data til specifikke brugsscenarier.
Lad os udforske disse i praksis.
Dette er en tilgang, hvor du bruger det primære indhold til at "fodre modellen" med nogle eksempler på det ønskede output for en given instruktion og lader den udlede mønsteret for det ønskede output. Afhængigt af antallet af eksempler kan vi have zero-shot prompting, one-shot prompting, few-shot prompting osv.
Prompten består nu af tre komponenter:
- En opgavebeskrivelse
- Nogle få eksempler på det ønskede output
- Starten på et nyt eksempel (som bliver en implicit opgavebeskrivelse)
| Læringstype | Prompt (Input) | Completion (Output) |
|---|---|---|
| Zero-shot | "The Sun is Shining". Translate to Spanish | "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 | The player ran the bases => Baseball The player hit an ace => Tennis The player hit a six => Cricket The player made a slam-dunk => |
Basketball |
Bemærk, hvordan vi måtte give en eksplicit instruktion ("Translate to Spanish") i zero-shot prompting, men den udledes i one-shot prompting-eksemplet. Few-shot-eksemplet viser, hvordan flere eksempler gør det muligt for modeller at lave mere præcise slutninger uden yderligere instruktioner.
En anden teknik til at bruge primært indhold er at give signaler i stedet for eksempler. I dette tilfælde giver vi modellen et skub i den rigtige retning ved at starte den med et uddrag, der afspejler det ønskede svarformat. Modellen "tager signalet" og fortsætter i samme stil.
| Antal Signaler | Prompt (Input) | Completion (Output) |
|---|---|---|
| 0 | Jupiter er den femte planet fra Solen og den største i solsystemet. Det er en gasgigant med en masse, der er en tusindedel af Solens, men to og en halv gang så stor som alle de andre planeter i solsystemet tilsammen. Jupiter er et af de klareste objekter, der kan ses med det blotte øje på nattehimlen, og har været kendt af gamle civilisationer siden før den skrevne historie. |
Summarize This | Jupiter er den største planet i vores solsystem og den femte fra solen. Det er en gasgigant med en masse, der er 1/1000 af solens, men den er tungere end alle de andre planeter tilsammen. Oldtidens civilisationer har kendt til Jupiter i lang tid, og den er let synlig på nattehimlen. |
| 1 | Jupiter er den femte planet fra solen og den største i solsystemet. Det er en gasgigant med en masse, der er en tusindedel af solens, men to og en halv gang så stor som alle de andre planeter i solsystemet tilsammen. Jupiter er et af de klareste objekter, der kan ses med det blotte øje på nattehimlen, og den har været kendt af oldtidens civilisationer siden før historisk tid.
Summarize This
Det vi lærte er, at Jupiter | er den femte planet fra solen og den største i solsystemet. Det er en gasgigant med en masse, der er en tusindedel af solens, men to og en halv gang så stor som alle de andre planeter tilsammen. Den er let synlig med det blotte øje og har været kendt siden oldtiden. |
| 2 | Jupiter er den femte planet fra solen og den største i solsystemet. Det er en gasgigant med en masse, der er en tusindedel af solens, men to og en halv gang så stor som alle de andre planeter i solsystemet tilsammen. Jupiter er et af de klareste objekter, der kan ses med det blotte øje på nattehimlen, og den har været kendt af oldtidens civilisationer siden før historisk tid.
Summarize This
Top 3 fakta vi lærte: | 1. Jupiter er den femte planet fra solen og den største i solsystemet.
2. Det er en gasgigant med en masse, der er en tusindedel af solens...
3. Jupiter har været synlig for det blotte øje siden oldtiden ... |
| | | |
En prompt-skabelon er en foruddefineret opskrift på en prompt, som kan gemmes og genbruges efter behov for at skabe mere konsistente brugeroplevelser i stor skala. I sin enkleste form er det blot en samling af prompt-eksempler som dette fra OpenAI, der både indeholder de interaktive prompt-komponenter (bruger- og systembeskeder) og API-drevne anmodningsformater – for at understøtte genbrug.
I en mere kompleks form som dette eksempel fra LangChain indeholder den pladsholdere, som kan erstattes med data fra forskellige kilder (brugerinput, systemkontekst, eksterne datakilder osv.) for at generere en prompt dynamisk. Det giver os mulighed for at opbygge et bibliotek af genanvendelige prompts, der kan bruges til at skabe konsistente brugeroplevelser programmatisk i stor skala.
Endelig ligger den egentlige værdi i skabeloner i muligheden for at oprette og offentliggøre prompt-biblioteker til vertikale anvendelsesområder – hvor prompt-skabelonen nu er optimeret til at afspejle applikationsspecifik kontekst eller eksempler, der gør svarene mere relevante og præcise for den målrettede brugergruppe. Prompts For Edu er et godt eksempel på denne tilgang, hvor man samler et bibliotek af prompts til uddannelsesområdet med fokus på nøglemål som lektionsplanlægning, læseplanlægning, elevvejledning osv.
Hvis vi ser på prompt-konstruktion som bestående af en instruktion (opgave) og et mål (primært indhold), så er sekundært indhold som ekstra kontekst, vi giver for at påvirke output på en eller anden måde. Det kan være justeringsparametre, formateringsinstruktioner, emnetaksonomier osv., som hjælper modellen med at tilpasse sit svar, så det passer til de ønskede brugerformål eller forventninger.
For eksempel: Givet en kursuskatalog med omfattende metadata (navn, beskrivelse, niveau, metadata-tags, underviser osv.) for alle tilgængelige kurser i læseplanen:
- kan vi definere en instruktion om at "opsummere kursuskataloget for efteråret 2023"
- kan vi bruge det primære indhold til at give nogle eksempler på det ønskede output
- kan vi bruge det sekundære indhold til at identificere de 5 vigtigste "tags" af interesse.
Nu kan modellen levere et resumé i det format, som eksemplerne viser – men hvis et resultat har flere tags, kan den prioritere de 5 tags, der er identificeret i det sekundære indhold.
Nu hvor vi ved, hvordan prompts kan konstrueres, kan vi begynde at tænke over, hvordan vi designer dem, så de afspejler bedste praksis. Vi kan opdele det i to dele – at have den rette tankegang og anvende de rette teknikker.
Prompt Engineering er en prøve-og-fejl proces, så husk tre brede vejledende faktorer:
-
Domæneforståelse er vigtig. Svarenes nøjagtighed og relevans afhænger af det domæne, som applikationen eller brugeren opererer i. Brug din intuition og domæneekspertise til at tilpasse teknikkerne yderligere. For eksempel kan du definere domænespecifikke personligheder i dine systemprompter eller bruge domænespecifikke skabeloner i dine brugerprompter. Giv sekundært indhold, der afspejler domænespecifik kontekst, eller brug domænespecifikke signaler og eksempler for at guide modellen mod velkendte brugsmønstre.
-
Modelforståelse er vigtig. Vi ved, at modeller er stokastiske af natur. Men modelimplementeringer kan også variere med hensyn til træningsdatasættet (forudindlært viden), de funktioner, de tilbyder (f.eks. via API eller SDK) og typen af indhold, de er optimeret til (f.eks. kode vs. billeder vs. tekst). Forstå styrker og begrænsninger ved den model, du bruger, og brug den viden til at prioritere opgaver eller bygge tilpassede skabeloner, der er optimeret til modellens kapaciteter.
-
Iteration & validering er vigtig. Modeller udvikler sig hurtigt, og det samme gør teknikkerne til prompt engineering. Som domæneekspert kan du have anden kontekst eller kriterier for din specifikke applikation, som måske ikke gælder for det bredere fællesskab. Brug prompt engineering-værktøjer og teknikker til at "komme godt i gang" med prompt-konstruktionen, og iterer og valider resultaterne med din egen intuition og domæneekspertise. Registrer dine indsigter og opbyg en vidensbase (f.eks. prompt-biblioteker), som andre kan bruge som ny baseline for hurtigere iterationer fremover.
Lad os nu se på almindelige bedste praksisser, som anbefales af OpenAI og Azure OpenAI praktikere.
| Hvad | Hvorfor |
|---|---|
| Evaluer de nyeste modeller. | Nye modelgenerationer har sandsynligvis forbedrede funktioner og kvalitet – men kan også medføre højere omkostninger. Evaluer dem for effekt, og træf derefter beslutning om migrering. |
| Adskil instruktioner & kontekst | Tjek om din model/udbyder definerer afgrænsere for tydeligere at adskille instruktioner, primært og sekundært indhold. Det kan hjælpe modeller med at tildele vægte mere præcist til tokens. |
| Vær specifik og klar | Giv flere detaljer om ønsket kontekst, resultat, længde, format, stil osv. Det forbedrer både kvalitet og konsistens i svarene. Gem opskrifter i genanvendelige skabeloner. |
| Vær beskrivende, brug eksempler | Modeller reagerer ofte bedre på en "vis og fortæl"-tilgang. Start med en zero-shot tilgang, hvor du giver en instruktion (men ingen eksempler), og prøv derefter few-shot som en finjustering, hvor du giver nogle få eksempler på ønsket output. Brug analogier. |
| Brug signaler til at kickstarte svar | Skub modellen mod et ønsket resultat ved at give nogle ledende ord eller sætninger, som den kan bruge som udgangspunkt for svaret. |
| Gentag for at forstærke | Nogle gange skal du gentage dig selv over for modellen. Giv instruktioner før og efter dit primære indhold, brug en instruktion og et signal osv. Iterer og valider for at se, hvad der virker. |
| Rækkefølge betyder noget | Den rækkefølge, du præsenterer information for modellen i, kan påvirke output, også i læringseksempler, på grund af recency bias. Prøv forskellige muligheder for at finde det, der virker bedst. |
| Giv modellen en “udvej” | Giv modellen et fallback-svar, den kan bruge, hvis den ikke kan fuldføre opgaven af en eller anden grund. Det kan mindske risikoen for, at modellen genererer falske eller opdigtede svar. |
Som med enhver bedste praksis, husk at din oplevelse kan variere afhængigt af model, opgave og domæne. Brug disse som udgangspunkt, og iterer for at finde det, der virker bedst for dig. Evaluer løbende din prompt engineering-proces, efterhånden som nye modeller og værktøjer bliver tilgængelige, med fokus på skalerbarhed og svar-kvalitet.
Tillykke! Du er nået til slutningen af lektionen! Det er tid til at prøve nogle af de koncepter og teknikker af med rigtige eksempler!
Til vores opgave bruger vi en Jupyter Notebook med øvelser, du kan gennemføre interaktivt. Du kan også udvide Notebooken med dine egne Markdown- og kodeceller for at udforske ideer og teknikker på egen hånd.
- (Anbefalet) Start GitHub Codespaces
- (Alternativt) Klon repoet til din lokale enhed og brug det med Docker Desktop
- (Alternativt) Åbn Notebooken i dit foretrukne Notebook-runtime-miljø.
- Kopiér
.env.copy-filen i repoets rod til.envog udfyld værdierne forAZURE_OPENAI_API_KEY,AZURE_OPENAI_ENDPOINTogAZURE_OPENAI_DEPLOYMENT. Gå tilbage til Learning Sandbox sektionen for at lære hvordan.
- Vælg runtime-kernen. Hvis du bruger mulighed 1 eller 2, vælg blot den standard Python 3.10.x kerne, som dev-containeren leverer.
Du er klar til at køre øvelserne. Bemærk, at der ikke findes rigtige eller forkerte svar her – det handler om at prøve sig frem og opbygge intuition for, hvad der virker for en given model og applikationsdomæne.
Af denne grund er der ingen kode-løsningsafsnit i denne lektion. I stedet vil Notebooken indeholde Markdown-celler med titlen "My Solution:", som viser et eksempel på output til reference.
Hvilken af følgende er en god prompt, der følger nogle rimelige bedste praksisser?
- Vis mig et billede af en rød bil
- Vis mig et billede af en rød bil af mærket Volvo og model XC90 parkeret ved en klippe med solen gående ned
- Vis mig et billede af en rød bil af mærket Volvo og model XC90
A: 2, det er den bedste prompt, da den giver detaljer om "hvad" og går i dybden med specifikationer (ikke bare en hvilken som helst bil, men et bestemt mærke og model) og beskriver også omgivelserne. 3 er næstbedst, da den også indeholder mange beskrivelser.
Prøv at bruge "cue"-teknikken med prompten: Fuldfør sætningen "Vis mig et billede af en rød bil af mærket Volvo og ". Hvad svarer den, og hvordan ville du forbedre det?
Vil du lære mere om forskellige Prompt Engineering-koncept? Gå til den fortsatte læringsside for at finde andre gode ressourcer om emnet.
Gå videre til Lektion 5, hvor vi ser på avancerede prompting-teknikker!
Ansvarsfraskrivelse:
Dette dokument er blevet oversat ved hjælp af AI-oversættelsestjenesten Co-op Translator. Selvom vi bestræber os på nøjagtighed, bedes du være opmærksom på, at automatiserede oversættelser kan indeholde fejl eller unøjagtigheder. Det oprindelige dokument på dets oprindelige sprog bør betragtes som den autoritative kilde. For kritisk information anbefales professionel menneskelig oversættelse. Vi påtager os intet ansvar for misforståelser eller fejltolkninger, der opstår som følge af brugen af denne oversættelse.