Back to Bytes

Build ContaminationDetector with LLM probing — lab audio overview

2026-04-21

Build a ContaminationDetector class that analyzes recorded probe transcripts - the expected answer for each evaluation test case paired with the text a model returned for it - and decides deterministically which cases look contaminated. You implement text normalization, n-gram overlap scoring, per-p

GenAI Platform Engineering › GenAI Evaluation, Safety & Governance › Chapter 1 · Evaluation Dataset Curation › Detect dataset contamination and leakage

4:49
Build a ContaminationDetector class that analyzes recorded probe transcripts - the expected answer for each evaluation test case paired with the text a model returned for it - and decides deterministically which cases look contaminated. You implement text normalization, n-gram overlap scoring, per-p
Share

More from this chapter

Transcript
Host: Welcome back. You're in GenAI Evaluation, Safety and Governance — a course about making sure the AI systems your organization ships actually work, stay safe, and follow the rules. This chapter is about curating evaluation datasets — the test questions you use to grade a model. And today's skill — spotting when a model has secretly memorized your test — is something every evaluation team runs into the moment they move past demos. Expert: Let me paint the scenario. Imagine you're on a five-person platform team at a mid-sized insurance company. You've spent weeks building a careful set of test questions — say, five hundred real customer scenarios with the ideal answers written by your domain experts. You run your new model against this test set, and it scores ninety-four percent. Everyone celebrates. You ship it. Two weeks in, customer complaints start rolling in. The model is hallucinating on live traffic. How? Because the test set you used — or something very close to it — was scraped off the public internet years ago and ended up in the training data of the model you were evaluating. The model didn't understand the questions. It remembered the answers. That's called data contamination, and it silently inflates every evaluation number you report to leadership. If you don't check for it, you're flying blind. The skill you're about to build is the first line of defense against this — a way to ask a model, point blank, "have you seen this before?" Host: So this is lab one of three in this chapter — your starting point. The chapter overview walked through the big picture of evaluation datasets. Now let's get specific. What exactly will we build? Expert: You're going to build a contamination detector — a small piece of code that takes each question from your evaluation set, sends it to a hosted language model, and checks whether the model's answer looks suspiciously close to the reference answer you already have on file. You'll probe two models in particular — OpenAI's GPT-4o and Google's Gemini Pro — and you'll reach them through what we call a proxy URL, which is just a web address your organization routes requests through so it can manage keys and track usage centrally. Now here's the key idea, the conceptual aha. A model that has genuinely learned general skills will paraphrase, restructure, maybe get the gist right but use different words. A model that has memorized your test will reproduce the expected answer almost verbatim — same phrasing, same numbers, same examples. So you're not asking "did the model get it right." You're asking "did the model get it right in a way that looks like it's reading from a memory of the exact text." That distinction is everything. One is learning. The other is cheating on the test, and it tells you this test case is burned and needs to be thrown out or rewritten. Host: Before you start, what's the one thing that trips people up here? Expert: The biggest trap is treating this like a pass-fail check. People write it so that if the model's output matches the expected answer closely, the detector screams "contaminated." But real answers naturally overlap sometimes — there's often only one right way to say "the deductible is five hundred dollars." So you don't want a hard yes-or-no. You want a signal — a score, a confidence level, and ideally the raw text from both models side by side so a human can judge. Also, watch your error handling. You're calling two external services over the network. They will time out. They will rate-limit you. Build in retries with a short wait between attempts, and make sure one failing request doesn't kill the whole run. Log which cases failed so you can come back to them. Host: And to close — what will you walk away able to do? Expert: After this exercise, you'll be able to take any evaluation dataset your team maintains and produce a contamination risk report for it — a list of which test cases look compromised on which models, with the evidence attached. That's a building block your team can plug directly into your existing evaluation pipeline, and it's the kind of control that governance and compliance reviewers increasingly ask about. Next, in exercise two, you'll extend this work by implementing a specific way of measuring how much two pieces of text overlap — a classic technique based on finding the longest sequence of words that appears in the same order in both texts. That gives your detector a real numeric score instead of a gut feeling. And exercise three ties it all together into a workflow that quarantines the suspicious cases automatically. For now, focus on getting clean, reliable probes out to both models and capturing what comes back. Good luck, and thanks for listening.

Want to go deeper? Explore disciplines with hands-on labs, quizzes, and chapter podcasts.