Grunden til, at mange går så meget op i længden af LLM'ers kontekstvindue, er fordi det er nemt at forstå, og fordi det er et tal, som er nemt at sammenligne på tværs af modeller.

I virkeligheden tror jeg ikke, at vi burde være så optagede af, hvor lange tekster sprogmodeller kan læse ad gangen.

Problemet er bare at det tal som vi burde være optaget af, ikke kan måles direkte.

På mange måder er det beslægtet med det samme problem, vi støder ind i, når vi forsøger at måle menneskelig intelligens.

Jeg tror, i langt højere grad, vi bør være interesserede i modelarkitekturer og metoder til produktion af træningsdata, som kan få modellerne til at øge det tal, vi ikke kan måle direkte, i forhold til modellens størrelse.

På samme måde, som konsekvenserne af Moores lov skabte uforudsigelig innovation indenfor computerteknologien, kun fordi computere blev hurtigere, billigere og mindre, så tror jeg, at noget lignende kan ske, hvis der arbejdes på at gøre generative modeller mere effektive.

Jeg synes at Martin Thorborg, på det her tidspunkt i Mark Tanges podcast sætter ord på et emne, som jeg ofte går og spekulerer over.

Jeg har ikke talt om det med særlig mange eller skrevet om det i nogen offentlig sammenhæng.

Måske fordi kønsdebatten generelt bare er lidt skræmmende at blande sig i.

Men når man ikke selv er modig nok til det, så er det rart at se, at der er andre, der tør.

For jeg har nemlig kendt langt flere jævnaldrende utilpassede mænd end kvinder i mit liv, som enten er gået totalt i hundene, permanent skadede grundet en hård livsstil eller døde af unaturlige årsager.

Det gør nok at jeg i kønsdebatten også føler en vis omsorg for mit eget køn og føler en trang til at give det mandlige køn en krammer og sige, at vi er gode nok og det hele nok skal gå 🤗

Og det føler jeg nok lidt det er, når jeg hører Martin og andre sætte ord på det i podcasts, tv, etc. For det er vi måske ikke så gode til os mænd, hvis man skal generalisere lidt.

Bare det at jeg synes det er lidt scary at dele den her post vidner på en eller anden måde om at det nok er meget godt at gøre.

Derudover er den en fed podcast Mark Tange har lavet her, som jeg kan anbefale at give et lyt.

Det kræver måske også lidt at man lytter fra mit timestamp for at fatte konteksten til indlægget, så det er måske en meget god teaser 😅

Jeg tror, mange af os ML-nørder undervurderer, hvor meget indsigt vi har i den udvikling, der sker inden for generativ AI lige nu.

Som jeg ser det er 2024 en fantastisk mulighed for at øge vores indsigt yderligere og på den måde gøre vores viden endnu mere værdifuld i 2025 💎

Jeg tror jeg at vi som ML-nørder i 2024 bør fokusere på følgende:

1. Vær hands-on. Ha’ fingrene i bolledejen og nyd at være i bygge processen. Ha’ fingrene i bolledejen og nyd at være i bygge processen. Engineering er en blanding af håndværk og teori, men det står sparsomt til med teorien inden for det her felt, så som jeg ser det er hands-on den eneste vej. Så skriver vi teorien bagefter.
2. Fokuser på ægte anvendelighed. Løser det du laver et reelt problem? Eller er det et problem som du tror nogen har, men som ingen i virkeligeheden har? Optimer for virklige problemer.
3. Hold dig orienteret om, hvad der sker i feltet, og hold dig opdateret på den seneste viden og de nyeste open source-projekter.
4. Dan din egen unikke mening om hvordan man bygger med generativ AI. Del den med andre. Få deres input. Bliv klogere. Gentag.
5. Vær opmærksom på “fascinations bias”. Nogle gange bliver en teknologi/metode hypet, fordi man kan lave en fascinerende demo med den. Forsøg at se igennem fascinationen. Der kan være aspekter af metoden, som er brugbare, men det er meget muligt, at selve fascinationen orienterer folk i en forkert retning. Zoom ud, vær kritisk, og skær fascinationen fra.
6. Slå koldt vand i blodet. Giv en kæmpe f***-finger til FOMO. Du kan ikke vide det hele, og det skal nok gå alligevel. Glem det der unicorn start-up som alle siger der er kæmpe mulighed for at start lige nu (med mindre du er i gang med at lave sådan et start-up selvfølgelige 😅). Bare gør hvad du kan for at sikre, at du opfylder punkt 2, så skal du nok bevæge dig i den rigtige retning.
7. Husk at det er mega svært det her, og der er ikke nødvendigvis nogle best practices og rigtige svar for det du sidder og laver. Det er det vi skal opfinde sammen i 2024!

Ting som jeg har læst, tænkt, noteret, spekuleret over etc. i 2023 som her er serveret som et råt brain-dump. Da det er rimelig råt, så kan redundans forekomme 🙃

1. Meget tyder på, at deep learning-modeller lærer det, der er at lære i de data, de trænes med. Hvis de ikke lærer det, skyldes det enten uklarheder i data eller at der ikke er tilstrækkelig information i data til at løse opgaven (se Universal Approximation Theorem). Fremtidige fremskridt i AI vil derfor sandsynligvis i højere grad blive gjort mulige ved at udvikle metoder til at tilvejebringe data af højere kvalitet end ved at udvikle nye modelarkitekturer.
2. Alle undervurderer evaluering af sprogmodeller. Det er ærgerligt, da evaluering kommer til at blive noget af det vigtigste at tage seriøst, hvis man vil lave imponerende og værdifulde ting med LLM'er. Derfor, væn dig til at tænke i evaluering af AI-systemer, og gå aldrig i gang med et AI-projekt uden at have en strategi for evalueringen af det. Evalueringen behøver ikke at være perfekt fra starten, og man skal regne med at udvikle evalueringen af systemet løbende.
   
3. Når du arbejder med teknologi, bør brugernes behov altid komme før teknologien. En "bruger-først"-tankegang er afgørende for succes, i modsætning til en "teknologi-først"-tankegang. Det lyder virkelig som en floskel, men det er seriøst vigtigt, og det kræver disciplin at praktisere.
   
4. Mennesker har en forenklet forståelse af, hvordan verden faktisk er. Det kan være meget uproduktivt at bilde sig selv ind, at ens forståelse af verden er perfekt. Hvis man gør det, ender man med at sidde med sine peers i et mødelokale og bilde sig selv ind, at man kan diskutere sig frem til, hvad ens brugere vil have. Det er i høj grad nemmere sagt end gjort og kræver disciplin konstant at udfordre sit syn på verden.
   
5. Den generelle sprogforståelse i store sprogmodeller (LLM'er) er totalt undervurderet. Med LLM'er er det blevet mange tusinde gange billigere og hurtigere at lave et proof of concept på skræddersyede NLP-klassificeringsmodeller end tidligere – det kan nu praktisk talt gøres gratis. Det giver et kæmpe potientiale for at udvikle "oldschool" NLP, som rigtig mange overser, fordi det generative aspekt af LLM'er er så fascinerende.
   
6. En brugbar måde at tænke på store sprogmodeller (LLM'er) er som et nyt interface, på linje med smartphonen, der hjælper brugere med at interagere med software. Smartphonen gjorde interaktionen med software mere mobil. LLM'er gør interaktion med software mere naturlig og kan håndtere en hel masse kompleksitet for brugeren. Gode eksempler er virksomheder, der har et komplekst produkt, som er svært for brugerne at betjene, navigere og forstå selv, fx et regnskabsprogram eller en bank. På nuværende tidspunkt er brugerens interface til de komplekse produkter ofte kundeservice. Det kommer LLM'er til at kunne hjælpe kundeservicemedarbejdere med og på sigt overtage helt. Rent engineeringmæssigt tænk:
   1. Input: Brugerintention formuleret i naturligt sprog.
   2. Mellemliggende output/input: Opfølgende spørgsmål og svar.
   3. Endelig output: Sekvens af funktionskald i det relevante software.
7. Hvis store sprogmodeller (LLM'er) fortsætter med at blive mindre, hurtigere og billigere med samme hastighed, som de har gjort i 2023, så kan de skabe muligheder som at svære at forestille sig på nuværende tidspunkt på samme måde, som fremskridt i computerkraft har gjort det ifølge Moores lov.
   
8. Udviklingen inden for 7B LLM-modeller går så stærkt, fordi de er tilgængelige at køre, træne og eksperimentere med for open source-entusiaster.
   
9. Teknologifascination skygger ofte for virkelige forretningsproblemer.
   
10. Hvis man bruger meget tid på at tale om AI use-cases frem for forretningsproblemer, er det enten fordi man er i gang med at lære at forstå, hvad AI grundlæggende kan, eller også er man som ekspert i gang med at formidle/sælge AI-løsninger til nogen, som ikke forstår det.
    
11. Hvorvidt en teknologi er en succes, er 100% korreleret med hvor meget den bliver brugt. Biler er en succesfuld teknologi, fordi de bliver brugt. ChatGPT er en succes, fordi den bliver brugt. Tandbørster er en succes, fordi de bliver brugt. Så hvis du gerne vil lave teknologi, som bliver en succes, så handler det om at få nogen til at bruge din teknologi.

Forslag til folketingsbeslutning

om at skabe højkvalitets datasets til træning og evaluering af danske sprogmodeller

Folketinget pålægger regeringen i indeværende folketingssamling at igangsætte arbejdet med at udvikle omfattende og højkvalitets datasets til træning og evaluering af sprogmodeller, herunder at indsamle og organisere data fra Det Kgl. Bibliotek og andre store vidensdatabaser.

Bemærkninger til forslaget

Forslagsstillerne ønsker, at Danmark skal bidrage til udviklingen af avancerede sprogmodeller ved at skabe omfattende, kvalitetsrig og diversificeret trænings- og evalueringsdata. Dette kan sikre, at danske værdier, kultur og sprog nuanceret og korrekt repræsenteres i fremtidige sprogmodeller.

Med baggrund i EU og Danmarks unikke værdier og regelsæt, som amerikanske og andre udenlandske sprogmodeller ofte overser, understreger forslagsstillerne vigtigheden af at udvikle datasets, der afspejler dansk kultur, normer, love og sprog.

Andre lande, herunder de skandinaviske naboer, har allerede anerkendt vigtigheden af at bidrage til træningsdata for sprogmodeller. Dette ses i Sveriges indsats for at udvikle svenske træningsdata til sprogmodeller.

For at undgå fejl og misforståelser i anvendelsen af kunstig intelligens i en dansk kontekst, er det afgørende at have trænings- og evalueringsdata, der fuldt ud forstår og integrerer danske kulturelle aspekter og juridiske rammer. En sådan indsats er ikke kun nødvendig for at bevare det danske sprog og kultur, men også for at sikre præcis og relevant anvendelse af AI-teknologi i Danmark.

Forslagsstillerne fremhæver, at generativ AI og tilhørende teknologier bør ses som en del af kritisk infrastruktur, sammenlignelig med veje og elnettet. Derfor bør udviklingen og vedligeholdelsen af disse datasæt være under offentlig kontrol eller et offentlig-privat partnerskab.

Forslagsstillerne betoner også, at det er essentielt at sikre, at træningsdata er transparente, så offentligheden kan forstå grundlaget og indholdet af dataene. Dette gælder også for de algoritmer, der anvender disse datasæt.

Økonomi og finansiering

Udvikling af højkvalitets trænings- og evalueringsdata kræver betydelige ressourcer. Anslået vil omkostningerne være omkring 40 millioner danske kroner, baseret på sammenlignelige projekter. Disse omkostninger dækker indsamling, organisering og vedligeholdelse af datasæt samt eventuelle rettighedsmæssige afklaringer.

Forslagsstillerne foreslår, at projektet finansieres gennem det offentlige økonomiske råderum, men er åbne for at diskutere alternative finansieringsmuligheder.

Ten years ago, many companies were concerned with a concept called "Mobile First," which prioritized developing software that worked well on a new interface gaining massive user adoption: the smartphone.

Within the near future, many companies will be concerned with a concept known as "Language First." This approach involves developing software that works well with an emerging interface gaining widespread use: Large Language Models (LLMs).

The chatbot interface has made LLMs famous. However, many things are pointing towards LLMs being not only great for chat but also for interacting with software systems through language. Because of the LLMs' reasoning capabilities and their ability to use tools, this new interface can help humans handle much of the cognitive load involved in learning and using complex systems.

In the near future, we as humans will be able to interact with much more complex software systems without being experts. Imagine if everyone could handle the most complex systems relevant in their daily lives as an expert would.

So, how are we as software developers going to design software for this future where "Language First" principles are going to dominate?

As the "Mobile First" paradigm was obsessed with graphical user interfaces and user experiences, the "Language First" paradigm will be obsessed with user intent. 

What problems does the user have that they can express in plain, non-expert layman language, and how can we use AI to understand it and orchestrate functionality to help the user achieve their goal?

This will involve organizing systems of prompts to build the reasoning framework for orchestrating functionality. Also it will involve indexing and organizing functionality (basically endpoints) and processes to give the LLMs the best possible conditions to do a good job.

Much like search intent which is a big thing in natural language information search, user intent will be the main focus in functionality search and execution.

To be continued... (I'm not done writing yet 😅)

If your product has a UX element that aligns user interactions with the goal of your AI models, then you have a beautifully machine-learning-based product.

Think of Midjourney. You write a prompt, get 4 generated images. Midjourney's goal is to generate the best possible images given a prompt. The user's desire is to get the best possible image from a prompt. There is 100% alignment between the product's and the user's goals. And you don't need to give advanced instructions to Midjourney users on selecting the best picture. Their human intuition guides them effortlessly. The result is invaluable data for Midjourney to train their models.

Think of Netflix. Occasionally, while you're watching Netflix, you will be asked, 'Are you still watching X?' Netflix understands how crucial this subtle piece of information is for their recommender systems and the user experience of the product. The recommender system needs to know if you are actually watching to determine what to recommend next. And if you fell asleep, it's convenient that Netflix can predict this and automatically stop the series for you, so you don't have to search for where you stopped watching. When you are prompted with 'Are you still watching X?', you as a user have a 100% interest and need to give Netflix almost the perfect information they need to evaluate their system.

More examples of products that do this are Google Search and every social media feed. Huge companies are built by integrating UX and AI to craft superior products. Yet, not many consider AI and UX in this integrated manner. It should be a consideration in every UX decision made.

The more I use ChatGPT and develop software using LLM APIs, the more I realize that context is essential for LLMs to provide high-quality answers. When I use ChatGPT and receive unsatisfactory answers, it's typically due to a lack of information about the problem I'm presenting or my current situation. I often notice that I might be ambiguous about the task I want ChatGPT to solve, or ChatGPT perceives the issue in a manner I hadn't anticipated. However, I've observed that by adopting a simple pattern, I can significantly reduce these challenges, consistently leading to more accurate responses.

The pattern is as follows:

1. Me: I instruct ChatGPT to perform a task. I tell it not to respond immediately but to ask clarifying questions if any aspect of my instruction is unclear.
2. ChatGPT: Asks clarifying questions.
3. Me: I answer the questions and tell it again not to execute the instruction but to ask further clarifying questions if any part of my answers is unclear.
4. ChatGPT: It does one of two things.
   a) Asks additional clarifying questions. If this happens, return to step 3.
   b) Indicates it has no further questions. If this is the case, proceed to step 5.
5. Me: I give the command to execute the instruction.

Before LLMs really became a thing, getting up and running with a text classifier for a non-standard problem from scratch, including the annotation of a dataset for training, would probably take at least 3 weeks of work hours. That amounts to 7,200 minutes. Today, getting up and running with a classifier using LLMs requires only writing a prompt, which takes about a minute.

That's a 7,200x productivity gain in the initial process of working with text classifiers.

One thing to note, however, is that in the 1-minute prompt scenario, you have collected zero data and therefore have nothing to measure your classifier's performance against. However, since you have a classifier, you can annotate much more efficiently using an active learning approach, and you have 7,199 minutes to knock yourself out with evaluating your classifier.

Everybody talks about chatbots and agents as the hot new thing, but honestly, a 7,200x productivity gain in text classifier development is also pretty huge!

It seems like there are two kinds of things you can work on: right and wrong things. The right things bring you closer to your goals, the wrong things take you further away from your goals or nowhere at all. I firmly believe that one's ability to choose the right things to work on largely determines one's success.

Right and wrong things to work on must always be viewed relative to a goal. One thing may be the right thing to work on to achieve goal A, but the wrong one if you want to achieve goal B.

As a person, I am very enthusiastic and full of ideas. This may seem like two positive attributes, but the combination often leads to a lack of focus. For there are many good ideas, but not all of them lead towards the same goal. If you are too easily seduced by your abundance of ideas, you end up being unfocused, and this leads you very inefficiently towards your goal.

In my opinion, that's why it's important to spend time figuring out what your goals are. It sounds simple, but personally, I find it much easier said than done! For what is the actual dream scenario if you think 5-10 years into the future? This question deserves that you make an effort to answer it, and that you regularly revisit it to see if your actions align with your long-term goals.

The clearer you are on your goals, the better you become at determining what the right and wrong things to work on are in relation to achieving your goals.

Large language models (LLMs) can be prompt-engineered to solve a wide variety of tasks. While many consider chat as the primary use case, LLMs can also be used to build traditional classifiers. 

Before the rise of advanced generative text-to-text models, crafting a custom text classifier was a time-consuming process that required extensive data collection and annotation.

Nowadays, you can get your hands dirty with LLMs without worrying about annotating data. This is great as it saves you a lot of time. However, it also becomes tempting to bypass best practices for building robust machine learning applications. 

When there's no need to create a training dataset, the temptation of simply hand-tuning a prompt based on a few examples becomes strong. You might convince yourself that it will generalize to any data that might be presented to it.The challenge is, without annotations to measure accuracy or a method to assess your prompt, you can't determine its robustness once deployed.

{
    "thoughts": <rationale behind classification here>, 
    "class": <the class the model has classified the example as here>
}

Step 3: Run, Inspect and Annotate

Now run the hand-tuned prompt on the entire validation dataset.  For reproducibility, set the temperature to 0. Review all classified samples. If the LLM's categorization is inaccurate, correct it and document areas of misunderstanding. Use the thoughts output to understand its decision-making process. 

During annotation, you'll almost certainly discover complexities and nuances in the problem you're trying solve that didn't initially think of. Also you will likely discover ambiguities in the instruction you asked the LLM to follow, where you will have to be more clear in what you want it to do. In some cases the LLM's limits of understanding will also reveal themselves. Document these findings in an "annotation protocol", which outlines rules for managing edge cases.

Step 4: Measure Performance of Prompt

Upon completing step 3, you'll have an annotated validation dataset. This allows for the evaluation of the prompt's predictive performance. Measure the performance to gain insight into the prompt's predictive capabilities.

Step 5: Adjust Prompt

Post step 5, you'll have written notes detailing cases where the LLM misclassified data. From this, formulate a hypothesis on potential prompt modifications to enhance its accuracy. Adjust the prompt in a which you think will mitigate the errors.

Step 6: Iterate

After step 6, run the adjusted prompt on the validation dataset and measure its performance. Ideally, results should improve post-adjustment. Analyze incorrect classifications and take notes to understand the model's behavior. Repeat this process until you are satisfied with the prompt's performance or you believe that you have reached maximum performance.

Step 7: Measure Performance on Test Dataset

Now is the time. It's time to follow best practices, like the diligent and competent ML engineer you are. Now, you need to run the tuned prompt on a test set. However, your test set isn't annotated yet, presenting a significant temptation to skip this step. But you know you have to do it! If you do this, you will likely find that performance on the test dataset is a little worse. This is expected and is because you have probably overfitted your prompt to the validation dataset.

Conclusion

Congratulations, you now have an LLM classifier to solve a problem for you! For now, this is the best process I have. If you know of a better approach, I would love to hear from you. Additionally, at SEO.ai, where I work as an ML Engineer, we are constantly striving to crystallize our learnings into code. Specifically, we are developing a Python package called prompt-functions, which, in our experience, makes this process much smoother. We would love to continue the conversation on how to manage LLM applications, so please feel free to open an issue, send us a pull request or simply just reach out to me 🤗

I feel like I spend way too much time in front of a screen coding, compared to the time I spend interacting with people. When I talk to other people about this, some say the exact opposite. Perhaps it would be useful to define a metric for this. This way, people can measure it and strive to achieve their desired balance between screen and human interaction. We could call it the human-to-screen (H2S) metric.

Let:

H: time spent interacting with humans 

S: time spent in front of a screen

Forleden havde vi hos seo.ai en diskussion om hvorvidt LLM'er kan skabe ny viden 🤔

Hver gang man støder ind et spørgsmål af typen:

"𝗞𝗮𝗻 𝗔𝗜 𝗫?"

Så føler jeg tit at det er brugbart at stille spørgsmålet:

"𝗞𝗮𝗻 𝗺𝗲𝗻𝗻𝗲𝘀𝗸𝗲𝗿 𝗫?"

Altså i det her tilfælde:

"𝗞𝗮𝗻 𝗺𝗲𝗻𝗻𝗲𝘀𝗸𝗲𝗿 𝘀𝗸𝗮𝗯𝗲 𝗻𝘆 𝘃𝗶𝗱𝗲𝗻?"

Smag lige på de to spørgsmål når de står ved siden af hinanden:

𝟭. 𝗞𝗮𝗻 𝗔𝗜 𝘀𝗸𝗮𝗯𝗲 𝗻𝘆 𝘃𝗶𝗱𝗲𝗻?

𝟮. 𝗞𝗮𝗻 𝗺𝗲𝗻𝗻𝗲𝘀𝗸𝗲𝗿 𝘀𝗸𝗮𝗯𝗲 𝗻𝘆 𝘃𝗶𝗱𝗲𝗻?

Svaret på nummer 1. kender jeg ikke, men jeg er faktisk heller ikke sikker på svaret på 2. 😅

Når man tænker over det, så er spørgsmålet måske lidt mere nuanceret end først antaget. For er ny viden ikke noget man erfarer fra den virkelige verden?

Og er det så ikke unfair over for LLM'er at mennesker i langt højere grad har adgang til den virkelige verden 🤔

Jeg bruger seriøst ChatGPT konstant, når jeg arbejder! Jeg bruger det til at:

• skrive kode
• visualisere data
• forklare kode, som andre har skrevet
• teste kode
• sparre omkring best practices og arkitektur
• lære at kode
• og meget, meget mere

Et slag på tasken er, at ChatGPT i gennemsnit øger min produktivitet med 35%. Til nogle opgaver øger ChatGPT min produktivitet med adskillige 1000%. Der er sågar ting, jeg kaster mig ud i, fordi jeg har ChatGPT, som jeg ellers ikke ville gøre. Og så er der det aspekt, at jeg også overordnet skriver bedre kode, fordi jeg har en sparringspartner, som altid er online.

Når jeg taler med mine kollegaer i tech-branchen, er det langt fra alle, der bruger ChatGPT. Når jeg tænker på, hvor meget værdi jeg får ud af ChatGPT, kan jeg slet ikke fatte, at alle udviklere ikke bruger det vildt meget!

Fra mit synspunkt ligger der stadigvæk et kæmpe uudnyttet produktivitetspotentiale og lurer lige om hjørnet!

Den generative AI-teknologi er i rivende udvikling. Dog har avancerede modeller som GPT-3.5 og GPT-4 en udfordring: De har tendens til at generere udsagn, som er usande. ChatGPT, en populær bruger af generativ AI, møder ofte kritik for netop dette.

Spørgsmålet er, om vi forventer, at generativ AI skal agere som en alvidende vidensdatabase, der har styr på alle fakta i verden. Eller er dette måske den forkerte tilgang til at forstå disse store sprogmodeller?

En alternativ tankegang kan være at opfatte modeller som GPT-3.5 og GPT-4, også kaldet Large Language Models (LLM'er), som små ræsonnementmotorer. Motorer som kan løse mere fleksible og komplekse problemer end traditionel programmering. Ved at se generativ AI i dette lys, kan det måske udvide vores forståelse af teknologien og gøre os i stand til at tænke i gunstige anvendelsesmuligheder inden for AI-teknologi.

Efterspørgslen efter viden om kunstig intelligens er steget markant inden for det seneste halve år, siden udgivelsen af ChatGPT. Mig selv og mine kolleger, der arbejder med AI, bliver regelmæssigt kontaktet af medier og organisationer, der ønsker præsentationer om kunstig intelligens for at få mere indsigt i, hvad der sker i øjeblikket.

Verden er nysgerrig på AI, og det er selvfølgelig utrolig smigrende for os, der har viden om emnet, da vores viden pludselig er blevet værdifuld. I mine samtaler med mennesker og mine observationer af, hvordan folk taler om kunstig intelligens i medierne, har jeg identificeret to typer nysgerrighed.

Type 1: Den orienterende nysgerrighed 

Den mest almindelige type nysgerrighed, jeg oplever. Det er den nysgerrighed, folk har om et emne, fordi det påvirker deres liv på den ene eller anden måde. Måske er deres erhverv ved at blive disrupt'et. Måske er de investorer, der ønsker at placere deres penge et sted, hvor de kan tjene penge på AI. Måske er de ledere i en virksomhed og ønsker at vide, hvordan deres ansatte kan blive mere effektive med generativ kunstig intelligens.

Type 2: Den platoniske nysgerrighed 

Desværre oplever jeg mindre ofte denne type nysgerrighed. Det er den type nysgerrighed, hvor folk ønsker at forstå emnet, fordi det giver dem en fornemmelse af tilfredsstillelse og de får et kick hver eneste gang de forstår emnet dybere. Mennesker med denne type nysgerrighed bruger den viden de får, til at forme deres mentale model af verden, så de på den måde kan tænke vildere tanker. De bruger viden som brændstof til deres forestilling om, hvordan verden hænger sammen, og hvad der er muligt. De har en slags kærlighedsforhold til rå viden.

En ting, som jeg har bemærket ved GPT-4 og resten af de generative sprogmodeller, er deres manglende temporale dimension. Det eneste tidspunkt, hvor GPT-4's neuroner er aktiverede, er når den bliver promptet af et menneske.

Menneskers neuroner er derimod konstant aktive. Uanset om et menneske har en samtale med et andet menneske eller bare sidder og stirrer ud i luften, så kører det neurale netværk og modtager data ustandseligt i den temporale dimension.

Hvis man skulle give et menneske de samme forudsætninger som GPT-4, ville det svare til, at menneskets hjerne kun blev aktiveret, når andre mennesker valgte at kommunikere med det.

Vi mennesker har en form for "idle tilstand", som GPT-4 ikke har - en tilstand hvor vi bare modtager input og har tid til at tænke og dyrke vores bevidsthed.

Det er super udfordrende at udvikle software applikationer med store sporgmodeller! Hovedsagligt fordi man ikke kan 100% styre med hvad AI modellerne finder på at generere.

Der bliver dog forsket intensivt i metoder til at prompte sprogmodellerne så de bliver mere konsistente og nøjagtige i deres output. Ja, der er faktisk efterhånden opstået så mange metoder til at prompte sprogmodeller at det er blevet en hel profession i sig selv at gøre.

Den nye profession indenfor AI og Machine Learning er efterhånden blevet døbt Prompt Engineering. Og hvis man tror at det bare en døgnflue trend, som handler om at flere og flere folk har det sjovt med ChatGPT, så er det fordi man ikke opmærksom på hvad der hvad der rør sig. Man nemlig nogle helt nye ting med den her teknologi og på nuværende tidspunkt virker det kun til at være fantasien som sætter grænserne for hvad der er muligt.

Men det der med at sætte store sprogmodeller i produktion uden at være helt sikker på hvad de fortæller brugerne, er lidt en pain for mange. Derfor bliver det i stigende grad nødvendigt med "PromptOps" i takt med at Prompt Engineering af vinder frem i flere og flere software applikationer. Altså en måde hvorpå man struktureret kan styre sin prompt udvikling. Hvis du vil have et lille smugkig ind i fremtiden for dette felt, vil jeg anbefale, at du sætter dig ind i open source-projektet og Python-pakken langchain.

https://github.com/hwchase17/langchain

Hvis du er interesseret i at forstå, hvad det her Python bibliotek kan gøre for udvikling af applikationer med generativ AI, kan jeg garantere et mind-blow!

For nylig havde jeg en samtale med en ven, som mente, at OpenAI var priviligeret og kun havde alt den succes og kunne lave alt den fede forskning, fordi de havde så mange penge. Men er mange penge virkelig lig succes? Eller kræver det flere ingredienser for at opnå succes?

Man har mange gange set, at virksomheder har haft masser af penge, men stadig har valgt at bruge dem på en mildt sagt ugunstig måde. Så den med at penge bare er lig succes, den køber jeg ikke 🙃

Jeg mener personligt, at OpenAIs succes skyldes tre ting:

• De er dygtige til at rejse penge.
• De er dygtige til at vælge de rigtige projekter at arbejde på og bruger dermed deres penge optimalt.
• De er dygtige til at promovere deres forskning og få det ud til brugerne.

OpenAI har truffet mange valg undervejs.

For eksempel har de valgt at udgive ChatGPT gratis, selvom det har kostet dem mange penge, som kunne være brugt på forskning.

Mange ville måske ikke have valgt at give en så stor model ud gratis og bruge penge på noget, der ikke giver umiddelbar profit.

Men fordi OpenAI forstår værdien af PR, har de is i maven til at træffe en sådan beslutning.

Og det hjalp dem med at få rejst endnu en milliardinvestering fra Microsoft og muligvis sætte gang i en disruption af internetsøgning 😅

OpenAI er ikke den overnight success, som mange opfatter dem som. De har ufortrødent forsket i generel kunstig intelligens siden 2015 og har offentliggjort mange vigtige forskningsresultater og open source-projekter undervejs.

Og ikke mindst så har de formået at formidle den forskning på en måde, som ingen andre er i stand til. Derfor vil jeg sige:

OpenAI er privilegerede, fordi de er dygtige.

Der findes mange fantastiske open source-værktøjer man kan bruge som softwareingeniør. Fælles for dem alle er, at man interagerer med dem gennem terminalen. Selvom mange programmører er glade for terminalen, sætter de fleste mennesker pris på et lækkert grafisk interface.

Og faktisk findes der grafiske interfaces til overraskende mange open source-værktøjer. To eksempler er Docker Desktop til Docker og Attu til vektordatabasen Milvus! Og helt seriøst. Min livskvalitet steg, da jeg begyndte at bruge netop disse to værktøjer. Så slipper jeg for at rode rundt i terminalen og huske på alle mulige kryptiske kommandoer, som de færreste alligevel kan uden ad.

Min pointe er simpel, men desværre ikke åbenlys for alle. Du bør gøre livet som ingeniør så nemt for dig selv som muligt. På den måde får du mest muligt for hånden. Og bare rolig, du er stadig cool, selvom du bruger et GUI-værktøj i stedet for terminalen. Hvis nogen siger noget andet, er det dem, der er nogle spader. 🙃

Open source community'et kæmper virkelig for at gøre LLM'er (Large Language Models) tilgængelige for så mange som muligt! Det er inspirerende at se, hvordan nørder spredt ud over hele verden kan samarbejde om et fælles kode projekt. Et eksempel på dette er petals.ml.

Petals.ml er et open source projekt, der arbejder på at udvikle en decentraliseret løsning til at køre den store åbne sprogmodel Bloom. Sådan lidt blockchain møder large-scale deep learning agtigt 😂. Det er sjovt at tænke på, at udviklingen af LLM'er går både mod flere proprietære modeller og hosting, men det er som om, at "The Open Source Army" ikke finder sig i det og er super hurtige til at samles om at lave løsninger, som har potentiale til at øge den åbne tilgængelighed af denne teknologi markant 👨‍💻.

Vi lever i en spændende tid, hvor de digitale tektoniske plader er i bevægelse, og det ser ud til, at dette kan tippe i alle mulige retninger 🙈. Vi kan kun vente og se, hvad fremtiden vil bringe, men én ting er sikkert, det er fascinerende at se, hvad der kan opnås, når mennesker samarbejder og tænker i fællesskab.

Check petals.ml ud projektet på deres hjemmeside: https://petals.ml.

Som ingeniør bokser man ofte med tekniske barrierer, og nogle gange kan de paralysere mig. De kan føre til at jeg udskyder eller helt undgår ting, og at jeg mister momentum og modet.

For nylig er jeg blevet opmærksom på en inspirerende type af ingeniør, som tackler denne udfordring på en anderledes måde - ingeniører jeg selv har stødt på og har hørt om, og som jeg vil beskrive som ukuelige og frygtløse.

Uanset en opgaves tekniske kompleksitet og deres manglende viden, trækker de frygtløst i arbejdstøjet og går i gang hver gang. De har en dyb tro på deres evne til at tilegne sig viden og at hacke sig igennem vilkårligt komplicerede problemer. De kan abstrahere fra enorme tekniske udfordringer, tage det første skridt og langsomt arbejde sig igennem opgaven.

Den ukuelige og frygtløse ingeniør, som gør hvad der er nødvendigt for at nå målet, uanset om det er at bygge en Android-app eller sende en rumraket til månen.

Sådan en slags ingeniør vil jeg være!

Og jeg tror ikke det er noget man er eller ikke er. Jeg tror, det er et mindset. Jeg tror, det kræver, at man overbeviser sig selv om at man kan løse alle tænkelige problemer, hvis bare man bryder dem op og arbejder metodisk og fokuseret.

Sig det til dig selv hver morgen, når du står op. Faktisk, uanset om du er ingeniør eller ej: "Der er ikke noget problem, jeg ikke kan løse"

Engang var det nødvendigt at kunne svær kode og matematik for at udvikle applikationer med avancerede Deep Learning-baserede sprogmodeller. Men nu kan man komme utrolig langt - endda længere - ved blot at kalde et API og manipulere med strings.

De store sprogmodeller, bedre kendt som Large Language Models (LLM's), har nemlig et super simpelt interface: 

Tekst ind, tekst ud.

Og med dette interface er der begyndt at opstå en ny form for AI-udvikling, en profession kaldet "Prompt Engineering".

Man har nemlig fundet ud af, at hvis man bruger tid på at skrive de rigtige prompts til LLM'erne, kan man øge deres performance til at løse en række forskellige opgaver drastisk! 

Og det er faktisk ikke noget nyt. Det har nemlig været en ting siden OpenAI åbnede API'et til GPT-3 i 2020. Jeg vil dog mene, at mange, inklusiv mig selv, har sovet i timen, når det gælder om at sætte sig ind i, hvad der rent faktisk er muligt med LLM'er.

Jeg har i hvert fald selv undervurderet Prompt Engineering som fænomen, indtil fornyligt, da jeg hørte en tale med en af ingeniørerne bag GitHub Copilot, som fortalte om deres arbejde med at udvikle en vaskeægte AI pair programmer.

ChatGPT har virkelig øget fokus på dette område, og der er virkelig mange, som har fået øjnene op for potentialet i denne teknologi. Flere og flere får også øjnene op for, at det bekvemme "Tekst Ind, Tekst Ud"-interface betyder, at man ikke længere behøver at være en datalog for at udvikle applikationer med avancerede NLP-teknikker.

Det er en spændende tid vi lever i, og jeg kan ikke vente med at se, hvad der bliver muligt med software i den nærmeste fremtid!

Jeg har indrømmet det over for mig selv. Jeg syntes det er mega fedt at høre corny elevator musik. Så jeg er begyndt at lave en playliste på Spotify, der hedder "Elevator Life". Indtil videre indeholder den følgende sange:

• Walter Wanderley - Call Me
• Walter Wanderley - One Note Samba
• Sven Libaek - Bikini Girls
• Walter Wanderley - Crickets Sing For Ana Maria
• Walter Wanderley - Summer Samba (So Nice)

Walter Wanderley dominerer listen rimelig hårdt på grund af hans utemmelige orgelspil. Walters musik er meget tæt på at være uacceptabelt corny, men alligevel er det også lidt fedt. Det er svært at forklare 😅

Efter jeg har lavet spillelisten har jeg fundet ud af, at "elevator musik" faktisk er et rimelig vidt begreb. Det, som binder genren sammen, er, at musikken kunne køre som baggrundsmusik i et shoppingcenter, en butik eller, ja, en elevator.

Men når jeg siger, at jeg er blevet lidt vild med elevator musik, så er det en bestemt slags. Det skal helst have orgel, være lidt latin inspireret og så helst ikke for pjattet, men gerne lidt pjattet. Jeg tror, i virkeligheden, at Walter Wanderley indtil videre må være guldstandarden for netop min elevator musik smag.

Jeg ved virkelig ikke, hvad der er med mig, siden jeg synes det er fedt. Jeg tror det er en skade fra alle de virkelig dårlige og corny vinylplader, jeg har hørt som cratedigger, da jeg producerede mange hiphop beats.

Men nu er jeg endelig kommet ud af skabet. Latin, orgel og ikke for pjattet elevator musik er mega fedt 🙏

Anyways, du kan følge playlisten her 👇

Husk at holde den elevator, peace out 🛗

Jeg oplever tit at forventningerne til udvikleres forretningsforståelse er meget lav. Der er en opfattelse af at udviklere bare gerne vil programmere og snakke om tekniske ting, og så kan forretningen ellers rende dem. Det forventes at udviklere er analfabeter når det kommer til forretning.

Min titel er Data Scientist, altså en form for udvikler. Og ja, jeg kan da godt lide alle mulig tech ting og er da også fast lytter af podcasts som The Changelog, Lex Fridman Podcast og Data Engineering Podcast. Men jeg er i ligeså høj grad optaget af forretning, ledelse og strategi, og lytter med lige så stor interesse til podcasts som Inside The Strategy Room, Topchefernes Strategi og Nordea Market Insights. Men som udvikler er det som om at jeg nogen gange skal kæmpe lidt for at blive taget alvorligt når der tales forretning. For det er jo ikke er min opgave at bekymre mig om den slags.

Dertil kommer fordommen om at udviklere er introverte og har svært ved at begå sig socialt. Gad vide hvor den forestilling kommer fra? Og er der hold i den? Er jeg bare en en outlier 😅 

I min optik skal man kæmpe lidt ekstra som udvikler for at blive opfattet som en der har forstand på forretning. Måske på samme måde som kvinder skal kæmpe lidt ekstra for at blive opfattet som ledere?

Og det er sjovt, fordi hvis der er et område hvor der gang på gang bliver taget forretningsmæssige katastrofale beslutninger, så er det IT. Beslutninger, hvor nogen bilder sig ind at de ved hvilken teknisk løsning forretningen har brug for, og er totalt ignorante overfor problemets kompleksitet og hvad det kræver at lave IT-systemer som resonerer med brugere. 

Tag for eksempel et koncept som teknisk gæld. Et begreb som jeg vil våge at påstå at man har svært ved at forstå og lave en strategi for at håndtere, hvis man ikke har erfaring som udvikler.

Den 6. februar udfordrede jeg mig selv til at skrive et blog post på 10 minutter. I den satte jeg mig spontant for at skrive et blog post hver dag i en måned, inspireret af YouTube vlogging konceptet "daily vlogging".

Nu er det 7 dage siden og det er tid til at gøre status.

1. Er der nogen som læser bloggen?
Her kan du se et overblik fra posthaven.com dashboard over de 6 sidste dages blog posts 👇

Hvis man skulle tænke på menneskets evolution som et reinforcement learning system, kunne dette være en måde at gøre det på:

• agent = mennesket
• policy = menneskets hjerne
• state = fysisk tilstand
• environment = den fysiske verden og andre mennesker
• reward function = overlevelse og reproduktion

Hvis man skulle kode sådan et system ville man skulle implementere to typer af agenter, mandlige og kvindelige. 

I forhold til at reproduktion er et centralt mål for en agents reward og dermed succes, er en interessant observation at reglerne for hvordan de to typer af agenter reproducere sig selv er forskellige. 

Den mandlige agent har evnen til at befrugte og den kvindelige til at blive befrugtet. Når en kvindelig agent bliver befrugtet vil den overgå til en reproduktions-mæssig stand-by tilstand i 9 måneder. Den mandlige agent vil efter at have befrugtet derimod være klar til at gøre det igen umiddelbart efter.

Hvis man ser sådan lidt forsimplet på det, kan man forestille sig at mandlige agenter i sin livstid har potentiale til at formere sig langt mere end kvindelige agenter. 

Jeg kan ikke overskue hvad effekten af denne forskel på mænd og kvinder mon har haft på den menneskelige evolution, men jeg synes den virker så signifikant at jeg ikke kan forestille mig andet end at den må have haft en ikke uvæsentlig betydning på den ene eller den anden måde.