I modelli linguistici di grandi dimensioni sanno estrarre informazioni da un singolo documento con risultati sorprendenti. Quando però la domanda diventa trasversale – “quali sono i rischi comuni emersi in tutte le trascrizioni delle call con i nostri cento maggiori clienti?” – il meccanismo siinceppa. Overflow del contesto, perdita di attribuzione sulle singole entità e latenza lineare per via delle chiamate sequenziali agli strumenti trasformano l’analisi su scala aziendale in un esercizio frustrante.

BatchDAG, un sistema appena presentato, ribalta l’approccio. Invece di usare l’LLM per rispondere direttamente, gli chiede di scrivere la partitura: un grafo aciclico diretto tipato (DAG) che descrive un piano di esecuzione fatto di query SQL, ricerche semantiche, trasformazioni in-memory e ramificazioni parallele. Un motore deterministico esegue poi quel piano sfruttando un parallelismo a onda topologica e un flusso di dati JSON strutturati. Il punto chiave non è solo architetturale, ma sta in un’ottimizzazione chiamata “entity-aware batching”: raggruppare le righe per entità logica prima di diramare le chiamate all’LLM, così da ridurre il numero di invocazioni fino a 47 volte.

I numeri delle sperimentazioni su dodici query incentrate su trascrizioni danno una misura concreta. BatchDAG ottiene un punteggio di 3,74 su 5, un valore paragonabile a quello di una pipeline progettata a mano da esperti (3,25) e sensibilmente superiore rispetto a un agente ReAct (3,09). La differenza è statisticamente significativa (il p-value riportato nel paper è inferiore alla soglia di 0,05). Non stiamo parlando di un miglioramento incrementale nella capacità di comprensione del modello, ma di un salto nell’efficienza e nella generalizzabilità dell’intero sistema.

Cosa significa per chi guarda all’on-premise

La notizia interessa da vicino chi lavora su stack di AI auto-ospitati, in particolare in contesti dove i dati non possono lasciare il perimetro aziendale. Il risparmio di chiamate all’LLM è un moltiplicatore di capacità: con un taglio di quasi due ordini di grandezza è realistico pensare di usare modelli più piccoli, magari quantizzati a 4-bit, per guidare l’orchestrazione, riservando i modelli più pesanti solo quando servono, oppure evitando del tutto il ricorso a GPU di fascia altissima. In uno scenario on-premise tipico, dove la potenza di calcolo è limitata e il Total Cost of Ownership (TCO) va tenuto sotto controllo, BatchDAG promette di abbattere i costi di inference senza sacrificare la qualità dell’analisi.

C’è un altro aspetto strutturale. Il motore di esecuzione è deterministico e riproducibile: una volta generato il DAG, il comportamento non dipende più dalla temperatura del modello o da variazioni casuali. In ambiti regolati come la finanza o la sanità, dove la compliance e la verificabilità contano, la separazione tra piano (prodotto dall’LLM) ed esecuzione (affidata a un motore tradizionale) offre un livello di auditability che un agente completamente black-box non può garantire. I dati rimangono sotto controllo locale e il tracciato delle operazioni è trasparente.

Non meno rilevante è l’impatto organizzativo. Oggi costruire pipeline di analisi su dati aziendali eterogenei richiede data engineer che conoscono SQL, motori di ricerca semantica e logiche di enrichment. BatchDAG, come orchestration layer general-purpose, permette di esprimere domande in linguaggio naturale e ottenere una strategia di esecuzione ottimizzata. Non sostituisce le competenze ingegneristiche, ma riduce la necessità di riscrivere flussi di lavoro ogni volta che cambia la domanda. Su scala enterprise, questa flessibilità può tradursi in cicli di sviluppo più brevi e una democratizzazione dell’accesso ai dati, senza rinunciare alla governance.

Chi investe in infrastrutture AI on-premise dovrebbe osservare questo passaggio con attenzione: non si tratta dell’ennesimo case study su come un LLM risponde correttamente, ma di un segnale che il valore differenziante sta migrando dalla potenza del singolo modello alla capacità di orchestrare tool deterministici. È esattamente la direzione che rende l’AI auto-ospitata non solo possibile, ma pragmaticamente sostenibile.