🤖 MCP/LLM для интеграции коллекции собеседований с ботом сообщества

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

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

Однако, ответы на более сложные вопросы по агрегации и анализу коллекции через поиск уже не получить:

• “Дай ссылки на java-собесы, где обсуждались интеграции с сервисами оплаты/платежей”
• “Найди собесы, в которых спрашивают про orm, hibernate, jpa, jdbc в рамках опыта работы”
• “Что спрашивают по межсервисному взаимодействию?”
• “Среди вопросов по брокерам, про что спрашивают чаще, Kafka или RabbitMQ?”
• “Дай топ 10 вопросов по легенде среди Python собесов”

Напрашивается решение, основанное на LLM. Задача - дать языковой модели доступ к базе собесов, чтобы она могла отвечать на вопросы по базе собесов и таймкодов. Интегрировать это с ботом сообщества.

К чему у бота есть доступ

• 600 собесов
• Атрибуты собеса - название компании, тип собеседования (скрининг, техническое, финал), язык (русский, английский, …), язык программирования, результат, сумма оффера, теги
• Для каждого собеса - список вопросов
• Атрибуты вопроса - текст, таймкод, теги

Примеры работы

Бот доступен для всех участников сообщества в чате @zhukovsd_it_chat.

Пример промпта - /ai технические собесы на java.

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

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

Вопрос:

Дай ссылки на java-собесы, где обсуждались интеграции с сервисами оплаты/платежей.

Ответ:

Нашёл несколько java-собесов, где явно всплывали интеграции с оплатой/платежами:

• %Company Name 1% — обсуждалась интеграция с системой оплаты https://t.me/c/********/****

• %Company Name 2% — по вопросам видно, что кандидат работал с платежами/платёжной архитектурой https://t.me/c/********/****

• %Company Name 3% — есть кейс про платёжный запрос и идемпотентность https://t.me/c/********/****

• %Company Name 4% — прямо упоминается вопрос про платежи: https://t.me/c/********/****

Если кратко, самое прямое попадание — %Company Name 1%, там буквально есть вопрос: «Как интегрировалась система оплаты?»

Вопрос:

Среди вопросов по брокерам, про что спрашивают чаще, Kafka или RabbitMQ?

Ответ:

По этой выборке чаще спрашивают про Kafka.

Если считать интервью, где среди категорий встречается тема:

• Kafka — примерно 49 интервью

• RabbitMQ — примерно 32 интервью

То есть Kafka встречается где-то в 1.5 раза чаще.

По самим формулировкам тоже видно, что частый паттерн вопросов — это: • “Kafka vs RabbitMQ”

• “Почему выбрали Kafka, а не RabbitMQ?”

• “В чем архитектурное отличие Kafka и RabbitMQ?”

Вывод: если готовиться по брокерам в первую очередь, приоритет — Kafka, но сравнение Kafka vs RabbitMQ тоже очень часто спрашивают.

Вопрос:

Какие вопросы про CI/CD и Kubernetes задают чаще всего?

Ответ:

По записям интервью (в выборке 82 интервью, где встречались категории CI/CD и/или Kubernetes) чаще всего повторяются такие формулировки/темы:

CI/CD — что спрашивают чаще всего • Опыт и участие в CI/CD

• «Опыт с CI/CD?»

• «На каком уровне работал с CI/CD?»

• «Разработчики участвуют в процессах CI/CD?»

• «Кто отвечал за развёртывание CI/CD?»

• «Как устроен CI/CD-пайплайн на проекте»

• «CI/CD. Как устроена инфраструктура, стенды?»

• «Инструменты CI/CD (что именно использовали)»

• «С какими инструментами CI/CD ты работал?»

• «В гите CI/CD настроен?» / «Почему не использовали GitLab CI/CD?»

• «Использовали линтеры, встраивали в CI/CD?»

Kubernetes — что спрашивают чаще всего

• «Вообще есть ли опыт с Kubernetes»

• «Опыт K8s?»

• «K8s знаешь/работал с ним?»

• «Используете Kubernetes?»

• «Базовые сущности и компоненты Kubernetes

• «Основные компоненты k8s»

• «Что такое Pod/Deployment?»

• «Какими сущностями оперирует K8s?»

• «Разница между deployment и service?»

Как деплоили/разворачивали приложение в K8s (практика)

• «Опишите как должно разворачиваться приложение в k8s»

• «Как можно задеплоить в K8s, какие шаги?»

• «Писал манифесты deployment/service?»

Архитектура решения

Основные компоненты:

• Телеграм бот на Python, с клиентом к LLM от OpenAI
• MCP сервер на Golang, с PostgreSQL базой, где лежат собесы и таймкоды. MCP - “REST API” для LLM моделей. Тулы (tools) MCP сервера (аналоги эндпоинтов в REST API) позволяют модели запрашивать у MCP сервера данные и исполнять действия
• Датасет (набор данных) в Google Spreadsheets. Туда люди, ответственные за пополнение коллекции собеседований, заносят собесы и вопросы с таймкодами. Датасет в таблице синхронизируется с SQL базой MCP сервера
• Админка на app script поверх Google Spreadsheet

Обработка запроса юзера, пошагово:

• Запрос в чате /ai технические собесы в сбер на Java
• Telegram бот обрабатывает команду, открывает сессию к OpenAI API (мы используем модели GPT 5.2 и 5.4). В сессии указан наш MCP сервер и его тулы
• LLM модель понимает, что ей нужно получить собесы с фильтром по названию компании, находит в списке тулов MCP нужный тул со списком параметров
• LLM модель вызывает тул, MCP сервер превращает аргументы запроса к SQL запрос (условно, WHERE company_name = "сбер"). Ответ на запрос к MCP тулу - JSON
• LLM модель формирует человекочитаемый текст на основе полученного JSON, бот отправляет его в чат

Ответ:

Нашёл в базе 66 технических собеседований в Сбер/СберТех/дочках на Java (язык: русский). Ниже — список с датами и ссылками на записи.

• 2024-10-16 — Сбер — https://t.me/c/********/****/****

• 2024-06-20 — Сбер (оффер, 230000) — https://t.me/c/********/****/****

• 2024-05-31 — Сбер (оффер, 250000) — https://t.me/c/********/****/****

…

Шаги в виде sequence диаграммы:

Тегирование

Самый большой челлендж данного проекта - тегирование вопросов. Если пользователь спрашивает “дай вопросы про Kubernetes”, нерационально делать фильтрацию вопросов на стороне модели. Ей придётся запросить у MCP все 23 тысячи вопросов, что приведёт к переполнению контента. Поэтому, фильтрация происходит на стороне MCP.

Однако, необходимо, чтобы было по чему тегировать. Самое очевидное решение - искать вхождение определённого слова в формулировку вопроса. Но далеко не всегда подходящий тег встречается в теге вопроса. Пример - “Расскажите про композитные индексы”. Теги вопроса “SQL, базы данных”, и оба этих тега не встречаются в формулировке.

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

Первый - по подстроке. Ищем в формулировках вопроса сроки из набора, и если нашлась хотя бы одна - ставим тег. Пример:

• Название категории “Дженерики”.
• Подстроки - “дженерики, generics, стирание типов, PECS, type erasure”

Второй механизм - KNN (k-nearest neighbors). Модель проставляет теги для тех категорий вопросов, где не обойтись подстроками.

Самый яркий пример - вопросы по опыту. Они слишком разнообразны, один и тот же вопрос можно задать разными словами.

На вход KNN модели подаётся категория с примерами вопросов, на выходе - вероятности принадлежности каждого вопроса из базы данной категории. Если пороговое значение превышено - выставляем тег.

Борьба с переполнением контекста

Одна из болей проекта - переполнение контекста. Если модель загрузит в контент слишком много вопросов, контекст переполнится и ответа на промпт не будет.

Основная часть связанных с этим проблем была решена тегированием и фильтрацией вопросов на стороне MCP, но всё-равно возможно задать слишком “общие” вопросы, которые уронят контекст.

Наше решение:

• Исполняем промпт в GPT 5.2 с контекстным окном 400к токенов
• Если получили переполнение контекста - пробуем GPT 5.4 с окном 1М токенов
• Если всё равно получили переполнение контекста - добавляем в конец промпта “рассмотри последние 50 собесов”

Сколько стоит эксплуатация проекта

• VPS за 10 евро в месяц для хостинга бота, MCP, KNN модели
• Токены для OpenAI - ~1-2 цента за запрос