← Latest papers
📈 economics

The Partial Testimony of Logs: Evaluation of Language Model Generation under Confounded Model Choice

This paper proposes and evaluates a three-source framework that combines a small randomized experiment with an offline simulator to identify and correct the selection bias inherent in large-scale observational language model logs, thereby enabling valid causal comparisons of model performance.

Original authors: Jikai Jin, Vasilis Syrgkanis

Published 2026-05-05
📖 5 min read🧠 Deep dive

Original authors: Jikai Jin, Vasilis Syrgkanis

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to figure out which of three chefs makes the best soup. You have a massive notebook of customer reviews from a busy restaurant (the Observational Log, or OBS). However, there's a catch: customers didn't pick a chef at random. They picked the chef they thought was best based on their own mood, hunger, or past experiences.

If you just read the notebook, you might think Chef A is the best because the people who ordered from Chef A were already in a good mood and loved everything. But maybe Chef B is actually better; they just served grumpy customers who were too tired to appreciate the soup. This is confounding: the reason people chose a chef is mixed up with how much they liked the food.

To solve this, you could run a small, strict experiment where you force customers to pick a chef at random (the Randomized Experiment, or EXP). This gives you a fair, unbiased taste test. But running this experiment is expensive and annoying for customers, so you can only do it a few times.

This paper proposes a clever three-part strategy to get the best of both worlds, using a "Kitchen Simulator" as the bridge.

The Three Ingredients

  1. The Big Notebook (OBS): A huge pile of real-world reviews. It's biased, but it has lots of data.
  2. The Small Fair Test (EXP): A tiny pile of reviews where customers were forced to pick randomly. It's unbiased, but it's very small.
  3. The Kitchen Simulator (SIM): A robot that can re-cook the soup. If you tell it, "Chef A made this soup for this specific customer," the robot can instantly generate what Chef A's soup would have looked like, even if the customer never actually ordered it.

The Big Discovery: The "Magic Trick"

The paper's main finding is a mathematical proof (Theorem 1) that says: You don't need the Big Notebook to figure out who is actually the best chef.

Here is the magic trick:

  • The Simulator can show you what every chef would have cooked for any customer.
  • The Small Fair Test tells you exactly how good the soup was in those few random cases.

By combining these two, you can mathematically calculate the true skill of every chef. The Big Notebook (OBS) is not needed to prove who is better; it is only needed later to make your estimate more precise (reducing the "noise" in your answer).

Think of it like this: The Simulator and the Small Fair Test give you the truth. The Big Notebook is just a magnifying glass that helps you see that truth more clearly, but it doesn't create the truth itself.

The Six Ways to Mix the Ingredients

Once you know the truth is recoverable, the paper asks: "How do we use the Big Notebook to help us without getting tricked by its bias?" They tested six different "recipes" (estimators) for mixing the data:

  1. The Pure Experimenter (EXP-Only): Ignores the big notebook entirely. Uses only the small fair test.
    • Pros: Totally unbiased.
    • Cons: Very shaky results if the fair test is too small (high variance).
  2. The Notebook Reader (OBS-Only): Ignores the fair test and just reads the big notebook.
    • Pros: Very stable numbers.
    • Cons: Completely wrong because of the bias (low variance, high bias).
  3. The Translator (Representation-EXP): Uses the big notebook to learn a "language" of what customers like, then uses the small fair test to learn the actual scores in that language.
    • Pros: Good if the notebook's "language" captures the right details.
    • Cons: Fails if the notebook misses the important details.
  4. The Grounded Corrector (Grounded): Starts with the Notebook Reader's answer, then uses the small fair test to "fix" the mistakes.
    • Pros: Great if the notebook is mostly right but has a small systematic error.
  5. The Mixer (CVCI): Blends the Notebook and the Fair Test together, adjusting the mix based on which combination works best in the small fair test.
    • Pros: Often the most balanced approach.
  6. The Residual Mixer (CVCI-Residual): Similar to the Mixer, but first removes the "easy" part of the problem using the notebook, then uses the fair test to fix the "hard" leftovers.

What the Experiments Showed

The authors tested these recipes on two real-world tasks: Summarizing News Articles and Fixing Computer Code.

  • No "One Size Fits All": There is no single winner. Which recipe works best depends on two things:
    1. How much data do you have? If you have very little fair test data, you need to lean heavily on the notebook (but carefully). If you have a lot of fair test data, you can ignore the notebook's bias more easily.
    2. What are you measuring?
      • In the Summarization task, the "Mixer" (CVCI) was usually the best. It balanced the huge amount of notebook data with the small fair test perfectly.
      • In the Coding task, the results changed based on what "success" meant. If success meant "did the code fix the bug?", the notebook-based methods were better. If success meant "is the code style nice?", a different method (Representation-EXP) worked better.

The Bottom Line

When you are evaluating AI models using real-world logs, you can't just trust the numbers because people choose models based on hidden factors.

The paper proves that if you have a Simulator (to re-generate outputs) and a Small Randomized Test (to get fair scores), you can mathematically find the true performance of the models. The massive pile of biased real-world logs is helpful for fine-tuning the answer, but it is not the key to unlocking the truth. The key is the combination of the simulator and the randomized experiment.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →