# Perché la maggior parte dei progetti 'AI' commerciali sono stupidi > "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 ## Introduzione 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. [TOC] ## I due tipi di progetti commerciali AI Strappare le palle di marketing e troverete che circa il 95% dei progetti commerciali "AI" rientrano in una delle due categorie: ### Tipo 1: Il gasdotto RAG Questo è di gran lunga il più comune. Ogni "soluzione AI aziendale" segue questo schema: ```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 ``` 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. ### Tipo 2: Il modello finemente tracciato 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. ```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] ``` 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. ## Perché l'ingestione del documento è dove i sogni vanno a morire 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: - Bellissimi PDF che fluiscono nel sistema - Pulisci il conto alla rovescia estratto alla perfezione - Tutta la tua conoscenza, ricercabile da AI! Ecco cosa succede veramente: ### Il problema PDF 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: - Colonne che si fondono in modo errato - Tabelle che diventano bizzarre - Intestazioni e piè di pagina che inquinano il contenuto - Documenti scansionati che necessitano di OCR (e OCR ha i propri tassi di errore) - Documenti protetti dalla sicurezza che non possono essere elaborati per niente - Problemi di codifica dei caratteri che trasformano il testo in spazzatura E questi sono solo PDF. Aspetta di premere: - File di PowerPoint con testo in SmartArt - Documenti Word con modifiche alla traccia - Excel file con celle unite - Immagini scansionate con calligrafia - Formati legacy da sistemi morti negli anni '90 ### La Catastrofe Chunking 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. ```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] ``` ### Il mess dei metadati I buoni RAG hanno bisogno di buoni metadati. Ma estrarre i metadati dai documenti è difficile: - Qual è la data del documento? È la data di creazione, la data di modifica, o la data indicata nel contenuto? - Chi è l'autore? La persona che ha creato il file, l'autore legale, o l'esperto di materia? - A che categoria appartiene? La vostra tassonomia probabilmente non corrisponde a come i documenti sono stati effettivamente organizzati. - Questo documento è ancora valido? O è stato sostituito da qualcosa di più nuovo di cui il sistema non è a conoscenza? 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. ## La fantasia di fine-tuning 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. ### Il problema dei dati La messa a punto richiede dati di formazione di qualità. La maggior parte delle aziende non ce l'hanno. Hanno: - Dati rumorosi e incoerenti sparsi tra sistemi - Dati che riflettono come le cose sono state fatte, non come dovrebbero essere fatte - Dati pieni di errori che nessuno si è mai preoccupato di correggere - Dati che sono proprietari ma in realtà non così preziosi "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? ### Il problema della valutazione Come fai a sapere se il tuo modello perfezionato è in realtà meglio? La maggior parte delle aziende non può rispondere a questo perché: - Non hanno un buon set di dati di riferimento - Non hanno metriche di valutazione chiare - Non hanno fatto rigorosi test A/B - Stanno confrontando le vibrazioni, non i dati. 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. ### Il problema della manutenzione 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: - Raccolta di nuovi dati di formazione - Corsa di nuovo l'allenamento - Convalida del nuovo modello - Sfruttarla - Sperando che tu non abbia introdotto le regressioni. 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. ## Che cosa i progetti "AI" sono realmente buoni per Non fraintendermi, ci sono casi d'uso legittimi: ```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 ``` 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. ## I veri problemi che nessuno sta risolvendo Mentre tutti stanno costruendo la stessa pipeline RAG, i problemi realmente interessanti nell'IA commerciale vengono ignorati: ### Qualità dei dati Il più grande vincolo sull'efficacia dell'intelligenza artificiale non è il modello. Sono i dati. La maggior parte delle organizzazioni hanno: - Dati diffusi in dozzine di sistemi che non si parlano - Nessuna fonte di verità per nulla - Governance dei dati che è più aspirazione della realtà - Problemi di qualità che nessuno ha da risolvere **Ma "l'iniziativa per la qualità dei dati" non ti procura un articolo di Forbes come "la trasformazione dell'AI."** ### Integrazione dei processi 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. ### Collaborazione uomo-AI 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: - Pulisci i punti di consegna - Ragione IA trasparente - Meccanismi di override facili - Loop di feedback per il miglioramento La maggior parte dei progetti commerciali di IA trattano l'umano come un ripensamento. ### Innovazione autentica Le applicazioni AI davvero preziose non sono "chatbot sui vostri documenti." Sono applicazioni che: - Abilita cose che in precedenza erano impossibili - Crea nuove categorie di valore - Risolvere i problemi in modi fondamentalmente nuovi Ma quelli sono duri. RAG tubi sono facili (beh, più facile). Così è quello che tutti costruiscono. ## Il Complesso Industriale di Consulenza Un importante motore di progetti IA stupidi è l'ecosistema di consulenza: ```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 ``` 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. ## Il requisito VC-Driven AI Le startup cadono in una trappola leggermente diversa. Non sono le consulenze che guidano la disfunzione è l'ambiente di finanziamento. ```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" ``` 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é: - Gli investitori non guarderanno ai ponti senza "AI" menzionato - Le valutazioni sono 3-5 volte superiori per le "società AI" - La stampa racconta solo storie di AI - "AI-powered" è la posta in gioco per il marketing 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: - L'AI migliora davvero la proposta di valore del mio prodotto? - O sto solo selezionando una casella per gli investitori? 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. ## Il complesso industriale Hype Qui è la verità scomoda nessuno nell'intelligenza artificiale vuole discutere: **quasi tutti nell'ecosistema ha un incentivo finanziario per mantenere l'hype andare.** ```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 ``` **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? ## Cosa dovresti fare in realta'? Se stai considerando un progetto di IA, ecco il mio onesto consiglio: ### 1. Iniziare con il problema, non la tecnologia Non chiedete "come possiamo usare AI?" Chiedete "che problema stiamo cercando di risolvere?" Se AI è la soluzione giusta, grande. Ma spesso non lo è. ### 2. Fissare i vostri dati prima 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à. ### 3. Avviare Piccolo e Iterare Non lanciare una massiccia "trasformazione AI." Costruisci una piccola prova di concetto. Provalo con utenti reali. Scopri cosa funziona realmente. Poi espandi. ### 4. Investire nelle punte noiose 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. ### 5. Essere onesti sulle limitazioni AI non è magia. LLM attuali allucinazioni. sistemi RAG perdere documenti rilevanti. modelli di fine-tuned deriva. Impostare aspettative realistiche. ### 6. Piano di manutenzione Costruire il sistema è forse il 30% dello sforzo. Mantenerlo, migliorarlo e mantenerlo rilevante è l'altro 70%. Bilancio di conseguenza. ### 7. Considerate se avete bisogno di una soluzione personalizzata a tutti 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. ## Ma non devono essere stupidi. 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. ### Uncino AI in flussi di lavoro esistenti, non sostituirli 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. ```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 ``` Notate cosa c'è di diverso: - **Gli umani sono ancora nel ciclo** per le decisioni che contano - **IA gestisce i bit noiosi** - estrazione, sommarizzazione, classificazione - **Ogni fase dell'intelligenza artificiale è piccola e verificabile** - se l'IA sbaglia l'estrazione, l'uomo la cattura durante la revisione - **Esistono loop di feedback** - i risultati registrati allenano i futuri miglioramenti dell'intelligenza artificiale Questo è molto più robusto di "l'AI gestisce tutto e a volte un controllo umano." ### Utilizzare LLM locali per i costi e la riservatezza 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: - Documenti legali con informazioni sul cliente - Registri medici - Dati finanziari - Ricerca proprietaria - Qualsiasi cosa coperta dal GDPR, HIPAA, ecc. **La soluzione: modelli locali** Moderni modelli open-source sono maledettamente buono. Eseguire localmente significa: - **Costo marginale zero per ogni query** - hai pagato per l'hardware, l'inferenza è "gratuita" - **Completa privacy dei dati** - niente lascia la tua infrastruttura - **Nessun limite di velocità** - scalare quanto il vostro hardware permette - **Opzioni di personalizzazione** - fine-tune senza che i dati lascino il tuo controllo ```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 ``` #### Opzioni pratiche del modello locale Per **Incorporazione** (il bit di ricerca vettoriale RAG): - **frase-trasformatori** - Veloce, preciso, funziona con hardware modesto - **nomic-enbed** - Ottima qualità, piccola impronta - **Modelli BGE** - Competitiva con le opzioni commerciali Per **generazione** (le risposte "AI" effettive): - **Llama 3.1 8B/70B** - Eccellente scopo generale, grande istruzione seguente - **Mistral/Mixtral** - Veloce, efficiente, buon ragionamento - **Phi-3City name (optional, probably does not need a translation)** - Sorprendentemente in grado per le sue dimensioni - **Qwen 2.5** - Forte sostegno multilingue Per **attività di codifica**: - **CodiceLlama** - Specificamente addestrato per il codice - **Codificatore DeepSeek** - Eccellente comprensione del codice - **StarCoderCity name (optional, probably does not need a translation)** - Buono per molte lingue 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. #### L'approccio ibrido Non c'è bisogno di andare tutto-o-niente. Un'architettura sensibile utilizza: 1. **Modelli locali per attività ad alto volume e a bassa complessità** - Classificazione dei documenti - Estrazione di entità - Semplice Q&A - Sintesi 2. **API cloud per un ragionamento complesso quando necessario** - Analisi complessa a più fasi - Attività che richiedono le finestre di contesto più grandi - Ripiegare quando la fiducia dei modelli locali è bassa Questo approccio ibrido ti dà i vantaggi di costo di inferenza locale con la capacità dei modelli cloud quando ne hai davvero bisogno. ### Costruisci valore incrementale, non trasformazioni Big Bang ```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 ``` Ogni passo nell'approccio incrementale fornisce valore misurabile. Ogni passo ti insegna qualcosa. Se qualcosa fallisce, hai perso settimane, non mesi. ### Rendi l'ingestione del documento una preoccupazione di prima classe 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. ### Pensa al sistema completo, non solo l'AI Bit 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. ### Costruisci nell'osservabilità dal primo giorno Non puoi migliorare cio' che non puoi misurare. - **Qualità di recupero**: Stai trovando documenti pertinenti? Precisione e richiamo del recupero delle tracce. - **Qualità della generazione**: Le risposte sono accurate? Tracciare i tassi di allucinazione (sì, questo è difficile). - **Soddisfazione dell'utente**: Le persone lo trovano effettivamente utile? Tracciare l'uso, i tassi di completamento, pollici su / giù. - **Costo per interrogazione**: Che cosa stai effettivamente spendendo? Track token utilizzo, latenza, costi di infrastruttura. - **Modalità guasti**: Quando si rompe? Tracciare i tassi di errore per tipo di documento, tipo di query, ecc. 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. ### La fine di "Big LLM risolve tutto" 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 passaggio a piccoli modelli orchestrati Il futuro non e' un modello gigante che fa tutto. **modelli specializzati multipli che lavorano insieme**Ognuno fa cio' in cui e' bravo. ```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 ``` Questo è quello che ho esplorato nel mio [DiSE (Directed Synthetic Evolution)](/blog/disejustvoyager) 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](/blog/semantidintelligence) 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. #### Perché questo è importante per gli orientamenti Se non l'hai già fatto, dai un'occhiata alla mia [Serie RAG](/blog/rag-primer) 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: - **Modello di inserimento** → trova i documenti candidati - **Modello di riranking** → Ordini per rilevanza effettiva - **Modello di classificazione** → determina l'intento della query - **Modello di piccola generazione** → gestisce semplici query di fatto - **Modello di ragionamento di grandi dimensioni** → gestisce analisi complesse (solo quando necessario) Ogni modello è più piccolo, più veloce e più economico rispetto all'utilizzo di GPT-4 per tutto. Ma insieme superano l'approccio monolitico. #### Il futuro agentico 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](https://www.anthropic.com/news/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é: - **Le descrizioni degli strumenti possono essere aggiornate istantaneamente** - nessuna riqualificazione necessaria - **Nuovi strumenti possono essere aggiunti al runtime** - basta aggiungere un altro schema - **Il modello beneficia del suo ragionamento generale** - non solo schemi memorizzati - **È possibile utilizzare qualsiasi modello capace** - non specificamente perfezionata ```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 ``` 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: - Un piccolo modello veloce maniglie routing e classificazione - Modelli specializzati gestiscono attività specifiche per dominio - L'uso dello strumento estende le funzionalità oltre la lingua pura - I loop di feedback consentono un miglioramento continuo 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. #### Dove saperne di più Ho scritto molto su questi schemi: | Topic | Article | What you'll learn | |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | **Architettura** | [DiSE vs Voyager](/blog/disejustvoyager) | Perché l'orchestrazione strutturata batte i modelli monolitici | | **Multi-modello** | [Motori a decisione sintetica](/blog/semantidintelligence) | Tubi per l'edilizia di modelli specializzati | | **RAG Fondamenti** | [Serie RAG](/blog/rag-primer) | Dalle inserzioni ai sistemi di produzione | | **Inserzioni locali** | [Ricerca semantica con ONNX](/blog/semantic-search-with-onnx-and-qdrant) |CPU-friendly local vector search | | **LLM locali** | [DiSE](/blog/semanticintelligence-part10) | A selkf evolvign workflow system using local models linked together | | **Simulazione API** | [LLMApiCity name (optional, probably does not need a translation)](/blog/llmapi) | Utilizzando LLM locali per simulare le API per il test | | **RAG pratici** | [Costruire un avvocato GPT](/blog/building-a-lawyer-gpt-for-your-blog-part1) | 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. ## Conclusione 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.