Sammi De Blas | Knowledge Base

JEV - patrones de construcción

JEV - patrones de construcción

Tesis de construcción

Construir un workflow de software normal e insertar System One solo donde haga falta IA. El código conserva el control de flujo, las reglas deterministas y los efectos secundarios; el modelo hace juicios de sentido común sobre datos no estructurados.

Los 4 patrones

PatronQue haceBeneficio
Speculative Fan-OutMuchas preguntas en una llamada, incluidas especulativas; el código decide que es relevanteCoste, velocidad
Confidence-Gated RoutingUsa la confianza como segundo eje de decisiónFiabilidad, seguridad
Composite ScoringCombina varias dimensiones en una puntuaciónCoste, fiabilidad, velocidad
Intent RoutingClasifica la intención y enruta al handler adecuadoCoste, velocidad

Speculative Fan-Out (detalle)

Enviar todas las preguntas que el sistema pueda necesitar en una sola petición, aunque algunas solo importen para ciertas entradas. El código decide después cuales usa. Todas se evaluan en paralelo: anadir preguntas no anade latencia.

Ejemplo (triage): preguntar category, bug_severity, has_reproducible_steps, refund_requested, frustration a la vez. Si la categoría no es bug, se ignora bug_severity.

Datos medidos (doc): 13 preguntas en una llamada son ~11.5x más baratas y ~9.6x más rapidas que 13 llamadas separadas, sin cambiar las respuestas.

if category.choice == "bug_report":
    if bug_severity.score > 1.5 and bug_repro.noul > 0.6:
        escalate_to_engineering(ticket_id, severity="high")
    else:
        add_to_bug_backlog(ticket_id)
elif category.choice == "billing":
    if refund.noul > 0.7:
        route_to_billing_with_flag(ticket_id, refund_likely=True)
    else:
        route_to_billing(ticket_id)
# Frustration es util independientemente de la categoria
if frustration.score > 1.5:
    flag_for_priority_response(ticket_id)

Workflow de 8 pasos

  1. Usar código cuando puedas. Trabajo determinista en código (fiable y barato). Evitar bucles while de agente si un workflow lo expresa.
  2. Descomponer el estado de entrada. Incluir solo el contexto relevante para las preguntas actuales. No depender del conocimiento en pesos del modelo cuando la info actual puede venir de tu base de conocimiento.
  3. Usar estructura en el estado. JSON anidado. Apuntar a valores concretos con rutas entre backticks (p.ej. `support.tickets[0].message`).
  4. Descomponer las preguntas. Las más explicitas, estrechas, especificas y atomicas posibles. Este es probablemente el concepto más importante. Una pregunta amplia esconde varios juicios; atomizarlos los expone para inspeccionar, afinar y combinar.
  5. Usar estructura en las preguntas. Objetos/arrays con campos con nombre en vez de prosa densa. Para Choice: que cubre cada opción, que NO cubre, ejemplos. Mismos nombres de campo entre opciones para comparar.
  6. Hacer muchas preguntas. Muchas preguntas estrechas e independientes sobre el mismo estado en una petición. Maximiza inteligencia por dolar.
  7. Combinar salidas en código (o alimentar un modelo ML clasico). Reglas deterministas o sumas ponderadas. Para composición aprendida, usar las probabilidades como features de un modelo clasico downstream.
  8. Enrutar por incertidumbre. Acciones distintas para respuestas confiadas y no confiadas. Escalar casos inciertos a humano o a un modelo de razonamiento más caro. Probar umbrales graficando confianza contra accuracy.

Ejemplo: descomponer spam

Mal (una pregunta amplia): is_spam: "Is message spam?"

Bien (descompuesto en Nouls atomicos):

  • requests_credentials: pide contraseña o credencial de login
  • offers_unexpected_reward: promete premio/pago/recompensa inesperada
  • creates_time_pressure: presiona a actuar rápido
  • sender_identity_mismatch: la organización del nombre no casa con el dominio del email
  • link_domain_mismatch: el dominio del enlace no casa con la organización
  • disguises_link_destination: el texto del enlace oculta/miente sobre el destino

Combinar en código:

spam_risk = (
    0.45 * answers["requests_credentials"].noul
    + 0.30 * answers["sender_identity_mismatch"].noul
    + 0.25 * answers["unexpected_reward"].noul
)
spam_is_uncertain = 0.4 < spam_risk < 0.6
if spam_is_uncertain or answers["topic"].confidence < 0.75:
    return route_to_human_review(ticket)
if spam_risk >= 0.6:
    return quarantine_as_spam(ticket)

Ejemplo: verificar tool-calls

En vez de “Is trace.tool_calls correct for request?” (amplia), preguntar atomicamente: si la herramienta es relevante, si los argumentos casan con el schema, si las coordenadas usan el resultado del geocode, si fecha/unidad casan, etc. Mismo principio: cada pregunta un único hecho comprobable.

Que hace componible a System One

PropiedadDescripción
EstructuradoType-safe por construcción; nunca hay que recuperar un valor de prosa
ParaleloPreguntas independientes en paralelo; sin contexto oculto entre ellas
ComparableSalidas ordenables que mueven if, umbrales y comparaciones
RápidoLa mayoría de consultas en ~100 ms; apto para tiempo real y UIs
Confianza calibradaRLCD comunica incertidumbre en vez de tender al exceso de confianza
Auto-consistenteDisenado para respuestas estables en evaluaciones repetidas

Objetivo declarado: ratio inteligencia/velocidad-coste mayor de 100x. La apuesta de fondo: inteligencia más barata creara mucha más demanda.

Nota sobre agentes

Los agentes de código caen más que las personas en el habito de una pregunta por llamada. La agent skill existe para corregir esto: decirle al agente que meta muchas preguntas por llamada, incluidas las especulativas.

Relacionado

Vista Gráfica

Retroenlaces