Привет, Хабр! Последнее время я много слышал, что в облачных технологиях появляются ИИ‑ассистенты. Они перестают быть экспериментом и становятся рабочим инструментом. Кроме того, нейросетевые модели всё больше появляются в разных облаках. Но как это выглядит с точки зрения разработчиков облачных платформ, и какие технологии лежат в основе таких сервисов? Об этом я поговорил на конференции GigaConf с директором продуктовой разработки Cloud.ru Владимиром Шульгой. Также в разговоре затронули темы RAG‑пайплайна, интеграции LLM в DevOps‑процессы, автоматизации рутинных операций и о том, как облачные ассистенты меняют пользовательский опыт. Приятного чтения!
Какие рутинные операции в облаке можно автоматизировать с помощью ассистентов и как это меняет пользовательский опыт?
Мы уже разработали и внедрили первый прототип ИИ‑помощника «Клаудия» на базе LLM, автоматизирующего ряд типовых операций. Эффективность этого решения оценивается метриками. В тестах число кликов и действий пользователя заметно сократилось: если раньше простая операция в облаке занимала 30–40 минут, то теперь для этого требуется около 2–3 минут.
Ассистент выявляет потребности и подбирает решения, что упрощает работу с облаком, пользователь может задать вопросы по сервисам/документации. Кроме того, мы автоматизируем рутинные задачи и для опытных DevOps‑инженеров. Агенты могут выполнять сопровождение систем, например мониторинг. Это освобождает много времени специалистов. Таким образом, мы видим широкий спектр задач, в которых ассистенты дают ценность всем сегментам пользователей.
Что такое RAG‑пайплайн и каковы его ключевые этапы (токенизация, чанкование, индексация, поиск, генерация)?
RAG (Retrieval-Augmented Generation) — это подход, при котором LLM дополняется внешней базой знаний. Основные этапы RAG-пайплайна таковы: исходные документы разбиваются на токены и чанки, создаётся векторный индекс (индексация). По запросу выполняется векторный поиск наиболее релевантных чанков. Далее эти фрагменты передаются в контекст LLM, на основе которого она формирует ответ.
В облачных платформах все эти шаги стараются собрать в единый управляемый сервис. Клиент загружает данные, выбирает модели для токенизации, реранкинга, поиска и генерации, настраивает параметры (например, размер и число чанков) и получает готовый ответ. Поэтому не нужно самостоятельно собирать пайплайн: облачный провайдер предоставляет многоарендный сервис с уже настроенным и оптимизированным RAG‑процессом.
Как внедрение RAG‑подхода помогает решить проблему устаревших знаний у LLM (галлюцинаций) и какие при этом возникают новые сложности (точность поиска, задержки, безопасность)?
RAG позволяет обогатить LLM актуальными данными, что устраняет проблему устаревших знаний и снижает количество «галлюцинаций». Вместе с тем появляются новые задачи: нужно обеспечивать точный поиск по базе, учитывать дополнительную задержку на запросы к индексу и особенно следить за безопасностью. Дополнительная задержка обычно невелика (сотни миллисекунд), но требует оптимизации для быстрого отклика.
В корпоративной среде безопасность критична: провайдер привязывает специфичные данные клиента к модели, поэтому надо использовать изолированные инстансы LLM. Это значит, что данные одного клиента не смешиваются с другими и не используются для обучения модели. В публичных сервисах типа OpenAI загруженные данные могут использоваться в обучении, что неприемлемо для компаний. Облачные провайдеры предлагают выделенные окружения с технической изоляцией (аналогично виртуальным машинам). Высокая степень изоляции дороже, мультиарендный режим — дешевле. И из этих двух вариантов клиент сам выберет.
Как можно использовать методы машинного обучения для анализа логов и обнаружения аномалий? Какие проблемы при этом обычно возникают?
Традиционный подход — собрать логи, разметить их и обучить модель (например, Isolation Forest) на выявление аномалий. Для этого требуется дата‑саентист и ресурсы для обучения модели. Процесс итеративный и длительный. Причём он может оказаться дорогим, а результат — часто недостаточно точным: при появлении ложных срабатываний систему невозможно будет запустить в продакшн. Например, при точности модели 80% появляется слишком много «шумовых» алертов.
Альтернативный подход — использовать предобученные LLM или специализированные retrieval‑модели для анализа логов без дополнительного обучения. Такие модели могут сразу находить аномалии по шаблонам и статистикам в логах. Это проще и дешевле, поскольку не требует этапа дообучения. Резкий рост ошибок или неожиданный перезапуск сервиса можно считать аномалией.
Какие движки (фреймворки) для инференса LLM поддерживают облачные платформы и зачем их так много?
Рынок движков для инференса LLM быстро развивается, и есть множество решений. Разные команды создают свои движки, оптимизированные под разные задачи и архитектуры. Например, мы используем движки VLLM (Virtual LLM) — у каждого из них есть свои преимущества (скорость, поддержка разных моделей и т. д.). Некоторые движки созданы для больших текстовых генераторов, другие — для мультимодальных моделей. Такая ситуация похожа на отсутствие единого стандарта: разные решения конкурируют, и обычно побеждает то, которое эффективнее. Чтобы дать лучший результат, мы, например, совмещаем несколько движков, обеспечивая гибкость и надёжность решения.
Какие модели для генерации кода доступны в облаке, и как они интегрируются в процесс разработки?
В облачных сервисах есть модели, специализирующиеся на генерации кода. Например, доступны Qwen3-Coder, GLM-4.5 и так далее, хорошо справляющиеся с программированием. У нас в библиотеке Foundation Models сейчас самая популярная для кодинга модель — Qwen3-Coder-480B‑A35B‑Instruct, на 480 миллиардов параметров. Есть модели и с меньшим количеством параметров, каждая подходит для разных задач.
В инструменты разработки интегрируются плагины и API. Например, существует плагин AWS CodeWhisperer, позволяющий писать код в «агентном» режиме: разработчик подключает плагин, указывает LLM‑провайдера и API‑ключ, после чего модель помогает с автодополнением кода. Схожим образом во многих IDE можно выбрать модель и получать подсказки по коду. Это значит, кодогенерация встроена в процесс разработки через привычные механизмы автодополнения и ассистирования. Полностью автономные «боты», генерирующие весь код, пока остаются редкостью (хотя появляются экспериментальные решения, например от GitHub). Однако пока это направление только развивается.
Как генеративные модели используются для поддержки пользователей и управления базой знаний?
Любой современный облачный провайдер ориентирован на клиента и применяет мультиагентные решения в службе поддержки. Агенты автоматически обрабатывают часть типовых запросов пользователей и помогают оперативно давать ответы на вопросы о сервисе. Благодаря этому самообслуживание улучшается: значительная доля запросов уже решается без участия оператора. Например, около 70% типовых обращений обрабатываются ИИ‑ассистентами. Агенты также динамически обновляют базу знаний на основе новых запросов, повышая качество ответов со временем.
Как генеративные модели применяются в DevOps‑процессах и какие проблемы при этом возникают (например, связанные с документацией и галлюцинациями)?
Мы только входим в эту область. Например, некоторые команды тестировали GPT‑бота в Slack, который помогал разработчикам читать документацию и деплоить сервисы. Он повышал эффективность таких операций, но сталкивался с «галлюцинациями» и устаревшей документацией, поэтому пока требует контроля человека. В целом мы видим, что ИИ‑инструменты ускоряют выполнение многих DevOps‑задач (написание плейбуков, проверка конфигураций и т. д.), однако DevOps‑инженер работает с крайне разнородной инфраструктурой. Поэтому полностью автономная работа пока невозможна: сейчас ИИ‑помощники выступают вспомогательными инструментами, ускоряющими конкретные задачи. Но заменить опытного специалиста не смогут. В перспективе такие системы могут взять на себя рутинную часть задач, однако сегодня эти инструменты выступают лишь в роли инструмента поддержки.
Что такое «структурированный вывод» (structure output) и «вызов функций» (function calling) в контексте LLM и зачем они нужны при интеграции с инфраструктурными сервисами?
Структурированный вывод — это когда LLM выдаёт результат в формализованном формате (JSON, XML и так далее) вместо свободного текста. Это позволяет интегрировать LLM с реальными ИТ-системами. Например, можно попросить модель создать задачу в системе Jira: модель вернёт корректный JSON с полями задачи, и этот JSON отправляется через API в Jira для создания тикета. Таким образом, пользователь взаимодействует на естественном языке, а модель автоматически формирует и отправляет точный API-вызов (например, для создания тикета или запуска скрипта) без ручного программирования.
А вызов функций позволяет моделям взаимодействовать с вашим кодом и внешними системами структурированным образом, значительно расширяя возможности LLM. Вместо простого генерирования текстовых ответов LLM могут понимать, когда нужно вызвать определённые функции, и предоставлять необходимые параметры для выполнения реальных действий.
Какие крупные языковые модели (LLM) поддерживаются на вашей платформе? В частности, доступны ли российские модели и open‑source решения?
Наша платформа предоставляет доступ к различным «фундаментальным» моделям. Мы поддерживаем ведущие российские чат‑ориентированные модели и лучшие open‑source решения.
Например, среди доступных — QeM, DeepPavlov и другие российские разработки (модели банковского сектора, команда «Вихрь»), а также глобальные open‑source модели. В перспективе мы планируем добавить модели, разрабатываемые крупными компаниями («Яндекс», «Сбер» и Avito). И что‑то уже добавили, кстати, например GigaChat. Платформа выступает как хаб: заказчик может опробовать разные модели и выбрать оптимальную. (Отметим, что ChatGPT доступен как облачный сервис, и open source gpt‑oss-120b).
Заключение
Из нашего разговора с Владимиром я понял, что нейросети, ИИ и LLM стали неотъемлемой частью облачных сервисов. И, судя по тому, какие сервисы на их основе предоставляются компаниям, то как раз рутину можно будет уменьшить очень сильно. Не знаю, насколько это хорошо или плохо, но идея «уверенный пользователь ИИ» или, как сейчас это называется, промт‑инжиниринга всё больше развивается. Ну а про ИИ я ещё поговорю с другими специалистами из других компаний. Спасибо за внимание!
