ユースケース
コンテキストの圧縮
エージェントの会話を圧縮するとき、どの事実がまだ重要かを判断します。
問題
単純な切り詰めは、そのスレッドの発端となったバグを落とします。
回答に対してコードが行うこと
`still_relevant` が高い事実だけを保持します。
リリースを止める事実を残す圧縮
state はこれまでの会話と、保持または削除の候補である 1 つの事実を運びます。質問は 2 つ：still_relevant（この候補は圧縮後のコンテキストに残すべきか）と topic（会話は実際にどのスレッドにいるか — 元の障害、新機能、それとも両方が動いているか）。サンプルでは、null のゲストカートに起因する 500 という事実は still-relevant と判定され、topic は両方が動いていると読みます — バグの要約を追い出す単純な切り詰めが負けて、この呼び出しはそれを残します。
ターンごとではなく事実ごとに決める
会話を縮めなければならないとき、候補の事実を 1 つのリクエストで評価します — 1 呼び出し最大 8 件で、たいてい 1 クレジットに収まります。関連性のラインより上の事実は、予算が満たされるまで保持します。topic がそう言うなら、両方のスレッドを保持します。圧縮はターンの間で定期的に走り、ホットパスでは走らないので、400〜600 ms の往復がユーザーの時計に乗ることはありません。
圧縮特有の落とし穴
候補の事実には state 内に出自が必要です（"log search ツールが発見"）— でないと関連性スコアが、エージェントが積み上げた推論の鎖よりも、鮮やかな 1 行の事実を優先します。ターンの途中で圧縮しないこと — 何も実行中でないターンの間に走らせます。そして両スレッドのケースに予算を明示的に割くこと：常に片方のスレッドの予算だけを守る圧縮器は、会話が正当に 2 本の動いている筋を持つとき飢えます。
リクエストの形状
これは、このプリセットについて Playground が送る完全なリクエストです — 自分のサーバーが Bearer キー付きで /v1/systemone に送るのと同じ JSON です。
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
- 圧縮後、どれだけのコンテキストが生き残りますか？
- 予算が許す範囲で、関連性の順に残ります。topic が「両方が動いている」と言うなら、両方のスレッドの分を予算に取っておきます — 場所を作るために元のバグを落とすのが、エージェントが自分の作業を「忘れる」仕方です。
- 事実の代わりにターン全体をスコア化できますか？
- 事実レベルの候補が判断を鋭く保ちます：1 つのターンはしばしば、まったく異なる将来を持つ 2 つの事実を持ち上げます。ターンの境界しか持たないなら、ラッパーが候補の事実を提案する形にします。
- すべての事実が高く判定されたら？
- 圧縮は無から場所を作れません — 最下層のティアを要約します。型付きの呼び出しは、何かを要約する前に、何が支え柱だったかを教えてくれます。