1Quick Recap
| Model Eval | App Eval |
|---|
| Evaluates | The LLM itself | App built on models |
| Method | Benchmarks (reasoning, coding...) | Does the app do its job? |
As an AI engineer you'll spend far more time on app evals than model evals.
2Why Multiple Pipelines?
One app can have multiple failure points and multiple risk categories — one eval is never enough.
- Reason 1 — components/workflows can fail independently.
- Reason 2 — correct ≠ safe ≠ cheap ≠ fast; each is a separate risk.
3RAG Example: Failure Points
Query→
Retriever→
Vector DB→
Docs→
Generator→
Answer
- Retriever fail — wrong/irrelevant docs returned.
- Generator fail — ignores context or hallucinates.
4Component-Level Eval
Retriever: given a query, does it return the correct, relevant docs?
Groundedness/Faithfulness: the generated answer must be supported by the given context — no invented extras.
5Workflow-Level Eval
Retriever ✓ + Generator ✓ ≠ Workflow ✓. Independently-correct components can still combine into a wrong output.
Component-level correctness ≠ workflow-level correctness.
6Worked Failure: K=5 Retrieval
Correct doc (D5) is retrieved within top-5 → retriever "passed." But generator prioritizes higher-ranked D1–D4, which mention a different course's duration → wrong final answer.
Lesson: retriever correct, generator correct, workflow still wrong — ranking mattered.
Fix: add a reranker to reorder docs (D5 → rank 1) before generation.
7Application-Level Eval
Retriever ✓, Generator ✓, Workflow ✓ — still not guaranteed production-ready.
Example: correct answers but 10s latency per query = unacceptable UX.
Latency
TTFT
Cost/request
Token efficiency
Error rate
Load performance
8Three Failure Levels
ApplicationHigh latency/cost/error rate, poor load handling, bad UX
WorkflowRAG retrieve+generate, agent plan+act, multi-turn chat
ComponentPrompt, retriever, reranker, embeddings, vector DB, parser, tool selector, memory, guardrails
Evaluation must cover all three — Component → Workflow → Application.
9Three Risk Categories
Application Quality
Safety
Operations
A correct answer can still fail on safety or be too slow/expensive to ship.
10Application Quality Risks
- Correctness/accuracy — factually right?
- Relevance — addresses the actual query?
- Completeness — covers everything asked?
- Instruction following — format/length/structure honored?
11RAG-Specific Risks
| Context Relevance | Retrieved docs relevant? |
| Retriever Recall | Got the needed info? |
| Groundedness | Answer based on context? |
| Faithfulness | No invented facts? |
| Citation Accuracy | Cited sources actually support claims? |
Retrieval quality = right info found. Groundedness = answer actually used it.
12Agent-Specific Risks
- Tool selection — right tool for the job?
- Parameter correctness — right args passed?
- Task completion — did it finish the task?
- Error recovery — handles failures gracefully?
Eval isn't just the final answer — also the decisions/actions along the way.
13Multi-Turn Chatbot Risks
- Context retention — remembers earlier turns correctly?
- Clarification behavior — asks instead of guessing on ambiguity?
14Safety Risks
A factually correct answer can still be unacceptable if unsafe (e.g. leaking another user's PII).
Toxicity
Harmful content
Bias
Privacy/PII leak
Prompt injection
Jailbreak
15Operational Risks
| Latency | Response time |
| TTFT | Time to first token |
| Cost/request | $ per query |
| Token efficiency | Tokens used well? |
| Error rate | Failure frequency |
| Latency under load | Stays fast at scale? |
16Combined Framework
| Level | Quality | Safety | Ops |
|---|
| Component | Retriever relevance, faithfulness, tool select | Injection, unsafe tool use | Component latency |
| Workflow | E2E correctness, groundedness | Safety across steps | Workflow latency/cost |
| App | Correctness, relevance, completeness | Toxicity, bias, privacy, jailbreak | Latency, cost, reliability, scale |
17Building the Pipelines
App→
Find Failure Points→
Find Risk Categories→
Build Evals→
Measure & Improve
One RAG app can carry: retriever relevance, retriever recall, reranker, groundedness, faithfulness, citation accuracy, E2E workflow, safety, latency, cost, error-rate evals — all at once.
18Key Takeaways
- Component-level pass ≠ workflow-level pass.
- Workflow-level pass ≠ production-ready application.
- Three failure levels: Component → Workflow → Application.
- Three risk categories: Quality, Safety, Operations.
- A correct-but-unsafe or correct-but-slow answer is still a failure.
- 99.99% of serious LLM apps need >1 eval pipeline.
- Only build evals tied to a real, meaningful failure point or risk.
19Final Mental Model
- Find the failure points.
- Identify the risk categories.
- Evaluate individual components.
- Evaluate component interaction (workflow).
- Evaluate the complete application.
- Continuously monitor quality, safety & operations.