Обзор технологий через призму реальных внедрений в HR-автоматизацию.
Вокруг агентного стека много шума. MCP, LangGraph, RAG, векторные базы — каждую неделю новый «стандарт». Для команды, которая строит продакшен, а не демо, важно другое: что из этого выдерживает корпоративную нагрузку и требования безопасности. Делимся практическим взглядом без хайпа.
RAG (retrieval-augmented generation) часто сводят к «чат с вашими PDF». В HR это работает плохо: ответы расплывчаты, источники теряются. Но RAG полезен иначе — как слой, который подтягивает релевантный контекст к задаче агента: похожие закрытые вакансии, прошлые решения по грейдам, политики компании. Ключ — в качестве индексации. Векторный поиск по сырым текстам даёт мусор; поиск по структурированным узлам с метаданными — точное попадание.
RAG ценен ровно настолько, насколько структурированы данные под ним. Векторная база поверх хаоса возвращает релевантный хаос.
Фреймворки оркестрации агентов решают реальную проблему — управление состоянием в многошаговых процессах с ветвлениями и возвратами к человеку. Но они же добавляют сложность. Наш принцип: оркестрация оправдана там, где процесс действительно недетерминирован (агент сам решает следующий шаг). Для линейных сценариев («скрининг → интервью → оффер») тяжёлый граф избыточен — достаточно простой машины состояний. Не каждый процесс заслуживает автономного агента.
MCP (Model Context Protocol) решает скучную, но важную задачу: как агент единообразно получает доступ к инструментам и данным. Для корпоративного контекста это ценно тем, что отделяет логику агента от интеграций — можно менять источник данных, не переписывая агента. Но MCP не магия: он не делает данные структурированными и не решает вопрос прав доступа. Это транспорт, а не архитектура.
В HR данные чувствительны, и вопрос «куда уходит запрос» — не теоретический. Практичный подход — гибрид: тяжёлые рассуждения на облачных моделях там, где данные обезличены, и локальные модели (через Ollama и подобные) для операций с персональными данными. Архитектура должна позволять маршрутизировать запрос в зависимости от чувствительности — это закладывается на уровне платформы, а не выбирается раз и навсегда.
Технологии — это инструменты, а не решение. Работает не «самый модный фреймворк», а связка: структурированные данные внизу (без них всё остальное бессмысленно), точный RAG как слой контекста, оркестрация только где она оправдана, и гибкая маршрутизация моделей по чувствительности. AIDORS собран именно по этому принципу — стек подобран под задачу, а не задача подогнана под модный стек.