CritICL: Weak Models Teach Strong Ones to Think Faster
CritICL uses small model failures as free in-context critiques, matching test-time scaling’s reasoning gains without the token bloat—proof that failure modes are a signal, not noise.
Why it earned a slot
CritICL’s static variant hits **1.9x reasoning accuracy** over standard in-context learning on GSM8K, and it does so with **1/3 the token budget** of test-time scaling methods. The authors’ key insight—that failure patterns repeat across model scales—isn’t just theoretical; it’s a **cheap heuristic** for guiding inference. The paper’s **CritICL-dynamic** approach adapts critiques to specific inputs, but even the static version outperforms baselines by **1.3–1.7x** on MathQA and MMLU. That’s not noise. That’s **structured failure data** acting as a free teacher. No extra generations. No external verifiers. Just **a few hundred tokens** of critique examples, pulled from weaker models’ mistakes. Here’s what’s not in the paper: a discussion of how this scales to proprietary APIs. CritICL’s strength is in open models, where you can mine failure modes from smaller checkpoints. For closed systems, the critique data would need to come from **user interactions**, and that’s a whole other problem (privacy, drift, etc.). But for now, this is a **practical win** for anyone running inference at scale. The authors also note that CritICL’s performance **degrades less** than test-time scaling when context length is limited. That makes sense—you’re not repeating generations, you’re **reusing insights**. But it’s a reminder that **efficiency isn’t just about bigger models**. Sometimes, it’s about **teaching them smarter**. What I don’t know: how CritICL handles **adversarial examples**. If an input is designed to exploit a failure mode, does the critique backfire? The paper tests on standard benchmarks, but real-world inputs are messier. That’s the next step. And here’s the kicker: this isn’t just about math. The same logic applies to **any** structured reasoning task—debugging, planning, even code generation. If you can **capture and reuse** how weaker models fail, you’ve got a **free knowledge transfer mechanism**. No fine-tuning. No retraining. Just **better prompts**. The only downside? The paper’s **CritICL-static** version uses a global failure profile, which means it’s not input-specific. That’s a trade-off: **simplicity vs. precision**. But for most use cases, it’s a sweet spot.