ИИ-наставник для онбординга: как собрать ИИ-агента для адаптации новых сотрудников в компании
- В тексте отмечается, что выход на эффективность у новичка в среднем занимает 3 месяца, а иногда 4–5, потому что вопросы и поиск информации отнимают время у него и у руководителей.
- Выдвигается гипотеза: ИИ-наставник, который собирает базу знаний и учитывает должность, может снизить повторяющиеся вопросы к HR минимум на 80% и сократить время онбординга.
- Интерфейсом выбран Telegram: приветствие в первый день, мини-инструкции и персональный план адаптации с материалами (документы, видео, презентации).
- База знаний предлагается собирать из систем вроде Confluence и HR-систем через API, преобразовывать документы в текст (dedoc) и дополнять OCR для текста на изображениях; обновление — по webhook или по таймеру.
- Для индексации описаны чанкинг по смыслу (300–400 слов, overlap 50–80), метаданные по ролям/отделам и эмбеддинги BAAI/bge-m3 с хранением в векторной базе Qdrant (косинусная метрика).
Почему это важно: В статье разложена типовая проблема онбординга: знания есть, но они разнесены по разным хранилищам и контексту конкретной роли. ИИ-наставник в такой схеме сводит поиск и ответы в один канал и помогает быстрее пройти первые недели, когда барьеров и вопросов больше всего. На практике это часто снижает нагрузку на людей, к которым идут повторяющиеся вопросы.
На что обратить внимание: В описании много зависит от того, какие источники подключаются и насколько регулярно обновляется индекс, чтобы база знаний не устаревала. Отдельно упомянуты сложности с картинками и схемами (нужен OCR) и риски при использовании облачной LLM, где предлагается маскирование данных. В конце отмечено, что guardrails, A/B-тестирование, стоимость и сроки разработки в тексте не разобраны.
Коротко
- Кейс показывает, почему онбординг буксует: нужная информация есть, но распределена по разным каналам, и поиск легко съедает полдня.
- Для коротких запросов вроде «VPN» или «Jira» в тексте предлагается multi-query: расширять запрос, чтобы не промахиваться мимо нужных документов.
- После гибридного поиска в Qdrant автор добавляет переранжирование, чтобы отсечь слабые совпадения и оставить несколько наиболее релевантных фрагментов.
- При использовании облачной LLM отдельно подчёркнуто маскирование имён, фамилий и названий проектов перед обращением к API как мера снижения риска утечки.
- Отдельный приём для разработки — think-tool: логирование рассуждений агента перед действием, чтобы проще было проверять логику и качество ответов.
FAQ
Зачем компании может понадобиться ИИ-наставник для онбординга, если уже есть документы, чаты и руководители, которым можно задавать вопросы?
В тексте описано, что знания часто разбросаны по разным системам, а вопросы уходят к людям. Агент задуман как способ быстрее находить ответы с учётом роли и снижать поток повторяющихся вопросов.
Откуда, по описанию, берётся база знаний для ИИ-наставника и как она поддерживается актуальной при изменении документов в Confluence или других системах?
Предлагается забирать документы из источников через API и превращать их в текст, дополняя OCR для изображений. Обновление запускается по webhook при изменении страниц или по таймеру, если webhook недоступен.
Как в статье предлагается учитывать роль и отдел новичка, чтобы ИИ-наставник возвращал релевантные материалы и не отвечал общими фразами на разные ситуации?
К чанкам добавляются метаданные, включая отдел и роли, часть из них предлагается обогащать через LLM. При поиске результаты фильтруются по этим метаданным и затем отбираются наиболее релевантные.
Что автор отмечает про выбор облачной или локальной LLM-модели для агента и какие меры предлагает, чтобы снизить риск утечки корпоративных данных?
Он пишет, что можно использовать локальную или облачную модель. Для облака отдельно подчёркнуто маскирование данных: замена имён, фамилий и названий проектов на placeholder перед отправкой в API.
Читайте также
Память на миллион токенов, а толку ноль: как ИИ-агента спасали от «тупости»- От RAG-прототипа к агенту в продакшн: путь по метрикам, а не по моде
- Capacitor: от веба к мобильным приложениям. Часть 4. Интегрируем локальную LLM в проект
- Самохостный AI-агент на почте, systemd и LLM
- Конец бесплатного кремния: как Google AI Studio превратилась из рая для инженеров в симулятор смены аккаунтов
- Двухконтурная архитектура ИИ-наставника: обновляемая база знаний + рантайм-агент: В статье предложено разделять систему на два независимых процесса: фоновый пайплайн, который регулярно обновляет базу знаний, и рантайм-агента, который отвечает на вопросы и оркестрирует инструменты. Такой разнос снижает стоимость обновлений: вместо полной переиндексации обновляются только изменившиеся части данных.
[Архитектура LLM-агентов]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Автор описывает кейс: ИИ-наставник для онбординга новых сотрудников в IT-компании, который общается с новичком через Telegram-бота и опирается на базу знаний. В основе — разделение на обновляемую базу знаний и рантайм-агента, отвечающего на вопросы по роли.