Irregularidades de Jev 1.13

Jev no es perfecto. Estas son algunas aristas irregulares que conocemos de jev-1.13. Muchas se corregirán en versiones posteriores.

jev-1.13 es rápido, está calibrado y es bueno en el juicio de sentido común, pero no es perfecto. jev-1.13 rinde mejor en las tareas de System One. Puede tener dificultades con tareas que requieren niveles adicionales de indirección. Puede ser bastante literal en su comprensión. Le cuestan las tareas que requieren precisión numérica.

Los modos de fallo en detalle

Lectura literal

jev-1.13 responde a la pregunta que escribiste, no a la que querías. Las palabras de alcance, las negaciones y las condiciones implícitas se leen al pie de la letra. Una pregunta se responderá según las palabras escritas en la instrucción, mientras que una persona podría haber leído la intención detrás de las instrucciones.

En su lugar: indica la condición exacta en las instructions. Sé específico. Pon los casos límite en los criterios. Cuando mires una respuesta errónea y te descubras explicando lo que querías decir en realidad, esa explicación es la mitad que falta de la instrucción. Cuando la interpretación sea inevitable, divídela en dos preguntas literales y combínalas en código.

Matemáticas y números

Jev no es una calculadora. Recomendamos encarecidamente implementar cualquier lógica matemática en código. Jev rinde mejor en preguntas semánticas que en matemáticas.

Contar

jev-1.13 no cuenta de forma fiable. Esto abarca caracteres de una palabra, apariciones de un término en un pasaje y elementos de una lista larga. El modelo reconoce la forma de una respuesta en lugar de contarlos uno a uno, y el error crece con el tamaño de lo que se cuenta.

Antes de hacer una pregunta de conteo, pregúntate por qué el conteo necesita un modelo. Si la unidad es algo que una expresión regular o un analizador puede encontrar, el conteo pertenece al código y el modelo no tiene nada que aportar.

En su lugar: cuenta en código. Cuando quieras contar elementos que cumplen ciertos criterios, itera en código sobre los candidatos y haz una pregunta para cada uno, y luego suma tú mismo las respuestas.

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # up to you on what you want the threshold to be, depends on your usecase.

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 > YES for i in range(len(items)))

Representaciones numéricas

jev-1.13 rinde mejor con representaciones semánticas que numéricas. Por ejemplo, las preguntas sobre colores que usan valores hexadecimales rinden peor que las que usan los nombres en inglés. Dados tripletas RGB o valores hexadecimales, no puede juzgar de forma fiable si dos valores están cerca el uno del otro.

Del mismo modo, las preguntas sobre lenguajes de programación de alto nivel rendirán mejor que las preguntas sobre ensamblador de bajo nivel o instrucciones codificadas en binario.

En su lugar: haz la conversión en código y pasa el número calculado o un grupo con nombre. Reserva el modelo para la parte que es genuinamente un juicio, como si un color se lee como advertencia.

Matemáticas usando score

No uses las salidas de score (por ejemplo, esperanzas y probabilidad) para calcular la magnitud exacta de un número entre dos niveles de un criterio. Puedes usar la esperanza para comprobar si supera un umbral concreto, pero los niveles de score de jev-1.13 son débiles en calibración numérica. No podrá ayudarte a reconstruir el número exacto interpolando entre los dos niveles más cercanos.

Comparación de fechas y horas

jev-1.13 lee las fechas como texto, no como cantidades ordenadas. Preguntar cuál de dos fechas es anterior, cuánto distan entre sí o si una cae dentro de una ventana no es fiable. Empeora con formatos mixtos, referencias relativas y límites de dominio como trimestres, ventanas de liquidación y periodos de devengo.

En su lugar: divide el trabajo. La extracción es un juicio, así que dale esa parte al modelo. La aritmética no lo es, así que mantenla en código.

Cada parte de una fecha es un conjunto cerrado pequeño: doce meses, treinta y un días posibles, un rango acotado de años. Eso convierte la extracción en un Choice sobre opciones enumeradas en lugar de un análisis de forma libre, y te da un sitio donde poner una opción explícita de “no indicado” para que una parte ausente se informe en lugar de adivinarse. El código ensambla las partes en una fecha real y se encarga de todo lo demás, incluidos el orden, la duración, el desfase y el día de la semana.

El cookbook de extracción de fechas tiene la versión resuelta, incluidas las fechas relativas y el gating por confianza.

Indirección

Las instrucciones con dobles negaciones o indirección compleja se responden de forma menos fiable. Una pregunta sobre una propiedad de una propiedad, o algo que requiere varios saltos de razonamiento, cuesta precisión.

En su lugar: escribe tus instrucciones lo más directamente posible. Cuando sea posible, identifica por nombre las partes relevantes del estado.

Estado grande lleno de detalles irrelevantes

La precisión cae a medida que el estado crece con contenido no relacionado con la decisión. El detalle no relacionado actúa como distractor, y un estado grande dificulta saber qué parte de la entrada produjo una respuesta errónea.

En su lugar: recupera y filtra primero en código, y envía solo los campos que la pregunta necesita. Cuando no sea posible filtrar en el estado, puedes usar un Noul para filtrar por relevancia. El cookbook de clasificación de pasajes RAG tiene un ejemplo resuelto.

Contenido adversario

El estado son datos, y jev-1.13 no los trata como hostiles por defecto. El contenido escrito para dirigir de forma adversaria al modelo, ya sea una instrucción inyectada, un encuadre deliberadamente engañoso o un texto que argumenta a favor de su propia clasificación, puede mover la respuesta. Esperamos mejorar esto en el futuro.

En su lugar: sé explícito en los criterios. Prueba tu integración a fondo antes de desplegarla para muchos usuarios.

Instrucciones y criterios contradictorios

Cuando las instructions y los criteria piden cosas distintas, jev-1.13 puede confundirse. El mejor rendimiento viene de una redacción clara. Por ejemplo, un Noul en el que true se asigna a no y false a sí rendirá peor. Apunta a instrucciones que a una persona media le resulte fácil leer y entender.

En su lugar: trata los criterios como una extensión de la instrucción. Alinea ambos con un lenguaje claro y preciso.

Orden de las opciones de un Choice

En algunos casos, observamos que el orden de las opciones de un Choice puede afectar la respuesta, y jev-1.13 se inclina por la opción que aparece primero.

En su lugar: reordena las opciones para comprobar que la respuesta se mantiene consistente.

Generación

jev-1.13 no está entrenado para generar texto. Aunque puedes forzarlo encadenando choices, esto no funcionará bien y será muy lento. Para la extracción de datos, es mejor extraer las opciones posibles usando expresiones regulares o un modelo generativo y dejar que jev-1.13 elija la extracción correcta.

En su lugar: cuando el espacio de respuestas está acotado, convierte la extracción en un Choice sobre las opciones en lugar de pedir el valor en sí. Si de verdad necesitas generar texto… hay otros modelos para eso.