Systempromptlæring: et nytt paradigme for KI-systemer

Har du opplevd at en bestemt prompt fungerer godt, men så plutselig slutter å virke?

Har du havnet i en runddans der du stadig lapper på systemprompten for å forbedre resultatene, men ingenting virker?

Systempromptlæring kan være akkurat det du trenger.

Systempromptlæring (SPL) er et nytt interesseområde i KI-miljøet og ble gjort allment kjent av Andrej Karpathy på X i mai.

Systempromptlæring tar tak i begrensningene ved lite fleksible og sårbare KI-systemer som er avhengige av statiske systemprompter eller tungvinte oppsett for finjustering. Det gir en alternativ måte å støtte kontinuerlig læring i KI-systemer på.

Før vi går i dybden, tar vi en kort gjennomgang av det grunnleggende ved prompter.

Når vi utvikler en agent eller en tilpasset modell, må vi først utforme to sentrale komponenter:

1. En systemprompt

2. En brukerprompt

Systemprompter fastsetter grunnreglene for hvordan en modell skal opptre. Når de skrives for tilpassede KI-løsninger, begynner de ofte omtrent slik:

“You are an intelligent assistant. Your role is to perform <insert task here>.

You must not do (A), (B), or (C).”

Brukerprompter inneholder derimot vanligvis brukerens spørsmål og annen relevant informasjon, som tidssone og preferanser. En brukerprompt kan se slik ut:

I’m in the capital city of Portugal. Can you suggest some things I can do tonight?

Lekkasjer av systemprompter har blitt vanlige etter lanseringer av nye modeller fra store KI-laboratorier, fordi brukere jailbreaker chatboter for å avsløre de underliggende instruksjonene. Et populært GitHub-lager samler nå mange av disse systempromptene på ett sted. De avslører «hemmeligheten» KI-laboratoriene over tid har utviklet for å fremme hensiktsmessig modellatferd. Den nylig lekkede systemprompten for GPT-5 (avslørt i ChatGPT) inneholder for eksempel rundt 6000 ord. Det viser hvor mye kunnskap og veiledning som må bygges inn for å forme systemets atferd.

Slike omfattende systemprompter dekker vanligvis flere sentrale områder, blant annet:

• Søkeinstruksjoner

• Verktøydefinisjoner

• Brukerpreferanser

• Instruksjoner for kildehenvisninger

• Hurtigrettelser for kjente problemer

I praksis lapper utviklere av tilpassede KI-systemer systempromptene manuelt i flere omganger mens de tester og forbedrer løsningene sine. De bruker hovedsakelig evalueringer til å styre denne prosessen.

Andre måter å styre atferden til en modell på er:

• Promptutforming, inkludert hentingstøttet generering (RAG), som styrer innholdet modellen får tilgang til

• Finjustering (direkte endring av modellens underliggende vekter)

Hva om det fantes en annen måte å påvirke modellatferden på? Tenk deg et system som dynamisk lærer og forbedrer sin egen systemprompt ved hjelp av tidligere genererte tanker, planer og strategier. Det kan bruke både tilbakemeldinger fra brukere og evalueringer med LLM som dommer til å vurdere resultatene sine.

Tenk på en vedvarende forretningsutfordring du vil automatisere ved hjelp av et agentbasert system. Effektive løsninger krever resonneringsevner utover enkel automatisering av arbeidsflyter. I slike tilfeller er det avgjørende å innlemme en komponent for plangenerering i KI-systemet. Da kan systemet samarbeide med flere agenter på ulike måter, avhengig av oppgaven. Enkelte trinn kan inneholde instruksjoner om å bruke andre agenter til å utføre deloppgaver eller om å bruke verktøy.

Merk: Et agentverktøy er en ekstern funksjon, et API eller en ressurs som en KI-agent kan kalle for å gå utover tekst og utføre reelle handlinger.

Du kan velge å «så» modellens systemprompt med en plan som følger de logiske trinnene et menneske ville tatt. LLM-er trenger imidlertid vanligvis mer konkret veiledning om bruk av verktøy, formatering av resultater og lignende krav. Noen ganger er den optimale strategien uklar, eller du arbeider med et problem som ikke har blitt vurdert på nytt fordi det tidligere ble ansett som løst. Det er her systempromptlæring (SPL) kommer inn.

SPL forbedrer en systemprompt trinnvis ved å innlemme tidligere genererte strategier. Etter hvert som nye problemer oppstår, samler systemet gradvis kunnskap og blir mer robust. Tenk på det som å lage en håndbok for problemløsning innenfor fagområdet ditt.

SPL innlemmer gradvis innsikt fra brukernes tilbakemeldinger i systemprompten. Etter hvert som systemet modnes, kan du oppdage tilbakevendende problemer som kan omformes til mer generelle og overordnede prinsipper.

La oss se nærmere på hvordan prosessen fungerer, trinn for trinn:

1. Begynn med brukerens spørsmål, der systemet blir bedt om å utføre en bestemt oppgave.

2. 1. Hvis systemet bare håndterer ett problem, kan du velge en «grådig» tilnærming og bruke strategiene med høyest poengsum fra tidligere kjøringer. Du kan også oppmuntre til utforsking ved å gjøre et utvalg fra en fordeling som favoriserer høyt vurderte strategier, men av og til tar med svakere vurderte alternativer. Dette er spesielt nyttig når du nettopp har begynt å samle inn strategier.

   2. For systemer som skal håndtere ulike problemområder, kan du legge til et klassifiseringslag eller bruke embeddings og cosinuslikhet – de samme teknikkene som vanligvis brukes i RAG – for å finne relevante fremgangsmåter. Dette hjelper deg med å velge strategier som passer til det konkrete problemet, for eksempel strategier tilpasset programmeringsoppgaver.

Merk: Embeddings brukt sammen med cosinuslikhet gjør det mulig å måle hvor nært to informasjonsbiter henger sammen. Dermed blir det enklere å koble sammen dokumenter, spørsmål eller ideer, selv når ordlyden er forskjellig.

Eksempel på et enkelt utgangspunkt for et strategilager til programmeringsproblemer.

Merk: «Startstrategiene» som vises her, er bare eksempler. I reelle programmeringssituasjoner ville vi ha forbedret dem ytterligere. Smalere forretningsproblemer krever at man samler inn mer innsikt over tid.

3. Når du har valgt N, innlemmer du dem i systemprompten. Dette forankrer plangenereringen i tidligere tilbakemeldinger fra eksperter i stedet for å overlate til modellen å lage planer med minimal veiledning. Oppmuntre modellen til å «tenke utenfor boksen» og legge til trinn ved behov, i stedet for bare å kopiere eksempelstrategiene ordrett.

4. Bruk den dynamisk opprettede systemprompten til å generere en ny strategi for å håndtere brukerens forespørsel. Denne prosessen bør gi flere oppgaver som forbedrer det endelige resultatet. Målet er kreativitet: Kombiner de beste elementene fra tidligere strategier, slå sammen overlappende trinn og legg til nyttige trinn ved behov.

Merk: Husk at temperatur er en parameter som kan justeres for å gi mer varierte og mindre deterministiske resultater, noe som er nyttig når man ønsker kreativitet. Når temperaturen er høyere enn null, kan hver genererte plan bli forskjellig.

5. Når du har mottatt resultatet fra modellen, får du en person eller en LLM-dommer til å evaluere det ut fra bestemte kriterier som definerer en god løsning på problemet. For eksempelet med aktiviteter i Portugal som ble nevnt tidligere, kan evalueringskriteriene være:

• Kortfattethet (et svar begrenset til én setning)

• Hvor relevant den foreslåtte aktiviteten er

• Geografisk nøyaktighet

6. Bruk en annen modell til å forbedre strategien på grunnlag av evalueringen. En valgfri tilbakemeldingssløyfe kan innlemme menneskelige innspill og støtte felles forbedringer. Lagre den forbedrede strategien i databasen med egnede metadata for å spore versjoner og endringer.

Hvorfor gjøre seg alt dette bryet? Du kan gå gjennom resultatene manuelt og justere systemprompten deretter. Kraftige resonneringsmodeller kan imidlertid forbedre strategier ved hjelp av både konteksten rundt resultatet og tilbakemeldinger fra mennesker. Mennesker oppdager lett svakheter ved enkle fremgangsmåter, men i komplekse systemer som håndterer bredere problemområder, blir det både krevende og tidkrevende å finne dem.

LLM-er trenger ofte detaljerte instruksjoner og flere trinn for å innhente kontekstkunnskapen som mennesker naturlig tar med seg inn i et problem. Antallet nødvendige oppgaver kan vokse raskt når et system utvides til å håndtere bredere problemområder. Mennesker som løser programmeringsproblemer, kan for eksempel forstå den omkringliggende kodebasen intuitivt, mens en LLM først må «lese» flere filer.

• Når det hjelper: Tenk deg at du leder et kundestøtteteam, og at en KI-agent sorterer henvendelser. Over tid kan SPL avdekke en kategoriseringsmetode teamet ikke hadde vurdert, og dermed redusere andelen eskaleringer.

• Når det ikke hjelper: Hvis samsvarskrav eller regelverk allerede definerer arbeidsflytene, som ved finansiell rapportering, kan SPL gi liten verdi fordi kreativitet blir en ulempe snarere enn en styrke.

• Når det hjelper: I forskningsintensive roller, som markedsanalyse eller produktstrategi, kan du samarbeide med KI-en ved å forbedre planene, berike resultatene og ta vare på forbedringene for senere bruk. Hver samhandling gjør systemet mer effektivt.

• Når det ikke hjelper: Hvis teamet hovedsakelig bruker KI til enkle arbeidsflyter med få menneskelige innspill, for eksempel fakturabehandling, kan kostnaden ved samarbeidet overstige nytten.

• Når det hjelper: Tenk deg at du utvider til en ny region, og at KI-en plutselig må håndtere lokale skattespørsmål. Med SPL kan du raskt bygge inn nye regler og tommelfingerregler etter hvert som de oppstår, slik at feil ikke gjentas.

• Når det ikke hjelper: Hvis miljøet er statisk, som når møtereferater omgjøres til standardiserte sammendrag, gir kontinuerlig tilpasning liten nytte.

I teorien virker alt dette lovende, men det byr på reelle utfordringer å innføre SPL. Nedenfor ser vi på noen av de viktigste:

I de tidlige fasene av strategigenereringen stopper fremdriften ofte opp: Nye resultater bygger ikke videre på de forrige, og utviklingen mister fart. Dette skyldes vanligvis to hovedproblemer:

• • Løsning: Bygg inn all tilgjengelig forretningskunnskap fra starten, slik at systemet har et solid kunnskapsgrunnlag å trekke på.

• • Løsning: Utform detaljerte vurderingskriterier som måler flere sider ved et svar, som nøyaktighet, tydelighet og relevans, og tilpass utvalget etter disse signalene.

Hvis systemet genererer hundrevis av strategier, men får lite tilbakemelding som skiller de gode fra de dårlige, blir utvalget raskt uhåndterlig. Løsningen er beskjæring.

Når du forbedrer strategilageret, bør du vurdere:

• Levetid: Ta strategier ut av bruk når de overskrider en definert tidsramme eller et bestemt antall generasjoner.

• Poengsum: Bruk vurderingskriteriene til å filtrere bort strategier som gjennomgående gir svake resultater. Kombinert med levetid sikrer dette at du bare beholder fremgangsmåter som viser sin verdi over tid.

• LLM-vurdering: Vurder strategiene jevnlig for å finne dem som ikke lenger gir unik innsikt, fordi de nyttige elementene trolig allerede er tatt inn i nyere versjoner.

Løsning: Behandle strategidatabasen som et levende system: Beskjær den regelmessig, slik at bare relevant kunnskap av høy verdi blir værende.

Systempromptlæring er fortsatt på et tidlig stadium, men potensialet er enormt. Virksomheter som utelukkende baserer seg på statiske prompter eller endeløs finjustering, vil møte velkjente begrensninger: sårbare systemer, økende kostnader og bortkastet innsats. SPL gir en vei ut av denne runddansen ved å bygge systemer som forbedres over tid og lærer overordnede prinsipper fremfor enkeltstående rettelser.

SPL er fortsatt under utvikling, men retningen er klar: Systemer som kan lære av seg selv, vil utvikle seg raskere enn dem som ikke kan det. Nå er tiden inne for å eksperimentere, begynne i det små, ta vare på lærdommen og legge grunnlaget for KI-systemer som blir bedre for hver samhandling.