Почему агент на сырых данных отвечает чушью — и какой слой подготовки это исправляет

Самый быстрый способ разочароваться в ИИ-агенте — дать ему сырую выгрузку и попросить найти причину падения конверсии.

Ответ придёт через несколько секунд. Уверенный, структурный, с цифрами.

И почти наверняка неверный.

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

Честно — я не верю ответам агента на сырых данных. Не потому, что он глупее. А потому, что у него нет ни полного массива, ни определений, ни права эти определения придумывать.

Что происходит, когда агенту дают сырьё

У агента есть контекст — объём текста, который он держит в работе за один раз. Он не бесконечный. Если вставить в чат файл на десятки тысяч строк, внутрь попадёт не весь файл.

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

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

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

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

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

И даже если все строки на месте, модель — не калькулятор. Она предсказывает следующий фрагмент текста, а не гарантирует арифметику. Сумму, среднее и конверсию надёжнее считать формулой или кодом.

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

В сырой выгрузке нет главного — смысла. Что считается лидом? Какой статус платежа считать оплатой? Что делать с отменёнными заказами и частичной оплатой? Где дубли? Какая дата главная? Как учесть два кабинета и две валюты? Агент ответит на эти вопросы сам. Молча. И не факт, что так же, как ответили бы вы.

Выглядит это по-разному, причина одна: у агента нет слоя, который превращает строки в данные.

• Обрезали объём. В контекст попала часть таблицы, а вывод сделан по всей.
• Потеряли связи. Таблицы соединили не по тому ключу или не соединили вовсе.
• Подменили определение. Лид, заказ и платёж посчитали одной сущностью.

Почему промпт не решает проблему

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

Промпт меняет формулировку вопроса. Слой подготовки меняет то, на что вопрос отвечает.

Есть простые признаки, что агент работает на сырье:

• называет цифры, которых нет в отчёте;
• на один и тот же вопрос отвечает по-разному;
• не может показать путь от цифры до записи;
• путает лиды, заказы и оплаты;
• говорит «примерно» там, где нужна точная сумма;
• не знает, что часть данных не загрузилась.

Если узнали хотя бы два пункта, дело не в модели.

Мой порядок: пять слоёв, агент — сверху

Мой порядок выглядит скучно. Именно поэтому он работает.

Слой 1. Собрать источники в одно место. Рекламные кабинеты, GetCourse, Метрика, CRM, телефония. По каждому источнику — период, валюта, часовой пояс, ключ. Не в один файл, а в слой, где у каждого источника своё место и своя история.

Раньше это была отдельная работа на недели. Сейчас вайбкодинг на Чатиум позволяет собирать коннекторы быстро: API, регулярная догрузка, история. Но скорость сбора не отменяет вопроса «что именно мы собираем».

На этом слое ещё нет аналитики. Есть сырьё, к которому можно вернуться.

Слой 2. Навести порядок. Это самый нелюбимый и самый важный слой. Здесь данные превращаются в таблицы, с которыми можно работать.

• один факт — одна строка: заказ, платёж, регистрация, расход, звонок;
• статусы: получен, отменён, возврат, частичная оплата;
• сущности: лид, заказ и платёж — разные, их нельзя складывать;
• ключи: uid, номер заказа, UTM, client id, телефон;
• словари: кампании, каналы, продукты, подрядчики;
• время: дата регистрации, дата заказа и дата платежа — не одно и то же;
• деньги: валюта, курс, комиссия;
• дубли и технические записи;
• «не распределено» и «неизвестно» — разные вещи.

После этого прошу агента найти закономерности и аномалии. Не «посчитай выручку», а «посмотри, где дыры, дубли, странные всплески, что не сходится между таблицами». Агент хорошо видит паттерны. Но его находка — не истина, а повод проверить.

Проверяю на адекватность: контрольные суммы, сверка с источником, один заказ вручную, разумность диапазонов. Отрицательная выручка или доходимость 300% — это не инсайт, это ошибка слоя.

Слой 3. Посчитать метрики. Здесь появляются определения, без которых дальше нельзя. Маркетинг: расход, CPL, CAC, ROAS, ROMI, ДРР. Деньги: выручка, средний чек, прибыль. Клиенты: LTV, повторные покупки, когорты.

У каждой метрики — формула, источник, фильтры, окно и список исключений. Не в голове, а в документе и в коде.

• CPL — расход на лид. Но лид надо определить: заявка с формы, регистрация, диалог? Если в лиды попадают технические записи, CPL занижен.
• ROAS — выручка на расход. Выручка за какой период? По календарю или по когорте? С учётом возвратов или без? Два ответа — две разные цифры.
• LTV — сколько клиент приносит за время. Пока окно не закрыто, LTV недосчитан. Когорты разного возраста сравнивать нельзя.
• Прибыль — не «выручка минус реклама». Если вычитаете только рекламу, вы видите прибыль до остальных расходов, а не прибыль бизнеса. Для управленческой прибыли нужны все согласованные расходы, и это надо назвать своим именем.

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

Слой 4. Собрать дашборд поверх расчётов. Не вместо и не до. Дашборд — это интерфейс к посчитанным метрикам: период, фильтр, разрез, расшифровка.

Один экран — один вопрос. Не «всё про школу», а «почему изменилась окупаемость», «откуда пришли платежи», «какие когорты дозрели».

На этом слое видно, чего не хватает. Если для ответа нет метрики, дашборд это покажет. Лучше здесь, чем в разговоре с собственником.

Слой 5. Посадить агента на посчитанное. И только теперь он появляется. Он получает не выгрузку, а посчитанные метрики и понятные инструменты: «покажи ROAS по каналу за полгода», «сравни когорты одного возраста», «разложи падение на CPL, конверсию и чек».

Он отвечает цифрами, потому что видит посчитанное. Не «примерно», не «в среднем по рынку», а число, которое можно открыть на экране.

Разница в вопросах видна сразу. Плохой: «Вот выгрузка, почему упал ROAS?» Хороший: «Покажи ROAS по каналам за шесть месяцев. Если упал — разложи на CPL, конверсию в оплату и средний чек. Сравни с предыдущим периодом». В первом случае агент ищет объяснение в куске данных. Во втором — считает по готовым метрикам.

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

Три проверки по цепочке

Проверяю не по красоте отчёта, а по цепочке.

1. Данные — с источником. Любая цифра раскручивается до записи: заказ → платёж → кабинет → кампания. Если путь обрывается, перед вами гипотеза, а не факт.
2. Формула — с методикой. У метрики есть определение, период, фильтры и исключения. Если методики нет, два человека посчитают по-разному — и оба будут правы.
3. Ответ агента — с дашбордом. Если агент назвал цифру, которой нет на экране, это не ответ, а повод разобраться.

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

Где здесь 152-ФЗ

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

Поэтому данные клиентов остаются на серверах в РФ — как требует 152-ФЗ. Отдельный контур на школу, доступы по ролям, выгрузки только по необходимости.

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

Когда данные приведены в порядок, персональные записи можно вообще не тащить в модель. Метрик достаточно.

Что меняется, когда слои на месте

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

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

Что сделать на этой неделе

1. Выпишите источники и то, что из каждого нужно.
2. Соберите в одну таблицу хотя бы оплаты и расходы.
3. Определите пять метрик: лид, оплата, CPL, ROAS, LTV. Формулы запишите.
4. Проверьте один заказ по цепочке.
5. Соберите один экран под один вопрос.
6. Только после этого подключайте агента — к метрикам, а не к сырью.

Сырые данные — это не вход для агента. Это вход для подготовки. Агент приходит после — и отвечает цифрами, потому что до него их уже посчитали.