Fabrice AI: Nuværende teknisk implementering

I det sidste indlæg, Fabrice AI: The Technical Journey, forklarede jeg den rejse, vi gik igennem for at bygge Fabrice AI, og som var en fuld cirkel. Jeg startede med at bruge Chat GPT 3 og 3.5. Skuffet over resultaterne forsøgte jeg at bruge Langchain Framework til at bygge min egen AI-model oven på den, før jeg vendte tilbage til Chat GPT, da de begyndte at bruge vektordatabaser og massivt forbedrede resultaterne med 4o.

Her er den nuværende proces for træning af Fabrice AI:

  • Træningsdataene (blogindlæg, Youtube-URL’er, podcast-URL’er, PDF-URL’er og billed-URL’er) er gemt i vores WordPress-database.
  • Vi udtrækker data og strukturerer dem.
  • Vi leverer de strukturerede data til Open AI til træning ved hjælp af Assistants API.
  • Open AI opretter derefter en vektorlager-database og gemmer den.

Her er et eksempel på et stykke struktureret data. Hvert stykke indhold har sin egen JSON-fil. Vi sørger for ikke at overskride grænsen på 32.000 tokens.

{

“id”: “1”,

“dato”: ” “,

“link”:”https://fabricegrinda.com/”,

“title”: {

“gengivet”: “Hvad er Fabrice AI?”

  },

“Kategori”: “Om Fabrice”,

“featured_media”: “https://fabricegrinda.com/wp-content/uploads/2023/12/About-me.png”,

“andre_medier”: “”,

“viden_type”: “blog”,

“contentUpdated”: “Fabrice AI er en digital repræsentation af Fabrices tanker baseret på hans blogindlæg og udvalgte transskriberede podcasts og interviews ved hjælp af ChatGPT. I betragtning af at mange af transskriptionerne er ufuldstændigt transskriberede, og at bloggen kun er en begrænset repræsentation af Fabrice som person, undskylder vi unøjagtigheder og manglende oplysninger. Ikke desto mindre er dette et godt udgangspunkt for at få Fabrices tanker om mange emner.”

}

Det er den nuværende tekniske implementering:

  • Den forbrugerrettede hjemmeside er hostet på AWS Amplify.
  • Integrationen mellem det offentlige websted og Open AI sker via et API-lag, som hostes på AWS som en Python API-server.
  • Vi bruger MongoDB som log til at gemme alle de spørgsmål, som offentligheden har stillet, de svar, som Chat GPT har givet, og kildernes URL’er.
  • Vi bruger forskellige scripts til at strukturere data fra bloggen, YouTube osv. og sende dem til Open AI til træning.
  • Vi bruger React-Speech Recognition til at konvertere stemmeforespørgsler til tekst.
  • Vi bruger også Google Analytics til at spore trafikken på hjemmesiden.

Det er vigtigt at bemærke, at vi bruger to assistenter:

  • En til at svare på spørgsmål.
  • En til at hente metadata-URL’er, de blog-URL’er, der har det originale indhold, så kilderne kan vises nederst i svarene.

Hvad bliver det næste?

  1. Forbedringer af tale-til-tekst

Open AI’s Whisper-model til tale til tekst er mere præcis end React. Den understøtter også flere sprog fra start, og den er god til at håndtere tale på blandede sprog, accenter og dialekter. Derfor vil jeg højst sandsynligt gå over til den i de kommende måneder. Når det er sagt, er det mere komplekst at sætte op, så det kan tage et stykke tid. Du skal håndtere modellen, styre afhængigheder (f.eks. Python, biblioteker) og sikre, at du har tilstrækkelig hardware til effektiv ydelse. Whisper er heller ikke designet til direkte brug i browsere. Når du bygger en webapp, skal du oprette en backend-tjeneste til at håndtere transskriptionen, hvilket øger kompleksiteten.

  • Fabrice AI Avatar

Jeg vil gerne skabe en Fabrice AI-avatar, der ser ud og lyder som mig, og som man kan føre en samtale med. Jeg vurderede D-iD, men fandt det alt for dyrt til mine formål. Eleven Labs er kun til stemmer. Synthesia er fantastisk, men kan i øjeblikket ikke lave videoer i realtid. I sidste ende besluttede jeg at bruge HeyGen på grund af den mere passende pris og funktionalitet.

Jeg formoder, at Open AI på et tidspunkt vil udgive sin egen løsning, så dette arbejde vil have været forgæves. Det har jeg det fint med, og jeg vil skifte til Open AI-løsningen, når og hvis den kommer. På nuværende tidspunkt er pointen med hele denne øvelse at lære, hvad der er muligt med AI, og hvor meget arbejde det kræver for at hjælpe mig med at forstå området bedre.

  • Brugerdefineret dashboard

Lige nu har jeg brug for at køre en MongoDB-forespørgsel for at få et udtræk af dagens spørgsmål og svar. Jeg er ved at bygge et simpelt dashboard, hvor jeg kan få udtræk og simpel statistik over antallet af forespørgsler pr. sprog, antallet af tale-til-tekst-anmodninger osv.

  • Yderligere datakilder

Vi har lige uploadet FJ Labs-porteføljen til Fabrice AI. Du kan nu spørge, om en virksomhed er en del af porteføljen. Fabrice AI svarer med en kort beskrivelse af virksomheden og et link til dens hjemmeside.

I betragtning af antallet af personlige spørgsmål, som Fabrice AI fik, og som den ikke havde svar på, tog jeg mig tid til manuelt at tagge hver taler i min 50-års fødselsdagsvideo for at give den det indhold, den havde brug for.

Konklusion

Med alt det arbejde, jeg har udført i løbet af de sidste tolv måneder om alt, hvad der har med AI at gøre, synes der at være en klar universel konklusion: Jo mere du venter, jo billigere, nemmere og bedre bliver det, og jo mere sandsynligt er det, at Open AI vil tilbyde det! I mellemtiden må du endelig sige til, hvis du har spørgsmål.

Fabrice AI: Den tekniske rejse

Som jeg nævnte i det forrige indlæg, viste det sig at være langt mere komplekst end forventet at udvikle Fabrice AI, hvilket tvang mig til at udforske mange forskellige tilgange.

Den indledende tilgang: Llama-indeks – Vektorsøgning

Mit første forsøg på at forbedre Fabrice AI’s genfindingsevner involverede brugen af Llama-indekset til vektorsøgning. Konceptet var enkelt: at tage indholdet fra min blog, konvertere det til Langchain-dokumenter og derefter omdanne dem til Llama-dokumenter. Disse Llama-dokumenter ville derefter blive gemt i et vektorindeks, så jeg kunne søge efter relevante oplysninger i dette indeks.

Men da jeg begyndte at teste systemet, blev det tydeligt, at denne tilgang ikke gav de resultater, jeg havde håbet på. Når jeg stillede systemet konteksttunge spørgsmål som “Hvad er de største fejl, som iværksættere begår på markedet?”, kunne den kunstige intelligens ikke give meningsfulde svar. I stedet for at hente det nuancerede indhold, som jeg vidste var indlejret i dataene, returnerede den irrelevante eller ufuldstændige svar.

Denne første fiasko fik mig til at genoverveje min tilgang. Jeg indså, at det ikke var nok bare at gemme indhold i et vektorindeks; genfindingsmekanismen skulle forstå konteksten og nuancerne i de spørgsmål, der blev stillet. Denne erkendelse var den første af mange erfaringer, der kom til at forme udviklingen af Fabrice AI.

Opbevaring af viden: MongoDB dokumentlagring og -hentning

Med begrænsningerne i Llama Index-tilgangen i baghovedet undersøgte jeg derefter muligheden for at gemme Llama-dokumenterne i MongoDB. MongoDB’s fleksible skema og dokumentorienterede struktur virkede som en lovende løsning til at håndtere de forskellige typer indhold, jeg havde samlet i årenes løb.

Planen var at skabe en mere dynamisk og responsiv søgeoplevelse. Men denne tilgang løb hurtigt ind i problemer. Søgefunktionen, som jeg havde forventet ville være mere robust, fungerede ikke som forventet. Forespørgsler, der skulle have givet relevante dokumenter, gav i stedet ingen resultater eller irrelevant indhold.

Dette tilbageslag var frustrerende, men det understregede også en vigtig lektie: Opbevaringsmetoden er lige så vigtig som søgestrategien. Jeg begyndte at overveje andre muligheder, f.eks. at bruge MongoDB Atlas til vektorsøgninger, som potentielt kunne give den præcision og skalerbarhed, jeg havde brug for. Men før jeg besluttede mig for dette alternativ, ville jeg udforske andre tilgange for at finde ud af, om der måske var en mere effektiv løsning.

Metadata Retriever og Vector Store: På jagt efter specificitet

En af de næste muligheder, jeg udforskede, var brugen af en metadatahenter kombineret med et vektorlager. Ideen bag denne tilgang var at kategorisere den store mængde information i Fabrice AI og derefter hente svar baseret på disse kategorier. Ved at strukturere dataene med metadata håbede jeg at kunne forbedre AI’ens evne til at give specifikke, målrettede svar.

Men denne metode havde også sine begrænsninger. Selv om den virkede lovende på overfladen, kæmpede AI’en med at levere præcise svar på alle typer forespørgsler. For eksempel da jeg spurgte: “Er forfatteren optimistisk?” Systemet kunne ikke fortolke spørgsmålet i sammenhæng med det relevante indhold. I stedet for at give en indsigtsfuld analyse baseret på metadataene, returnerede det enten vage svar eller ingen.

Denne tilgang lærte mig en værdifuld lektie om betydningen af kontekst i AI. Det er ikke nok blot at kategorisere information; den kunstige intelligens skal også forstå, hvordan disse kategorier interagerer og overlapper hinanden for at skabe en sammenhængende forståelse af indholdet. Uden denne dybe forståelse kan selv de mest sofistikerede genfindingsmetoder komme til kort.

Strukturering af viden: Indekset SummaryTreeIndex

Da jeg fortsatte med at forfine Fabrice AI, eksperimenterede jeg med at skabe et SummaryTreeIndex. Denne tilgang havde til formål at opsummere alle dokumenterne i et træformat, så den kunstige intelligens kunne navigere gennem disse opsummeringer og hente relevante oplysninger baseret på indholdets struktur.

Tanken var, at AI’en ved at opsummere dokumenterne hurtigt kunne identificere nøglepunkter og svare på forespørgsler med kortfattet, præcis information. Men denne metode stod også over for betydelige udfordringer. AI’en kæmpede med at give meningsfulde svar på komplekse forespørgsler, såsom “Hvordan træffer man vigtige beslutninger i livet?” I stedet for at trække på det rige, nuancerede indhold, der var gemt i resuméerne, var AI’ens svar ofte overfladiske eller ufuldstændige.

Denne erfaring understregede, hvor svært det er at finde en balance mellem bredde og dybde i AI. Mens resuméer kan give et overblik på højt niveau, mangler de ofte den detaljerede kontekst, der er nødvendig for at besvare mere komplekse spørgsmål. Jeg indså, at enhver effektiv løsning ville være nødt til at integrere både detaljeret indhold og resuméer på højt niveau, så AI’en kunne trække på begge dele efter behov.

Det er derfor, jeg i den version af Fabrice AI, der er live i øjeblikket, lader AI’en først give et resumé af svaret, før den går i detaljer.

Udvidelse af horisonten: Vidensgraf-indeks

I erkendelse af de tidligere metoders begrænsninger vendte jeg mig mod en mere sofistikeret tilgang: Knowledge Graph Index. Denne tilgang involverede konstruktion af en vidensgraf ud fra ustruktureret tekst, hvilket gjorde det muligt for AI’en at foretage entitetsbaserede forespørgsler. Målet var at skabe en mere dynamisk og sammenkoblet forståelse af indholdet, så Fabrice AI kunne besvare komplekse, konteksttunge spørgsmål mere effektivt.

På trods af sit løfte stod Knowledge Graph Index også over for betydelige forhindringer. AI’en kæmpede med at producere nøjagtige resultater, især for forespørgsler, der krævede en dyb forståelse af konteksten. For eksempel kunne AI’en ikke give et relevant svar på spørgsmålet “Hvad er fair Seed & Series A valuations?”, hvilket understreger, hvor svært det er at integrere ustruktureret tekst i en sammenhængende vidensgraf.

Selv om denne tilgang i sidste ende ikke lykkedes, gav den vigtig indsigt i udfordringerne ved at bruge vidensgrafer i AI. Datakompleksiteten og behovet for præcis kontekst betød, at selv en velkonstrueret vidensgraf kunne have svært ved at levere de ønskede resultater. Endnu en ulempe ved Knowledge Graph Index var dens langsomme hastighed. Svartiden for at finde relaterede dokumenter var meget høj i forhold til et vector store-indeks.

Revurdering af data: Gemini

Efter flere tilbageslag besluttede jeg at tage en anden tilgang ved at udnytte Googles AI, Gemini. Ideen var at oprette datasæt fra JSON-CSV-filer og derefter træne en brugerdefineret model LLM ved hjælp af disse data. Jeg håbede, at jeg ved at bruge strukturerede data og en robust træningsmodel kunne overvinde nogle af de udfordringer, der havde plaget tidligere forsøg.

Denne tilgang stødte dog også på problemer. Træningsprocessen blev stoppet på grund af forkert dataformatering, som forhindrede modellen i at blive trænet effektivt. Dette tilbageslag understregede vigtigheden af dataintegritet i AI-træning. Uden korrekt formaterede og strukturerede data kan selv de mest avancerede modeller ikke fungere som forventet.

Denne erfaring fik mig til at overveje potentialet i at bruge BigQuery til at lagre JSON-data, hvilket giver en mere skalerbar og pålidelig platform til at håndtere de store datasæt, der er nødvendige for at træne Fabrice AI effektivt.

Kombination af styrker: Langchain-dokumenter med Pinecone

På trods af de hidtidige udfordringer var jeg fast besluttet på at finde en løsning, der ville gøre det muligt for Fabrice AI at lagre og hente viden effektivt. Denne beslutsomhed fik mig til at eksperimentere med Langchain-dokumenter og Pinecone. Metoden gik ud på at oprette et Pinecone-vektorlager ved hjælp af Langchain-dokumenter og OpenAI-indlejringer og derefter hente de mest lignende dokumenter baseret på forespørgslen.

Denne metode viste sig at være lovende, især når forespørgslen omfattede dokumentets titel. For eksempel var AI’en i stand til at hente og opsummere det relevante indhold præcist, når den blev spurgt: “Hvad er nøglen til lykke?”. Der var dog stadig begrænsninger, især når forespørgslen manglede specifikke nøgleord eller titler.

Denne tilgang demonstrerede potentialet i at kombinere forskellige teknologier for at forbedre AI’ens ydeevne. Ved at integrere Langchain-dokumenter med Pinecones vektorlager var jeg i stand til at forbedre relevansen og nøjagtigheden af AI’ens svar, omend med visse begrænsninger.

Opnåelse af konsistens: GPT-byggeren OpenAI

Efter at have udforsket forskellige metoder og teknologier vendte jeg mig mod Open AI’s GPT Builder for at konsolidere og forfine den viden, der var lagret i Fabrice AI. Ved at uploade alt indholdet til en GPT-videnbase ville jeg skabe en mere konsekvent og pålidelig platform til at hente og interagere med min viden.

Denne tilgang viste sig at være en af de mest succesfulde, idet den kunstige intelligens var i stand til at give bedre resultater på tværs af en række forespørgsler. Nøglen til denne succes var integrationen af al viden i et enkelt, sammenhængende system, så den kunstige intelligens kunne trække på hele bredden af indhold, når den besvarede spørgsmål.

Som jeg nævnte i mit tidligere indlæg, kunne jeg ikke få det til at køre på min hjemmeside, og det var kun tilgængeligt for betalende abonnenter på Chat GPT, hvilket jeg følte var for begrænsende. Og selv om det var bedre, var jeg stadig ikke vild med kvaliteten af svarene, og jeg var ikke tryg ved at offentliggøre det.

Endelig forbedring: GPT-assistenter bruger model 4o

Den sidste brik i puslespillet i udviklingen af Fabrice AI kom med introduktionen af GPT-assistenter ved hjælp af Model 4o. Denne tilgang repræsenterede kulminationen på alt, hvad jeg havde lært gennem hele projektet. Ved at bruge en vektordatabase og finpudse spørgsmålene forsøgte jeg at opnå det højest mulige niveau af nøjagtighed og kontekstuel forståelse i AI’ens svar.

Metoden gik ud på at uploade al den viden, jeg havde samlet, til en vektordatabase, som derefter blev brugt som grundlag for AI’ens interaktioner. Vektordatabasen gjorde det muligt for den kunstige intelligens at udføre mere sofistikerede søgninger og hente oplysninger baseret på den semantiske betydning af forespørgsler i stedet for udelukkende at basere sig på søgeordsmatchning. Dette markerede et betydeligt fremskridt i forhold til tidligere tilgange og gjorde AI’en i stand til bedre at forstå og svare på komplekse, nuancerede spørgsmål.

En af de vigtigste nyskabelser i denne tilgang var den omhyggelige forbedring af spørgsmålene. Ved omhyggeligt at udforme og teste forskellige forespørgsler kunne jeg guide den kunstige intelligens til at give mere præcise og relevante svar. Det indebar ikke kun at tilpasse ordlyden af spørgsmålene, men også at eksperimentere med forskellige måder at strukturere forespørgslerne på for at få de bedst mulige svar.

Resultaterne var imponerende. AI’en var nu i stand til at håndtere en lang række forespørgsler med stor nøjagtighed, selv når spørgsmålene var åbne eller krævede en dyb forståelse af konteksten. For eksempel da den blev spurgt: “Hvordan træffer man de vigtigste beslutninger i sit liv?” gav AI’en et omfattende og indsigtsfuldt svar, der trak på en række forskellige kilder og perspektiver for at levere et velafrundet svar.

Denne succes var kulminationen på hundredvis af timers arbejde og utallige eksperimenter. Den viste, at det med den rette kombination af teknologi og raffinement var muligt at skabe en AI, der ikke bare kunne lagre og hente information effektivt, men også engagere sig i den på en meningsfuld måde. Udviklingen af GPT Assistants ved hjælp af Model 4o markerede det punkt, hvor Fabrice AI virkelig kom til sin ret og opnåede det niveau af raffinement og nøjagtighed, som jeg havde forestillet mig fra starten. GPT Assistants API blev derefter integreret i min blog for at give slutbrugerne mulighed for at interagere med Fabrice AI på den måde, du ser det på bloggen lige nu.

Reflekterer over rejsen

Processen med at udvikle Fabrice AI viste, hvor komplekst det er at arbejde med AI, især når det drejer sig om at forstå og sætte information ind i en sammenhæng. Det lærte mig, at der ikke er nogen genveje i AI-udvikling – hvert trin, hver iteration og hvert eksperiment er en nødvendig del af rejsen mod at skabe noget virkelig effektivt.

Fremover glæder jeg mig til at fortsætte med at forfine og udvide Fabrice AI. Som nævnt i det sidste indlæg vil jeg gennemgå de stillede spørgsmål for at supplere vidensbasen, hvor der er huller. Jeg håber også, at jeg på et tidspunkt kan udgive en interaktiv version, der ligner og lyder som mig, og som man kan tale med.

>