RAG после reranker: как Рунити сделала из поиска по Confluence исследовательского агента

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Показывает, как превратить корпоративный RAG-поиск в агента с проверкой прав и мультишаговым исследованием — рабочий паттерн для внутренних ИИ-ассистентов.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Что произошло

Рунити выложила вторую часть разбора про поиск по внутренней базе знаний. Первая была про ранжирование: почти 35 тысяч страниц Confluence, dense и sparse retrieval, объединение кандидатов, reranker на выходе. Метрики тогда показали неприятное: нужный документ часто уже попадал в выборку, но стоял слишком низко в списке.

Reranker помог поднять подходящие фрагменты и заметно улучшил выдачу.

Вторая часть начинается там, где заканчивается хорошая выдача. Поиск обернули в MCP-сервер и отдали агенту Hermes. Тот вызывает инструмент сам, раунд за раундом, пока не наберёт материал для ответа. Автор разбора: Александр Михеев, ML-инженер Центра гибридного интеллекта в Рунити. Материал рассчитан на 8 минут чтения.

Что собрали, если убрать термины

Есть поисковый сервис (в тексте он называется Indexer). Внутри вся начинка: подготовка данных, два канала поиска, слияние, переранжирование. Снаружи висит HTTP-эндпоинт /mcp, агент стучится туда по JSON-RPC, передаёт запрос и фильтры, получает обратно фрагменты документов со ссылками в обычном JSON. Никаких stdio и SSE для этого инструмента не используется.

Агент не знает, как устроены векторы и как склеиваются каналы. Ему дали кнопку «искать» и правила, когда её нажимать. Запрос можно сузить пространством Confluence или конкретным разделом документации.

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

Чем отличается от предыдущей схемы

В первой статье целевой production-схемой называли предварительную ACL-фильтрацию: права применяются до поиска. В прототипе на Qdrant так и было, ограничения лежали в payload рядом с каждым чанком. Эксперимент на синтетике показал, что одна коллекция обслуживает людей с разными доступами.

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

Поэтому проверку вынесли в ACL-шлюз. Indexer сначала находит кандидатов, потом отдаёт шлюзу идентификаторы страниц и пользователя, шлюз сверяется с Confluence, и в выдачу попадает только разрешённый текст.

Проверку нужно выполнять до передачи содержимого документов модели. Просить её самостоятельно скрывать закрытые сведения уже после чтения документа было бы слишком поздно.

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

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

Кому это нужно и где применить

Всем, кто строит внутреннего ассистента поверх Confluence, Notion, GitLab wiki или SharePoint с наследованием прав. Паттерн переносится почти без изменений.

• Поиск живёт отдельным сервисом с понятным интерфейсом, а не внутри промпта агента.
• Права проверяются в источнике, а не в копии. Одна точка правды.
• Выборка идёт с запасом, потому что отсев неизбежен.
• Агент получает до N раундов и явный лимит кандидатов, иначе он уходит в бесконечное уточнение.
• Отказ по правам возвращается отдельным полем, а не пустым результатом.
• Проверка факта в смежной системе (в разборе это Jira) вынесена в skill-инструкции агента.

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

Где подвох

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

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

Третье: название и ссылка в denied_results это решение про политику доступа, а не про код. Его придётся согласовывать с ИБ и, возможно, с юридическим отделом.

Брать или подождать: вердикт за 30 секунд

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

Подождать, если поиск ещё не доведён до reranker. Сначала качество выдачи, потом агент. Ставить многошаговое исследование на плохой индекс значит ускорить доставку мусора.

Не брать как готовое решение: это описание паттерна, а не библиотека. Код придётся писать под свои системы.

FAQ

Нужен ли MCP, если есть обычный API?

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

Почему нельзя проверить права до поиска?

Можно, и в прототипе на Qdrant так и делали. Проблема в сопровождении: права в Confluence меняются сами по себе, копию пришлось бы чинить постоянно.

Что будет, если за три раунда ничего не нашлось?

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

Сколько это стоит в железках?

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

Что делать дальше

Проверьте две вещи. Первая: где у вас хранится правда о правах доступа. Вторая: сколько кандидатов вы просите у поиска и что делаете с отсевом. Если на оба вопроса нет внятного ответа, агент вам пока рано. Если есть, разбор Рунити читается как инструкция.