# Progetti di ricerca

Canonical HTML: https://aogavrilov.com/it/projects/

Document language: it

Partire dal malfunzionamento osservabile, quindi seguire il metodo, le evidenze e i limiti di applicabilità pertinenti.

## Scegliere in base all'errore osservato

Lo stesso sintomo può derivare dalla rappresentazione, dalla generazione, dal controllo o dalla verifica.

| Problema osservato | Prima verifica diagnostica | Evidenze da richiedere | Metodo |
| --- | --- | --- | --- |
| L'output decodificato è scadente, ma non è nota la fase responsabile dell'errore | Valutare il sorgente, la ricostruzione abbinata e l’output generato con il medesimo valutatore esterno. | Distribuzioni confrontabili e comportamento delle code in ogni fase. | [Diagnosi per fasi del collo di bottiglia](https://aogavrilov.com/it/projects/codec-bottleneck-diagnosis/#workflow) |
| Una metrica dello spazio latente migliora, ma la qualità finale no | Verificare se il miglioramento dell’indicatore surrogato persiste dopo la decodifica. | Metriche appaiate sull'output decodificato, non soltanto diagnostiche latenti. | [Verifica della trasferibilità della metrica surrogata](https://aogavrilov.com/it/projects/codec-bottleneck-diagnosis/#decision-table) |
| Un editor di codice riscrive più della regione richiesta | Dichiarare un confine di preservazione esplicito e misurare le differenze esterne alla regione. | Località e successo nel compito misurati congiuntamente. | [Valutazione delle modifiche localizzate](https://aogavrilov.com/it/projects/discrete-latent-generation/#measurement) |
| Un refactoring deve preservare il comportamento, non soltanto la sintassi | Separare la proposta dall’esecuzione e dalla verifica. | Compilazione, test, controlli statici e rilevamento del refactoring. | [Mappa decisionale delle interfacce di controllo](https://aogavrilov.com/it/projects/discrete-latent-generation/#control-surface) |

Direzione di ricerca attiva

## Generazione latente discreta

Rappresentazioni discrete per la rigenerazione selettiva del codice, affiancate da scelte fondate sulle evidenze tra generazione vincolata, refactoring assistito dall'IA e modifica prevedibile del codice.

Guida alla valutazione

## Diagnosi del collo di bottiglia del codec

Un metodo per fasi volto a stabilire se la qualità decodificata sia limitata dalla ricostruzione, dalla generazione latente o da una misura surrogata che non si trasferisce al testo finale.

## Risposte mirate

Note autonome sulle evidenze per ricerche più ampie che non partono dal titolo di un articolo. Ciascuna rimanda alla pubblicazione pertinente e al relativo testo integrale.

1. [Diffusione mascherata nello spazio dei codici e nello spazio dei token: come confrontarle](https://aogavrilov.com/it/research-notes/code-space-vs-token-space-masked-diffusion/) Un protocollo di confronto coerente tra le fasi per modelli linguistici a diffusione mascherata nello spazio dei codici e nello spazio dei token, quando il codec discreto comporta una perdita di informazione.
2. [Modifica localizzata del codice mediante modelli generativi](https://aogavrilov.com/it/research-notes/localized-code-modification-generative-models/) Come evitare di riscrivere inutilmente un’intera funzione, lasciando al contempo a un modello generativo libertà sufficiente per apportare la modifica richiesta al codice.
3. [Generazione vincolata di codice per l'ingegneria del software](https://aogavrilov.com/it/research-notes/constrained-code-generation-software-engineering/) Una distinzione operativa tra vincoli grammaticali, vincoli di tipo, confini di preservazione e controlli di accettazione sul comportamento del codice generato.
4. [Refactoring assistito dall'IA: metodi ed evidenze](https://aogavrilov.com/it/research-notes/ai-assisted-refactoring-evidence/) Come valutare i recenti metodi di refactoring assistito dall’IA senza confondere la plausibilità di una patch generata con l’effettiva verifica della preservazione del comportamento.
5. [La generazione prevedibile di codice richiede un contratto di preservazione](https://aogavrilov.com/it/research-notes/predictable-code-generation-preservation-contract/) Perché il campionamento deterministico non è sufficiente e in che modo proprietà protette osservabili e controlli di accettazione rendono verificabile il comportamento della generazione di codice.

## Domande di ricerca a cui può rispondere questo sito

Apri una domanda pratica per ottenere una risposta concisa, quindi segui il collegamento alle evidenze per consultare metodi, misurazioni e limiti. Si tratta di percorsi di accesso alla ricerca, non di garanzie universali.

1. Come può un modello generativo modificare il codice senza riscrivere l'intera funzione? Definire il confine modificabile prima della generazione, preservare o riutilizzare il codice sorgente al suo esterno, generare soltanto modifiche candidate e rifiutare gli output che non soddisfano il compito o alterano le regioni protette. Il blocco gerarchico delle variabili latenti è un'interfaccia di controllo sperimentale, ma non garantisce intervalli identici nel codice sorgente. [Confrontare le interfacce di controllo per la modifica localizzata](https://aogavrilov.com/it/projects/discrete-latent-generation/#control-surface) .
2. Quali evidenze mostrano che una modifica del codice è locale, anziché meramente valida sul piano sintattico? Misurare il diff esterno alla regione richiesta insieme al successo del compito, alle modifiche nella regione editabile, agli invarianti strutturali, ai test o ai controlli statici e alla variabilità tra esecuzioni ripetute. Il solo tasso di parsing attesta unicamente la correttezza sintattica. [Esamina la lista di controllo delle evidenze di località](https://aogavrilov.com/it/projects/discrete-latent-generation/#measurement) .
3. Come si dovrebbe bilanciare la località delle modifiche al codice con la diversità della generazione? Riportare la stabilità della regione protetta insieme alla libertà nella regione modificabile e all’unicità dei candidati. Copiare l’input può massimizzare la stabilità senza produrre alcun avanzamento nel compito; una riscrittura priva di vincoli può massimizzare il cambiamento distruggendo però la località. [Consulta le evidenze circoscritte sul compromesso tra stabilità e libertà](https://aogavrilov.com/it/projects/discrete-latent-generation/#evidence) .
4. In che cosa differiscono la modifica localizzata del codice, la generazione vincolata e la riparazione dei programmi? La modifica localizzata pone l’accento su ciò che deve rimanere invariato; la generazione vincolata impone una proprietà formale dell’output, come l’appartenenza a una grammatica; la riparazione dei programmi richiede invece che la modifica soddisfi la specifica di un difetto o di un compito. La sola sintassi non dimostra l’equivalenza semantica, la correttezza funzionale, il successo nel compito o la località. [Confrontare i tre obiettivi](https://aogavrilov.com/it/projects/discrete-latent-generation/#comparison) .
5. Come si possono rigenerare parti selezionate di una funzione Python mantenendo stabile il resto? Definire le regioni protette e modificabili prima della generazione, intervenire soltanto sulla rappresentazione modificabile, decodificare e rifiutare i candidati che alterano il codice protetto o non superano la sintassi, i test, i controlli statici o gli invarianti specifici del compito. L'esperimento riportato con variabili latenti gerarchiche misura la stabilità probabilistica su funzioni di 64 token; non garantisce che gli intervalli o il comportamento rimangano invariati. [Esaminare il flusso di lavoro di rigenerazione selettiva](https://aogavrilov.com/it/projects/discrete-latent-generation/#workflow) .
6. Quale strategia di controllo è adatta al refactoring assistito dall'IA con preservazione del comportamento? Usare il modello per individuare o proporre una trasformazione; ove possibile, eseguirla poi con un motore di refactoring affidabile e verificare la compilazione, i test, i controlli statici e il refactoring previsto. Una patch generata plausibile non costituisce evidenza sufficiente. [Apri la riga decisionale relativa al refactoring](https://aogavrilov.com/it/projects/discrete-latent-generation/#control-surface) .
7. Che cosa rende la generazione di codice prevedibile, anziché soltanto controllabile? Definire un contratto di preservazione osservabile e i controlli di accettazione prima di scegliere il generatore. La prevedibilità dipende da ciò che resta stabile dopo la decodifica e la verifica, non soltanto dall’aver fissato un prompt, una maschera, una grammatica o un codice latente. [Definire il contratto di preservazione](https://aogavrilov.com/it/projects/discrete-latent-generation/#core-idea) .
8. Qual è stato il confronto tra la diffusione mascherata nello spazio dei codici e quella nello spazio dei token nell’esperimento testuale descritto? Con il medesimo valutatore esterno, l'MDLM nello spazio dei codici ha ottenuto una perplexity mediana di 26.55, rispetto a 38.42 per la baseline nello spazio dei token, con una riduzione del 30.9%. La mediana della ricostruzione del codec era già pari a 27.36; il risultato va quindi interpretato congiuntamente al collo di bottiglia della ricostruzione. [Esaminare i valori riportati per ciascuno stadio](https://aogavrilov.com/it/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
9. Come si dovrebbero confrontare la diffusione mascherata nello spazio dei codici e quella nello spazio dei token quando il codec è con perdita? Utilizzare gli stessi campioni di test e lo stesso valutatore del testo decodificato per gli originali, le ricostruzioni del codec, gli output nello spazio dei token e quelli nello spazio dei codici. Riportare separatamente lo scarto di ricostruzione, poiché un generatore latente più efficace non può recuperare informazioni già eliminate dal codec. [Confrontare le fasi con un unico valutatore](https://aogavrilov.com/it/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
10. Come si può diagnosticare la perdita di qualità in un generatore di testo a due stadi? Con un unico valutatore invariato del testo decodificato, misurare prima lo scarto tra originale e ricostruzione e poi quello tra ricostruzione e generazione. In tal modo si distingue il limite massimo di qualità imposto dal codec dall'ulteriore deterioramento introdotto dalla generazione latente. [Segui la diagnosi articolata in quattro punti di controllo](https://aogavrilov.com/it/projects/codec-bottleneck-diagnosis/#workflow) .
11. Quando metriche migliori nello spazio latente possono non tradursi in un miglioramento dell'output decodificato? Una misura surrogata latente può migliorare senza riflettere la proprietà a valle di interesse. Il trasferimento va verificato decodificando output corrispondenti e valutandoli con le stesse metriche finali; diversamente, la geometria o l'utilizzo del codebook rimangono evidenze diagnostiche, non un miglioramento della qualità testuale. [Verificare la trasferibilità della metrica surrogata](https://aogavrilov.com/it/projects/codec-bottleneck-diagnosis/#decision-table) .

## Due istantanee di evidenze circoscritte

Questi valori indicano ciò che è stato misurato; non costituiscono garanzie universali sul modello.

### Diagnosi della compressione

In una configurazione TinyStories con compressione da 64 a 16, la perplessità mediana è aumentata da **15.17** per il testo sorgente a **27.36** dopo la ricostruzione. MDLM nello spazio dei codici ha raggiunto **26.55** rispetto a **38.42** per la baseline nello spazio dei token, utilizzando lo stesso valutatore esterno.

### Controllo ispezionabile delle modifiche

In una configurazione con funzioni Python di 64 token, il blocco di quattro codici di livello superiore ha innalzato il tasso di parsing da **0.453** a **0.591** , mentre le posizioni non bloccate sono cambiate con un tasso pari a **0.936** e i campioni condizionati sono rimasti **0.998** univoco.

## Che cosa non sostiene questa mappa

Gli esperimenti pubblicati non dimostrano la preservazione esatta dell’AST, l’equivalenza semantica, la correttezza funzionale, la riparazione su scala di repository né un ordinamento universale dei colli di bottiglia del codec e del generatore. Le guide trasformano evidenze circoscritte in procedure diagnostiche riutilizzabili; ogni nuovo sistema richiede comunque una propria validazione dell’output decodificato e del comportamento.