Caso de uso
Compactação de contexto
Decida quais fatos ainda importam quando uma conversa de agente é comprimida.
O problema
O truncamento ingênuo derruba o bug que começou a thread.
O que seu código faz com a resposta
Mantenha um fato apenas quando `still_relevant` estiver alto.
Compressão que mantém o fato que bloqueia o lançamento
O state carrega a conversa até agora e um fato candidato a manter ou descartar. Duas perguntas: still_relevant (este candidato deve permanecer no contexto comprimido) e topic (de que thread a conversa está realmente — a queda original, a funcionalidade nova, ou ambas ativas). No exemplo, o fato de carrinhos de convidado nulos causarem o 500 pontua como ainda relevante e topic lê ambas ativas — o truncador ingênuo que expulsa o resumo do bug perde, e esta chamada o mantém.
Decida por fato, não por turno
Quando uma conversa tem de encolher, avalie os fatos candidatos em uma requisição — até oito por chamada, o que tipicamente permanece em um único crédito. Mantenha os fatos acima da sua linha de relevância até o orçamento encher; mantenha ambas as threads quando o topic disser isso. A compactação roda periodicamente entre turnos, não no hot path, então o round trip de 400–600 ms nunca está no relógio do usuário.
Pitfalls específicos de compactação
Fatos candidatos precisam de proveniência no state ("achado pela ferramenta de busca em logs"), ou os scores de relevância vão favorecer fatos vívidos de uma linha sobre cadeias de inferência conquistadas pelo agente. Não compacte no meio de um turno — rode entre turnos, quando nada está em voo. E orce os casos de ambas-ativas explicitamente: um compactador que sempre mantém o orçamento de uma thread passa fome quando a conversa tem, legitimamente, duas linhas ativas.
O formato da requisição
Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave 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"
}
}
}
}'FAQ sobre este caso de uso
- Quanto contexto sobrevive à compactação?
- O que o seu orçamento permitir, em ordem de relevância. Se o topic diz "ambas ativas", segure orçamento para as duas threads — derrubar o bug original para abrir espaço é como agentes "esquecem" o que estavam fazendo.
- Posso pontuar turnos inteiros em vez de fatos?
- Candidatos no nível de fato mantêm a decisão nítida: um turno muitas vezes levanta dois fatos com futuros bem diferentes. Se você só tiver fronteiras de turno, o seu wrapper propõe os fatos candidatos.
- E se todo fato pontuar alto?
- Compactação não abre espaço do nada — resuma o tier mais baixo. A chamada tipada diz a você o que era load-bearing antes de você resumir qualquer coisa.