AI Onboarding Buddy. Как собрать ИИ-агента для адаптации новых сотрудников в компании

Всем привет! Продолжаю делиться кейсами, где действительно ИИ экономит время, ресурсы, а значит деньги бизнеса. Сегодня в статье разберу ещё один кейс внедрения ИИ-агента в бизнес-процессы, речь пойдёт про онбординг новых сотрудников. Если среди вас есть HR, не стесняйтесь, делитесь, а как у вас проходит адаптация новых сотрудников, какие механики используете?

В статье будем разбирать ИИ-агента для IT-компании, в целом он применим для всего сектора бизнеса. Просто будут отличаться те или иные документы, знания агента.

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

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

А бизнес в это время теряет деньги, точнее недополучает, потому что эффективность такого сотрудника крайне низкая, хотя он может быть и хочет пользу больше дать, но у него на этом этапе много барьеров. По каждому вопросу надо спрашивать, а бывает времени нет у руководителя. Получается, в среднем в компании на эффективность сотрудник выходит после 3 месяцев, а то и после 4–5.

А как сделать личного Buddy (наставника) каждому новому сотруднику при этом не увеличивая штат? Давайте разбираться, как можно это построить, сколько денег потребуется, какие нужны мощности, разберём ограничения и инвестиции. Немного расскажу ещё про эффективность таких ИИ-наставников в конце.

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

---

Выявляем боли новичка

Боли ^[1] уже известны в компании всем, начиная от руководителей, заканчивая IT-поддержкой. Зайдёте к HR, они вам расскажут. А если вы хотите сделать действительно крутой ИИ-продукт, а не просто ИИ в бизнес внедрить, то я рекомендую провести интервью с новичками из разных отделов.

Глобально есть 3 категории запросов новичка. Я категоризировал их так:

1. «Где это вообще?»
   Информация существует, но найти её невозможно. Часть в Confluence, часть в Telegram, часть у разработчика где-то в каком-то потоке от полугода назад, часть кто-то написал в email и забыл скинуть в общую папку. Новичок не знает, куда смотреть, и тратит полдня на поиск того, что можно было бы узнать за минуту. И ведь информация точно есть, просто она размазана по разным местам.

2. «А это вообще к мне относится?»
   Даже если человек нашёл нужный документ, не всегда понятно, применимо ли оно именно к нему. Например, процесс получения доступа или процесс постановки задач, да что угодно. Документ написан общим языком, а ситуация у каждого конкретная.

3. «С кого вообще начать?»
   Есть задачи, которые вообще нельзя решить по документам. «Как подключиться к проекту X?», «Кто у нас в команде отвечает за Y?». Здесь нужен живой человек, и новичок не всегда понимает, кого именно спросить, чтобы не тратить чужое время зря.

Раз мы уж затронули тему с интервью, давайте и гипотезу сформулируем, мы же продукт делаем.

Если мы создадим ИИ-наставника, который собирает всю базу знаний компании в одном месте, помогает и отвечает на все вопросы новичков с учётом роли и должности, обучает внутренней документации, то снизим количество повторяющихся вопросов к HR минимум на 80% и сократим среднее время на онбоардинг.

---

Как работает ИИ-наставник

Новичок в первый рабочий день в Telegram получает приветственное сообщение от бота, где у него есть мини-инструкции и персональный план адаптации для своей роли.

Каждый пункт чеклиста это не просто текст, а ссылка на материалы: документы, видео, презентации. Материалы могут быть созданы заранее или сгенерированы автоматически через сервисы типа Notebook LM (об этом подробнее ниже).

Telegram бота мы выбрали потому что он бесплатный, не нужно делать UI и у всех он есть. Вы можете выбрать корпоративный чат или любой другой интерфейс, где ночиок будет общаться с ИИ-наставником

А теперь Архитектура

У нас два отдельных процесса:

1. Пайплайн 1: База занний для ИИ-наставника
   Фоновый процесс, обновляет базу знаний. Работает по расписанию или по триггеру (webhook), независимо от того, задаёт новичок вопросы или нет. То есть следит за тем, чтобы у ИИ-агента всегда были актуальные знания.

2. Пайплайн 2: Runtime (сам ИИ–наставник)
   Сам агент, который управлет оркестрирует всей системой, то есть отвечает на вопросы, ищет документы и т.д

   Будем разбирать каждый пайплайн отдельно и компоненты.

---

Пайплайн 1: База занний для ИИ-наставника

Пайплайн можно построить на фреймворках агентских (LangChain, LlamaIndex и другие) или упростить себе жизнь и собрать на n8n + Docker. Всё очень просто настраивается, нужно 3–4 часа, чтобы всё это протестировать, проверить и прогнать. Напишите мне в Telegram ^[2], если нужна консультация.

1. Компонент: Откуда берём данные

   Нужны подключения ко всем системам, где есть информация. Например, это Confluence и HR-система (где-то это 1С). Везде есть API, если есть API, уже хорошо. По источникам данных я разберу Confluence как наиболее часто встречающийся инструмент хранения данных, но описания будут применимы и к другим системам, где есть API.
   У Confluence есть API, по которому мы будем получать данные. Confluence отдаёт в HTML, и нам нужно извлекать текст, но надо будет ещё и картинки (схемы), презентации тоже распаршивать.
   Для извлечения текста, парсинга документов, таблиц, изображений будем использовать библиотеку dedoc ^[3] бесплатная, работает отлично. Поддерживает PDF, Word, PowerPoint, HTML и другие форматы.

   Получается, первый шаг: мы делаем по апи запрос и получаем документы из источников, а после эти документы преврашаем в обычный текст.

   Обновление данных: настраиваем webhook в Confluence, который триггерится при изменении страницы. Webhook посылает event подтягиваем только изменённую страницу. Если webhook не работает делаем обновление по таймеру.

2. Компонент: Парсинг и OCR

   Dedoc справляется с большинством форматов: PDF, Word, PowerPoint, HTML. Извлекает текст, таблицы, сохраняет структуру документа.
   Но есть данные, где текст на изображениях (скриншоты, схемы, графики). Для этого нужен OCR (Optical Character Recognition).

   Модели для OCR:
   Dolphin ^[4] Качественный OCR, работает с русским, можно развернуть локально. Бесплатный.
   LlamaParse Платный сервис, но точный. Хорошо работает с таблицами, схемами. Через API.
   DeepSeek-OCR: https://huggingface.co/deepseek-ai/DeepSeek-OCR
   ^[5]Недавно вышла модель от DeepSeek, можно развернуть локально. Хорошо с русским.

   Все это мы делаем, чтобы векторизовать, то есть собрать базу знаний в LLM понимаемый формат.

3. Компонент: Чанкинг (разбиение на куски)
   Что такое чанкинг? Чанкинг это деление на куски большого документа, делается это потому что документ нельзя просто целиком превратить в вектор. Слишком размытый вектор, нерелевантные результаты. Нужно разбить на чанки (куски). А векторы нам нужны чтоб ИИ-агент мог праивльно овтечтьа на вопросы наших пользвоателей, то есть искать (быстро) и находить релевантные ответы.

   Логика ^[6] чанкинга:
   Разбиваем документ по смыслу, а не просто по количеству слов. Используем semantic chunking через LlamaIndex. Модель анализирует текст и определяет границы смысловых блоков.

   Параметры:
   Размер чанка: 300–400 слов
   Overlap (перекрытие): 50–80 слов

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

   Почему LlamaIndex? Потому что у них есть готовые инструменты для semantic chunking. Можете чанкинг делать и другими инструментами.

4. Компонент: Создание метаданных

   4.1 Для каждого чанка создаём метаданные:

   Автоматические метаданные (берём из документа):

   id – генерируем уникальный (например, chunk_12345)

   source – откуда взяли ("confluence")

   url – ссылка на документ

   title – название документа

   last_updated – дата обновления

   Enrichment (дополнительные метаданные через LLM ) после чанкинга отправляем в LLM модель: «Определи отдел, роль, тему». Модель заполняет метаданные, которые мы не могли определить автоматически.

   Пример:
   {
"source": "confluence",
"title": "Процесс согласования командировок",
"url": "https://company.atlassian.net/wiki/HR/12345",
^[7] "department": "all",
"roles": ["all"],
"last_updated": "2025-11-15",
"validity_date": null,
"tags": ["командировки", "согласование"],
"file_type": "confluence_page"
}
Добавляем эти метаданные к чанку. И храним в векторной БД векторы +метаданные.

5. Компонент: Векторизация
   Превращаем текст в векторы (эмбединги). От качества эмбеддингов напрямую зависит качество поиска.
   Русский язык морфологически богат. Например: слово «командировка» может быть в шести формах: командировка, командировки, командировке, командировку, командировкой, о командировке. Плюс «командировочный», «командировочные». Эмбединговая модель должна понимать, что все формы семантически близки.

   Модель для эмбеддингов:
   BAAI/bge-m3 ^[8] моя рекомендация для production. Размерность 1024, генерирует dense (похоже по смыслу) и sparse (похожие по словам) векторы из одной модели (для гибридного поиска). Один из лучших по бенчмаркам MTEB. Работает локально.

6. Компонент: Векторная база данных (Qdrant)
   Настройка векторной БД я использую distance=Distance.COSINE – косинусное сходство. Для русского критично, игнорирует длину текста, ищет по смыслу

Супер, с первым пайплайном закончили. У нас получилось, что каждый раз когда обновляется наша база знаний в Confluence или где-то ещё, запускается пайплайн и обновляет запись в Базе знаний агента, либо обогащает, либо стирает предыдущую статью и перезаписывает. Плюсы такого пайплайна в том, что мы не векторизируем каждый раз полностью базу знаний, а обновляем только те куски, которые обновились. Экономия денег и ресурсов.

---

Пайплайн 2: Сам ИИ-агент наставник

Давайте сначала спроектируем и разработаем этого ИИ-агента. Кстати, такого ИИ-агента можно собрать и на n8n, с условием что некоторые функции и tools будут написаны и развёрнуты в Docker, а n8n мы будем просто вызывать функцию. Я писал выше, если нужна будет консультация, велком ко мне в Telegram.

Что нужно для агента

• LLM модель – локальная или облачная. Тут решите сами, если облачную, настоятельно рекомендую сделать маскирование данных.

• Векторная база данных – она у нас уже есть из Пайплайна 1, готова с данными.

• Чеклисты для профессий – набор данных, которые должен знать сотрудник на этой позиции. У нас уже есть из Пайплайна 1, храним в PostgreSQL.

• Telegram-бот – интерфейс для общения.

• NotebookLM или другой инструмент – который будет интерактивные обучающие курсы создавать. Если у вас уже есть эти интерактивные курсы, то просто держим ссылки на курсы в таблице по профессиям в БД (не векторная, а реляционная). Опциональный компонент.

• LangGraph – фреймворк для сборки этого агента. Ну, если хотите, напишите код весь руками.

Компонент 1: LLM модель

Если облако кажется, тут всё предельно понятно, не будем тратить буквы, не казённые же)) Выбирайте любую которую захотите. Кстати, GigaChat, Alisa AI вполне справляются с задачами, поэтому не вижу смысла ходить в GPT-подобные модели.
Критично: если берёте облако, делайте маскирование данных. Перед отправкой в API заменяйте все имена, фамилии, названия проектов на placeholder. Иначе рискуете утечкой.

Если локально, я буду, кстати, брать модель, которая наделала шума: glm-4.7-flash:latest. ^[9]
Для ИИ-наставника хватит вполне даже модели на 7B параметров. Как выбрать лучшую модель, рассказал в тут ^[10].

Развёртывание локальной LLM модели: Ollama vs vLLM

Хочу с вами вот о чём поговорить, о развёртывании локальных LLM-моделей. Давайте рассмотрим сегодня 2 способа: Ollama и vLLM.

Ollama – способ запустить локально модель без особых усилий в 2–3 команды. Принцип такой, что скачали модель, запустили, работает. Ollama хороша как «быстрый старт» для локального запуска моделей: поставить, скачать, дёрнуть API, показать прототип, дать команде поиграться.

vLLM – это решение для serving LLM. Оптимизировано для высокой нагрузки (много запросов одновременно), поддерживает батчинг, снижает latency.

Что это вообще значит? Если мы при равных условиях на машине с GPU через Ollama запустим модель, то проиграем по производительности, потому что vLLM может утилизировать ресурсы с большей эффективностью. То есть одновременно обрабатывать несколько запросов, делать батчинг (пакетная обработка), эффективно использовать KV-cache.

Ollama обычно упирается в то, что она не выжимает максимум из железа. В реальности это выглядит так: модель отвечает, всё работает, но стоимость одного токена становится выше, а задержки под нагрузкой растут быстрее, чем должны.

Короче, берите в продакшн vLLM. А то часто вижу в проде Ollama и то, что ресурсы уже на пределе. Дальше не идём в техничку, на этом остановились. Договорились, что в проде будем разворачивать с помощью vLLM. И всё, модель готова работать.

Компонент 2: LangGraph (оркестрация агента)

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

Компонент 3: Tools (инструменты агента)

Tools это функции, которые агент может вызвать. У нас будет 2 tool.

1. search_knowledge_base

2. escalate_to_human

search_knowledge_base – ищет информацию в векторной базе знаний. Это вот часть RAGа.

Как работает:

1. Получает запрос от агента. Например: «получение доступа к Jira».

2. Векторизует запрос через BGE-M3 (генерирует dense и sparse векторы).

3. Делает гибридный поиск в Qdrant:

   1. Dense search (векторный поиск) – ищет семантически похожие чанки

   2. Sparse search (BM25) – ищет по ключевым словам

   3. Объединяет результаты через Reciprocal Rank Fusion

   4. Фильтрует по метаданным (department, role пользователя)

   5. Возвращает топ-20 кандидатов

4. Multi-query generation если скоры низкие, генерирует 2–3 варианта запроса через LLM и ищет по каждому. Объединяет результаты, убирает дубликаты по ID. (я нижу разберу этот шаг поиска данных чуть детальнее)

5. Re-ranking: топ-20 кандидатов пропускает через bge-reranker-v2-m3. Получает более точные скоры релевантности. Выбирает топ-5.

6. Возвращает результат агенту: топ-5 чанков с текстом, метаданными (url, title, source) и скорами.

Multi-query generation что за это такое?.
Например: пользователь пишет короткие запросы: «VPN», «Jira», «командировки». Такие короткие запросы плохо работают с векторным поиском. Нужно расширить.

Multi-query generation генерируем несколько вариантов запроса через LLM.

Исходный запрос: «VPN»

LLM генерирует 3 варианта:

1. «Как настроить VPN для удалённого доступа к корпоративной сети»

2. «Процесс получения VPN-ключа для подключения к серверам компании»

3. «Инструкция по установке VPN-клиента на рабочий компьютер»

Зачем multi-query? Потому что один короткий запрос может пропустить нужный документ. А если ищем по трём вариантам, шансы найти релевантное выше. Потом делаем поиск по каждому варианту, объединяем результаты, убираем дубликаты по ID, делаем re-ranking.

Давайте в догонку еще разберем и гибридный поиск:

Dense search (векторный) – отлично находит семантически похожие. «Как согласовать командировку» – «процесс одобрения поездки». Но плох с точными терминами. «Что такое OKR?» может вернуть не про OKR.

Sparse search (BM25) – keyword-поиск. Плох для семантики, идеален для специфических терминов.

Hybrid search – объединяем оба. Qdrant поддерживает через sparse_vectors. А наша эмбединговая модель BGE-M3 умеет генерирвоатьdense и sparse из одной модели.

results = client.query_points(
    collection_name="knowledge_base",
    prefetch=[
        Prefetch(query=dense_vector, using="dense", limit=20),
        Prefetch(query=sparse_vector, using="sparse", limit=20)
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=10
)

fusion=Fusion.RRF – Reciprocal Rank Fusion. Взвешивает результаты из двух поисков.

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

Если и этого вам в процессе разработки не хватило, то мы доавбляем еще и Re-ranking (перерранжирование).

Re-ranking (перерранжирование)

После гибридного поиска у нас есть топ-20 кандидатов. Но они отсортированы по скору из Qdrant, который не всегда точен.

Re-ranker берёт исходный запрос и каждого кандидата (тут имею ввижду каждый найденный чанк-ответ), выставляет более точный скор. После перенажирвоания всех найденых ответо оставлем топ 10 самых релевантных по скору и отдаем уже LLM модели.

Она “покумекает” сама с собой если ей хватило данных отправит ответ пользвоателю, если не хватило еще раз запустит поиск уже переформулировал запрос.

А как она запустит второй раз перепоиск если мы не самую умную модель LLM взяли?
К нам на помощь приходит MCP think tool

MCP think tool– инструмент для reasoning (рассуждения). Агент вызывает tool think, чтобы записывать свои мысли перед ответом. Это еще один tools для нашего ИИ-агента.

Как работает:

Агент получает вопрос новичка. Перед тем как вызвать search_knowledge_base, агент вызывает think_tool

Примерно так

{
  "tool": "think",
  "thought": "Пользователь спрашивает про доступ к Jira. Мне нужно найти информацию в базе знаний про процесс получения доступа. Вызову search_knowledge_base с query 'получение доступа к Jira'."
}

Этот блок рассуждений логируется. Мы можем смотреть, правильно ли модель рассуждает, понимает ли она контекст. Это помогает отлаживать агента.

Без reasoning модель может сразу генерировать ответ, не подумав. С think tool модель сначала рассуждает, потом действует. Это повышает качество ответов, особенно для сложных вопросов.

---

И так, дорогие читатели, мы с вами построили 2 пайплайна, развернули локально модель. Разработали стратегибю поиска данны по векторной БД, настроили нашу LLM модель. Получается что:
1. База знаний ИИ-агента собрана
2. ИИ-агент(наставник) собран. То есть у него есть досутп к базе знаний и есть инструменты, которые помогают ему работать с этими данными.

Все на этом можем уже идти тестировать на ползователях. Но для начала подключим тг бот.

Что не разобрали

1. Настройка guardrails под корпоративный контекст

2. A/B-тестирование и rollout

3. Стоимость разработки и сроки

Если темы интересны, напишите в комментариях или личку в Telegram.

---

Спасибо, что прочитали. ❤️

Telegram-канал: «AI-заметки» ^[11] – рассказываю про ИИ, лайфхаки, полезные инструменты. Каждую неделю дайджест с самыми важными новостями в мире ИИ без инфошума, только всё самое важное.