Что такое AI-стек и почему LLM — не продукт
В корпоративных проектах генеративный ИИ почти никогда не внедряется «как есть» — вокруг языковой модели всегда приходится собирать полноценный технологический стек: данные, оркестрацию, retrieval-слой, интеграции и контроль эксплуатации.
AI-стек — это не модель и не ассистент, а совокупность компонентов, которые позволяют встроить LLM в реальные бизнес-процессы. Такой подход последовательно прослеживается как в экосистеме YandexGPT, так и в экосистеме Sber AI.
Ключевая архитектурная ошибка — рассматривать модель как продукт. На практике модель — это вычислительное ядро, которое не управляет данными, доступами и сценариями использования.
Ключевые компоненты AI-стека
Модель (LLM)
Языковая модель отвечает за генерацию и анализ текста. В экосистеме Яндекса доступны разные классы моделей, ориентированные на различные сценарии: от YandexGPT 5 Lite до более ресурсоёмких YandexGPT 5 Pro и YandexGPT 5.1 Pro, а также предыдущей версии YandexGPT 4.5.
В экосистеме Сбера аналогичную роль играют модели линейки GigaChat: GigaChat 2 Lite, GigaChat 2 Pro и GigaChat 2 Max. В публичных кейсах они описываются именно как ядро обработки текста.
Ассистент и оркестрация
Ассистент — это прикладной слой, который управляет диалогом, контекстом и вызовами внешних инструментов. В экосистеме Яндекса таким слоем выступает Алиса, а также ассистентные сервисы поверх YandexGPT.
Отдельно выделяется Alice AI LLM, позиционируемая как наиболее функционально насыщенный вариант для корпоративных сценариев.
В экосистеме Сбера аналогичную роль выполняет GigaChat AI, который в кейсах описывается как корпоративный ассистент, встраиваемый в бизнес-процессы.
Данные и retrieval-слой
Источники данных всегда находятся на стороне компании: документы, базы знаний, почта, CRM. Для работы с ними используется retrieval-слой (RAG), который реализуется как сервисный компонент, а не как свойство модели.
Архитектурные паттерны под задачи
Внутренние ассистенты
Ассистенты для сотрудников — один из самых распространённых сценариев. Модель используется для обработки текста, а логика, данные и контроль остаются в корпоративных системах.
Поиск по базе знаний
RAG-архитектура применяется для работы с регламентами и инструкциями. Ассистент управляет поиском, а модель формирует ответ на основе переданных фрагментов.
Контакт-центры
LLM используется для классификации обращений, подготовки ответов и суммаризации диалогов, не заменяя существующие CRM и телефонию.
Экосистема YandexGPT
Экосистема YandexGPT ориентирована на ассистентные сценарии, быстрый запуск и плотную интеграцию с сервисами Яндекса. Архитектура решений часто выстраивается вокруг готового ассистентного слоя.
Это снижает порог входа, но усиливает vendor lock-in: использование AI-сервисов и инфраструктуры Яндекса делает последующую миграцию архитектурно сложной.
Экосистема GigaChat
Экосистема Sber AI в кейсах ориентирована на корпоративные процессы — промышленность, HR, аналитику, поддержку.
Архитектура чаще проектируется модульно: retrieval-слой и бизнес-логика остаются в зоне ответственности компании, а модель может быть заменена без полной перестройки системы.
Граница ответственности
Вендор отвечает за модель, инфраструктуру и API. Заказчик — за данные, интеграции, безопасность и эксплуатацию.
Ограничения и риски
Квоты, лимиты, облачная привязка и стоимость эксплуатации — обязательные факторы при проектировании. Миграция между платформами требует переписывания интеграций и промптов.
Как выбирать AI-стек
Выбор определяется не «качеством модели», а требованиями к данным, архитектуре и контролю. В одних случаях оправдан ассистентный подход, в других — процессная интеграция.
Ключевые выводы
LLM — лишь один слой AI-стека. Результат определяется архитектурой, границей ответственности и тем, насколько осознанно модель встроена в систему.
Архитектурные паттерны под задачи
Внутренние ассистенты
Внутренние ассистенты для сотрудников — один из наиболее распространённых сценариев использования LLM в корпоративной среде. В таких решениях языковая модель выступает инструментом обработки текста, тогда как бизнес-логика, правила доступа и источники данных остаются в корпоративных системах.
Типичная архитектура включает ассистентный слой, который управляет диалогом, определяет, какие инструменты или базы данных необходимо задействовать, и передаёт модели строго ограниченный контекст. Это позволяет использовать LLM без предоставления ей прямого доступа к чувствительным данным.
В кейсах GigaChat подобные ассистенты описываются как помощники инженеров, HR-специалистов или аналитиков. В экосистеме Яндекса аналогичный подход реализуется через ассистентные сервисы поверх YandexGPT.
Поиск по документам и базе знаний (RAG)
Поиск по корпоративным документам — один из наиболее прикладных и управляемых сценариев использования LLM. Здесь ключевую роль играет retrieval-слой, а не сама модель. Ассистент формирует поисковый запрос, извлекает релевантные фрагменты и передаёт их в модель в качестве контекста.
Такой подход позволяет использовать LLM для работы с регламентами, инструкциями, договорной документацией и техническими описаниями, не обучая модель на этих данных и не нарушая требования к хранению информации.
Важно отметить, что качество ответов в RAG-архитектуре в большей степени зависит от структуры базы знаний, стратегии поиска и отбора фрагментов, чем от версии используемой модели.
Контакт-центры и поддержка
В контакт-центрах LLM применяется для классификации обращений, подготовки черновиков ответов, суммаризации диалогов и аналитики. При этом модель не заменяет CRM, телефонию или системы тикетов, а используется как дополнительный интеллектуальный слой.
Типовая архитектура предполагает автоматическую обработку стандартных запросов и передачу сложных случаев операторам. Ассистент контролирует границы автоматизации и предотвращает некорректные действия со стороны модели.
Внутренняя аналитика и суммаризация
Суммаризация стенограмм встреч, отчётов и переписки — ещё один распространённый паттерн. В этих сценариях модель работает исключительно с текстовыми данными, уже собранными внутри компании, и используется для снижения когнитивной нагрузки на сотрудников.
Важно, что такие решения не принимают управленческих решений самостоятельно. Модель лишь агрегирует и структурирует информацию, а интерпретация результатов остаётся за человеком.
Инструменты для разработчиков
LLM могут применяться в developer-инструментах для объяснения кода, генерации шаблонов и помощи в отладке. В экосистемах YandexGPT и GigaChat такие сценарии реализуются через API и SDK.
При этом использование моделей в разработке требует строгого контроля контекста и понимания ограничений: результаты генерации не могут рассматриваться как гарантированно корректные или безопасные без дополнительной проверки.
Экосистема YandexGPT в составе AI-стека
Экосистема YandexGPT строится вокруг облачной платформы и ассистентных сервисов. В публичных материалах модель часто позиционируется как ядро для создания AI-помощников, голосовых и текстовых интерфейсов, а также агентных решений.
Типичный заказчик таких решений — компании, которым важны быстрый запуск, готовые ассистентные сценарии и плотная интеграция с сервисами экосистемы Яндекса. Архитектура в таких проектах часто оптимизируется под возможности платформы, а не под потенциальную смену вендора.
Это снижает порог входа и ускоряет внедрение, но одновременно усиливает vendor lock-in. Использование ассистентных API, агентных сервисов и облачной инфраструктуры Яндекса делает последующую миграцию архитектурно и операционно затратной.
Экосистема GigaChat в составе AI-стека
Экосистема GigaChat в доступных кейсах ориентирована прежде всего на корпоративные сценарии: промышленность, HR, контакт-центры, аналитику и работу с документами. Модель чаще встраивается в уже существующие ИТ-ландшафты компаний.
Типичный заказчик — крупные организации, для которых приоритетом является автоматизация конкретных процессов, а не создание универсального пользовательского ассистента.
Vendor lock-in в таких архитектурах проявляется в первую очередь на уровне облачной инфраструктуры и API. При этом retrieval-слой, бизнес-логика и пользовательские интерфейсы нередко проектируются более модульно, что теоретически упрощает замену модели без полной перестройки системы.
Ответственность вендора и заказчика
Граница ответственности в корпоративных AI-проектах проходит достаточно чётко. Вендор предоставляет модель, облачную инфраструктуру, масштабирование и базовые API. Эти элементы находятся вне зоны контроля заказчика.
Компания-заказчик отвечает за данные, сценарии использования, интеграции с корпоративными системами, управление доступами, безопасность и эксплуатацию решения. Именно на этой стороне возникают основные риски и издержки при внедрении.
Игнорирование этого разделения ответственности часто приводит к ошибочному ожиданию, что платформа «решит всё сама», тогда как на практике большая часть архитектурных решений остаётся за заказчиком.
Практические ограничения и риски
При сборке AI-стека необходимо учитывать ряд практических ограничений. К ним относятся квоты и лимиты на использование моделей, ограничения на объём контекста и количество запросов, а также требования к авторизации и управлению доступами.
Существенным фактором является облачная привязка. Использование ассистентных сервисов и managed-решений упрощает эксплуатацию, но усложняет гибридные и мультиоблачные архитектуры.
Миграция между платформами требует переписывания интеграционного кода, адаптации обработки ошибок и пересмотра промптов. Даже при формальной совместимости API поведение моделей может существенно отличаться.
Как выбирать AI-стек в реальных условиях
Выбор AI-стека определяется не сравнением «качества» моделей, а архитектурными и организационными требованиями проекта. Ключевыми факторами становятся источники данных, требования к юрисдикции, уровень контроля и допустимый vendor lock-in.
В одних случаях оправдан ассистентный подход с опорой на готовые сервисы и быстрый time-to-market. В других — более модульная архитектура, ориентированная на долгосрочную эксплуатацию и возможность замены компонентов.
Практика показывает, что успешные проекты начинаются с проектирования архитектуры и границ ответственности, а выбор конкретной модели происходит уже на позднем этапе.
Ключевые выводы
LLM — это лишь один из слоёв AI-стека, а не готовый продукт. Реальные корпоративные проекты требуют архитектурного подхода, чёткого разделения ответственности и трезвой оценки ограничений.
YandexGPT и GigaChat представляют разные акценты внутри российских экосистем: ассистентный и процессный. Однако в обоих случаях результат определяется не моделью, а тем, насколько осознанно она встроена в систему.
