Проблема «бесконечного радиуса поражения»: почему обновления нейросетей ломают готовые ИТ-системы

В современной разработке программного обеспечения на базе искусственного интеллекта наметилась серьезная проблема: даже незначительное обновление языковой модели (LLM) может вывести из строя отлаженную инфраструктуру. Обозреватели технического сообщества указывают на концепцию «бесконечного радиуса поражения», когда изменения в модели приводят к непредсказуемым сбоям в работе прикладных систем.

В качестве примера приводится работа сервиса, который автоматизирует создание отчетов. Система преобразовывала запросы пользователей на естественном языке в вызовы программного интерфейса (API). Аналитики и менеджеры вместо ручного сбора данных из различных панелей управления и CRM-систем вводили простые команды. Например, запрос о росте продаж в конкретном регионе за определенный период автоматически трансформировался в структурированный JSON-объект, содержащий маршрут API и необходимые фильтры.

Переход от стабильности к хаосу

Изначально система была построена на базе модели Claude Sonnet 3.5. Переходы на версии 3.7 и 4.0 прошли бесшовно, что создало у разработчиков ложное чувство безопасности. Однако внедрение версии Claude 4.5 привело к критическим ошибкам в значительном проценте запросов. Эксперты выделили два основных сценария отказа:

• Утечка данных в описание: Модель начала перемещать содержимое тела запроса (параметры фильтрации) в поле текстового описания. В результате API получал пустые поля, что приводило либо к выдаче некорректных данных за всё время работы компании, либо к ошибкам сервера.
• Избыточная «вежливость» и уточняющие вопросы: В отличие от предыдущих версий, которые старались максимально точно выполнить задачу, новая модель стала чаще задавать уточняющие вопросы. Поскольку система была спроектирована для автоматического исполнения кода без участия человека, такие ответы блокировали дальнейшую цепочку обработки данных.

Почему традиционная инженерия оказывается бессильной

В классическом программировании разработчики полагаются на детерминированность: поведение библиотеки или драйвера можно предсказать или проверить с помощью модульных тестов. При обновлении LLM ситуация иная. Команда инженеров не может просто сравнить код новой версии модели с предыдущей, так как модель является «черным ящиком».

Специалисты подчеркивают, что при замене версии LLM происходит полная замена функциональной логики системы. Ошибка заключалась не в самой нейросети, а в предположении, что новая модель будет заполнять пробелы в спецификациях так же, как и старая. Традиционные схемы данных (schemas) способны контролировать синтаксис, но они бессильны перед семантическими изменениями — например, когда модель решает, что задать вопрос «полезнее», чем выдать программный код.

Архитектура, ориентированная на оценку (Evals-first)

Для решения подобных проблем предлагается изменить подход к проектированию. Вместо того чтобы считать основным документом инструкции для нейросети (промпты), разработчикам следует опираться на наборы тестов для оценки качества — так называемые «эвалы» (evals). В такой архитектуре именно тесты становятся формальной спецификацией системы.

Эффективный набор тестов должен включать три компонента:

• Входные данные для проверки.
• Свойство, которому должен соответствовать ответ.
• Функция оценки (автоматическая проверка или другая нейросеть в роли судьи).

Например, для предотвращения утечки данных в текстовое описание инженеры внедряют автоматическую проверку, которая блокирует ответы, содержащие элементы программного кода в неположенных полях.

Несмотря на то что создание и поддержка таких тестовых наборов требует значительных ресурсов, эксперты считают это единственным способом ограничить «радиус поражения» при обновлении ИИ-технологий. В ближайшие годы ключевой задачей инженерии станет преодоление разрыва между успешным прохождением простых тестов и уверенностью в стабильной работе системы в реальных условиях.

* — деятельность компании запрещена на территории РФ

Твитнуть