Caso de uso
Compactación de contexto
Decide qué hechos siguen importando cuando se comprime una conversación de agente.
El problema
El truncado ingenuo descarta el bug que inició el hilo.
Qué hace tu código con la respuesta
Conserva un hecho solo cuando `still_relevant` sea alto.
Compresión que conserva el hecho que bloquea el lanzamiento
El estado lleva la conversación hasta ahora y un hecho candidato a conservar o descartar. Dos preguntas: still_relevant (¿debería quedarse este candidato en el contexto comprimido?) y topic (¿en qué hilo está realmente la conversación — la parada original, la funcionalidad nueva, o ambos activos?). En la muestra, el hecho de los 500 causados por carritos de invitado nulos puntúa como aún relevante y topic se lee ambos activos — el truncador ingenuo que expulsa el resumen del bug pierde, y esta llamada lo conserva.
Decide por hecho, no por turno
Cuando una conversación tiene que encoger, evalúa los hechos candidatos en una solicitud — hasta ocho por llamada, que normalmente se queda en un solo crédito. Conserva los hechos por encima de tu línea de relevancia hasta llenar el presupuesto; conserva ambos hilos cuando topic lo diga. La compactación corre periódicamente entre turnos, no en el camino caliente, así que el viaje de ida y vuelta de 400–600 ms nunca está en el reloj del usuario.
Riesgos propios de la compactación
Los hechos candidatos necesitan procedencia en el estado («encontrado por la herramienta de búsqueda de logs») o los scores de relevancia favorecerán hechos vívidos de una sola línea sobre las cadenas de inferencia ganadas por el agente. No compactes a mitad de turno — ejecútalo entre turnos, cuando nada esté en vuelo. Y presupuesta explícitamente los casos de ambos hilos: un compactador que siempre reserva el presupuesto de un solo hilo se queda sin aire cuando la conversación legítimamente tiene dos líneas activas.
La forma de la solicitud
Esta es la solicitud completa que el playground envía para este preset — el mismo JSON que tu servidor envía a /v1/systemone con una clave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"conversation_so_far": "User asked to debug a 500 on /checkout. We found a null customer_id. User then asked about adding Apple Pay.",
"candidate_to_keep": "The /checkout 500 is caused by a null customer_id on guest carts."
},
"questions": {
"still_relevant": {
"type": "noul",
"instructions": "Should `candidate_to_keep` stay in the compressed context?"
},
"topic": {
"type": "choice",
"instructions": "Which topic is the conversation on now?",
"criteria": {
"debug": "The original outage",
"feature": "A new feature request",
"both": "Both are still active"
}
}
}
}'Preguntas frecuentes sobre este caso de uso
- ¿Cuánto contexto sobrevive a la compactación?
- Todo lo que permita tu presupuesto, en orden de relevancia. Si topic dice «ambos activos», guarda presupuesto para ambos hilos — descartar el bug original para hacer sitio es cómo los agentes «olvidan» lo que estaban haciendo.
- ¿Puedo puntuar turnos enteros en lugar de hechos?
- Los candidatos a nivel de hecho mantienen la decisión nítida: un turno suele plantear dos hechos con futuros muy distintos. Si solo tienes fronteras de turno, tu wrapper propone los hechos candidatos.
- ¿Y si todos los hechos puntúan alto?
- La compactación no puede hacer hueco de la nada — resume el tier más bajo. La llamada tipada te dice qué era estructural antes de que resumas nada.