Déboguer les évaluations Hawk/Inspect bloquées

VérifiéSûr

Diagnostiquez et résolvez les évaluations bloquées ou gelées en utilisant des commandes Hawk, l'analyse de logs et des tests API directs pour identifier les erreurs de timeout, de mémoire ou d'API.

Spar Skills Guide Bot
TestingAvancé
4002/06/2026
Claude Code
#debugging#inspect-ai#stuck-eval#api-testing#eval-recovery

Recommandé pour

Notre avis

Ce skill fournit des outils et des techniques pour diagnostiquer et résoudre les problèmes d'évaluations Hawk/Inspect AI qui restent bloquées ou ne progressent pas.

Points forts

  • Checklist structurée avec étapes claires pour identifier les causes de blocage.
  • Couverture des motifs d'erreur courants avec des résolutions spécifiques.
  • Commandes prêtes à l'emploi pour tester directement l'API via middleman.
  • Procédure de récupération permettant de reprendre l'évaluation via le buffer S3.

Limites

  • Nécessite l'accès à la CLI Hawk et aux buckets S3 internes.
  • Certaines étapes dépendent de l'infrastructure spécifique de Metr (middleman).
  • Peut ne pas couvrir tous les cas de blocage, notamment les problèmes de configuration.
Quand l'utiliser

Utilisez ce skill lorsque l'utilisateur signale qu'une évaluation AI est bloquée, ne progresse pas, ou affiche des erreurs 500 ou des boucles de nouvelles tentatives.

Quand l'éviter

Ne l'utilisez pas si l'utilisateur pose des questions sur la conception générale des évaluations ou sur l'interprétation des résultats.

Analyse de sécurité

Sûr
Score qualité92/100

The skill provides diagnostic and recovery commands for debugging stuck evaluations using Hawk/Inspect AI tools. No destructive or exfiltrating commands are included; all operations are standard debugging steps within the evaluation platform.

Aucun point d'attention détecté

Exemples

Stuck evaluation
My evaluation set is stuck and not progressing. Can you help me debug it?
High retry count
I see that my eval has a high retry count. What should I do?
Direct API test
The logs show retries but no clear error. Can you help me test the API directly?

name: debug-stuck-eval description: Debug stuck Hawk/Inspect AI evaluations. Use when user mentions "stuck eval", "eval not progressing", "eval hanging", "samples not completing", "eval set frozen", "runner stuck", "500 errors in eval", "retry loop", "eval timeout", or asks why an evaluation isn't finishing.

Quick Checklist

  1. Verify auth: hawk auth access-token > /dev/null || echo "Run 'hawk login' first"
  2. Get eval-set-id from user
  3. Check status: hawk status <eval-set-id> - JSON report with pod state, logs, metrics
  4. View logs: hawk logs <eval-set-id> or hawk logs -f for follow mode
  5. List samples: hawk list samples <eval-set-id> - see completion status
  6. Look for error patterns (see below)
  7. Test API directly if logs show retries without clear errors

Error Patterns

| Log Pattern | Meaning | Resolution | |-------------|---------|------------| | [uuid task/id/epoch model] Retrying request to /responses | OpenAI SDK retry with sample context | Test API directly with curl to see real error | | [uuid task/id/epoch model] -> model retry N ... [ErrorType code] | Inspect retry with error summary | Check error type; use curl for full details | | 500 - Internal server error | API issue | Download buffer, find failing request, test through middleman AND directly to provider | | 400 - invalid_request_error | Token/context limit exceeded | Check message count and model context window | | Pod UID mismatch | Sandbox pod was killed and restarted | No fix needed—sample errored out, Inspect will retry | | Empty output, pending: true | API returned malformed response | Restart eval (buffer resumes) | | OOMKilled in pod status | Memory exhaustion | Increase pod memory limits |

Key Techniques

  1. Retry messages have sample context - All retry messages include a [sample_uuid task/sample_id/epoch model] prefix. Inspect's own retries also include a compact error summary suffix like [RateLimitError 429 rate_limit_exceeded]. The OpenAI SDK's internal retry messages still don't show the actual error — use curl for full details.
  2. FAIL-OK patterns are fine - Alternating failures and successes mean the eval IS progressing. Only worry about consistent FAIL-FAIL-FAIL patterns.
  3. Use S3 for buffer access - Download .buffer/ from S3 rather than accessing the runner pod directly.
  4. Read .eval files with inspect_ai - Use from inspect_ai.log import read_eval_log instead of manually extracting zips.

Test API Directly

Middleman is the auth proxy. If middleman fails but direct provider calls work, it's a middleman issue.

TOKEN=$(hawk auth access-token)

# Test through middleman
curl --max-time 300 -X POST https://middleman.internal.metr.org/anthropic/v1/messages \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"model": "claude-sonnet-4-20250514", "max_tokens": 100, "messages": [{"role": "user", "content": "Say hello"}]}'

# Test OpenAI-compatible
curl --max-time 300 -X POST https://middleman.internal.metr.org/openai/v1/chat/completions \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "Say hello"}], "max_tokens": 100}'

Recovery

# Delete stuck eval and restart
hawk delete <eval-set-id>
hawk eval-set <config.yaml>

The sample buffer in S3 allows Inspect to resume from where it left off (unless you use --no-resume).

HTTP Retry Count

Task progress logs include "HTTP retries: X". High retry counts indicate API instability even while tasks complete.

Severity: Retry count × wait time = stuck duration. E.g., 45 retries × 1800s = 22+ hours stuck.

More Details

See docs/debugging-stuck-evals.md for:

  • Sample buffer SQL queries
  • Detailed API testing examples
  • Escalation checklist

References

Filing Issues

  • Middleman: https://github.com/metr-middleman/middleman-server/issues
  • Hawk: Linear issue on Evals Execution team
  • Inspect AI: https://github.com/UKGovernmentBEIS/inspect_ai/issues
Skills similaires