Store Språkmodeller (LLM-er) som GPT har blitt stadig mer populære. Disse modellene kan gi imponerende resultater innen tekstgenerering og naturlig språkforståelse.
Vi gjennomførte nylig en case hvor vi fikk erfaring med å bruke Volue sitt API for å predikere strømdata og Azure OpenAIs GPT 3.5-Turbo modell for å utvikle en app som kunne gi tekstlige råd om optimal strømbruk.
Under arbeidet med denne appen møtte vi flere utfordringer knyttet til begrensningene til modellen. Vi fant ut at å bare presentere rå data til språkmodellen ikke var den beste tilnærmingen.
I dette blogginnlegget vil vi presentere 3 tips for hvordan data kan behandles før den sendes til språkmodellen. Disse tipsene kan føre til færre feil, bedre svar fra språkmodellen samt redusert ressursbruk.
#1. Fjern irrelevant data
Irrelevant data har en evne til å forstyrre mennesker og få mennesker til å gi feil svar på problemer. Spesielt data som ligner på problemet som skal løses. Ut ifra vår erfaring har også språkmodeller denne svakheten.
Schibsted ut mot AI-lov: - Frykter monopol
Nedenfor er et forenklet eksempel hvor vi har hentet JSON data fra et API som sier noe om energikilder og CO2-kompensasjon. Vi er ikke opptatt av CO2-kompensasjon i den tenkte løsningen, kun om energikildene i seg selv er bærekraftig. Det er allikevel med i API-et fordi en annen løsning som også konsumerer API-et har bruk for feltet:
Bruker:
"Vi har data for strømbruk i en by for tre dager:
[ {“dato” : “1.mai”, “forbruk” : {“sol” : 10, “vann”: 20, “kull”:5}, “CO2Kompensert”: false}, {“dato” : “2.mai”, “forbruk” : {“sol” : 0 “vann”: 0, “kull”:30} “CO2Kompensert”:true}, {“dato” : “3.mai”, “forbruk” : {“sol” : 20, “vann”: 5, “kull”:0}, “CO2Kompensert”:false}, ]
Ranger de tre dagene etter bruk av mest og minst bærekraftige energikilder forbrukt. Svar med kun en oppsummering på en paragraf."
AI-Assistent:
"I løpet av de tre dagene i mai ble strømbruket i byen registrert sammen med informasjon om energikildene som ble brukt. Basert på dataene, var den første dagen preget av høy bruk av fossile brenselkilder, spesielt kull, med 20 enheter for sol og 10 enheter for vann. Den andre dagen ble imidlertid energibruken kraftig redusert, men den ble ikke oppgitt noen verdier for sol og vann, mens hele 30 enheter av kull ble brukt. På den siste dagen var det en betydelig økning i bruk av fornybare energikilder med 20 enheter for sol og 5 enheter for vann, og ingen kull ble brukt. Når det gjelder CO2-kompensasjon, ble den bare utført på den andre dagen. Samlet sett kan vi si at den første dagen var den minst bærekraftige med"
Derfor må du hjelpe brukerne dine med AI-chat
I eksempelet over så gir AI-assistenten et svar som inkluderer CO2-kompensasjon selv om vi spurte om bruk av energikilder.
En løsning her kan være å skrive en bedre prompt der vi sier for eksempel «se bort ifra CO2 kompensasjon». Den løsningen vil fungere i vårt forenklede eksempel, men jeg vil ikke anbefale den tilnærmingen. I et mer komplisert eksempel kan det være at språkmodellen skal si noe om CO2-kompensering uten å bruke feltet “CO2Kompensert”. Da kan prompten fort bli komplisert.
Det er enklere og bedre å bare fjerne dataen før den i det hele tatt kommer inn til språkmodellen. Da blir prompten forenklet og en feilkilde eliminert.
#2. Velg et kompakt dataformat
Vi opplevde at vår modell slet når vi skulle ta inn enda mer kontekst. Språkmodellen begynte å glemme kontekst. Vi fant ut at det er en begrensning på hvor mange tokens man kan sende, som er referert som token limit.
For modellen vi brukte så blir de første tokens ikke med når denne grensen nåes. Derfor oppleves det som at instruksjoner glemmes. Vi trengte grep for å spare tokens i prompten.
Hver eneste tekst har tokens, som benyttes for tolkning av teksten i maskinlæring. Tokens representerer hvert enkelt element i teksten, og inkluderer alle tegn og symboler. JSON-lister som vi bruker her kan ha flere tokens enn andre formater. Dette er i hovedsak på grunn av gjentakelse av nøkkelverdier, og ekstra mellomrom.
Det kan være nyttig å minimere unødvendige tegn eller symboler i datasettene. Jo mer komplekse og større datasettet er, jo mer tid og ressurser vil modellene trenge. Derfor er det viktig å sørge for at datasettene er så rene som mulig, og at det ikke er noen unødvendige tegn eller symboler som kan føre til unødvendig belastning for språkmodellen.
«Vi gikk derfor over til CSV-formatet og opplevde at vi sparte tokens.»
Da vi brukte en tabell i CSV format istedenfor en JSON liste for å spare tokens, fikk vi mye bedre resultat:
[ {"dato" : "1.mai", "forbruk" : {"sol" : 10, "vann": 20, "kull":5} }, {"dato" : "2.mai", "forbruk" : {"sol" : 0 "vann": 0, "kull":30} }, {"dato" : "3.mai", "forbruk" : {"sol" : 20, "vann": 5, "kull":0} } ]
dato,sol,vann,kull
1.mai,10,20,52.mai,0,0,303.mai,20,5,0
JSON-formatet her gjentar nøklene, som for eksempel «dato» flere ganger. Dette er fordi JSON-formatet er laget for å være lesbart for mennesker. CSV-formatet er derimot mer kompakt fordi den blant annet ikke gjentar nøkkelverdier.
Vi gikk derfor over til CSV-formatet og opplevde at vi sparte tokens. Dette var en mye bedre løsning enn å droppe kontekst.
#3. Bryt opp problemet og vurder programmering
Vi prøvde i begynnelsen å bare lage en stor prompt som tok all konteksten, løste hele problemet og gav nye muligheter til å chatte med svarene som det gav.
Dette viste seg å være vanskeligere enn vi trodde, og det gav ikke resultatene vi ønsket. Dette tror vi er fordi at problemet var for vanskelig å løse for språkmodellen. Problemet bestod av både språklige og algoritmiske aspekt.
Hvis man står overfor et problem som er satt sammen av både språklige og algoritmiske aspekt, kan det ofte lønne seg å bryte opp problemet. Språkmodeller kan brukes til å løse det språklige aspektet av problemet, mens programmering kan benyttes for å håndtere det algoritmiske.
Reglene rammer også norske utviklere
For eksempel, så klarte ikke GPT-3.5 å finne ut hvilken ukedag dataene gjaldt. JSON data var oppgitt i dato. Vi brukte da programmering for å oversette dato til ukedag, og sendte dette videre til språkmodellen.
Det kan imidlertid hende at det ikke er tilstrekkelig å bare bryte opp problemet i disse to delene. I noen tilfeller kan det også være hensiktsmessig å bryte opp det språklige problemet ved å bruke flere kall til språkmodeller. Dette kan sammenlignes med hvordan du bryter opp algoritmiske problemer i ditt favorittprogrammeringsspråk ved hjelp av flere funksjoner eller metoder.
Å gjøre dette vil bidra til å redusere belastningen på hver enkel språkmodell og gi mer nøyaktige og effektive resultater når man arbeider med komplekse problemstillinger.
Å jobbe med nye teknologier er både spennende og utfordrende. Det har skjedd en rask utvikling på feltet og vi har lært mye. Hvis du har lyst til å bruke språkmodeller med data-input i ditt prosjekt, så anbefaler vi at du først prosseserer data til et format som er lett å lese for språkmodellen. Det vil si et kompakt format uten irrelevante felt, som er behandlet for å redusere behovet for algoritmisk problemløsning fra LLM-en.
Lykke til!
