AI-агент рекрутер. Кейс компании LinkedIn
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.