๐ฌ In plain words:
Because Large Language Models (LLMs) generate probabilistic output, your test suite scores will bounce around slightly even if you haven't touched a single line of code. To find your noise floor, run your exact same test suite three times without making any changes. The mathematical spread between those three scores is your normal variance. If a score change happens inside that spread, it means nothing.
⚡ Key Points
- AI test scores vary naturally; a drop in your score is not always a bug.
- Without measuring your baseline variance (the noise floor), your test scores are uninterpretable.
- Your Continuous Integration (CI) gate threshold must be set just outside the observed spread.
- Always re-measure your noise floor when you add a significant chunk of new test cases to your suite.
๐บ️ Module Map
MODULE 11 root: 'How do you prove it works, repeatably?' ├─ 11.1 Why agent testing is statistical ├─ 11.2 Testing Center and custom evaluations └─ 11.3 The noise floor ๐ (Current)
๐ฌ Real-Life Example: The Regression That Was Not There
The Old/Bad Way: A development team watched their automated test suite drop from a 91% pass rate to an 89% pass rate. Panicking over the "regression," they spent two full days rewriting their subagent descriptions and tweaking prompts trying to fix it.
Why this fails: They had never measured their statistical variance. If they had run three unchanged tests earlier, they would have seen a standard three-point spread in their baseline. The drop to 89% was just normal AI noise. Their two days of firefighting fixed nothing, but accidentally introduced entirely new instruction overlap.
The New/Good Way:
1. Run the completely unchanged suite three times.
2. Record all three scores to find the "spread" (e.g., 91, 89, 92 = 3-point spread).
3. Set your CI/CD regression threshold just outside that spread (e.g., investigate ONLY if it drops below 88).
4. Only investigate when a score actually falls below the threshold.
The Old/Bad Way: A development team watched their automated test suite drop from a 91% pass rate to an 89% pass rate. Panicking over the "regression," they spent two full days rewriting their subagent descriptions and tweaking prompts trying to fix it.
Why this fails: They had never measured their statistical variance. If they had run three unchanged tests earlier, they would have seen a standard three-point spread in their baseline. The drop to 89% was just normal AI noise. Their two days of firefighting fixed nothing, but accidentally introduced entirely new instruction overlap.
The New/Good Way:
1. Run the completely unchanged suite three times.
2. Record all three scores to find the "spread" (e.g., 91, 89, 92 = 3-point spread).
3. Set your CI/CD regression threshold just outside that spread (e.g., investigate ONLY if it drops below 88).
4. Only investigate when a score actually falls below the threshold.
⚙️ Core Concept: Understanding the Spread
When migrating from traditional deterministic software engineering (where 1+1 always equals 2) to AI agent development, accepting variance is the hardest mental hurdle. Here is how you manage it operationally:
- Because LLM output varies by design, test evaluation scores will drift even when absolutely nothing in the system configuration has changed.
- Executing three identical, sequential runs is the most cost-effective and reliable way to measure this baseline variance.
- Inside the spread = Noise. Outside the spread = True Regression.
- Your Continuous Integration (CI) gate must understand this floor. If your spread is 3 points, do not fail a build because of a 1-point drop.
- The noise floor is not static. As your test suite grows, the mathematical variance will change. You must re-measure it periodically.
๐งญ 360 Card — The Noise Floor
Rule: You must mathematically measure your baseline variance before interpreting any test score, and set your deployment gates just outside of it.
Gain: You stop chasing imaginary regressions, saving days of wasted engineering effort.
Price: It requires three extra full suite runs, and each run consumes LLM API credits (Einstein Requests).
Limits: The floor moves as your suite scales up. Re-measure after major additions to your testing scenarios.
Mirror (The Wrong Way): Treating every single percentage drop as a critical regression leads to constant firefighting, developer burnout, and desperate prompt-tweaking that usually degrades overall system stability.
Later: This exact threshold calculation is what your CI/CD pipeline gate will compare against in later deployment modules.
Rule: You must mathematically measure your baseline variance before interpreting any test score, and set your deployment gates just outside of it.
Gain: You stop chasing imaginary regressions, saving days of wasted engineering effort.
Price: It requires three extra full suite runs, and each run consumes LLM API credits (Einstein Requests).
Limits: The floor moves as your suite scales up. Re-measure after major additions to your testing scenarios.
Mirror (The Wrong Way): Treating every single percentage drop as a critical regression leads to constant firefighting, developer burnout, and desperate prompt-tweaking that usually degrades overall system stability.
Later: This exact threshold calculation is what your CI/CD pipeline gate will compare against in later deployment modules.
๐จ INTERVIEW TRAP: Chasing Ghost Bugs
If an interviewer asks, "Your test score dropped by 2%. What is your first troubleshooting step?"
Do not say: "I would immediately check the trace logs to see which prompt failed."
Say: "I would check our noise floor. If our normal variance is 3%, I do absolutely nothing. Chasing a 2% drop without a baseline is chasing a ghost."
If an interviewer asks, "Your test score dropped by 2%. What is your first troubleshooting step?"
Do not say: "I would immediately check the trace logs to see which prompt failed."
Say: "I would check our noise floor. If our normal variance is 3%, I do absolutely nothing. Chasing a 2% drop without a baseline is chasing a ghost."
๐ฃ️ Core Q&A
Q: Your test suite drops from 91% to 89%. Is this a regression or just noise?
๐ฏ Say this first: It depends entirely on the noise floor. Without measuring three unchanged baseline runs, that number is completely uninterpretable.
A: The honest answer is that you cannot answer that question without knowing the baseline variance.
- Because LLM output varies by design, test scores will naturally drift even when zero changes are made.
- To find out if it's a real regression, I run the unchanged suite three times and record the results. The spread between those scores is my noise floor.
- If the three baseline runs varied by three points (e.g., 89, 91, 92), then an 89% score is inside normal variance. I ignore it.
- If the baseline runs varied by only half a point, then a drop to 89% is a genuine regression. At that point, I immediately open the trace logs to find the failing action or subagent.
- By setting the CI/CD gate threshold just outside this calculated spread, I ensure the pipeline fails on real signal, rather than statistical noise.
Q: Does increasing the number of test cases reduce the noise floor?
A: Generally, yes. The Law of Large Numbers applies here. A suite with 10 test cases might have a massive noise floor (e.g., a 10% swing if just one test flips). A suite with 500 well-designed test cases will typically have a much tighter, more predictable noise floor (e.g., a 1-2% swing). This makes larger suites more reliable barometers of true system health.