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

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

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

Хорошие задачи для RAG:
— daily/weekly report из внутренних доков и прошлых созвонов
— поиск причины просадки по заметкам байеров и changelog-ам
— подсказки по структуре кампаний, если у команды есть единый playbook
— саппорт-бот для медиабаеров, который отвечает только по вашим SOP

Избыточен RAG там, где есть API и жёсткая схема: выгрузить статистику, посчитать CTR/CPA, сверить spend, отправить алерт. Тут лучше прямой tool-call, а не «поиск по базе». Иначе платите токенами за то, что можно взять одной функцией. Ещё хуже — когда база грязная: дубли, старые версии SOP, разные термины для одного и того же события.

Правило простое: если вопрос можно ответить SQL/API-запросом — не тащите RAG. Если нужен контекст из текстов, решений команды и разбросанных документов — RAG оправдан. Лучший паттерн для perf-команды: сначала structured data через инструменты, потом RAG только для объяснения и рекомендаций.

Итог: RAG — это не «мозг агента», а слой памяти для неструктурированных знаний. Сначала чистим источники, потом подключаем поиск, и только потом даём агенту говорить с командой.