Jev System Architect
Propósito
Usa esta habilidad para determinar:
- Si Jev debe pertenecer a un sistema en absoluto
- Exactamente dónde debe estar el límite de Jev
- Qué juicios deben convertirse en preguntas Choice, Score o Noul
- Qué estado debe ver cada juicio
- Qué preguntas deben ejecutarse juntas
- Cómo el código ordinario debe componer los resultados
- Cómo la incertidumbre debe cambiar el comportamiento del sistema
- Cómo debe evaluarse la integración antes del uso en producción
Esta es principalmente una habilidad de arquitectura y descomposición.
Para la sintaxis exacta del SDK, los campos de solicitud/respuesta, modelos, límites o comportamiento de la API específico de la versión, lee la documentación actual de TypeSafe y, cuando esté disponible, utiliza la habilidad oficial del agente de TypeSafe.
No inventes campos de la API.
Modelo Mental Principal
Jev no es la aplicación.
Jev no es el motor de flujo de trabajo.
Jev no es un agente autónomo.
La arquitectura preferida es:
ESTADO DE LA APLICACIÓN
↓
preguntas semánticas acotadas
↓
JEV
↓
juicios tipificados + probabilidades
↓
CÓDIGO DETERMINÍSTICO DE LA APLICACIÓN
↓
rutear / clasificar / verificar / preguntar / escalar / ejecutar
El modelo proporciona juicio programable.
El código posee:
- flujo de control
- permisos
- cálculos
- reglas determinísticas
- persistencia
- transacciones
- efectos secundarios
- ejecución de herramientas
- autorización
- aplicación de políticas
Usa Jev solo donde el software ordinario necesite comprensión semántica de información no estructurada o ambigua.
Condiciones de Activación
Considera Jev cuando el sistema contenga un límite con esta forma:
información no estructurada o contextual
↓
se requiere un juicio acotado
↓
el software necesita un valor tipificado para continuar
Los candidatos sólidos incluyen:
- clasificación de intenciones
- enrutamiento semántico
- decisiones de moderación
- clasificación de documentos
- verificación de evidencia
- verificación de citas
- barreras de seguridad semánticas
- señales de riesgo
- interpretación de mensajes
- selección de candidatos
- dimensiones de clasificación
- juicios de relevancia
- sentimiento o urgencia
- interpretación de solicitudes de usuario
- selección de herramientas/funciones
- extracción de un conjunto de candidatos conocido
- filtrado de pasajes RAG
- triaje de flujo de trabajo
- juicios de calidad
- comparación de políticas con casos
- coincidencia difusa
- alineación de entidades
- decisiones de escalado
También inspecciona el código en busca de síntomas como:
LLM → prosa → analizador sintáctico → JSON → validación → reintento
o:
árbol regex grande
clasificador semántico enorme if/else
clasificador basado en prompt que devuelve JSON arbitrario
bucle de agente usado solo para tomar una decisión limitada
modelo de razonamiento costoso usado para una clasificación trivial
Estos son posibles puntos de inserción de Jev.
No Uses Jev por Defecto
Prefiere código ordinario para:
- aritmética
- fechas exactas ya representadas estructuralmente
- búsquedas en base de datos
- coincidencias exactas de cadenas
- permisos
- autorización
- validación de esquemas
- reglas de negocio determinísticas
- transformaciones conocidas
- ordenar números conocidos
- operaciones criptográficas
- analizadores sintácticos exactos que ya resuelven el problema de manera confiable
Prefiere un modelo generativo cuando la salida requerida es fundamentalmente abierta:
- escritura
- resumen
- explicación
- lluvia de ideas
- generación de código
- síntesis de formato largo
- investigación abierta
- razonamiento de múltiples pasos
Jev puede apoyar esos sistemas tomando decisiones limitadas a su alrededor, pero no debe ser forzado a un rol generativo.
Paso 1 — Encuentra los Límites del Juicio
Inspecciona el flujo de trabajo desde la entrada hasta el resultado.
Marca cada punto donde el software efectivamente pregunta:
"Tengo información, pero necesito entender lo que significa antes de saber qué camino determinístico tomar."
Para cada límite candidato, escribe:
ESTADO DE ENTRADA: ¿Qué información existe?
JUICIO: ¿Qué determinación semántica se necesita?
SALIDA: ¿Qué valor limitado permitiría que el código continúe?
ACCIÓN: ¿Qué hará el código con la respuesta?
CONSECUENCIAS: ¿Qué sucede si el juicio es incorrecto?
No implementes Jev de inmediato.
Primero determina si el código determinístico puede resolver el problema de manera más confiable.
Paso 2 — Aplica la Prueba de Idoneidad de Jev
Un juicio es un candidato fuerte para Jev cuando la mayoría de estos son ciertos:
- La entrada contiene lenguaje natural o datos contextuales.
- La salida requerida puede ser limitada.
- El software necesita la respuesta programáticamente.
- Un humano con conocimiento podría emitir el juicio rápidamente.
- El juicio puede describirse explícitamente.
- La incertidumbre es información útil.
- El resultado puede probarse contra ejemplos o etiquetas.
- El código puede poseer la acción después del juicio.
Sé escéptico cuando la tarea requiera:
- deliberación profunda
- largas cadenas de razonamiento
- muchas conclusiones intermedias dependientes
- generación abierta
- planificación autónoma
Descompón primero.
Paso 3 — Haz las Preguntas Atómicas
Una pregunta de Jev debe representar un juicio coherente.
MAL:
Analiza a este cliente y determina si debemos reembolsarlo, qué tan enojado está, si es probable un fraude y qué departamento debe manejar el caso.
MEJOR:
tema→ Choicereembolso_solicitado→ Noulsenal_fraude→ Noulfrustracion→ Score
Luego compón esas respuestas en código.
El objetivo es:
comportamiento complejo = muchos juicios pequeños + composición determinística
No escondas la política de la aplicación dentro de una pregunta semántica gigante cuando el código podría expresar esa política explícitamente.
Paso 4 — Selecciona la Primitiva Correcta
Choice
Úsala cuando exactamente una respuesta deba seleccionarse de un conjunto definido.
Forma: ¿Cuál?
Ejemplos:
- facturación | técnico | ventas | cuenta
- reembolso | re-reserva | información
- python | javascript | rust | otro
Añade un resultado "otro", "desconocido" o "ninguno" cuando las opciones proporcionadas puedan no cubrir la entrada.
Noul
Úsala para una proposición cuya probabilidad de ser verdadera es útil.
Forma: ¿Es esto cierto?
Ejemplos:
- ¿El cliente solicita un reembolso?
- ¿Este pasaje responde la pregunta del usuario?
- ¿Este mensaje solicita una credencial?
- ¿El currículum indica experiencia profesional en Python?
Interpreta la salida como la probabilidad de que sí.
No interpretes ~0.5 como "intensidad media".
Significa que sí/no son aproximadamente igual de plausibles.
Score
Úsala cuando el juicio exista en una dimensión ordenada.
Forma: ¿Dónde en este espectro definido cae el estado?
Ejemplos:
- tranquilo / preocupado / muy frustrado
- irrelevante / parcialmente relevante / fuertemente relevante / respuesta directa
Cada nivel debe describir una condición semántica concreta.
Evita etiquetas indefinidas como malo / regular / bueno / excelente a menos que su significado esté explícitamente definido.
Paso 5 — Diseña el Estado Deliberadamente
Envía el estado más pequeño que contenga la evidencia requerida para las preguntas.
Prefiere estado estructurado:
{
"ticket": {
"mensaje": "...",
"remitente": {}
},
"cliente": {
"plan": "...",
"pedidos": []
},
"politica": {
"politica_reembolso": "..."
}
}
en lugar de un gran blob de prosa.
Principios:
- relevante > completo
- estructurado > plano
- hechos observados > conocimiento modelado asumido
- información actual > conocimiento integrado obsoleto
Mantén los hechos observados distinguibles de los juicios inferidos.
Cuando las preguntas se refieran a campos de estado específicos, apunta explícitamente a esos campos.
Paso 6 — Despliega Preguntas Independientes
Si varias preguntas pueden responderse desde el mismo estado existente, prefieres preguntarlas juntas.
┌── tema
├── urgencia
ESTADO ── JEV ────────┼── reembolso_solicitado
├── frustracion
└── senal_fraude
No crees llamadas seriales innecesarias como:
Jev → respuesta → Jev → respuesta → Jev → respuesta
cuando las tres preguntas podrían haberse evaluado desde el estado original.
Haz preguntas especulativas cuando sean baratas y puedan ser útiles más adelante.
Ejemplo: categoria, severidad_error, calidad_reproduccion, reembolso_solicitado, frustracion
Si categoria = facturacion, el código simplemente ignora las respuestas específicas del error.
Paso 7 — Usa Múltiples Etapas de Jev Solo para Dependencias Reales
Una segunda solicitud de Jev está justificada cuando la primera respuesta es necesaria para:
- obtener nueva evidencia
- construir nuevo estado
- elegir el siguiente conjunto de candidatos
- determinar qué preguntas pueden hacerse significativamente
- atravesar una jerarquía
- recuperar documentos necesarios para el siguiente juicio
Ejemplo:
PASO 1 ¿Qué familia de productos?
↓
código recupera productos en esa familia
↓
PASO 2 ¿Qué producto exacto coincide mejor?
No serialices preguntas meramente porque el flujo de trabajo conceptualmente contenga varios pasos.
Paso 8 — Mantén la Composición en Código
Jev produce señales semánticas.
El código decide qué significan esas señales operativamente.
Ejemplo:
tema = facturacion
reembolso_solicitado = 0.94
frustracion = alta
El código de la aplicación puede decidir:
if tema == facturacion:
redirigir_a_facturacion()
if reembolso_solicitado > UMBRAL_MARCA_REEMBOLSO:
anadir_marca_reembolso()
if frustracion > UMBRAL_PRIORIDAD:
aumentar_prioridad()
La lógica de negocio debe permanecer inspeccionable.
No le preguntes a Jev "¿Qué debería hacer toda nuestra aplicación?" cuando la respuesta puede construirse a partir de juicios más pequeños.
Paso 9 — Trata la Incertidumbre como una Señal de Primera Clase
Nunca trates la salida tipificada como equivalente a la verdad.
La salida tipificada significa que la interfaz está restringida.
No significa que el juicio semántico no pueda ser incorrecto.
Para Choice y Score, inspecciona las probabilidades y la confianza.
Para Noul, inspecciona la probabilidad de "sí" directamente.
Diseña comportamientos como:
- ALTA CERTEZA → ruta automática
- CERTEZA MEDIA → pedir confirmación / recopilar más evidencia / modelo más fuerte / marcar para revisión
- BAJA CERTEZA → no adivinar / escalar
Los umbrales son política de la aplicación.
Deben reflejar el costo de falsos positivos/negativos, la reversibilidad, el impacto financiero/de seguridad/regulatorio del usuario.
Un umbral copiado de un ejemplo no es evidencia de que sea apropiado para este sistema.
Paso 10 — Ajusta las Puertas de Confianza al Riesgo
No uses un umbral de confianza universal.
Ejemplo:
- mostrar_articulo_ayuda — baja consecuencia
- redirigir_ticket_soporte — consecuencia moderada
- cancelar_suscripcion — consecuencia más alta
- mover_dinero — consecuencia muy alta
El juicio semántico puede ser idéntico mientras que la certeza requerida y la ruta de confirmación difieren.
Para acciones de alto impacto, Jev generalmente debe informar un límite de decisión controlado en lugar de autorizar de forma independiente el efecto secundario.
Paso 11 — Diseña la Evaluación Antes de la Automatización
Antes de poner en producción un límite de Jev, identifica casos representativos.
Incluye: positivos fáciles, negativos fáciles, casos ambiguos, casos con evidencia faltante, casos límite, casos adversariales, fallos raros pero costosos.
Registra: estado, pregunta, comportamiento esperado, respuesta de Jev, probabilidades/confianza, acción de la aplicación, resultado real cuando esté disponible.
Evalúa el comportamiento del sistema, no meramente si la etiqueta principal parecía razonable.
Para sistemas con umbral, mide el comportamiento en varios umbrales.
Mide especialmente: cobertura / tasa de automatización, tasa de falsos positivos, tasa de falsos negativos, tasa de revisión humana, costo de errores, latencia, costo.
Ajusta los umbrales utilizando datos reales del dominio objetivo.
Paso 12 — Centraliza la Política de Jev
Mantén las preguntas de Jev, los criterios, los pesos y las constantes de umbral fáciles de encontrar y revisar.
Prefiere una estructura como:
ai/
jev/
preguntas.*
umbrales.*
evaluacion/
cliente.*
o la estructura equivalente apropiada para el proyecto.
No disperses la política semántica en docenas de manejadores de ruta.
Los revisores humanos deben poder inspeccionar:
- ¿Qué está juzgando Jev?
- ¿Qué definiciones le dimos?
- ¿Qué umbrales causan acciones?
- ¿Qué acciones son reversibles?
- ¿Qué sucede cuando la confianza es baja?
Paso 13 — Conserva los Juicios en Bruto
Cuando sea práctico, retén las salidas en bruto útiles por separado de la acción derivada de ellas.
Por ejemplo:
probabilidad_reembolso = 0.91
puntuacion_frustracion = 1.72
tema = facturacion
confianza_tema = 0.88
en lugar de almacenar solo prioridad = alta.
Esto permite reevaluar umbrales, cambiar pesos, auditar el comportamiento, comparar versiones del modelo, investigar fallos y realizar análisis posteriores.
No retengas datos sensibles más allá de los requisitos legítimos de la aplicación.
Paso 14 — Busca Jev Alrededor de IA Generativa
Jev a menudo es valioso alrededor de un LLM en lugar de reemplazarlo.
Ejemplos:
ENTRADA → Jev barrera de seguridad → LLM → Jev verificación de citas/calidad → código decide si devolver
o:
consulta → recuperación → Jev relevancia / juicios de inyección → contexto seleccionado → modelo de razonamiento
o:
solicitud de usuario → Jev selección de intención/función → función tipificada determinística → resultado
Esto puede reducir la cantidad de control de la aplicación confiado a un modelo generativo abierto.
Procedimiento de Revisión de Arquitectura
Cuando se te pida revisar un sistema existente en busca de oportunidades de Jev:
1. Mapea el flujo de trabajo
Identifica: entradas, pasos determinísticos, decisiones semánticas, llamadas a modelos, analizadores sintácticos, enrutadores, llamadas a herramientas, efectos secundarios, puntos de revisión humana.
2. Produce un mapa de oportunidades de Jev
Para cada candidato:
- UBICACIÓN: Código/módulo/flujo de trabajo actual
- MÉTODO ACTUAL: Cómo se toma el juicio hoy
- CANDIDATO JEV: Sí / No / Quizás
- POR QUÉ: Por qué una decisión semántica acotada es o no apropiada
- ESTADO: Evidencia mínima requerida
- PRIMITIVA: Choice / Score / Noul
- PREGUNTAS: Juicios atómicos propuestos
- COMPOSICIÓN: Cómo el código debe usarlos
- INCERTIDUMBRE: Qué sucede cuando la respuesta no es clara
- RIESGO: Consecuencia de un juicio incorrecto
- EVALUACIÓN: Cómo validarlo
3. Prioriza por apalancamiento
Prefiere oportunidades donde Jev pueda reemplazar código semántico frágil, análisis sintáctico LLM repetido, llamadas de razonamiento trivial costosas, bucles de agente no acotados, clasificadores duplicados o revisión manual de casos obvios — mientras mantienes el comportamiento del sistema acotado y comprobable.
4. Recomienda la v más pequeña
…[truncado para traducción]