RAG в performance-маркетинге: где даёт пользу, а где это лишний слой

RAG в performance-маркетинге: где даёт пользу, а где это лишний слой

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

Хорошие кейсы:
— daily summary по кампаниям, если данные лежат в отчётах и заметках
— поиск ответов по базе креативов: какие углы уже тестили, что сработало
— ассистент для медиабайера: «как у нас принято настраивать UTM, naming, postback»
— внутренний саппорт по трекингу и антифрод-логике

Избыточно включать RAG, если задача уже решается структурированным API-запросом или маленьким жёстким промптом. Для проверки бюджета, статуса кампании или ставки не нужен векторный поиск: лишний retrieval добавит задержку, cost и новые точки отказа. Если источник один и он структурный — RAG чаще мешает, чем помогает.

Правило простое: сначала спрашивайте, можно ли решить задачу прямым tool call. Если нет — нужен ли агенту доступ к вашим текстам, где важны формулировки и история решений. Если да, RAG должен возвращать не «похожие куски», а короткий ответ с ссылкой на источник внутри базы. Иначе агент красиво перескажет шум.

Лучший тест для RAG — дать ему 20 типовых запросов от байера и посмотреть, где он ошибается: в retrieval, в суммаризации или в самом знании. Если ошибки идут на поиске, чистите чанки и метаданные. Если на ответе — ограничивайте роль модели и заставляйте цитировать найденное, а не сочинять поверх него.