Determinismo en IA generativa: greedy decoding y guardrails
Los LLMs son probabilísticos por diseño. Cómo reducir la variabilidad del output con greedy decoding, temperatura baja y guardrails en el contexto — y por qué un CLAUDE.md bien estructurado es el primer paso.
¿Por qué los LLMs no son deterministas?
Los modelos de lenguaje generativos producen texto token a token. En cada paso, el modelo calcula una distribución de probabilidad sobre todo el vocabulario posible — decenas de miles de tokens candidatos — y elige el siguiente según esa distribución. El sampling probabilístico es el mecanismo por defecto: no se elige siempre el token más probable, sino que se muestrea de la distribución.
Tres parámetros controlan cuánta variabilidad hay en ese muestreo: temperature (escala la distribución — más alta, más plana y variada; más baja, más concentrada en los tokens más probables), top-k (considera solo los k tokens más probables) y top-p (considera el conjunto mínimo de tokens cuyas probabilidades acumuladas superen p). La combinación de los tres determina cuánta variabilidad hay en el output.
La consecuencia práctica: dos ejecuciones con el mismo prompt, el mismo modelo y la misma configuración pueden producir outputs diferentes. Esto no es un bug — es una característica de diseño. La pregunta es cuánta variabilidad es aceptable para cada tipo de tarea.
Greedy decoding: elegir siempre el token más probable
El greedy decoding es la estrategia de selección más simple: en cada paso, elegir el token con la probabilidad más alta, sin muestreo. Combinado con temperature=0, el output es determinista en el sentido de que para el mismo input el modelo siempre elige el mismo camino probabilístico — aunque pequeñas diferencias en el hardware o la versión del modelo pueden seguir produciendo variaciones mínimas.
El greedy decoding es adecuado para generación de código y documentación técnica porque reduce la creatividad del modelo en favor de la consistencia. El coste es que los outputs pueden ser más repetitivos y menos originales — lo que en código y documentación es precisamente lo que se busca.
Importante: temperatura 0 no garantiza determinismo perfecto en todos los modelos. Algunos proveedores aplican variaciones adicionales por diseño. Para tareas críticas, verificar la documentación del modelo específico sobre su comportamiento con temperatura 0.
Guardrails en el contexto
La temperatura controla la variabilidad en el muestreo de tokens. Pero hay otra fuente de variabilidad que la temperatura no controla: el espacio de respuestas válidas que el modelo considera razonables dado el contexto. Aquí es donde los guardrails de contexto actúan.
Un CLAUDE.md bien estructurado, reglas explícitas sobre convenciones de código, ejemplos few-shot de outputs esperados y criterios de aceptación detallados reducen el espacio de respuestas que el modelo considera válidas. Cuanto más específico y restrictivo es el contexto, menos margen tiene el modelo para improvisar — y más predecible es el output, independientemente de la temperatura.
La escala del determinismo
No hay un valor único correcto de temperatura — depende de la tarea. La escala va desde la máxima variabilidad útil para exploración hasta el comportamiento casi determinista necesario para generación de código repetible:
Alta variabilidad
Brainstorming, generación creativa, exploración de ideas
Variabilidad moderada
Redacción de documentación, respuestas conversacionales
Baja variabilidad
Generación de código, extracción de datos estructurados
Greedy decoding
Código repetible, transformaciones deterministas, tests
Consecuencias prácticas para equipos
El determinismo — o la falta de él — tiene efectos concretos en la forma en que los equipos trabajan con agentes:
El mismo prompt puede dar resultados distintos en dos miembros del equipo
Si cada uno tiene un CLAUDE.md diferente o usa configuraciones distintas de temperatura, los outputs divergen aunque el prompt sea idéntico.
El CLAUDE.md y las reglas son guardrails colectivos
Un contexto compartido y versionado reduce la variabilidad entre miembros del equipo más que ajustar la temperatura individualmente.
Versionar el contexto junto con el código es crítico
Si el CLAUDE.md cambia entre la implementación y la revisión, el agente puede generar código diferente al original aunque el prompt sea el mismo.
Los modelos más nuevos no garantizan más determinismo
Un modelo más capaz con temperatura alta puede ser más impredecible que un modelo anterior con temperatura baja y contexto restrictivo.
La conclusión práctica: la herramienta más poderosa para reducir la variabilidad en un equipo no es la temperatura — es el contexto compartido. Un CLAUDE.md bien estructurado, versionado en git y mantenido por el equipo completo reduce la variabilidad entre desarrolladores más que cualquier ajuste de parámetros del modelo.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.