AI-тренажёр собеседований: от вакансии до честного отчёта

Задача

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

Такой продукт держится на доверии. Вопрос должен звучать уместно для вакансии. Оценка должна совпадать с тем, что реально посчитал backend. Пример сильного ответа не должен выдумывать опыт кандидата.

Я собирал проект сразу по нескольким слоям: frontend, backend API, голосовой ввод, отчёт, промпты, проверка моделей и визуальное совпадение с макетом.

Что я собрал

На backend-стороне я собрал API-контур из пяти эндпоинтов.

/api/context разбирает вакансию и резюме в структурированный профиль. /api/questions генерирует вопросы без повторов. /api/evaluate оценивает один ответ по пяти критериям. /api/session собирает итоговый отчёт. /api/transcribe переводит аудио в текст, чтобы пользователь мог тренироваться голосом.

Внутри backend есть строгие Zod-схемы, серверный пересчёт score по breakdown, CORS под нужный фронт, защита загрузки вакансий от небезопасных URL, rate-limit, структурные логи, промпты с env-override и отдельные smoke-скрипты.

На frontend-стороне я собрал webapp-флоу: стартовую форму с вакансией и резюме, список сессий, экран вопроса, голосовой и текстовый ответ, карточку фидбека, повторную попытку, финальный отчёт, лимитные модалки, шапку интервью и переходы из расширения.

Отдельно я довёл extension-контур: popup, handoff в webapp, rating links, production build, locale-файлы для 12 языков и проверку, что расширение не ломается без удалённого конфига.

Где отчёт терял доверие

Во время браузерного прогона выяснилось, что backend отдаёт точные оценки 62, 51, 47, 65, 42, а frontend показывает 60, 50, 50, 70, 40. Для пользователя это мелочь только на вид. На самом деле он видит не ту обратную связь, которую посчитала система.

Вторая проблема была в финальном отчёте. Он показывал общий readiness score, а разбивка по пяти критериям могла превращаться в ровный шаблон 20/20/20/20/20. Такой отчёт выглядит уверенно, но не объясняет, почему кандидат получил именно такой результат.

Я поправил путь данных так, чтобы интерфейс хранил score в шкале 0-100, передавал breakdown в финальный отчёт и не рисовал фейковую разбивку. После проверки отчёт показывал readiness 54, оценки 62/51/47/65/42 и реальный breakdown 12/13/9/10/10.

Как проверял AI-качество

Одной модели тут мало. Нужно было понять, где проблема в модели, где в промптах, где во фронтовом отображении, а где в самом продукте.

Для этого была собрана матрица качества моделей. Один и тот же сценарий прогонялся через разные связки моделей и промптов. В журнал сохранялись системные и user-промпты, ответы кандидата, сырой ответ модели, распарсенный JSON, токены, примерная стоимость, длительность шагов, score и итоговый report.

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

Отдельно проверялись thinking и grounding-варианты. Grounding оставлен только как гипотеза для генерации вопросов, потому что при оценке ответа модель должна судить кандидата по вакансии и его словам, а не по внешнему контексту.

Что изменилось в продукте

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

Визуально я довёл продукт ближе к макету: стартовую форму, экран вопроса, feedback-карточки, report summary, progress list, limit popup, extension handoff и мобильные состояния. Отдельные тексты лоадеров и подсказок были переписаны так, чтобы интерфейс звучал спокойнее и не создавал ощущение технического черновика.

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

Когда нужен такой контур

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

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

Результат

Я собрал рабочий full-stack контур AI-интервьюера: backend API, frontend-флоу, голосовой ответ, итоговый отчёт, extension-сценарий, локализацию и модельную диагностику.

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

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

Нужен AI-продукт, где модель работает внутри проверяемого пользовательского сценария? Такой проект стоит начинать с контракта данных, качества фидбека и полного прогона глазами пользователя.