# Proyectos de investigación

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

Document language: es

Parta del fallo observable y siga después el método, la evidencia y el límite de alcance que le correspondan.

## Elegir en función del fallo observado

Un mismo síntoma puede proceder de la representación, la generación, el control o la verificación.

| Problema observado | Primer diagnóstico | Evidencia que debe requerirse | Método |
| --- | --- | --- | --- |
| El resultado decodificado es deficiente, pero se desconoce qué etapa falla | Evaluar el texto fuente, su reconstrucción emparejada y la salida generada con el mismo evaluador externo. | Distribuciones comparables y comportamiento de las colas en cada etapa. | [Diagnóstico por etapas de los cuellos de botella](https://aogavrilov.com/es/projects/codec-bottleneck-diagnosis/#workflow) |
| Mejora una métrica del espacio latente, pero no la calidad final | Compruebe si la mejora del indicador indirecto se mantiene tras la decodificación. | Métricas pareadas de la salida decodificada, no solo diagnósticos latentes. | [Comprobación de la transferencia de la métrica indirecta](https://aogavrilov.com/es/projects/codec-bottleneck-diagnosis/#decision-table) |
| Un editor de código reescribe más que la región solicitada | Defina un límite de preservación explícito y mida las diferencias fuera de la región. | Localidad y éxito de la tarea medidos conjuntamente. | [Evaluación de la edición localizada](https://aogavrilov.com/es/projects/discrete-latent-generation/#measurement) |
| Una refactorización debe preservar el comportamiento, no solo la sintaxis | Separar la propuesta de la ejecución y la verificación. | Compilación, pruebas, comprobaciones estáticas y detección de refactorizaciones. | [Mapa de decisión de interfaces de control](https://aogavrilov.com/es/projects/discrete-latent-generation/#control-surface) |

Línea activa

## Generación latente discreta

Representaciones discretas para la regeneración selectiva de código, junto con decisiones guiadas por la evidencia entre generación restringida, refactorización asistida por IA y edición predecible de código.

Guía de evaluación

## Diagnóstico del cuello de botella del códec

Un método por etapas para determinar si la calidad decodificada está limitada por la reconstrucción, la generación latente o una medida sustitutiva que no se transfiere al texto final.

## Respuestas específicas

Notas de evidencia independientes para búsquedas más amplias que no parten del título de un artículo. Cada una remite a la publicación pertinente y a su texto completo.

1. [Difusión enmascarada en el espacio de códigos frente al espacio de tokens: cómo compararlas](https://aogavrilov.com/es/research-notes/code-space-vs-token-space-masked-diffusion/) Un protocolo de comparación coherente entre etapas para modelos de lenguaje de difusión enmascarada en el espacio de códigos y en el espacio de tokens cuando el códec discreto presenta pérdidas.
2. [Modificación localizada de código mediante modelos generativos](https://aogavrilov.com/es/research-notes/localized-code-modification-generative-models/) Cómo evitar la reescritura innecesaria de una función completa y, al mismo tiempo, conservar libertad suficiente para que un modelo generativo realice el cambio de código solicitado.
3. [Generación restringida de código para la ingeniería de software](https://aogavrilov.com/es/research-notes/constrained-code-generation-software-engineering/) Una distinción práctica entre restricciones gramaticales, restricciones de tipos, límites de preservación y comprobaciones de aceptación del código generado en el nivel del comportamiento.
4. [Refactorización asistida por IA: métodos y evidencia](https://aogavrilov.com/es/research-notes/ai-assisted-refactoring-evidence/) Cómo evaluar métodos recientes de refactorización asistida por IA sin confundir un parche generado plausible con la preservación verificada del comportamiento.
5. [La generación predecible de código requiere un contrato de preservación](https://aogavrilov.com/es/research-notes/predictable-code-generation-preservation-contract/) Por qué el muestreo determinista no basta y cómo las propiedades protegidas observables y las comprobaciones de aceptación permiten someter a prueba el comportamiento de la generación de código.

## Preguntas de investigación a las que puede responder este sitio

Abra una pregunta práctica para obtener una respuesta concisa y, a continuación, siga el enlace a la evidencia para consultar los métodos, las mediciones y los límites. Se trata de vías de acceso a la investigación, no de garantías universales.

1. ¿Cómo puede un modelo generativo modificar código sin reescribir la función completa? Definir el límite editable antes de la generación, preservar o reutilizar el código fuente situado fuera de él, generar únicamente cambios candidatos y rechazar los resultados que no cumplan la tarea o alteren regiones protegidas. El bloqueo latente jerárquico es una interfaz de control experimental, pero no garantiza tramos idénticos del código fuente. [Comparar interfaces de control para la edición localizada](https://aogavrilov.com/es/projects/discrete-latent-generation/#control-surface) .
2. ¿Qué evidencia demuestra que una edición de código es local y no solo válida desde el punto de vista sintáctico? Medir las diferencias fuera de la región solicitada junto con el éxito de la tarea, los cambios en la región editable, los invariantes estructurales, las pruebas o comprobaciones estáticas y la variabilidad entre ejecuciones repetidas. La tasa de análisis sintáctico solo acredita la corrección formal de la sintaxis. [Revisar la lista de comprobación de la evidencia de localidad](https://aogavrilov.com/es/projects/discrete-latent-generation/#measurement) .
3. ¿Cómo debe equilibrarse la localidad de la edición de código con la diversidad de generación? Presentar conjuntamente la estabilidad de la región protegida, la libertad en la región editable y la unicidad de los candidatos. Copiar la entrada puede maximizar la estabilidad sin avanzar en la tarea; una reescritura sin restricciones puede maximizar el cambio a costa de destruir la localidad. [Véase la evidencia acotada sobre estabilidad y libertad](https://aogavrilov.com/es/projects/discrete-latent-generation/#evidence) .
4. ¿En qué se diferencian la edición localizada de código, la generación restringida y la reparación de programas? La edición localizada pone el énfasis en lo que debe permanecer inalterado; la generación restringida impone una propiedad formal de la salida, como la pertenencia a una gramática; y la reparación de programas exige que el cambio satisfaga la especificación de un defecto o de una tarea. La sintaxis por sí sola no demuestra la equivalencia semántica, la corrección funcional, el éxito de la tarea ni la localidad. [Comparar los tres objetivos](https://aogavrilov.com/es/projects/discrete-latent-generation/#comparison) .
5. ¿Cómo se pueden regenerar partes seleccionadas de una función de Python manteniendo estable el resto? Definir las regiones protegidas y editables antes de la generación, modificar únicamente la representación editable, decodificar y rechazar los candidatos que alteren el código protegido o incumplan la sintaxis, las pruebas, las comprobaciones estáticas o los invariantes específicos de la tarea. El experimento descrito con variables latentes jerárquicas mide la estabilidad probabilística en funciones de 64 tokens; no garantiza que los tramos ni el comportamiento permanezcan inalterados. [Examinar el flujo de regeneración selectiva](https://aogavrilov.com/es/projects/discrete-latent-generation/#workflow) .
6. ¿Qué estrategia de control resulta adecuada para la refactorización con preservación del comportamiento asistida por IA? Utilice el modelo para identificar o proponer una transformación; después, siempre que sea posible, ejecútela con un motor de refactorización fiable y verifique la compilación, las pruebas, los análisis estáticos y la refactorización prevista. Un parche generado que resulte plausible no constituye evidencia suficiente. [Abrir la fila de decisión sobre refactorización](https://aogavrilov.com/es/projects/discrete-latent-generation/#control-surface) .
7. ¿Qué hace que la generación de código sea predecible y no meramente controlable? Defina un contrato de preservación observable y comprobaciones de aceptación antes de elegir el generador. La predictibilidad depende de lo que permanezca estable tras la decodificación y la verificación, no solo de que se hayan fijado una instrucción, una máscara, una gramática o un código latente. [Definir el contrato de preservación](https://aogavrilov.com/es/projects/discrete-latent-generation/#core-idea) .
8. ¿Qué comparación se observó entre la difusión enmascarada en el espacio de códigos y en el espacio de tokens en el experimento de texto descrito? Con el mismo evaluador externo, el MDLM en el espacio de códigos obtuvo una perplejidad mediana de 26.55, frente a 38.42 para la referencia en el espacio de tókenes, lo que supone una reducción del 30.9%. La mediana de la reconstrucción del códec ya era de 27.36, por lo que el resultado debe interpretarse junto con el cuello de botella de la reconstrucción. [Examinar las cifras desglosadas por etapas](https://aogavrilov.com/es/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
9. ¿Cómo deben compararse la difusión enmascarada en el espacio de códigos y en el espacio de tokens cuando el códec presenta pérdidas? Utilice las mismas muestras reservadas y el mismo evaluador de texto decodificado para los originales, las reconstrucciones del códec y las salidas en los espacios de tókenes y de códigos. Informe por separado de la brecha de reconstrucción, pues un generador latente más potente no puede recuperar información que el códec ya haya eliminado. [Comparar las etapas con un único evaluador](https://aogavrilov.com/es/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
10. ¿Cómo se puede diagnosticar la pérdida de calidad en un generador de texto de dos etapas? Medir primero la brecha entre el original y la reconstrucción, y después la brecha entre la reconstrucción y la generación, mediante un mismo evaluador de texto decodificado sin modificaciones. Así se distingue el límite máximo de calidad impuesto por el códec de la degradación adicional introducida por la generación latente. [Siga el diagnóstico de cuatro puntos de control](https://aogavrilov.com/es/projects/codec-bottleneck-diagnosis/#workflow) .
11. ¿Cuándo pueden unas métricas mejores del espacio latente no traducirse en una mejora de la salida decodificada? Una medida sustitutiva latente puede mejorar sin reflejar la propiedad posterior de interés. Compruebe la transferencia decodificando salidas equiparadas y evaluándolas con las mismas métricas finales; de lo contrario, la geometría o la utilización del libro de códigos sigue siendo evidencia diagnóstica, no una mejora de la calidad textual. [Utilice el diagnóstico de transferencia de indicadores indirectos](https://aogavrilov.com/es/projects/codec-bottleneck-diagnosis/#decision-table) .

## Dos panorámicas de evidencia acotada

Estas cifras indican qué se midió; no constituyen garantías universales del modelo.

### Diagnóstico de la compresión

En una configuración 64-a-16 de TinyStories, la perplejidad mediana aumentó de **15.17** para el texto fuente a **27.36** tras la reconstrucción. El MDLM en el espacio de códigos alcanzó **26.55** frente a **38.42** para la línea base del espacio de tókenes con el mismo evaluador externo.

### Control de edición inspeccionable

En una configuración de funciones de Python de 64 tokens, bloquear cuatro códigos de nivel superior elevó la tasa de análisis sintáctico de **0.453** a **0.591** , mientras que las posiciones desbloqueadas cambiaron a una tasa de **0.936** y la tasa de unicidad de las muestras condicionales se mantuvo en **0.998** .

## Qué no pretende afirmar este mapa

Los experimentos publicados no demuestran una preservación exacta del AST, equivalencia semántica, corrección funcional, reparación a escala de repositorio ni una ordenación universal de los cuellos de botella del códec y del generador. Las guías convierten evidencia acotada en procedimientos de diagnóstico reutilizables; aun así, cada sistema nuevo requiere su propia validación de los resultados decodificados y del comportamiento.
