AI-агент проверяет гипотезу за минуты вместо недель. Разбираю, почему его ответам можно верить

Одна гипотеза в банке упирается в очередь к данным. После 4 уточнений она тянется до 28 рабочих дней. Это оценка по этапам цепочки, но эту очередь узнает любой продакт.

Допустим, продуктолог хочет понять, где вырастить доход от эквайринга. Он пишет заявку аналитику, она до недели стоит в очереди, потом он ещё от 0,5 до 3 дней ждёт выгрузку. Смотрит выгрузку, уточняет вопрос, и заявка снова встаёт в очередь: ещё от 4 часов до недели.

AI-агент проверки гипотез знает схему хранилища, сам пишет SQL и отвечает за минуты. Это один из моих проектов: постановка задачи, устройство агента, метрики для пилота и дорожная карта мои. Я продуктолог, много лет строю продукты в банках, последний год перевожу команды на AI-native модель.

Ниже я разберу по шагам один вопрос, покажу три слоя проверки и цифры пилота аналогичного агента. Сессия агента восстановлена по приёмам боевого кода, а числа в ней условные. Реальные данные банков закрыты NDA. Откуда каждая цифра, я пишу рядом с ней.

Продуктолог пишет агенту обычными словами: «где вырастить доход от эквайринга?». Заявки аналитику нет.

Сначала агент открывает свои правила: только чтение через SELECT, WITH и EXPLAIN, только закрытые месяцы, доход клиента из поля income_month. Если данных нет, агент так и говорит, а не угадывает.

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

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

Запрос агент пишет сам. Перед базой стоит защита: она пропускает select, with и explain, а delete отклоняет. В этой сессии вышло 14 строк за 2,8 секунды.

Ответ: в Регионе 1 эквайринг у 20% клиентов, в среднем по портфелю у 47%. Если подтянуть слабые регионы до среднего, банк получит ещё 260 млн рублей в месяц. Это пример расчёта для крупного банка, а не цифра конкретного банка.

По пути агент заметил три зацепки. У части клиентов тают платежи: риск оттока? Новые когорты держатся лучше: дело в тарифе? У клиентов нет второго продукта: кросс-продажа? Копать сейчас или отложить, решает продуктолог.

Главный вопрос к такому агенту: что будет, если он уверенно ошибётся?

Первый слой ловит ошибку в данных до ответа. Пример из моего кода, данные синтетические. Средний доход 124 000 клиентов вышел нулём. Агент не пишет «данные не сошлись», а проверяет три версии, у каждой свой запрос. Период: август загружен на 12% от обычного объёма, месяц ещё не закрыт. Это причина. Совпадения: 0 из 124 000, у клиентов нет строк выручки за август. Это следствие той же причины. Единицы: значения в рублях, версия снята. Вывод агента: считать по последнему полному месяцу. Если не подтвердилась ни одна из трёх версий, агент возвращает отказ с числами каждой проверки.

Второй слой отделяет тезис от гипотезы. Утверждение становится тезисом, только когда в базе есть все нужные источники. Для разрыва по эквайрингу их три: проникновение по регионам и отраслям, среднее по портфелю и доход клиента с продуктом. Все три есть. Агент пишет тезис: «В Регионе 1 проникновение вдвое ниже среднего по портфелю». А утверждение про комиссию могут подтвердить только отзывы клиентов. Пока их нет, агент оставляет его гипотезой и называет, каких данных не хватает: отзывов клиентов об эквайринге за полгода. Шлюз доказательств я взял из кода моих агентов. Данные в карточках синтетические.

Третий слой держит контур. Агент работает с обезличенным срезом хранилища внутри закрытого контура банка. Языковая модель тоже стоит внутри, данные наружу не уходят. Каждый запрос агента к витрине только читает. Таймаут 15 секунд обрывает долгий запрос, а после выполнения база всё откатывает. Менять код, настройки и базу агент не может. Это делает отдельный агент-исполнитель по заявке, после проверки.

Аналитик за итерацию смотрит около 10 разрезов, агент на одну гипотезу делает 20–30 и больше. Так было в пилоте аналогичного агента.

Новых таблиц для этого не нужно. Берём 20 типов данных, которые уже лежат в базе банка: платежи, обороты по картам, эквайринг, кредиты, депозиты, отрасль, регион, сезонность, отзывы и другие. Сочетаний по 2–5 типов из 20 выходит 21 679. Команде аналитиков их не перебрать.

В пилоте аналогичного агента около 70% находок прятались в деталях поведения клиентов. Они видны только на пересечении нестандартных срезов, аномалий и разных источников, поэтому при обычной работе их пропустили бы.

Так агент шёл к находке про эквайринг, ход восстановлен. В слабом регионе продукт у 20% клиентов, в сильном у 63%. Разрыв сидит в отдельных отраслях. Там часть клиентов каждый месяц платит картами банка. Их и стоит подключать первыми. Почему они до сих пор без продукта, агент предполагает: из-за комиссии. Но это гипотеза, и он просит отзывы клиентов об эквайринге за полгода. С аналитиком каждый такой круг занимает дни, с агентом минуты.

Второй пример из моей практики, про удержание. Банк отправляет 100 клиентам предложение остаться. Если выбирать их по дашборду, уйти собирались 10, по отчёту аналитика 30, по списку агента 80. Агент разбирает каждого клиента: оборот, платежи, остатки, продукты, и сводит это с тем, что говорили в звонках и отзывах ушедшие клиенты с похожим поведением. Чтобы предложение дошло до 100 уходящих, по дашборду нужно 1 000 предложений, агенту 125.

Цифры ниже из внешнего пилота аналогичного агента. Я их не пересчитывал. За 8 рабочих дней было 11 сессий, 306 запросов, 61 гипотеза, 329 инсайтов и 277 аналитических обращений. По медиане гипотезу проверяли около 10 минут, а раньше неделями. Освободилось 400+ часов работы аналитика.

На одного продуктолога это 7–10 проверенных гипотез в день вместо 2–3 итераций в неделю. Инсайтов у него около 36 в день. Гипотезы и инсайты здесь разные показатели. Все цифры взяты из презентации пилота, без пересчёта на команду и месяц.

Сейчас аналитик тратит до 60–70% времени на рутинные выгрузки. С агентом он становится куратором: берёт сложные расчёты, проверяет выводы агента и учит его правилам данных. Решают по-прежнему люди. Одного-двух аналитиков тогда хватает на 5–10 команд, и под новую команду не нужно нанимать ещё одного. Это расчёт по цифрам пилота, а не его результат.

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

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

Пилот идёт 1–2 месяца. До и после меряем срок проверки гипотезы, число проверенных гипотез и время аналитика на команду. Дальше 2–3 месяца подключаем хранилище и строим иерархию агентов, потом переходим ко всему банку. Состав пилота и этапы: мой план.

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

https://stapel.studio/ai-process/hypothesis-agent

А у вас сколько раз гипотеза возвращается к аналитику, пока ответ не устроит продукт?