This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Wednesday, 26 November 2025
"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
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.
Strippa bort marknadsföring bulllocks och du kommer att upptäcka att cirka 95% av kommersiella "AI" projekt faller i en av två kategorier:
Detta är den överlägset vanligaste. Varje "företag AI-lösning" följer detta mönster:
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.
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.
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.
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:
Så här går det till:
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:
Och det är bara PDF:er.
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.
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]
Bra RAG behöver bra metadata, men att extrahera metadata från dokument är svårt:
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.
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.
Finjustering kräver kvalitet utbildningsdata. De flesta företag har inte det. De har:
"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?
Hur vet du om din finjusterade modell faktiskt är bättre? De flesta företag kan inte svara på detta eftersom:
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.
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:
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.
Missförstå mig inte.
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.
Medan alla bygger samma RAG rörledning, de faktiskt intressanta problemen i kommersiell AI ignoreras:
Den största begränsningen på AI effektivitet är inte modellen. Det är data. De flesta organisationer har:
Men "datakvalitetsinitiativ" ger dig inte en Forbes artikel som "AI transformation" gör.
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.
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:
De flesta kommersiella AI-projekt behandlar människan som en eftertänksamhet.
De verkligt värdefulla AI-tillämpningar är inte "chatbot på dina dokument." De är program som:
Men det är svårt. RAG rörledningar är enkla (ja, lättare). Så det är vad alla bygger.
En viktig drivkraft för dumma AI-projekt är konsultekosystemet:
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.
Startups faller i en något annorlunda fälla. Det är inte konsulter som driver dysfunktionen – det är finansieringsmiljön.
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:
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:
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.
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.
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?
Om du överväger ett AI-projekt, här är mitt ärliga råd:
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.
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.
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.
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.
AI är inte magi. Nuvarande LLMs hallucinate. RAG system saknar relevanta dokument. Finjusterade modeller drift. Ställ in realistiska förväntningar.
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.
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.
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.
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.
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:
Detta är betydligt mer robust än "AI hanterar allt och ibland en mänsklig kontroll."
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:
Lösningen: Lokala modeller
Moderna open-source modeller är jävligt bra. Köra lokalt innebär:
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
För inbäddning (RAG-vektorsökbiten):
För generation (de faktiska "AI"-svaren):
För Kodningsuppgifter:
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.
En förnuftig arkitektur använder:
Lokala modeller för uppgifter med hög volym, lägre komplexitet
Cloud API:er för komplexa resonemang vid behov
Denna hybrid tillvägagångssätt ger dig kostnadsfördelar av lokala slutsatser med kapaciteten hos molnmodeller när du verkligen behöver det.
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.
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.
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.
Du kan inte förbättra vad du inte kan mäta. Varje AI-system bör spåra:
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.
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.
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å.
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) 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 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.
Om du inte redan har, kolla in min RAG-serien 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:
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.
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 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:
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:
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.
Jag har skrivit mycket om dessa mönster:
Vad du kommer att lära dig |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | Arkitektur | DiSE mot Voyager "Varför strukturerad orkestrering slår monolitiska modeller" | Flera förlagor | Syntetiska beslutsmotorer 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 Från inbäddningar till produktionssystem | Lokala inbäddningar | Semantisk sökning med ONNX på CPU-vänlig lokal vektorsökning | Lokala LLM:er | SYFTE En selkf evolvign workflow system med hjälp av lokala modeller som är anslutna till varandra | API- simulering | LLMAPI Ordförande Använda lokala LLMs för att simulera API:er för testning | Praktiska regionala aktionsgrupper | Att bygga en advokat GPT 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.
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.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.