LLM-ассистент для управления проектами: как обучить модель на задачах, переписке и базе знаний компании

Менеджер проекта в продуктовой команде из 12 человек. Каждое утро — разбор мессенджеров, сборка статусного отчёта, декомпозиция нового эпика, поиск того самого решения, которое «точно где-то обсуждали три недели назад». По данным кейса TrueTech — такой PM тратит до 38% рабочего времени на административную рутину, а декомпозиция эпика сокращается с 10 минут до 2, sprint report — с 45 минут до 5. Цифры не верифицированы независимым источником, но порядок величин совпадает с тем, что описывают команды, прошедшие аналогичный путь.

Это произошло не потому, что команда подключила ChatGPT и попросила его «помочь с проектом». Модель получила доступ к реальным данным: задачам, переписке, архитектурным решениям.

LLM-ассистент без контекста компании — дорогой генератор общих советов. Тот же ассистент, подключённый к трекеру, базе знаний и переписке, забирает на себя рутину, которая съедает треть рабочего дня.

Эта статья про конкретную архитектуру: как подготовить данные, выбрать подход (RAG или fine-tuning), с каких сценариев начинать пилот и каких ошибок избежать. Без теории нейросетей — только то, что нужно знать менеджеру проекта или техлиду, который хочет запустить ассистента за разумное время.

Почему «голый» чат-бот бесполезен для управления проектами

Команда подключает ChatGPT, пишет: «Помоги составить план спринта». Получает красивый ответ с пятью пунктами. Проблема в том, что модель не знает, что спринт уже сдвинулся на неделю, что Иванов перегружен и взял двойную нагрузку, что в ADR зафиксировано решение не использовать этот подход — его отменили ещё в марте.

Модель отвечает из «знания мира» — из всего, на чём её обучали. Это огромный массив информации о лучших практиках, методологиях, фреймворках. Но у неё нет «знания компании»: что происходит в вашем проекте сейчас, какие решения принимались, кто за что отвечает.

Разрыв между этими двумя типами знания — главная причина, по которой большинство попыток «внедрить ИИ» заканчиваются разочарованием. Как отмечают консультанты, работающие с LLM, «голый» чат-бот без интеграции в трекер и базу знаний не решает задач PM — он просто переформулирует запрос красивыми словами.

Ассистент становится полезным при выполнении нескольких условий. Первое: доступ к актуальным данным проекта — задачам, комментариям, статусам, решениям. Второе: умение различать, что от него хотят — получить информацию или выполнить действие. Об этом подробнее написано в статье про три типа AI-ассистентов в управлении проектами. Третье: интеграция с трекером через API, чтобы ассистент мог не только отвечать, но и действовать. И четвёртое, о котором часто забывают: логирование запросов и ответов — без него невозможно понять, где ассистент ошибается и что нужно поправить в данных.

RAG или fine-tuning — какой подход выбрать для проектных данных

Когда речь заходит об «обучении модели на данных компании», большинство команд представляют это так: загружаем переписку, документы, задачи — модель всё это «запоминает» и начинает отвечать с учётом нашего контекста. Интуитивно понятно. Технически — неверно.

Есть два принципиально разных способа работы с корпоративными данными, и выбор между ними определяет, будет ли ассистент работать или нет.

Когда RAG — единственный рабочий вариант

RAG (Retrieval-Augmented Generation) работает иначе, чем дообучение. Документы хранятся во внешней векторной базе — отдельно от модели. Когда приходит запрос, система сначала ищет релевантные фрагменты в этой базе, затем передаёт их модели как контекст, и только потом модель генерирует ответ на основе найденного.

Для проектных данных это основной рабочий вариант. Задачи меняются ежедневно. Переписка растёт. Регламенты обновляются. Решение, принятое в марте, могло быть отменено в апреле. Модель физически не может «запомнить» всё это через дообучение весов — к тому моменту, как обучение закончится, данные уже устареют.

Где fine-tuning всё-таки нужен

Fine-tuning — настройка весов модели на конкретных примерах — решает другую задачу. Не «знай наши данные», а «отвечай в нашем стиле».

Модель, дообученная на шаблонах задач компании, будет генерировать описания в привычном формате: с Definition of Done, Acceptance Criteria, правильными тегами. Она будет писать в тоне, принятом в команде. Использовать специфическую терминологию. Фактические данные о проекте при этом всё равно берутся из RAG-слоя.

Fine-tuning на переписке — интуитивно привлекательная, но опасная идея. Переписка — это не только полезные паттерны. Это дубли, устаревшие решения, неформальные договорённости, которые никогда не выполнялись, и иногда — данные, которые не должны попасть в обучающую выборку. Модель перенимает всё это вместе с полезным. Исследователи, изучающие управление знаниями и большие языковые модели, прямо указывают: без строгой гигиены данных fine-tuning на корпоративном контенте воспроизводит хаос, а не порядок.

Подготовка данных — этап, на котором чаще всего проваливаются

Команды, у которых не получилось с ассистентом, обычно объясняют это «слабостью модели» или «недостаточно умным ИИ». На практике причина почти всегда другая: в базу скормили хаос и ожидали порядка на выходе.

Качество ассистента определяется не выбором модели. Авторы технических разборов на Habr фиксируют одно и то же: команды, которые меняли GPT-4 на Llama или обратно, не получали заметного улучшения — проблема неизменно оказывалась в данных. Качество определяется тем, насколько чисто подготовлены данные на трёх уровнях.

Задачи и трекер: что индексировать, а что отсеять

Не все задачи одинаково полезны для контекста. Ассистенту нужны: описания с Acceptance Criteria, комментарии с зафиксированными решениями, связи между задачами и эпиками, история изменений статусов. Не нужны: пустые карточки-заглушки, дубли из миграций, тестовые задачи с названиями «ааа» и «проверка».

Перед индексацией стоит прогнать трекер через фильтр: задача без описания и без единого комментария — не контекст, а шум. Ассистент, который «знает» о существовании 3000 пустых карточек, не становится умнее.

Переписка: анонимизация и выделение эталонных диалогов

Переписка — ценный источник решений, которые нигде больше не зафиксированы. Работать с ней нужно аккуратно.

Строгая гигиена: удаление дублей, анонимизация персональных данных, исключение устаревших веток, где решение было принято, а потом отменено. Из переписки стоит выделить «золотой фонд»: письма с зафиксированными решениями, протоколы встреч, ADR — это наиболее ценный материал для RAG-индекса. Остальное — по ситуации.

База знаний: от «цифрового кладбища» к инженерной системе

Большинство корпоративных баз знаний — это Confluence с 400 страницами, из которых 200 не обновлялись два года, 80 — черновики, которые никто не дочитал, а 50 — копии друг друга с незначительными правками.

Для LLM база знаний должна быть не набором файлов, а инженерной системой — с версионированием, метаданными и единым форматом. По каждому документу должно быть ясно, к чему он относится, когда обновлялся и актуален ли он вообще. Без этого модель будет уверенно ссылаться на отменённые процедуры.

Отдельный момент: много регламентов, договоров и схем существует в виде сканов и скриншотов. Без OCR/Vision-слоя эти документы остаются невидимыми для модели — индексировать нужно не только текст, но и всё, что можно извлечь из изображений.

В Shtab база знаний встроена в ту же среду, где живут задачи и проекты. Ассистент получает контекст из задач, страниц и комментариев без дополнительных интеграций — это упрощает индексацию и убирает проблему «разрозненных источников». Если вы выбираете, где хранить знания, посмотрите на 9 лучших систем для базы знаний — там разобраны форматы хранения и критерии выбора.

Пошаговая схема: от пилота на 5 сценариях до полноценного «второго PM»

Самая распространённая ошибка при запуске ассистента — попытка охватить всё сразу. «Пусть он знает весь проект, всю переписку, все регламенты». Через месяц проектирования «идеальной» системы команда получает либо ничего, либо что-то настолько сложное, что никто не понимает, как это поддерживать.

Российские практики, работающие с LLM в проектном управлении, сходятся в одном: начинать нужно с 5–10 чётко описанных сценариев, а расширять покрытие по результатам пилота.

Шаг 1. Определить границы и запрещённые зоны. До написания первой строчки кода — зафиксировать письменно: что ассистент может делать (создать задачу, собрать отчёт, найти решение в базе знаний), чего не может (менять бюджет, удалять проекты, отвечать на вопросы вне своей области). Формат ответа: шаблонный или свободная генерация. Это фиксация границ ответственности — без неё ассистент рано или поздно «поможет» удалить что-то важное.

Шаг 2. Выбрать стартовые сценарии. Для пилота рекомендуется набор с минимальным риском и максимальной видимостью результата:

• Декомпозиция эпика на задачи с описаниями и Acceptance Criteria
• Сводка по статусу проекта за неделю
• Поиск решения в базе знаний по естественному запросу («как мы решали проблему с авторизацией в прошлом квартале?»)
• Формирование списка рисков по открытым задачам без ответственного или без дедлайна
• Создание задачи из протокола встречи или голосового сообщения
• Автоматическая приоритизация бэклога по соотношению ценности и усилий — сценарий, который хорошо ложится на методику Value vs Effort и легко проверяется командой вручную на первых итерациях

Шаг 3. Собрать и очистить данные для RAG-индекса. Для пилота достаточно одного проекта с историей 3–6 месяцев. Не нужно индексировать всё — нужно индексировать чистое. Подробнее о подготовке данных — в предыдущем разделе.

Шаг 4. Настроить архитектуру. Типовой пайплайн, который описывают в документации большинства LLM-провайдеров (например, в референс-архитектуре GigaChat): приём запроса → маршрутизация по типу (информационный или операционный) → обращение к RAG-индексу или API трекера → генерация ответа → логирование. Маршрутизация — обязательный элемент: без неё ассистент пытается «выполнить» вопрос или «объяснить» команду.

Шаг 5. Пилот, замер, расширение. Запустить на одной команде. Собирать обратную связь 2–4 недели. Замерить время на рутинные операции до и после — не по ощущениям, а по конкретным задачам. Принять решение о расширении сценариев на основе данных, а не энтузиазма.

Если нужен детальный план внедрения с метриками и контрольными точками, следующий шаг — статья «12 недель до ROI: пошаговый фреймворк внедрения AI-агента для управления проектами».

Кейс KozhinDev: GPT-ассистент руководителя на базе Llama 3

Аутсорсинговая компания. Нет выделенной ML-команды. Менеджеры проектов теряли время на поиск документов в проектных Wiki — информация была, но найти её быстро не получалось.

Алексей Гучко, менеджер проектов KozhinDev, собрал GPT-ассистент руководителя на базе локальной модели Llama 3. Ассистент обучен на проектных документах и внутренней Wiki. Данные не покидают инфраструктуру компании — для аутсорсинга с NDA это критично.

По словам Алексея, точный замер в цифрах не проводился: «Прямо точную цифру не назову». Качественный эффект — сотрудники реже отвлекаются на поиск, информация стала доступнее. Косвенный индикатор: количество обращений к коллегам с вопросами «а где лежит документ по X?» заметно снизилось — хотя формального трекинга таких обращений не было, команда зафиксировала это в ретроспективе.

Отсутствие точных метрик на этапе пилота — нормальная ситуация. Задача первого запуска — убедиться, что ассистент вообще полезен и команда им пользуется. Количественные замеры имеет смысл подключать на втором-третьем цикле, когда сценарии стабилизировались.

Главный урок кейса — в последовательности. Начали с одного сценария: поиск по Wiki. Работает. Теперь планируют расширять на обработку созвонов и таймшиты. Ровно та логика «от пилота к масштабированию», о которой шла речь выше.

Комментарий редакции Shtab: Этот кейс подтверждает принцип, который мы видим у команд, внедряющих AI-агентов: лучше один работающий сценарий за две недели, чем полгода проектирования «идеальной» системы.

Интеграция с экосистемой: ассистент, который не только отвечает, но и действует

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

Советчик отвечает на вопросы. Спросил — получил ответ. Это экономит время на поиск информации, но не на исполнение. Ты всё равно идёшь в трекер и создаёшь задачу руками.

Агент выполняет действия через API. Сказал «создай задачу по этому протоколу» — задача появилась в трекере с описанием, ответственным и дедлайном. Это другой уровень автоматизации.

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

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

В Shtab AI реализован режим «Агент», который работает внутри платформы. Наиболее востребованные у PM-команд сценарии: декомпозиция задач с автоматическим созданием подзадач и чек-листов, обработка загруженных файлов (xlsx, pdf, docx, md, txt, log) с извлечением задач и сроков, голосовой ввод для создания карточек прямо со встречи, а также генерация еженедельных сводок по проекту. Поддерживаются Claude, Gemini, ChatGPT, YandexGPT, DeepSeek, GigaChat, Llama, Qwen, Mistral. Для закрытых контуров — подключение к локальной модели on-premise.

Интеграция агента логично следует за базовым внедрением трекера. Если этот этап ещё не пройден, стоит начать со статьи «Внедрение системы управления проектами в компании: пошаговый план для руководителя».

Четыре ошибки, которые превращают ассистента в генератор галлюцинаций

Большинство неудачных внедрений LLM-ассистентов объясняется не ограничениями модели. Команды скармливают модели хаос и ожидают порядка на выходе. Вот конкретные способы это сделать.

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

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

Ошибка третья: игнорировать визуальные документы. Много корпоративных знаний живёт в PDF-сканах, скриншотах схем и фотографиях досок. Без OCR/Vision-слоя эти данные остаются невидимыми для модели — как будто их не существует. Ассистент, который не «видит» половину регламентов, будет давать половинчатые ответы. Проблема решается на этапе подготовки базы, а не после запуска.

Ошибка четвёртая: не логировать запросы. Без истории запросов невозможно понять, где ассистент систематически ошибается, какие сценарии работают хуже ожидаемого и что нужно доработать в данных. Логирование — единственный способ улучшать систему на основе реального использования, а не догадок. Команды, которые пропускают этот шаг, через месяц оказываются в ситуации «вроде работает, но непонятно, насколько хорошо» — и не могут обосновать ни расширение, ни отказ от ассистента.

Что ассистент сможет делать завтра — и к чему готовиться через полгода

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

Ближайшие функции, которые появляются в обновлениях Shtab, меняют сценарии использования:

Транскрибация встреч — ассистент расшифровывает созвон с отметками спикеров и автоматически создаёт задачи из договорённостей. Это убирает ручной разбор протоколов полностью.

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

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

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

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

Что можно сделать на этой неделе

Не «внедрить ИИ» — это слишком абстрактно. Четыре конкретных действия.

Первое: провести аудит базы знаний. Открыть Confluence или любое другое хранилище и честно ответить: сколько страниц не обновлялись больше года? Сколько черновиков, которые никто не дочитал? Привести в единый формат хотя бы один проект — это и есть стартовая точка для RAG-индекса.

Второе: выбрать один сценарий для пилота. Рекомендация — «сводка по статусу проекта за неделю». Минимальный риск, понятный результат, легко замерить время до и после.

Третье: настроить логирование с первого дня. Даже если пилот запускается на одной команде — фиксировать запросы, ответы и оценку полезности. Без этого через месяц не будет данных для решения о расширении.

Четвёртое: запустить на ограниченном scope. Одна команда, один проект, 2–4 недели. Замерить время на рутину. Принять решение о расширении на основе данных.

Если готовы к полноценному внедрению с метриками и контрольными точками — следующий шаг: «12 недель до ROI: пошаговый фреймворк внедрения AI-агента для управления проектами».

FAQ

Какие задачи LLM-ассистент может выполнять в управлении проектами?

Декомпозиция эпиков на задачи, генерация еженедельных отчётов, поиск решений в базе знаний, формирование списка рисков, создание задач из протоколов встреч. В агентном режиме — создание и изменение задач, установка связей и зависимостей, обработка файлов xlsx, pdf, docx, md, txt, log.

Что такое база знаний для AI-агента?

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

Чем RAG отличается от fine-tuning при обучении на данных компании?

RAG хранит документы во внешней базе и находит релевантные фрагменты по запросу — подходит для данных, которые часто меняются. Fine-tuning «вшивает» знания в веса модели — подходит для настройки стиля и терминологии, но не для хранения фактов.

Как подключить ИИ к системе управления проектами?

Через API трекера: ассистент получает доступ к задачам, комментариям и статусам, может создавать и обновлять карточки. В некоторых системах, например в Shtab, AI-агент встроен и работает внутри платформы без дополнительных интеграций.