03 dec. 2025·6 min
Andrej Karpathy — djupinlärning: lärdomar för att lansera AI
Andrej Karpathys syn på djupinlärning visar hur du förvandlar neurala nät till produkter med tydliga antaganden, mätvärden och ett ingenjörsfokus.
Andrej Karpathys syn på djupinlärning visar hur du förvandlar neurala nät till produkter med tydliga antaganden, mätvärden och ett ingenjörsfokus.
En djupinlärningsdemo kan kännas som magi. En modell skriver ett rent stycke, känner igen ett objekt eller svarar på en knepig fråga. Sedan försöker du göra den demonstrationen till en knapp som folk trycker på varje dag, och saker blir röriga. Samma prompt beter sig annorlunda, edge cases hopar sig och "wow"-ögonblicket blir en supportbiljett.
Det gapet är anledningen till att Andrej Karpathys arbete har gått hem hos byggare. Han drev en inställning där neurala nät inte är mystiska artefakter. De är system du designar, testar och underhåller. Modellerna är inte värdelösa — produkter kräver bara konsekvens.
När team säger att de vill ha "praktisk" AI menar de oftast fyra saker:
Team kämpar eftersom djupinlärning är probabilistiskt och kontextkänsligt, medan produkter bedöms på tillförlitlighet. En chattbot som svarar bra på 80 % av frågorna kan fortfarande kännas trasig om de andra 20 % är säkra, felaktiga och svåra att upptäcka.
Ta en "autorespons"-assistent för kundsupport. Den ser fantastisk ut på några handplockade ärenden. I produktion skriver kunderna i slang, bifogar skärmdumpar, blandar språk eller frågar om policy-edge cases. Nu behöver du skyddsräcken, tydligt avvisandebeteende och ett sätt att mäta om utkastet faktiskt hjälpte en agent.
Många mötte Karpathys arbete genom praktiska exempel, inte abstrakt matematik. Även tidiga projekt gjorde en enkel poäng: neurala nät blir användbara när du behandlar dem som mjukvara du kan testa, bryta och fixa.
Istället för att stanna vid "modellen fungerar" skiftar fokus till att få den att fungera på röriga, verkliga data. Det inkluderar datapipelines, träningskörningar som misslyckas av tråkiga anledningar och resultat som ändras när du finjusterar en liten detalj. I den världen slutar djupinlärning låta mystisk och börjar kännas som teknik.
En Karpathy-liknande metod handlar mindre om hemliga trick och mer om vanor:
Den grunden spelar roll senare eftersom produkt-AI i grunden är samma spel, bara med högre insatser. Om du inte bygger hantverket tidigt (tydliga indata, tydliga utdata, reproducerbara körningar) blir lanseringen av en AI-funktion gissningslek.
En stor del av Karpathys påverkan var att han behandlade neurala nät som något man kan resonera om. Tydliga förklaringar förvandlar arbetet från ett "trosystem" till ingenjörsarbete.
Det spelar roll för team eftersom personen som skickar första prototypen ofta inte är samma som underhåller den. Om du inte kan förklara vad en modell gör kan du sannolikt inte debugga den, och du kan definitivt inte supporta den i produktion.
Tvinga fram tydlighet tidigt. Innan du bygger funktionen, skriv ner vad modellen ser, vad den returnerar och hur du kommer avgöra om den blir bättre. De flesta AI-projekt misslyckas på grunderna, inte på matematiken.
En kort checklista som lönar sig senare:
Klarhet visar sig i disciplinerade experiment: ett skript du kan köra om, fasta evaluppsättningar, versionerade prompts och loggade mätvärden. Baslinjer håller dig ärlig och gör framsteg synliga.
En prototyp bevisar att en idé kan fungera. En lanserad funktion bevisar att den fungerar för riktiga människor, i röriga förhållanden, varje dag. Det gapet är där många AI-projekt fastnar.
En forskningsdemo kan vara långsam, dyr och skör, så länge den visar kapacitet. Produktion vänder prioriteringarna. Systemet måste vara förutsägbart, observerbart och säkert även när indata är konstiga, användare otåliga och trafiken spikar.
I produktion är latenstid en funktion. Om modellen tar 8 sekunder överger användarna den eller trycker om knappen, och du betalar för varje retry. Kostnad blir också ett produktbeslut, för en liten promptändring kan dubbla din nota.
Övervakning är icke förhandlingsbart. Du behöver veta inte bara att tjänsten är uppe, utan att utsignalerna håller acceptabel kvalitet över tid. Datadrift, nytt användarbeteende och förändringar upstream kan tysta bryta prestandan utan att kasta ett fel.
Säkerhets- och policykontroller går från "trevligt att ha" till obligatoriskt. Du måste hantera skadliga förfrågningar, privata data och edge cases på ett sätt som är konsekvent och testbart.
Team måste oftast svara på samma frågor:
En prototyp kan byggas av en person. Lansering kräver ofta produkt för att definiera framgång, dataarbete för att validera indata och evaluppsättningar, infrastruktur för att köra det pålitligt och QA för att testa felmoder.
"Fungerar på min maskin" är inte ett releaskriterium. En release betyder att det fungerar för användare under belastning, med loggning, guardrails och ett sätt att mäta om det hjälper eller stjälper.
Karpathys inflytande är kulturellt, inte bara tekniskt. Han behandlade neurala nät som något du kan bygga, testa och förbättra med samma disciplin som vilken ingenjörsprocess som helst.
Det börjar med att skriva ner antaganden innan du skriver kod. Om du inte kan säga vad som måste vara sant för att funktionen ska fungera, kommer du inte kunna debugga det senare. Exempel:
Det är testbara påståenden.
Baslinjer kommer nästa. En baslinje är det enklaste som kan fungera, och det är din verklighetskontroll. Det kan vara regler, en sökmall eller till och med "gör inget" med ett bra UI. Starka baslinjer skyddar dig från att spendera veckor på en fin modell som inte slår något enkelt.
Instrumentation gör iteration möjlig. Om du bara tittar på demos styr du efter känslor. För många AI-funktioner säger en liten uppsättning siffror redan om du blir bättre:
Iterera sedan i täta loopar. Ändra en sak, jämför mot baslinjen och håll en enkel logg över vad du försökte och vad som rörde sig. Om framstegen är verkliga syns det i en graf.
Att skicka AI fungerar bäst när du behandlar det som teknik: tydliga mål, en baslinje och snabba återkopplingsloopar.
Formulera användarproblemet i en mening. Skriv det som ett klagomål du kunde höra från en verklig person: "Supportagenter spenderar för lång tid på att skriva svar på vanliga frågor." Om du inte kan säga det i en mening är funktionen för stor.
Välj ett mätbart utfall. Välj en siffra du kan följa veckovis. Bra val inkluderar tid sparad per uppgift, andel första utkast accepterade, minskning i redigeringar eller biljettavledning. Bestäm vad som är "tillräckligt bra" innan du bygger.
Definiera baslinjen du måste slå. Jämför mot en enkel mall, en regelbaserad metod eller "endast människa". Om AI:n inte slår baslinjen på ditt valda mått, skicka inte.
Designa ett litet test med representativa data. Samla exempel som matchar verkligheten, inklusive röriga fall. Behåll en liten evaluppsättning som du inte "tränar på" mentalt genom att läsa den varje dag. Skriv ner vad som räknas som godkänt och vad som är ett fel.
Skicka bakom en flagga, samla feedback och iterera. Börja med en liten intern grupp eller en liten procentandel av användarna. Logga indata, utdata och om det hjälpte. Fixa toppfelmoden först, kör sedan om samma test så du ser verklig förbättring.
Ett praktiskt mönster för utkastverktyg: mät "sekunder till skick" och "procent utkast använda med små redigeringar".
Många AI-funktionsfel är inte modellfel. De är "vi kom aldrig överens om vad framgång är"-fel. Om du vill att djupinlärning ska kännas praktisk, skriv antaganden och mätningar innan du skriver fler prompts eller tränar fler modeller.
Börja med antaganden som kan bryta din funktion i verklig användning. Vanliga handlar om data och människor: inmatningstext är på ett språk, användare begär en avsikt åt gången, UI ger tillräcklig kontext, edge cases är sällsynta och gårdagens mönster gäller nästa månad (drift). Skriv också vad du inte kommer hantera ännu, som sarkasm, juridisk rådgivning eller långa dokument.
Gör varje antagande till något du kan testa. Ett användbart format är: "Givet X ska systemet göra Y, och vi kan verifiera det genom Z." Håll det konkret.
Fem saker värda att skriva på en sida:
Håll offline och online separata avsiktligt. Offline-mått säger om systemet lärt sig uppgiften. Online-mått säger om funktionen hjälper människor. En modell kan prestera bra offline och ändå irritera användare eftersom den är långsam, för självsäker eller fel i de fall som betyder något.
Definiera "tillräckligt bra" som trösklar och konsekvenser. Exempel: "Offline: minst 85 % korrekta på evaluppsättningen; Online: 30 % av utkasten accepterade med minimala redigeringar." Om du missar en tröskel, bestäm i förväg vad som händer: håll det bakom en växel, dra ner rollout, routa lågkonfidensfall till en mall eller pausa och samla mer data.
Team behandlar ofta en AI-funktion som en vanlig UI-ändring: skicka den, se vad som händer, justera senare. Det kraschar snabbt eftersom modellbeteende kan förändras med prompts, drift och små konfigurationsändringar. Resultatet är mycket arbete utan tydligt bevis att det hjälpte.
En praktisk regel är enkel: om du inte kan namnge baslinjen och mätningen är du inte redo att skicka.
De vanligaste felmoder:
Ett konkret exempel: du lägger till AI för att utforma supportsvar. Om du bara spårar tumme upp kan du missa att agenter tar längre tid att granska utkasten, eller att svaren är korrekta men för långa. Bättre mätvärden är "procent skickade med minimala redigeringar" och "median tid till skick".
Behandla releasedagen som en ingenjörsavstämning, inte en demo. Du bör kunna förklara, enkelt, vad funktionen gör, hur du vet att den fungerar och vad du gör när den går sönder.
Innan du skickar, se till att du har:
Behåll också en offline-evaluppsättning som ser ut som riktig trafik, inkluderar edge cases och är stabil nog att jämföra över veckor. När du ändrar prompts, modeller eller datarengöring, kör om samma uppsättning och se vad som rört sig.
Ett supportteam vill ha en assistent som utformar svar inne i ärendevyn. Agenten skickar inte meddelanden själv. Den föreslår ett utkast, markerar nyckelfakta den använde och ber agenten granska och redigera innan skick. Det ena valet håller risken låg medan du lär dig.
Börja med att bestämma vad "bättre" betyder i siffror. Välj utfall du kan mäta från dag ett med befintliga loggar:
Innan du tar in en modell, sätt en tråkig men verklig baslinje: sparade mallar plus ett enkelt regelager (känn igen refund vs leverans vs lösenord, fyll i bästa mallen). Om AI:n inte kan slå den baslinjen är den inte redo.
Kör en liten pilot. Gör den opt-in för ett fåtal agenter, begränsad till en ärendekategori först (t.ex. orderstatus). Lägg till snabb feedback på varje utkast: "hjälpsamt" eller "inte hjälpsamt", plus en kort anledning. Fånga vad agenten ändrade, inte bara om hen klickade en knapp.
Definiera sändkriterier i förväg så ni inte gissar senare. Exempel: handläggningstiden förbättras med 10 % utan att eskalering eller återöppning ökar, och agenter accepterar utkast med minimala redigeringar åtminstone 30 % av gångerna.
Bestäm också vad som triggar rollback: en topp i eskaleringar, en nedgång i nöjdhet eller upprepade policyfel.
Välj en AI-idé du kan skicka på 2–4 veckor. Håll den tillräckligt liten för att du ska kunna mäta den, debugga den och rulla tillbaka utan drama. Målet är inte att bevisa att modellen är smart. Målet är att göra ett användarutfall pålitligt bättre än vad ni redan har.
Gör idén till en en-sidig plan: vad funktionen gör, vad den inte gör och hur ni vet att den fungerar. Inkludera en baslinje och det exakta mått ni ska följa.
Om du vill gå snabbt på implementation kan Koder.ai (koder.ai) användas för att skapa webb-, server- och mobilappar genom ett chattgränssnitt, med funktioner som snapshots/rollback och export av källkod när du behöver djupare kontroll.
Vanan att behålla är enkel: varje AI-ändring ska ha ett skriftligt antagande och ett mätbart resultat. Så slutar djupinlärning kännas som magi och börjar kännas som arbete du kan leverera.
För att demoexempel oftast bygger på rena, handplockade indata och bedöms efter känsla, medan produkter möter rörig input, användarpåverkan och upprepad användning.
För att minska gapet: definiera ett input/output-kontrakt, mät kvalitet på representativa data och designa fallbacks för timeouts och lågt förtroende.
Välj ett mått som är kopplat till användarvärde och som du kan följa varje vecka. Bra standardval:
Bestäm vad som är “tillräckligt bra” innan du finjusterar prompts eller modeller.
Använd det enklaste alternativet som realistiskt skulle kunna levereras:
Om AI:n inte slår baslinjen på huvudmåttet (utan att förstöra latenstid/kostnad), skicka inte än.
Behåll en liten uppsättning som liknar verklig trafik, inte bara bästa-fallet-exempel.
Praktiska regler:
Detta gör framsteg synliga och minskar oavsiktliga regressioner.
Börja med förutsägbara, testbara guardrails:
Behandla guardrails som produktkrav, inte valfri finish.
Övervaka både systemhälsa och outputkvalitet:
Logga också in- och utdata (med integritetskontroller) så du kan reproducera fel och åtgärda de vanligaste mönstren först.
Sätt en maximal budget från början: mål för latenstid och maxkostnad per förfrågan.
Minska spenderingen utan att gissa:
En liten kvalitetsökning är sällan värd en stor kostnad eller hastighetsnackdel i produktion.
Skicka bakom en flagga och rulla ut gradvis.
En praktisk rollout-plan:
Rollback är inte ett misslyckande; det är en del av att göra AI underhållbar.
Miniminroller som behöver täckas (även om en person har flera hattar):
Det fungerar bäst när alla är överens om mätet, baslinjen och rollback-planen.
Använd den när du vill gå från idé till fungerande app snabbt, men ändå behålla ingenjörsdiciplin.
Ett praktiskt arbetsflöde:
Verktyget hjälper dig iterera snabbare; du behöver fortfarande tydliga antaganden och mätbara resultat.