Hvordan et AI-bygget investeringsværktøj voksede og hvorfor det vigtigste endte med at være dokumenterne.
Jeg begyndte med at bede en AI om at skrive noget HTML tilsat JavaScript for interaktion. Tre måneder senere er koden stadig den mindst interessante del af projektet.
Disclaimer: Dette indlæg er delvist skrevet af AI og tilrettet til.
Det her handler om, hvordan et AI-værktøj skiftede form tre gange, og hvad der viste sig at være nødvendigt for, at det overhovedet kunne blive ved med at vokse.
Derudover lidt opmærksomhed på at Power BI skal stramme sig an for at blive anvendt som frontend-værktøj fremadrettet.
Udgangspunktet: En HTML-fil
Jeg havde udarbejdet en Power BI-fil, hvor jeg bl.a. kunne se afkast på ETF’ere. Fint nok som slutbruger. Ønsket var i stedet for visualiseringslaget i Power BI, så at jeg kunne have AI til at lave fortolkninger på visualiseringer. Ikke bare fortolkninger med det valg af slicers, der var anvendt, men også fortolkninger på tværs af visualiseringer især på tværs af væsentlige slicers som valg af dato.
Det skyldes, at udstillingen af visualiseringslaget er statisk og at brugeren af visualiseringerne ikke hjælpes med at fortolke visualiseringerne indenfor en bestemt defineret kontekstramme samt at i stedet for at støtte sig til brugerens hukommelse, at så anvende AI til at være den hukommelse, der kan huske visualiseringerne fra tidligere datoer og derfor kan gøre opmærksom på relevante fund på tværs af datoer.
En konsekvens ville være at ændre formålet med Power BI fra at være sidste datamæssige produkt før mennesket til at være et mellemliggende trin før mindst et nyt dataprodukt. Eller med andre ord: At betydningen af Power BI bliver mindre, hvilket betyder, at produktet, Power BI, pt. ikke kan levere den værdi, jeg forventer, der efterspørges. Jeg skriver ikke, at Power BI fremadrettet er uanvendeligt, men det kan bare ikke levere tilstrækkeligt på AI-siden lige nu.
For at have et dataformat og filformat, som AI let ville kunne arbejde med, trak jeg CSV-data ud af en pivottabel via ‘Eksporter data’-funktion i Power BI og bad AI’en om at bygge et værktøj, der kunne rangere og filtrere de samme data. I princippet kunne jeg have taget snips af visualiseringer fra Power BI og så lagt dem ind i Claude og så få den til at lave de samme visualiseringer. Alternativet som jeg fik gjort var at beskrive dem i stedet. Derefter udfordrede jeg Claude i at se på data og foreslå relevante forskningsresultater, som jeg kunne anvende til nye kolonner og målinger, som først blev lavet direkte i HTML, men senere oprettet i M code og DAX i Power BI, så de var beregnet i nyere CSV-filer.
Så gik der en uge og jeg åbnede en ny samtale i Claude.
Historikken var væk. Undtaget HTML-koden. Men hvorfor tærsklen var sat, som den var. At vi allerede havde afprøvet tre alternativer på at opnå et formål med en måling. At en bestemt kolonne havde dårlig datakvalitet. Jeg skulle forklare det hele forfra og jeg forklarede det lidt anderledes, end jeg havde gjort ugen før, så jeg fik et lidt andet svar.
Det er den erfaring, alt det følgende er en konsekvens af: En AI-samarbejdspartner har ingen hukommelse mellem samtaler. Alt, der er skrevet i en samtale over en uges tid er glemt, når en ny samtale startes.
Tre faser
Set udefra ligner projektet én ting, der er blevet bedre. Indefra er det tre forskellige måder at arbejde på, som afløste hinanden. Hvert skift flyttede viden ét skridt længere ud af mit hoved.
Fase 1: Værktøjet – Anvendelse af AI som kodeskriver
En enkelt HTML-fil, der kører lokalt i browseren. AI’en skrev koden; jeg beskrev, hvad koden og AI skulle gøre. Jeg kunne uploade eksport-CSV’en fra Power BI og arbejde med dataene.
Jeg fik AI til at oprette underkategorier til at have under kategorierne. Først lavede jeg et Python-script til at hente stamdata om ETF’erne via API. Disse stamdata kunne så anvendes til at Claude fik yderligere information, for at kunne foreslå en underkategori til hver ETF, hvorefter jeg har gennemgået listen over underkategorier manuelt for at lave tilretninger.
ETF-scanneren som HTML-fil blev udviklet og mere avanceret over et par uger. Knapperne til ‘Introduktion’ og ‘Ordbog’ begyndte at have mere og mere information om anvendelsen af HTML-filen, som hvordan beregninger blev lavet, hvilket forskningssartikler var anvendt, definitioner af mange udtryk, som f.eks. udtryk fra momentumforskning.
Så slutproduktet var en HTML-fil, som jeg kunne anvende og den HTML-fil var jeg også glad for. Altså lige indtil jeg opdagede muligheden for endnu en fase.
Fase 2: Promptmanualen – AI som analytiker
Vendepunktet var, da jeg efterhånden ikke kunne finde på mere funktionalitet at indbygge i HTML-siden og fik den idé: Kunne du kære AI ikke tage al læringen fra udviklingen af HTML-filen og så returnere det til mig som en prompt?
Idéen var tiltrækkende: I stedet for at lave en prompt, der laver analyser på et datagrundlag enten baseret på hvad jeg foreslår som prompt eller hvad AI’en selv foreslår som prompt ud fra datagrundlaget, hvorfor så ikke få Claude til at lave en best practice prompt ved at analyse værktøjet?
Promptmanualen definerer hele metodikken som en nummereret kæde af trin, med definitioner, tærskler, stående regler og eksplicitte forbehold. Den er udtømmende nok til, at analysen kan køres uden nogen forudgående samtalehistorik og uden at det gør en mærkbar forskel, hvilken AI-model der kører den.
Så først havde jeg brugt flere uger på at lave den bedste HTML-fil med al mulig funktionalitet, og nu kunne jeg egentlig bare lægge HTML-siden til side, anvende prompten i f.eks. Google Gemini og få returneret et Word-dokument, der så ret ens ud, uanset om det var Google Gemini eller Claude, der havde anvendt prompten sammen med et eksportdatatræk fra Power BI.
Netop dét er beviset: Når to forskellige modeller returnerer stort set samme rapport ud fra samme prompt og samme data, ligger metoden ikke i værktøjet. Den ligger i teksten.
Jeg bruger dog HTML-siden fortsat til scenarieanalyse. F.eks. kan jeg eksportere data ud på en række ETF’ere, der f.eks. er udvalgt via filtrering og så importere på en senere dags dato i ETF-scanneren, således at jeg kan se afkastudviklingen for den mellemliggende periode.
Det var her, jeg forstod noget, jeg ikke havde forventet: Promptmanualen er ikke dokumentation af systemet. Promptmanualen er systemet.
HTML-koden er én implementering af den. Skillen blev senere en anden. Word-rapporten er ikke en implementering: Den er resultatet, der kommer ud, når systemet køres.
Bivirkningen var vigtigere end hovedvirkningen. Når hvert trin står skrevet, kan man teste, om trinnet virker — og fjerne det, hvis det ikke gør. Det er sket: et filter, jeg var overbevist om var rigtigt i HTML-filen, røg ud, fordi tre målinger viste, at det gjorde skade på afkastdata. Uden en skrevet manual var jeg bare stille holdt op med at bruge det og havde aldrig lært noget.
Fase 3: Skills – AI som procedure
Sidste skridt var at pakke manualen sammen med de scripts, der ellers blev genskrevet hver uge, som en skill: Et navngivet værktøj, der kaldes med en skråstreg. Lidt som at kalde en funktion i Excel.
Den ugentlige rutine var før “Upload fil, indsæt kontekstprompt, kør otte prompts i rækkefølge”, tjek at intet blev sprunget over”. Nu er det en funktion, der kan kaldes og så afvikler.
Tidsbesparelsen er ikke det interessante. Det interessante er, at rutinen nu er identisk hver gang. Variationen mellem uger kom tidligere lige så meget fra min egen formulering som fra markedet. Nu er formuleringen fastfrosset, og en ændring i resultatet betyder faktisk noget.
Hvorfor der kom regler, som Claude AI skulle arbejde ud fra?
Jeg opdagede. at Claude AI forbrugte unødvendige tokens.
Vi genererede rapporter som Word-filer via kode. En fil bestod alle kontroller og kunne endda konverteres til PDF uden problemer, men Word nægtede at åbne den. Så jeg måtte lave filen igen med AI. Årsagen var en intern id-værdi over en grænse, ingen dokumentation nævner. Ud af det kom en regel om, hvordan de id’er håndteres, således at Claude AI ikke ville lave den fejl igen, således at fremtidige filer kunne åbnes i Word. Så var den første regel oprettet.
Docx,w14:paraId-værdier skal være under 0x80000000 – udelad dem og lad Word generere dem
Der er 48 regler lige nu, fordelt på metodisk disciplin, datakilder, filbehandling, output, dokumentformat, kommunikation og effektivitet.
En AI vil meget gerne gøre, hvad du beder om. Det er præcis derfor, du har brug for nedskrevne regler for, hvordan AI’en skal arbejde for at den arbejder ensartet hver gang.
Hvorfor der kom versionsstyring på alle filer
Da dokumenterne begyndte at vokse, opstod et subtilere problem.
Jeg bad om en opdatering af et dokument og fik en tilbage. Den så rigtig ud. Men den var bygget på en version, der var to generationer gammel, fordi filnavnet endte på _1, og det lignede et versionsnummer. Det var browserens duplikat-suffiks fra et download. Ingen fejlmeddelelse, ingen advarsel — bare tre ugers ændringer, der stille var forsvundet.
Konventionen, der kom ud af det:
- Versionsnummeret står i dokumentets titel, ikke kun i filnavnet. Filnavne kan browseren rode med; indholdet kan den ikke.
- Ændringsloggen står nederst i hvert dokument, og hver post forklarer hvorfor, ikke kun hvad.
- Ændringslogafsnit undtages altid, når versionsnumre erstattes maskinelt. Ellers omskriver man sin egen historie.
- Grundlaget hentes fra den aktuelle fil ved arbejdets start — aldrig fra en kopi tidligere i samtalen og der køres en sammenligning før levering med bekræftelse af, at kun de aftalte ændringer afviger, hvilket for øvrigt er endnu en regel.
Ved levering af fuld kodefil baseret på brugerens original (M-kode, scripts, scanner-HTML m.v.): hent grundlaget fra projektets aktuelle fil ved arbejdets START – aldrig en kopi fra tidligere i sessionen – og kør diff mod netop den fil FØR levering med bekræftelse af, at kun de aftalte ændringer afviger.
En detalje viser, hvor fint det skal skæres: koden står i dag på version 14.6, dokumentationen på 14.7. Det er ikke en fejl. Den sidste opdatering var ren dokumentation uden kodeændring, og da eksportfilerne navngives efter koden, ville en hævning af kodeversionen have løjet om, at der var ændret noget. De to spor er bevidst afkoblet og det står skrevet hvorfor, så jeg ikke om tre måneder “retter” en uoverensstemmelse, der er tilsigtet.
Det kan være udfordrende manuelt at holde styr på, om f.eks. en skill er baseret på den nyeste promptmanual, så derfor er det praktisk at lave endnu en skill, der alene holder styr på versionerne, når f.eks. en promptmanual bliver brugt som indmad i en skill. Ligesom at genererede Word-dokumenter angiver, hvilke versioner, der er forudsætning for genereringen af Word-dokumentet.
Dokumenterne og formålet med dem
Systemet består i dag af seks dokumenttyper. De har hver især én opgave og ingen af dem overlapper:
1. Metodebeskrivelsen. Definerer hvert mål, hver tærskel og hver knap i værktøjet plus datagrundlaget kolonne for kolonne. Svarer på: Hvad betyder det tal, hvordan er det beregnet og hvornår kom det til? Det er opslagsværket.
2. Promptmanualen. Selve metodikken som en nummereret kæde af trin, fra datakvalitetstjek over markedsvurdering til kandidatliste og risikotjek. Hvert trin har formål, beregning, output-format og krav om en konkret anbefaling til sidst. Det er den, der gør analysen reproducerbar uden samtalehistorik.
3. Måleprotokollen. Definerer, hvordan systemet testes: hvordan et datapar udvælges, hvordan afkastet efterfølgende beregnes, hvad der må konkluderes af ét datapunkt (næsten intet), og hvor mange uafhængige målinger der kræves, før en regel må ændres. Det er dokumentet, der forhindrer, at gode uger bliver til beviser.
4. Den kritiske gennemgang. En gennemgang af hvert trin i processen med primær styrke og primær svaghed, holdt op mod den akademiske litteratur, plus et eksplicit regnestykke over, hvad der realistisk kan forventes. Det er det eneste dokument, hvis formål er at modsige de andre.
5. Arbejdsreglerne. De 48 nummererede regler, kategoriseret. Kort format, én linje pr. regel, ingen prosa. Fordelen ved nummereringen er, at man kan henvise til “regel 45” midt i en samtale i stedet for at genforklare princippet.
6. Statusdokumentet. Ét dokument med gældende versioner af alt, de centrale begreber i kort form, de vigtigste empiriske fund og de åbne spørgsmål. Formålet er, at en helt ny samtale kan få fuld kontekst uden at lede. Det er den nærmeste ækvivalent til hukommelse, jeg kan give en samarbejdspartner, der ikke har nogen.
Dertil kommer det, der ikke er dokumenter, men som versioneres på samme måde: Selve HTML-værktøjet, de installerede skills, de ugentlige datasnapshots, som er Word-filer og de logfiler, hvor målingerne akkumuleres.
Efterskrift
Visualiseringslaget i Power BI er ikke overflødigt, men det kan ikke længere være det sidste led før beslutningstageren. Det værktøj, der vinder, er det værktøj, der kan aflevere data i et format, som en AI kan fortolke på tværs af datoer uden at menneskelig hukommelse skal være en forudsætning som mellemled.
Da jeg begyndte, var flaskehalsen, hvor hurtigt jeg kunne bygge og min egen viden.
Flaskehalsen er nu disciplinen. Reglerne og versionsstyringen ser ud som administration, men de er reelt det eneste, der gør det muligt at blive ved med at bygge oven på noget, jeg ikke længere kan holde i hovedet.
Udover de ovennævnte faser er der også lavet andre produkter: En prompt til analyse af en virksomhed, som dog ikke er udarbejdet så struktureret som processen ovenfor samt anvendelse af Pine Script til at lave en teknisk indikator, som anvendes på TradingView, hvilket kan ses i Anvende Pine Script til teknisk analyse af WEBN
| Perspektivering: Promptmanualer er overvældende! Hvordan skal virksomheder fremadrettet beskytte videnaktiver som deres promptmanualer? Forestil dig en revisionsvirksomhed, som har udviklet en prompt til udarbejdelse af årsregnskabet for en servicevirksomhed, som en frisørsalon. Hvordan skal virksomheden beskytte prompten mod at blive anvendt i en anden virksomhed? Der er helt klart et markedsbehov for noget IT, hvor medarbejdere kan uploade datafiler og så afvikles en prompt i det skjulte uden at prompten vises for medarbejderen, hvorefter resultatet udstilles til medarbejderen. |