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

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

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

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

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

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

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

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

Боли уже известны в компании всем, начиная от руководителей, заканчивая 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, если нужна консультация.

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

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

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

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

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

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

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

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

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

    Логика чанкинга:
    Разбиваем документ по смыслу, а не просто по количеству слов. Используем 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",
     "department": "all",
    "roles": ["all"],
    "last_updated": "2025-11-15",
    "validity_date": null,
    "tags": ["командировки", "согласование"],
    "file_type": "confluence_page"
    }
    Добавляем эти метаданные к чанку. И храним в векторной БД векторы +метаданные.

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

    Модель для эмбеддингов:
    BAAI/bge-m3 моя рекомендация для 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.
Для ИИ-наставника хватит вполне даже модели на 7B параметров. Как выбрать лучшую модель, рассказал в тут.

Развёртывание локальной 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-заметки» - рассказываю про ИИ, лайфхаки, полезные инструменты. Каждую неделю дайджест с самыми важными новостями в мире ИИ без инфошума, только всё самое важное.