Dette modul dækker essentielle begreber og teknikker til at skabe effektive prompts i generative AI-modeller. Den måde, du skriver din prompt til en LLM, har betydning. En omhyggeligt udformet prompt kan give en bedre kvalitet af svar. Men hvad betyder begreber som prompt og prompt engineering egentlig? Og hvordan forbedrer jeg prompt input, 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 svar på brugerens forespø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 ved hjælp af velkendte paradigmer som chat, uden at have behov for teknisk ekspertise eller træning. Modellerne er prompt-baserede - brugere sender en tekstinput (prompt) og får AI-svaret (completion) tilbage. De kan derefter "chatte med AI'en" iterativt i samtaler med flere omgange og finjustere 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 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 udforme mere effektive prompts til en given model og 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.
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 for prompt engineering.
- Anvende lærte teknikker på virkelige eksempler ved hjælp af en OpenAI-endpoint.
Prompt Engineering: Praksis med at designe og finjustere inputs for at guide AI-modeller mod at producere ønskede outputs.
Tokenization: Processen med at konvertere 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 kunst end videnskab. Den bedste måde at forbedre vores intuition for det er at øve mere og anvende en trial-and-error tilgang, der kombinerer ekspertise inden for applikationsdomænet 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 - enten løbende eller som en del af kodeudfordringen i slutningen. For at udføre øvelserne skal du bruge:
- En Azure OpenAI API-nøgle - serviceendpointet for en implementeret LLM.
- Et Python Runtime - hvor Notebook kan udføres.
- Lokale miljøvariabler - fuldfør SETUP trin nu for at blive klar.
Notebooken kommer med startø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 ideer - og opbygge din intuition for promptdesign.
Vil du have det store overblik over, hvad denne lektion dækker, før du dykker ned? Tjek denne illustrerede guide, som giver dig en fornemmelse af de vigtigste emner, der dækkes, og de vigtigste pointer, du skal tænke over i hver enkelt. Lektionens køreplan tager dig fra at forstå kernebegreber og udfordringer til at adressere dem med relevante prompt engineering-teknikker og bedste praksis. Bemærk, at afsnittet "Avancerede teknikker" i denne guide refererer til indhold, der dækkes i det næste kapitel af dette pensum.
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 kan "designe" prompts:
- Administratorer kan bede AI om at analysere pensumdata for at identificere mangler i dækningen. AI'en kan opsummere resultater eller visualisere dem med kode.
- Undervisere kan bede AI om at udforme en lektionsplan for en målgruppe og et emne. AI'en kan opbygge den personlige plan i et specificeret format.
- Studerende kan bede AI om at tutorere dem i et svært emne. AI'en kan nu vejlede studerende med lektioner, hints og eksempler skræddersyet til 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 ved hjælp af 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 kvalitetsmæssige svar (completions) til et givet applikationsmål og model. Vi kan tænke på dette som en 2-trins proces:
- designe den oprindelige prompt til en given model og mål
- finjustere prompten iterativt for at forbedre kvaliteten af svaret
Dette er nødvendigvis en trial-and-error proces, der kræver brugerens intuition 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 på rå tekst), har måden, prompts bliver tokeniseret på, en direkte indvirkning 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, som vist nedenfor. Kopier din prompt ind - og se, hvordan den bliver konverteret til tokens, og læg mærke til, hvordan mellemrumstegn og tegnsætning håndteres. Bemærk, at dette eksempel viser en ældre LLM (GPT-3) - så hvis du prøver dette med en nyere model, kan det give et andet resultat.
Når en prompt er blevet tokeniseret, er den primære funktion for "Base LLM" (eller grundmodellen) at forudsige det næste token i den sekvens. Da LLM'er er trænet på massive tekstdatasæt, har de en god fornemmelse af de statistiske relationer mellem tokens og kan lave den forudsigelse med en vis 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 de bliver afbrudt af brugeren eller en forudbestemt betingelse.
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 forespørgsler om information - så du bør se en completion, der opfylder denne kontekst.
Men hvad hvis brugeren ønskede at se noget specifikt, der opfyldte nogle kriterier eller opgaveformål? Det er her, instruction-tuned LLM'er kommer 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 svaret fra AI'en forsøger at følge den instruktion.
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 egnet til praktiske applikationer og mere relevante for brugerens mål.
Lad os prøve det - gå tilbage til ovenstående prompt, men ændr nu systembeskeden for at give følgende instruktion som kontekst:
Opsummer det indhold, du får, for en elev i anden klasse. Hold resultatet til ét afsnit med 3-5 punktformuleringer.
Se, hvordan resultatet nu er tilpasset til at afspejle det ønskede mål og format? En underviser kan nu direkte bruge dette svar i sine 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 det faktum, at nuværende LLM'er udgør en række udfordringer, der gør det sværere at opnå pålidelige og konsistente completions uden at lægge indsats i promptkonstruktion og optimering. For eksempel:
-
Modelresponser 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 rammer.
-
Modeller kan fabrikere svar. Modeller er forudtrænet med store men begrænsede datasæt, hvilket betyder, at de mangler viden om begreber uden for det træningsområde. Som et resultat kan de producere completions, der er unøjagtige, imaginære eller direkte modstridende med kendte fakta. Prompt engineering-teknikker hjælper brugere med at identificere og afbøde sådanne fabrikationer, f.eks. ved at bede AI om citater eller ræsonnement.
-
Modellers kapaciteter vil variere. Nyere modeller eller modelgenerationer vil have rigere kapaciteter, men også medføre unikke særheder og afvejninger 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, problemfri måder.
Lad os se dette i aktion 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 udtrykket "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 begrænsninger. Du har måske også hørt dette omtalt som "hallucinationer" i populære artikler eller forskningspapirer. Vi anbefaler dog stærkt at bruge "fabrikation" som udtryk, så vi ikke utilsigtet antropomorfiserer adfærden ved at tilskrive en menneskelignende egenskab til et maskindrevet resultat. Dette understøtter også Retningslinjer for ansvarlig AI fra et terminologisk perspektiv, hvor vi fjerner udtryk, der også kan betragtes som stødende eller ikke-inkluderende i nogle sammenhænge.
Vil du have en fornemmelse af, hvordan fabrikationer fungerer? Tænk på en prompt, der instruerer AI'en i at generere indhold for et ikke-eksisterende emne (for at sikre, at det ikke findes i træningsdatasættet). For eksempel - jeg prøvede denne prompt:
Prompt: generer en lektionsplan om den Marskrig i 2076. En web-søgning viste mig, at der findes fiktive beretninger (f.eks. tv-serier eller bøger) om krige på Mars - men ingen i 2076. Almindelig logik 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?
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 modellernes kapacitet. For eksempel retter én model sig mod et publikum på 8. klasses niveau, 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 temperature configuration kan reducere modellens fejlinformation til en vis grad. Nye prompt engineering-arkitekturer integrerer også nye værktøjer og teknikker problemfrit i prompt-flowet for at afhjælpe 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 Pair Programmer" - den konverterer tekstprompter til kodeforslag og er integreret i dit udviklingsmiljø (f.eks. Visual Studio Code) for en problemfri brugeroplevelse. Som dokumenteret i serien af blogs nedenfor, var den tidligste version baseret på OpenAI Codex-modellen - med ingeniører, der hurtigt indså behovet for at finjustere modellen og udvikle bedre prompt engineering-teknikker for at forbedre kodekvaliteten. I juli introducerede 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 | Inde i 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 virksomhed LLM-app: Lærdom fra GitHub Copilot
Du kan også gennemse 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 prompt design.
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 ord i 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 begynder på teksten til "The Star-Spangled Banner", USA's nationalsang. Den fulde tekst 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.
Forespørgslen er nu i nedenstående form, hvor tokeniseringen effektivt fanger relevant information fra kontekst og samtale. Nu kan ændring af systemkonteksten være lige så afgørende for kvaliteten af svarene som de leverede 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 brugerens prompt en simpel tekstforespørgsel, der kan tolkes som en anmodning om information. Med instruktions-prompter 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) | Instruction Type |
|---|---|---|
| Skriv en beskrivelse af Borgerkrigen | returnerede et simpelt afsnit | Simpel |
| Skriv en beskrivelse af Borgerkrigen. Angiv nøgledatoer og begivenheder og beskriv deres betydning | returnerede et afsnit efterfulgt af en liste over nøglebegivenheder med datoer og beskrivelser | Kompleks |
| Skriv en beskrivelse af Borgerkrigen i 1 afsnit. Angiv 3 punkter med nøgledatoer og deres betydning. Angiv yderligere 3 punkter med nøglehistoriske figurer og deres bidrag. Returner output som en JSON-fil | returnerede 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 gav LLM mulighed for at beslutte, hvilken del af dens forudtrænede datasæt der var relevant. Med primært indhold-designmønsteret opdeles inputteksten i to dele:
- en instruktion (handling)
- relevant indhold (der påvirker handlingen)
Her er et eksempel, hvor instruktionen er "opsummer 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 på 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 er synlige for 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] Set fra Jorden kan Jupiter være så lysstærk, at dens reflekterede lys kan kaste synlige skygger,[20] og den 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 gasgigant med en masse, der er to og en halv gang større end 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, giv den eksempler på, hvad den skal gøre, og lad den udlede mønsteret.
- Hint - følg instruktionen med et "hint", der forbereder modellen og guider den mod mere relevante svar.
- Skabeloner - dette er gentagelige 'opskrifter' for prompts med pladsholdere (variabler), der kan tilpasses med data til specifikke anvendelser.
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. Baseret på antallet af givne eksempler kan vi have zero-shot prompting, one-shot prompting, few-shot prompting osv.
Prompten består nu af tre komponenter:
- En opgavebeskrivelse
- Et par eksempler på det ønskede output
- Starten på et nyt eksempel (som bliver en implicit opgavebeskrivelse)
| Læringstype | Prompt (Input) | Completion (Output) |
|---|---|---|
| Zero-shot | "Solen skinner". Oversæt til spansk | "El Sol está brillando". |
| One-shot | "Solen skinner" => ""El Sol está brillando". "Det er en kold og blæsende dag" => |
"Es un día frío y ventoso". |
| Few-shot | Spilleren løb baserne => Baseball Spilleren slog et es => Tennis Spilleren slog en sekser => Cricket Spilleren lavede et slam-dunk => |
Basketball |
Bemærk, hvordan vi var nødt til at give en eksplicit instruktion ("Oversæt til spansk") i zero-shot prompting, men det bliver udledt i one-shot prompting-eksemplet. Few-shot eksemplet viser, hvordan tilføjelse af flere eksempler gør det muligt for modellerne at lave mere præcise udledninger uden yderligere instruktioner.
En anden teknik til at bruge primært indhold er at give hint 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 hintet" og fortsætter i samme stil.
| Antal hints | 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 på 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 er synlige for det blotte øje på nattehimlen, og har været kendt af gamle civilisationer siden før den skrevne historie. Opsummer Dette |
Jupiter er den største planet i vores Solsystem og den femte fra Solen. Det er en gasgigant med en masse på 1/1000 af Solens, men den er tungere end alle de andre planeter tilsammen. Gamle 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 større end alle de andre planeter i Solsystemet tilsammen. Jupiter er et af de klareste objekter, der er synlige for det blotte øje på nattehimlen, og har været kendt af gamle civilisationer siden før den skrevne historie. Opsummer dette 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 større end alle de andre planeter tilsammen. Den er let synlig for 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 større end alle de andre planeter i Solsystemet tilsammen. Jupiter er et af de klareste objekter, der er synlige for det blotte øje på nattehimlen, og har været kendt af gamle civilisationer siden før den skrevne historie. 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 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 giver både de interaktive prompt-komponenter (bruger- og systemmeddelelser) og det API-drevne anmodningsformat - for at understøtte genbrug.
I sin mere komplekse form som dette eksempel fra LangChain indeholder den pladsholdere, der kan erstattes med data fra forskellige kilder (brugerinput, systemkontekst, eksterne datakilder osv.) for dynamisk at generere en prompt. Dette giver os mulighed for at skabe 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 udgive prompt-biblioteker for vertikale applikationsdomæner - 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 repository er et godt eksempel på denne tilgang, der kuraterer et bibliotek af prompts til uddannelsesområdet med vægt på nøglemål som lektionsplanlægning, læseplansdesign, 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 kunne være justeringsparametre, formateringsinstruktioner, emnetaksonomier osv., der kan hjælpe modellen med at tilpasse sit svar til at passe til de ønskede brugerformål eller forventninger.
For eksempel: Givet en kursuskatalog med omfattende metadata (navn, beskrivelse, niveau, metadatamærker, instruktør osv.) om alle de tilgængelige kurser i læseplanen:
- vi kan definere en instruktion til "opsummer kursuskataloget for efteråret 2023"
- vi kan bruge det primære indhold til at give nogle eksempler på det ønskede output
- vi kan bruge det sekundære indhold til at identificere de 5 vigtigste "mærker" af interesse.
Nu kan modellen give en opsummering i det format, der vises af de få eksempler - men hvis et resultat har flere mærker, kan den prioritere de 5 mærker, der er identificeret i det sekundære indhold.
Nu hvor vi ved, hvordan prompts kan konstrueres, kan vi begynde at tænke på, hvordan vi kan designe dem til at afspejle bedste praksis. Vi kan tænke på dette i to dele - at have den rette tankegang og anvende de rette teknikker.
Prompt engineering er en proces med forsøg og fejl, så husk tre brede vejledende faktorer:
-
Domæneforståelse betyder noget. Svarets nøjagtighed og relevans er en funktion af det domæne, hvor applikationen eller brugeren opererer. Brug din intuition og domæneekspertise til at tilpasse teknikker yderligere. For eksempel kan du definere domænespecifikke personligheder i dine systemprompts eller bruge domænespecifikke skabeloner i dine brugerprompts. Giv sekundært indhold, der afspejler domænespecifikke kontekster, eller brug domænespecifikke ledetråde og eksempler til at guide modellen mod velkendte brugsmønstre.
-
Modelforståelse betyder noget. Vi ved, at modeller er stokastiske af natur. Men modelimplementeringer kan også variere med hensyn til det træningsdatasæt, de bruger (forudindlært viden), de funktioner, de tilbyder (f.eks. via API eller SDK), og den type indhold, de er optimeret til (f.eks. kode vs. billeder vs. tekst). Forstå styrkerne og begrænsningerne ved den model, du bruger, og brug den viden til at prioritere opgaver eller bygge tilpassede skabeloner, der er optimeret til modellens kapaciteter.
-
Iteration og validering betyder noget. 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 samfund. Brug værktøjer og teknikker til prompt engineering til at "springe i gang" med prompt-konstruktion, og iterer og valider resultaterne ved hjælp af din egen intuition og domæneekspertise. Registrer dine indsigter og opret en vidensbase (f.eks. prompt-biblioteker), der kan bruges som en ny baseline af andre til hurtigere iterationer i fremtiden.
Lad os nu se på almindelige bedste praksis, der 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 deres effekt, og tag derefter beslutninger om migration. |
| Adskil instruktioner og kontekst | Tjek om din model/udbyder definerer afgrænsninger for tydeligere at skelne instruktioner, primært og sekundært indhold. Dette kan hjælpe modeller med mere præcist at tildele vægte til tokens. |
| Vær specifik og klar | Giv flere detaljer om den ønskede kontekst, resultat, længde, format, stil osv. Dette vil forbedre både kvaliteten og konsistensen af svarene. Fang opskrifter i genanvendelige skabeloner. |
| Vær beskrivende, brug eksempler | Modeller kan reagere 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 forbedring, hvor du giver nogle eksempler på det ønskede output. Brug analogier. |
| Brug ledetråde til at starte svar | Skub det mod et ønsket resultat ved at give det nogle indledende ord eller sætninger, som det kan bruge som udgangspunkt for svaret. |
| Gentag dig selv | Nogle gange kan det være nødvendigt at gentage dig selv over for modellen. Giv instruktioner før og efter dit primære indhold, brug en instruktion og en ledetråd osv. Iterer og valider for at se, hvad der fungerer. |
| Rækkefølgen betyder noget | Den rækkefølge, du præsenterer information for modellen, kan påvirke outputtet, selv i læringseksemplerne, takket være recency bias. Prøv forskellige muligheder for at se, hvad der fungerer bedst. |
| Giv modellen en "udvej" | Giv modellen et fallback-svar, den kan give, hvis den af en eller anden grund ikke kan fuldføre opgaven. Dette kan reducere chancerne for, at modeller genererer falske eller fabrikerede svar. |
Som med enhver bedste praksis, husk at din oplevelse kan variere afhængigt af modellen, opgaven og domænet. Brug disse som et udgangspunkt, og iterer for at finde ud af, hvad der fungerer bedst for dig. Genovervej konstant din prompt engineering-proces, efterhånden som nye modeller og værktøjer bliver tilgængelige, med fokus på proces-skalerbarhed og svar-kvalitet.
Tillykke! Du nåede til slutningen af lektionen! Det er tid til at teste nogle af de begreber og teknikker med rigtige eksempler!
Til vores opgave vil vi bruge en Jupyter Notebook med øvelser, du kan fuldfø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 repoen til din lokale enhed og brug den med Docker Desktop
- (Alternativt) Åbn Notebooken med dit foretrukne Notebook runtime-miljø.
- Kopier
.env.copy-filen i 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 mulighederne 1 eller 2, skal du blot vælge standard Python 3.10.x-kernen, der leveres af udviklingscontaineren.
Du er klar til at køre øvelserne. Bemærk, at der ikke er rigtige og forkerte svar her - bare udforskning af muligheder gennem forsøg og fejl og opbygning af intuition for, hvad der fungerer for en given model og applikationsdomæne.
Af denne grund er der ingen kode-løsningssegmenter i denne lektion. I stedet vil Notebooken have Markdown-celler med titlen "Min løsning:" der viser et eksempeloutput som reference.
Hvilken af følgende er en god prompt, der følger nogle rimelige bedste praksis?
- 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 solnedgang
- 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 et specifikt mærke og model), og den beskriver også den overordnede setting. 3 er næstbedst, da den også indeholder mange beskrivelser.
Se om du kan udnytte "ledetråd"-teknikken med prompten: Fuldfør sætningen "Vis mig et billede af en rød bil af mærket Volvo og ". Hvad svarer den med, og hvordan ville du forbedre det?
Vil du lære mere om forskellige begreber inden for Prompt Engineering? Gå til siden for fortsat læring for at finde andre gode ressourcer om dette emne.
Gå videre til Lektion 5, hvor vi vil se 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 automatiserede 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 er ikke ansvarlige for eventuelle misforståelser eller fejltolkninger, der opstår som følge af brugen af denne oversættelse.