Алгоритмы и ИИ

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

Была поставлена следующая задача:

написать конвертер графических файлов из одного формата в другой.

Есть программа компоновки растровых однобитных файлов на лист полимерной пластины.

Программа оптимизирует раскладку флексоформ на пластине для безотходного производства. Результат экспортируется в виде двух документов: растрового файла для экспонирования («прожига») формы и векторного файла с контурами для последующей лазерной резки.

Есть лазерный плоттер, который может по векторному файлу резать пластину.

Для точного позиционирования лазерного плоттера используются сквозные метки совмещения — они наносятся на саму пластину при прожиге и служат системой координат для файла резки, гарантируя попадание лазера строго в границы форм.

Векторный формат разметки, в котором сохраняет программа компоновки не поддерживается программой плоттера.

Можно сказать, да что за дичь! Да никакой дичи нет — есть продажи и маркетинг. Купил станок для прожига форм, покупай и станок для раскроя форм.. у этой же компании. За очень большие деньги. Не лазерный. Старый.. с ножиком.

Вот здесь и появляется задача: написать конвертер из одного формата в другой.

На входе у нас файл с расширением .acm. Формат .acm разработан норвежской компанией Kongsberg. Исторически он создавался как закрытый («родной») командный язык (Proprietary Machine Language) для управления собственными плоттерами и режущими станками. Впоследствии бизнес по производству режущих плоттеров Kongsberg перешел под контроль бельгийской компании Esko-Graphics.

Прямой конкурент Esko по технологии изготовления форм является компания Kodak. И что мы видим? Они тоже используют .acm. Поскольку режущие столы Kongsberg (исторические создатели формата) и аналогичные им столы являются стандартами, Kodak добавил полную поддержку вывода в ACM.

Другие производители плоттеров тоже периодически добавляют интеграцию с .acm в свой софт. Чего не скажешь о китайских производителях: они этот формат полностью игнорируют, предлагая по умолчанию классические DXF или PLT, а в свежих версиях — SVG. Встречается и поддержка PDF, но из-за хаотичности его реализации в стороннем софте (даже в условной Figma) этот импорт часто работает некорректно. Использовать PDF без предварительных тестов я крайне не рекомендую.

Надо отдать должное ИИ: разбор формата ACM он выдал просто отличный — чётко разложил по полочкам, где что обозначается и в каких единицах измеряется. Без нейросетей я бы точно дошёл до этого сам методом проб и ошибок, но благодаря им сэкономил добрых 6–10 часов работы. С форматом PLT история повторилась: ИИ не только понятно объяснил его структуру, но и набросал базовый конвертер, который мне осталось лишь слегка доработать.

Однако следующая задача ввела в ступор и меня, и искусственный интеллект с его шаблонными решениями. Справедливости ради отмечу: я использовал бесплатные версии моделей, так что, возможно, дело в ограничениях контекста или логики, но уверенности нет.

Суть проблемы заключалась в следующем: на раскладке форм присутствовала тестовая плашка нестандартного размера — коммерческие формы таких габаритов просто не заказывают. Моя цель была проста: найти этот уникальный прямоугольник и выжечь внутри него номер пластины (взяв его из имени файла). Казалось бы, что может быть проще? Отфильтровать прямоугольники по размерам и встроить туда текст. Но, формат ACM устроен гораздо хитрее.

Рассмотрим на примере. Есть раскладка форм, красным я показал нужный нам прямоугольник – тестовую форму.

Вроде бы какая проблема — найти этот красный прямоугольник. Но проблема есть, для этого я увеличу область прямоугольника и раздвину линии, чтобы они не прикасались — это позволит вам увидеть линии формата ACM.

Как вы видите, линии контура прямоугольника не обязаны замыкаться строго в вершинах прямоугольника. Они могут выходить за пределы угловых стыков или, напротив, прерываться, из-за чего одна сторона фигуры может формироваться из нескольких независимых отрезков. Иными словами, у нашего прямоугольника нет жестко очерченных угловых границ. Как в таких условиях корректно распознать и выделить искомую фигуру?

Формулирую задачу немного поподробнее: найти область ограниченную линиями, линии должны ограничивать прямоугольник определенного размера, получив координаты этой области необходимо в одном углу написать номер. Область может располагаться, как вертикально, так и горизонтально.

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

И вот на третий день нейросеть сдалась и уперлась в тупик. Взамен элегантного алгоритма она выкатила громоздкую многоходовочку: «Сначала делаем шаг А, анализируем, потом на основе этого крутим шаг Б, снова анализируем, и если что — накатываем шаг В...».

Меня хватило на две такие итерации. Прямо в процессе я смоделировал один хитрый вариант пересечения линий, на котором эти две итерации гарантированно ломались. Посмотрел я на этот хаос... и пошел на очередной перекур.

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

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

Таким образом, я получил два массива виртуальных отрезков: горизонтальных и вертикальных. Т.е. одна вертикальная линия могла превратится в два виртуальных отрезка, если к ней примыкает или её пересекает одна горизонтальная линия. Если пересекает две горизонтальных линии, то отрезков будет три и так далее.

Теперь переходим к перебору и анализу этих виртуальных отрезков.

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

Шаг 1: Анализируем конец отрезка. Если есть линия вниз — сворачиваем вниз. Если линии вниз нет, но есть продолжение влево — идем влево. Другие направления сразу отбрасываем: они гарантированно не ведут к нижнему прямоугольнику.

Шаг 2: Двигаясь вниз, ищем первый же поворот направо (это будет нижняя грань).

Шаг 3: По той же аналогии ищем поворот вверх.

Шаг 4: Затем — налево, пока круг прямоугольник не замкнется на нашем стартовом отрезке.

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

Зная, на что способен ИИ, я ждал от него красивого и быстрого решения. Однако первый день хаотичного тестирования различных нейросетей показал: пора остановиться и сфокусироваться. На второй день мне удалось четко сформулировать шаги алгоритма — ИИ даже признал их эффективными и начал использовать в своих ответах.

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

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