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, betyder også noget. En omhyggeligt udformet prompt kan opnå en bedre kvalitet af svar. Men hvad betyder begreber som prompt og prompt engineering egentlig? Og hvordan forbedrer jeg prompt inputtet, som 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 er i stand til at skabe nyt indhold (f.eks. tekst, billeder, lyd, kode osv.) som respons på brugerforespørgsler. Det opnås ved hjælp af Large Language Models som OpenAIs GPT ("Generative Pre-trained Transformer") serie, der er trænet til brug af naturligt sprog og kode.
Brugere kan nu interagere med disse modeller ved brug af velkendte paradigmer som chat uden behov for teknisk ekspertise eller træning. Modellerne er prompt-baserede - brugere sender en tekstinput (prompt) og modtager AI-svaret (completion). De kan derefter "chatte med AI'en" iterativt, i multi-turn samtaler, og forfine deres prompt indtil svaret matcher deres forventninger.
"Prompts" bliver nu det primære programmeringsinterface 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 hastigt voksende studieområde, som fokuserer på design og optimering af prompts for at levere konsistente og kvalitetsfulde 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 et applikationsmå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 begreber anvendt på virkelige eksempler.
Når vi har gennemført lektionen, 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 de lærte teknikker på virkelige eksempler ved hjælp af en OpenAI-endpoint.
Prompt Engineering: Praksis med at designe og forfine input for at styre AI-modeller mod at producere ønskede output. Tokenization: Processen med at konvertere tekst til mindre enheder, kaldet tokens, som en model kan forstå og behandle. Instruction-Tuned LLMs: Large Language Models (LLMs), der er finjusteret med specifikke instruktioner for at forbedre deres svarpræcision og relevans.
Prompt engineering er i øjeblikket mere en kunst end en videnskab. Den bedste måde at forbedre vores intuition for det er at øve sig mere og anvende en trial-and-error tilgang, som kombinerer domænefaglig ekspertise med anbefalede teknikker og model-specifikke optimeringer.
Jupyter Notebook, der ledsager denne lektion, giver et sandbox-miljø, hvor du kan prøve det, du lærer – som du går frem, eller som en del af kodeudfordringen til sidst. For at gennemføre øvelserne skal du bruge:
- En Azure OpenAI API-nøgle - serviceendpoint for en implementeret LLM.
- Et Python-runtime - hvor Notebook kan køres.
- Lokale miljøvariabler - fuldfør SETUP trin nu for at være klar.
Notebooken kommer med starter øvelser - men du opfordres til at tilføje dine egne Markdown (beskrivelse) og Code (prompt-forespørgsler) sektioner for at prøve flere eksempler eller idéer - og opbygge din intuition for promptdesign.
Vil du have det store overblik over, hvad denne lektion dækker, før du dykker ned? Kig på denne illustrerede guide, som giver dig en fornemmelse af hovedtemaerne og nøglepointerne, du kan tænke over i hver del. Lektionens køreplan tager dig fra forståelse af kernebegreber og udfordringer til at håndtere dem med relevante teknikker og bedste praksis inden for prompt engineering. Bemærk, at afsnittet "Avancerede teknikker" i denne guide refererer til indhold, der dækkes i det næste kapitel i dette kursusforløb.
Lad os nu tale om, hvordan dette emne relaterer til vores startup-mission om at bringe AI-innovation til uddannelse. Vi ønsker at bygge AI-drevne applikationer til personaliseret læring - så lad os tænke over, hvordan forskellige brugere af vores applikation kan "designe" prompts:
- Administratorer kan bede AI'en om at analysere læseplansdata for at identificere mangler i dækningen. AI kan opsummere resultater eller visualisere dem med kode.
- Undervisere kan bede AI'en om at generere en lektionsplan for et målrettet publikum og emne. AI kan bygge den personlige plan i et specificeret format.
- Studerende kan bede AI'en om at vejlede dem i et svært fag. AI kan nu guide studerende med lektioner, hints og eksempler tilpasset deres niveau.
Det er bare toppen af isbjerget. Kig på Prompts For Education - et open source prompts-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 tekstinputs (prompts) for at levere konsistente og kvalitetsfulde svar (completions) til et givent applikationsmål og model. Vi kan betragte dette som en 2-trins proces:
- designe den oprindelige prompt til en given model og formål
- forfine prompten iterativt for at forbedre svarenes kvalitet
Dette er nødvendigvis en trial-and-error proces, der kræver brugerintuition og indsats for at opnå optimale resultater. Så hvorfor er det vigtigt? For at besvare det spørgsmål må 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 trænes på tokens (og ikke på rå tekst), har måden prompts tokeniseres på direkte indflydelse på kvaliteten af det genererede svar.
For at få en intuition for, 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, mens du lægger mærke til, hvordan mellemrum og tegnsætning håndteres. Bemærk at dette eksempel viser en ældre LLM (GPT-3) – så forsøg med en nyere model kan give et andet resultat.
Når en prompt er tokeniseret, er hovedfunktionen for "Base LLM" (eller foundation-model) at forudsige token i den sekvens. Da LLM'er er trænet på massive tekstdatasæt, har de en god forståelse af de statistiske relationer mellem tokens og kan lave denne forudsigelse med nogenlunde sikkerhed. Bemærk, at de ikke forstår betydningen af ordene i prompten eller token; de ser bare et mønster, de kan "fuldføre" med deres næste forudsigelse. De kan fortsætte med at forudsige sekvensen, indtil den bliver afbrudt af brugerintervention eller en forudfastlagt betingelse.
Vil du se, hvordan promptbaseret completion fungerer? Indtast ovenstående prompt i Azure OpenAI Studio Chat Playground med standardindstillingerne. Systemet er konfigureret til at behandle prompts som forespørgsler om information – så du bør se et svar, der opfylder denne kontekst.
Men hvad hvis brugeren ville se noget specifikt, som opfylder et kriterium eller en opgave? Her kommer instruction-tuned LLM'er ind i billedet.
En Instruction Tuned LLM starter med foundation-modellen og finjusterer den med eksempler eller input/output par (f.eks. multi-turn "messages"), som kan indeholde klare instruktioner – og AI’ens svar forsøger at følge denne instruktion.
Dette benytter teknikker som Reinforcement Learning med Human Feedback (RLHF), som 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 – besøg prompten ovenfor igen, men ændr nu systemmeddelelsen til at give denne instruktion som kontekst:
Opsummer det indhold, du får, for en elev i 2. klasse. Hold resultatet til ét 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 udgør en række udfordringer, som gør pålidelige og konsistente svar vanskeligere at opnå uden indsats i promptkonstruktion og optimering. For eksempel:
-
Modelsvar er stokastiske. Den samme prompt vil sandsynligvis producere forskellige svar med forskellige modeller eller modelversioner. Og den kan endda producere 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 sikkerhed.
-
Modeller kan fabrikere svar. Modeller er for-trænet med store men begrænsede datasæt, hvilket betyder, at de mangler viden om koncepter uden for dette træningsområde. Som følge heraf kan de producere svar, der er upræcise, opfundne eller direkte i modstrid med kendte fakta. Prompt engineering teknikker hjælper brugere med at identificere og afbøde sådanne fabrikationer, f.eks. ved at bede AI’en om kilder eller ræsonnement.
-
Modellers evner vil variere. Nyere modeller eller modelgenerationer vil have rigere evner, men medbringe unikke særheder og kompromiser i omkostning og kompleksitet. Prompt engineering kan hjælpe os med at udvikle bedste praksis og arbejdsgange, der abstraherer forskelle og tilpasses model-specifikke krav på skalerbare, problemfri måder.
Lad os se det i praksis i OpenAI eller Azure OpenAI Playground:
- Brug samme prompt med forskellige LLM-udrulninger (f.eks. OpenAI, Azure OpenAI, Hugging Face) – så du variationerne?
- Brug den samme prompt gentagne gange med den samme LLM-udrulning (f.eks. Azure OpenAI playground) – hvordan adskilte disse variationer sig?
I dette kursus bruger vi begrebet "fabrikation" til at referere til fænomenet, hvor LLM'er nogle gange genererer faktuelt ukorrekt information på grund af begrænsninger i deres træning eller andre forhold. Du kan også have hørt det omtalt som "hallucinationer" i populære artikler eller forskningspapirer. Vi anbefaler dog kraftigt at bruge "fabrikation" som termen, så vi ikke utilsigtet antropomorfiserer adfærden ved at tilskrive en menneskelig egenskab til en maskinbaseret handling. Dette styrker også Ansvarlig AI-retningslinjer fra et terminologisk perspektiv ved at fjerne udtryk, der i nogle kontekster også kan opfattes som stødende eller ikke-inkluderende.
Vil du have en fornemmelse af, hvordan fabrikationer fungerer? Tænk på en prompt, der instruerer AI’en om at generere indhold om et ikke-eksisterende emne (for at sikre, at det ikke findes i træningsdatasættet). For eksempel prøvede jeg denne prompt:
Prompt: generer en lektionsplan om Den Marsianske Krig i 2076. Et websøgningsresultat viste mig, at der fandtes fiktive fortællinger (f.eks. tv-serier eller bøger) om Martianske krige – men ingen i 2076. Sund fornuft fortæller os også, at 2076 er i fremtiden og derfor ikke kan forbindes med en reel begivenhed.
Så hvad sker der, når vi kører denne prompt med forskellige LLM-udbydere?
Svar 1: OpenAI Playground (GPT-35)
Svar 2: Azure OpenAI Playground (GPT-35)
Svar 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 en 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 reel.
Prompt engineering-teknikker som metaprompting og temperaturkonfiguration kan til en vis grad reducere model-fabricationer. Nye prompt engineering arkitekturer inkorporerer også nye værktøjer og teknikker sømløst i prompt-flowet for at afbøde eller reducere nogle af disse effekter.
Lad os afslutte denne sektion med at få en fornemmelse af, hvordan prompt engineering bruges i virkelige løsninger ved at se på en Case Study: GitHub Copilot.
GitHub Copilot er din "AI parprogrammer" – det omsætter tekstprompter til kodeforslag og er integreret i dit udviklingsmiljø (f.eks. Visual Studio Code) for en glidende brugeroplevelse. Som dokumenteret i nedenstående blogserie var den tidligste version baseret på OpenAI Codex-modellen – hvor ingeniørerne hurtigt indså behovet for at finjustere modellen og udvikle bedre prompt engineering-teknikker for at forbedre kodekvaliteten. I juli debuterede 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 | Inside GitHub: Arbejde med LLM’erne bag GitHub Copilot.
- Jun 2023 | Hvordan man skriver 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 | Hvordan man bygger en virksomhedsløsning med LLM: Læringer fra GitHub Copilot
Du kan også browse 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 prompter konstrueres, så vi kan evaluere forskellige teknikker til mere effektiv promptdesign.
Lad os starte med den grundlæggende prompt: en tekstinput, der sendes til modellen uden anden kontekst. Her er et eksempel – når vi sender de første få ord af USA’s nationalsang til OpenAI’s 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 begynder teksten til "The Star-Spangled Banner," USA’s nationalsang. Hele teksten er ... |
Lad os nu tilføje kontekst og instruktioner til denne grundlæggende prompt. Chat Completion API’en giver os mulighed for at konstruere en kompleks prompt som en samling af beskeder med:
- Input/output-par, der afspejler bruger input og assistent respons.
- Systembesked, der sætter konteksten for assistentens adfærd eller personlighed.
Forespørgslen er nu i nedenstående form, hvor tokeniseringen effektivt fanger relevant information fra kontekst og samtale. Nu kan ændring af systemkontexten være lige så indflydelsesrig på kvaliteten af svarene som de brugerinput, der gives.
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 kunne tolkes som en anmodning om information. Med instruktionsprompter kan vi bruge den tekst til at specificere en opgave mere detaljeret og give bedre vejledning til AI’en. Her er et eksempel:
| Prompt (Input) | Completion (Output) | Instruktionstype |
|---|---|---|
| Skriv en beskrivelse af den amerikanske borgerkrig | returnerede et simpelt afsnit | Simpel |
| Skriv en beskrivelse af den amerikanske borgerkrig. Giv nøgle datoer og begivenheder og beskriv deres betydning | returnerede et afsnit efterfulgt af en liste med nøglebegivenheders datoer og beskrivelser | Komplekst |
| Skriv en beskrivelse af den amerikanske borgerkrig i 1 afsnit. Giv 3 punktpunkter med nøgle datoer og deres betydning. Giv 3 flere punktpunkter med nøglehistoriske personer og deres bidrag. Returnér output som en JSON-fil | returnerer mere omfattende detaljer i en tekstboks, formatteret som JSON, som du kan kopiere og validere efter behov | Kompleks. Formateret. |
I ovenstående eksempler var prompten stadig ret åben, hvilket lod LLM’en beslutte, hvilken del af dets forudtrænede datasæt der var relevant. Med designmønstret 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 gasplanet med en masse på en tusindedel af Solens, men to og en halv gang så stor som alle de andre planeter i Solsystemet tilsammen. Jupiter er en af de klareste genstande, der er synlige med det blotte øje på nattehimlen, og er kendt af gamle civilisationer siden før historisk tid. Den er opkaldt efter den romerske gud Jupiter.[19] Når Jupiter ses fra Jorden, kan den være lysstærk nok til, at dens reflekterede lys kaster synlige skygger,[20] og er i gennemsnit det tredje klareste 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 klareste objekter på nattehimlen. Opkaldt efter den romerske gud Jupiter, er det en gasplanet, hvis masse er to og en halv gang så stor som alle de andre planeter i Solsystemet tilsammen. |
Segmentet for primært indhold kan bruges på forskellige måder for 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 der skal gøres, og lader den udlede mønsteret.
- Tips – føl instruktionen med et "tip", der forbereder completion’en og guider modellen mod mere relevante svar.
- Skabeloner – disse er gentagelige 'opskrifter' på 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 ønsket outputmønster. 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å ønsket output
- Starten på et nyt eksempel (som bliver en implicit opgavebeskrivelse)
| Læringstype | Prompt (Input) | Completion (Output) |
|---|---|---|
| Zero-shot | "The Sun is Shining". Oversæt 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øb baserne => Baseball Spilleren slog en ace => Tennis Spilleren slog en sekser => Cricket Spilleren lavede en slam-dunk => |
Basketball |
Bemærk, hvordan vi måtte give eksplicit instruktion ("Oversæt til spansk") i zero-shot prompting, men den udledes i one-shot prompt-eksemplet. Few-shot-eksemplet viser, hvordan flere eksempler tillader modeller at lave mere præcise slutninger uden ekstra instruktioner.
En anden teknik til at bruge primært indhold er at give tips i stedet for eksempler. I dette tilfælde giver vi modellen en skub i den rigtige retning ved at starte den med et uddrag, der afspejler det ønskede svarformat. Modellen "tager tipset" og fortsætter i den stil.
| Antal Tips | Prompt (Input) | Completion (Output) |
|---|---|---|
| 0 | Jupiter er den femte planet fra Solen og den største i Solsystemet. Det er en gasplanet med en masse på en tusindedel af Solens, men to og en halv gang så stor som alle de andre planeter i Solsystemet tilsammen. Jupiter er en af de klareste genstande, der er synlige med det blotte øje på nattehimlen, og er kendt af gamle civilisationer siden før historisk tid. Opsummer dette |
Jupiter er den største planet i vores Solsystem og den femte fra Solen. Det er en gasplanet med en masse på 1/1000 af Solens, men den er tungere end alle de andre planeter tilsammen. Gamle civilisationer har kendt 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 gas-gigant 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 mest lysstærke objekter synlige med det blotte øje på nattehimlen og har været kendt af gamle civilisationer siden før skriftlige optegnelser. Opsummer dette Det vi lærte er, at Jupiter |
er den femte planet fra Solen og den største i Solsystemet. Det er en gas-gigant 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 gas-gigant 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 mest lysstærke objekter synlige med det blotte øje på nattehimlen og har været kendt af gamle civilisationer siden før skriftlige optegnelser. Opsummer dette Top 3 fakta vi lærte: |
1. Jupiter er den femte planet fra Solen og den største i Solsystemet. 2. Det er en gas-gigant med en masse, der er en tusindedel af Solens... 3. Jupiter har været synlig med 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 simpleste form er det blot en samling af prompt-eksempler som dette fra OpenAI, der giver både de interaktive prompt-komponenter (bruger- og systembeskeder) og API-styrede anmodningsformater – for at støtte genbrug.
I en mere kompleks form som dette eksempel fra LangChain indeholder den pladsholdere, som kan erstattes med data fra forskellige kilder (brugers input, systemkontekst, eksterne datakilder osv.) for dynamisk at skabe en prompt. Det giver os mulighed for at oprette et bibliotek af genanvendelige prompts, der kan bruges til at skabe konsistente brugeroplevelser programmatisk i stor skala.
Endelig ligger den reelle værdi af skabeloner i evnen til at oprette og offentliggøre prompt-biblioteker for 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 repositoriet er et godt eksempel på denne tilgang, der kuraterer et bibliotek af prompts til uddannelsesområdet med fokus på nøglemål som lektionsplanlægning, pensumdesign, elevvejledning osv.
Hvis vi tænker på prompt-konstruktion som at have en instruktion (opgave) og et mål (primært indhold), så er sekundært indhold som yderligere kontekst, vi giver for at påvirke output på en eller anden måde. Det kan være justeringsparametre, formateringsinstruktioner, emnetaksonomier osv., der kan hjælpe 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.) på alle tilgængelige kurser i pensum:
- vi kan definere en instruktion til "at opsummere kursuskataloget for efterår 2023"
- vi kan bruge det primære indhold til at give nogle eksempler på ønsket output
- vi kan bruge det sekundære indhold til at identificere de 5 vigtigste "tags" af interesse.
Nu kan modellen give en opsummering i formatet vist ved eksemplerne – men hvis et resultat har flere tags, kan den prioritere de 5 tags, der blev identificeret i sekundært indhold.
Nu hvor vi ved, hvordan prompts kan konstrueres, kan vi begynde at tænke på, hvordan vi designer dem, så de afspejler bedste praksis. Vi kan opdeles det i to dele – at have den rette tankegang og anvende de rette teknikker.
Prompt Engineering er en prøv-og-fejl proces, så hold tre overordnede vejledende faktorer i tankerne:
-
Domæneforståelse er afgørende. Svarets nøjagtighed og relevans afhænger af det domæne, hvor applikationen eller brugeren opererer. Brug din intuition og domæneekspertise til at tilpasse teknikker yderligere. Definer for eksempel domænespecifikke personligheder i dine systemprompter, eller brug domænespecifikke skabeloner i dine brugerprompter. Giv sekundært indhold, der afspejler domænespecifikke kontekster, eller brug domænespecifikke hints og eksempler til at lede modellen mod kendte anvendelsesmønstre.
-
Modelforståelse er afgørende. Vi ved, at modeller er stokastiske af natur. Men modelimplementeringer kan også variere med hensyn til det træningsdatasæt, de bruger (forudtrænet viden), de kapabiliteter de tilbyder (fx via API eller SDK) og den type indhold, de er optimeret til (fx kode vs. billeder vs. tekst). Forstå styrker og begrænsninger af den model, du bruger, og brug den viden til at prioritere opgaver eller opbygge tilpassede skabeloner, der er optimeret til modellens kapabiliteter.
-
Iteration og validering er afgørende. Modeller udvikler sig hurtigt, og det samme gør teknikker for prompt engineering. Som domæneekspert kan du have anden kontekst eller kriterier for din specifikke applikation, som måske ikke gælder for det brede samfund. Brug prompt engineering-værktøjer og teknikker til at "jumpstarte" prompt-konstruktion, og iterer derefter og valider resultaterne med din egen intuition og domæneekspertise. Notér dine indsigter og opret en vidensbase (fx prompt-biblioteker), som andre kan bruge som nyt udgangspunkt for hurtigere iterationer fremover.
Lad os nu se på almindelige bedste praksisser, som anbefales af OpenAI og Azure OpenAI.
| 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 tag derefter beslutninger om migration. |
| Adskil instruktioner & kontekst | Undersøg om din model/udbyder definerer afgrænsere for at skelne instruktioner, primært og sekundært indhold tydeligere. Det kan hjælpe modeller med at tildele vægte mere korrekt til tokens. |
| Vær specifik og klar | Giv flere detaljer om ønsket kontekst, resultat, længde, format, stil osv. Dette forbedrer både kvaliteten og konsistensen af svar. Indfang opskrifter i genanvendelige skabeloner. |
| Vær beskrivende, brug eksempler | Modeller responderer 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 forfining, hvor du giver nogle eksempler på ønsket output. Brug analogier. |
| Brug hints til at starte 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 om nødvendigt | Nogle gange skal du gentage dig overfor modellen. Giv instruktioner før og efter dit primære indhold, brug både instruktion og hint osv. Iterér 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 nyhedsbias. Prøv forskellige muligheder for at se, hvad der virker bedst. |
| Giv modellen en "vej ud" | Giv modellen et fallback-svar, som den kan give, hvis den ikke kan fuldføre opgaven af en eller anden grund. Det kan reducere risikoen for, at modeller genererer falske eller opdigtede svar. |
Som med enhver bedste praksis, husk at dine resultater kan variere afhængigt af model, opgave og domæne. Brug dette som udgangspunkt, og iterér for at finde ud af, hvad 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 afprøve nogle af de koncepter og teknikker med reelle eksempler!
Til vores opgave vil vi bruge en Jupyter Notebook med øvelser, du kan gennemføre interaktivt. Du kan også udvide Notebook’en med dine egne Markdown- og kodeceller for at udforske ideer og teknikker på egen hånd.
- (Anbefalet) Start GitHub Codespaces
- (Alternativt) Klon repo’et til din lokale enhed og brug det med Docker Desktop
- (Alternativt) Åbn Notebook’en med dit foretrukne Notebook-runtime-miljø.
- Kopiér filen
.env.copyi repo-roden til.envog udfyld værdierne forAZURE_OPENAI_API_KEY,AZURE_OPENAI_ENDPOINTogAZURE_OPENAI_DEPLOYMENT. Kom 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 foruddefinerede Python 3.10.x kernel, der leveres med dev-containeren.
Du er klar til at køre øvelserne. Bemærk, at der ikke findes rigtige eller forkerte svar her – det handler om at afprøve muligheder ved prøv-og-fejl og opbygge intuition for, hvad der virker for en given model og applikationsdomæne.
Derfor er der ikke Code Solution-segmenter i denne lektion. I stedet indeholder Notebook’en Markdown-celler med titlen "My Solution:", som viser et eksempel på output til reference.
Hvilket 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 klippeskrænt 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 detaljer (ikke bare en hvilken som helst bil, men en specifik mærke og model) og den beskriver også den overordnede kontekst. 3 er næstbedst, eftersom den også indeholder mange beskrivelser.
Se om du kan udnytte "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 fortsat 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, skal du være opmærksom på, at automatiske oversættelser kan indeholde fejl eller unøjagtigheder. Det originale 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.