¿Para qué puedes usar Jev?

Identifica la decisión antes de elegir el modelo

Una tarea útil para empezar tiene una pregunta acotada, pruebas suficientes para responder y un siguiente paso claro. Para un mensaje de cliente, podrían ser el servicio solicitado, el registro de cuenta pertinente y una cola sugerida. Para un documento, podrían ser la consulta de un lector, el texto y una ubicación que examinar.

Los flujos son propuestas de diseño salvo que se identifiquen como ejemplos oficiales o informes de la comunidad. Hemos realizado llamadas reales para comprobar el funcionamiento del sitio, pero no hemos reproducido de forma independiente los casos de terceros ni publicado evaluaciones de calidad o rendimiento. Una demo funcional o un resultado aislado no establecen la precisión de estas aplicaciones.

Casos de la comunidad: cómo usan Jev los desarrolladores

Estos informes públicos muestran decisiones concretas que los desarrolladores han puesto a prueba. Cada resumen enlaza al autor. Su inclusión no implica que TypeSafe ni los equipos mencionados respalden este sitio.

Prueba una revisión de texto en el Playground oficial

Ejemplo didáctico original y ficticio; sin resultados registrados del modelo. Es un ejercicio independiente inspirado en la revisión de textos, no el prompt de Every ni una reproducción de su experimento. Orbit Notes es un producto ficticio. La entrada y las preguntas se mantienen en el mismo inglés en todos los idiomas para poder copiarlas.

Abrir el Playground oficial

Es una página externa de TypeSafe. Inicia sesión con tu propia cuenta y los permisos de acceso necesarios. Estar en la lista de espera no otorga acceso por sí solo.

1. Pega el ejemplo de abajo en el campo state.

2. Añade tres preguntas Noul con los nombres e instrucciones que aparecen abajo. La guía oficial de inicio rápido explica cómo introducir state y las preguntas.

3. Ejecuta la solicitud en el Playground oficial. Lee cada probabilidad junto con su pregunta; después, si te resulta útil, modifica el ejemplo y vuelve a ejecutarlo.

Entrada ficticia

Orbit Notes saves your drafts locally.
Your drafts are stored on your device.
Click Export to download a copy.

Preguntas que debes introducir

repetition (Noul)
Does the text repeat a claim without adding new information?

clear_action (Noul)
Does the text explain what happens when the reader clicks Export?

guaranteed_safety (Noul)
Does the text claim that a draft can never be lost?

Comprueba si las dos primeras frases aportan información distinta, si se explica la acción Export y si el texto promete que los borradores nunca se perderán. Las preguntas son independientes; sus probabilidades no tienen que sumar uno. Usa los juicios como pistas para una revisión humana. Este ejercicio no proporciona puntuaciones esperadas ni umbrales de decisión automática.

Cuatro funciones, cuatro puntos de partida

Desarrolladores: revisar una regla semántica

Prueba una convención redactada de forma precisa que el lint habitual no detecte: ¿un cambio introduce un error visible para el usuario sin explicar cómo recuperarse? Proporciona el diff pertinente y la regla, y devuelve una señal para revisión. El mapa oficial de casos de uso incluye lint semántico de código; esta comprobación concreta es nuestra propuesta ilustrativa.

Conserva el compilador, el conjunto de pruebas y las reglas exactas de lint. Deja que una persona revise las líneas señaladas y decida si la preocupación es válida. Empieza con comentarios orientativos para conocer el coste de las falsas alarmas antes de convertir la comprobación en un requisito para integrar cambios. Es una integración sugerida, no un bot de solicitudes de cambios disponible a través de este sitio.

Equipos de soporte: separar la responsabilidad de la urgencia

Un cliente frustrado puede necesitar al equipo de facturación y no al de ingeniería. Un mensaje aparentemente tranquilo puede describir una interrupción urgente. Pregunta por separado por el destino y la urgencia temporal, y después aplica una política de colas. La guía oficial de inicio rápido proporciona el ejemplo de ticket que aparece más abajo.

Tu aplicación aún debe recuperar los datos de la cuenta, eliminar tickets duplicados y aplicar las reglas para reembolsos o cambios de cuenta. Una clasificación no confirma que el fallo comunicado haya ocurrido.

Equipos de búsqueda y RAG: elegir las pruebas antes de redactar

La generación aumentada por recuperación (RAG) proporciona material recuperado a un generador de texto. Jev puede evaluarse entre la recuperación y la generación. El recetario de pasajes RAG de TypeSafe comprueba por separado la relevancia, las pruebas utilizables, las contradicciones y los intentos de dar instrucciones; después utiliza código para incluir, señalar o excluir un pasaje.

Conserva el identificador de la fuente junto con la valoración. Las pruebas contradictorias pueden merecer una advertencia visible en lugar de una eliminación silenciosa. Evalúa si tu filtro elimina el único pasaje necesario para responder una consulta difícil. El generador sigue siendo responsable de la redacción final; ninguna de las etapas debe eludir los permisos de acceso a los documentos.

Equipos de seguridad: priorizar la atención de los analistas

El recetario de controles para LLM de TypeSafe muestra la comprobación de mensajes entrantes y respuestas generadas, con probabilidades de riesgos y una valoración ordenada de gravedad. Después, el código aplica la política de respuesta.

Para una integración inicial, conserva tu vía de detección existente y compara la cola de revisión propuesta con las decisiones de los analistas. Registra por separado los incidentes no detectados y las derivaciones innecesarias. Una puntuación baja del modelo no debe conceder permisos a una herramienta, desactivar un control existente ni demostrar que un adjunto es inofensivo. Consulta las limitaciones ante entradas hostiles.

Ejemplo completo: encontrar una respuesta en un documento

1. Tarea y entrada

Busca en el texto de las condiciones de servicio de GitHub del recetario: 218 líneas etiquetadas con identificadores, utilizando jev-1.12. El recetario y el script completo enlazan la entrada completa y explican cómo reproducir el ejemplo.

2. Preguntas

Una solicitud pregunta where (Choice sobre los identificadores de línea) y exists (Noul: ¿contiene el documento una respuesta?).

3. Extracto de la salida publicada

Estos son valores seleccionados, no una respuesta completa de la API:

query: who owns the code I upload?
exists: 0.98
L052: 0.95

La línea coincidente de la fuente comienza así: L052 | You own Your Content.

4. Posprocesamiento

El recetario ordena las probabilidades de las líneas y vuelve a asociar los identificadores con el texto de origen. Su política de existencia marca los valores de al menos 0.7 como respuesta presente, los inferiores a 0.35 como ausencia y el intervalo intermedio como respuesta parcial. Por tanto, este ejemplo apunta a L052 y supera la comprobación de existencia de una respuesta.

5. Límites y fuente

Los umbrales y la versión anterior del modelo pertenecen a este ejemplo. Reproducirlo no es una nueva medición. Demuestra recuperación de información, no interpretación jurídica ni exactitud en otros documentos. Caso original y salida mostrada

¿Por qué usar dos señales?

Choice distribuye la probabilidad entre las opciones proporcionadas, que suman uno en conjunto. Por ello, la opción principal es una ganadora relativa; no garantiza de forma independiente que exista una opción adecuada. TypeSafe documenta un máximo de 255 opciones Choice. Semántica y límites de Choice

Nuestra recomendación de implementación es conservar tanto la ubicación como la valoración de existencia en un registro del resultado. No conviertas la primera línea en una respuesta incondicional. Muestra el texto de origen para que pueda examinarse, trata explícitamente las pruebas ausentes o parciales y conserva la versión del documento para que las ediciones posteriores no cambien silenciosamente el significado de un identificador.

Al adaptar este diseño, incluye en tu conjunto de revisión documentos sin respuesta. Incluye también respuestas que abarquen varias líneas y preguntas cuya redacción contenga una suposición falsa. Esos casos prueban la política de recuperación que realmente necesitas, más allá de si la primera línea clasificada parece plausible.

Ejemplo completo: clasificar un ticket de soporte

Entrada, preguntas y salida documentada

El cliente del ejemplo describe un fallo de conexión con Stripe durante tres días, ventas perdidas y la necesidad de ayuda urgente. La solicitud pregunta por el departamento, el nivel de frustración y la urgencia. Aquí parafraseamos el mensaje.

Fuente: solicitud y respuesta de la guía de inicio rápido.

Convertir el resultado en una propuesta

El siguiente código es nuestra explicación. Sus umbrales son elecciones ilustrativas de política, no configuraciones validadas:

function proposeRoute(response) {
  const department = response.answers.department;
  const urgency = response.answers.is_urgent.noul;

  return {
    queue: department.confidence >= 0.7
      ? department.choice
      : "manual-triage",
    priority: urgency >= 0.9 ? "urgent" : "normal",
    suggestedTeam: department.choice,
  };
}

Con los valores publicados, esta función propone una clasificación manual urgente y sugiere soporte técnico. El departamento principal no supera el umbral de confianza que hemos elegido. Este ejemplo no asigna realmente ningún ticket.

La probabilidad y la confianza son campos distintos. TypeSafe deriva la confianza de Choice y Score a partir de la distribución; Noul no tiene un campo de confianza separado. Documentación sobre confianza

Antes de conectar una propuesta así a un sistema de tickets, valida la respuesta, define cómo se resuelven los conflictos y haz observables los fallos. Evalúa por separado las rutas incorrectas y los tickets urgentes no detectados. El ejemplo no establece el estado de la cuenta del cliente ni resuelve el problema de integración.

Informe de la comunidad: explorar la clasificación de correos de phishing

Un participante de Discord describió un experimento inicial con el SDK de Python el 17 de septiembre de 2026, entre las 14:24 y las 14:27 UTC, con la intención de ayudar a las operaciones de seguridad y conectarlo más adelante a un flujo SOAR. Comunicó resultados iniciales alentadores y sensibilidad a la redacción y al detalle de los criterios. Introducción del experimento, observaciones posteriores

Es un informe de la comunidad basado en observaciones de su autor. No demuestra exactitud de detección, tasas de falsos positivos, velocidad, ahorro, comportamiento determinista ni integración en producción. No lo hemos reproducido. No se observó una respuesta oficial verificada en el intercambio capturado; la investigación cubrió conversaciones seleccionadas, no el historial completo de la comunidad. Los enlaces pueden requerir acceso a la comunidad.

Elige un siguiente paso

Elige una decisión cuyo resultado pueda examinarse y cuyo proceso de revisión sea manejable. Empieza por obtener acceso y enviar una solicitud, presupuesta el recorrido con la guía de precios y lee las limitaciones antes de conectar la salida con acciones automáticas.