LLM-агент против SerpApi: что лучше работает для поиска публичных резюме

В одном из проектов нам нужно было показать клиенту, как может работать система поиска и нормализации публичных данных о кандидатах. Задача была не просто “найти людей”, а собрать структурированную выборку из разных источников: поисковой выдачи, публичных резюме, профессиональных профилей, GitHub/GitLab и других открытых источников, где можно получить полезные сигналы о человеке, его роли и рабочем стеке.

Отдельное пожелание клиента было связано с Google и Bing: клиент прямо обозначил, что хотел бы увидеть поиск резюме через обычную поисковую выдачу. Поэтому в пилот мы включили SerpApi как один из основных способов сбора первичных результатов.

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

Во время разработки стало понятно, что поисковый слой и браузерный LLM-агент работают по совершенно разным правилам.

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

Но именно это становится его ограничением.

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

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

Третья проблема — избыточность. На раннем этапе нам не всегда нужно читать всю страницу. Часто достаточно понять, что в выдаче есть человек с нужной ролью, стеком, компанией, регионом или ссылкой на резюме. Для этого не обязательно открывать каждый результат.

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

SerpApi в такой архитектуре используется не как “скрапер сайтов”, а как интерфейс к поисковой выдаче. Система отправляет запросы в Google или Bing и получает структурированные результаты:

• ссылку на документ или профиль;
• заголовок страницы;
• сниппет;
• позицию в поисковой выдаче;
• дополнительные признаки результата.

Это оказалось полезно по простой причине: для первичного отбора часть нужного сигнала уже лежит в выдаче. В заголовке или сниппете может быть указана роль, компания, стек, регион, ссылка на резюме, GitHub-профиль, личный сайт или профессиональный профиль. На этом этапе нам не обязательно открывать саму страницу, чтобы понять, что результат потенциально релевантен.

Например, если мы ищем Python-разработчиков с опытом FastAPI и PostgreSQL, поисковая выдача уже может показать документы или профили, где эти слова встречаются рядом с именем, ролью или описанием опыта. Если мы ищем ML-инженеров с Computer Vision, то в сниппете часто видны PyTorch, OpenCV, detection, segmentation, research или похожие технические маркеры.

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

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

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

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

Для поиска документов можно использовать комбинации роли, технологий, региона, слов resume/CV и типов файлов. Но сам по себе найденный документ ещё не является готовым результатом. Его нужно скачать, извлечь текст, определить структуру, найти ключевые поля и привести всё к единому формату.

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

В упрощенном виде пайплайн выглядел так:

1. Система получает описание искомого кандидата или документа.
2. Формирует поисковые запросы и обращения к API.
3. Собирает результаты из Google, Bing, GitHub, GitLab и других источников.
4. Приводит данные к единому формату.
5. Объединяет дубли и рассчитывает релевантность.
6. Передает клиенту уже готовую выборку.

В результате клиент получает не “вот тысяча ссылок, разбирайтесь”, а очищенную выборку: кто найден, почему он релевантен, из каких источников это следует и насколько система уверена в результате.

Один и тот же человек может одновременно встретиться в поисковой выдаче, на GitHub, GitLab, в PDF-резюме и на личном сайте. Без дедупликации итоговая таблица быстро превращается в набор повторов.

Поэтому система сравнивает URL, имя, username, работодателя, стек и другие признаки, объединяя совпадающие записи в одну карточку кандидата.

При обработке тысячи релевантных кандидатов таким образом удалось объединить 581 дублирующуюся запись. Для клиента такая очистка важна не меньше, чем сам поиск: вручную разбирать сотни повторов почти так же неприятно, как искать кандидатов с нуля.

Главный вывод пилота был не в том, что LLM-агенты бесполезны. Наоборот, LLM хорошо подходит для задач, где нужно понять смысл найденного результата.

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

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

В этой задаче было важно сразу задать границы. Мы не строили систему, которая заходит за логин, обходит CAPTCHA, имитирует действия пользователя на защищённых платформах или пытается вытащить данные из закрытых областей сайтов.

Пилот был построен вокруг публично доступных источников: поисковой выдачи, открытых документов, публичных технических профилей и API. Это немного снижает “волшебство” решения, зато делает его более предсказуемым и пригодным для реального использования.

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

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

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

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