11 docs tagged with "evaluation"

A trace tells you one run went wrong. A dataset lets you check whether a prompt or model change made things better or worse across many runs at once — the LLM equivalent of a regression test suite.

A classifier has a right answer to check against. A generative model's output has no correct answer at all — "is this a good generated cat image" has no ground truth to compare against, only a distribution to compare against. Every metric in this page is a different proxy for that comparison, and every proxy can be gamed.

The hardest part of working with language models isn't building one — it's knowing, with any confidence, whether the new version is actually better. There's no single number that captures "good," and the real skill in evaluation is knowing each imperfect proxy's specific blind spot well enough to know when it's lying to you.

Recommender evaluation is unusually treacherous: the offline metric is computed on data generated by a previous model, the ranking metrics disagree with each other, and the correlation between offline improvement and online business impact is famously weak.

Accuracy is the wrong metric more often than it is the right one. A model that predicts "healthy" for every patient in a dataset where 99% of patients are healthy scores 99% accuracy while being completely useless. Picking the right metric means picking it from the cost of each error type, not from convention.

Regression metrics all try to say "how close were the predictions" in a single number, but they disagree about what "close" means — and that disagreement matters exactly when outliers are present or when comparing models. Knowing which metric lies to you in which situation is the actual skill.

99% of your rows are one class, and accuracy just became a lie. Imbalance is best understood as a metric-and-threshold problem before it's a sampling problem — fixing evaluation costs nothing and should always come first, and often it turns out to be the only fix actually needed.

One aggregate number hides every failure that matters. A model at 94% accuracy can be failing badly on a 5% subgroup, systematically wrong in a specific, predictable direction, or actively worse than the model it's replacing on the exact cases that matter most — none of which a single headline metric will ever reveal.

The offline metric improved, and the business metric did not. This gap is common enough to expect it as the default outcome, not a surprising exception — offline metrics are proxies, and only a genuine online experiment measures the thing actually being optimised for.

The test set is spent the moment you make a decision based on it. If you tune a hyperparameter, pick a model, or even decide "let's try one more architecture" after looking at test performance, that number is no longer an honest estimate of how the model will do on truly new data. The validation set exists specifically to absorb those decisions so the test set can stay clean.

Every evaluation rule you learned for i.i.d. data is wrong here. Random k-fold cross-validation on a time series does not measure forecasting ability at all — it measures interpolation, and it reports a number far better than anything you will see in production.