Почему одной LLM оказалось недостаточно и как мы связали языковую модель с данными, API и интерфейсом геоаналитической платформы.

Платформа для геоаналитики

2ГИС Про — это BI-платформа для геоаналитики, в которой карта является основным интерфейсом работы с данными. С помощью 2ГИС Про можно решать прикладные задачи: анализировать конкурентов в районе, оценивать распределение и объём автомобильного трафика, создавать слои из своих данных, визуализировать результат на карте и дополнять его виджетами.

Но у такой гибкости есть обратная сторона.

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

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

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

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

Здесь важно сразу разделить термины. Чат — это только форма общения с пользователем: окно, в котором он пишет запрос и получает ответ. LLM — языковая модель, которая помогает понять естественную формулировку и сгенерировать текст. А ИИ-ассистент в 2ГИС Про — это уже вся система: она использует LLM, но также работает с контекстом дашборда, инструментами продукта и API.

Мы не пытались сразу заменить аналитику моделью или сделать «универсального советчика». Начали с более конкретного сценария — научить ассистента собирать дашборд по команде в чате.

Например, пользователь пишет:

«Покажи кафе в районе Арбат, Москва с рейтингом выше 3»

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

Такой сценарий полезен сразу нескольким группам пользователей. Аналитикам он помогает быстрее собирать отчеты для клиентов. Клиентам — быстрее переходить от своей бизнес-задачи к готовому дашборду. Менеджерам по продажам — показывать возможности продукта без необходимости глубоко помнить все настройки и сценарии работы.

В этой статье рассказываю, почему такой ассистент оказался не просто чат-ботом, а агентом над картой, инструментами и API 2ГИС Про.

Почему одной LLM недостаточно

В таких продуктах как 2ГИС Про сложность часто возникает не потому, что в системе нет нужных данных или инструментов. Наоборот: проблема в том, что данных и инструментов много.

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

«Хочу посмотреть хорошие кафе на Арбате»

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

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

А в 2ГИС Про можно создать цифровой двойник местности: организации, здания, территории, с их уникальными атрибутами. Поэтому запрос про кафе можно обработать не как вопрос «вообще», а как прикладную операцию внутри продукта.

LLM в такой схеме — не источник фактов и не двигатель геоаналитики. Она помогает понять запрос пользователя и перевести его в действия внутри продукта. А результат получается уже через данные 2ГИС, API, фильтры, слои, карту и контекст текущего дашборда.

Именно поэтому мы пришли не к «чату с LLM», а к агентной системе поверх продукта.

Как ассистент собирает дашборд

В статье будем использовать один сквозной пример:

«Покажи кафе в районе Арбат, Москва с рейтингом выше 3»

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

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

Внутри запрос раскладывается на параметры: территория — Арбат, набор данных — «Фирмы», категория — кафе, фильтр — рейтинг выше 3. После этого ассистент вызывает инструмент создания слоя и передаёт в него территорию, категорию и фильтр.

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

Важно, что ассистент не «знает», какие кафе есть на Арбате. Он понимает задачу и запускает нужные действия внутри 2ГИС Про.

Записанное короткое видео 20-40 секунд, как ИИ-ассистент собирает дашборд по запросу.

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

Почему это именно агент

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

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

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

Такой сценарий нельзя нормально описать одной кнопкой. Для него нужен слой, который понимает запрос, видит контекст и выбирает следующий шаг. Эту роль и выполняет агент: он связывает естественный язык пользователя с инструментами и API 2ГИС Про.

Что нужно агенту для работы

Чтобы агент мог работать внутри 2ГИС Про, ему нужны не только LLM и текст запроса.

В основе агентной логики используется ReAct-подход (ReAct: Reasoning + Acting: агент чередует рассуждение о следующем шаге и действие — например, вызов инструмента или API): агент не пытается сразу выдать финальный ответ, а действует по шагам. Он смотрит на запрос пользователя и контекст продукта, выбирает следующий инструмент, получает результат его выполнения и после этого решает, что делать дальше — вызвать еще один инструмент или уже вернуть ответ пользователю. 

2ГИС Про — это веб-продукт, где фронтенд отображает карту, слои, фильтры, виджеты и дашборды, а бэкенд отвечает за данные, операции и сохранение состояния. Фронтенд и бэкенд общаются через API: когда пользователь создает слой, меняет фильтр или открывает дашборд, интерфейс отправляет запросы к бэкенду и получает обновленное состояние.

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

Для этого агенту нужны три вещи.

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

Вторая — инструменты: операции продукта, которые агент может вызвать через API.

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

В итоге агент работает как прослойка между запросом пользователя и уже существующей логикой 2ГИС Про: понимает фразу, смотрит на контекст, вызывает нужный API и возвращает результат в интерфейс.

Что происходит под капотом

Возьмём наш сквозной пример:

«Покажи кафе в районе Арбат, Москва с рейтингом выше 3».

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

{

 "tool": "create_layer",

 "args": {

   "layer_name": "Кафе на Арбате",

   "asset": "Фирмы",

   "territories": [

     {

       "name": "Арбат"

     }

   ],

   "categories": ["кафе"],

   "need_extra_filters": true

 }

}

Дальше начинается обычная серверная логика: через API находится территория, определяется категория, подтягиваются доступные атрибуты. Условие «рейтинг выше 3» переводится в формальный фильтр:

rating:[3 TO *]

После этого фильтр приводится к формату, который понимает API 2ГИС Про, и используется при создании слоя. В интерфейс уходит событие о создании слоя, карта обновляется, а пользователь получает пояснение, что было найдено и какие условия применились.

А что с вопросами по самому продукту

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

Для этого рядом с основным агентом есть отдельный RAG-сценарий по документации 2ГИС Про. Он не создает слои и не меняет дашборд, а работает как справочный контур: ищет ответ в документации и объясняет его пользователю.

Так мы разделяем две роли: основной агент выполняет действия внутри продукта, а RAG помогает разобраться с продуктом и его возможностями.

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

Где пришлось поставить ограничения

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

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

Такой подход нужен не потому, что мы хотим искусственно ограничить ассистента. Просто в BI- и GIS-продуктах любое автоматическое действие меняет рабочее пространство пользователя: создает слои, обновляет карту, добавляет виджеты. Поэтому поведение должно быть предсказуемым.

Есть и более содержательные ограничения. Например, запрос:

«Оцени, насколько хороша эта локация»

звучит естественно, но это уже не просто создание слоя или применение фильтра. Для такого сценария нужна отдельная модель оценки, набор метрик и понимание бизнес-контекста: для кафе, аптеки и банка «хорошая локация» будет означать разное.

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

Что в итоге получилось

Мы начинали не с идеи «заменить интерфейс нейросетью», а с более прикладной задачи: сократить путь от пользовательского запроса до готового дашборда.

В результате ассистент стал не отдельным чат-ботом рядом с продуктом, а слоем поверх 2ГИС Про. Он понимает запрос пользователя, подтягивает контекст, вызывает нужные инструменты через API и возвращает результат в интерфейс: слой на карте, настроенные фильтры, виджеты или пояснение.

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

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