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

Многочисленные маркетинговые материалы по применению ИИ пестрят видео, в которых ИИ-агент якобы решает все проблемы бизнеса и уже готов заменить штатных аналитиков. Подобная пропаганда формирует у пользователей ожидание, что достаточно «подключить модель» и система заработает. На практике это не так. В массовом восприятии нейросети до сих пор остаются «собеседниками», но для бизнеса этого недостаточно — нужен не диалог, а выполнение конкретных задач. Как показывает опыт разработки в Tengri Data, переход от демонстраций к рабочему инструменту лежит через понимание того, чем на самом деле является агент, и создание вокруг него жесткой технологической базы, системы ролей и прозрачной семантики.

Рис. 1. Архитектура ИИ-агента

Принципиальное отличие ИИ-агента от чата — автономность. Если обычная языковая модель работает по принципу «вопрос — ответ», то агент способен самостоятельно достигать поставленной цели, используя доступные инструменты (рис. 1).

Вместо простого ответа на вопрос агент может сам написать SQL-запрос, получить данные, проанализировать их и сформулировать вывод. Если результат некорректный, он переписывает запрос и повторяет попытку до получения приемлемого результата. При этом важно понимать, что агент — это не LLM, которая остается базовым элементом, но поверх нее строится логика, делающая систему автономной: планирование действий, работа с инструментами, память и учет контекста. По сути, агент — это сложная программная надстройка над языковой моделью, которая превращает алгоритм из интерфейса для общения в полноценный инструмент выполнения задач.

Подход «подключить GPT к данным» не работает

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

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

Рис. 2. Фундамент ИИ-агента

Для того чтобы ИИ-агент действительно приносил реальную пользу, он должен опираться на фундамент из трех слоев (рис. 2).

На нижнем уровне — данные компании. Если аналитику допустимо ждать доступа неделю, то агент должен его получать за минуты, иначе он просто не сможет работать. Следующий уровень — инструменты, через которые он взаимодействует с данными: SQL, Python. Система должна оперировать стандартными языками, на которых обучалось большинство языковых моделей, и применение менее распространенных технологий, таких как Hadoop или MapReduce, может вызвать проблемы. Третий и самый важный уровень — это данные о данных (метаданные), объясняющие, как все устроено. Именно этот уровень определяет, понимает ли система, с чем она работает, или просто генерирует ответы.

Семантика — основа понимания

Любой аналитический вопрос всегда упирается в смысл. Агенту важно понимать значения имен и терминов, с которыми он сталкивается: системе нужно заранее задать, что именно стоит за каждым понятием. Без четких определений и семантики работа заходит в тупик на простейших вещах. Например, на вопрос о количестве клиентов LLM не переспросит, что именно в данной компании считается «клиентом», хотя это единственный правильный вопрос в такой ситуации. Модель не уточняет контекст, а сразу пытается дать ответ, который будет формально корректным, но вряд ли верным по смыслу.

Опыт показывает, что аналитический агент может успешно работать внутри отдельных подразделений, но часто пасует в масштабах всей компании. Он не масштабируется, потому что в разных частях бизнеса одни и те же термины имеют разное значение. Например, такие базовые понятия, как «выручка» или «прибыль», в разных департаментах трактуются по-разному. Все эти смыслы, нюансы и формулы расчета метрик (например, правила определения retention, коэффициента удержания) формируют семантический слой, который должен быть сохранен и передан системе для корректной работы.

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

Tengri Data

Tengri Data — аналитическая платформа, в которой хранятся данные, обрабатываются и становятся доступными через единый слой вычислений и интерфейсов. Основная идея внедрения ИИ-агентов в платформу заключалась в том, чтобы не пытаться «приклеить» нейросеть сбоку, а сделать ее органичной частью системы.

ИИ-агент в Tengri Data — это такой же пользователь, как и человек. Он наделяется стандартными правами доступа, на него распространяются те же ограничения, а каждое его действие фиксируется в журналах. Такая архитектура превращает агента из внешней надстройки в органичную часть корпоративной экосистемы. Это позволяет не просто «запускать нейросеть» над базой данных, а создавать контролируемую рабочую среду.

Рис. 3. Архитектура Tengri Data

Для полноценной работы агента ему нужно окружение, как и у аналитика: SQL- и Python-вычислители, интерфейсы доступа к данным, API и хранилище (рис. 3). Как и аналитик, агент действует через инструменты, не имея прямого доступа к данным, а работая через контролируемый слой вычислений. Он не генерирует ответы, а выполняет действия: пишет запросы, обрабатывает данные и проверяет результат.

Рис. 4. Базовые когнитивные функции

Для обеспечения устойчивости в платформу добавляются механизмы, имитирующие базовые когнитивные функции (рис. 4).

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

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

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

Разделение ролей

Рис. 5. Взаимодействие виртуальных сотрудников

Как показывает опыт, попытка создания одного «всемогущего» агента неизбежно ведет к перегрузке модели и росту числа ошибок. Модель начинает терять контекст, хуже проверяет результаты и чаще дает нестабильные ответы. Гораздо эффективнее распределять задачи между специализированными ролями, имитируя структуру реального аналитического отдела. Это снижает нагрузку на каждый компонент и делает результат предсказуемым. В практике Tengri Data имеется три виртуальных сотрудника (рис. 5).

  • Аналитик @Теодор. Отвечает за работу с запросом. Он принимает вопрос на естественном языке, переводит его в SQL, проверяет результат и при необходимости переписывает запрос, пока не получит корректный ответ, после чего формулирует вывод.
  • Визуализатор @Даша. Отвечает за представление данных. Она не просто выводит цифры, а преобразует результат в код и строит дашборды, которые можно использовать в работе.
  • Архивариус @Арчи. Работает на базовом уровне с самими данными. Он сканирует таблицы и выявляет информацию, не зафиксированную документально, — до 80–90% фактов можно без участия человека извлечь из структуры и содержимого таблиц. Арчи формализует эти знания и вносит их в семантический слой, создавая основу, на которой работают остальные агенты.

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

Агенты на практике

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

Это важное отличие от обычной работы с LLM в режиме чата, когда модель сразу стремится дать ответ. В агентной системе вывод формируется на основе добытых из базы данных, а если в доступных таблицах нет нужных данных, то агент не начинает «додумывать». Он фиксирует, что в текущем контексте ответить не может. Именно здесь важна роль семантического слоя — пока в системе нет описания, агент ограничен тем, что видит в таблицах, но как только в семантический слой добавляются определения и связи, тот же самый вопрос начинает обрабатываться иначе. Агент получает контекст и может связать данные между собой. Меняется не модель, а качество понимания данных.

Результат

ИИ-агенты начинают приносить бизнесу результат не в момент подключения модели, а лишь после того, как в компании выстроена работа с данными: организован доступ к источникам, зафиксированы метрики и описан их смысл.

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

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

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

***

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

Николай Голов (n.golov@postgrespro.ru) — директор по продукту Tengri Data, компания Postgres Professional (Москва). Статья подготовлена на основе материалов выступления на конференции «Качество данных 2026».