Ansible Lightspeed против локальной CodeLlama: тест на типовых задачах автоматизации

Red Hat в конце октября объявил о переводе Ansible Lightspeed with IBM watsonx в production-режим. Расширение для VSCode теперь официально поддерживается, интеграция с Ansible Automation Platform задокументирована, IBM watsonx Code Assistant for Red Hat Ansible Automation стал отдельным SKU с поддержкой. Словом, AI-генерацию задач теперь можно ставить в коммерческое предложение без пометки «технический превью».

Мы посмотрели на это с практической стороны: несколько недель назад начали тест, где параллельно гоняли Lightspeed и локальную CodeLlama 34B на одних и тех же сценариях. Результаты неоднозначные - делимся.

Контекст: почему вообще смотрим на локальную альтернативу

Для части наших клиентов облачный Lightspeed - это закрытая тема уже на уровне ИТ-политики. Данные в контуре, никакого watsonx в облаке. При этом инженеры по автоматизации были бы рады хоть какому-то ассистенту при написании плейбуков: task-level генерация на основе комментария или имени задачи экономит реальное время.

Та же инфраструктура, которую мы используем для code review в CI и RAG-пилотов, - GPU-сервер с llama.cpp в контуре клиента - теоретически подходит и для этого сценария. CodeLlama обучена на коде, YAML она видела немало. Проверили.

Как тестировали

Взяли три категории задач, которые встречаются в реальных плейбуках чаще всего:

Установка пакетов и управление сервисами. Установить nginx, включить и запустить, проверить конфигурацию, перезапустить при изменении шаблона. Это хлеб с маслом любого Ansible-проекта.

Конфигурирование через шаблоны Jinja2. Развернуть конфигурационный файл из шаблона, выставить правильные права, уведомить хендлер. Тут важно, чтобы модель правильно понимала notify, vars, template module.

Управление пользователями и правами. Создать системного пользователя, добавить SSH-ключ, настроить sudo-правила. Задачи не сложные, но с множеством нюансов в параметрах модулей.

Lightspeed тестировали через VSCode-расширение - пишешь комментарий # Install and start nginx, enable at boot, жмёшь Tab, получаешь предложение задачи. CodeLlama работала через скрипт, который отправлял аналогичный промпт с контекстом файла и ждал ответ.

Что показал Lightspeed

На типовых задачах - хорошо. Установка пакета через ansible.builtin.package с правильным state: present, сервис через ansible.builtin.service с enabled: yes и state: started - всё корректно с первого раза. Предложения учитывают контекст файла: если вверху уже объявлены переменные, модель их использует в генерируемой задаче.

Работа с шаблонами и notify тоже приличная - хендлер прописывается правильно, имена ссылаются корректно. На управлении пользователями модель предлагала разумные параметры ansible.builtin.user, хотя иногда путала groups и group (мелочь, но характерная).

Задержка генерации - около секунды. Для ассистента при написании кода это хорошо.

Что показала CodeLlama

На простых установочных задачах - вполне приемлемо. Модуль правильный, параметры основные верные. Но вылезают косяки, которых у Lightspeed нет.

Устаревшие имена модулей. CodeLlama регулярно предлагала yum вместо ansible.builtin.dnf или ansible.builtin.package. Это работает, но в контексте нашего кода со включёнными FQCN - рябь в глазах и замечание от ansible-lint.

Синтаксис шаблонов - слабое место. На задаче с Jinja2-шаблоном и notify модель сгенерировала синтаксически корректный YAML, но хендлер назвала иначе, чем он объявлен в handlers:. Это тихая ошибка - плейбук не падает, просто хендлер не вызывается. Нужна проверка.

Параметры user-модуля. Несколько раз генерировала createhome: yes вместо create_home: yes (deprecated параметр). Снова работает, но ansible-lint ругается.

Скорость. На нашем железе - 3-4 секунды на задачу. Для VSCode-ассистента это уже ощутимо, хотя терпимо.

Промежуточный вывод

Lightspeed на типовых задачах заметно точнее - Ansible-специфичная дообучка чувствуется: правильные FQCN, актуальные параметры, понимание хендлеров. Если у клиента нет ограничений на облако и есть подписка, выбор очевиден.

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

На более сложных задачах - условная логика, block/rescue, роли с зависимостями - CodeLlama начинает давать откровенно сырые предложения, которые требуют существенной доработки. Там экономия времени сомнительная.

Сейчас смотрим, есть ли смысл дообучить CodeLlama на нашем корпусе плейбуков - несколько тысяч задач накопилось. Гипотеза: основная часть ошибок с устаревшими именами и параметрами лечится примерами из актуальных коллекций. Проверим.