Битрикс24 рассказал, как построил eval и автоматизировал оптимизацию RAG-агента Марты

Команда Битрикс24 опубликовала вторую часть технического разбора RAG-системы для AI-помощника Марты. Первая была про retrieval-пайплайн и поиск по базе знаний. Теперь — о том, как измерять качество всей цепочки целиком, почему отдельных retrieval-метрик недостаточно и как автоматизировать цикл экспериментов, чтобы каждое изменение можно было проверить системно.

Retrieval-метрики обманывают

Классические метрики поиска — precision, recall, MRR — показывают, насколько точно система находит нужные документы. Но они не отвечают на главный вопрос: получил ли пользователь полезный ответ? Разработчики Битрикс24 столкнулись с типичной ловушкой production RAG: retrieval-показатели росли от эксперимента к эксперименту, но реальное качество ответов Марты улучшалось непропорционально — а иногда и вовсе не улучшалось. Retrieval и generation — разные звенья одной цепочки. Улучшение поиска не гарантирует улучшение финального ответа. Решение — сквозная eval-система, которая оценивает итоговый ответ, видимый пользователю, а не только промежуточный результат поиска.

Два типа датасетов

Основа системы оценки — два датасета с принципиально разными характеристиками: Экспертный датасет — вопросы и эталонные ответы, написанные вручную специалистами, хорошо знающими продукт. Точный и надёжный: если система ошибается здесь, проблема очевидна. Минус — дорого создавать, сложно масштабировать. Синтетический датасет — пары вопрос-ответ, автоматически сгенерированные на основе продуктовой документации. Создаётся быстро и в большом объёме, но требует фильтрации: LLM-генерация неизбежно вносит шум и артефакты. Оба датасета работают в связке. Экспертный закрывает критически важные сценарии, синтетический покрывает длинный хвост запросов, до которого вручную не добраться. Такая комбинация даёт более полную картину качества, чем любой из подходов по отдельности.

Замкнутая петля оптимизации

Ключевой практический результат второй части — автоматизация цикла экспериментов. Раньше каждое изменение в retrieval pipeline требовало ручной проверки: запустить eval, собрать цифры, сравнить с предыдущей версией, принять решение. Медленно, субъективно и неудобно масштабируется. Новая система замыкает петлю: изменение попадает в pipeline автоматически запускается eval на обоих датасетах метрики сравниваются с baseline регрессии фиксируются немедленно и не уходят в прод * история экспериментов накапливается в структурированном виде По сути, это CI/CD для качества ответов. Каждый эксперимент оставляет след, команда видит, какие решения работают системно, а не случайно. Это особенно важно, когда RAG-пайплайн состоит из нескольких взаимозависимых компонентов.

Когда метрики расходятся

Одно из ключевых наблюдений статьи: retrieval-метрики и метрики качества финального ответа могут двигаться в разные стороны — и это нормально. Более точный поиск иногда возвращает документы, которые технически релевантны, но не помогают LLM сформулировать хороший ответ: слишком длинные, слишком технические или дублирующие друг друга. Наоборот, менее агрессивный retrieval иногда даёт лучший результат, потому что контекст получается компактнее и чище для генерации.

«Production RAG — это постоянная работа с retrieval, шумом и latency».

Финальная картина качества — это всегда несколько метрик в связке. Ориентироваться только на одну — значит оптимизировать не то.

Что это значит

Опыт Битрикс24 показывает, как выглядит зрелый подход к production RAG: не «запустили и надеемся», а системная работа с датасетами, сквозными метриками и автоматизированным eval-циклом. Такой процесс превращает оптимизацию из серии интуитивных догадок в управляемую инженерную дисциплину — с воспроизводимыми экспериментами и понятной историей решений.