Estado para Jev
Estructura el material que evaluará Jev: cadena, objeto o array de texto.
El estado es el contenido que pides evaluar a un modelo de System One. Puede ser un mensaje de soporte, un pasaje o la instantánea actual de una aplicación. Se envía en el campo state junto a las preguntas. Cada solicitud evalúa un estado mediante una o más preguntas. Todas las preguntas reciben el mismo estado y se ejecutan de forma independiente. Puedes combinar Choice, Score y Noul en ese mapa. No incluyas las preguntas en el estado y elimina todo lo que la valoración no necesite.
Estructuras admitidas
El estado más sencillo es una cadena de texto: «Me cobraron dos veces en la tarjeta». Usa una cadena cuando el caso conste de un único texto. Usa un objeto JSON cuando tengas campos con nombre, registros relacionados o el estado de una aplicación, como un mensaje junto con un identificador de pedido. Usa un array de texto para una secuencia de mensajes o registros. En Python, pasa la cadena, dict o list correspondiente a client.system_one(state=...).
La página sobre estados de TypeSafe recomienda usar un objeto para la mayoría de las solicitudes, de modo que cada parte tenga un nombre descriptivo. Una conversación de soporte, un pedido con dos cargos capturados y una política de reembolsos pueden coexistir en un mismo objeto. Sigue siendo un único estado. Agrupa la información relacionada cuando la decisión exija comparar esas partes. No ocultes una segunda pregunta en el nombre de un campo.
Jev solo acepta texto. El estado debe ser una cadena, un objeto JSON o un array de valores de texto. No se admiten imágenes, audio ni video. El inglés es el principal idioma de entrenamiento; se aceptan otros idiomas, incluidas las escrituras CJK, pero con menor precisión. Consulta esa nota sobre idiomas en la ficha del modelo y evita enviar píxeles: conviértelos primero en campos.
Separa el contenido de las preguntas
El estado contiene el contenido y los datos de apoyo. Las preguntas definen las valoraciones. Mantén la solicitud de reembolso y la política en el estado; después pregunta si el cliente solicitó un reembolso y si la política lo permite. Si pegas la pregunta en el bloque del estado, Jev seguirá respondiendo al campo de instrucciones y habrás duplicado el prompt en un lugar que consume el presupuesto de 32k compartido entre el estado y la pregunta más larga.
Un estado grande y lleno de detalles irrelevantes es un modo de fallo documentado de jev-1.13. La precisión disminuye porque el contenido no relacionado actúa como distracción, y un bloque sobredimensionado dificulta saber qué campo produjo una respuesta incorrecta. Filtra primero en el código. Envía solo los campos que necesite la pregunta. Cuando no puedas filtrar, un Noul puede puntuar la relevancia de los pasajes antes de la valoración principal, como en la receta de clasificación de pasajes RAG de TypeSafe.
La longitud del contexto es limitada. Jev 1.13 admite 64k tokens para toda la solicitud y 32k para el estado más la pregunta más larga. fan-out especulativo agrupa muchas preguntas breves en torno a un estado conciso. Es más barato y preciso que adjuntar el historial completo de un ticket cuando solo necesitas el último mensaje del cliente y dos filas de cargos.
Un registro de soporte como estado
Un objeto documentado usa ticket.subject, ticket.messages como pares from/text, order.id, order.charges con amount y status, y refund_policy como oración. Así, el caso de cargo duplicado se convierte en un conjunto de Nouls y Choices aplicados a ese objeto, en vez de un chat que deba repetir la política. Tu código ya conoce los importes; Jev determina si el texto solicita un reembolso y si se aplica la oración de la política.
En un bucle de juego como Doom, el estado es una representación textual estructurada del mundo, no fotogramas. La demo de TypeSafe envía ese texto a unas 10 consultas por segundo. En Wikiracing, el estado es la página junto con los enlaces candidatos. En el asistente para el hogar inteligente, el estado es lo que dice el usuario más la lista de dispositivos que ya tengas en memoria. Ninguna de esas demos envía píxeles a Jev.
Cuando un campo de tu base de datos sea numérico, envía una categoría con nombre o un número calculado si la evaluación es semántica ("¿este color se percibe como una advertencia?") y deja los cálculos hexadecimales en el código. jev-1.13 interpreta peor las ternas RGB y los valores hexadecimales que los nombres de colores en inglés. Lo mismo se aplica a las fechas: extrae sus partes con Choice y compáralas después en el código.
Límites y lenguaje
La ventana de 64k de la solicitud incluye el estado y todas las preguntas. La ventana de 32k incluye el estado y la pregunta más larga. Volcar en el estado un PDF de políticas de 20k deja poco espacio para el mapa de preguntas y además activa el modo de fallo por detalles irrelevantes. Recupera primero la información y luego envía los dos párrafos necesarios para la evaluación.
Por ahora, la mayor precisión se obtiene en inglés. Si tus tickets están en japonés o coreano, ejecuta una muestra, grafica la confianza de Noul y Choice, y mantén la revisión humana hasta que esos histogramas se parezcan a los del inglés. El modelo aceptará el texto; no rechazará CJK de forma silenciosa.
Los arreglos de texto sirven para secuencias, no para ocultar un segundo esquema. Si necesitas partes con nombre, usa un objeto. Si necesitas un solo bloque, usa una cadena. Incluir la URL de una imagen en una cadena no dota de visión a Jev; solo da a Jev un token de URL que puede interpretar mal. Obtén y describe el contenido en tus procesos de trabajo y luego envía la descripción.
Si un campo solo sirve para tus registros, no lo incluyas en el estado. Los identificadores de pregunta ya proporcionan claves para relacionar los datos. El estado debe contener las pruebas que leería un panel humano. Esta disciplina también te mantiene dentro del límite de 32k para el estado más la pregunta más larga cuando el hilo del ticket es extenso.
Los campos con nombre son mejores que las codificaciones ingeniosas. order_id, charges[].status y refund_policy resultan legibles tanto para ti como para Jev. Una única cadena que concatene esos mismos datos es válida, pero peor. El objeto documentado para tickets de soporte es la plantilla: ticket, order y policy, seguidos de preguntas que hagan referencia a esos nombres.
Elimina la información de identificación personal que no necesites para tomar la decisión. Jev no se entrena con solicitudes de clientes, pero estas sí permanecen en tus propios registros. Un estado más pequeño corrige un problema de jaggedness y, además, protege la privacidad.
Un arreglo de texto es una secuencia, no un conjunto de espacios con nombre. Si necesitas nombres, usa un objeto.
Fuentes