Set up ab testing
Skill ContextJet-ai/awesome-llm-observability/skills/set-up-ab-testing
50+ curated LLM observability tools PLUS 26 Agent Skills (several with runnable, unit-tested scripts) to build, evaluate, debug, secure & monitor reliable LLM apps. Tracing, evals, guardrails, LLMOps.
npx -y skills add ContextJet-ai/awesome-llm-observability --skill set-up-ab-testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
What its author says it does
Copied from the file, not written here
Use this to test an LLM change (new prompt, new model, new retrieval) on real traffic before rolling it out to everyone. Trigger on "A/B test my prompt", "roll out a new model safely", "compare two prompts in production", "canary this change", "does this actually improve things for real users". Measure impact on real users, gated, before a full switch.
The file declares its own license as CC0-1.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.5 KB, 720 tokens by cl100k_base, as published. Nobody here has run it
A/B test LLM changes in production
Offline evals tell you a change should be better; a production experiment tells you it is, on real users and real traffic. For anything user-facing, run a controlled rollout instead of flipping the switch for everyone.
When to use this vs offline evals
- Offline evals (
add-llm-evals): fast, cheap, run in CI, catch regressions before deploy. Do these first, always. - A/B / online experiment: use when the change is user-facing and the offline metric does not fully capture success (helpfulness, engagement, task completion, downstream conversion). Offline says "passes"; A/B says "users actually do better."
Set it up
- Pick one variable. New prompt OR new model OR new retrieval, not all at once, or you cannot attribute the result.
- Define the metric up front. The primary success metric (task completion, thumbs-up rate, downstream action) plus guardrail metrics (cost, latency, error rate) that must not regress. Decide the win condition before you start.
- Split traffic deterministically by user/session (a feature-flag / experiment tool: LaunchDarkly, GrowthBook, or your platform's built-in). Keep a user on one variant for consistency.
- Instrument both arms with the same tracing + online evals + feedback capture (
instrument-llm-observability,collect-user-feedback), tagged with the variant, so every metric is comparable across arms. - Run until it is significant, not until it looks good. Small differences need enough traffic; stopping early on a favorable blip is how you ship noise.
Read the result honestly
- Compare the primary metric across arms and the guardrails (a +2% quality win that doubles cost or latency may not be worth it).
- Watch for novelty effects and segment differences (a change can help new users and hurt power users).
- If it is flat or worse, keep the control. "No worse and cheaper" is still a win.
Safer rollout patterns
- Canary: send 5% to the new variant, watch the dashboards, ramp up if healthy. Good for risky changes.
- Shadow / offline replay: run the new variant on copied traffic without showing users, compare outputs. Zero user risk, no live metric though.
Verify
- Traffic is actually split and each user stays on one arm.
- Both arms emit the same metrics, tagged by variant.
- The decision cites the primary metric + guardrails with enough sample size, not a first-hour blip.
Anti-patterns
- Changing several things at once (you cannot attribute the effect).
- Peeking and stopping the moment it looks good (false positives).
- Measuring only quality, ignoring cost/latency guardrails.
- A/B testing something an offline eval would have caught for free (do offline first).
Grounding
Online controlled experimentation methodology: Kohavi, Tang & Xu, Trustworthy Online Controlled Experiments (2020), and Kohavi et al., Controlled experiments on the web (2009). Applied here with LLM-specific metrics (online LLM-as-judge, Zheng et al. 2023, arXiv:2306.05685) and user feedback (collect-user-feedback).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most test skills give in 720 tokens
Counted across 964 of the 1,571 authors here whose files we hold, read 2026-08-07
- Close the browser when donein 55 of 964, across 12 files
- Wait for network idle statein 51 of 964, across 6 files
- Launch Chromium in headless modein 49 of 964, across 6 files
- Use descriptive selectors for elementsin 49 of 964, across 6 files
- Run provided scripts with help flag firstin 49 of 964, across 6 files
- Add appropriate explicit waitsin 48 of 964, across 5 files
- Use bundled scripts as black boxesin 46 of 964, across 3 files
- Do not read script source codein 46 of 964, across 3 files
- Use sync playwright for scriptsin 46 of 964, across 3 files
- Inspect dom before executing actionsin 46 of 964, across 3 files
- Run the full test suitein 37 of 964
- Write the failing test firstin 29 of 964, across 23 files
Said here and by no other author read
- Run offline evals before production A/B testing
- Define the primary metric before starting
- Split traffic deterministically by user
- Tag all metrics with the variant
- Run the experiment until results are significant
- Keep the control if results are flat or worse
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.