Så designar jag en AI-driven investeringsanalys utan att låta LLM:n hitta på siffror
Det farligaste med en språkmodell i finansiell analys är inte att den ibland säger "jag vet inte". Det är motsatsen: den kan leverera en välstrukturerad investeringsanalys även när underlaget saknar aktuell kurs, senaste rapport, kassaflöde eller en central balanspost.
Det farligaste med en språkmodell i finansiell analys är inte att den ibland säger "jag vet inte". Det är motsatsen: den kan leverera en välstrukturerad investeringsanalys även när underlaget saknar aktuell kurs, senaste rapport, kassaflöde eller en central balanspost. Texten kan låta som en analys långt innan systemet har rätt att analysera.
I min trading-bot blev därför en av de viktigaste funktionerna möjligheten att returnera KAN INTE BEDÖMA. Jag vill hellre ha ett explicit abstention-state än ett elegant case byggt på luckor.
LLM:n får aldrig vara min marknadsdatabas
Jag separerar först allt som ska vara deterministiskt från allt som faktiskt kräver resonemang.
Deterministiskt:
LLM-lagret får ta emot de här värdena. Det får inte "minnas" dem. Om aktuell kurs saknas ska systemet inte fråga modellen vad aktien ungefär står i.
Det här låter trivialt men förändrar arkitekturen. Prompten blir inte "analysera Dellia". Den blir snarare:
Data snapshot före analys
Jag vill att varje review bygger på ett explicit snapshot. Då går det att reproducera bedömningen senare.
Varje numeriskt fält ska ha provenance. Om siffran kommer från bolagets rapport ska vi veta vilken rapport och vilken rad. Om kursen kommer från en marknadsdatakälla ska timestamp finnas. Det betyder också att en analys kan bli inaktuell utan att ha varit fel — en viktig distinktion i finans.
Pre-flight validation bestämmer om analys får börja
Innan LLM:n ser caset kör jag en completeness gate. Exakta krav beror på strategin, men för en fundamental analys kan det exempelvis vara:
Saknas ett required-fält får analysen inte "göra sitt bästa". Resultatet ska beskriva vad som saknas och varför det blockerar en meningsfull bedömning. Det här var exakt problemet i ett case där ett bolag hade en vinstvarning men underlaget saknade aktuell kurs och uppdaterad finansiell bild. Den korrekta outputen var inte ett lågt betyg — det var att säga att värderingen inte gick att bedöma på materialet.
Separera uträkning från narrativ
Jag vill också att multiplar och värderingsmatematik sker i kod eller tydliga deterministiska funktioner.
LLM:n kan sedan resonera om vad 18x EBIT betyder givet tillväxt, kvalitet, kapitalbindning och risk. Den ska inte själv behöva hålla ihop multiplikation, valutaomräkning och definitionsval i fri text. Det är samma designprincip som i mina SQL- och contentflöden: kod äger exakt logik, modellen äger osäkrare syntes.
Värderingsmodeller är verktyg, inte ett facit
En annan fälla är att lägga in 25 värderingsmodeller och tro att fler modeller ger säkrare analys. Jag föredrar ett mindre bibliotek där varje metod har tydliga användningsvillkor.
Exempel:
Systemet ska välja metod efter företagets ekonomi, inte efter vilken formel som råkar finnas i biblioteket. Jag vill dessutom att boten rankar en metods lämplighet innan den visar resultatet, i stället för att fritt-textmässigt "välja en modell" varje gång:
Med det fältsettet kan systemet visa flera modeller sida vid sida i stället för ett magiskt fair value — och grunddatan i varje modell hämtas fortfarande från definierade källor, aldrig ur modellens minne.
Analys och beslut måste vara olika objekt
Jag vill inte att samma LLM-call både analyserar och bestämmer "köp/sälj". I stället separerar jag:
Ett analysobjekt kan säga:
- tillväxten accelererar,
- marginalen pressas,
- nettokassan ger viss nedsidesbuffert,
- värderingen kräver fortsatt expansion.
Verdict-lagret kan sedan applicera en investeringspolicy: vilken margin of safety krävs, vilka risker är blockerande och vilken confidence får sättas. Det gör det lättare att ändra investeringsramverk utan att förändra faktalagret, och lättare att felsöka: om slutsatsen är dålig går det att se om felet satt i rådatan, beräkningen eller beslutspolicyn.
Confidence är inte en procentsiffra modellen hittar på
Jag undviker "87 % confidence" om systemet inte faktiskt är kalibrerat mot historiska utfall. En LLM:s självsäkerhet är inte samma sak som sannolikhet. Jag föredrar kategorier med observerbara krav:
Då blir confidence en policy, inte en känsla.
Fler abstention-states än ett enda "kan inte bedöma"
Confidence-nivåerna räcker inte ensamma, för de förutsätter att analysen faktiskt går att göra. Jag vill i stället att systemet kan svara med ett av flera abstention-states, inte bara ett binärt ja/nej:
Triggern för vilket state som gäller ska vara datakvaliteten, aldrig modellens känsla. Och ett "kan inte bedöma" ska vara handlingsbart, inte bara en avvisning:
Kan inte bedöma nettoskuld på ett tillförlitligt sätt eftersom senaste kvartalsrapporten saknas i den aktuella datakällan. Hämta rapporten innan värderingen körs igen.
Scenarioanalys ska vara strukturerad
För många case vill jag ha bull/base/bear, men även här måste modellen få tydliga parametrar.
LLM:n kan hjälpa till att formulera varför ett scenario är ekonomiskt rimligt, men själva beräkningen körs deterministiskt. Om modellen vill ändra en parameter ska den ange orsak och källa. Det förhindrar att bear case blir "lite lägre siffror" och bull case "lite högre".
Watchlist kräver maskinläsbara villkor
Efter review kommer nästa problem: ett AVVAKTA-case kan ha ett villkor som "Q3 visar att orderingången håller och marginaldippen är måttlig". Om det bara ligger som prosa händer ingenting när Q3 kommer.
Jag försöker därför bryta villkor till triggers:
Exempel:
LLM:n kan hjälpa till att översätta en investeringshypotes till kandidater för triggers, men reglerna ska lagras strukturerat så att bevakningen faktiskt kan köras. En trigger som slår till ska normalt öppna en ny review, inte utlösa en order direkt — då hinner systemet kontrollera vad mer som förändrats sedan tesen skrevs, innan något händer.
Event detection är ett separat lager
Samma sak gäller insiders, estimatrevideringar och kursrörelser. Jag vill inte att en agent "följer bolaget" genom att ibland söka på nätet. Jag vill ha event feeds eller schemalagda checks som skapar normaliserade events.
Först därefter kan en analysagent resonera om händelsen förändrar caset.
Källkonflikt ska blockera numerisk syntes
Finansiell data kan skilja sig mellan rapport, dataleverantör och nyhetsartikel. Om två trovärdiga källor anger olika nettoskuld ska modellen inte ta medelvärdet eller välja den "rimligaste".
Jag vill ha:
Skillnader beror ofta på period, lease treatment, valuta eller definition. Det är en datamodelleringsfråga, inte ett språkproblem.
Technical analysis bör också vara regelstyrd
Jag är försiktig med att be en LLM "se" tekniska patterns och sedan sätta ett trade. Om en setup går att definiera med pris, volym, trend och volatilitet vill jag att detektorn är kod.
LLM:n kan beskriva kontext, jämföra flera signaler eller sammanfatta varför en setup är intressant. Den ska inte skapa den historiska prisserien.
Audit trail är lika viktigt som analysen
Varje verdict bör kunna återspelas:
När en analys visar sig vara dålig kan jag då fråga: var datan fel, var modellen dålig, var värderingsramverket fel eller förändrades världen efteråt? Utan den spårbarheten blir "AI-investering" mest en ström av texter som är svåra att lära sig av.
Det system jag vill ha
Min idealarkitektur ser ungefär ut så här:
Det intressanta är att LLM:n bara äger en del av kedjan. Det är medvetet.
Min viktigaste princip
Jag vill inte bygga en bot som alltid har en åsikt. Jag vill bygga ett system som vet vilken typ av svar underlaget tillåter.
Om siffrorna finns och är verifierade kan modellen hjälpa till att se samband, formulera hypoteser och jämföra risker. Om siffrorna saknas ska den säga det. Om källorna konfliktar ska den blockera. Om värderingen kräver antaganden ska de vara explicita.
Det är först då jag tycker AI blir riktigt användbart i investeringsanalys: inte som en maskin som producerar fler case, utan som ett lager ovanpå en datamodell och ett reviewprotokoll som gör det svårare att lura sig själv.
Hur jag skulle backtesta själva analysprocessen
Jag vill inte bara backtesta en teknisk setup. Jag vill även utvärdera reviewprotokollet. Ta historiska snapshots där framtiden inte är synlig, kör samma data- och analysflöde och mät sedan vilka typer av fel som återkommer. Var datakomplettheten tillräcklig? Överskattade modellen narrativ styrka? Var valuation range för snäv? Avstod systemet för ofta eller för sällan?
Det ger ett eval-set för analyskvalitet utan att låtsas att all investering kan reduceras till hit rate. Ett "bra" beslut kan få dåligt kortsiktigt utfall och tvärtom. Därför vill jag även mäta processmått: source completeness, claim correctness, scenario consistency och om verdict följde den definierade policyn.
Notifications måste kopplas till materialitet
En watchlist som skickar allt blir snabbt ignorerad. Jag vill därför att event-lagret först normaliserar händelsen och sedan kör materialitetsregler. En insideraffär på ett litet belopp, en estimatrevidering på 0,5 procent och en kursrörelse på normal volatilitet ska inte ha samma prioritet som ett rapporterat covenantproblem eller en stor prognossänkning. Modellen kan hjälpa till att beskriva betydelsen, men trösklar och prioriteringspolicy ska vara explicita och granskningsbara.
Notiser: event är inte samma sak som alert
Ett watchlist-system kan tekniskt skicka en notis varje gång en datapunkt ändras. Det betyder inte att det borde göra det. Jag skiljer på ett event — att något hände — och en alert, som betyder att det kräver uppmärksamhet. Om samma trigger är sann tio kontroller i rad ska användaren inte få tio meddelanden: jag sparar senaste notifierade state och skickar igen först när något materiellt förändras.
Notisen måste också säga varför. Inte "Aktien har förändrats", utan något i stil med:
Operating margin passerade din trigger 12 % för andra kvartalet i rad. Senaste observation 13,1 %. Ny review rekommenderas.
Severity bör styra kanal: en lågprioriterad förändring kan hamna i veckosammanfattningen, ett tidskritiskt event kan skickas direkt. Det minskar confirmation fatigue.
Jag mäter också om notisen faktiskt var värd att störa operatören för — inte bara om systemet hittade eventet. Precision är ofta viktigare än recall i ett investeringsflöde där en människa annars drunknar i larm, så jag loggar notified, dismissed, opened_case och changed_verdict. Med tiden kan materialitetsreglerna justeras utifrån vilka signaler som faktiskt ledde till review, utan att modellen själv börjar optimera på lösa känslor.
Min produktionschecklista för A013
Innan jag betraktar en metod som produktionsklar går jag igenom samma checklista jag använder för alla mina AI-flöden — versionerad input, provenance på externa fakta, spårbara first-hand-påståenden och tydliga kontrakt för vad nästa komponent får förvänta sig. Den fulla listan, och varför de flesta produktionsproblem visar sig vara kontraktsproblem snarare än modellproblem, beskriver jag i Från research paper till fungerande AI-skill.
Definitioner måste låsas lika hårt som siffror
Två system kan läsa samma rapport och ändå få olika EV/EBITDA om de behandlar leasing, pensionsskuld, minoriteter eller normaliseringar olika. Därför räcker det inte att verifiera värden; jag måste även versionera definitioner.
LLM:n ska få både värdet och definitionen när den jämför bolag. Annars kan den skriva en rimlig peer-analys med multiplar som inte faktiskt är jämförbara.
Normalisering är ett separat reviewsteg
Rapporterad EBIT kan innehålla engångsposter. Justerad EBIT kan samtidigt vara aggressivt definierad av bolaget. Jag vill därför inte att modellen automatiskt tar "adjusted" som sanningen. Normalisering bör producera en bridge:
Varje justering behöver en motivering. Det är här LLM:n kan vara användbar för att läsa noterna och klassificera poster, men själva bridge-tabellen ska vara explicit och granskningsbar.
Thesis claims ska få samma behandling som faktaclaims
En investeringsidé består inte bara av data. Den består av påståenden som "marginalen kan återhämta sig när mixen normaliseras" eller "den nya produkten höjer kapitalavkastningen". Jag vill märka sådana påståenden som THESIS_CLAIM och länka dem till observationer som skulle stärka eller försvaga tesen.
Då blir watchlist-bevakningen en fortsättning på analysen. Systemet kan fråga om verkligheten utvecklas enligt tesen, inte bara om aktiekursen går upp.
Prisrörelser ska inte automatiskt ändra fundamenta
En aktie som faller 20 procent kan bli billigare men också signalera ny information. Jag vill därför separera två triggers:
Om bara kursen förändras kan systemet räkna om valuation. Om en vinstvarning kommer måste fact snapshot och thesis uppdateras innan ett nytt verdict. Det förhindrar den farliga logiken "aktien är 20 procent billigare, alltså är caset 20 procent bättre".
Modellrouting även här
All finansiell analys behöver inte den dyraste reasoning-modellen. Datavalidering, extraction och formatering kan ofta köras billigare. Djup thesis review eller konflikter kan eskalera. Jag skulle routea efter uppgift:
Det gör systemet billigare och samtidigt säkrare eftersom modellen inte används där kod är bättre.
Hur en dålig output ska se ut
En viktig eval är att ge systemet ett avsiktligt ofullständigt case. Jag vill inte ha en kreativ analys. Jag vill ha något i stil med:
Det är en mycket högre kvalitetsnivå än en välskriven 1/100-rating på samma underlag.
Hur jag hanterar tidsdimensionen. Finansiell data är alltid knuten till tid. Ett P/E-tal utan prisdatum och resultatperiod är inte ett fullständigt faktum. Jag vill därför att varje härledd metric bär as_of för marknadsdata och period_end för rapportdata. När agenten jämför två bolag ska den kunna upptäcka om ena bolaget rapporterat Q2 och det andra fortfarande bara har Q1 — ett klassiskt ställe där snygg automation annars blandar äpplen och päron.
Currency och unit normalization. Samma princip gäller valuta och enheter. Jag normaliserar innan LLM-lagret ser datan. 13 MUSD i en acquisition note får inte blandas med MNOK och MSEK i samma resonemang utan explicit konverteringsdatum. Scripts bör äga konverteringen och lagra både originalvärde och normaliserat värde. Modellen får beskriva finansieringsrisken, men inte improvisera växelkursen.
När analyst consensus får användas. Konsensus är användbart men inte en primär sanning. Jag vill veta leverantör, antal estimat, snapshotdatum och spridning. En medianestimat utan spridning kan se mer exakt ut än det är. Om bara två analytiker täcker bolaget bör systemet kunna sänka vikten på signalen. LLM:n ska aldrig formulera "marknaden förväntar sig" om underlaget bara är ett gammalt eller tunt estimatset.
En AI-analys behöver en tydlig ansvarslinje
Slutligen vill jag att systemet gör skillnad på maskinoutput och investeringsbeslut. Agenten kan sammanställa data, kalkylera, flagga risker och föreslå ett verdict inom ett definierat protokoll. Men audit trail ska visa vem eller vad som godkände nästa steg. Det är viktigt både för lärande och disciplin: en snygg LLM-text ska aldrig göra det oklart vilken del som var data, vilken del som var modellbedömning och vilken del som var mänskligt beslut.
Hur jag behandlar kvalitativa bolagsuppgifter
Allt viktigt finns inte i tabeller. Ledningens guidning, konkurrensläge, kundkoncentration och strategiska förändringar är ofta kvalitativa. Jag vill ändå strukturera dem. Varje sådan claim får source, timestamp och claim type. Modellen kan sedan väga dem i analysen utan att blanda dem med hårda finansiella värden.
Om guidningen senare ändras kan systemet se vilken del av tesen som byggde på den gamla versionen.
Red flags bör vara explicit kodifierade
Vissa risker är så viktiga att jag inte vill att de bara dyker upp om modellen "kommer på dem". Exempel kan vara negativt operativt kassaflöde trots rapporterad vinst, snabbt stigande nettoskuld, återkommande justeringar, stora närståendetransaktioner eller kraftig utspädning. En rule engine kan flagga kandidater och låta modellen analysera kontexten. Det är ett bra exempel på hybridarkitektur: kod hittar mönstret, LLM:n förklarar om det sannolikt är materiellt, och reviewprotokollet bestämmer hur det påverkar verdict.
Kvaliteten på underlaget bör synas i outputen
Jag vill att läsaren kan se skillnaden mellan ett case byggt på komplett rapportdata och ett case med tunn information. Därför kan analysen innehålla ett data_quality-block: vilka källor som användes, vilka fält som saknas, hur färsk marknadsdatan är och om det finns konflikter. Det gör abstention begriplig och hindrar en snygg text från att dölja ett svagt faktaunderlag.
Min sista kontroll före ett verdict
Precis innan verdict kontrollerar jag att varje material numerical claim går tillbaka till snapshot eller deterministisk calculation, att thesis claims är markerade som tolkningar och att inget scenario bygger på en parameter som modellen infört utan motivering. Jag vill även se att bear/base/bull använder samma definitioner och att eventuella konflikter är lösta eller explicit blockerande. Om en enda central värderingsparameter saknar provenance ska systemet hellre sänka confidence eller avstå än att fylla luckan.
Det här är medvetet strikt. I finans är en blockerad analys billigare än ett välformulerat beslut på fel data. Dataproveniens är därför en del av investeringsdisciplinen.
Datakällor i praktiken
I en svensk implementation bör bolagsrapporter och officiella marknads-/börskällor vara primära framför modellminne. Exempel på officiella utgångspunkter är Nasdaq Nordic och respektive emittents publicerade rapportarkiv.
- SEC — EDGAR company filings
- Aswath Damodaran — Valuation resources
- OpenAI — Evals
- Google SRE — Monitoring distributed systems