Как собрать evaluation dataset для LLM-ассистента

Коротко

Evaluation dataset — зафиксированный набор входов, ожидаемых свойств ответа и контекста, на котором можно сравнивать версии системы.

Материал относится к полке «AI и машинное обучение» и построен вокруг рабочего решения: сначала определить объект и границы расчёта, затем проверить пример и только после этого выбирать инструмент или метрику.

• Назови вопрос до того, как открывать дашборд или писать запрос.
• Зафиксируй единицу наблюдения, период и знаменатель.
• Проверь результат на маленьком наборе с известным ответом.
• Отделяй факт в данных от гипотезы о причине.

Какой вопрос решает материал

Как проверить, что ассистент стал лучше, а не просто красиво отвечает на демо-вопросы?

Без набора задач команда оценивает модель впечатлением. После изменения prompt или retrieval невозможно понять, какие сценарии улучшились, а какие сломались.

Для support нужны обычные вопросы, неоднозначные формулировки, отсутствие ответа, конфликтующие документы и запросы вне области.

Определение и зерно расчёта

Одна строка результата должна описывать одну сущность и один период. Перед агрегацией проверь, что исходные строки не повторяют объект и что фильтры не меняют знаменатель незаметно.

Собери реальные обезличенные кейсы, добавь метки сложности, эталон или rubric и раздели набор на development и holdout.

Если показатель строится по событиям, отдельно проверь повторную отправку, идентичность пользователя и часовой пояс. Если данные приходят из бизнес-системы, сопоставь техническое поле с тем, как команда реально принимает решение.

Рабочий пример

Для support нужны обычные вопросы, неоднозначные формулировки, отсутствие ответа, конфликтующие документы и запросы вне области.

Не копируй пример в рабочий отчёт вслепую. Сначала замени названия таблиц и полей, проверь кардинальность связей и запиши, какие строки должны попасть в результат. Хорошая адаптация сохраняет логику, но делает допущения видимыми.

Как читать результат

Evaluation должен быть частью релиза: новая версия проходит regression suite до публикации.

Результат полезен только в контексте baseline, размера объекта и действия после сигнала. Одна цифра без периода и сравнения выглядит убедительно, но не отвечает на вопрос, стало ли решение лучше.

Для ревью оставь короткую запись: что измерено, на каких данных, какая проверка пройдена, что остаётся неизвестным и какое наблюдение должно изменить следующий шаг.

Где расчёт ломается

Слишком маленький набор, оценка только fluency, утечка тестовых вопросов в prompt и отсутствие проверки цитат.

Отдельно протестируй пустой результат, NULL, дубль, граничную дату и объект без связанной записи. Эти случаи не являются редкими исключениями: именно они чаще всего превращают рабочий показатель в красивую, но неверную цифру.

• Не смешивай зрелые и незрелые периоды без отдельной подписи.
• Не заменяй проверку качества тем, что запрос просто выполнился.
• Не делай причинный вывод из одного разреза.

Визуальная проверка

График здесь нужен не для украшения статьи. Он помогает увидеть форму сигнала: тренд, разрыв между сегментами, хвост распределения или этап, на котором теряется объект. Сначала прочитай оси и единицы, затем сравни с таблицей и только после этого формулируй вывод.

На визуализации «Как собрать evaluation dataset для LLM-ассистента» сравнивай не только максимальное значение. Проверь, одинаковы ли базы, не скрыта ли неполная дата и не меняется ли знаменатель от категории к категории.

Мини-практика

Сделай 30 кейсов в пяти категориях и опиши, кто и по какой шкале оценивает ответ.

После упражнения напиши вывод в двух версиях. Первая — техническая: какие строки и условия дали результат. Вторая — для команды: что изменилось, насколько это надёжно и какое действие стоит проверить. Если эти версии противоречат друг другу, вернись к определению показателя.

• Собери контрольный пример из пяти-десяти строк.
• Сверь итог с независимым способом расчёта.
• Проверь хотя бы один крайний случай.
• Зафиксируй дату, версию схемы и ограничение.

Контрольные сценарии

Проверь не только обычный путь. Добавь пустую группу, повторную строку, объект без связанного факта, значение на границе периода и неполный текущий день. Для каждого случая заранее запиши ожидаемое поведение: ноль, NULL, исключение или отдельный статус. Такой набор превращает разовую проверку в маленький контракт расчёта.

Если материал связан с пользователями, отдельно проверь повторное действие одного человека. Если он связан с деньгами, добавь возврат, скидку и нулевую сумму. Если он связан со временем, протестируй полночь, timezone и запоздалую запись. Эти тесты не занимают много времени, но ловят ошибки, которые обычная строка почти никогда не показывает.

После изменения схемы или определения запусти прежний контрольный пример снова. Сравни не только финальное число, но и промежуточный grain, количество уникальных ключей и долю исключённых строк. Если число изменилось, должно быть понятно, какая именно договорённость это объясняет.

Когда выбрать другой подход

Не каждый вопрос стоит решать тем же инструментом. Если нужен быстрый обзор, достаточно таблицы и одной декомпозиции. Если важна воспроизводимость, вынеси логику в SQL или Python. Если нужен причинный вывод, добавь эксперимент или квазиэксперимент, а не усложняй описательный график.

Команда может выбрать другой метод, когда меняются стоимость ошибки, скорость обновления, доступность данных или требование к аудиту. Это не отменяет текущий расчёт, а помогает не выдавать удобный инструмент за универсальный.

Как передать результат

Рабочее сообщение должно начинаться с ответа, а не с истории всех попыток. Напиши, что изменилось, на какой базе это видно, какой размер эффекта и какое ограничение нужно учитывать. Затем добавь ссылку на запрос, notebook или карточку метрики, чтобы коллега мог проверить расчёт без устного экскурса.

Если результат требует действия, назови owner и момент пересмотра. «Проверить mobile checkout до пятницы» полезнее, чем «обратить внимание на конверсию». Если данных пока недостаточно, сформулируй следующий сбор: какое событие, какой период или какой эксперимент закроет неопределённость.

Хороший аналитический артефакт сохраняет контекст: дату обновления, источник, версию определения, размер выборки и известные исключения. Это снижает стоимость повторного анализа и помогает отличить изменение продукта от изменения расчёта.

Как довести расчёт до рабочего процесса

Начни с маленького контрольного запроса или notebook, где видны исходные фильтры, зерно и промежуточные строки. Сверь его с ручным примером и только затем переноси логику в дашборд, витрину или регулярную задачу. Так ошибка находится до того, как на её основе появится решение.

Перед публикацией договорись, кто отвечает за определение и кто проверяет свежесть данных. Зафиксируй ожидаемый диапазон, допустимую задержку и сигнал, при котором расчёт нужно остановить. Для сложной метрики полезно хранить версию SQL и дату последнего пересмотра рядом с описанием.

После запуска смотри не только на итоговое значение. Контролируй количество строк, долю NULL, долю исключений и размер ключевых сегментов. Если эти показатели резко меняются, сначала проверяй загрузку и схему, а не объясняй скачок поведением пользователей.

• Один контрольный пример с известным ответом.
• Владелец определения и владелец данных.
• Порог свежести и допустимый диапазон.
• Лог изменений, SQL или notebook в одном месте.

Чеклист перед публикацией

Перед тем как отправить материал, число или график коллегам, пройди короткую проверку. Если один пункт пока неизвестен, запиши его ограничением, а не прячь под нейтральным названием.

• Понятно ли, что является строкой результата?
• Названы ли период, timezone, фильтры и знаменатель?
• Есть ли проверка на дубли, NULL и пустые группы?
• Сравнивается ли результат с baseline или сегментом?
• Понятно ли, какое решение поддерживает показатель?
• Есть ли следующий шаг, если сигнал подтвердится?

Вывод

Evaluation должен быть частью релиза: новая версия проходит regression suite до публикации.

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