# Practical Tactics to Build Reliable AI Apps

Dmitry Kuchin, Multinear | AI Engineer World's Fair 2025 | 14:55

Source: https://www.youtube.com/watch?v=-T6uZYYzkWw
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/practical-tactics-to-build-reliable-ai-apps
Published: 2025-08-03
Tags: evals, reliability, testing

## TL;DR
- Reliable AI applications need evaluations built around real user and business outcomes, rather than generic metrics such as factuality or bias.
- Teams should create evaluations at the start of development, inspect individual failures, and rerun them after every change to catch regressions.
- A task-specific benchmark lets teams compare models, prompts, data, retrieval, and agentic or simpler designs with more confidence.

## Summary
Dmitry Kuchin argues that AI projects need a different development process from ordinary software. A proof of concept can work half the time, but the remaining failures are difficult because models are nondeterministic and every change to code, prompts, models, logic, or data can affect results. Kuchin recommends reverse-engineering evaluations from real product scenarios and business outcomes. A customer-support bot, for example, should be judged by whether it answers the specific question with every required detail, or whether users escalate to a human. Teams should build these tests before the application is finished, inspect each failure, and keep rerunning them as the system changes. The resulting benchmark supports comparisons between models, retrieval methods, prompts, databases, and agent designs. The exact evaluation method depends on the application, but the principle stays the same: test the behavior users need, including guardrail cases and regressions.

## Key ideas
### Generic quality metrics do not tell you whether the product works
[02:00](https://www.youtube.com/watch?v=-T6uZYYzkWw&t=120s)
Kuchin says teams often begin with metrics such as groundedness, factuality, and bias because AI development involves experimentation. Those measures may miss the product outcome that matters. For a customer-support bot, he asked an ex-colleague how they knew the system worked and heard about factuality metrics. Kuchin instead identified the rate at which conversations moved from the AI bot to human support. A response can be grounded and factually correct while still failing to give the answer the user expects. Evaluations should therefore come from the product experience and the business outcome, with criteria specific to the task.

### Evaluations should be reverse-engineered from real materials and questions
[04:17](https://www.youtube.com/watch?v=-T6uZYYzkWw&t=257s)
For a bank support bot, Kuchin starts with existing FAQ material, such as instructions for resetting a password. He uses an LLM to generate the user question that the material should answer and to extract the exact criteria required in the response. Those criteria can include receiving a mobile verification code by SMS and contacting support when no mobile number is available. If one required detail is missing, the answer is incorrect. He recommends creating many evaluations that mimic specific user questions instead of relying on a generic score.

### Personas and question variations belong in the test set
[06:52](https://www.youtube.com/watch?v=-T6uZYYzkWw&t=412s)
Kuchin says the same request can be phrased differently by different personas while requiring the same answer. He provides the model with enough context about the personas and uses a model such as o3 to generate evaluation cases. For the password-reset example, a test records the input, the output, and the checklist used to decide whether the answer is correct. The team can then generate about 50 variations of the question and check whether each response still matches the required checklist.

### Teams should write evaluations before they finish the first version
[08:32](https://www.youtube.com/watch?v=-T6uZYYzkWw&t=512s)
Kuchin recommends building the first evaluation set at the beginning of the project. The team creates an initial proof of concept, defines its first tests, runs them, and studies both successful and failed cases. Looking at the individual evaluations can reveal that the test itself is wrong or that the application has a real defect. The team may then change the model, prompt, logic, or source data. The process repeats as the evaluations improve and new cases are added.

### Detailed evaluations catch regressions that average scores hide
[08:54](https://www.youtube.com/watch?v=-T6uZYYzkWw&t=534s)
An average score does not explain how to improve a system, according to Kuchin. A prompt change may fix one case while breaking a case that previously worked. Without evaluations at the case level, the team has no dependable way to catch that regression quickly. After refining the tests, the team has a baseline and benchmark for the current application. That benchmark makes later experiments safer because changes can be checked against known behavior rather than a single aggregate number.

### A benchmark supports controlled choices about models and architecture
[11:02](https://www.youtube.com/watch?v=-T6uZYYzkWw&t=662s)
Once the benchmark is trustworthy, Kuchin says teams can compare models, retrieval methods, and application designs. They can test whether a smaller or different model performs similarly, whether graph retrieval works, whether an agentic design is worth its extra time and inference cost, or whether part of the logic can be simplified. The evaluation design still depends on the application. For text-to-SQL or text-to-graph systems, he recommends a mock database with the same schema and representative data, so expected results are known.

### Guardrail cases need their own entries in the benchmark
[12:57](https://www.youtube.com/watch?v=-T6uZYYzkWw&t=777s)
The same task-specific process applies to guardrails. A customer-support benchmark should include questions the bot must refuse, questions that require a different response, and questions whose answers are absent from the source material. Kuchin treats these as different benchmark cases within the same evaluation process. He closes by arguing that frequent evaluation enables faster progress with fewer regressions. When the tests are defined correctly, the team can explain what the system does and how it behaves on the cases it has chosen to test.

## Notable quotes
- "You can very easily do a POC that works 50% of the time, but making it do the same reliable work the rest of the 50% is very hard." (01:37)
- "The average numbers won't tell you anything. They won't tell you how to improve it." (08:54)
- "You need to evaluate your apps the way your users actually use them." (13:41)
- "The point is in the approach, not in the platform." (07:41)

## Tools & references mentioned
- o3
- Multinear
- Cursor

## Who should watch
- You have an AI proof of concept that works inconsistently and need a way to find the specific failures.
- Your team is comparing prompts, models, retrieval methods, or agent designs and wants to catch regressions after each change.
- You are building support, text-to-SQL, text-to-graph, classification, or guardrail features and need tests tied to actual behavior.

## Related talks

- [How to Run Evals at Scale: Thinking Beyond Accuracy or Similarity](https://aietalks.com/talks/how-to-run-evals-at-scale-thinking-beyond-accuracy-or-similarity) (Muktesh Mishra, Adobe, 09:25)
- [Building and evaluating AI Agents](https://aietalks.com/talks/building-and-evaluating-ai-agents) (Sayash Kapoor, AI Snake Oil, 20:00)
- [Evals Are Not Unit Tests](https://aietalks.com/talks/evals-are-not-unit-tests) (Ido Pesok, Vercel, 15:22)
- [Evals](https://aietalks.com/talks/evals) (Omar Khattab & Vitor Balogh & Rafal Wilinski, Zapier & Ido Pesal, Vercel & Randall, Bolt Foundry & Diego Rodriguez, Krea & Doug Guthrie & Ankur Goyal, Braintrust & Jeff Huber, Chroma & Jason Liu, 567 Studio & John Dickerson, Mozilla AI, 3:59:12)
- [Why (Senior) Engineers Struggle to Build AI Agents](https://aietalks.com/talks/why-senior-engineers-struggle-to-build-ai-agents) (Philipp Schmid, Google DeepMind, 10:40)