Desarrollador creó un simulador de lectura de código — y se encontró con el no determinismo del LLM

Un desarrollador de Habr lanzó un proyecto inusual: un entrenador donde no escribes código, sino que lees un fragmento funcionando y lo explicas con tus propias palabras — y un modelo de lenguaje evalúa la calidad de tu explicación. La idea es simple, pero la implementación resultó ser inesperadamente compleja.

De dónde vino la idea

Dos irritaciones se acumularon gradualmente. La primera era mi propio código de hace dos meses: en principio todo es claro, pero tienes que leerlo más tiempo del que te gustaría. La segunda fueron los intentos de explicar la arquitectura del proyecto a amigos: lo sabes todo a la perfección, pero hablas en fragmentos, tropiezas en las palabras, no puedes conectar tus pensamientos en un todo coherente. El entrenador surgió de estos dos problemas.

La mecánica es simple: se te muestra un fragmento de código funcionando real, lo explicas con tus propias palabras — oral o por escrito — y recibes una calificación de un LLM. Nada de escribir código, solo leer y explicar. Algo entre una revisión de código y una conversación con un mentor.

La idea en sí no es nueva — explicar código en voz alta se usa en la programación en pareja y en entrevistas técnicas. Pero una versión automatizada, siempre disponible, ya es interesante.

Donde se rompió: no-determinismo del LLM

Escribir el entrenador en sí resultó ser sencillo. Las dificultades comenzaron al configurar la evaluación. La tarea parece trivial: dale al modelo dos textos — el código y la explicación del usuario — y pídele que evalúe qué tan bien uno describe al otro. En la práctica, el modelo se comportaba de manera impredecible:

• Para la misma explicación, daba calificaciones diferentes en solicitudes repetidas
• Valoraba algunos aspectos del código injustamente alto, ignoraba otros sin razón
• La "severidad" del evaluador cambiaba de solicitud a solicitud sin patrones visibles
• Era imposible decir qué contar como una buena explicación — ¿exhaustiva o concisa?

Este es el no-determinismo clásico de LLM — una propiedad que todos conocen teóricamente, pero que se siente acutamente precisamente cuando necesitas una función de evaluación reproducible del modelo, no generación de texto.

Qué exactamente evaluar

El desarrollador descubrió que el problema principal no es técnico, sino conceptual: ¿qué cuenta como una buena explicación de código? ¿Debe ser exhaustiva — cubriendo todas las ramas, casos límite, efectos secundarios? ¿O es suficiente transmitir con precisión la idea principal del algoritmo? ¿Deberías mencionar posibles bugs? ¿Es importante la terminología? ¿Debe el que explica demostrar que entiende por qué se escribió este código, no solo qué hace?

Sin respuestas claras, cualquier criterio de evaluación para un LLM se vuelve vago — y el modelo llena la incertidumbre arbitrariamente. Este es precisamente por qué la ingeniería de prompts para tareas de evaluación es significativamente más compleja que para tareas generativas.

Posibles enfoques técnicos: prompts estrictos con rúbricas específicas, votación en múltiples solicitudes independientes al modelo, explicaciones de referencia como punto de referencia. Pero primero necesitas determinar exactamente qué estás midiendo.

"La parte más difícil resultó no ser escribir el entrenador, sino

hacer que la red neuronal evalúe honesta y consistentemente — y entender exactamente qué necesita ser evaluado"

Qué significa esto

La historia ilustra una trampa típica de proyectos con LLM: la parte que parece más simple — "el modelo evaluará" — en realidad requiere más esfuerzo de ingeniería que todo el resto del producto. La tarea de entrenar la habilidad de leer y explicar código es una necesidad real, especialmente en equipos con grandes cantidades de código heredado. Pero construir un evaluador automatizado confiable para tales habilidades prácticas sigue siendo un desafío de ingeniería abierto.