ИИ-агент: что это и что агенты умеют в аналитике данных

ИИ-агент — короткий ответ

Представьте утренний вопрос от руководителя: «Почему упала выручка по рейсам?» В обычном чате вы получили бы предположение и, возможно, черновик SQL. ИИ-агент получает ограниченный набор инструментов, сам выбирает следующий шаг, выполняет запрос, видит результат и корректирует план. Его цикл — план → действие → наблюдение → следующий шаг. Но итоговая фраза всё ещё требует проверки: инструмент может точно выполнить ошибочный запрос.

Рабочее определение такое: ИИ-агент — система, в которой модель управляет последовательностью действий через разрешённые инструменты и использует результаты этих действий для достижения цели. Это не синоним любой нейросети. Если в интерфейсе написано «агент», посмотрите на след действий: были ли реальные вызовы базы, файлов или кода, какие аргументы ушли и что вернулось.

Для аналитика полезная граница начинается раньше автономности. Сначала задайте цель, источник, право на чтение, контрольную цифру и точку остановки. Затем дайте агенту выполнить ограниченную цепочку. Если не можете восстановить, откуда взялся показатель, результат нельзя отправлять руководителю только потому, что он выглядит правдоподобно.

Из каких частей состоит агент

Первый слой — модель. Она читает задачу и контекст, предлагает план, выбирает инструмент и формулирует ответ. Второй — инструменты: SQL-запрос, чтение файла, запуск Python, поиск по документации, запись в заметку. Третий — управляющая оболочка, которая решает, какие инструменты доступны, сколько шагов допустимо, нужно ли согласование и какие события записать в журнал. Без этой оболочки красивое обещание «агент всё сделает» ничего не говорит о безопасности.

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

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

Почему чат, сценарий и агент дают разный риск

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

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

Иногда в продукте «агентом» называют последовательность фиксированных вызовов LLM и API. Это скорее workflow; для пользователя важнее контракт: что разрешено, что сохраняется, где требуется человек. Не спорьте о вывеске. Спросите, способен ли исполнитель самостоятельно изменить маршрут после наблюдения и есть ли протокол этих изменений.

Сценарий аналитика: один вопрос о рейсах

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

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

Чтобы пример не превращался в театр, зафиксируйте входной датасет, запросы и ответы инструментов. Для учебной базы «Авиаперевозки» в нашем эксперименте эталонная выручка по файлу за 5 августа составила 438 406 200 ₽. Этот результат получен кодом по 548 строкам, а не текстовым «счётом» модели. Мы не тестировали именно агентный продукт на этих данных; число здесь служит контрольной точкой для метода проверки.

Какие действия агент уже может выполнять

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

Официальная документация Claude Code описывает работу с файлами и запуск команд; документация Cursor Agent — поиск по проекту, правку файлов и терминал. Для аналитика это полезно при создании скрипта или проверки запроса, но доступ к терминалу гораздо шире доступа к одной таблице. Настройка проекта и разрешения определяют фактический риск. Продуктовые названия здесь примеры классов инструментов, не рейтинг качества.

Готовый отчёт — тоже несколько действий: открыть источник, вычислить метрику, проверить её, собрать текст и сохранить артефакт. Чтобы не потерять контроль, разделите этапы. Пусть агент вернёт SQL и таблицу контроля до того, как напишет объяснение. А отправку письма, изменение дашборда или загрузку файла во внешний сервис оставьте отдельным действием с явным решением человека.

Как ошибка накапливается в длинной цепочке

Предположим, первый запрос неверно соединяет рейсы и билеты: строк становится больше. Инструмент SQL исполняет запрос без ошибки синтаксиса. Агент принимает увеличенную сумму как исходный факт и строит диаграмму. Затем он видит самый большой столбец и пишет, что один аэропорт обеспечил рост. На каждом шаге выход выглядит аккуратнее, хотя первичная ошибка никуда не исчезла.

Другой сбой начинается с незаметного фильтра. Модель решила, что «выручка» означает оплаченные билеты, а команда считает только выполненные рейсы. Разница не исправляется повторным запуском. Нужна внешняя спецификация метрики. Если такой спецификации нет, честный результат — два расчёта с подписями и вопрос владельцу показателя, а не уверенный выбор за него.

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

Контроль на каждом шаге

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

Храните журнал вызовов: постановка, дата среза, идентификатор версии данных, SQL или код, параметры, ошибки инструмента, число строк ответа, итог. Для повторного анализа достаточно файла с запросом и выводом, но он должен быть доступен другому аналитику. Если в отчёте фигурирует «снижение на 12%», по журналу должен находиться исходный знаменатель и способ округления.

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

Доступ к базе: отдельная роль и только нужные данные

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

Права базы важнее текста инструкции «ничего не меняй». Модель способна ошибиться, данные могут содержать подсказку от атакующего, а сервер-инструмент может иметь собственный дефект. Роль без права UPDATE не сможет исправить таблицу по внезапной «полезной» инициативе агента. При этом SELECT может читать персональные данные; read-only не равно безопасно для приватности.

Ограничьте не только запись, но и объём чтения: отдельная витрина, маскирование полей, лимит строк, таймаут запроса. Результат может уйти в контекст внешней модели, поэтому согласуйте политику обработки. Подробнее о протоколе подключения, SQL-роли и конфиге — в отдельном разборе MCP.

Сколько стоит автономность

Каждый шаг агента может включать новый вызов модели: ей снова передают задачу, историю и результат инструмента. Длинный вывод SQL или целый файл занимает контекст; повторные попытки увеличивают расход и время ответа. Единой цены «за агента» нет: она зависит от модели, числа итераций, объёма возвращаемых данных и условий сервиса. Поэтому вместо калькуляции по рекламе измеряйте собственные запуски.

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

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

Воспроизводимость: что сохранить после сессии

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

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

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

Четыре ошибки, которые портят аналитический ответ

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

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

Третья: принимать успешный SQL за верную арифметику. JOIN может умножить строки и пройти без ошибок. Последствие — неверная сумма в отчёте. Лечение — контроль зерна, числа строк и независимый итог.

Четвёртая: скрыть цепочку действий и дать агенту сразу публиковать отчёт. Последствие — нельзя найти источник неверной цифры, а ошибка разойдётся по команде. Лечение — журнал и ручная точка утверждения перед публикацией. Пятая: разрешить неограниченные повторные вызовы; это съест время и бюджет без улучшения доказательства.

Когда выбрать агента, а когда хватит SQL или скрипта

Если вопрос известен и повторяется каждую неделю, сохранённый SQL и расписание чаще дают более прозрачный результат. Если нужно один раз рассмотреть разные гипотезы по новой схеме, агент может быстрее подготовить маршрут. Но даже в таком случае лучшая роль агента — разведка с ограниченными правами и проверяемыми промежуточными результатами, а не источник окончательной истины.

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

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

Как оценить пилот на собственных задачах

Соберите небольшой набор вопросов, для которых уже существует проверенный ручной ответ. Включите простой агрегат, запрос с соединением таблиц, задачу с пропусками и вопрос, где определения метрики пока не хватает. Для каждого случая сохраните правильный SQL, ожидаемую таблицу, допустимый интервал округления и критерий, когда агент обязан остановиться и спросить человека. Такой набор лучше показательного диалога: он измеряет поведение на типичных для вас ошибках.

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

После пилота выберите границу автоматизации. Например, агент готовит SQL и табличный разбор, а аналитик утверждает интерпретацию; либо агент проверяет качество выгрузки, но не публикует отчёт. Зафиксируйте эту границу в правах и процессе, а не только в инструкции модели. Если новые данные или версия инструмента меняют поведение, повторите тот же набор вопросов.

Чек-лист перед запуском агента

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

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

Если в сессии выяснилось, что доступа или определения недостаточно, правильный ответ — остановиться и сформулировать, что требуется. Агент, который честно обозначает недостающий источник, полезнее агента, который заполняет пробелы догадкой.

• У входных данных известны версия и владелец.
• Права допускают только нужное чтение.
• Каждая цифра указывает на запрос и контроль.
• Публикация требует отдельного подтверждения.

Частые вопросы

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

Может ли ИИ-агент сам анализировать базу данных? Да, если приложение подключило инструмент доступа и выдали права. Он может писать и выполнять SQL, но определение метрики, качество JOIN и итоговый вывод требуют проверки.

Чем агент отличается от чат-бота? В простом чате переход от текста к действию обычно делает человек. Агент может сам выбрать разрешённое действие, увидеть ответ и продолжить работу. Конкретный продукт может сочетать оба режима.

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

Как не дать агенту испортить данные? Отдельная роль БД без прав записи, ограниченный набор инструментов, read-only режим сервера и ручное подтверждение внешних действий снижают риск. Одной фразы «не изменяй данные» недостаточно.