Как проверить AI-навык кандидата: тестовое, критерии и красные флаги

Кандидат показывает AI-помощника. Тот бодро отвечает на вопросы, цитирует документы и даже умеет поддержать беседу. Потом вы спрашиваете: «Что произойдёт, если в базе лежат две версии регламента?» — и уверенность заканчивается раньше, чем демонстрация.

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

Ниже — тестовое на 3–4 часа, общая матрица оценки и короткая защита решения: этого хватает, чтобы увидеть навык.

Красивое демо заканчивается на втором вопросе

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

• откуда модель взяла ответ;

• как система ведёт себя при нехватке данных;

• что происходит с противоречивыми документами;

• кто увидит закрытую информацию;

• как команда заметит ухудшение качества после смены модели или промпта;

• сколько будет стоить тысяча реальных запросов вместо десяти демонстрационных.

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

NIST AI RMF рекомендует тестировать AI-системы до запуска и регулярно после него, документировать наборы проверок и метрики. В документации OpenAI Evals оценка тоже начинается с двух вещей: критериев и набора данных для прогона. На собеседовании важно услышать, опирается ли человек на такую логику.

Тестовое на 3–4 часа: дайте кандидату противоречивую базу

Подойдёт небольшой AI-помощник по внутренним документам компании. Сценарий близок к реальным RAG-задачам и помещается в компактный прототип.

Я бы дал 10–12 синтетических файлов: правила отпуска, инструкцию по технике, порядок согласования командировки, список льгот. В наборе специально оставил бы несколько ловушек:

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

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

Попросите приложить:

• репозиторий без ключей, персональных данных и секретов;

• README с инструкцией запуска и принятыми допущениями;

• набор из 10–15 тестовых вопросов;

• результаты прогона: ответ, источник, статус теста, задержка и расход токенов;

• короткий список ограничений и следующий шаг, если на развитие есть ещё один день.

Обязательны первые три пункта. Замеры и ограничения можно описать в README словами: важно, что кандидат знает, что мерить, а не что успел собрать таблицу за отведённое время.

Лимит в 3–4 часа заставляет выбирать главное. Если задание требует полноценной авторизации, дизайна, деплоя и панели аналитики, вы уже отправили кандидату кусок бэклога. Такой объём стоит оплачивать как отдельную работу.

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

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

Красный флаг: любой сбой лечится новым промптом

Промпт важен, но он не заменяет архитектуру, авторизацию и тестирование. Если на каждый вопрос человек отвечает «добавим ещё одну инструкцию», уточните, где остановится этот документ. Иногда промпт растёт так быстро, что скоро ему понадобятся оглавление и юрист.

Вот пять сигналов, после которых стоит копнуть глубже.

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

2. Права доступа описаны словами для модели. Фраза «не показывай зарплаты обычным сотрудникам» внутри системного промпта не создаёт авторизацию. OWASP прямо предупреждает: системный промпт нельзя считать секретом или механизмом контроля доступа. Разрешённые документы и действия должен ограничивать код до обращения к модели.

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

4. Стоимость начинается и заканчивается ценой модели. В продакшене добавятся эмбеддинги, поиск, хранение, повторные запросы, логи, мониторинг и поддержка — из чего складывается счёт после релиза, мы разбирали отдельно. Финансовый план на три года здесь лишний. Достаточно формулы с допущениями: сколько запросов, какой средний контекст, сколько токенов уходит на ответ и где поставить лимит.

5. Код работает, пока его не просят изменить. Использование AI при выполнении тестового допустимо. Проблема появляется, когда автор не может объяснить функцию, заменить модель, добавить новый тип проверки или найти источник странного поведения. Владение инструментом видно по способности управлять результатом.

На защите попросите кандидата сломать своего бота

На защите откройте решение вместе с кандидатом и задайте вопросы, у которых нет удобного ответа на первом слайде:

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

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

Кого звать на следующий этап

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

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

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