La corsa ai gemelli digitali basati su LLM si è finora concentrata su una premessa apparentemente ovvia: più informazioni si forniscono al modello, più accurata sarà la simulazione di una persona. Un nuovo studio pubblicato sul tema ribalta questa convinzione. Il collo di bottiglia, sostengono i ricercatori, non è la quantità di dati ma la struttura con cui le informazioni personali vengono organizzate prima di essere passate al modello simulatore.

Lo studio confronta due approcci. Da un lato, i riassunti non strutturati prodotti da LLM a partire da trascrizioni di survey. Dall'altro, rappresentazioni strutturate della persona. In un benchmark omogeneo, chiamato Twin-2K-500, uno schema costruito a mano — BDE, ovvero Background, Decision procedure, Evaluation — migliora l'accuratezza predittiva di +1,91 punti percentuali rispetto alle trascrizioni grezze. Il guadagno si conferma con gpt-5.4-mini e con Qwen3-8B, due modelli molto diversi per architettura e modalità di accesso.

Ma c'è un limite. Lo schema fisso BDE non regge quando i compiti diventano eterogenei: in quel caso le prestazioni tornano statisticamente indistinguibili dalla baseline. Per superare questo problema, i ricercatori propongono una pipeline automatica di scoperta della struttura: un LLM propone e affina in modo iterativo schemi e prompt di estrazione specifici per ogni compito. Su un benchmark di 13 sotto-studi diversi, questo approccio ripristina il vantaggio, con un miglioramento medio di +1,91 punti percentuali rispetto alla baseline e l'eliminazione delle perdite significative osservate con lo schema fisso.

Il messaggio è chiaro: per i gemelli digitali, il vincolo principale non è quanto si fornisce, ma come lo si organizza. E la struttura ottimale dipende dal compito.

Questa conclusione ha implicazioni dirette per chi progetta pipeline di inference su infrastrutture self-hosted. In un contesto locale, la finestra di contesto e la VRAM disponibile sono risorse finite. Se la compressione in riassunti non riduce l'accuratezza, ma la struttura sì, allora il lavoro di progettazione degli schemi di estrazione assume un peso maggiore rispetto all'accumulo di token grezzi. Una rappresentazione strutturata può ridurre l'input al simulatore e alleggerire la pressione sulla memoria, senza sacrificare fedeltà. Non è una raccomandazione universale, ma un trade-off da valutare: lo schema giusto può essere più economico in termini di token, ma la ricerca automatica della struttura introduce a sua volta passaggi di inference aggiuntivi.

C'è anche un aspetto legato alla sovranità dei dati. L'estrazione strutturata può avvenire interamente in locale, limitando la necessità di inviare trascrizioni grezze a servizi cloud. Questo si allinea con i principi di minimizzazione dei dati previsti dal GDPR. Inoltre, il fatto che i risultati siano stati verificati anche con Qwen3-8B — un modello open-weight che può girare su hardware proprio — segnala che l'approccio non dipende da API proprietarie.

Sul piano competitivo, la scoperta ridimensiona il valore dei tool di summarizzazione generica. Se il volume non è il problema, chi vende compressione tout court rischia di rispondere alla domanda sbagliata. Al contrario, chi sviluppa framework per l'orchestrazione di prompt e schemi dinamici può trovare spazio. La struttura diventa un layer di progettazione a sé, distinto dal fine-tuning del modello e dalla raccolta dei dati.

In definitiva, il lavoro sposta l'attenzione da una corsa al contenuto a una corsa alla forma. Non è un dettaglio accademico: per chi costruisce gemelli digitali su stack locali, significa ripensare le pipeline non come semplici condotti di dati, ma come sistemi che devono negoziare continuamente tra fedeltà, costi di calcolo e vincoli di contesto.