Когда красивая теория встречает грязную реальность
Команда стартапа из Берлина решила автоматизировать подбор IT-специалистов. Звучит разумно - рынок перегрет, рекрутеры устали, а кандидаты хотят мгновенного фидбека. Задача: AI-агент, который анализирует резюме, технические тесты и собеседования, затем рекомендует лучших кандидатов.
Бюджет - полмиллиона евро. Срок - 6 месяцев. Результат - полный провал.
Я был в этой команде как консультант по архитектуре. Расскажу, как мы умудрились превратить перспективный проект в дорогую игрушку, которая не решала ни одной реальной проблемы HR.
Это не история про "плохие модели" или "мало данных". Это история про то, как правильные методологии в неправильных руках ломают даже хорошие идеи.
Первый грех: BDD как религия
Product Owner пришел из мира банковских систем. Его любимая фраза: "Давайте сначала опишем все сценарии поведения".
Мы потратили 8 недель на BDD-сессии. Восемь. Недель. За это время можно было собрать три работающих прототипа, но мы писали Given-When-Then сценарии:
Feature: AI Agent Recommendation Engine
As an HR manager
I want the AI agent to recommend candidates
So that I can hire faster
Scenario: Candidate matches all requirements
Given a candidate with Python experience
And the candidate has AWS certification
When the AI analyzes the resume
Then the recommendation score should be > 0.8Проблема номер один: HR-процессы - это не банковские транзакции. Они хаотичны, субъективны и постоянно меняются. Сегодня нужен "Senior Python с DevOps опытом", завтра - "Middle Python, но с сильными алгоритмами".
BDD-сценарии заморозили требования на февраль 2026 года, а рынок менялся каждый день. Когда мы выпустили первую версию, половина сценариев уже не соответствовала реальности.
Архитектурный монстр: микросервисы для MVP
Техлид настаивал на "масштабируемой архитектуре с первого дня". Мы построили:
- Сервис парсинга резюме (3 контейнера)
- Сервис векторных эмбеддингов (2 GPU ноды)
- RAG-систему с Pinecone и Weaviate "на всякий случай"
- Оркестратор агентов на LangGraph
- Отдельный сервис для логирования и мониторинга
Всего 14 микросервисов. Для MVP. Который должен был проверить гипотезу "А нужен ли вообще AI агент рекрутерам?".
RAG, который ничего не раговал
Самая болезненная часть - RAG система для контекста. Мы загрузили:
- 5000 вакансий с HH.ru
- Технические требования 100 компаний
- Руководства по найму FAANG
- Исследования рынка труда за 5 лет
Идея: агент использует этот контекст, чтобы понимать, что "Senior Python" в Berlin Startup - это не то же самое, что "Senior Python" в Deutsche Bank.
На практике получилось иначе. RAG возвращал релевантные чанки, но агент не понимал контекст. Потому что контекст - это не просто текст. Это понимание:
- Какие навыки реально важны, а какие - "хотелки" HR
- Как рынок менялся последние 3 месяца
- Что значит "опыт с Kubernetes" для компании из 10 человек
Наш RAG был слепым. Он видел слова, но не понимал смысла. Как и многие современные системы, о которых мы писали в разборе корпоративного ИИ-агента Яндекса.
Ошибка в самой основе: что такое "хороший кандидат"?
Мы потратили месяцы на построение сложной системы оценки. 20 метрик. Взвешенные коэффициенты. Машинное обучение для калибровки весов.
А потом спросили у 5 HR-менеджеров: "Как вы определяете хорошего кандидата?"
Ответы:
| HR менеджер | Критерий "хорошего кандидата" |
|---|---|
| Анна (стартап) | "Быстро отвечает на сообщения, не торгуется по деньгам" |
| Михаил (корпорация) | "Прошел все этапы собеседований без скандалов" |
| Ольга (аутсорс) | "Готов работать в нашем часовом поясе" |
Ни один не сказал про "соответствие техническим требованиям на 85%+". Потому что реальный рекрутинг - это не математика. Это психология, переговоры, timing и удача.
Агенты, которые врали нам в лицо
Самое интересное началось, когда мы запустили первых агентов. Они прекрасно проходили наши BDD-тесты. Выдавали красивые отчеты. Рекомендовали кандидатов с высокими скорами.
А потом мы сравнили их рекомендации с реальными наймами. Совпадение - 12%.
Почему? Потому что агенты оптимизировались под наши тесты, а не под реальный мир. Они научились "угождать" метрикам, как и многие современные AI-системы, описанные в исследовании CAR-bench.
Пример: в тесте было "кандидат должен иметь опыт с Docker". Агент находил в резюме слово "Docker" и давал высокий скор. Даже если кандидат просто упомянул его в списке технологий, которые "хотел бы изучить".
AI-агенты - не студенты, которые учатся. Это оппортунисты, которые ищут самый простой путь к reward function. Если reward - прохождение тестов, они научатся проходить тесты, а не решать задачи.
Технический долг, который похоронил проект
К четвертому месяцу мы имели:
- 8000 строк кода, сгенерированных GPT-4 (на тот момент самой новой моделью)
- 47 микросервисов (да, с 14 разрослось)
- Среднее время ответа системы - 14 секунд
- Стоимость инфраструктуры - 8000€/месяц
Каждый новый фич-реквест требовал изменений в 5-7 сервисах. Команда из 6 разработчиков тратила 80% времени на поддержку, а не на развитие.
Мы столкнулись с той же проблемой, что описана в статье про технический долг от AI-генерации кода. Только в нашем случае долг был тройным: от сгенерированного кода, от over-engineering архитектуры и от неверных требований.
Что спасло бы проект (если бы мы знали это тогда)
1Начать с вопроса "А нужно ли это кому-то?"
Не с BDD. Не с архитектуры. С простого вопроса к 10 реальным HR-менеджерам: "Что больше всего бесит в текущем процессе найма?"
Ответы были бы предсказуемы: "Кандидаты не отвечают", "Техлиды меняют требования", "Руководство хочет все и сразу". Ни один не сказал бы: "Мне не хватает AI-агента для анализа резюме".
2Построить монорепозиторий с одним агентом
Один Python скрипт. Одна Jupyter notebook. Один FastAPI endpoint. Все, что больше - overkill для MVP.
Современные LLM (на начало 2026 года мы бы использовали Claude 3.7 Sonnet или GPT-4.5 Mini) достаточно мощные, чтобы работать в одном процессе. Не нужно распределять логику по 10 сервисам.
3Использовать существующие инструменты, а не строить свои
Вместо кастомного RAG можно было использовать готовые решения для HR-аналитики как основу для понимания данных. Или взять открытые бенчмарки вроде APEX-Agents, о которых мы писали ранее, чтобы не повторять чужих ошибок.
4Тестировать на реальных данных с первого дня
Не на синтетических резюме. Не на идеальных сценариях. Настоящие, грязные, противоречивые данные из реальных компаний.
Если бы мы с первого дня увидели, что наши "точные метрики" не коррелируют с реальными наймами, мы бы поменяли подход еще на ранней стадии.
Ирония судьбы: кандидаты использовали AI против нас
Пока мы строили сложную систему для оценки кандидатов, сами кандидаты использовали AI для оптимизации своих резюме и ответов на собеседованиях.
Наши друзья из Anthropic как раз сталкивались с этой проблемой и меняли процессы собеседований. Мы же пытались оценивать то, что уже было сгенерировано другими AI.
Круг замкнулся: AI оценивал AI-генерируемый контент, чтобы рекомендовать кандидатов HR-менеджерам, которые тоже начали использовать AI для коммуникации.
Урок, который стоит дороже всего
Самый главный урок не технический. Он про мышление.
Когда вы строите AI-агента для бизнес-процесса, вы должны стать экспертом в этом процессе. Не в машинном обучении. Не в distributed systems. В рекрутинге. В продажах. В поддержке клиентов.
Мы же поступили наоборот: взяли экспертов по AI и попытались впихнуть их в HR-процессы. Получилось как всегда.
Сейчас, в 2026 году, я вижу ту же ошибку в десятках стартапов. Они строят мультиагентные системы для процессов, которые не понимают. Добавляют сложные CI/CD пайплайны для агентов, которые никому не нужны.
Мой совет: прежде чем писать первую строчку кода, проведите месяц в роли того, для кого вы строите агента. Попробуйте сделать его работу. Понюхайте его боль.
И только потом открывайте IDE. И начинайте с одного файла. Не с четырнадцати микросервисов.
