Индексация баз знаний (Confluence, Notion, SharePoint) для RAG

Почему RAG-индексация корпоративных баз знаний даёт мусорные ответы

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

Первый источник сбоев — разнородная разметка. Страницы в Confluence, Notion и SharePoint живут вложенными блоками, врезками и списками задач; плоский парсер снимает иерархию, и заголовок раздела отрывается от своего тела. В выдачу попадают шаги из соседней инструкции, а порядок действий теряет смысл.

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

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

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

Что меняется после управляемой перестройки поиска по базе

Первое, что меняется, — выдача перестаёт зависеть от того, угадал ли сотрудник формулировку. Гибридный поиск складывает точное совпадение по словам и векторную близость, а переранжирование поднимает наверх фрагменты, где действительно есть ответ. Индексируем пространства Confluence, Notion и SharePoint в едином RAG-контуре: источники остаются на своих местах, меняется только слой поиска.

Полнота выдачи и опора на источник

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

Скорость ответа и актуальность базы знаний

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

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

Полная, инкрементальная и гибридная пересборка: что выбрать

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

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

Как выбрать режим под поток изменений

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

Этапы RAG-индексации: от аудита источников до приёмки

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

1. Аудит источников. Обходим пространства и разделы Confluence, Notion и SharePoint: объём, частота правок, владельцы, дубли. Закрытые разделы либо исключаем, либо помечаем уровнем доступа, чтобы права сохранялись и в выдаче.
2. Схема разбиения. Режем по смысловым блокам — заголовки, таблицы, шаги инструкций, а не по фиксированному окну. Единый размер фрагмента для регламента и переписки даёт обрывки смысла на стыках.
3. Метаданные документа. К каждому фрагменту привязываем источник, раздел, владельца, дату изменения и уровень доступа. Без них не работают фильтры по пространствам и отзыв документа из индекса.
4. Конвейер обновления. Настраиваем инкрементальную переиндексацию по событиям изменения и удаления, полный проход по расписанию — как страховку от пропущенных событий.
5. Проверка качества. Собираем контрольный набор вопросов с эталонными ответами и смотрим, попадает ли нужный фрагмент в первые позиции. Промахи разбираем отдельно: чаще всего это дубли или устаревшая версия.
6. Передача в эксплуатацию. Фиксируем регламент переиндексации, ответственного за качество базы и порядок подключения новых источников. Приёмка идёт на ваших данных, а не на демонстрационном наборе.

Схемы разбиения текста, политики доступа и регламенты обновления

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

• Карта источников. Какие пространства, разделы и базы попадают в индекс, кто владелец каждого, что исключено сознательно и по чьему решению.
• Правила наследования прав. Доступы из исходной системы переносятся в индекс по той же иерархии: сотрудник получает в ответе только те фрагменты, что открыты ему в самой вики или хранилище.
• Конфигурации сборки. Схемы разбиения по типам документов — регламенты, тикеты, таблицы, переписка — с размером фрагмента и перекрытием под каждый тип.
• Регламент обновления. Частота переиндексации по источникам, обработка удалённых и перемещённых документов, поведение при смене прав доступа.
• Метрики качества. Контрольный набор вопросов, доля ответов со ссылкой на подтверждающий фрагмент, доля честных отказов «не знаю», динамика по итерациям.
• Инструкция для команды. Как подключить новый источник, как отозвать доступ, что делать, если ответ расходится с документом-источником.

Поддержка без нас

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

Кейс: как сократили долю нерелевантных ответов в поддержке

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

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

Динамика метрик

Обратная связь команды

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

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

Что делать, если база знаний уже проиндексирована сторонним сервисом?

Сначала выясняем, что осталось от стороннего сервиса: параметры разбиения на фрагменты, состав метаданных, учёт прав доступа. Если это есть в выгрузке — переносим настройки и достраиваем потерянное; если отданы только готовые векторы без структуры, чище переиндексировать источники напрямую. Индекс без метаданных почти всегда даёт худшую выдачу.

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

Мягкая миграция без остановки: новый индекс собирается рядом со старым, наполняется снимком источников и догоняется по изменениям. Запросы пока идут в старый, а на новый уходит та же выборка в теневом режиме — качество сравниваем на живом потоке. Переключение по флагу, когда метрики совпали; откат тем же флагом, старый индекс держим в запасе несколько недель.

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

Технические сомнения: права доступа, разметка, потеря контекста

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

Таблицы и вложения превратятся в кашу?

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

Как не потерять контекст при нарезке?

Фрагменты режутся по смысловым границам с перекрытием, а заголовки разделов и путь по дереву страниц пишутся в метаданные. В модель уходит не одиночный кусок, а фрагмент вместе с иерархией. Это снижает долю ответов, где вырванная из контекста фраза трактуется неверно.

Что с устаревшими страницами и противоречиями?

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

Документы на разных языках?

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

Обсудим задачу: с чего начнём и что потребуется от вас

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

• Аудит источников. Перечень пространств в Confluence, баз Notion, библиотек SharePoint, файловых хранилищ и внутренних порталов — с пометкой, что реально используется в работе, а что осталось архивом и в индекс не пойдёт.
• Частота правок. Как быстро устаревают страницы, есть ли регламент публикации, кто следит за актуальностью и нужно ли переиндексировать всё или хватит изменённого.
• Доступы и выгрузки. Сервисная учётная запись с правом чтения, выгрузка страниц в открытом формате либо разовый снимок базы. Если контур закрытый — обсуждаем сборку внутри вашей сети.
• Ограничения по данным. Разделы, которые индексировать нельзя: кадры, договоры, персональные данные. Исключения закладываем в правила сбора на старте, а не после.
• Ожидаемые сценарии. 5–10 реальных вопросов, на которые ассистент должен отвечать, — по ним видно, какие типы документов критичны, а какие можно не трогать.
• Ответственный за приёмку. Один человек с вашей стороны, который подтверждает полноту ответов и решает спорные случаи на этапе настройки.

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