# Varför de flesta kommersiella "AI" projekt är dumma > "Vi bygger en AI-driven kunskapsassistent som kommer att revolutionera hur våra medarbetare får tillgång till information..." > > - Varje jobbannons, pitch deck och konsultförslag 2024-2025 ## Inledning Jag har tillbringat den senaste månaden eller så ordentligt nedsänkt mig själv i den kommersiella AI utrymme. Läs rikliga mängder av marknadsföring rumpa. Pored över dussintals jobbannonser. Satsade genom mer produktdemos än jag vill erkänna. Och jag har kommit till en ganska deprimerande slutsats. **Det är nästan samma sak.** "AI-driven företagskunskap bas." "Intelligent dokumentsökning." "Kund chatbot med företag kunskap." Ta bort andfådd marknadsföring kopia och du kommer att hitta samma arkitektur, samma fellägen, och samma besvikna intressenter ca sex månader längre bort. Kunden chatbot varianter är särskilt underhållande-de kan bli PR katastrofer anmärkningsvärt snabbt när utvecklare som inte förstår skyddsräcken släppa dem lös på allmänheten. Inget riktigt som din support bot glatt erbjuder återbetalningar du inte ger, att göra upp produktfunktioner som inte finns, eller gå på en filosofisk tangent om meningen med tillvaron när någon frågar om frakttider. Utan lämpliga begränsningar, kommer dessa bots gärna lova något, erkänna brott ditt företag inte begick, eller utveckla starka åsikter om konkurrenter. Kanoniska exemplet förblir Air Kanadas chatbot säker uppfinna en sorg politik som inte fanns-och företaget hålls till det i domstol. Här är den smutsiga hemligheten som ingen i ledningen vill höra: **De flesta kommersiella AI-projekt är inte innovativa.** Innan jag går vidare, en disclaimer: Jag är inte en "AI visionary" eller vad den hype-driven titeln på ögonblicket är (mestadels tidigare "blockchain visionärer" som har bekvämt pivoted). Jag är en programvaruingenjör som har byggt denna typ av system-sök, kunskapshantering, naturlig språkbehandling, beslutsstöd-i närmare tre decennier. Jag har sett denna bild tidigare med expertsystem, med semantisk webb, med stora data, med blockchain. Tekniken förändras; mönstret av överpromation och underleverans inte. [TOC] ## De två typerna av kommersiella AI-projekt Strippa bort marknadsföring bulllocks och du kommer att upptäcka att cirka 95% av kommersiella "AI" projekt faller i en av två kategorier: ### Typ 1: RAG Pipeline Detta är den överlägset vanligaste. Varje "företag AI-lösning" följer detta mönster: ```mermaid flowchart LR A[Documents] --> B[Document Ingestion Pipeline] B --> C[Vector Database / RAG] C --> D[Construct Prompts] D --> E[LLM API Call] E --> F[Hybrid Search] F --> G[Response to User] style B stroke:#ff0000,stroke-width:4px ``` Den röda lådan är där allt går sönder. Planen låter imponerande: "Vi har byggt en AI som förstår ditt företags dokument och kan svara på frågor intelligent!" Verkligheten: Du har byggt en sökmotor med extra steg och en $10,000/månad OpenAI räkning. ### Typ 2: Den finjusterade modellen Den här är ännu mindre. Pitchen: "Vi har tränat vår egen AI-modell speciellt för din bransch!" Verkligheten: Du har tagit någon annans modell och finjusterat den på en datauppsättning som förmodligen är för liten, för smutsig, och för smal för att göra en meningsfull skillnad över att bara använda basmodellen med bra uppmaningar. ```mermaid flowchart TD A[Existing LLM] --> B[Collect Training Data] B --> C[Clean Data - Maybe] C --> D[Fine-tune Model] D --> E[Deploy Model] E --> F[Discover it's not much better than base model] F --> G[Keep paying for inference anyway] G --> H[Hope nobody notices] ``` De flesta finjusterande projekt jag har sett skulle ha varit bättre tjänar genom att spendera samma pengar på att förbättra sina samtal och hämtningssystem. ## Varför dokument förtäring är där drömmar går att dö Låt oss prata om den röda lådan i RAG-diagrammet. **Dokumentintag är den del som misslyckas oftast**, och det är den delen som får minst uppmärksamhet i de flashiga demos. Här är vad säljdemo visar: - Vackra PDF-filer som flödar in i systemet - Ren markering extraherad perfekt - All din kunskap, sökbar av AI! Så här går det till: ### PDF-problemet PDF-filer är en mardröm. De är utformade för utskrift, inte för att extrahera strukturerad data. Varje PDF-tolk jag har använt har olika fellägen: - Kolumner som slås ihop felaktigt - Tabeller som blir rappakalja - Huvuden och sidfotar som förorenar innehållet - Skannade dokument som behöver OCR (och OCR har sina egna felfrekvenser) - Säkerhetsskyddade dokument som inte kan behandlas alls - Problem med teckensnittskodning som förvandlar text till skräp Och det är bara PDF:er. - PowerPoint-filer med text i SmartArt - Orddokument med spårändringar - Excel-filer med sammanslagna celler - Skannade bilder med handstil - Legacy format från system som dog på 90-talet ### Hunkande katastrof När du har extraherat text (dåligt), måste du klippa den för din vektordatabas. Det är här mer magiskt tänkande händer. "Vi kommer att använda semantisk bitning!" Bra, din 200-sidiga kontrakt är nu 500 bitar, och AI har ingen aning om vilka som är relaterade eller i vilken ordning de visas. "Vi kommer att använda fast storlek bitar med överlappning!" Perfekt, du har bara delat en mening på mitten och inbäddningen nu representerar nonsens. ```mermaid flowchart TD A[Original Document] --> B[Chunk 1: This contract shall be governed by] A --> C[Chunk 2: the laws of the State of California] B --> D[Embedding: Legal stuff?] C --> E[Embedding: Geography?] D --> F[User asks about jurisdiction] E --> F F --> G[AI: Based on my knowledge, possibly California, or maybe legal governance, who knows] ``` ### Metadata- messen Bra RAG behöver bra metadata, men att extrahera metadata från dokument är svårt: - Vad är dokumentets datum? Är det skapelsedatum, ändringsdatum eller datum som nämns i innehållet? - Vem är författaren? Personen som skapade filen, den juridiska författaren, eller ämnesexperten? - Vilken kategori tillhör den? Din taxonomi matchar förmodligen inte hur dokumenten egentligen var organiserade. - Är detta dokument fortfarande giltigt? Eller har det ersatts av något nyare som ditt system inte känner till? De flesta organisationer har decennier av dokument med inkonsekvent namngivning konventioner, mappstrukturer som var vettigt för någon som lämnade 2003, och metadata som antingen saknas eller fel. ## Den finslipade fantasin Låt mig vara tydlig: finjustering har sin plats, men det sätt på vilket de flesta företag närmar sig är i grunden trasigt. ### Uppgiftsproblemet Finjustering kräver kvalitet utbildningsdata. De flesta företag har inte det. De har: - Buller, inkonsekventa data spridda över olika system - Data som speglar hur saker och ting gjordes, inte hur de skulle göras - Data som är full av fel ingen brytt sig om att fixa - Data som är egenutvecklade men inte så värdefulla "Vi finjusterar våra supportbiljetter!" Dina supportbiljetter är fulla av frustrerade kunder, felaktig information från juniorpersonal och kantfall som inte representerar normal användning. "Vi finjusterar våra säljsamtal!" Menar du de där säljarna lovar att produkten inte kan hålla? ### Utvärderingsproblemet Hur vet du om din finjusterade modell faktiskt är bättre? De flesta företag kan inte svara på detta eftersom: - De har inte ett bra riktvärde dataset - De har inga tydliga mätvärden. - De har inte gjort rigorösa A/B-tester. - De jämför vibbar, inte data. Jag har sett företag spendera sex månader finjustera en modell och sedan har inget sätt att bevisa att det är bättre än att bara använda GPT-4 med en bra systemprompt. ### Underhållsproblem Finjusterade modeller behöver uppdateras. Ditt företag förändras. Dina produkter ändras. Dina processer förändras. Den modellen som du finjusterade i januari ger nu svar baserade på föråldrad information. Men uppdatering innebär: - Insamling av nya utbildningsdata - Köra träning igen - Validering av den nya modellen - Sprida ut den - Hoppas du inte införde regressioner. De flesta företag finjustera en gång och sedan bara leva med drift. Modellen blir långsamt mindre relevant medan alla låtsas att det fortfarande ger mervärde. ## Vad "AI" projekt egentligen är bra för Missförstå mig inte. ```mermaid flowchart TD subgraph RAGWorks["✅ RAG Works When"] R1[Well-structured docs] R2[Clear metadata] R3[Search + synthesis use case] R4[Heavy ingestion investment] R5[Feedback loops exist] end subgraph FTWorks["✅ Fine-Tuning Works When"] F1[Large high-quality dataset] F2[Base model truly struggles] F3[Ongoing maintenance budget] F4[Clear eval metrics] F5[Already tried prompting + RAG] end style R4 stroke:#00aa00,stroke-width:2px style F5 stroke:#00aa00,stroke-width:2px ``` De gröna lådorna är förutsättningarna de flesta projekt hoppar över. **"Vi har redan optimerat uppmaningen och RAG"** är baren för finjustering. **"Tung förvärvsinvestering"** Hoppa över de här och du bygger på sand. ## De verkliga problemen Ingen löser Medan alla bygger samma RAG rörledning, de faktiskt intressanta problemen i kommersiell AI ignoreras: ### Datakvalitet Den största begränsningen på AI effektivitet är inte modellen. Det är data. De flesta organisationer har: - Data sprids över dussintals system som inte pratar med varandra - Ingen enskild källa till sanning för någonting - Datastyrning som är mer ambition än verklighet - Kvalitetsfrågor som ingen har budget att lösa **Men "datakvalitetsinitiativ" ger dig inte en Forbes artikel som "AI transformation" gör.** ### Processintegration Att släppa en AI chatbot i en befintlig process gör inte magiskt det bättre. Processen måste omdesignas runt AI: s kapacitet och begränsningar. De flesta företag bara skruva AI på trasiga processer och undrar varför det inte hjälper. ### Human-AI-samarbete De bästa AI implementationer öka mänskliga förmågor snarare än att försöka ersätta dem. Men det är svårare att sälja än "AI som gör X automatiskt!" Människor + AI arbetar tillsammans kräver: - Rensa avlämningspunkter - Genomskinligt AI-resonemang - Lätta manövreringsmekanismer - Återkopplingsslingor för förbättring De flesta kommersiella AI-projekt behandlar människan som en eftertänksamhet. ### Verklig innovation De verkligt värdefulla AI-tillämpningar är inte "chatbot på dina dokument." De är program som: - Aktivera saker som tidigare var omöjliga - Skapa nya värdekategorier - Lösa problem på i grunden nya sätt Men det är svårt. RAG rörledningar är enkla (ja, lättare). Så det är vad alla bygger. ## Rådgivningskomplexet för industrin En viktig drivkraft för dumma AI-projekt är konsultekosystemet: ```mermaid flowchart TD A[Big Consultancy Tells C-Suite: You Need AI!] --> B[C-Suite Panics] B --> C[Consultancy Deploys Army of Juniors] C --> D[Recommendations: RAG + Fine-Tuning] D --> E[Build Same Thing as Last 20 Clients] E --> F[Demo Goes Well] F --> G[Reality: Real Data Breaks Everything] G --> H[Consultancy Moves On] H --> I[Internal Team Struggles] I --> J[Project Quietly Fails] J --> K[Nobody Admits It] K --> A style G stroke:#ff0000,stroke-width:3px style J stroke:#ff0000,stroke-width:3px ``` Jag har sett detta mönster dussintals gånger. Konsulten får betalt. Ledningarna får säga att de "gjorde AI." Ingenjörer fastnar underhåll något som knappt fungerar. Och själva affärsproblemet förblir olöst. ## Det VC-drivna AI-kravet Startups faller i en något annorlunda fälla. Det är inte konsulter som driver dysfunktionen – det är finansieringsmiljön. ```mermaid timeline title Technology Requirements for VC Funding 2005 : Web 2.0 - "You need social features" 2010 : Mobile - "You need an app" 2015 : Cloud - "You need to be cloud-native" 2018 : Blockchain - "You need a token" 2023 : AI - "You need an AI strategy" ``` Låter bekant? Vartannat år, det finns en ny teknik som VCs bestämmer är viktigt. Om din pitch däck inte nämner det tydligt, du inte får finansiering. Tekniken kan vara irrelevant för din faktiska produkt – spelar ingen roll. Du behöver buzzword. Jag såg detta hända med blockchain i 2017-2018. Företag som inte hade något företag att vara på en blockchain var skohorning polletter i sina produkter eftersom det är vad som fick finansiering. De flesta av dessa blockchain funktioner tyst försvann när pengarna var säkrad. **Nu händer det med AI.** Startups är skruvning LLM funktioner på produkter som inte behöver dem eftersom: - Investerare kommer inte att titta på däck utan "AI" nämns - Värderingarna är 3-5x högre för "AI-företag" - Pressen tar bara upp AI-historier - "AI-driven" är tabellinsatser för marknadsföring Resultatet? Produkter med obekväma AI-funktioner som användare ignorerar. Bränns banan på finjusterande experiment som går ingenstans. Ingenjörstid slösas på RAG-system när en enkel databas fråga skulle fungera bättre. **Det värsta är:** Många grundare vet att detta är löjligt. De bygger AI funktioner de inte tror på eftersom de behöver överleva tillräckligt länge för att bygga vad de faktiskt bryr sig om. Vissa lyckas på detta spel. De flesta inte. Om du är en startup grundare som trycks för att lägga till AI, fråga dig själv: - Har AI verkligen förbättra min produkt kärnvärde proposition? - Eller kollar jag bara en låda för investerare? Om det är den senare, bygga den minsta livskraftiga AI-funktion som kryssar i rutan, sedan fokusera på vad som faktiskt spelar roll. Låt inte finansieringsmiljön distrahera dig från att bygga något värdefullt. ## Industrikomplexet Hype Här är den obekväma sanningen ingen i AI vill diskutera: **Nästan alla i ekosystemet har ett ekonomiskt incitament att hålla igång hypen.** ```mermaid flowchart TD subgraph Researchers["🔬 Frontier Labs"] R1[Need billions for compute] R2[Must show progress to justify spend] R3[Hype generates investment] end subgraph Companies["🏢 Tech Companies"] C1[Need AI angle for valuation] C2[Must justify AI team costs] C3[Hype drives stock price] end subgraph Investors["💰 Financial Backers"] I1[Massive capital deployed] I2[Need exits and returns] I3[Hype maintains valuations] end subgraph Media["📰 Tech Media"] M1[AI stories get clicks] M2[Access depends on positive coverage] M3[Hype drives engagement] end R3 --> I1 C3 --> I1 I3 --> R1 I3 --> C1 M3 --> R3 M3 --> C3 ``` **Forskarna** Vid gränslabb behöver miljarder i beräkna för att träna nästa generation av modeller. Att pengar kommer från investerare och stora tech. För att motivera att spendera, de måste visa framsteg – och "framsteg" blir översatta till andfådd tillkännagivanden om kapacitet som kan eller inte kan materialiseras i praktiska tillämpningar. Om hype dör, finansieringen torkar upp. **Företagen** (både AI-labbet och alla som använder AI) behöver berättelsen för att fortsätta. OpenAI värdering beror på tron att AGI är runt hörnet. Varje "AI-driven" start multipel beror på AI förblir den heta sektorn. Ögonkänslor skiftar, miljarder i pappers rikedom avdunstar. **Investerarna** De behöver utgångar. De behöver musiken för att fortsätta spela tillräckligt länge för att realisera avkastning. En realistisk bedömning av nära-term AI kapacitet skulle krater värderingar över hela sektorn. **Medierna** har upptäckt att AI berättelser genererar massivt engagemang. Nuanced täckning får inte klick. "AI kommer att ta ditt jobb" och "AI genombrott löser X" gör. Tillgång till AI företag beror ofta på att upprätthålla positiva relationer – vilket innebär att kritisk täckning är karriärbegränsande. Resultatet? En självförstärkande hypecykel där alla har skäl att fortsätta uppblåsta förväntningar, och väldigt få människor drar nytta av att tala sanning. Detta betyder inte att AI inte är verkligt användbart – det är absolut, som jag har diskuterat genom denna artikel. Men klyftan mellan vad som utlovas och vad som levereras är enorm, och incitamenten är alla anpassade för att hålla den klyftan dold. När någon säger till dig att AI kommer att revolutionera din verksamhet, fråga dig själv: vad tjänar de på att du tror på det? ## Vad bör du egentligen göra? Om du överväger ett AI-projekt, här är mitt ärliga råd: ### 1. Börja med problemet, inte tekniken Fråga inte "hur kan vi använda AI?" Fråga "vilket problem försöker vi lösa?" Om AI är rätt lösning, bra. Men ofta är det inte det. ### 2. Rätta dina uppgifter först Innan du bygger en RAG rörledning, fixa ditt dokument röran. Innan du finjustera, rensa din träningsdata. AI kommer inte att fixa dina data problem; det kommer att förstärka dem. ### 3. Börja småskaligt och iterera Starta inte en massiv "AI transformation." Bygg ett litet bevis på koncept. Testa det med riktiga användare. Lär dig vad som faktiskt fungerar. Sedan expandera. ### 4. Investera i de tråkiga bitarna Dokumentet intag pipeline är inte sexig. Data rengöring är inte spännande. Utvärderingsramen är inte något du kan demo till styrelsen. Men detta är vad som avgör framgång eller misslyckande. ### 5. Var ärlig om begränsningar AI är inte magi. Nuvarande LLMs hallucinate. RAG system saknar relevanta dokument. Finjusterade modeller drift. Ställ in realistiska förväntningar. ### 6. Underhållsplan Att bygga upp systemet är kanske 30 procent av arbetet. Att upprätthålla det, förbättra det och hålla det relevant är de andra 70 procenten. Budgeten i enlighet därmed. ### 7. Fundera över om du behöver en anpassad lösning alls Kanske vad du behöver är bara bättre användning av off-the-shälf verktyg. ChatgPT med vissa anpassade instruktioner kan vara tillräckligt. Allt behöver inte en skräddarsydd AI-plattform. ## Men de behöver inte vara dumma Jag har lagt ner några ord på kommersiella AI-projekt. **Dessa projekt kan faktiskt fungera, om du närmar dig dem förnuftigt.** Problemet är inte RAG eller finjustering som begrepp. Problemet är lat genomförande, orealistiska förväntningar, och ignorera grunderna. Här är hur man gör det bättre. ### Haka AI i befintliga arbetsflöden, byt inte dem Det största misstaget jag ser är att behandla AI som en ersättning för befintliga processer snarare än en förbättring. Ditt företag har redan arbetsflöden som fungerar (för det mesta). Istället för att riva ut dem och ersätta dem med en "AI-driven" version, kroka AI i luckorna. ```mermaid flowchart TD subgraph Traditional["Traditional Workflow"] A[Document Arrives] --> B[Human Reviews] B --> C[Decision Made] C --> D[Action Taken] D --> E[Results Logged] end subgraph Enhanced["AI-Enhanced Workflow"] A2[Document Arrives] --> AI1[AI: Extract Key Info] AI1 --> B2[Human Reviews - With AI Summary] B2 --> AI2[AI: Suggest Decision Based on History] AI2 --> C2[Human Makes Final Decision] C2 --> D2[Action Taken] D2 --> AI3[AI: Auto-categorise & Log] AI3 --> E2[Results Available for Future AI Training] end ``` Lägg märke till vad som är annorlunda: - **Människor är fortfarande i slingan** för beslut som är av betydelse - **AI hanterar de tråkiga bitarna** - utdrag, sammanfattning, kategorisering - **Varje AI steg är liten och kontrollerbar** - om AI får utvinning fel, den mänskliga fångar det under översyn - **Återkopplingsloopar finns** - loggade resultat utbildar framtida AI-förbättringar Detta är betydligt mer robust än "AI hanterar allt och ibland en mänsklig kontroll." ### Använd lokala LLMs för kostnad och sekretess Här är en smutsig hemlighet: du behöver förmodligen inte GPT-4 eller Claude för de flesta uppgifter. Och du behöver definitivt inte skicka dina konfidentiella dokument till OpenAI: s servrar. **Kostnadsproblemet** På skala, API kostnader lägga upp snabbt. En upptagen RAG-system kan göra tusentals LLM samtal per dag. $0.01-0.03 per 1K polletter, det är riktiga pengar. Och när du skala, det blir värre. **Konfidentialitetsproblemet** Många organisationer kan inte (eller bör inte) skicka sina dokument till externa API:er: - Juridiska dokument med kundinformation - Medicinska journaler - Finansiella uppgifter - Ägandeforskning - Allt som omfattas av GDPR, HIPAA, etc. **Lösningen: Lokala modeller** Moderna open-source modeller är jävligt bra. Köra lokalt innebär: - **Noll marginalkostnad per fråga** - du har betalat för hårdvaran, slutsatsen är "fri" - **Fullständig dataintegritet** - inget lämnar din infrastruktur - **Inga räntegränser** - skala så mycket din hårdvara tillåter - **Anpassningsalternativ** - finjustera utan att data lämnar din kontroll ```mermaid flowchart LR subgraph Cloud["Cloud API Approach"] A1[Your Documents] --> B1[Internet] B1 --> C1[OpenAI/Anthropic] C1 --> D1[£££/month] C1 --> E1[Privacy Concerns] end subgraph Local["Local LLM Approach"] A2[Your Documents] --> B2[Your Server] B2 --> C2[Local LLM] C2 --> D2[Fixed Hardware Cost] C2 --> E2[Data Never Leaves] end ``` #### Praktiska lokala modellalternativ För **inbäddning** (RAG-vektorsökbiten): - **Meningsöversättare** - Snabbt, exakt, körs på blygsam hårdvara - **nomic-bädd** - Bra kvalitet, litet fotavtryck - **BGE-modeller** - Konkurrenskraftig med kommersiella optioner För **generation** (de faktiska "AI"-svaren): - **Llama 3.1 8B/70B** - Utmärkt allmän mening, bra instruktion följande - **Mistral/Mixtral Ordförande** - Snabbt, effektivt, bra resonemang - **I detta avsnitt ska följande punkt läggas till som punkt 3:** - Förvånansvärt kapabel för sin storlek - **Qwen 2.5** - Starkt flerspråkigt stöd För **Kodningsuppgifter**: - **KodLlama** - Speciellt utbildad för kod - **Djupsökarkodare** - Utmärkt kodförståelse - **Stjärnkodare** - Bra för många språk Att köra de här lokalt är inte så svårt som man tror. **Ollama Ordförande**, **lama.cpp**, **VLM**, eller **text-generation-slutsats** gör det enkelt. Jag har byggt ett antal appar (se botten av artikeln) som visar detta körs på konsument hårdvara. #### Hybridmetoden En förnuftig arkitektur använder: 1. **Lokala modeller för uppgifter med hög volym, lägre komplexitet** - Dokumentklassificering - Uttag av entitet - Enkla frågor och svar - Sammanfattande 2. **Cloud API:er för komplexa resonemang vid behov** - Komplex analys i flera steg - Uppgifter som kräver de största sammanhangsfönstren - Tillbaka när den lokala modellens förtroende är lågt Denna hybrid tillvägagångssätt ger dig kostnadsfördelar av lokala slutsatser med kapaciteten hos molnmodeller när du verkligen behöver det. ### Bygga inkrementellt värde, inte Big Bang Transformations ```mermaid flowchart LR subgraph Waterfall["❌ The Waterfall AI Project"] W1[Month 1-3: Requirements] --> W2[Month 4-6: Build Platform] W2 --> W3[Month 7-9: Integration] W3 --> W4[Month 10: Demo - Looks Great!] W4 --> W5[Month 11: Real Users Break It] W5 --> W6[Month 12: Project Shelved] end subgraph Incremental["✅ The Incremental Approach"] I1[Week 1-2: One Small Problem] --> I2[Week 3-4: Refine + Measure] I2 --> I3[Week 5-6: Add Capability] I3 --> I4[Week 7-8: Refine + Measure] I4 --> I5[Repeat...] I5 --> I6[Continuous Value Delivery] end style W5 stroke:#ff0000,stroke-width:3px style W6 stroke:#ff0000,stroke-width:3px style I6 stroke:#00aa00,stroke-width:3px ``` Varje steg i inkrementellt tillvägagångssätt ger mätbart värde. Varje steg lär dig något. Om något misslyckas, har du förlorat veckor, inte månader. ### Gör dokumentinlagringen till ett första klassens problem Minns du den röda lådan i diagrammet? **Investera i kvalitet över kvantitet.** Det är bättre att ha 1000 perfekt bearbetade dokument än 100.000 dåligt bearbetade. Börja med dina viktigaste dokument och få dem rätt. **Använd AI för att hjälpa till med intag.** Moderna visionsspråksmodeller (GPT-4V, Claude, LLaVA lokalt) kan faktiskt läsa komplexa dokument - tabeller, diagram, handskrivna anteckningar - på sätt som traditionella OCR inte kan. Använd dem för de hårda dokumenten. **Skapa återkopplingsloopar.** När hämtning misslyckas, logga det. När användare säger "det är inte vad dokumentet säger", fånga det. Använd denna feedback för att förbättra ditt intag pipeline. **Acceptera att vissa dokument inte fungerar.** Inte varje gammal skannad PDF är värt att kämpa med. Ibland svaret är "vi kommer att hantera den typen manuellt" snarare än att spendera månader på kant fall. ### Tänk på hela systemet, inte bara AI bit En fungerande AI-lösning behöver: Vad de flesta projekt gör vad som faktiskt fungerar |-----------|----------------------|---------------------| på dataintag på eftertänkt på primär fokus på "AI kommer att räkna ut det" med särskild rengöringsrörledning Retrieval på grund av vektorsökning - Hybridsökning + omplacering Utgång från produktion av rå LLM-utgång Strukturerad utmatning med validering på människa översyn på frivillig basis på ett integrerat sätt i arbetsflödet på till Feedback Ingen med kontinuerlig förbättringsslinga på övervakning på "Det fungerar" på Detaljerade mätvärden och varning "Version 1 forever" med regelbundna uppdateringar och omskolning AI-modellen är kanske 20% av ett arbetssystem. De andra 80% är de tråkiga saker som faktiskt gör att det fungerar i produktionen. ### Bygg upp i observerbarhet från dag ett Du kan inte förbättra vad du inte kan mäta. Varje AI-system bör spåra: - **Återhämtningskvalitet**: Hittar du relevanta dokument? Spårhämtning precision och återkalla. - **Produktionskvalitet**: Är svaren korrekta? Spåra hallucinationer (ja, detta är svårt). - **Användarnöjdhet**: Tycker folk verkligen att det är användbart? Spåra användning, slutförande hastigheter, tummen upp / ner. - **Kostnad per fråga**: Vad spenderar du egentligen? Spåra token användning, latency, infrastrukturkostnader. - **Fellägen**: När går det sönder? Spåra felfrekvenser efter dokumenttyp, frågetyp, etc. Denna data talar om för dig var du ska investera ansträngning. Kanske din hämtning är bra men generation hallucinerar. Kanske vissa dokumenttyper alltid misslyckas. Du kan inte fixa det du inte kan se. ### Slutet på "Big LLM Solves Everything" Här är det viktigaste skiftet som händer just nu: **Eran av "kasta allt på GPT-4 och hoppas på det bästa" är slut.** Den 2023-2024 strategi var enkel: få den största modellen du har råd med, stoppa ditt sammanhang fönster full av allt, och be. Det fungerade ... typ. För demos. För prototyper. För att få investeringar. Men det är dyrt, långsamt och alltmer överträffas det av smartare arkitekturer. #### Övergången till iscensatta små modeller Framtiden är inte en enda jättemodell som gör allt. **Flera specialiserade modeller som arbetar tillsammans**, var och en gör vad den är bra på. ```mermaid flowchart TD subgraph OldWay["The 2023 Approach"] A1[Everything] --> B1[GPT-4] B1 --> C1[Hope It Works] B1 --> D1[£££££] end subgraph NewWay["The 2025+ Approach"] A2[Input] --> B2[Router Model - Small/Fast] B2 --> C2[Specialist Model A - Extraction] B2 --> D2[Specialist Model B - Reasoning] B2 --> E2[Specialist Model C - Generation] C2 --> F2[Orchestrator] D2 --> F2 E2 --> F2 F2 --> G2[Output] end ``` Detta är vad jag har utforskat i min [DiSE (riktad syntetisk utveckling)](/blog/disejustvoyager) arbete – idén att **struktur slår briljans**. En omsorgsfullt iscensatt pipeline av mindre, fokuserade modeller överträffar en enda massiv modell som försöker göra allt. Samma tankegång gäller för [Syntetisk beslutsmotor](/blog/semantidintelligence) Koncept: att använda flera LLM-backends i sekvens, där varje modell ger olika styrkor. Snabba modeller för triage, exakta modeller för validering, kreativa modeller för generation. Var och en gör vad den gör bäst. #### Varför detta är viktigt för RAG Om du inte redan har, kolla in min [RAG-serien](/blog/rag-primer) Men här är den viktigaste insikten: **RAG i sig är en form av detta iscensatta tillvägagångssätt**. Du använder inbäddningar (en modell) för att hitta relevant innehåll, sedan använder en LLM (en annan modell) för att syntetisera ett svar. Nästa utveckling är att gå vidare med detta: - **Inbäddningsmodell** → hittar kandidathandlingar - **Omställningsmodell** → Order efter faktisk relevans - **Klassificeringsmodell** → bestämmer fråge intention - **Modell för små generationer** → hanterar enkla faktafrågor - **Stor resonemangsmodell** → hanterar komplex analys (endast vid behov) Varje modell är mindre, snabbare och billigare än att använda GPT-4 för allt, men tillsammans överträffar de det monolitiska tillvägagångssättet. #### Den agentiska framtiden Termen "agentic" lånas från psykologi – mitt ursprungliga fält innan jag föll in i programvara. I psykologi, byrå hänvisar till förmågan att agera självständigt, att göra val och utföra dem i världen. En agentisk person svarar inte bara på stimuli; de initierar handling, strävar efter mål, och anpassa sitt beteende baserat på utfall. **Agentiv AI** tillämpar detta begrepp på språkmodeller. I stället för det traditionella mönstret – du ställer en fråga, modellen genererar text – ett agentiskt system kan faktiskt *gör saker*. Det kan använda verktyg, köra kod, frågedatabaser, ringa API:er, skriva filer och orkestrera flera steg arbetsflöden. Det är skillnaden mellan att be någon om vägbeskrivning och anställa någon att köra dig dit. Detta är vad Anthropics senaste modeller (inklusive [Claude Opus 4.5](https://www.anthropic.com/news/claude-opus-4-5) att jag bokstavligen använder för att skriva detta via Claude Code) demonstrera så effektivt. Här är det som gör den finjusterande publiken obekväm: **Om du beskriver verktyg tillräckligt väl, behöver du inte dyr finjustering för att använda dem.** Moderna grundmodeller är anmärkningsvärt bra på verktygsanvändning utanför boxen – du behöver bara tydliga funktionsscheman och bra dokumentation i sammanhanget. Detta är en massiv övergång från Toolformer-metoden (finjustera en modell för att lära sig när man ska använda verktyg genom att mäta utfall). Det är dyrt, kräver specialiserade träningsdata, och låser in dig i en specifik uppsättning verktyg. Alternativet? Beskriv dina verktyg tydligt, ge modellen bra sammanhang, och låt det räkna ut när du ska använda dem. Resultaten är ofta bättre eftersom: - **Verktygsbeskrivningar kan uppdateras omedelbart** - ingen omskolning behövs - **Nya verktyg kan läggas till vid körning** - Lägg till ett annat schema. - **Modellen drar nytta av sitt allmänna resonemang** - inte bara memorerade mönster - **Du kan använda alla dugliga modeller** - Inte särskilt finjusterad. ```mermaid flowchart TD subgraph RAG["Traditional RAG Chatbot"] R1[User Question] --> R2[Search Documents] R2 --> R3[Construct Prompt] R3 --> R4[LLM Generates Answer] R4 --> R5[Return to User] end subgraph Agentic["Agentic AI Pattern"] A1[User Task] --> A2[LLM Understands Task] A2 --> A3[Break Into Steps] A3 --> A4{Select Tool} A4 --> A5[Execute Tool] A5 --> A6{Evaluate Results} A6 -->|Need More| A4 A6 -->|Done| A7[Return to User] end style A6 stroke:#00aa00,stroke-width:3px ``` Detta agentiska mönster skiljer sig i grunden från RAG chatbots och det är där det verkliga värdet ligger. **Ramverk som LangChain, LlamaIndex och Semantic Kernel gör detta möjligt idag.** Du kan bygga system där: - En liten snabb modell hanterar routing och klassificering - Specialiserade modeller hanterar domänspecifika uppgifter - Verktygsanvändning utökar funktioner utöver rent språk - Återkopplingsslingor möjliggör kontinuerlig förbättring De företag som räknar ut detta kommer att bygga AI-system som faktiskt fungerar. De som fortfarande försöker finjustera sin väg till framgång eller bygga ännu en RAG chatbot kommer att fortsätta att bli besviken. #### Var du kan lära dig mer Jag har skrivit mycket om dessa mönster: Vad du kommer att lära dig |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | **Arkitektur** | [DiSE mot Voyager](/blog/disejustvoyager) "Varför strukturerad orkestrering slår monolitiska modeller" | **Flera förlagor** | [Syntetiska beslutsmotorer](/blog/semantidintelligence) på att bygga pipelines för specialiserade modeller | **Grundprinciper i riktlinjerna för statligt stöd till undsättning och omstrukturering av företag i svårigheter** | [RAG-serien](/blog/rag-primer) Från inbäddningar till produktionssystem | **Lokala inbäddningar** | [Semantisk sökning med ONNX](/blog/semantic-search-with-onnx-and-qdrant) på CPU-vänlig lokal vektorsökning | **Lokala LLM:er** | [SYFTE](/blog/semanticintelligence-part10) En selkf evolvign workflow system med hjälp av lokala modeller som är anslutna till varandra | **API- simulering** | [LLMAPI Ordförande](/blog/llmapi) Använda lokala LLMs för att simulera API:er för testning | **Praktiska regionala aktionsgrupper** | [Att bygga en advokat GPT](/blog/building-a-lawyer-gpt-for-your-blog-part1) på fullständig genomgång av genomförandet av riktlinjerna för statligt stöd till undsättning och omstrukturering av företag i svårigheter Tekniken finns. Mönstren växer fram. Frågan är om din organisation kommer att bygga något förnuftigt eller något annat dumt AI-projekt. ## Slutsatser Den nuvarande kommersiella AI landskap påminner mig om den tidiga webberan. Alla behövde en "webbstrategi." Företag byggde webbplatser eftersom de var tvungna, inte för att de visste vad de skulle göra med dem. De flesta av dessa webbplatser var värdelösa. Så småningom, de företag som lyckades var de som listade ut vad webben var faktiskt bra för och byggdes för det. Detsamma kommer att hända med AI. Just nu är vi i "bygga det för att vi måste" fas. De flesta projekt är dumma. De flesta kommer att misslyckas eller underlever. Det är normalt för ny teknik. Men om du vill vara en av de som lyckas, sluta följa mallen. Börja med verkliga problem. Investera i tråkiga bitar. Och för Guds skull, fixa ditt dokument intag pipeline innan du skyller på LLM. AI är inte problemet. Dina data är. Dina processer är. Dina orealistiska förväntningar är. Fixa dem först, så kanske ditt AI-projekt inte blir dumt.