Domain-Driven AI: sappiamo più di quanto sappiamo dire

Ciò che l'esperto sa ma non dice non arriverà mai al tuo RAG. Ontologie, knowledge graph e CTA: come catturarlo prima che sia tardi.

Domain-Driven AI: sappiamo più di quanto sappiamo dire

Un tecnico esperto entra nella sala macchine, ascolta il rumore del motore per tre secondi e dice: "Questo cuscinetto a rulli non durerà ancora una settimana." Non sa spiegare come lo sa. Lo sa e basta. Questa è la conoscenza che un sistema AI verticale deve riuscire a usare — e che quasi nessun progetto si preoccupa davvero di catturare.

Sappiamo più di quanto sappiamo dire

Nel 1966, il chimico e filosofo Michael Polanyi (1891-1976) pubblicò The Tacit Dimension, un saggio breve e denso in cui propose una distinzione destinata a diventare fondamentale per chi lavora con la conoscenza: quella tra conoscenza tacita e conoscenza esplicita.

La conoscenza esplicita è quella che puoi scrivere, trasmettere, archiviare: un manuale, una procedura, una normativa. La conoscenza tacita, invece, è incorporata nelle persone — è il saper fare, il riconoscimento di pattern, l'intuizione maturata nel tempo.

"Sappiamo più di quanto sappiamo dire" è la sua frase più citata, e descrive esattamente il problema: buona parte di ciò che un esperto sa non è mai stata scritta da nessuna parte.

Iceberg della conoscenza

Il nostro tecnico è l'esempio perfetto. In vent'anni di sala macchine ha sviluppato una mappa sensoriale che non esiste in nessun documento aziendale: sa distinguere il rumore di un cuscinetto a rulli usurato da quello di un disallineamento all'albero, sa quando una vibrazione è normale e quando è il segnale di qualcosa che sta per cedere. Questa mappa non si è formata leggendo manuali — si è formata attraverso migliaia di ore di esposizione diretta, errori, correzioni, pattern che il cervello ha imparato a riconoscere.

Conoscenza tacita nei LLM

Un paper del 2025 pubblicato su The Review of Austrian Economics"Tacit Knowledge in Large Language Models" — ha chiarito dove si colloca esattamente questo problema quando parliamo di AI.

Gli LLM possiedono alcune forme di conoscenza tacita: riconoscono pattern impliciti nel linguaggio, colgono sfumature e sottotesti mai esplicitati. Ma mancano della terza forma identificata da Polanyi, quella incarnata (embodied): la conoscenza sensoriale e corporea che si acquisisce solo attraverso l'esperienza diretta. Ciò che il tecnico sa non può essere trasferito al modello per via testuale, perché non è mai stato testo.

Per un sistema AI che deve operare in un settore verticale, questa distinzione è cruciale. I documenti — manuali, normative, report — rappresentano solo la superficie della conoscenza di un dominio. Sotto c'è uno strato molto più ricco, fatto di giudizi, eccezioni, euristiche, convenzioni non scritte. Ignorarlo significa costruire un sistema che sa leggere i libri, ma non sa fare il mestiere.

Il linguaggio come confine del pensiero

C'è un secondo livello del problema che riguarda le parole stesse. Quando il tecnico dice "cuscinetto a rulli" non sta usando un'espressione generica — sta nominando con precisione un componente specifico, con un regime di usura specifico, con procedure di sostituzione specifiche, con una firma sonora che lui riconosce e che distingue da tutti gli altri cuscinetti che compongono quella macchina.

La parola non è intercambiabile. È un nodo in una rete di significati che esiste solo dentro quel dominio.

Giochi linguistici

Il filosofo Ludwig Wittgenstein (1889-1951), nelle Ricerche Filosofiche (1953), osservò che il significato delle parole non è fisso — dipende dal contesto d'uso, da quello che chiamò il gioco linguistico. La stessa parola, in contesti diversi, non descrive la stessa cosa. E il suo aforisma più noto, tratto dal Tractatus, è il complemento filosofico dell'intera questione: "I limiti del mio linguaggio sono i limiti del mio mondo."

Ludwig Wittgenstein osservando un cuscinetto a rulli (gpt-image-2)

Un modello generico non abita il gioco linguistico della manutenzione industriale. Per il tecnico, anomalia e guasto non sono sinonimi — sono due stati completamente diversi con conseguenze operative opposte. Un'anomalia è un segnale: qualcosa si sta deteriorando, c'è ancora tempo, si pianifica un intervento preventivo. Un guasto è un evento: il componente ha già ceduto, il fermo è immediato, i costi esplodono. Confondere i due termini in un sistema AI di manutenzione non produce una risposta leggermente imprecisa — produce il piano di intervento sbagliato.

Costruire un'ontologia per quella distinzione significa definire il perimetro logico dentro cui le parole hanno significato stabile. Senza quel perimetro, il modello opera in modo probabilistico — genera testo che assomiglia a una risposta corretta, senza garantire che lo sia semanticamente.

Cosa sa il tecnico che il manuale non dice

Supponiamo di voler costruire un sistema AI che sappia fare, almeno in parte, quello che fa il nostro tecnico.

Il primo istinto di quasi ogni progetto è raccogliere i documenti: i manuali di manutenzione, i report di guasto, le procedure operative. È necessario, ma non sufficiente. Quei documenti descrivono la conoscenza esplicita del dominio — lo strato superficiale. La mappa sensoriale del tecnico non è lì.

Esiste un campo di ricerca dedicato a questo problema — la Knowledge Elicitation — che studia metodi per rendere articolabile ciò che un esperto fa senza saperlo spiegare. Il metodo più consolidato è la Cognitive Task Analysis (CTA), un processo strutturato in tre fasi: elicitazione, analisi e rappresentazione. In pratica, significa affiancare il tecnico nel suo lavoro reale — non chiedergli di descriverlo a posteriori — e usare tecniche di intervista strutturata, osservazione etnografica e sessioni collaborative per far emergere euristiche, criteri decisionali e casi limite che non compaiono in nessun manuale.

La figura che coordina questo processo è il Knowledge Engineer: un profilo ibrido, a metà tra il consulente di dominio e l'architetto di sistemi, che sa fare le domande giuste al tecnico e tradurre le risposte in strutture formali computabili. Non è un ruolo nuovo — esiste dagli anni dei sistemi esperti degli anni Ottanta — ma nell'era degli LLM è tornato centrale, perché il modello da solo non sa cosa non sa.

Knowledge Engineer trasforma l’esperienza del tecnico in sapere condiviso (gpt-image-2)

Un aspetto spesso sottovalutato: l'AI generativa sta cambiando anche il processo di elicitazione stesso.

Un paper del 2025 pubblicato su SAGE Journals"Making tacit knowledge explicit: Generative AI's role in enhancing apprenticeship systems" — documenta come i modelli generativi possano analizzare trascrizioni di conversazioni con esperti, estrarre pattern da log operativi e sessioni di lavoro, e portare alla superficie euristiche che il tecnico stesso non aveva mai formalizzato. Il processo diventa bidirezionale: il tecnico aiuta l'AI a capire il dominio, e l'AI aiuta il tecnico a capire cosa sa.

C'è però un limite strutturale che nessun metodo elimina del tutto. Il paper MDPI "Unveiling the Unspoken" (2025) lo identifica con precisione: la conoscenza tacita è incarnata, situata e contestuale — è legata alla percezione, all'emozione, al contesto fisico in cui si opera. La firma sonora di quel cuscinetto a rulli non è elicitabile completamente né con interviste né con AI.

Il knowledge modeling non risolve il problema della tacitness: lo riduce sistematicamente, cattura un'approssimazione sempre più fedele, ma non il tutto. Riconoscerlo non è una resa — è onestà ingegneristica.

Costruire l'architettura della conoscenza

Ciò che l'elicitazione ha estratto — le euristiche, le distinzioni, i casi limite, le relazioni tra componenti e comportamenti — deve diventare conoscenza esplicita e computabile. Il Knowledge Modeling è questo processo. Non si tratta di caricare documenti in un database vettoriale. Si tratta di costruire un'architettura su tre livelli.

Ontologie e Vocabolari Controllati

La distinzione tra "cuscinetto a rulli" e "cuscinetto radiale" non è stilistica — è la differenza tra una diagnosi corretta e una sbagliata. Definire rigorosamente il significato dei termini del dominio significa costruire una struttura formale che specifica relazioni di equivalenza, gerarchia, esclusione. Quella distinzione diventa una relazione esplicita nell'ontologia, non un'inferenza affidata al modello.

La ricerca empirica conferma il valore di questo approccio: uno studio del 2025 pubblicato su Arxiv (Ontology Learning and Knowledge Graph Construction, 2511.05991) ha dimostrato che i sistemi di retrieval guidati da ontologie superano sostanzialmente il retrieval vettoriale puro, con un ulteriore vantaggio pratico: le ontologie estratte da database relazionali — tipici in contesti enterprise — sono comparabili in qualità a quelle derivate da testo, ma significativamente più economiche da mantenere.

Knowledge Graphs

Il cuscinetto a rulli che il tecnico ha diagnosticato non esiste in isolamento: è collegato al motore che lo ospita, ai parametri di vibrazione che ne segnalano l'usura, alle procedure di sostituzione, ai ricambi compatibili, alle normative di sicurezza applicabili durante l'intervento. Mappare queste relazioni in un knowledge graph è ciò che permette al sistema di ragionare, non solo di recuperare.

La tecnica nota come GraphRAG, sviluppata da Microsoft Research, integra strutture a grafo e LLM superando i limiti del semplice recupero vettoriale. I dati più recenti sono netti: i sistemi GraphRAG raggiungono accuratezze superiori al 90% rispetto al 60% dei sistemi basati solo su embedding.

Nel 2025 la tecnologia ha raggiunto maturità produttiva — e una variante ottimizzata, LazyGraphRAG, riduce i costi di indicizzazione fino al 90%, rendendo l'approccio accessibile anche fuori dai grandi budget enterprise.

Tassonomie e Metadati

Non tutti i documenti sono uguali: un manuale di installazione, un report di guasto e una normativa di sicurezza richiedono metadati diversi per garantire un retrieval granulare e contestuale. La tassonomia è la mappa che rende navigabile l'intero sistema.

Quando il tecnico va in pensione

Il nostro tecnico ha sessantadue anni. Tra pochi anni andrà in pensione. Con lui uscirà dalla porta tutta la mappa sensoriale che ha costruito in vent'anni — le euristiche, le distinzioni, i pattern sonori, i casi limite che non ha mai scritto da nessuna parte, perché non ne ha mai avuto bisogno. Questo è il momento in cui la questione smette di essere filosofica e diventa urgente.

Il risultato finale del processo di knowledge modeling è una Ground Truth modulare: una rappresentazione verificabile e aggiornabile della conoscenza del dominio. Quando cambia una normativa, si aggiorna la knowledge base — non si riaddestra il modello. Quando emerge un'eccezione non documentata, si aggiunge un nodo al grafo — non si riscrive il prompt. Quando il tecnico va in pensione, la sua conoscenza non va con lui — è già nell'architettura.

Questo è il vantaggio strutturale di un approccio domain-driven rispetto a uno model-centric: la conoscenza è separata dal modello, manutenibile in modo indipendente, verificabile da chi conosce il dominio.

Non è solo una questione tecnica. Al World Economic Forum di Davos nel gennaio 2026, il CEO di Microsoft Satya Nadella ha introdotto il concetto di "firm sovereignty": la capacità di un'azienda di incorporare la propria conoscenza tacita in modelli che controlla.

La sua tesi è che questo fattore conti più della localizzazione geografica dei dati. Un'azienda che ha investito nella propria Ground Truth — che ha esplicitato le proprie ontologie, mappato i propri knowledge graph, codificato le proprie euristiche — possiede qualcosa che non può essere replicato scaricando un modello generico.

Il tecnico sa più di quanto sa dire. Il lavoro è fare in modo che quella conoscenza sopravviva a lui.

📚Bibliografia

[0] Ludwig Wittgenstein, Tractatus Logico-Philosophicus, Feltrinelli, Ed. Italiana, 2022

[1] Ludwig Wittgenstein, Ricerche Filosofiche, Feltrinelli, Feltritinelli, Ed. Italiana, 2024

[2] Michael Polanyi, The Tacit Dimension, University of Chicago Press, Ed. Inglese, 2009

🔗Sitografia

2024

[0] Enterprise Knowledge, The Role of Ontologies with LLMs, Enterprise Knowledge Blog, 09/01/2024

[1] Enterprise Knowledge, How to Inject Organizational Knowledge in AI, Enterprise Knowledge Blog , 31/10/2024

2025

[0] Lumina, Knowledge Engineering: Building Intelligent Systems That Think, Medium, 01/10/2025

2026

[0] Anirban Ghoshal, Nadella redefines ‘sovereignty’ for the AI era — analysts call it smart, self‑serving, Computerworld, 22/01/2026

🔎Papers

2021

[0] Arrieta, A. et al., A Survey of Domain Knowledge Elicitation in Applied Machine Learning, MDPI Multimodal Technologies and Interaction, 16/10/2021

2022

[0] Seidel, S. et al., Tacit knowledge elicitation process for Industry 4.0, Discover Artificial Intelligence, Springer, 10/03/2022

2025

[0] Koch, J. et al., Identifying, Capturing, and Reusing Tacit Knowledge in Creative Domains with Generative AI, ACM UIST, 27/09/2025

[1] Kommineni, V. K. et al., Ontology Learning and Knowledge Graph Construction: A Comparison of Approaches and Their Impact on RAG Performance, Arxiv 2511.05991, 08/11/2025

[2] Edge, C., Tacit Knowledge in Large Language Models, The Review of Austrian Economics, 10/11/2025

[3] Peng, B. et al., Graph Retrieval-Augmented Generation: A Survey, ACM Transactions on Information Systems, 23/12/2025

[4] Nasser Khalili, Mohammad Jahanbakht , Unveiling the Unspoken: A Conceptual Framework for AI-Enabled Tacit Knowledge Co-Evolution, MDPI AI, 23/12/2025

[5] Guo, G., Hu, J., Making tacit knowledge explicit: Generative AI's role in enhancing apprenticeship systems, SAGE Journals, 29/12/2025

2026

[0] Andrenacci, G. et al., How to Build AI Agents by Augmenting LLMs with Codified Human Expert Domain Knowledge, Arxiv 2601.15153, 01/01/2026

[1] Caufield, J. H. et al., LLM-Driven Ontology Construction for Enterprise Knowledge Graphs, Arxiv 2602.01276, 01/02/2026