Внедрение в процессы разработки

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

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

Начинайте с боли, а не с технологии

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

Кандидаты в «Маркете»:

• Онбординг разработчика в чужой домен. Переход в команду Логистики занимает недели, из которых половина уходит на поиск того, кто расскажет.
• Дежурство и разбор инцидентов. Ночью, по алерту, нужно быстро понять, было ли такое раньше и что тогда делали.
• Межкомандные вопросы по контрактам. Классика: «какие поля приходят в событии о выплате и когда оно публикуется».
• Ответы поддержки селлерам. Регламенты меняются, операторы отвечают по памяти.

Выбирая первую боль, проверьте три критерия одновременно:

1. Вопрос задают часто. Редкая боль не даст ни данных, ни привычки.
2. Ответ существует в письменном виде. RAG находит написанное; он не создаёт знание, которого нет. Если ответ живёт только в голове ведущего разработчика, сначала его нужно записать.
3. Цена ошибки терпима. Не начинайте с того, где неверный ответ стоит денег или инцидента. Доверие набирается на дешёвых вопросах.

Пилот на одном домене

Пилот запускают на одном домене, где сходятся все три критерия, и никогда сразу на всей компании.

В «Маркете» это Логистика: у неё много интеграций со смежниками, поэтому много входящих вопросов, и документация ведётся, потому что без неё не работают партнёрские подключения.

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

Кто владеет системой

Разделение, без которого проект гниёт за квартал:

• Платформенная команда владеет движком: индексация, поиск, доступы, метрики, стоимость. Её зона ответственности: «система работает и отвечает быстро».
• Доменные команды владеют контентом: актуальностью своих ADR, runbook, регламентов. Их зона ответственности: «ответы про наш домен правильные».

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

Это же разделение делает документацию чьей-то работой. Пока документация ничья, она устаревает; когда от неё зависят ежедневные ответы команде, у неё появляется владелец.

Встраивайте в существующие ритуалы, а не стройте портал

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

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

• Бот в командном канале. Вопрос задаётся там же, где его задали бы коллеге, и ответ видят все.
• Поиск в редакторе через MCP-сервер. Разработчик не выходит из задачи; агент сам обращается к базе знаний посреди работы.
• Комментарий в pull request. Ссылка на нарушенное соглашение приходит туда, где идёт ревью.
• Шаг в runbook дежурного. «Проверь похожие инциденты» становится частью процедуры, а не личной инициативой.
• Ссылка из шаблона задачи. Аналитик, заводя задачу, сразу видит связанные решения.

flowchart TB
    subgraph L ["Жизненный цикл задачи в «Маркете»"]
      direction TB
      A["Аналитик пишет требования"]
      B["Разработка"]
      C["Ревью"]
      D["Релиз"]
      E["Дежурство и инциденты"]
      A --> B --> C --> D --> E
    end
    KB[("База знаний: ADR, runbook, контракты, постмортемы")]
    KB -.->|"похожие решения домена"| A
    KB -.->|"поиск в редакторе"| B
    KB -.->|"нарушенные соглашения"| C
    KB -.->|"похожие инциденты"| E

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

Этапы

Четыре шага с критериями перехода. Критерии важнее сроков: переход по календарю вместо готовности разваливает проект.

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

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

Этап 2. Расширение. Больше доменов и источников, маршрутизация, реранкинг, разграничение прав. Переход дальше: качество на золотом наборе не просело при росте объёма индекса.

Этап 3. Встраивание. Система приходит в редакторы, каналы, ревью и runbook. Появляются инструменты поверх базы знаний, см. Инструменты вокруг RAG. Признак успеха: вопросы задают системе раньше, чем коллеге.

Что считать успехом

Метрики, которые имеют смысл:

• Время от вопроса до ответа по типовому межкомандному вопросу: было полтора дня, стало минуты.
• Время выхода разработчика на первую задачу в чужом домене.
• Доля вопросов в командных чатах, закрытых без участия человека.
• Обращения к ADR: раньше их писали и не читали, теперь на них ссылаются в ответах.

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

Типичные провалы

• Запуск на всю компанию сразу. Никто не отвечает за качество ни по одному домену.
• В индексе всё подряд. Ответы по черновикам и отменённым решениям убивают доверие за пару недель, а вернуть его дороже, чем заработать.
• Нет владельца контента. Дефекты некому чинить, платформа получает претензии, которые не может закрыть.
• Нет оценки. Спорить о качестве можно бесконечно, если нет набора вопросов.
• Система живёт отдельным порталом. Про неё забывают через две недели после презентации.
• Права доступа решены инструкцией модели. Работает ровно до первого человека, который переформулирует вопрос.
• Обещание «заменим экспертов». Гарантированное сопротивление тех самых людей, чьи знания нужно проиндексировать. Система снимает с них поток однотипных вопросов, и продавать её нужно именно так.

Что дальше

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