Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Store sprogmodeller som GPT – også kaldet ”large language models” eller ”LLMs”, er generelle.
Man kan tale om alt med dem, og de kommer ikke med et særligt fokus på et bestemt emneområde eller domæne.
Derfor hører jeg tit folk spørge om, hvorvidt de burde lave deres egen sprogmodel på deres egne data, så den kan svare bedre og mere specifikt på forespørgsler hertil.
Men i spørgsmålet ligger der allerede nogle potentielle misforståelser, for det kan sjældent betale sig at træne en stor sprogmodel helt fra bunden på egne data, selv om det faktisk er muligt med de gratis open-source sprogmodeller som findes i dag, såsom Llama 3, Mistral 7B, osv.
Det er dog et kæmpe arbejde, kræver voldsom computerkraft, og man står ofte selv for ting som sikkerhed og skalerbarhed.
For de fleste virksomheder og organisationer vil det i stedet give meget bedre mening at udvide den eksisterende sprogmodel sammen med ens egne sproglige data, således at den hovedsageligt svarer ud fra ens egen vidensbase, men samtidigt bevarer den styrke der ligger i den generelle sprogmodel, inkl. sikkerhed og skalerbarhed.
Dette kaldes ofte en RAG arkitektur (Retrieval Augmented Generation), og kan for eksempel laves i Microsoft’s Azure platform ved brug af blandt andet Azure OpenAI Services.
Et eksempel
Et eksempel kunne være en virksomhed som løbende håndterer en stor mængde sager, og derfor har oparbejdet en kæmpestor vidensbase af færdigbehandlede sager.
Disse sager er ret specifikke for virksomheden eller i det mindste deres domæne/branche/område, og er ikke blevet støvsuget ned og medtaget i den enorme mængde tekst, som de generelle sprogmodeller er trænet på.
Med en RAG-arkitektur vil de kunne bede den generelle sprogmodel kigge på deres custom vidensbase af færdigbehandlede, historiske sager beskrive forholdene rundt om en ny indkommen sag, og få genereret en kladde til den nye sag baseret på de eksisterende.
Kombinerer man dette med intelligent søgning såsom AI Search (tidligere kaldet Semantic Search), kan man endda få den til at pege på den håndfuld sager, som den har lagt sig mest op af i den review-proces, der følger.
For man vil nemlig oftest skulle tænke en sådan RAG-implementering som blot et værktøj til at generere en 80-90 procent færdig kladde, som skal rettes til af en menneskelig part.
Selv om det også kommer an på emne, kompleksitet og sprogmodel, vil jeg vove at sige, at selv med de store fremskridt, vi har set i feltet, er store sprogmodeller ikke der, hvor det særlig tit er en god ide at fuldautomatisere den slags processer.
Til gengæld kan man spare meget tid ved at få genereret en kladde, og ofte vil de etiske og juridiske rammer alligevel kræve, at det er et menneske, der sætter det endelig stempel.
Prøv selv
Hvis man har lyst til at prøve kræfter med dette, kan man ChatGPT i dag lave sin egen RAG-arkitektur.
Det er overraskende nemt, fordi meget af det arbejde der skal til er automatiseret.
Alt man skal gøre er at trykke ”Create” under MyGPTs, udfylde fritekstfektet med instruktioner (punkt 1) - lidt som når man forklarer en ny receptionist hvordan denne skal modtage gæster, og så uploade ens vidensbase i form af tekstfiler som den skal svare ud fra (punkt 2).
Jeg har for eksempel på denne måde lagt min eget forskningsmateriale op og lavet en GPT, der svarer på spørgsmål om min forskning og mine ideer om fremtiden AI på www.erk.dk.
Lige som på YouTube kan man endda tjene penge hvis mange brugere snakker med ens GPT, som man har gjort offentlig tilgængelig i OpenAIs ”Custom GPT Store”, og nu hvor OpenAI lige har besluttet at gøre denne tilgængelig for alle de gratis ChatGPT brugere også, snakker vi altså over 180 millioner brugere.
Over på Azure eller noget tilsvarende
Skal man bruge det seriøst til sin forretningskritiske og GDPR-sensitive data, er man dog nødt til at flytte sig ud af ChatGPT og over på sådan noget som Azure OpenAI Services, eller lignende.
Det vigtigste argument herfor er som sagt sikkerhed og GDPR, men derudover har man heller ikke den samme kontrol over løsningen i ChatGPT.
Eksempler på ting, man skal ud af ChatGPTs legekasse for at gøre, kunne være at opsætte en data pipeline – med andre ord, at sprogmodellen altid svarer på de nyeste data der er kommet ind i ens egen vidensbase.
Det kunne også være førnævnte fremhævelse af, hvilke dele af vidensbasen et svar eller kladde er baseret på.
Sidst men ikke mindst så mangler man også muligheden for at kunne indarbejde løsningen i diverse processer rundt omkring (se også her min tidligere klumme om Generativ AI og klassisk Machine learning).
Alle disse er meget vigtige i nutidens virksomheder og organisationer og grunden til, at dette er en af de mest populære AI-projekter, jeg ser blive implementeret i dag.
Et yderligere behov, jeg dog ser mange kæmpe lidt med, er så, at vidensbasen gerne skal kunne indeholde mere end bare sproglige data såsom tabeller og deciderede datasæt.
Denne type kvantitative data (tal, kategorier, etc.) håndteres ikke så godt af store sprogmodeller i dag – med mindre man benytter en helt særlig, nyere feature i sprogmodellernes verden kaldet ”Code Interpreter”.
Men hvad det er, og hvilke muligheder det repræsenterer nu og på sigt, bliver emnet for den næste klumme i vores føljeton om Generativ AI i Praksis.
Læs de to første klummer i serien her:
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
