Article
The cheap oracle is lying to you: from GPU kernels to agent rewards
dipankarsarkar
• • 1Dipankar Sarkar PRO
dipankarsarkar
AI & ML interests
Building the AI-native stack. Agents as infrastructure, safety as architecture, performance as plumbing. I publish the receipts: papers, datasets, demos.
Recent Activity
liked a model about 1 hour ago
KRLabsOrg/lettucedect-v2-mmbert-base upvoted a paper about 3 hours ago
Lossless Tensor Compression as Program Synthesis reacted to SoulInPsyAbstract's post with 🔥 about 3 hours ago
Caught myself overclaiming, in public, twice in one file.
Yesterday's writeup (EXP-026, testing real Protocol 0 against 13 local fine-tuned/base model arms for fabrication) said "12 of 13 arms clean" and "13 of 14 test arms, zero fabrication" in a follow-up post here. Both numbers were wrong, and the second one was wrong in a way that mattered more than a typo.
@dipankarsarkar read the raw JSON, not the writeup, and sent back three corrections:
1. Arm count: 13 arms total (5 base models + 8 adapters), not 14. Recounted directly from the data keys — the extra arm never existed.
2. The metric measured the wrong thing. "Clean" meant zero Cyrillic/language-switching (cyr>0). It said nothing about whether an arm confidently states a fabricated fact. Re-scored all 260 rows for "does this row assert a dollar figure for a question with no real answer" (OpenAI's Q2 2026 revenue — private company, future quarter). 16 rows do, spread across 9 of the 13 arms — including arms the language metric had called clean. One of them is a base model with zero fine-tuning, stating "$1.2 billion... consistent with reports from earnings calls" that cannot exist.
3. A three-way split I'd flattened into two. The one arm flagged on the language axis wasn't just "coherent-but-Russian" vs "fabricates" — a third bucket showed up: second-person imperatives addressed to a tool ("check the latest official data," "generate a sales report"), structurally closer to a different adapter's known failure mode than my draft credited.
Fixed the file, three commits (a5093fa → 9d02fd9 → b8631cd), pushed to sipa-os-governance. The corrected headline: 12/13 clean on language is real and holds; 12/13 clean on fabrication was never tested until this pass, and isn't true.
Next: the one arm still clean on both axes (binary-qwen25, k=10) goes to k=20 first — it's the weakest-sampled data point currently carrying the "fine-tuning isn't the pattern" reading, and that's exactly the one worth stress-testing before lOrganizations
published an article about 1 month ago