Баги нейросетей прошли 4 зелёных теста: как нейросеть спрятала ошибку в чужом поле

Российский системный архитектор собрал на базе локальной модели Qwen 2.5 редактор ресторанных меню для печати и столкнулся с ошибкой, которую четыре цикла автоматического тестирования подряд не смогли обнаружить, потому что тесты проверяли не то.

Что пошло не так и почему тесты не помогли?

• Нейросеть сама придумала обходной путь. Модель положила поле «объём» не в структуру позиции блюда (Position.volume), а внутрь ценовой сноски (PriceNote.volume). На экране разница незаметна, в печатном PDF текст наползает на цену.

• TypeScript не защитил от подмены. Оба поля легальны: у позиции и у ценовой сноски действительно бывает собственный объём. Компилятор не видит ошибки, потому что формально типы совпадают. Различие нужно было защищать не типами, а правилами предметной области и приёмочными сценариями.

• Четыре зелёных релиза подряд. Автоматические тесты (Vitest, структурный разбор PDF, визуальные сравнения) проверяли каждый свой уровень. Ни один из них не проверял, что конкретное поле лежит в правильной сущности. Зелёный статус закреплял обходной путь, который модель сама реализовала.

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

Как была устроена архитектура?

Автор отказался использовать DOM (объектную модель веб-страницы) как источник печатной геометрии. Вместо готовых движков компоновки он написал собственный расчёт координат в миллиметрах.

Ключевое решение: функция buildSceneTree получает проект, шаблон и язык, а возвращает единое дерево сцены. И экранный предпросмотр (через SVG), и экспорт в PDF читают одну и ту же рассчитанную сцену. Рендереры не вычисляют положение элементов заново.

PDFKit (библиотека для генерации PDF) добавляет к координатам из дерева сцены печатные боксы страницы и встраивает утверждённые шрифты. Такая схема исключает расхождение между экраном и печатью, но только если данные в дереве сцены верны. Баги нейросетей проникают именно на уровне данных, до того как рендерер начинает работу.

Какие уроки вынес автор?

Из одного шаблона меню за несколько итераций выросли три семейства документов с русской и английской версиями, отменой действий, форматированием текста, сохранением проекта, проверкой перед печатью и сборками под Windows и macOS.

Но список функций был обычным. Необычной оказалась цена расхождения между тем, что видно на экране, и тем, что получается в PDF. Предпросмотр мог быть приблизительным. Печатный документ для типографии нет.

Автор честно признаёт промах: он забыл про существование готовых движков компоновки и «изобрёл велосипед». Зато получил полный контроль над тем, как сцена превращается в печатный файл.

Как попробовать защититься от похожих ошибок?

1. Добавьте приёмочный тест на уровне предметной области. Проверяйте не «поле существует», а «поле лежит в правильной сущности». В примере автора достаточно было одного теста: «volume позиции блюда читается из Position.volume, а не из PriceNote.volume».

2. Не доверяйте скриншоту. После каждого релиза открывайте итоговый файл (PDF, изображение, вёрстку) и проверяйте критичные элементы вручную. Визуальная проверка на экране скрывает смещения, которые видны в печати.

3. Описывайте ограничения в системном промпте (системный промпт, это начальная инструкция, которая задаёт модели границы поведения). Если у двух сущностей есть одноимённые поля, явно укажите модели, какое поле куда записывать. Без этого нейросеть выбирает путь сама и закрепляет его тестами.

4. Разделяйте уровни тестирования и не считайте их приёмкой по отдельности. Юнит-тесты, структурный разбор PDF и визуальные сравнения закрывают разные уровни. Ни один из них в одиночку не заменяет ручную проверку бизнес-логики.

Есть ли аналогичные инструменты в России?

Автор использовал локальную модель Qwen 2.5 (открытая модель от Alibaba). Из доступных в РФ аналогов для генерации кода подойдут YandexGPT и GigaChat, но обе работают через облако, а не локально.

Для аудитории, которая не пишет код, главный вывод не в выборе модели, а в принципе: любая нейросеть, генерирующая структурированные документы, может незаметно подменить данные между похожими полями. Это касается и тех, кто использует ИИ для генерации таблиц, отчётов или шаблонов в Google Docs, Notion или любом другом инструменте.

Что делать с этим прямо сейчас, по ролям

Автору Дзена. Если вы используете нейросеть для генерации оформленных документов (обложки, карточки, PDF-материалы), проверяйте не только «красиво ли выглядит», а совпадают ли данные с тем, что вы задали. Скриншот обманывает.

Маркетологу. Печатные материалы, сгенерированные с участием ИИ (меню, каталоги, прайсы), требуют ручной сверки перед отправкой в типографию. Ошибка в расположении цены и объёма на меню ресторана портит весь тираж.

Предпринимателю. Если вы внедряете ИИ-генерацию документов в бизнес-процесс, заложите этап ручной приёмки. Автоматические тесты проверяют то, что в них заложили, а не то, что нужно бизнесу.

Частые вопросы

Нужно ли уметь программировать, чтобы столкнуться с такой ошибкой?

Нет. Баги нейросетей в структурированных документах касаются любого, кто использует ИИ для генерации файлов со сложной разметкой: таблиц, PDF, презентаций. Модель может положить число не в ту ячейку, и визуально это будет незаметно.

Почему автоматические тесты не поймали ошибку?

Потому что каждый тест проверял свой уровень: синтаксис кода, структуру PDF, визуальное сходство. Ни один не проверял бизнес-правило: «объём блюда должен лежать в поле позиции, а не в поле ценовой сноски». Тесты доказывали, что код работает, а не что он работает правильно.

Можно ли полностью доверять модели генерацию печатных макетов?

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