AI
AI-udvikling
Det er blevet let at bygge noget der virker på ti eksempler. Det er stadig svært at bygge noget der virker på tusind, og som ikke skal passes hver uge.
- Svar samme dag
- Fast pris
- Ingen binding
- Kører i produktion
- Evaluering fra start
- Leverandøruafhængigt
- Kontrol over omkostninger
Ydelse
AI-udvikling
Forskellen på en demo og noget der kører
En demo skal bare imponere én gang. Noget der kører, skal håndtere de input ingen havde tænkt på, svare inden for en rimelig tid, koste det samme i næste måned, og fejle på en måde man kan opdage.
Det er den del jeg bliver hentet ind til. Ikke fordi prototypen var dårlig, men fordi afstanden derfra og til produktion er større, end den ser ud udefra.
Hvad jeg bygger
- Søgning og svar oven på jeres egen dokumentation, hvor kilderne bliver vist, så man kan tjekke efter.
- Funktionskald mod jeres egne systemer, så modellen kan slå op i rigtige data i stedet for at gætte.
- Databehandling i store mængder: klassificering, udtræk fra dokumenter, produkttekster på tværs af tusinder af varenumre.
- Interne værktøjer hvor et team sparer timer om ugen på noget, der ellers gøres i hånden.
Evaluering
Uden en evalueringsopsætning aner man ikke om en ændring gjorde tingene bedre eller værre. Man har en fornemmelse, og fornemmelser er upålidelige, når svaret er anderledes hver gang.
Jeg bygger et testsæt af rigtige eksempler tidligt, som regel femogtyve til hundrede stykker, og måler op imod det hver gang der ændres i prompt eller model. Det er den enkeltting, der oftest mangler i de projekter jeg overtager.
Leverance
Det får du
Konkrete leverancer, ikke en rapport med anbefalinger nogen andre skal nå at udføre.
- Arbejdende system
Ikke en prototype i en notebook. Noget der kører i jeres infrastruktur, håndterer fejl og kan overvåges.
- Evalueringssæt
25 til 100 rigtige eksempler med forventede svar, så I selv kan se om en ændring gjorde det bedre eller værre.
- Omkostningsestimat
Hvad det koster per opslag og per måned ved jeres forventede volumen, regnet ud før vi bygger frem for bagefter.
- Dokumentation
Hvordan det hænger sammen, hvor grænserne går, og hvad man gør når det opfører sig mærkeligt. Skrevet til den der overtager.
Proces
Sådan foregår det
Fire trin. Du ved hvad der sker hvornår, og du kan stoppe efter hvert af dem.
- 01
Find opgaven
Vi leder efter det arbejde, der bliver gjort mange gange om ugen, følger et mønster og irriterer dem der laver det. Det er der den første gevinst ligger.
- 02
Mål udgangspunktet
Hvor lang tid tager det i dag, og hvor tit sker det. Uden det tal kan man bagefter ikke sige om noget blev bedre, og så bliver diskussionen fornemmelse mod fornemmelse.
- 03
Byg og evaluér
Jeg bygger et testsæt af rigtige eksempler tidligt og måler op imod det, hver gang der ændres i prompt eller model. Det er den enkeltting, der oftest mangler i projekter jeg overtager.
- 04
Sæt i drift
Ind i de systemer folk allerede arbejder i, med log på alt og en måde at slå det fra på. Og en aftale om hvem der ejer det, når jeg er væk igen.
Hvem laver arbejdet
Det er mig, du kommer til at arbejde sammen med
Jeg hedder Mikkel og har kodet til web siden 2010. Der er ingen projektleder imellem os, og du får ikke en junior på opgaven, fordi den erfarne var optaget. Det du aftaler, er det der bliver lavet, og det er mig der laver det.
Til daglig er jeg partner i Bigum&Co og har været inde over mere end 400 projekter på tværs af e-handel, medicinal, byggeri og offentlig sektor. Ring eller skriv — jeg svarer som regel samme dag, og jeg siger til med det samme, hvis opgaven ikke er noget for mig.
- Erfaring
- 16 år
- Projekter
- 400+
- Anmeldelser
- 5,0
- Svartid
- Samme dag
I dybden
AI-udvikling
Hvad AI-udvikling faktisk indebærer
Den del folk forestiller sig — at skrive en prompt og få et svar tilbage — er som regel under en tiendedel af arbejdet. Resten handler om alt det, der skal være på plads for at svaret kan bruges til noget.
Først er der data. En model kan ikke svare på noget, den ikke har adgang til, og virksomhedsdata ligger næsten altid spredt over flere systemer i formater der ikke passer sammen. Skal en model kunne svare på "hvad står der i vores leveringsbetingelser for erhvervskunder", skal de betingelser findes et sted, de kan hentes fra, i en form der kan søges i. Det er kedeligt arbejde, og det er der de fleste projekter bruger den første måned.
Så er der spørgsmålet om, hvordan man ved at svaret er rigtigt. En model har ingen fornemmelse af sin egen usikkerhed på den måde mennesker har. Den svarer lige overbevisende, uanset om den ved det eller finder på. Derfor bygger jeg altid kildehenvisninger ind, hvor det kan lade sig gøre: brugeren skal kunne klikke sig frem til det dokument, svaret kommer fra, og selv vurdere.
Og så er der drift. En model bliver opdateret, en API ændrer sig, priserne falder, og et bedre alternativ dukker op om otte måneder. Bygger man låst fast til én leverandør, bliver det dyrt at flytte. Derfor lægger jeg altid et tyndt lag ind imellem, så modellen kan skiftes uden at resten skal skrives om.
Hvornår det ikke er værd at bygge
En del af de idéer jeg får forelagt, ville være bedre løst med almindelig software. Skal noget klassificeres efter tre faste regler, er tre if-sætninger både billigere, hurtigere og til at forstå. En model tilføjer usikkerhed, hvor der ikke behøver at være nogen.
Volumen er den anden ting. Sker noget femten gange om måneden, og tager det ti minutter hver gang, taler vi om halvanden time. Det er svært at forsvare et udviklingsprojekt for. Jeg siger det, når regnestykket ikke hænger sammen, også selvom det betyder at jeg ikke får opgaven.
Anmeldelser
Det siger de om mig
Mikkel er kanon dygtig, hjælpsom, lynhurtig til at svare og så er han ovenikøbet sød.
Trine Handskemager Mikkel har leveret en kompetent og professionel ydelse i forbindelse med etablering af mit website. Alting er forløbet hurtigt og problemfrit.
Sisse Find Mikkel Tschentscher er min redningsplanke når noget haster og ingen andre kan finde ud af det.
Torben Wiese
Ydelser
Hvorfor mig
- 16 års erfaring
Jeg har kodet til web siden 2010 og set de fleste måder et projekt kan køre af sporet på. Det gør estimaterne mere ærlige.
- 400+ projekter
På tværs af e-handel, medicinal, byggeri og offentlig sektor. Der er stor sandsynlighed for, at jeg har set noget der ligner din opgave før.
- Du taler med den der koder
Ingen projektleder imellem os, og ingen junior på opgaven fordi den erfarne var optaget. Det du aftaler, er det der bliver lavet.
Brands jeg har arbejdet med
Et udpluk. Nogle som freelancer, nogle gennem bureau, nogle over flere år.
Spørgsmål
Ofte stillede spørgsmål
- Hvilke modeller arbejder du med?
- Primært Claude og OpenAI, men jeg bygger med et lag imellem, så I kan skifte. Prisen og kvaliteten på de her modeller ændrer sig hurtigt nok til, at man ikke skal låse sig fast.
- Skal vores data sendes ud af huset?
- Ikke nødvendigvis. Der er både EU-hostede muligheder og aftaler hvor data ikke bruges til træning. Skal alt blive internt, findes der modeller der kan køre på egen infrastruktur, men de er svagere, og det skal med i beslutningen.
- Hvad koster det at drive?
- Det afhænger helt af mængden af opslag og af hvor meget tekst der sendes med hver gang. Jeg regner et estimat ud tidligt, fordi det ofte ændrer på hvordan løsningen bør bygges.
- Kan I bygge oven på det, vores nuværende leverandør har lavet?
- Ofte ja. Jeg starter med at læse koden igennem og siger ærligt, om det bedst kan betale sig at bygge videre eller starte forfra. Begge svar forekommer.
- Hvor lang tid går der, før noget er i drift?
- En afgrænset løsning på ét system er typisk fire til otte uger inklusive test. Skal der hentes data fra flere systemer, er det integrationerne der bestemmer tempoet, ikke AI-delen.
- Hvem vedligeholder det bagefter?
- Det skal aftales, før vi går i gang. Kan jeres eget team overtage, bygger jeg det, så det er muligt, og skriver dokumentationen til dem. Kan de ikke, laver vi en aftale om det i stedet for at lade som om spørgsmålet ikke findes.