Как мы отучили ИИ галлюцинировать в управлении проектами: RAG и ссылки на источники

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

Мы разрабатываем «Проектный интеллект» — систему из четырех ИИ-агентов (поиск и аналитика, планирование, аудит статусов и управление рисками). Главное продуктовое требование, которое мы заложили в архитектуру: любое утверждение ИИ должно подкрепляться ссылкой на первоисточник.

В этой статье рассказываем, как устроен наш RAG-слой, почему обычные промпты в духе «не выдумывай» не работают и где система все еще спотыкается.

Почему обычный промптинг — это тупик

Просьбы вроде «отвечай честно, а если не знаешь — так и скажи» работают только с тоном ответов, но не с самими данными. Без реального контекста модель не знает, что задача PM-123 висит без движения три недели, по ней открыто два инцидента, и она тормозит весь проект. Вместо фактов ИИ генерирует правдоподобную «воду» — тот самый статус «готово на 90%», в который никто не верит.

Вторая проблема — разрозненность данных. Проект живет в десятках систем: Jira, Confluence, Битрикс24, Yandex Tracker, MS Project, локальных файлах и презентациях. «Из коробки» ни одна языковая модель туда не зайдет. Нужна прослойка между ИИ и вашими инструментами.

Архитектура: что стоит между моделью и данными

Мы выбрали надежную и проверенную архитектуру:

[Источники данных] ➔ [MCP-коннекторы] ➔ [Гибридный индекс] ➔ [LLM + Промпт с жесткими правилами] ➔ [Верификатор] ➔ [Ответ со ссылками]

Коннекторы к источникам. Мы собираем данные из Jira, Confluence, Битрикс24, Yandex Tracker/Wiki, MS Project и файлов PPTX. Данные приводятся к единому формату: текст + метаданные (система, ID, автор, дата). Коннекторы написаны на базе протокола MCP (Model Context Protocol), поэтому их легко заменять и масштабировать.

Индекс. Тексты режутся на части (чанки) и отправляются в векторное хранилище. Для поиска по ключам задач обычный векторный поиск работает плохо, поэтому мы используем гибридный поиск (dense + ключевой BM25) с последующим переранжированием.

Заменяемая LLM. Система может работать на любой модели — хоть на собственном сервере компании, хоть в Cloud.ru (https://cloud.ru). Данные клиента не покидают защищенный контур, а сама модель — это лишь заменяемая деталь.

Жесткое правило: «Нет источника — нет утверждения»

Главная фишка системы — не сам RAG, а то, как мы обрабатываем данные при генерации ответа:

1. Модель получает контекст в виде чанков с уникальными ID.

2. В системном промпте прописан жесткий запрет: нельзя утверждать то, что нельзя подтвердить конкретным чанком. Каждая цифра и факт должны сопровождаться ID источника.

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

4. Если данных не хватает, ИИ обязан ответить: «Информации недостаточно, вот что удалось найти частично».

Главная боль: как ИИ ломается на агрегации

С простыми запросами («какой статус у задачи X?») модель справляется отлично. Но когда нужно собрать общую картину по 20–50 задачам («что горит в спринте?»), ИИ начинает обобщать и «фантазировать»: округляет проценты, путает данные из разных систем или вспоминает факты из своего общего обучения.

Как мы это решили:

Цифры — отдельно от текста. Даты, статусы и проценты ИИ не считывает из текста. Мы забираем их напрямую из структурированных полей систем и подставляем в финальный ответ. Модель отвечает за логику («что и почему»), а данные — за точность.

Верификационный фильтр. После того как ответ готов, отдельный алгоритм перепроверяет каждое утверждение по исходным чанкам. Все, что не подтвердилось на 100%, безжалостно вырезается.

Разделение на факты и гипотезы. Ответ четко делится на подтвержденные факты (со ссылками) и предположения (с пометкой, что это лишь догадка ИИ).

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

Вопрос: «Успеем ли с релизом?»

Ответ ИИ: Критический путь проходит через задачи A-12 (оценка 5 дней, по факту — 9) и A-17 (ожидает ревью 4 дня). При текущем темпе релиз сдвигается на ~6 дней.

[Ссылка на A-12] [Ссылка на A-17] [Ссылка на план]

Все три ссылки ведут на реальные задачи в трекере.

Человек в контуре (HITL) вместо полной автономии

Наши агенты — это советники, а не исполнители. Они не имеют права сами переносить дедлайны, менять оценки или отправлять отчеты. ИИ готовит план, декомпозицию или статус, но финальное решение всегда принимает человек.

Мы осознанно отказались от «полной автономии», которая красиво смотрится на презентациях. Для реального бизнеса предсказуемость и контроль важнее скорости. Доверие к системе, которая может молча перестроить весь план проекта, завоевать слишком сложно.

Честно о наших слабых местах

1. Планирование — пока самая слабая зона. Агент-администратор умеет задавать уточняющие вопросы к размытым задачам, но сделать декомпозицию лучше, чем опытный PM, он пока не может.

2. Скорость работы. Верификационный проход удваивает время ожидания ответа. Мы идем на это осознанно: лучше подождать лишние 10 секунд, чем получить мгновенный отчет с выдуманными данными.

3. Ограничение по источникам. Если вашей системы нет в списке наших коннекторов, ИИ просто не увидит эти данные.

Что дальше?

Сейчас продукт находится на стадии бета-тестирования, до конца года мы запускаем 5–8 пилотных проектов. Если вы хотите проверить, как ИИ работает с вашими живыми трекерами, условия участия можно посмотреть на https://pm-ai.ru.

В следующей статье мы подробно расскажем о том, как измеряем качество ответов статус-агента и почему метрика «пользователю нравится» здесь абсолютно не работает.