Dscout: Почему исследователи должны возглавить AI-оценки

Опубликованная в январе 2026 года в блоге People Nerds на Dscout, эта статья Натана Рейффа — старшего UX-исследователя и продакт-менеджера в Dscout — утверждает, что сейчас наиболее важное место для применения навыков исследователей — не изучение пользователей AI-продуктов, а оценка самих AI-систем. Пока команды торопятся выпускать AI-функции, Рейфф доказывает: исследователи, включённые в процесс оценки на раннем этапе, способны предотвратить серьёзные провалы, которые автоматические метрики просто не обнаружат.

Аргумент

AI-оценки — в инженерной среде их чаще называют «evals» — обычно включают три метода: человеческие оценки, оценки по принципу LLM-as-a-judge и автоматические code-based оценки. Каждый из них измеряет, насколько точными, полезными или безопасными являются выходные данные AI-системы. Большинство команд воспринимают это как сугубо технические задачи. Рейфф оспаривает этот подход.

Человеческие оценки требуют от оценщика читать или слушать выходные данные AI и оценивать их качество — задача, которая кажется простой, но требует именно тех навыков, которые исследователи используют ежедневно: распознавать, когда ответ технически точен, но контекстуально вводит в заблуждение; выявлять граничные случаи, выходящие за пределы обучающей выборки; формулировать критерии, отражающие то, что пользователям действительно нужно от системы. Инженеры эффективно пишут code-based тесты, но им часто сложно определить, что означает «качество» с точки зрения пользователя.

Связь оценок и UX-исследований

Статья предлагает исследователям рассматривать evals как мост, а не отдельную дисциплину. Исследователь, встроенный в AI-команду, может начать с человеческих оценок на ранних этапах разработки модели, собирая качественные сигналы о том, какие выходные данные «не работают» и почему. Этот сигнал затем ложится в основу критериев для систем LLM-as-a-judge и в итоге для структурированных датасетов в code-based оценке. Такая последовательность переводит исследовательскую функцию из позиции «потребителя» выходных данных модели в позицию того, кто формирует её поведение.

Рейфф прямо говорит о том, почему это важно за пределами качества отдельного продукта: команды, воспринимающие AI-функции как инженерные результаты, а не пользовательский опыт, создают системы, которые работают корректно по внутренним метрикам, но разочаровывают или вводят в заблуждение пользователей. Исследователь в роли того, кого Рейфф называет «доброжелательным диктатором» на ранних этапах оценки, может изменить этот вектор до того, как это станет дорогостоящим.

Кому это полезно

Статья наиболее ценна для UX-исследователей, которые чувствуют себя маргинализированными в циклах AI-разработки: их привлекают уже после принятия решений, просят тестировать продукты, а не формировать их. Рейфф предлагает конкретную точку входа: запросить участие в процессах оценки, пусть и неформально, и продемонстрировать, чем исследовательские критерии отличаются от инженерных. Для руководителей исследовательских команд статья даёт аргументацию для встраивания исследователей в AI-команды с самого начала разработки модели, а не на этапе пользовательского тестирования.

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