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
"Stiamo costruendo un assistente di conoscenza ad alta tecnologia che rivoluziona il modo in cui i nostri dipendenti accedono alle informazioni..."
- Ogni annuncio di lavoro, pitch deck, e proposta di consulenza nel 2024-2025
Ho trascorso l'ultimo mese o così correttamente immergermi nello spazio AI commerciale. Leggere quantità copiose di marketing bumf. Pored più di dozzine di annunci di lavoro. Sat attraverso più demo di prodotto che mi interessa ammettere. E sono giunto ad una conclusione piuttosto deprimente.
E' quasi la stessa cosa.
"La base di conoscenza dell'azienda basata sull'AI." "Ricerca intelligente di documenti." "Chatbot cliente con conoscenza aziendale." Strip via la copia di marketing senza fiato e troverete la stessa architettura, le stesse modalità di fallimento, e gli stessi stakeholder delusi circa sei mesi più avanti.
Le varianti dei chatbot del cliente sono particolarmente divertenti possono diventare catastrofi PR notevolmente rapidamente quando gli sviluppatori che non capiscono guardrails li lasciano liberi sul pubblico. Niente come il vostro bot di supporto che offre allegramente i rimborsi non si dà, componendo le caratteristiche del prodotto che non esistono, o andando su una tangente filosofica circa il significato dell'esistenza quando qualcuno chiede circa i tempi di spedizione. Senza vincoli adeguati, questi bot felicemente promettono nulla, ammettono i crimini la vostra azienda non ha commesso, o sviluppano opinioni forti sui concorrenti. L'esempio canonico rimane il chatbot di Air Canada fiduciosamente inventando una politica di lutto che non esisteva e l'azienda è tenuta ad esso in tribunale.
Ecco il segreto sporcaccione che nessuno nella direzione vuole sentire: La maggior parte dei progetti commerciali di IA non sono innovativi, sono impianti idraulici di materie prime con un'etichetta elegante.
Prima di andare oltre, un disclaimer: non sono un "visionario AI" o qualunque sia il titolo hype-driven del momento (per lo più ex "visionari blockchain" che hanno comodamente pivoted). Sono un ingegnere software che sta costruendo questo tipo di sistemi di ricerca, gestione della conoscenza, elaborazione del linguaggio naturale, supporto decisionale per quasi tre decenni. Ho visto questa foto prima con sistemi esperti, con web semantico, con big data, con blockchain. La tecnologia cambia; lo schema di overpromising e underdelivering non lo fa.
Strappare le palle di marketing e troverete che circa il 95% dei progetti commerciali "AI" rientrano in una delle due categorie:
Questo è di gran lunga il più comune. Ogni "soluzione AI aziendale" segue questo schema:
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
Quella scatola rossa e' dove tutto si rompe, piu' avanti in un attimo.
Il passo suona impressionante: "Abbiamo costruito un AI che capisce i documenti della vostra azienda e può rispondere alle domande in modo intelligente!"
La realtà: Hai costruito un motore di ricerca con ulteriori passi e una banconota OpenAI da 10.000 sterline al mese.
Questo è anche sillier. Il passo: "Abbiamo addestrato il nostro modello AI specificamente per il vostro settore!"
La realtà: Hai preso il modello di qualcun altro e perfezionato su un set di dati che è probabilmente troppo piccolo, troppo sporco, e troppo stretto per fare una differenza significativa rispetto solo utilizzando il modello di base con buoni suggerimenti.
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]
La maggior parte dei progetti di messa a punto che ho visto sarebbero stati meglio serviti spendendo gli stessi soldi per migliorare i loro prompt e sistemi di recupero.
Parliamo di quella scatola rossa nel diagramma RAG. L'ingestione del documento è la parte che più spesso fallisce, ed è la parte che ottiene la meno attenzione nei demo appariscenti.
Ecco cosa mostra la demo di vendita:
Ecco cosa succede veramente:
I PDF sono un incubo. Sono stati progettati per la stampa, non per estrarre dati strutturati. Ogni parser PDF che ho usato ha diverse modalità di guasto:
E questi sono solo PDF. Aspetta di premere:
Una volta estratto il testo (povero), è necessario ritagliarlo per il database vettoriale. Questo è dove accade più pensiero magico.
"Useremo pezzi semantici!" Grande, il vostro contratto di 200 pagine è ora 500 pezzi, e l'IA non ha idea di quali sono collegati o in che ordine appaiono.
"Useremo pezzi di dimensioni fisse con sovrapposizione!" Perfetto, hai appena diviso una frase a metà e l'incisione ora rappresenta una sciocchezza.
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]
I buoni RAG hanno bisogno di buoni metadati. Ma estrarre i metadati dai documenti è difficile:
La maggior parte delle organizzazioni ha decenni di documenti con convenzioni di denominazione incoerenti, strutture di cartelle che avevano senso per qualcuno che se ne è andato nel 2003, e metadati che sono mancanti o sbagliati.
Vorrei essere chiaro: la messa a punto ha il suo posto. Ma il modo in cui la maggior parte delle aziende si avvicina è fondamentalmente rotto.
La messa a punto richiede dati di formazione di qualità. La maggior parte delle aziende non ce l'hanno. Hanno:
"Metteremo a punto i nostri biglietti di supporto!" I tuoi biglietti di supporto sono pieni di clienti frustrati, informazioni errate da parte dello staff junior, e casi di bordo che non rappresentano un uso normale.
"Metteremo a punto le nostre telefonate di vendita!" Intendi quelle in cui i venditori fanno promesse che il prodotto non può mantenere?
Come fai a sapere se il tuo modello perfezionato è in realtà meglio? La maggior parte delle aziende non può rispondere a questo perché:
Ho visto le aziende spendere sei mesi di messa a punto di un modello e poi non hanno modo di dimostrare che è meglio che utilizzare solo GPT-4 con un buon prompt di sistema.
I modelli perfezionati devono essere aggiornati. Il vostro business cambia. I vostri prodotti cambiano. I vostri processi cambiano. Quel modello che avete perfezionato a gennaio sta ora dando risposte basate su informazioni obsolete.
Ma l'aggiornamento significa:
La maggior parte delle aziende perfezionano una volta e poi semplicemente vivono con la deriva. Il modello diventa lentamente meno rilevante, mentre tutti fingono che stia ancora aggiungendo valore.
Non fraintendermi, ci sono casi d'uso legittimi:
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
I green box sono i prerequisiti che la maggior parte dei progetti salta. "Abbiamo già ottimizzato suggerimenti e RAG" è il bar per la messa a punto. "Heavy ingestion ininvestment" Salta questi e stai costruendo sulla sabbia.
Mentre tutti stanno costruendo la stessa pipeline RAG, i problemi realmente interessanti nell'IA commerciale vengono ignorati:
Il più grande vincolo sull'efficacia dell'intelligenza artificiale non è il modello. Sono i dati. La maggior parte delle organizzazioni hanno:
Ma "l'iniziativa per la qualità dei dati" non ti procura un articolo di Forbes come "la trasformazione dell'AI."
Far cadere un chatbot AI in un processo esistente non lo rende magicamente migliore. Il processo deve essere ridisegnato intorno alle capacità e ai limiti dell'AI. La maggior parte delle aziende semplicemente bullonare l'IA su processi rotti e chiedersi perché non aiuta.
Le migliori implementazioni AI aumentano le capacità umane piuttosto che cercare di sostituirle. Ma questo è più difficile da vendere che "AI che fa X automaticamente!"
Humans + AI che lavorano insieme richiede:
La maggior parte dei progetti commerciali di IA trattano l'umano come un ripensamento.
Le applicazioni AI davvero preziose non sono "chatbot sui vostri documenti." Sono applicazioni che:
Ma quelli sono duri. RAG tubi sono facili (beh, più facile). Così è quello che tutti costruiscono.
Un importante motore di progetti IA stupidi è l'ecosistema di consulenza:
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
Ho visto questo schema dozzine di volte, la consulenza viene pagata, i dirigenti dicono di aver fatto l'intelligenza artificiale, gli ingegneri restano bloccati a mantenere qualcosa che a malapena funziona, e il vero problema degli affari rimane irrisolto.
Le startup cadono in una trappola leggermente diversa. Non sono le consulenze che guidano la disfunzione è l'ambiente di finanziamento.
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"
Suono familiare? Ogni pochi anni, c'è una nuova tecnologia che i VCs decidono è essenziale. Se il vostro mazzo di passo non lo menziona prominentemente, non state ottenendo finanziati. La tecnologia potrebbe essere irrilevante per il vostro prodotto reale non importa. Avete bisogno della parola d'ordine.
Ho visto questo accadere con blockchain nel 2017-2018. Le aziende che non avevano alcun affare essere su una blockchain erano gettoni calzaturiera nei loro prodotti perché questo è ciò che ha ottenuto finanziamenti. La maggior parte di quelle caratteristiche blockchain tranquillamente scomparso una volta che il denaro è stato assicurato.
Ora sta succedendo con l'IA.
Le startup sono funzioni di bullonatura LLM su prodotti che non ne hanno bisogno perché:
Il risultato? Prodotti con caratteristiche di AI imbarazzante che gli utenti ignorano. pista bruciata su esperimenti di messa a punto che non vanno da nessuna parte. Tempo di ingegneria sprecato sui sistemi RAG quando una semplice query database avrebbe funzionato meglio.
La parte peggiore: molti fondatori sanno che questo è sciocco. Stanno costruendo AI caratteristiche che non credono in perché hanno bisogno di sopravvivere abbastanza a lungo per costruire ciò che realmente si preoccupano. Alcuni hanno successo in questo gioco. La maggior parte non.
Se sei un fondatore di startup spinto ad aggiungere AI, chiedetevi:
Se è quest'ultimo, costruire la funzione IA minimo vitale che seleziona la casella, quindi concentrarsi su ciò che effettivamente conta. Non lasciare che l'ambiente di finanziamento distrae dalla costruzione di qualcosa di valore.
Qui è la verità scomoda nessuno nell'intelligenza artificiale vuole discutere: quasi tutti nell'ecosistema ha un incentivo finanziario per mantenere l'hype andare.
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
I ricercatori I laboratori di frontiera hanno bisogno di miliardi in elaborazione per formare la prossima generazione di modelli. Quel denaro viene da investitori e grandi tecnologie. Per giustificare questa spesa, hanno bisogno di dimostrare il progresso e "progresso" viene tradotto in annunci senza fiato su capacità che possono o non possono concretizzarsi in applicazioni pratiche. Se l'hype muore, il finanziamento si secca.
Le società La valutazione di OpenAI dipende dalla convinzione che l'AGI sia dietro l'angolo. Ogni startup "AI-powered" dipende dal fatto che l'IA rimanga il settore caldo. Il momento in cui il sentimento cambia, miliardi di paper wealth evapora.
Gli investitori Hanno distribuito quantità sbalorditive di capitale in AI. Hanno bisogno di uscite. Hanno bisogno della musica per continuare a suonare abbastanza a lungo per realizzare i rendimenti. Una valutazione realistica delle capacità AI a breve termine sarebbe valutazioni cratere in tutto il settore.
I media ha scoperto che le storie AI generano un coinvolgimento massiccio. La copertura sfumata non ottiene i click. "AI prenderà il vostro lavoro" e "AI svolta risolve X" fanno. L'accesso alle aziende AI dipende spesso dal mantenimento di relazioni positive che significa copertura critica è limitante carriera.
Il risultato? Un ciclo hype auto-rinforzante in cui ognuno ha ragioni per continuare a gonfiare le aspettative, e pochissime persone beneficiano di dire la verità.
Questo non significa che AI non è veramente utile è assolutamente, come ho discusso in tutto questo articolo. Ma il divario tra ciò che è stato promesso e ciò che viene consegnato è vasto, e gli incentivi sono tutti allineati per mantenere quel divario nascosto.
Quando qualcuno ti dice AI rivoluzionerà il tuo business, chiedi a te stesso: che cosa guadagna da voi credendo che?
Se stai considerando un progetto di IA, ecco il mio onesto consiglio:
Non chiedete "come possiamo usare AI?" Chiedete "che problema stiamo cercando di risolvere?" Se AI è la soluzione giusta, grande. Ma spesso non lo è.
Prima di costruire una pipeline RAG, correggere il problema del documento. Prima di perfezionare, pulire i dati di allenamento. L'AI non risolverà i problemi dei dati; li amplierà.
Non lanciare una massiccia "trasformazione AI." Costruisci una piccola prova di concetto. Provalo con utenti reali. Scopri cosa funziona realmente. Poi espandi.
L'ingestione di documenti non è sexy. La pulizia dei dati non è emozionante. Il quadro di valutazione non è qualcosa che si può demo al consiglio. Ma questi sono ciò che determinano il successo o il fallimento.
AI non è magia. LLM attuali allucinazioni. sistemi RAG perdere documenti rilevanti. modelli di fine-tuned deriva. Impostare aspettative realistiche.
Costruire il sistema è forse il 30% dello sforzo. Mantenerlo, migliorarlo e mantenerlo rilevante è l'altro 70%. Bilancio di conseguenza.
Forse quello di cui hai bisogno è solo un uso migliore degli strumenti off-the-shelf. ChatGPT con alcune istruzioni personalizzate potrebbe essere sufficiente. Non tutto ha bisogno di una piattaforma AI su misura.
Giusto, ho speso un paio di parole sbattendo fuori i progetti commerciali di IA. Ora per la punta speranzosa: questi progetti possono effettivamente funzionare, se li si avvicinano in modo ragionevole.
Il problema non è RAG o fine-tuning come concetti. Il problema è l'implementazione pigro, aspettative irrealistiche, e ignorando i fondamentali. Ecco come farlo meglio.
L'errore più grande che vedo è trattare AI come una sostituzione per i processi esistenti piuttosto che un miglioramento. Il vostro business ha già flussi di lavoro che funzionano (per lo più). Invece di strapparli fuori e sostituirli con una versione "AI-powered," gancio AI nelle lacune.
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
Notate cosa c'è di diverso:
Questo è molto più robusto di "l'AI gestisce tutto e a volte un controllo umano."
Ecco un segreto sporco: probabilmente non hai bisogno di GPT-4 o Claude per la maggior parte delle attività. E sicuramente non hai bisogno di inviare i tuoi documenti riservati ai server di OpenAI.
Il problema dei costi
In scala, i costi API sommano velocemente. Un sistema RAG occupato potrebbe fare migliaia di chiamate LLM al giorno. A $0.01-0.03 per gettoni 1K, che è denaro reale. E come si scala, diventa peggio.
Il problema della riservatezza
Molte organizzazioni non possono (o non dovrebbero) inviare i propri documenti ad API esterne:
La soluzione: modelli locali
Moderni modelli open-source sono maledettamente buono. Eseguire localmente significa:
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
Per Incorporazione (il bit di ricerca vettoriale RAG):
Per generazione (le risposte "AI" effettive):
Per attività di codifica:
Eseguire questi localmente non è così difficile come si potrebbe pensare. Strumenti come OllamaCity name (optional, probably does not need a translation), llama.cpp, vLLM, oppure testo-generazione-inferenza rendono semplice. Ho costruito una serie di applicazioni (vedi la parte inferiore dell'articolo) che dimostra questo in esecuzione su hardware di consumo.
Non c'è bisogno di andare tutto-o-niente. Un'architettura sensibile utilizza:
Modelli locali per attività ad alto volume e a bassa complessità
API cloud per un ragionamento complesso quando necessario
Questo approccio ibrido ti dà i vantaggi di costo di inferenza locale con la capacità dei modelli cloud quando ne hai davvero bisogno.
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
Ogni passo nell'approccio incrementale fornisce valore misurabile. Ogni passo ti insegna qualcosa. Se qualcosa fallisce, hai perso settimane, non mesi.
Ricordi quella scatola rossa nel diagramma? Ecco come risolverla:
Investire nella qualità rispetto alla quantità. E 'meglio avere 1.000 documenti perfettamente elaborati rispetto a 100.000 quelli mal elaborati. Iniziare con i documenti più importanti e farli bene.
Usare l'intelligenza artificiale per aiutare con l'ingestione. Moderni modelli di linguaggio della visione (GPT-4V, Claude, LLaVA localmente) possono effettivamente leggere documenti complessi - tabelle, grafici, note scritte a mano - in modi che il tradizionale OCR non può. Usarli per i documenti duri.
Costruire loop di feedback. Quando il recupero fallisce, registralo. Quando gli utenti dicono "non è quello che dice il documento," catturalo. Usa questo feedback per migliorare la tua pipeline di ingestione.
Accetta che alcuni documenti non funzionino. Non ogni antico PDF scansionato vale la pena combattere con. A volte la risposta è "ci occuperemo di quel tipo manualmente" piuttosto che spendere mesi sui casi bordo.
Una soluzione AI funzionante necessita di:
| Componente | Che cosa fanno la maggior parte dei progetti | Che cosa funziona realmente |
|---|---|---|
| Ingestione di dati | Afterthought | Focus primario |
| Qualità dei dati | "AI lo capirà" | Conduttura di pulizia dedicata |
| Retrieval | Basic vector search | Hybrid search + reranking |
| Generazione | Uscita LLM grezzo | Uscita strutturata con convalida |
| Recensione umana | Optional | Integrated in workflow |
| Feedback | Nessuno | Ciclo di miglioramento continuo |
| Monitoring | "It's working" | Detailed metriches & alerting |
| Manutenzione | "Versione 1 per sempre" | Aggiornamenti regolari e riqualificazione |
Il modello AI è forse il 20% di un sistema di lavoro. L'altro 80% è la roba noiosa che realmente lo fa funzionare nella produzione.
Non puoi migliorare cio' che non puoi misurare.
Questi dati ti dicono dove investire sforzo. Forse il tuo recupero è grande, ma la generazione è allucinazioni. Forse alcuni tipi di documenti falliscono sempre. Non è possibile risolvere ciò che non si può vedere.
Qui è il cambiamento più importante che sta accadendo in questo momento: l'era del "getto tutto a GPT-4 e la speranza per il meglio" sta terminando.
L'approccio 2023-2024 era semplice: ottenere il modello più grande che si può permettersi, riempire la finestra del contesto pieno di tutto, e pregare. Ha funzionato ... una sorta di. Per demo. Per prototipi. Per ottenere investimenti.
Ma non e' scalabile, e' costoso, e' lento, e sempre piu' e' sovraperformato da architetture piu' intelligenti.
Il futuro non e' un modello gigante che fa tutto. modelli specializzati multipli che lavorano insiemeOgnuno fa cio' in cui e' bravo.
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
Questo è quello che ho esplorato nel mio DiSE (Directed Synthetic Evolution) lavorare l'idea che: struttura batte brillantezza. Un condotto accuratamente orchestrato di modelli più piccoli e focalizzati supera un unico modello massiccio cercando di fare tutto.
Lo stesso pensiero vale per il Motore sintetico di decisione concetto: utilizzando più backend LLM in sequenza, dove ogni modello porta diversi punti di forza. Modelli veloci per triage, modelli accurati per validazione, modelli creativi per generazione. Ognuno fa quello che fa meglio.
Se non l'hai già fatto, dai un'occhiata alla mia Serie RAG che va a fondo sui fondamenti. Ma ecco l'intuizione chiave: RAG è una forma di questo approccio orchestrato. Stai usando embeddings (un modello) per trovare contenuti rilevanti, quindi utilizzando un LLM (un altro modello) per sintetizzare una risposta.
La prossima evoluzione sta portando avanti questo processo:
Ogni modello è più piccolo, più veloce e più economico rispetto all'utilizzo di GPT-4 per tutto. Ma insieme superano l'approccio monolitico.
Il termine "agente" è preso in prestito dalla psicologia del campo originale prima che io cadessi nel software. In psicologia, l'agenzia si riferisce alla capacità di agire indipendentemente, di fare scelte ed eseguirle nel mondo. Una persona agente non risponde solo agli stimoli; avviano l'azione, perseguono gli obiettivi, e adattano il loro comportamento in base ai risultati.
IA agentica applica questo concetto ai modelli linguistici. Invece del modello tradizionale si fa una domanda, il modello genera il sistema agente testuale può effettivamente fare le cose. Può utilizzare strumenti, eseguire codice, database di query, chiamare API, scrivere file e orchestrare flussi di lavoro multi-step. E 'la differenza tra chiedere indicazioni a qualcuno e assumere qualcuno per guidarvi lì.
Questo è ciò che gli ultimi modelli di Anthropic (tra cui Claude Opus 4.5 che sto letteralmente usando per scrivere questo via Claude Code) dimostrano così efficacemente.
Ecco la cosa che rende la folla di fine-tuning scomodo: se descrivete gli strumenti abbastanza bene, non avete bisogno di fine-tuning costosi per usarli. Moderni modelli di fondazione sono notevolmente bravi nell'uso degli strumenti fuori dalla scatola... hai solo bisogno di schemi di funzione chiari e buona documentazione nel contesto.
Questo è un enorme cambiamento dall'approccio Toolformer (finire un modello per imparare quando utilizzare gli strumenti misurando i risultati). Questo è costoso, richiede dati di formazione specializzati, e si blocca in un set specifico di strumenti. L'alternativa? Descrivi chiaramente i tuoi strumenti, dare il modello buon contesto, e lasciare che capire quando usarli.
I risultati sono spesso migliori perché:
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
Questo modello agente è fondamentalmente diverso dai chatbot RAG. Ed è dove si trova il valore reale.
Framework come LangChain, LlamaIndix e Kernel Semantico lo rendono possibile oggi. È possibile costruire sistemi in cui:
Le aziende che lo capiranno costruiranno sistemi AI che funzionano davvero. Quelli che ancora cercano di perfezionare la loro strada per il successo o la costruzione di un altro chatbot RAG continueranno a rimanere delusi.
Ho scritto molto su questi schemi:
| Topic | Article | What you'll learn |
|---|---|---|
| Architettura | DiSE vs Voyager | Perché l'orchestrazione strutturata batte i modelli monolitici |
| Multi-modello | Motori a decisione sintetica | Tubi per l'edilizia di modelli specializzati |
| RAG Fondamenti | Serie RAG | Dalle inserzioni ai sistemi di produzione |
| Inserzioni locali | Ricerca semantica con ONNX | CPU-friendly local vector search |
| LLM locali | DiSE | A selkf evolvign workflow system using local models linked together |
| Simulazione API | LLMApiCity name (optional, probably does not need a translation) | Utilizzando LLM locali per simulare le API per il test |
| RAG pratici | Costruire un avvocato GPT | Complete RAG implementation walkthrough |
La tecnologia esiste. I modelli stanno emergendo. La domanda è se la vostra organizzazione costruirà qualcosa di sensibile o un altro progetto di IA stupido.
L'attuale panorama commerciale AI mi ricorda la prima era web. Tutti avevano bisogno di una "strategia web." Le aziende costruirono siti web perché dovevano, non perché sapessero cosa farne. La maggior parte di questi siti erano inutili.
Alla fine, le aziende che sono riuscite sono state quelle che hanno capito a cosa il web era effettivamente buono e costruito per questo. Lo stesso accadrà con l'IA.
In questo momento, siamo nella fase "costruiscila perché dobbiamo," la maggior parte dei progetti sono stupidi, la maggior parte fallirà o mancherà. E' normale per le nuove tecnologie.
Ma se si vuole essere uno di quelli che riesce, smettere di seguire il modello. Iniziare con problemi reali. Investire nelle parti noiose. E per l'amore di Dio, riparare il vostro documento pipeline ingestione prima di incolpare la LLM.
L'IA non è il problema. I tuoi dati lo sono. I tuoi processi lo sono. Le tue aspettative irrealistiche lo sono.
Sistemali prima, e forse, solo forse, il tuo progetto di IA non sara' stupido.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.