Varför de flesta kommersiella projekt är dumma (Svenska (Swedish))

" Vi, ', bygger en AI-maktvis kunskapsassistent som kommer att revolutionera hur våra anställda får tillgång till information.

Varje jobadvertisering, pitch deck , och konsultansen i 2024-2025

Inleiding

Jag har tillbringat den senaste månaden ungefär ordentligt med att fördjupa mig i den kommersiella AI-rymden.

Det är nästan samma sak

"_AI-_{driven företagskunskapsbas} ."_{"_{Intelligent dokumentsökande} ."_{M SK5}Kunstchatbot med företagsexpertise} M SK6~ Släpp bort den oroväckande marknadsföringskopien och du hittar samma typ av architecture ~ ,~ samma misslyckande former ~ ,~ och samma besvikna intressenter ungefär sex månader senare.

Kundenchatbot-varianter är särskilt roliga.—, de kan bli PR-katastrofer otroligt snabbt när utvecklare som inte förstår vaktväggen låter dem komma åt allmänheten.., det är inget som att en stödrobot gladt erbjuder återbetalningar du inte ger, ', gör upp produktfenskaper som inte finns,', eller går på ett filosofiskt sätt om meningen med existens, när någon frågar om fraktstid,., utan rätta begränsningar,M SK8, så kommer dessa robotar lyckligtvis lova något.Mska9, erkänner brott som ditt företag inte gjorde,Mska10, inte anklagar, Mska11, eller utvecklar starka åsikter om konkurrenterna,Mske12, det kanoniska exemplet är Air Canadas chatbot, som självförtroendet uppfann en avlidningspolitik som inte existerade,M Ska14, och företaget stod inför rättegång.M Ska16

Här är den smutsiga hemligheten som ingen i management vill höra. de flesta kommersiella AI-projekt är

Innan jag går vidare, så är det här: , en förbevakning, :, I', jag är inte en AI-visionär eller vilken hype som helst som ledde titeln för tillfället. Det är "(", de föregående visionärerna med blockchainer och ", som "" МSK9 "" -arbetade på ett bekvämt sätt. )., Jag är en mjukvaruingenjör som "". ' "" har byggt sådana här system ".—", "" Research "", , "" och "" Knowledge Management "".

De två typerna av kommersiella AI-projekt

Släpp bort marknadsföringsmissbruken och du kommer att se att ungefär 95% av kommersiella | " | AI | МSK3 | projekt faller in i en av två kategorier

Typ 1: RAG Pipeline

Det är den vanligaste lösningen.

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 där röda lådan, ?, det där allt går sönder.

Pitch låter imponerande

Verkligheten: Du ' har byggt en sökmotor med extra steg och ett £10,000/ månads OpenAI-bil

Typ 2: Den fina-Anpassningsmodellen

Den här är ännu ljusare. . Pitch: : , " Vi har tränat vår egen AI-modell speciellt för din industri.

Verkligheten: :, du, ', har tagit någon annans modell och gjort det bra. -, har justerat den på en datamängd som är troligtvis för liten, ,, för smutsig, M SK6 och för smal för att göra en meningsfull skillnad jämfört med att bara använda basemodellen med bra instruktioner.

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 mest fina projekt som jag sett skulle ha tjänats bättre genom att spendera samma pengar på att förbättra deras promptsystem och söksystem.

Varför är dokumentsmältning var drömmar kommer att dö

Låt oss prata om den röda lådan i RAG-diagrammet. Dokumentingestion är den del som ofta misslyckas, och det är den delen som får minst uppmärksamhet i blixtliga demoer

Här är vad demon visar

vackra PDF som flödar in i systemet
Rent markerdown extraherat perfekt
Alla dina kunskaper, sökbar av AI!

Här är vad som faktiskt händer.

PDF-problemet

PDF är en mardröm.

Kollor som blir sammanfogade felaktigt
Talar som blir dumma
Rubriker och fotskrif som förorenar innehållet
Skanderade dokument som behöver OCR ( och OCR har sina egna felfrekvenser )
säkra dokument som inte kan behandlas alls
Fontkodering som gör att text blir skräp

Och att "'" är bara PDFs . . Vänta tills du klickar.

PowerPoint-filer med text i SmartArt
Woorddokument med spårförändringar
Excel-Dater med sammanfogade celler
Skanderade bilder med handskrift
Avlägsna format från system som dog i 90s

Katastrofien i Melbourne

När du väl har extraherat text, måste du killra den till din vektordatabas. Det är här som mer magiska tankar händer.

" Vi ' använder semantisk chunkning!" BraM SK3 ditt 200--sidakontrakt är nu 500 chunks , och AI har ingen aning om vilka som är besläktade eller i vilken ordning de kommer upp

" Vi ' ska använda fixera - stora bitar med överlappande M SK3 Perfekta MST4 du MSV5 du har bara delat en mening i två och inbäddningen representerar nu nonsens

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]

Messen om metadata

Bra RAG behöver bra metadata. Men att extrahera metadata från dokument är svårt

Vad är dokumentens datum? Är det skapades datum? Modifieringsdatum? , eller datan i innehållet?
Vem, ', är författaren,?, personen som skapade pliken,,, lagstiftaren,M SK3, eller ämnesexperten,
Vad är den i kategorin?
Är denna dokument fortfarande geldig? Eller har den ersatts av något nyttare som systemet inte känner till?

De flesta organisationer har årtionden av dokument med okonsekvente namnskonventioner, folderstrukturer, som verkade vettiga för någon som lämnade i "2003,", och metadata som ' antingen saknas eller är felaktiga.

The Fine-Tuning Fantasy

Låt mig vara tydlig.

Dataproblemet

Fint- stämmande kräver kvalitet i utbildningsdata . De flesta företag har inte det ' inte det

Noisy, okonsistenta data spridda över system
Data som visar hur saker gjordes, inte hur de borde göras
Data som "'" är full av fel som ingen någonsin behövt fixa
Data som är egendomligt för ' men inte riktigt så värdefullt

" Vi ' kommer att bli olyckliga - får bra resultat på våra stödbiljetter M SK3 dina stödbiljettar är fulla av frustrerade kunder MSC4 felaktig information från unga anställda MST5 och marginalfall som inte representerar normal användning M ST7

" Vi ' kommer att bli bra, - får tur på våra försäljningsprångar, !" Du menar de där försäljare ger löften om att produkten kan

Evaluationsproblemet

Hur vet du om din bra modell är faktiskt bättre? De flesta företag kan inte svara på detta eftersom

De har inte en bra datauppsättning
De har inga tydliga utvärderingsmått
De har inte gjort rigorösa A-tester
De comparerar viber, inte data.

Jag har sett företag spendera sex månader med böter, modifiera en modell och sedan inte ha något sätt att bevisa att den är bättre än att bara använda GPT.

Konserveringsproblemet

Fint-justerade modeller behöver uppdateras . dina företagsförändringar . dina produkter förändras МSK3 dina processer förändras~ . Den modell du justerade i januari, -, visar nu svar baserat på föråldrade informationer

Men att uppdatera innebär

Samma nya utbildningsdata
Att köra träning igen
Validatering av den nya modellen
Deploring
Förhoppning att du inte introducerade regressioner

De flesta företag är bra på att vara en gång och sedan bara leva med driften. Modelet blir långsamt mindre relevant medan alla låtsas att det.

Vad är projekt egentligen bra för

Missförstå mig inte. Det finns legitima användningsområden.

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 nödvändiga för de flesta projekt " Vi ' har redan optimerat prompting och RAG är baren för fin , "-", och tunning . "Grot intagningsinvestering is the bar for RAG. Skip these and you 're building on sand

De verkliga problemen som ingen löser

Medan alla - ' - bygger samma RAG-kanal -, - ignoreras de intressanta problemen i kommersiell AI.

Datakvalitet

Den största begränsningen för AI-effektivitet är att

Data sprids över dussintals system som inte talar med varandra
Ingen enda källa till sanning för något
Datastyre som "'" har mer ambition än verklighet
Kvaliteproblem som ingen har budget att lösa

Men """ -datakvalitetsinitiativen """ gör det inte, ' "" ger dig inte en Forbes-artikel som "" МSK3 "", "" AI-transformation "", " "", eller .

Prosesintegrering

Att slänga in en AI chatbot i ett redan proces gör det inte bättre på något magiskt sätt.. Processen måste omdesignas runt den AI: s kapaciteter och begränsningar, ' Most companies just bolt AI onto broken processes and wonder why it doesn' t help

Människo---AI-kolaboration

De bästa AI-implementeringarna ökar mänskliga förmågor snarare än att försöka ersätta dem.

Människor + artificiell intelligens som arbetar tillsammans kräver

Klara handoff-punkter
Transparent AI resonemang
Lika överrider mekanismer
Feedback-loop för förbättring

De flesta kommersiella AI-projekt behandlar människan som en efterthought

Verklig innovation

De verkligt värdefulla AI-applikationerna är

Aktivera saker som tidigare var omöjligt
Create new categories of value
Lösa problem på fundamentalt nya sätt

Men de är svåra.

Konsultationsindustrikomplexet

En viktig drivkraft för dumma AI-projekt är konsultsystemet.

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. Konsultationer får betalt. Executiver får säga att de har gjort AI. Ingenjörerna fastnar i att underhålla något som knappt fungerar. Och det faktiska affärsproblemet är fortfarande olöst.

VC-driven AI krav

Startups faller in i en lite annorlunda fälla.

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 välbekant? Vart tionde år , finns det' en ny teknik som VK-makterna bestämmer att är nödvändigaM SK3 Om din pitch deck inte talar om på ', så kommer du inte att få pengar till denMSC7 Teknologin kanske inte är relevant för ditt faktiska produktMST8, det är inte så, MST9, det spelar ingen roll, M ST10, du behöver det där brångliga ordet, M st11

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 stoppade ut tokens i sina produkter eftersom det var vad som fick finansiering av ' Most of those blockchain features disappeared quietly once the money was secured | .

Nu händer det med AI

Startups tar fram LLM-featuder på produkter som inte behöver dem eftersom

Investorer fick inte titta på kortbord utan att nämna "" ", AI, " "".
Valuationerna är 3-5x högre för "AI-bolagen
Pressen rapporterar bara AI-berättelser
"" ", AI, -, kraftfulla " är bords stakes för marknadsföring

Resultatet? produkter med obehagliga AI-feature som användare ignorerar . uppbrännade startvägar på finta bränslen - tunning experiment som inte går någonstans M SK3 Inženieringstid slösas bort på RAG-system när en enkel databasequery skulle fungera bättre

Den värsta delen många grundare vet att detta är dumt. De bygger AI-feature som de inte tror på, eftersom de behöver överleva länge nog för att bygga det de faktiskt bryr sig om. Några lyckas med det här spelet.

Om du är en nystartare som tvingas lägga till AI, fråga dig själv:

Gör AI verkligen bättre på mitt produkt?
Eller är jag bara kollande en box för investerare?

Om det är "'" som är det sista , , Build the minimum viable AI feature that ticks the box, then focus on what actually matters" (Skratt om vad som verkligen betyder något) "Do not, ', let the funding environment distract you from building something valuable." (Skatt om när man bygger något värdefullt)

Hype-industrins komplex

Här är det obehagliga sanningen som ingen inom AI vill diskutera. nästan alla i ekosystemet har ett ekonomiskt incitament

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 på gränslabb behöver miljarder i beräkningar för att träna nästa generation av modeller. Den pengarna kommer från investerare och stora tekniker. För att rättfärdiga att spendera, de måste demonstrera framsteg— och " framstegen" blir översatta till ademlösa tillkännagivanden om möjligheter som kan eller inte materialiseras i praktiska tillämpningar. Om hypet dör, finansieringen torkar upp.

Företagen (, både AI-labberna och alla som använder AI, ), behöver berättelsen för att kunna fortsätta.., OpenAI, ', är beroende av att man tror att AGI är på spåret.

Investorerna har investerat häpnadsväckande summor av kapital i AI

Media har upptäckt att AI-berättelser genererar massivt engagemang.. Nyanserlig omfattning får inga träffar, ' inte några klick,. " AI tar ditt jobb, " och ", AI-avbrott löser problem, X, MSC6, gör det, M SK7, tillgången till AI-bolag beror ofta på att upprätthålla positiva relationer, МSK8, vilket betyder att kritiskt omfattning är karriär.

Resultaten? En självförstärkande hypecykl där alla har anledningar att fortsätta uppväxla förväntningar , och väldigt få människor drar nytta av att berätta sanningen

Detta betyder inte att AI är riktigt användbar, det är absolut det, som jag har diskuterat under hela artikeln.

När någon säger till dig att AI kommer revolutionera ditt företag fråga dig själv vad de tjänar på att du tror det

Vad ska du egentligen göra?

Om du tänker på ett AI-projekt

1. Börja med problemet , Inte teknologin

Inte fråga: "" Hur kan vi använda AI? "" "?"" Fråga: ""... What problem are we trying to solve?" "If AI is the right solution?" , "Great." . "But often it isn't"

2. Fixera dina data först

Innan du bygger en RAG pipeline, löser din dokumentmängd . Innar du klarar dig med det- stämdar dina utbildningsdataM SK4 AIn kommer att fixa dina dataproblemMska6 den kommer att förstärka demMske7

3. Start small and Iterate

Build a small proof of concept . Test it with real users . Learn what actually works

4. Investera i de tråkiga bitarna

Dokumentinspetsningskedjan är inte sexig, datauttorning är inte spännande, utvecklingsframställningen är inte något du kan demonstrera på brädan, men det här är vad som bestämmer framgång eller misslyckande.

5. Var ärlig om begränsningar

AI är inte "'", t magi , . Current LLMs hallucinate, . RAG-system missar relevanta dokument, . Fin (fin)

6. Plan för underhåll

Att bygga systemet är kanske 30% av ansträngningen . Att upprätthålla det ♫ , ♫ Att förbättra det | , ♫ och hålla det relevantt är den andra ♫70%. ♫ Budgeten accordingly ♫

7. Betänk om du behöver en personlig lösning överhuvudtaget

Kanske vad du behöver är bara bättre användande av av avlägsna verktyg. ChatGPT med några egna instruktioner kan vara tillräckligt.

Men de behöver inte vara dumma

Okej, jag har spenderat ganska många ord på att skämta om kommersiella AI-projekt. dessa projekt kan faktiskt fungera

Problemet är: ', t RAG eller bra -, sammansättning som koncept ., problemet är sluggiga implementering ,, orealistiska förväntningar ,, och att ignorera grunderna . Här, ' hur man gör det bättre .

Hook AI in i existerande arbetsflöden , Don' inte ersätta dem

Den största misstag jag ser är att behandla AI som en lösning på existerande processer snarare än en förbättring.

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

Titta på vad som skiljer sig.

Människor är fortfarande i cirkeln för beslut som är viktiga
AI hanterar tråkiga bitar - extraktion
Varje AI- steg är litet och verifierbart - om AI får fel utvinning , fångar människan den under undersökningen
Feedback-loopar existerar - registrerade resultat tränar framtida AI- förbättringar

Detta är betydligt mer robust än " AI hanterar allt och ibland checkar en människa

Använd lokala LLM för kostnad och integritet

Här är en smutsig hemlighet.

Det kostnadsproblemet

På skala, ,, API-kostnaderna ökar snabbt.., ett hektiskt RAG-system kan göra tusentals LLM-sändningar per dag.., på $0.01-0.03, per ,1, ett stort antal tokens, och ,, det är 's riktiga pengar.

Konfidentialitetsproblemet

Många organisationer kan-'t (eller borde de-'tM SK3 skicka sina dokument till externa APIs- -:

Rättsdokument med klientinformation
medicinska rekord
Finansdata
Proprietära forskning
Allt som är fallande under GDPR, HIPAA , etc.

Lösningen: Lokala modeller

Moderna öppna modeller är fruktansvärt bra

Null marginal kostnad per query - du ' har betalat för hårdvaran
Hela individen - inget lämnar din infrastruktur
Inga prisgränser - skala så mycket som din hårdvara tillåter
Variationer för personalisering - bra - stämma utan att data lämnar din kontroll

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 modellers möjligheter

För inbäddar (RAG-vektorsökningbiten

mening-transformatorer - snabb , korrekt , funkar på blygsam hårdvara
nomic-embed - Mycket bra kvalitet , liten fotavtryck
BGE-modeller - Konkurrerande med kommersiella alternativ

För generation (den faktiska "AIM SK2 svaren

Llama 3.1 8BM SK2B - Utmärkt allmän syfte, bra instruktion som följer
Mistral - snabb , effektiv
Phi-3 - förvånansvärt kapabel för sin storlek
Qwen 2.5 - Stark multilinguell stöd

För programmerande uppgifter:

CodeLlama - Speciellt tränad för kod
DeepSeek Koder - Utmärkt kodförståelse
StarCoder - Bra för många språk

Att köra dessa lokalt är inte så svårt som du tror. Ollama, llama.cpp, vLLM, eller text-generation-inferens göra det enkelt.

Den hybrida metoden

Du behöver inte göra allt.

Lokala modeller för höga, -, volymer och lägre , och - komplexa uppgifter
- Dokumentsklassificering
- Enhetens extraktion
- Enkela Q&A
- sammanfattning
Cloud APIs för komplext resonemang när det behövs
- Kompleks multi-step-analys
- Tacker som kräver de största kontextfensterna
- Fallback när lokal modellförtroende är låg

Den här hybrida tillvägagångsviisin ger dig kostnads fördelarna med lokalt utvärderi med möjligheten att skapa molnmodeller när du verkligen behöver det.

Build Incremental Value , Inte Big Bang Transformations

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 den inkrementella metoden ger mätbara värden.

Göra dokumentingestion till en första sak i klass -

Kom ihåg den röda lådan i diagrammet.

Investera i kvalitet över kvantitet. Det är bättre att ha 1,000 perfekt bearbetade dokument än 100,000 dåligt bearbetande documents

Använd AI för att hjälpa till med ingestionen. Modernt synsätt-språksmodeller (GPT-4VM SK3 ClaudeMSC4 LLaVA lokaltMska5 kan faktiskt läsa komplexa dokument Mske6 tabellerMsek7 diagrammerMkse8 handskrivna anteckningar | Mske9 på ett sätt som traditionell OCR inte kan |Mska10 Använda dem för hårda dokument

Att bygga feedback-loopar. När spårning misslyckas, log in det. När användare säger M SK2 att ' inte är vad dokumentet säger

Acceptera att vissa dokument kommer att fungera Inte varje forntida scannerad PDF är värt att kämpa med.

Tänk på hela systemet, Inte bara AI-biten

Ett fungerande AI-lösning behöver:

Komponent ♫	♫ Vad de flesta projekt gör ♫
Införing av data			Utväg			Primära fokus	МSK3
Datakvalitet			"	AI kommer räkna ut det
Tillförsel	Enkel vektorsökning	Hybridsökning		3	Rangering
Generering			rå LLM utgång	МSK2	strukturerad utgång med validering ♫
Människolära			Optionell			Integrerad i arbetsprocessen
Feedback
övervakning ♫	♫ ♫" ♫ Det ♫
Konservering			"Version ♫ ♫ 1 ♫ för alltid ♫

Den AI-modellen är kanske "20%" av ett arbetssystem . . är den tråkiga grejen som faktiskt gör att det fungerar i produktionen.

Att göra det synligt från första dagen

Man kan inte förbättra vad man kan mäta.

Uppfinningskvalitet: Hittar du relevanta dokument ? Precision i spåret och återhämtandet
Generationskvalitet: Är reaktionerna korrekta ? Märgselhallucinationsfrekvenser
Tillfredsställelse: Är det något som folk faktiskt tycker är användbart?
kostnad per fråga: Vad spenderar du faktiskt på?
Misslyckande former: När bryter det sig ? spåra felfrekvenser efter dokumenttyp

Dessa data talar om för dig var man ska investera pengar.

slutet av "Big LLM löser allt

Här är den viktigaste förändringen som händer just nu eran av """, släng allt på GPT, och hoppas på det bästa, " är på väg att ta slut.

2023-2024 tillvägagångssättet var enkelt : skaffa det största modellen du kan försörja dig för, , fylla ditt kontextfenster med allting, , och böna,. Det fungerade, M SK5 lite som . För demonstrationer, MST7, För prototyper, Mst8, För att få investeringar, M st9

Men den skalar inte, SK0, SK1, SK2 är dyr, SK3, SK4 är långsam, SK5 Och alltmer, SK6, SK7 blir bättre på grund av smartare arkitekturer.

Rödningen till orkestrerade små modeller

Framtiden är inte en gigantisk modell som gör allt flera specialiserade modeller som arbetar tillsammans, var och en gör vad det är ' är bra på

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

Det här är vad jag har utforskat i min DiSE (Inriktad syntetisk evolution) jobbade med idén att struktur beats briljans. En noggrant orkestrerad pipeline av mindre, fokusserade modeller överträffar en enda massiv modell som försöker göra allt

Samma tanke gäller Syntetiska beslutsprocessor koncept: med flera LLM-backends i sekvensen , där varje modell ger olika styrkor

Varför är detta viktigt för RAG

Om du inte redan har RAG-serien som går djupt in i grunden. RAG i sig själv är en form av den här orkestrerade approachen. Du, ', använder embeddinger, ♫ (, en modell, ), för att hitta relevant innehåll, | ,, sedan använder du en LLM. ♫

Nästa utveckling tar detta ännu längre.

Embeddingsmodell → hittar kandidatdokument
Reranking-modellen → order efter faktisk relevans
Klassifieringsmodell → bestämmer frågans syfte
En liten-generationsmodell → hanterar enkla faktafragen
Ett stort resonemangsmodell → hanterar komplex analys ( endast när det behövs

Varje modell är mindre, snabbare, billigare än att använda GPT.

Agentiska framtiden

Ordet "" agentisk "" är från psykologi. "" Agency "" står för förmågan att agera oberoende av andra, att göra val och utföra dem i världen "". "Agentiv person" är en person som inte bara reagerar på stimuler, utan också agerar. ;: e, ,: s" strävar efter mål "M SK 10", och anpassar sitt beteende baserat på resultat

Agentisk AI tillämpar det här konceptet på språkmodeller. göra saker. Den kan använda verktygen , utföra koden , sökdatabaser M SK3 kalla APIs, , skriva filen,, och orkestrera flera saker, m.in. - steg i arbetsflödet, . Det är skillnaden mellan att fråga någon efter vägledningar och att anställa någon för att köra dig dit.

Det här är vad de senaste modellerna av Anthropic ' , m.in. Claude Opus 4.5 som jag bokstavligen använder för att skriva detta via Claude Code

Här är det som gör den fina publiken obekväma om du beskriver verktygen tillräckligt bra, Moderna fundamentsmodeller är anmärkningsvärt bra på att använda verktyg utanför boxen.

Det här är en stor förändring från Toolformer-metoden. (fint, -formuera en modell för att lära sig när man ska använda verktyg genom att mäta utfallet,). Det är så, att ' är dyrt,,, kräver specialiserade utbildningsdata,M SK5, och lockar in dig i en specifik uppsättning verktyg.

Resultaten är ofta bättre eftersom

verktygsbeschreibunger kan uppdateras omedelbart - ingen omkvalificering
Nya verktyg kan läggas till vid starttid - bara lägga till ett annat schema
Modellet gynnar sig av dess generella resonemang - inte bara memorerade mönster
Du kan använda vilken typ av modell som helst - inte särskilt fin

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 grundligt från RAG chatbots

Ramper som LangChain, ,, LlamaIndex och Semantic Kernel gör det möjligt idag. Du kan bygga system där

En liten snabb modell hanterar ruttering och klassificering
Spetsialiserade modeller hanterar domenier-specifika uppgifter
Att använda verktyg för att utöka möjligheter bortom ren språk
Feedback-loopar möjliggör kontinuerlig förbättring

De företag som räknar ut detta kommer att bygga AI-system som faktiskt fungerar.

Var man kan lära sig mer

I' har skrivit mycket om dessa mönster

Topic
Arkitektur	DiSE mot Voyager	Varför beatar strukturerad orkestr monolitiska modeller?
Multi-Modell	Syntetiska beslutsmotorer	Byggnader av specialiserade modeller
RAG Fundamentals	RAG-serien	Från inbäddar till produktionssystem
Lokala Embeddinger	Semantiska sökningar med ONNX	CPU-vänlig lokal vektorsökning
Lokala LLMs	DiSE	Ett selkf evolvign arbetsflödesystem med hjälp av lokala modeller sammankopplade.
API-simulationer	LLMApi	Att använda lokala LLM för att simulera APIs för att testa
Praktisk RAG	Att bygga en advokat GPT	Rakett implementering av RAG

Teknologin finns, det finns mönster på gång, frågan är om organisationen ska bygga något vettigt eller ett annat dumt AI-projekt.

Slutsatsen

Den nuvarande kommersiella AI-landskapen påminner mig om den tidiga webåldern.

Till slut var de företag som lyckades de som listade ut vad webben faktiskt var bra för och byggde för det.

Just nu är vi i """ och bygger den eftersom vi måste """ -fasen, .". De flesta projekt är dumma. "" МSK5 "" De flesta kommer att misslyckas eller underförverkligas. "". . "" Det är normalt för nya tekniker "".

Men om du vill bli en av de som lyckas, stämda från att följa mallen. Starta med riktiga problem. Investera i tråkiga grejer. .. Och för guds skull fixa ditt dokumentinspegningskedjor innan du skyller på LLM.

Det är inte AIn som är problemet. dina data är ., dina processer är ., dina orealistiska förväntningar är

Fixera de första, , och kanske ,, kanske bara ,, så kommer ditt AI-projekt att bli bra.