fix(eval): retry transient 5xx in eval HTTP calls + live re-run (#46 #64) - #69
Conversation
) Addresses Gemini review on #64 + live eval. Both eval scripts only caught Timeout/ConnectionError around raise_for_status(), so a transient 502/503/504 from the contended daemon crashed instead of retrying. Now retry on 5xx (transient) and let 4xx (bad auth / bad request) propagate immediately rather than burning retries masking a permanent error. Live re-run against production (env URL fixed to http://familiar:8085) confirms the round-1 finding and is stronger: MRR 0.748 -> 0.921 (+23.1%), R@10 unchanged, R@5 a wash, one persistent regression (daemon-deploy-arch, rank 3->8) from cross-encoder score compression. Verdict stands: KEEP nano, follow up with an A/B vs ms-marco-MiniLM-L-12-v2 on the frozen pools. - scripts/evals/rerank_eval.py, collect_candidates.py: _is_retryable_http helper + 5xx retry / 4xx propagate - tests/test_rerank_eval.py: 5 new cases (5xx retryable, 4xx not, fetch_live retries 503 then succeeds, 4xx fails fast) — full suite 307 passed / 1 skipped - docs/evals/rerank-eval-2026-05-27.md: two-run results table + reconciliation - docs/evals/rerank-eval-live-2026-05-27.json: raw live run #2 output Read-only against the palace. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request hardens the evaluation harness by implementing intelligent retry logic for transient HTTP 5xx errors, ensuring that temporary daemon instability does not crash evaluation runs. It also includes a second, confirmed live production run that validates the rerank quality-lift metrics previously reported, providing more robust evidence for the model's performance. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request updates the rerank evaluation documentation with results from a second live run, adds a new raw metrics JSON file, and implements HTTP retry hardening in the evaluation scripts to retry transient 5xx server errors while failing fast on permanent 4xx errors. It also adds comprehensive unit tests for this new retry logic. No review comments were provided, so there is no feedback to address.
Summary
Round-2 follow-up to #64 (rerank quality-lift eval). Addresses the Gemini review and adds a confirming live production run.
Gemini fixes (both real boundary bugs):
scripts/evals/rerank_eval.pyandscripts/evals/collect_candidates.pyonly caughtTimeout/ConnectionErroraroundraise_for_status(), so a transient502/503/504from the contended daemon crashed instead of retrying._is_retryable_http()helper in both scripts.Live re-run (env URL fixed to
http://familiar:8085): re-confirms #64's finding and is stronger.Live results — two runs agree
MRR lift is robust (+15–23%) — rerank reliably surfaces the best answer higher (rank 7→1 rescue in run #2). R@10 untouched; R@5 a wash (rerank's win and its one regression cancel at the top-5 cutoff, which is why MRR is the load-bearing metric). One persistent regression —
daemon-deploy-archrank 3→8 — from cross-encoder score compression (~0.999 ties on a saturated pool).Final call: KEEP nano; follow up with an A/B vs MiniLM L-12
Lift is real and repeatable, latency acceptable (mean 47–126 ms depending on host load) → rules out REVERT. The persistent regression + flat scores are the ESCALATE candidate signal. Keep nano live; A/B
ms-marco-MiniLM-L-12-v2on the frozen pools (zero retrieval cost). Note: this FlashRank build ships only L-12, no L-6.Test plan
venv/bin/python -m pytest tests/ -q→ 307 passed, 1 skippedfetch_liveretries 503→succeeds, 4xx fails fast without consuming retries🤖 Generated with Claude Code