Как фронтенд берёт на себя интеграцию LLM: опыт DataLens и архитектура «нейро»-фич — VogueTech

Что нового

Команда DataLens в Yandex Cloud добавила в BI‑систему «Нейроаналитик» — чат‑ассистента на базе LLM, который:

строит графики по запросу пользователя;
пишет формулы для расчётов;
помогает решать аналитические задачи прямо в интерфейсе дашборда.

Главное не сам ассистент, а подход к его интеграции:

первый этап работы с LLM взяла на себя фронтенд‑команда;
интеграция вынесена в BFF‑слой (backend for frontend) на Node.js;
основной бэкенд DataLens при этом не меняли.

Для демонстрации подхода автор собрал открытый демо‑проект:

монорепозиторий на GitHub;
сервер на Express;
клиент на React;
слева — упрощённый дашборд, справа — чат с ИИ‑ассистентом;
типовой сценарий: пользователь просит, например, «топ‑5 продуктов», ассистент вызывает функцию getChartData, получает данные и формирует ответ.

Для интерфейса используется AIKit из Gravity UI — готовый UI‑кит для чат‑интерфейсов с корректной отрисовкой ответов и поддержкой стриминга.

Как это работает

Кто такие «фронтендеры» в этом контексте

В DataLens под фронтенд‑командой понимают не только людей, которые пишут React‑компоненты. Это скорее фуллстек‑инженеры с упором на UX и JavaScript/TypeScript:

отвечают за браузерный код и серверный код на Node.js;
поддерживают собственные CI/CD‑пайплайны;
делают DevOps для задач фронтенда;
но приоритет — интерфейсы и пользовательский опыт.

Архитектура с BFF

Между клиентским приложением и LLM добавляется слой BFF:

реализован на Node.js (в демо — Express; можно использовать Bun или другой рантайм, если команда готова его поддерживать);
живёт в зоне ответственности фронтенда как «бэкенд для фронтенда».

Что делает BFF:

хранит ключи доступа к LLM;
общается с API моделей;
реализует rate limiting;
настраивает CORS;
пишет логи и метрики;
инкапсулирует логику работы с LLM (prompt‑инг, стриминг, разбор ответов);
предоставляет фронтенду удобные эндпоинты, уже заточенные под конкретный UI.

При этом основной бэкенд DataLens остаётся как есть:

не нужно менять существующие сервисы на этапе экспериментов с ИИ;
бизнес‑логика и хранение данных не трогаются;
BFF просто обращается к уже существующим API и собирает нужный контекст.

Четыре ключевых компонента интеграции

Чтобы добавить LLM в продукт силами фронтенда, нужны четыре составляющие:

UI‑кит — готовые компоненты для чат‑интерфейса.
API SDK — библиотека для общения с LLM.
Тулинг (tools) — механизм, который позволяет модели вызывать функции и получать данные из системы.
Контекст — данные и состояние приложения, которые передаются вместе с запросом к LLM.

1. UI‑кит

Для фронтенда критично быстро собрать рабочий чат:

есть готовые решения вроде AI Elements от Vercel, Assistant UI, prompt‑kit, shadcn‑chatbot‑kit;
часть из них перегружена абстракциями и сложна в интеграции, особенно если нужно работать с опенсорс‑LLM;
важны не только фичи (стриминг, markdown, подсветка кода), но и простота встраивания в существующий дизайн‑систему.

В DataLens используют AIKit от Gravity UI:

визуально согласован с остальными компонентами Gravity UI;
корректно рисует ответы ассистента;
из коробки умеет работать с потоковыми ответами LLM.

2. API SDK

SDK берёт на себя техническую часть общения с LLM:

формирование запросов;
управление сессией диалога;
обработку стриминга токенов;
работу с ошибками и таймаутами.

Во фронтенд‑подходе SDK используют в BFF‑слое:

браузер общается только с BFF;
BFF — с LLM через SDK;
ключи и чувствительные настройки остаются на сервере.

3. Тулинг: функции и доступ к данным

Чтобы ассистент не просто «болтал», а реально помогал с аналитикой, ему нужны инструменты:

функции, которые модель может вызывать по ходу диалога;
доступ к данным дашборда, фильтрам, метрикам.

В демо‑проекте это реализовано так:

в BFF описывают функцию getChartData;
LLM получает в промпте описание этой функции и аргументов;
когда пользователь спрашивает, например, «покажи топ‑5 продуктов», модель решает, что нужно вызвать getChartData;
BFF выполняет функцию, получает данные от BI‑бэкенда и передаёт их обратно в LLM;
модель формирует человекочитаемый ответ и, при необходимости, структуру для визуализации.

Этот подход масштабируется:

можно добавить функции для создания графиков, изменения фильтров, расчёта метрик;
можно давать ассистенту доступ к метаданным (описания таблиц, полей, бизнес‑термины).

4. Контекст

Контекст — это всё, что модель должна «знать» о состоянии продукта и пользователя в момент запроса:

какие дашборды открыты;
какие фильтры применены;
какие метрики и измерения доступны;
в каком формате продукт ожидает данные для визуализации.

Преимущество фронтенда:

именно в интерфейсе сходятся данные из разных бэкендов;
BFF легко собрать нужный контекст, не трогая исходные сервисы;
можно дозапрашивать недостающие данные по уже существующим API.

Что это значит для вас

Когда имеет смысл отдавать интеграцию LLM фронтенду

Подход, который использует DataLens, полезен, если:

вы хотите быстро проверить, как ИИ впишется в продукт, без долгих изменений в основном бэкенде;
у вас уже есть фронтенд‑команда, которая умеет работать с Node.js и BFF;
в интерфейсе сходятся данные из нескольких бэкендов, и именно там проще собрать контекст для LLM;
вам важно контролировать UX: от промптов до того, как именно ассистент взаимодействует с UI.

Фронтенд‑подход даёт:

быстрые итерации — можно быстро менять промпты, поведение ассистента, набор инструментов;
минимум координации на старте — BFF на Node.js не блокирует другие команды;
более тесную связку ИИ и интерфейса — команда, которая проектирует UX, одновременно управляет поведением ассистента.

Когда лучше подключать основной бэкенд

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

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

Практичный сценарий:

Фронтенд‑команда поднимает BFF и собирает первый рабочий прототип ассистента.
Продукт тестирует сценарии, собирает фидбек, уточняет, где ИИ реально полезен.
Когда сценарии стабилизируются, часть логики переносят в основной бэкенд, если это даёт выигрыш в надёжности и производительности.

Для каких задач это особенно полезно

Подход хорошо работает:

в BI и аналитике, где много дашбордов и сложные фильтры;
в продуктах с насыщенным интерфейсом, где ассистент должен понимать контекст экрана;
в SaaS‑сервисах, где нужно быстро выкатывать и обкатывать ИИ‑фичи на ограниченной аудитории;
в внутренних корпоративных инструментах, где фронтенд‑команда часто ближе всего к пользователям.

Где он может не подойти:

если фронтенд‑команда ограничена только браузерным JavaScript и не готова поддерживать серверный код;
если архитектура запрещает отдельный BFF‑слой и все внешние интеграции жёстко контролируются основным бэкендом;
если продукт критичен по задержкам и каждое лишнее сетевое плечо нежелательно — тогда часть логики стоит сразу переносить ближе к данным.

Доступность

В материале описан архитектурный подход и демо‑проект. Конкретный выбор LLM и её провайдера зависит от вашей инфраструктуры и регуляторных ограничений. Для российских команд часто важен вопрос доступности без VPN и размещения данных в нужной юрисдикции — это нужно учитывать при выборе поставщика LLM.

Место на рынке

Материал описывает не конкретную модель вроде GPT‑4o или Claude 3, а способ интеграции LLM в продукт. Сравнивать его по скорости или цене с конкретными моделями некорректно:

BFF‑архитектура совместима и с коммерческими LLM, и с опенсорс‑решениями;
смена провайдера LLM в такой схеме происходит в основном в BFF‑слое и SDK;
фронтенд‑команда контролирует, какие именно API использовать и как строить промпты.

По сути, это конкурент не другим моделям, а классическому подходу «всё делает бэкенд». В сравнении с ним:

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

Как запустить

Автор выложил демо‑проект на GitHub в виде монорепозитория:

сервер на Express (Node.js);
клиент на React;
интерфейс — упрощённая BI‑система с дашбордом и чат‑ассистентом;
для интерфейса используется Gravity UI и AIKit.

Типовой сценарий использования в демо:

Пользователь открывает страницу: слева видит дашборд, справа — чат.
Пишет в чат запрос: например, «покажи топ‑5 продуктов по выручке».
BFF получает запрос, формирует промпт для LLM и отдаёт модели описание доступной функции getChartData.
LLM решает вызвать функцию и возвращает структуру вызова.
BFF выполняет getChartData, получает данные и передаёт их обратно в LLM.
LLM формирует текстовый ответ и, при необходимости, структуру для визуализации.
Фронтенд отображает ответ ассистента и обновлённый график.

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