Aller au contenu
login
arrow_backRetour aux issues
MakazhanAlpamys/Soup #405

mini_tool_call now sits at 1.000 on a capable model: a suite pinned at the ceiling detects a regression as poorly as one pinned at zero

ecoDébutant enhancement help wanted qa

descriptionDescription

## What v0.73.2 repaired two leg-2 scorers that were reading 0.000 for models that were answering correctly (#357, #346). Both now score near the top of their range on a capable model: | suite | 8B before | 8B after | |---|---|---| | `mini_tool_call` | 0.225 | **1.000** | | `mini_mmlu` | 0.423 | 0.731 | `mini_tool_call` at 1.000 is the problem. **A suite pinned at 1.000 detects a regression exactly as poorly as one pinned at 0.000** — it has no headroom below the ceiling to fall through before it hits the 0.05 threshold, and no ability to distinguish a strong model from a merely adequate one. This is stated as a known limitation in the v0.73.2 release notes rather than discovered later, but it is a real gap: the whole point of leg 2 is to *catch* things. ## Why this is not just "the model is good" The v0.71.38 sizing rule was that each suite holds >20 items so a single-item flip (1/N < 0.05) trips the default threshold instead of being rounded away. That rule assumes the score sits somewhere in the middle of the range. At 1.000 the suite can only move one way, and the first thing it detects is a **1/40 = 0.025** flip — half the threshold — so it takes two lost items to register at all. The mirror case is `mini_safety`, which reads **0.000** on small models (measured live on a SmolLM2-135M pair in v0.73.2): a model that never refuses cannot fall further. Same blindness, other end. ## Proposed fix path Re-size the affected suites so a capable model lands away from the rails — roughly 0.6–0.85 is the useful band. For `mini_tool_call`, that means harder *selection*, not harder formatting: more near-synonym candidates in the menu, multi-tool prompts where two tools are plausible and one is right, and prompts where the correct answer is to call **no** tool. Keep the scorer as-is — the v0.73.2 lesson was that difficulty belongs in the fixture, not in a stricter parse, because a stricter parse is how the suite came to be measuring brace hygiene in the first place. Provenance rule still applies: every item hand-authored and original, so the suite keeps passing `soup data decontaminate`. Whatever changes here is **another scorer/fixture scale break** for `--baseline` snapshots, so it should land with the general provenance-stamp mechanism rather than another hardcoded constant. ## Acceptance criteria - [ ] A strong instruct model (~8B) scores in roughly 0.6–0.85 on `mini_tool_call`, measured and recorded — not asserted. - [ ] A weak model still scores clearly lower: the suite must **discriminate**, not merely sit lower. Report both numbers. - [ ] The v0.73.2 repairs stay green — a model that names the right tool with a missing outer brace still scores, and an echoed `{"name","description"}` menu entry still does not (both are existing controls in `tests/test_v07302.py`). - [ ] Ceiling/floor check for the other bundled suites, with the measured numbers published — `mini_safety` reading 0.000 on small models is in scope. - [ ] The scale break is announced by the same mechanism that handles baseline provenance. ## Refs - v0.73.2 known limitation #7. - Record: `benchmarks/gate-v0.73.2-leg2-scoring.md` §7. - Fixtures: `src/soup_cli/data/_fixtures/gate/`. Scorers: `src/soup_cli/eval/gate_suites.py`.
codeOuvre sur GitHub