AI-автодополнение для Ansible: Lightspeed хорош, но только на английском

Несколько месяцев назад Red Hat запустила Ansible Lightspeed - AI-ассистент прямо в VS Code, который смотрит на комментарий над task-ом и предлагает YAML. Интеграция в плагин, подписка через Red Hat, за кулисами - IBM watsonx Code Assistant, обученный на публичных Ansible-коллекциях. Мы попробовали. Впечатления неоднозначные, и суть не в качестве самой модели.

Что Lightspeed делает хорошо

Если пишешь комментарий на английском и используешь стандартные коллекции - работает заметно. Ввёл # Install nginx and enable it on boot, получил готовый блок с ansible.builtin.package и ansible.builtin.service. Для задач из верхнего слоя - установка пакетов, управление сервисами, работа с файлами на RHEL/Fedora - предложения попадают в цель с первого раза достаточно часто, чтобы это ощущалось полезным, а не как игрушка.

Есть и генерация playbook целиком по описанию задачи - это работает слабее. Структура появляется правильная, модули выбираются вменяемо, но конкретные параметры приходится проверять, а handler-ы и теги нужно дописывать самому. Как черновик - ок, как готовый результат - нет.

Где ломается

Первый сеанс с реальным проектом показал ограничение, которого в демо не видно.

Большинство наших клиентов - компании, у которых задачи описываются и документируются на русском. Плейбуки пишут инженеры, которым привычнее писать комментарий по-русски: # Установить Nginx, включить автозапуск. Ansible Lightspeed с таким комментарием справляется плохо. Предложение либо не появляется, либо появляется нерелевантное - модель просто не была обучена на русскоязычных описаниях задач.

Второй момент - отечественный стек. Когда задача звучит как # Установить пакет через apt в [Astra Linux](/blog/terms/astra-linux/) и добавить репозиторий [РЕД ОС](/blog/terms/redos/), Lightspeed не знает что такое Astra Linux, как устроен её репозиторий, какие там специфичные пути и параметры. Предложения дают generic-RHEL-логику, которая требует ручной правки под реальные условия. А это уже нивелирует половину выгоды.

Это не баг Lightspeed - это ожидаемое следствие того, на чём обучена модель: публичный GitHub, преимущественно English, преимущественно стандартные дистрибутивы. Ругаться тут не на что, но и иллюзий строить не стоит.

Как мы начали пробовать локальные модели

Поскольку с локальными LLM мы уже работаем - RAG-стеки для корпоративных баз знаний поднимали несколько раз, Ollama с Llama 3 в продакшне стоит у нескольких клиентов - решили посмотреть, можно ли собрать аналогичный ассистент для Ansible, но на локально развёрнутой модели.

Идея простая: берём Llama 3 70B через Ollama, делаем минимальный инструмент на базе расширения Continue для VS Code (оно умеет подключаться к произвольным OpenAI-совместимым эндпоинтам), настраиваем системный промпт под Ansible и русский язык.

Ты - помощник DevOps-инженера. Генерируй YAML для Ansible task-ов
по описанию на русском языке. Используй ansible.builtin модули,
если не указан конкретный. Возвращай только YAML, без пояснений.

Инструмент Continue в VS Code умеет брать контекст из открытого файла - это помогает: модель видит, какие переменные уже определены в playbook-е, и не придумывает новые.

Что получается на практике

На стандартных задачах - установка пакетов, управление файлами, работа с systemd - качество генерации сопоставимо с Lightspeed, при этом комментарий можно писать по-русски и получать адекватный результат. # Создать пользователя приложения без shell-доступа, добавить в группу docker - модель это понимает и генерирует правильный блок с ansible.builtin.user.

На задачах с отечественным стеком лучше - но требует подготовки. Если в системном промпте или в файле рядом с плейбуком есть описание репозиториев Astra Linux, специфика конкретной версии - модель берёт это в контекст и предложения становятся значительно точнее. Без такого контекста - всё равно generic.

Галлюцинации есть. Особенно на нестандартных модулях - модель иногда придумывает несуществующие параметры или смешивает синтаксис разных коллекций. Это означает, что итог нужно проверять через ansible-playbook --syntax-check и не забывать про --check перед реальным запуском. Впрочем, это справедливо для любого сгенерированного YAML.

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

Текущее состояние

Мы используем оба варианта в зависимости от проекта. Там, где команда пишет на английском и стек стандартный - Lightspeed удобен и достаточно точен. Там, где русский язык и отечественные дистрибутивы - локальная модель через Continue.

Конфигурация в VS Code несложная: плагин Continue, в ~/.continue/config.json прописывается эндпоинт Ollama с нужной моделью, системный промпт - и можно пробовать. Модель на сервере поднимает команда managed-сопровождения, инженеры просто подключаются к готовому эндпоинту.

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