Hvordan kan din bedrift komme i gang med generativ AI?
Les hvordan PwC har utviklet en applikasjon for bruk av generativ AI i praksis
Den siste tiden har generative AI-modeller tatt verden med storm. Disse avanserte modellene, som blant annet store språkmodeller, Large Language Models (LLM), representerer et betydelig fremskritt i evnen til å generere realistisk og kontekstsensitivt innhold. Dette har utvidet mulighetsrommet for hvordan vi jobber med og tilnærmer oss problemstillinger i både privat- og arbeidslivet. Flere bedrifter tar nå grep for å bli med på utviklingen og vil utforske hvordan generativ AI kan tilpasses til deres egen bedrift, men det å utvikle og fine-tune generative AI-modeller er både tidkrevende og ressurskrevende. Et stadig mer populært alternativ i denne utviklingen er å ta i bruk Retrieval-Augmented Generation (RAG). Her kombineres de generative egenskapene til eksisterende LLM-er med et informasjonsinnhentingssystem for å tilpasse og forbedre konteksten. Denne artikkelen vil ta for seg noen av utfordringene man kan støte på i generative AI-modeller, konseptet RAG og hvordan RAG kan brukes til å mitigere en del av disse utfordringene, samt et eksempel på hvordan man kan komme i gang med utviklingen selv og hvordan PwC har jobbet med å utvikle RAG i kundesammenheng.
Hva er RAG?
RAG tar sikte på å forbedre kontekstforståelsen ved å integrere en egen kunnskapsdatabase. Dette gjør at modellen kan trekke informasjon fra eksterne og interne kilder for å berike genererte svar. Resultatet er ikke bare imponerende tekstproduksjon, men også en dypere forståelse av konteksten som gir større nytteverdi i en rekke bruksområder. Det er her det blir mulig for bedrifter å tilpasse bruken av gode, eksisterende generative AI-modeller til spesifikke problemstillinger som er relevante for deres egen virksomhet.
RAG er modellagnostisk, som vil si at de ved enkle tilpasninger kan fungere likt uavhengig av valg av språkmodell. Man kan altså velge blant både open-source modeller som Llama-3 og closed-source modeller som GPT-4o, og dermed velge det som egner seg best for ønsket bruk. I tillegg kan man selv styre data som modellen får tilgang til, og på denne måten enkelt kunne anonymisere kunnskapsdatabasen der det er ønskelig. RAG er også høyst fleksibelt, da man enkelt kan legge til og endre innholdet i kunnskapsdatabasen. På denne måten kan man lett tilpasse bruken av modellen til et større bruksområde for å kunne løse flere problemer for bedriften.
RAG kan unngå flere av utfordringene man kan støte på i store språkmodeller
Det er flere utfordringer knyttet til store språkmodeller, og noen av dem har du kanskje støtt på selv ved bruk av for eksempel OpenAIs Chat GPT. Ettersom de store språkmodellene hovedsakelig er trent på engelsk tekst, så er det naturligvis engelsk modellene presterer best på. Man kan derfor oppleve at tekst produsert på et annet språk enn engelsk eller andre språk som utgjør store deler av treningsgrunnlaget kan være mangelfullt. For eksempel så er kun ca. 0.03% av treningsgrunnlaget til open-source modellen Llama-2 på norsk¹. Dette kan føre til at generert norsk tekst mangler en naturlig flyt i språket, som man kanskje forventer av en som har norsk som sitt morsmål. Det er også lignende utfordringer knyttet til fagspråk og bransjesjargong, hvor modeller kan slite med å forstå tekniske begreper innenfor et fagområde eller bransje. Dette kan oppstå når det er begreper som enten kun brukes innad i en bedrift eller i en mer spesifikk bransje. Det er da ikke noen garanti for at de store språkmodellene har disse kildene som en del av sitt treningsgrunnlag. Løsningen på disse utfordringene kan være å fine-tune modellen på norske kilder og rapporter innenfor det spesifikke fagområdet, for å tilpasse både språk og kjennskap til tekniske fagbegreper.
Den største utfordringen knyttet til store språkmodeller er det som kalles hallusinasjoner. Dette oppstår når modellen produserer tekst som enten er misvisende eller direkte feil. Det er flere årsaker til dette, men den viktigste årsaken ligger i selve oppbygningen av modellene. Modellene er til dels probabilistiske, det vil si at ved tokengenerering for å finne neste ordet i en setning, så velger man fra en sannsynlighetsfordeling av alle mulige neste ord i tillegg til at det er lagt til tilfeldighet i utvalget, slik at det ikke alltid er det “mest sannsynlige” ordet som blir valgt. Dette gjør at modellene ikke alltid produserer den samme teksten til samme prompt, men kan også føre til at feil oppstår i teksten. En annen årsak til at hallusinasjoner kan oppstå er at noen av kildene modellen er trent på ikke er korrekte. Det er mye tekst og informasjon tilgjengelig, men det er ingen garanti for at alt som står skrevet ned er fakta eller moralsk og etisk rett. Dette problemet kan unngås ved menneskelig verifisering av datagrunnlag, noe som kan være svært ressurskrevende.
For å utnytte mulighetene knyttet til generativ AI, så må man ha kjennskap til både fordeler og utfordringer knyttet til modellene som er tilgjengelige for oss. Utvikling og tilpasning av de store språkmodellene gjennom fine-tuning kan motvirke flere av utfordringene man ofte støter på, men kan være både tid- og ressurskrevende. Et alternativ til mer omfattende fine-tuning er RAG, som muliggjør enklere tilpasning av allerede eksisterende språkmodeller til mer spesifikke formål, og bidrar til å unngå flere av disse utfordringene, enkelt og effektivt.
Hvordan jobber vi med RAG i PwC?
PwC har blant annet utviklet en chatbot som skal svare på brukerens spørsmål med utgangspunkt i lovdata og generativ AI, uten at brukeren trenger å gå gjennom flere steg for å få svar og ingen saksbehandler trenger å være involvert. Dette gjøres ved at boten finner relevante avsnitt fra lovdata basert på et spørsmål fra bruker, og sender de relevante avsnittene sammen med spørsmålet fra bruker og en prompt til OpenAI. Dette sørger for at brukeren får et svar som er oppdatert på relevante forskrifter og lover som gjelder i Norge, og slipper å inkludere saksbehandler eller manuelt lete gjennom lovverk før man kan få et svar. Vi har også bistått i utvikling av en modell som tar inn offentlige anbud innen vei og vedlikehold, og bruker disse til å la brukeren stille spørsmål rundt anbudene, få raskt oversikt og kartlegge mulige ulemper/fordeler med anbudet.
I utviklingen av RAG-modellene har vi inkludert mange i PwC, uten spesiell tech-bakgrunn, og fått disse til å tilpasse modellene etter sine egne ønsker. Dette understreker hvor enkelt en RAG-modell kan brukes og tilpasses til forskjellige formål, uten at det krever spesiell kompetanse innen apputvikling.
Hvordan utvikle RAG selv
Ved bruk av RAG kan man enkelt ta i bruk egne data uten videre trening av språkmodellene. Enkelt forklart lagres interne data i en kunnskapsdatabase som modellene kan slå opp i. Microsoft lanserte nylig “Vector Search in Azure AI”, noe som muliggjør RAG i storskala i eksisterende Azure-miljø. Dette gjør RAG enda mer aktuelt for norske bedrifter som allerede bruker Azure. I utviklingen av RAG kan man enkelt inkludere personer både med og uten utviklerbakgrunn, noe som åpner for bedre integrasjon mellom forretning og teknologi i bedrifter. Vi har selv inkludert folk med forskjellig bakgrunn i utviklingen av RAG, hvor disse har laget sin egen versjon og tilpasset modellen sine egne ønsker. Dette understreker hvor lett man kan utforske mulighetene og skape verdi med RAG.
Det er flere måter å utvikle RAG på, og følgende er kun et eksempel som er ment å illustrere hvordan man kan komme i gang med RAG selv. Det er mange muligheter for å utvikle applikasjoner som baserer seg på store språkmodeller. LangChain er et stadig mer populært alternativ hvor utviklingsprosessen forenkles ved at blant annet modeller, vektordatabase og tekstbehandling og -innlasting gjøres i én løsning. Det er også mulig å kombinere forskjellige løsninger for innlasting, vektordatabase og modell, og på denne måten få mer kontroll over alle delene av den endelige løsningen. Sistnevnte er fremgangsmåten tatt i dette eksempelet. Det anbefales å implementere applikasjonen i en brukervennlig UI, som kan lages enkelt med Chainlit, eller med litt mer innsats med blant annet React.
- Opprette embeddingsdatabase for interne data
Det første steget er å opprette en kunnskapsdatabase med interne data. Den kan inkludere blant annet rapporter, chat-logger, tilbud eller anbud. Her anbefaler vi å lage en embeddingsdatabase hvor all data blir gjort om til embeddings. Embeddings er vektorer som bevarer informasjon, semantiske forhold eller kontekst fra data når det konverteres fra tekstformat til tallformat. Disse vektorene kan deretter plasseres i et vektorrom basert på innholdet i teksten, og på denne måten være “nærmere” andre tekster som har likheter i innholdet. Vi har valgt å bruke open-source-produktet Chroma DB som er et enkelt og gratis alternativ til embeddingsdatabase, og brukt OpenAI sin egen embeddingsmodell text-embedding-ada-002 for å omgjøre tekst til embeddings.
2. Konvertere spørsmål til vektor og slå opp i kunnskapsdatabasen
Når brukeren stiller et spørsmål til modellen, så må spørsmålet konverteres til embedding, med samme embeddingsmodell som ble brukt for å opprette kunnskapsdatabasen. Deretter gjøres det et oppslag i kunnskapsdatabasen for å finne de n tekstene i databasen som ligner mest på spørsmålet brukeren stilte. Dette gjøres ved å finne de n embeddingene i databasen som har kortest relativ avstand til embeddingen av spørsmålet. Denne avstanden kan regnes ut på flere måter, men avstandsfunksjonen cosine similarity er et populært valg.
3. Sende spørsmål med beriket kontekst inn i en stor språkmodell
Etter at resultatet med de mest relevante tekstene er returnert, så konverteres disse tilbake til tekstformat. Spørsmålet som brukeren originalt stilte blir sent inn i en språkmodell, f.eks. gjennom openAI sitt API, sammen med de mest relevante tekstene som kontekst. Resultatet vil være et svar generert av språkmodellen, som er tilpasset konteksten hentet fra kunnskapsdatabasen. Dette reduserer sjansen for at modellen ikke forstår tekniske begreper og fagspråk, og øker resultatets relevans for bedriftens virksomhet. Resultatene som blir presentert inkluderer også vedlagte kilder, slik at du kan dobbeltsjekke hvilke kilder og hvilke n tekster som ble benyttet for å besvare spørsmålet.
Konklusjon
Det skjer fortsatt mye innen generativ AI og RAG, og OpenAI sin GPT-4 har nå funksjonalitet for å legge til kilder som brukes som kontekst i svarene. Dette er en form for RAG, og kan gjøre at man motvirker hallusinasjoner og får svar som er bedre tilpasset ønsket bruksområde. Dette åpner for mange muligheter, men dersom man ønsker å utvikle et produkt med tilleggsfunksjonalitet og en kunnskapsdatabase som inneholder både intern og ekstern data, så vil ikke dette være tilstrekkelig. RAG er en enkel og effektiv måte å kombinere generative egenskaper fra store språkmodeller med en kunnskapsdatabase skreddersydd til bedriftens ønsker. Disse modellene kan utvides ved å implementere tilleggsfunksjonalitet gjennom andre API’er, som for eksempel kartvisning, henting av værdata og trafikksituasjon, noe som kan øke nytteverdien for bedriften ytterligere.
RAG muliggjør enkel utforsking og bruk av generativ AI, tilpasset ditt ønskede formål. Det er mange mulige bruksområder og er langt mindre ressurskrevende enn tradisjonell utvikling av modeller for generativ AI. For å lykkes med generativ AI og RAG stilles det store krav til data management, data governance, dataplattform og organisering. Og i likhet med OpenAI og utviklingen av ChatGPT, vil det være nødvendig med en del manuelt arbeid for å etablere et godt datagrunnlag som maskiner kan bruke til å lære.
Ta gjerne kontakt om du er interessert i å høre mer om vårt arbeid innen generativ AI og RAG og hvordan vi kan hjelpe deg og din bedrift med å komme i gang med dette selv!
Les også:
Kilder:
¹Llama 2: Open Foundation and Fine-Tuned Chat Models
