Современные языковые модели (LLM) научились писать код, который выглядит убедительно. Они генерируют функции, классы, запросы, с которыми можно работать. Но за внешней уверенностью скрывается фундаментальная проблема: модель не понимает код. Она просто статистически предсказывает следующую строку, опираясь на миллиарды примеров из обучающей выборки. Результат — код, который часто работает, но так же часто содержит логические ошибки, уязвимости или не учитывает граничные случаи.
Эта ситуация напоминает «уверенное угадывание»: модель выдаёт ответ с высокой вероятностью, но без осознания семантики. Разработчики, которые полагаются на такие агенты в production-среде, рискуют получить непредсказуемое поведение. На Хабре недавно вышла статья, в которой авторы описывают новый подход — SLICER, призванный решить эту проблему. В материале подробно разбираются причины «галлюцинаций» у AI-кодинг-агентов и предлагается метод, сочетающий генерацию с формальной верификацией. Источник
Почему LLM не понимают код
Чтобы осознать важность SLICER, нужно понять природу ошибок AI-агентов. LLM — это огромные рекуррентные или трансформерные сети, обученные предсказывать следующий токен. Когда модель пишет def sort(arr):, она не знает, что такое сортировка; она лишь продолжает последовательность, которая в обучающих данных чаще всего вела к рабочей функции.
Исследования показывают, что даже самые продвинутые модели (GPT-4, Claude 3 Opus, Gemini 1.5) допускают логические ошибки в задачах, требующих точного понимания алгоритма. Например, при генерации кода для обработки бинарных деревьев около 30% сгенерированных решений содержат ошибки обхода граничных узлов. Модели легко воспроизводят шаблонные конструкции, но теряются при нетривиальных условиях.
Что такое SLICER
SLICER (Symbolic Language-Integrated Code Execution and Reasoning) — это метод, который авторы описали в своей статье. Его суть — не просто сгенерировать код, а проверить его на соответствие спецификации с помощью символьного выполнения и статического анализа. В отличие от обычного подхода «сгенерировал — запустил тесты», SLICER выполняет верификацию на уровне абстрактного синтаксического дерева, моделируя выполнение по всем возможным путям.
Ключевые компоненты SLICER:
| Этап | Описание | Результат |
|---|---|---|
| Генерация | LLM создаёт код по промпту | Готовая функция или модуль |
| Символьное выполнение | Анализ всех путей выполнения без реального запуска | Набор ограничений (constraints) на входные данные |
| Проверка спецификации | Сравнение ограничений с ожидаемым поведением | Выявление несоответствий (ошибки, лишние пути) |
| Обратная связь | Передача ошибки LLM для коррекции | Улучшенный код (итерации) |
Таким образом, SLICER не просто полагается на генеративную способность модели, а дополняет её формальной математической проверкой. Это похоже на работу компилятора с поддержкой контрактов (например, как в Ada или SPARK), но адаптированную для любых языков программирования.
Реальные примеры ошибок, которые ловит SLICER
Рассмотрим типовой сценарий. Промпт: «Напиши функцию, которая возвращает True, если переданное число является простым, и False в противном случае». Обычный AI-агент может сгенерировать такой код:
def is_prime(n):
if n < 2:
return False
for i in range(2, int(n**0.5) + 1):
if n % i == 0:
return False
return True
На первый взгляд всё верно. Но что будет при n = 2? Цикл выполнится для range(2, 2), что пусто, и функция вернёт True — верно. А при n = -1? Условие n < 2 вернет False. Но по математическому определению отрицательное число не может быть простым, но функция считает его составным? Фактически, возвращает False, что формально тоже неверно, так как понятие простоты не определено для отрицательных. Однако многие модели пренебрегают этим.
SLICER методами символьного выполнения смоделирует все пути: n < 2 -> путь A, n >= 2 -> цикл. Он обнаружит, что для отрицательных значений функция ведёт себя так же, как для чисел 0 и 1, хотя спецификация (если она явно задана) может требовать исключения или другого поведения. Если спецификация не задана, SLICER может просто предупредить о неоднозначности.
Другой пример — генерация SQL запросов. AI может написать:
SELECT * FROM users WHERE age > 18;
Но забыть учесть, что age может быть NULL. В зависимости от реализации NULL > 18 даёт UNKNOWN, и такие строки не попадут в результат. Символьное выполнение выявит, что условие не покрывает случай age IS NULL. SLICER предложит доработать: WHERE age > 18 OR age IS NULL (если нужно включать) или явно исключить NULL.
Сравнение SLICER с альтернативными подходами
На рынке существовали и другие попытки решить проблему «уверенного угадывания»:
| Подход | Механизм | Сильные стороны | Слабые стороны |
|---|---|---|---|
| Простая генерация (LLM) | Только авторегрессия | Быстро, универсально | Ошибки, галлюцинации |
| Chain-of-Thought (CoT) | Пошаговые рассуждения | Улучшает логику | Не гарантирует корректность |
| Тест-аугментация | Запуск юнит-тестов | Проверяет конкретные случаи | Не полное покрытие путей |
| SLICER | Символьное выполнение + верификация | Формальная гарантия | Требует ресурсы, сложность для динамических языков |
Достоинство SLICER — в том, что он оперирует не конкретными тестовыми данными, а всеми возможными значениями. Это приближается к формальной верификации, но без необходимости писать полную спецификацию на специальном языке. Пользователю достаточно дать промпт на естественном языке, а SLICER сам построит модель выполнения.
Практические ограничения и перспективы
Авторы статьи признают, что SLICER не является серебряной пулей. Во-первых, символьное выполнение может комбинаторно взрываться: для сложных алгоритмов с циклами и рекурсией количество путей огромно. Во-вторых, для языков с побочными эффектами (IO, мутабельное состояние) моделирование становится трудоёмким. Однако проект показывает, что для чистых функций и алгоритмов с ограниченным пространством состояний подход работает эффективно.
Команда продолжает развивать SLICER в направлении поддержки многопоточности и взаимодействия с внешними API. Уже сейчас инструмент может анализировать код на Python, JavaScript и Rust. Это открывает путь к интеграции SLICER в CI/CD пайплайны, где AI-агент будет не только генерировать код, но и гарантировать его корректность перед слиянием в основную ветку.
Выводы и рекомендации
Основная мысль новости на Хабре — доверять AI-агентам без проверки опасно. Они не понимают код, они лишь угадывают, хотя и с высокой точностью. SLICER предлагает прагматичный компромисс: оставить генерацию LLM, но добавить слой формального контроля. Такой гибридный подход позволяет получать скорость нейросетей и надёжность верификации.
Разработчикам, которые активно используют AI-агентов (GitHub Copilot, Cursor, Codeium), стоит обратить внимание на инструменты, внедряющие верификацию. В будущем такие методы могут стать стандартом индустрии. Для обучения и знакомства с подобными техниками можно обратить внимание на образовательные материалы — например, платформа ASI Biont предлагает специализированные курсы, где разбираются как методы генерации кода, так и верификации.
Пока же, используя AI-агентов, всегда держите в уме: ваш коллега-нейросеть очень уверен в себе, но иногда ошибается. SLICER — один из способов сделать его ответы более надёжными.
Комментарии