JEV - limitaciones

Aplica a jev-1.13. Jev es rápido, calibrado y bueno en juicio de sentido común, pero no perfecto. Rinde peor en tareas con niveles extra de indirección, es bastante literal y flojo en precisión numerica.

Tabla de fallos conocidos

#	Fallo	Que hacer
1	Lectura literal	Escribir la condición exacta y criterios por opción
2	Matematicas y numeros	Aritmetica en código
3	Comparación de fechas/horas	Extraer componentes; comparar en código
4	Indirección	Reducir saltos; apuntar al estado relevante
5	Estado grande con ruido	Filtrar antes; enviar solo lo que la pregunta necesita
6	Contenido adversarial	Prompts precisos; probar casos limite antes de desplegar
7	Instrucciones y criterios contradictorios	Alinear criterios e instrucción
8	Invariantes estructurales de sentido común	Preguntar cada decisión de una sola forma; imponer identidades en código
9	Generación de texto	Usar un modelo generativo

1. Lectura literal

Jev responde a la pregunta escrita, no a la que querias. Palabras de alcance, negaciones y condiciones implicitas se leen al pie de la letra.

Solución: declarar la condición exacta en instructions, ser específico, poner casos limite en criteria. Si te descubres explicando “lo que querias decir”, esa explicación es la mitad que falta de la instrucción. Cuando la interpretación es inevitable, partir en dos preguntas literales y combinar en código.

2. Matematicas y numeros

Jev no es calculadora. Toda lógica matematica va en código.

• Contar: no cuenta de forma fiable (caracteres, ocurrencias, items). Reconoce la forma de una respuesta en vez de contar; el error crece con el tamaño. Alternativa: iterar en código y preguntar uno a uno.

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]
result = client.system_one(
    {"items": items},
    {f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?") for i in range(len(items))},
)
count = sum(result.nouls[f"item_{i}"].noul > 0.5 for i in range(len(items)))

• Representaciones numericas: mejor en semantico que en numerico. Colores por nombre mejor que por hex; lenguajes de alto nivel mejor que ensamblador o binario. Convertir en código y pasar número o bucket con nombre.
• Math usando score: NO usar las salidas de Score para reconstruir la magnitud exacta de un número entre dos niveles. El score sirve para comprobar un umbral, pero la calibración numerica de los niveles es débil.

3. Comparación de fechas y horas

Jev lee las fechas como texto, no como cantidades ordenadas. Preguntar cuál va antes, cuanto distan o si caen en una ventana es poco fiable, y empeora con formatos mezclados, referencias relativas y limites de dominio (trimestres, ventanas de liquidación).

Solución: dividir el trabajo. La extracción es juicio (al modelo); la aritmetica no (al código). Cada parte de una fecha es un conjunto cerrado: 12 meses, 31 dias, rango de años → usar Choice sobre opciones enumeradas, con opción “not stated” explicita. El código ensambla la fecha y hace orden, duración, offset, día de la semana. Cookbook: date extraction.

4. Indirección

Instrucciones con doble negación o indirección compleja se responden peor. Preguntar por una propiedad de una propiedad, o algo que requiere varios saltos de razonamiento, cuesta precisión.

Solución: instrucciones lo más directas posible; identificar las partes del estado por nombre.

5. Estado grande lleno de detalle irrelevante

La precisión cae al crecer el estado con contenido no relacionado. El detalle irrelevante distrae y dificulta saber que parte del input causo un fallo.

Solución: recuperar y filtrar en código primero; enviar solo los campos que la pregunta necesita. Si no se puede filtrar en estado, usar un Noul para filtrar por relevancia (cookbook: classifying RAG passages). Hay limite de contexto.

6. Contenido adversarial

El estado es datos, y jev-1.13 no lo trata como hostil por defecto. Contenido disenado para desviar al modelo (instrucción inyectada, framing enganoso, texto que aboga por su propia clasificación) puede mover la respuesta. Se espera mejorar en el futuro.

Solución: ser explicito en los criterios; probar la integración a fondo antes de desplegar a muchos usuarios.

7. Instrucciones y criterios contradictorios

Cuando instructions y criteria piden cosas distintas, el modelo se confunde. Ejemplo: un Noul donde true mapea a no y false a si rinde peor.

Solución: tratar los criterios como extensión de la instrucción; alinearlos con lenguaje claro y preciso.

8. Invariantes estructurales

Jev es muy consistente (salidas cuantitativamente similares para entradas semanticamente similares), pero muchos invariantes estructurales que uno supondria NO se cumplen.

Ejemplo: “Is the customer asking for a refund?” sobre “I’m not happy with the fit. What are my options here?”:

Noul noul	Choice yes	Choice no	Choice confidence
0.22	0.01	0.99	0.97

Y la misma pregunta con su negación (“Is the customer asking for something other than a refund?”) sobre otro ticket:

refund	not_refund	Suma
0.72	0.47	1.19

Solución: no fiarse de invariantes. No llevar un umbral afinado en un Noul a un Choice. No exigir identidades aritmeticas entre preguntas separadas. Un Choice es relativo (decide cuál); cada Noul es absoluto (puede ser bajo para todas).

9. Generación de texto

Jev no esta entrenado para generar texto. Forzarlo encadenando choices no funciona bien y es muy lento.

Solución: cuando el espacio de respuestas es acotado, convertir la extracción en un Choice sobre opciones. Para extracción, mejor obtener candidatos con regex o un modelo generativo y que Jev elija. Si necesitas generar texto, hay otros modelos.

Recordatorio final (evitar)

• Preguntar al modelo algo que el código puede computar exactamente.
• Esconder varios juicios en una pregunta.
• Tareas System 2 (más capas de indirección).
• Dar más contexto en state del que la pregunta necesita (context rot).

Relacionado

• JEV - primitivas choice, score y noul
• la documentación de referencia
• IA LOCAL - MOC