标签：#datasets

You fine-tune a model, run your benchmark, and the score jumps six points. Before you write that up, there's one question worth ten minutes: how many of those benchmark examples were in the training data? If the answer is "some", part of that six points is a measurement of memory rather than capability — and there is no way to separate the two after the fact. This is train/test contamination. It's one of the most common and least discussed reasons an offline number fails to reproduce in production, and it is almost never introduced deliberately. How it gets in Nobody copies their test set into training on purpose. It happens through ordinary steps: Merging public datasets. Two datasets that look unrelated often share a source. Instruction-tuning collections are especially prone to this — many are recombinations of the same handful of seed sets. Splitting after augmentation. Paraphrase or template-expand first, split second, and variants of one item land on both sides. The split looks random. It isn't. Re-scraping. Your eval set came from a site in March. Your training crawl hit the same site in June. Synthetic data from a model that saw the benchmark. You may be distilling memorised answers straight into your training file. Datasets that grow. Eval was frozen a year ago; train has been appended to weekly by three people since, and nobody re-checked. The pattern: contamination arrives with pipeline changes . That's why a one-off audit doesn't stay true, and why this belongs in CI rather than in a notebook you ran once. Why it's worse than the percentage suggests If 5% of your eval set is contaminated and the model scores near-perfectly on that slice, it can move the headline number by several points — often the same magnitude as the improvement you're trying to demonstrate. Worse, it biases decisions , not just reporting. You pick checkpoints, hyperparameters and data mixes by comparing eval scores. Contamination rewards whichever run memorised more, which is usually

Gone are the hours of careful thought and planning that go into coding a new feature. Vibe coding is too risky though, so another Driven Development was created. I'm referring to SDD (Spec Driven Development) of course. The vibe coding approach is great for prototypes and throwaway code, but this way of working falls apart when teams realise that the code needs to be maintained. So the thing that helps fix this is SDD. Create a spec once from clear technical specs and then generate some high quality code. Sounds great, right. Reminds me of IaC, where you use a templating language to create infrastructure. Software as Code maybe. SaC anyone? Unfortunately, in practice it's not that straightforward. Thoughtworks have placed SDD into an "Assess" category and warned that it could be an anti-pattern for releasing software. Deterministic vs Probabilistic This article isn't about SDD. I'm more interested in discussing the output of SDD and how that is tested. Code can now be generated fast these days. So what better to test AI-written code than with AI itself. There are a lot of concepts and technical terms for the Quality Assurance part of AI generated code. One of these is the LLM-as-a-Judge idea. This idea is used to score the output of an LLM based on some explicit criteria. Traditionally, the way to evaluate an LLM was to judge its output on the helpfulness or faithfulness (using something called "exact-match" metrics). Sometimes it was usually down to a human to do this. It also changes the way that Quality is Assured when dealing with AI-written code. Traditional QA is built on deterministic checks; either something does or does not fail. Something like expect(x).toContainText(y); . A failing test means that something is wrong. Then the bug can be fixed in the code and the test will pass. However, the outputs of an LLM are probabilistic , so it breaks the traditional pass/fail model. This is where a judge comes in. Instead of pass/fail, it can assign a score based o