База знаний с ИИ на 15 000 запросов в день: как мы используем этот опыт в создании нейропомощника для проектных команд

Нейропомощник для проектного офиса

В этом году мы в проектном офисе делаем нейропомощник для проектных команд. Наши команды работают с объёмной нормативно-методологической базой: основное Положение о проектной деятельности на 100+ страниц, десятки важных смежных НМД (нормативно-методических документов), отдельные методики по мониторингу контрольных точек, по проектной дисциплине, по определению критериев успешности и интегрального статуса, десятки шаблонов документов, материалы обучающих курсов и вебинаров с корпоративного портала, лучшие практики коллег и прочее, и прочее… Это не один документ и не десять: это многослойная база, в которой нужную информацию ещё надо уметь найти.

Типовые обращения в проектный офис выглядят предсказуемо. “Как заполнить такой-то слайд в шаблоне для презентации управляющему комитету?”, “Как определяется интегральный статус проекта?”, “Что мне нужно делать, чтобы соответствовать методике по контрольным точкам?”. Это не сложные вопросы, но каждый из них отвлекает сотрудника PMO от работы, которая требует реальной экспертизы, а не справочного ответа. Умножьте это на десятки проектов и команд.

Задача нейропомощника прямая: член проектной команды пишет вопрос обычными словами и получает точный ответ со ссылкой на конкретный документ. Ему не нужно писать в PMO, не нужно самостоятельно искать по порталу среди десятков нормативных документов.

Создавая такой нейропомощник, мы изучаем опыт построения аналогичных систем и один кейс показался наиболее интересным: компания Cerebras, производитель ИИ-чипов, построила похожую систему поиска по внутренней базе знаний для своих сотрудников и обрабатывает 15 000 вопросов в день. Разберём, как она устроена и что из этого применимо в нашем контексте.

Почему 15 000 вопросов в день это не просто про масштаб

Система Cerebras работает как Slack-бот, сотрудник задаёт вопрос обычными словами, без специального синтаксиса, без поиска по порталу. Три источника данных питают систему одновременно: Slack-переписка и каналы, GitHub с задачами, запросами на изменение кода и комментариями, Confluence со страницами документации и runbook’ами (пошаговыми инструкциями для типовых операций). Три разных типа контента, три разных режима обновления.

Цифра 15 000 запросов в день говорит о том, что сотрудники ею пользуются и система популярна. Корпоративные базы знаний чаще всего умирают тихо: технически работают, но реально никому не нужны. 15 000 запросов в день означают, что система вписалась в реальный рабочий процесс.

Что применимо у нас: цель ровно та же. Нейропомощник должен войти в рабочий процесс члена проектной команды, а не стать ещё одним порталом, о котором все знают, но никто не использует. Принцип “человек пишет вопрос обычными словами” применим без изменений.

А вот что требует переосмысления, так это масштаб. 15 000 запросов в день это уровень нагрузки большой технологической компании с тысячами сотрудников и живыми коммуникационными потоками. В нашем контексте проектного офиса и с нашим количеством участников проектной деятельности ожидаемая нагрузка существенно ниже. Это влияет на требования к инфраструктуре, но не на принципы архитектуры.

Генерация с дополненной выборкой (RAG): почему базовая реализация не работает

Генерация с дополненной выборкой (RAG, Retrieval-Augmented Generation) проста в теории: возьми вопрос пользователя, найди релевантные фрагменты в базе знаний, передай их языковой модели вместе с вопросом, получи ответ. Базовую реализацию можно поднять за день. Работающую в реальных условиях с реальными данными, которым пользователи реально доверяют, за день не поднимешь.

У базовых реализаций три устойчивых точки отказа.

1. Нарезка документов на фрагменты без учёта структуры контента. Большинство инструментов режут документы по количеству токенов (единиц текста, которые обрабатывает языковая модель) или по абзацам. Slack-переписка, разрезанная посередине разговора, теряет контекст: система извлекает технически похожий кусок, в котором нет ответа, потому что ответ был в следующем сообщении. Таблица, разрезанная пополам, становится бессмысленной. Блок кода без соседнего комментария теряет объяснение.

2. Только семантический поиск по векторным представлениям (числовым описаниям смысла текста). Такой поиск хорошо находит контент по смыслу, но плохо справляется с точечными запросами. Вопрос “какое решение приняли по деплою в третьем квартале?” содержит конкретную терминологию и конкретный период. Семантический поиск вернёт всё похожее по смыслу, но может пропустить именно тот документ, где зафиксировано решение, потому что там использовались другие слова.

3. Устаревшие данные. Если обновление базы знаний происходит раз в сутки или реже, база всегда частично устарела. Пользователь получает ответ на основе документа трёхмесячной давности и не знает об этом. Один такой случай сеет сомнение. Несколько подряд убивают доверие.

Что применимо у нас: все три точки отказа актуальны независимо от масштаба. Особенно первая - многостраничное нормативно-методологическое положение, нарезанное по количеству токенов, будет давать те же проблемы, что переписка, разрезанная посередине.

Что нам не подходит или требует адаптации: третья точка отказа у нас устроена иначе. Утверждённые НМД и методики обновляются редко. Проблема устаревших данных в нашем случае значительно менее острая, чем у Cerebras с живыми коммуникационными потоками и для нас это упрощает задачу.

Как Cerebras решает проблему структуры данных

Cerebras не ищет универсальную стратегию нарезки. Каждый тип источника обрабатывается по своей логике.

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

Метаданные в этой системе работают не как справочная информация, а как фильтры при поиске. Автор сообщения, время отправки, принадлежность к команде, метки задачи. Это позволяет отвечать на запросы с конкретными параметрами: что инфраструктурная команда обсуждала за последний месяц, какие комментарии оставили к запросу на изменение кода с конкретной меткой.

Непрерывный приём данных закрывает проблему устаревших материалов. Новые Slack-сообщения, принятые изменения кода, обновлённые страницы Confluence попадают в базу знаний в режиме, близком к реальному времени. Это нетривиальная инженерная задача: Slack имеет ограничения на частоту запросов к своему API (application programming interface, программный интерфейс), GitHub требует настройки уведомлений об изменениях, Confluence разграничивает доступ. Но без режима близкого к реальному времени система с живыми коммуникациями как источником будет всегда отставать.

Что применимо у нас: логика “каждый тип источника обрабатывается по своей природе” применима напрямую. Нормативно-методологический документ логично резать по разделам и подразделам. Методика по проектной дисциплине, методика по контрольным точкам, методика по определению интегрального статуса, методика по критериям успешности - каждая из них имеет внутреннюю структуру, и граница фрагмента должна проходить по заголовкам, а не по счётчику символов. Шаблоны презентаций можно хранить по слайдам для вопросов о том, как показать ту или иную информацию на отдельном слайде. Отдельные шаблоны, в частности, шаблон карточки ИТ-инициативы, нельзя резать, он работает как единое целое.

Метаданные в нашем контексте - это принадлежность фрагмента к конкретной методике, тип документа (НМД, шаблон, материал курса, рассылка PMO), дата последнего обновления. С такими фильтрами система сможет отвечать точнее: “найди в методиках по мониторингу” или “покажи актуальный шаблон, не устаревший”.

А вот чего нам можно не делать, так это непрерывный приём данных, который для наших источников избыточен. Утверждённые НМД меняются по регламентированному процессу, материалы портала и курсов обновляются планово. Достаточно настроить регулярное обновление базы знаний при выходе новой версии документа. Это значительно проще в поддержке.

Ссылки на источники как архитектурное решение, а не UX-деталь

Языковые модели галлюцинируют. Это не баг конкретной реализации, это фундаментальное свойство технологии. RAG снижает вероятность галлюцинаций, ограничивая контекст, на основе которого строится ответ, но не устраняет их полностью. Задача системы не “никогда не ошибаться”, а “делать ошибки заметными”.

Именно для этого в Cerebras каждый ответ сопровождается ссылками на конкретные источники и информацией о том, какие фрагменты были извлечены при поиске. Пользователь видит не просто ответ, а ответ с доказательной базой. Это меняет характер взаимодействия: вместо “верю или не верю” человек получает возможность проверить.

Цитирование создаёт петлю обратной связи. Правильный ответ со ссылкой на актуальный документ получает уместный уровень доверия. Неправильный или устаревший ответ замечается быстрее, потому что пользователь видит источник.

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

Что нужно измерять, чтобы система улучшалась

Система без метрик выходит на плато. Она работает, отвечает на вопросы, но никто не знает, на сколько процентов запросов она отвечает успешно, где систематически ошибается и почему использование не растёт, хотя технически всё поднято.

Cerebras называет несколько ключевых сигналов:

• Объём запросов - растёт ли использование или стагнирует.
• Задержка отклика - сколько времени пользователь ждёт ответа, при каком пороге начинает терять терпение.
• Точность извлечения - насколько найденные фрагменты реально релевантны вопросу.
• Доля вопросов без ответа - запросы, на которые система не смогла ответить ничем осмысленным, это прямая карта белых пятен в базе знаний.
• Пользовательский фидбек в самой простой форме - “это помогло?” после каждого ответа даёт сигнал, который нельзя извлечь из технических логов.

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

Что берём в архитектуру, что откладываем

Изучив кейс Cerebras, мы можем сформулировать конкретные решения для нашего нейропомощника.

Берём без изменений.

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

Адаптируем под наш контекст:

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

Откладываем / не делаем:

• Сложный конвейер повторного ранжирования с использованием отдельной модели (re-ranking): это полезно при большом объёме данных и высокой нагрузке, в нашем случае добавляет сложность без пропорционального прироста качества на старте.
• Параллельный поиск по нескольким источникам одновременно: тоже история масштаба, не первого запуска.

Главный вывод из кейса Cerebras прямой. Генерация с дополненной выборкой (RAG) - это зрелый инструмент, который доказал свою работоспособность на реальной корпоративной нагрузке. Для проектного офиса с формализованной базой знаний задача даже проще: источники стабильны, структура предсказуема, обновления регламентированы. Это не снимает инженерных задач, но делает их решаемыми без экзотической инфраструктуры.

Все это затевается не для того, чтобы “поиграться в новые современные технологии”, а для реальной пользы для проектных команд, чтобы найти нужное можно было быстро и получить предсказуемый результат. Проектный офис также получает свою выгоду: мы рассчитываем на разгрузку от рутины и возможность сосредоточиться на задачах, где нужна реальная экспертиза. Правильно настроенный нейропомощник должен работать не как поисковик, который выдаёт список документов, а как коллега, который знает, где что лежит, и объясняет, а не только указывает направление. Получится ли у нас, узнаем уже совсем скоро.