Yandex Cloud explique pourquoi le frontend mène l'intégration de l'IA dans DataLens

Yandex Cloud предлагает смотреть на интеграцию нейросетей в продукт не как на задачу только для бэкенда. В DataLens первый рабочий слой Нейроаналитика взяла на себя фронтенд-команда: она собрала чат-интерфейс, BFF-прослойку и логику общения с моделью, не дожидаясь большой серверной переработки. Идея в том, что для раннего запуска ИИ-функций важнее не идеальная архитектура на годы вперёд, а быстрый выход в продукт с понятной зоной ответственности.

Речь идёт о DataLens, BI-системе Yandex Cloud для визуализации больших массивов данных. Внутри сервиса появился Нейроаналитик — ассистент, который помогает строить графики, писать формулы и решать аналитические задачи в диалоге. Вместо классической схемы, где бэкенд полностью берёт на себя интеграцию с LLM, команда предложила иной порядок: между клиентом и моделью появился BFF-слой, за который отвечает фронтенд.

Такой слой можно поднять на Node.js, Bun или другом знакомом стеке и использовать как отдельный сервер, ориентированный на нужды интерфейса. Подход автор иллюстрирует демо-проектом в виде монорепозитория с Express и React, где BI-дашборд работает рядом с чатовым ассистентом.

В этой схеме существующий бэкенд не нужно срочно переписывать. BFF хранит ключи доступа к модели, обрабатывает rate limiting, CORS, логирование и мониторинг, а также управляет стримингом ответов. Для фронтенд-разработчиков это не чужая территория: во многих продуктовых командах они давно работают как фулстек-инженеры, поддерживают серверный код, CI/CD и инфраструктуру вокруг клиентского приложения.

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

Первый — UI-kit для чатового интерфейса и связанных элементов: поля ввода, карточки, списки действий, стриминг сообщений. Второй — SDK для работы с моделью через API; здесь важен не конкретный провайдер, а совместимость, потому что многие сервисы повторяют формат OpenAI API. Третий — тулинг, то есть function calling и доступ модели к прикладным функциям, например к получению данных для графика или выборке топ-5 товаров.

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

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

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

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