At LightSight, we've been using DeepEval to evaluate our internal tooling. I wanted to share our thoughts and practices with the tool, and with LLM evaluation in general.
TLDR - Synthetic data at scale is an effective way to pressure-test your LLM-powered applications, but don't make the mistake of relying on it exclusively.
Example DeepEval Workflow
Let's walk through the simplest possible example of using DeepEval - analyzing a "Review Analyzer Assistant" tool, which summarizes Amazon product reviews for a walking treadmill.
Goldens
The very first thing we need to establish is a set of expected answers for different questions. In DeepEval, these are called goldens. Each golden has an input, an expected output, and context (in this case, the actual reviews).
input: "What were the top 3 complaints?" expected_output: "1) Poor setup instructions 2) App required 3) Noisy at high speeds" context: - "Review 1: Love the treadmill but setup was a nightmare..." - "Review 2: Why do I need to download an app just to start walking?..." - "Review 3: Great product, but it gets loud above speed 4..." - "... (50 reviews total)"
The context here should be the ground-truth data, which the system under test should be referencing while producing its response.
Synthesizer
Handwriting all of these is tedious, and often unnecessary (we'll discuss this more later), so we can use DeepEval's synthesizer to automate golden generation from source documents (the source documents are often the same content that goes into the context of a golden).
Test Cases
A test case is a golden + the system's actual response. With our goldens in hand, we run each against our "Review Analyzer Assistant" and fill in the actual_output to retrieve the final test cases.
Metrics & Evaluations
Metrics are the criteria upon which to evaluate your system. DeepEval offers customizable and out-of-the-box metrics: G-Eval, Faithfulness, Answer Relevancy, Hallucination detection, Toxicity and bias checks.
An evaluation is the result of running a test case against your chosen metrics, producing a score, reason, and success/failure result. For simplicity, we'll evaluate against a single G-Eval metric for correctness.
input: "What were the top 3 complaints?"
expected_output: "1) Poor setup instructions 2) App required 3) Noisy at high speeds"
actual_output: "The 3 most frequently cited complaints were 1) App download required 2) Poor first time setup instructions 3) High volume at higher speeds"
metrics:
- Correctness:
score: 0.9
success: true
reason: "The actual output identifies the same 3 complaints as the expected output. Minor ordering difference (app requirement listed first instead of second) does not affect correctness."
There are a variety of other important concepts in DeepEval (like datasets, single-turn vs multi-turn, prompts), but hopefully this gives you an idea of a typical flow.
Can AI Test AI?
DeepEval's synthesizer means you can have an LLM generate test cases, another LLM produce responses, and a third LLM judge those responses. Fully autonomous, without any human in the loop.
I'm reminded of Blade Runner - a bunch of machines pretending to be human and passing judgment on each other.
It's natural to doubt the efficacy of this - hallucination is one of the largest hurdles in this space, and when a single LLM answers a question, it's simultaneously trying to understand the query, retrieve knowledge, reason about it, and generate fluent text.
In an evaluation pipeline, however, each component has a narrow role:
The judge doesn't need world knowledge - it just compares text against provided context. That is a simpler task that LLMs are empirically better at.
There's also an adversarial dynamic:
None of these systems are obligated to make the others look good.
Why Humans Are Still in the Loop
There are a couple of reasons humans still need to be in the loop.
How We Handle It
I prefer the following routine:
Note - our preferred split is 85% synthetic and 15% manually created goldens, but this is arbitrary. Use whatever split works best for your team, but in general more sensitive contexts = higher % of manual goldens.
Takeaways
If you're not already evaluating your LLM systems, you should. When you do, don't be afraid to use synthetic data - it's a great way to test your LLM-powered applications.
Just keep in mind, humans are still essential for:
- Catching problems with the synthetic questions
- Turning production failures into test cases
- Nuanced, deep questions
- Tone/Style