By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
Jump to publisher timestampsChapter summaries
Why AI systems need evals (and why building the agent is the easy part)
Aishwarya frames evals as the key skill for making AI products reliable in production, not just getting a prototype working. She previews what the video will cover, including definitions, types of evals, and a full walkthrough.
- •Evals are positioned as the hardest and most misunderstood part of building AI systems for production
- •The goal is to understand what evals are and why they matter
- •The video will cover model vs. product evals, three evaluation approaches, and a hands-on walkthrough
- •Evals are highlighted as a common AI interview topic
What AI evals are: checks for “is the system doing what it was designed to do?”
Evals are defined as checks that determine whether an AI system is meeting its intended behavior. Aishwarya relates this to software testing intuition while emphasizing that AI evaluation differs in important ways.
- •AI evals are evaluations/checks for intended system behavior
- •They resemble testing conceptually, but the testing approach differs for AI products
- •Beginners often confuse evals with traditional software tests
Why AI products can’t be tested like traditional software
Using a typical web app example, Aishwarya explains that traditional software has constrained inputs, predictable outputs, and deterministic code paths, making pre-production testing more reliable. AI products change those assumptions because user inputs are open-ended and models are probabilistic.
- •Traditional apps constrain user actions (buttons, dropdowns) and have well-defined outputs
- •Deterministic code enables the assumption that tested inputs will behave consistently later
- •AI interfaces are free-form, with unbounded user input variety
- •AI model behavior is probabilistic, so outputs can vary even with similar inputs
Silent failures and the evaluation loop: why evals must evolve after launch
Aishwarya notes that AI systems often fail “quietly” by returning confident but incorrect responses, so issues can surface via user reactions rather than error logs. Because real user behavior differs from anticipated behavior, evals must be updated continuously as the product runs in production.
- •Traditional software failures are often loud (exceptions, stack traces); AI failures can be confident and wrong
- •Two major sources of non-determinism: free-form inputs and probabilistic generation
- •Evals aren’t “build once and forget”; they need ongoing updates
- •Process described as a loop: simulate behavior → build evals → observe real usage → improve evals
Model evals vs. product evals: why provider benchmarks don’t answer product performance
Aishwarya addresses why model-provider benchmarks aren’t sufficient for product builders. She distinguishes model evals (generic capability benchmarks) from product evals (performance within a specific ecosystem).
- •Providers publish benchmark results to communicate general model capability
- •Product builders still need their own evals tailored to their environment
- •Model evals and product evals serve different purposes
What model evals and benchmarks measure—and their limits in real ecosystems
Model evals are explained as standardized benchmark datasets with expected outputs and a scoring method based on matches. Aishwarya cites examples of benchmarks and then emphasizes that these tests are generic and don’t reflect a product’s specific policies, tools, knowledge bases, and users.
- •Benchmarks are datasets of inputs paired with expected outputs; scores reflect match rates
- •Examples mentioned include MMLU Pro, SWE-bench, and Arena AI
- •Benchmark results help compare general model capability under standardized conditions
- •Product environments are non-standard and unique, so benchmarks don’t simulate the real setup
How to use product evals: after narrowing models, test within your own system context
Aishwarya explains that model evals can help narrow down model choices, but they shouldn’t be the sole decision factor. Once a model shortlist exists, product builders should run product evals against their own environment and workflows.
- •Model evals can act as a filter for selecting candidate models
- •Product evals test the system in the specific environment being built
- •The need for product evals follows from unique policies, tools, and user behavior
Three ways to build evals: human review, code-based checks, and LLM judges
Aishwarya introduces three common evaluation methods and explains when each is used. Human evaluation provides ground truth; code-based checks are scalable but limited; LLM judges address subjective, language-dependent criteria.
- •Human evaluation is straightforward but unscalable; it sets “ground truth”
- •Code-based checks scale and are deterministic but struggle with nuance
- •LLM judges use an AI model plus rubrics to score outputs on subjective dimensions
- •The latter two aim to approximate human judgment at scale
Code-based evals in practice: pass/fail rules and similarity scores
Code-based checks are broken into two types: objective pass/fail validations and similarity-based scoring metrics. Aishwarya stresses that these methods are deterministic but do not truly understand language context or nuance.
- •Pass/fail checks include schema validation, required fields, citation existence, and label consistency
- •Similarity-based evals (example: BLEU-style overlap) produce a numeric score
- •Determinism: same texts/rules produce the same results every time
- •Limitation: these checks don’t capture nuance or contextual meaning
LLM judges and rubrics: evaluating nuanced criteria like politeness and context
Aishwarya explains LLM judges as models tasked with judging another model’s output using written rubrics. She illustrates why this matters with an example where the same phrase can be polite or curt depending on user context.
- •An LLM judge applies rubrics/criteria to evaluate another system’s output
- •Rubrics should reflect how a human would judge the response
- •Context sensitivity matters (e.g., tone changes depending on user frustration)
- •LLM judges are used when subjective understanding is required
Live walkthrough setup: creating a reference dataset for a support agent eval
Aishwarya begins a walkthrough using a fictional shopping support agent and demonstrates the first step: building a small reference dataset. She describes the minimum columns needed and how the dataset is created based on anticipated user queries.
- •Example use case: customer support agent for an online shopping app
- •Step 1 is assembling a small reference dataset
- •A basic dataset includes user request, the AI’s answer, and a reference (correct) answer
- •Reference data is built by anticipating real user query patterns
Error analysis to find the real issue: identifying missing escalation behavior
Reviewing sample rows, Aishwarya spots a recurring failure mode: the agent doesn’t escalate to humans when it should. She uses this to decide the evaluation dimension to build next: an escalation check.
- •Comparing AI answers to reference answers reveals mismatches
- •Examples show cases where reference expects escalation but the AI suggests self-serve steps
- •Pattern recognition leads to selecting an “escalation” evaluation dimension
- •Error analysis guides what to measure rather than guessing metrics upfront
Writing the escalation rubric and running the LLM judge in Arize
Aishwarya shows how to add an evaluator, choose an LLM judge, and write rubric criteria for when escalation should happen. She runs the evaluator to label each dataset item as correct/incorrect and notes the need for iterative improvement.
- •An evaluator is created as an LLM judge and named for the escalation check
- •Rubrics specify conditions where escalation is required (e.g., anger, swearing, fraud/security scenarios)
- •Outputs are classified into two classes: correct vs. incorrect
- •After running, the system produces a correctness judgment across the dataset; the judge may need refinement
From reference to production: calibration, continuous improvement, and closing takeaways
Aishwarya summarizes the five-step process shown: build a dataset, do error analysis, choose the eval, write rubrics, and run the judge. She emphasizes calibration once real user data arrives and reiterates that evals are an ongoing loop rather than a one-time setup.
- •Five-step workflow recap: reference dataset → error analysis → pick eval → write rubrics → run judge
- •LLM judges are meant to scale human-like judgment, but require calibration
- •After launch, the dataset shifts from reference to production data, requiring continuous updates
- •Evals are positioned as a continuous loop for improving live systems
Publisher timestamps
- 0:00Why AI products can't be tested like normal software
- 4:55Model evals vs. product evals (and why benchmarks like MMLU Pro aren't enough)
- 7:56The three ways to build evals: human, code-based, and LLM judges
- 10:53Live walkthrough: building your first eval in Arize
- 13:31Finding the real problem through error analysis
- 15:30Writing rubrics and running your first LLM judge
