Sapere che un LLM ha deciso non basta più. In contesti regolati, chi schiera modelli on-premise ha bisogno di capire esattamente quali segnali — e soprattutto quali combinazioni di segnali — hanno orientato una previsione. IMEX (Interaction-Based Model Explanation) nasce proprio qui: non si limita a stilare una classifica di feature rilevanti, ma mappa le interazioni che contano, anche oltre le coppie.

L’idea di fondo è che molti comportamenti predittivi sfuggano a spiegazioni puramente additive. Due variabili prese singolarmente possono apparire trascurabili, mentre la loro azione congiunta spiega il target molto meglio di quanto farebbe una semplice somma di contributi. IMEX cattura questa complessità attraverso due metriche: il Power Correlation Statico (PCS), che quantifica l’apporto di una feature considerata isolatamente, e il Power Correlation Interattivo (PCI), che misura la parte non additiva dell’effetto congiunto.

La validazione pubblicata dagli autori si concentra sul PCS, confrontandolo con il metodo INVASE su tre dataset sintetici a struttura nota. I risultati mostrano che IMEX recupera le strutture rilevanti anche in presenza di non linearità, dipendenze condizionate e multicollinearità. Niente benchmark su hardware specifici, nessuna metrica di throughput: è uno studio metodologico. Ma il punto è un altro, e per chi si occupa di deployment on-premise merita attenzione.

Perché le interazioni contano nel self-hosting

Quando un’organizzazione decide di mantenere i propri modelli in-house — per ragioni di sovranità dei dati, compliance o semplice TCO — il problema della spiegabilità diventa concreto nel momento in cui qualcosa va storto. Un fine-tuning su dati proprietari può innescare comportamenti inattesi, e senza strumenti come IMEX diventa difficile isolare se la colpa sia di una feature in particolare o di un incrocio mal digerito dal modello. In uno stack locale, la possibilità di profilare l’inference non è più un nice-to-have: è uno strumento di audit.

Chi lavora con LLM self-hosted sa che la quantization, ad esempio, può alterare la rappresentazione interna dei token e quindi modificare le interazioni tra feature latenti. Un framework di spiegabilità che non si fermi al singolo attributo, ma esplori anche il secondo e il terzo ordine, aiuta a validare che le compressioni applicate per far girare il modello su hardware più modesto non stiano distorcendo catene causali importanti.

Il cantiere aperto delle interazioni di ordine superiore

C’è un altro segnale. L’assenza di limiti sull’ordine delle interazioni analizzate da IMEX suggerisce che la comunità stia cercando metodi capaci di tenere il passo con la complessità crescente dei modelli. Non è un caso: più un sistema diventa capace di ragionamento compositivo, più le spiegazioni monodimensionali diventano fuorvianti. Sul piano pratico, per un team che gestisce l’inference on-premise, questo significa che l’investimento in tooling di explainability non può limitarsi a librerie che restituiscono una heatmap. Serve la capacità di interrogare il modello su combinazioni sospette, specialmente quando il deployment tocca dati sensibili e ogni decisione automatizzata deve essere giustificabile.

In definitiva, IMEX non risolve il problema della trasparenza dei modelli, ma indica una direzione precisa: la spiegabilità non può restare aggrappata a singole feature. Chi progetta pipeline di validazione per ambienti locali farà bene a tenerne conto, perché la vera partita si gioca sulle interazioni che restano invisibili fino a quando qualcuno non va a cercarle.