Инструменты вокруг RAG

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

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

1. Вопрос-ответ по домену

Бот отвечает на вопросы в командном канале со ссылками на источники. Минимальный полезный продукт: с него начинают почти все, и в первую очередь им пользуются смежники, которым нужно что-то узнать про чужой домен.

Проверяется по золотому набору вопросов: нашёлся ли верный источник, есть ли в ответе ссылка, умеет ли система сказать «не нашёл».

2. Навигатор для новичка

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

Я перехожу в команду Логистики. Расскажи по документации:
какие сервисы входят в домен, какой из них главный,
где описан расчёт срока доставки и какие соглашения
по коду приняты в команде. Дай ссылки на источники.

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

3. Поиск владельца и экспертизы

Отвечает на вопрос «кто знает про биллинг рекламных кампаний»: сопоставляет историю изменений в коде, авторов архитектурных решений и участников обсуждений. Нужен тем, кто ищет собеседника, а не документ.

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

4. Помощник дежурного

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

Алерт: рост ошибок 5xx в сервисе выплат, началось в 03:40.
Найди похожие инциденты за последний год, их причины
и runbook, который применяли. Дай ссылки.

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

5. Ассистент ревью

В комментарии к pull request подсказывает нарушенные соглашения команды со ссылкой на документ, где они зафиксированы. Заменяет «у нас так не принято» на «см. ADR-14».

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

6. Проверка требований на противоречия

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

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

7. Генерация тест-кейсов

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

Возьмите закрытый релиз и сравните сгенерированные сценарии с багами, которые тогда нашли и пропустили. Подробнее о работе с агентом в этой роли рассказано в треке тестировщика.

8. Помощник поддержки селлеров

Отвечает операторам поддержки по внутренним регламентам и публичной справке, со ссылкой на пункт регламента.

Требования здесь строже, чем у всего остального: ответ уходит наружу, а ценой ошибки становятся деньги партнёра. Обязательны разграничение прав (оператор не должен видеть индивидуальные условия чужих контрактов), обязательная ссылка на пункт и ответ «не нашёл» вместо догадки.

9. Сводки для менеджера

Собирает по документам ответ на вопросы вида «какие решения по выплатам приняты за квартал, кем и почему», «что менялось в контракте события о доставке».

Сверьте сводку с реальным списком решений за период. Особенно опасна здесь неполнота: пропущенное решение в сводке никак не видно.

10. База знаний как MCP-сервер

Последний инструмент отличается от предыдущих девяти: он отдаёт поиск по базе знаний не человеку, а агенту, обычным инструментом по протоколу MCP. Агент сам решает, когда обратиться к базе, посреди своей задачи.

При виде готового индекса возникает соблазн построить ещё один чат. Но у разработчика уже есть агент, у аналитика уже есть агент, и оба работают внутри своих задач. Отдав поиск инструментом, вы получаете базу знаний во всех этих местах сразу и бесплатно: агент, правящий код в домене Платежей, сам сходит и прочитает ADR про возвраты, не спрашивая человека. Заодно это самый практичный способ построить агентный RAG, уровень 5 из вариантов архитектуры.

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

Сводная таблица

Инструмент	Кому	Сложность	Что должно быть в индексе
Вопрос-ответ по домену	всем, в первую очередь смежникам	низкая	ADR, регламенты, контракты API, README и runbook домена
Навигатор для новичка	новым в команде и переходящим между командами	низкая	карта сервисов, ADR, README, схема окружений, документы онбординга
Поиск владельца	всем	средняя	история коммитов и авторства, ADR с авторами, задачи, метка команды-владельца
Помощник дежурного	дежурным, SRE, поддержке	средняя	постмортемы, runbook, описания алертов, история инцидентов
Ассистент ревью	ревьюерам и авторам изменений	средняя	ADR, гайдлайны, обсуждения прошлых ревью
Проверка требований	аналитикам, продуктовым менеджерам	средняя	ADR, регламенты, ранее написанные требования
Генерация тест-кейсов	тестировщикам	средняя	требования, баг-репорты, постмортемы, тест-планы
Помощник поддержки	поддержке	высокая	регламенты работы с селлерами, публичная справка, история обращений, права доступа
Сводки для менеджера	руководителям команд и направлений	высокая	ADR с датами и авторами, история изменений контрактов, задачи
База знаний как MCP-сервер	всем, кто работает с агентами	высокая	всё вышеперечисленное

Что дальше

Трек: программист: как выглядит ежедневная работа с агентом у разработчика.
Трек: менеджер: как оценивать пользу и внедрять ИИ-инструменты в команде.

Автор учебника: Шахматов Алексей