Проверка макета нейросетью: что агент находит сам и как научить его ошибаться реже

Коротко

Насколько агент ошибается при проверке макета?

На обучении для отдела дизайна один из первых вопросов дня касался вовсе не генерации картинок. Речь зашла о внутренней задаче - проверять макет на ошибки, и прозвучал вопрос: «Насколько вообще-то он ошибается? Он всегда ошибается?»

Я ответил: «Он всегда ошибается, если его не научить». И сразу перевёл в практику. Делаем задачу первый раз - агент чего-то не видит. Смотрим сами, указываем на промахи, запускаем ещё.

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

Лучшая аналогия здесь - стажёр. Пришёл человек из другой компании, знания есть, а как у вас принято сверять этикетку, ему неизвестно. Идеальной первой работы от него никто не ждёт. Ты показываешь на примерах, что нормально, что брак, и со временем он справляется сам.

С ИИ-агентом так же, только обучение записывается в файл и остаётся у компании, даже когда сотрудник уходит.

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

Граница: что агент находит по картинке, а что нет

Колонку «по исходнику» на обучении не прогоняли: это то, чего стоит ждать от редактируемого файла, а не измерение.

Ключевая строка запроса из упражнения с этикетками: ничего не исправлять додумывая, а если по картинке пункт проверить нельзя, например шрифт, так и написать. Без неё агент может заполнить пустую клетку правдоподобным «соответствует», и ты не узнаешь, что пункт не проверялся.

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

Почему найти ошибку не значит исправить её?

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

Группа рассчитывала на исправленные файлы. Из группы объяснили: мы попросили, чтобы он исправил неправильное. Вместо исправленных картинок пришёл аудит и Excel с подсвеченными строками.

А в ответе агент написал: для точного выполнения пунктов по шрифтам, размерам и выравниванию лучше нужны редактируемые исходники или редактируемый PDF, плюс новый логотип и знак качества.

Поведение правильное. Перерисовать надпись на растровой этикетке агент может, но выйдет похожая этикетка, а совпадения с исходником уже не будет. Для упаковки, которая идёт в печать, «похоже» не годится.

Сверка с ТЗ: где агент полезнее всего

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

Первая догадка была такая, будто дело в разных артикулах: наверное, образец на один, а ТЗ на другие. Агент такую разницу уже учёл. Противоречие сидело внутри строк для новых артикулов: в характеристиках нагрузка вдвое больше, чем в рекомендациях. Он предложил взять рекомендацию, но решение оставил людям.

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

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

Как научить агента проверке до того, как делать скилл?

Скилл, сохранённый после первого прогона, закрепляет первые ошибки. Поэтому порядок такой.

1. Прогон на одном макете

   Дай агенту макет, ТЗ и строку про честность: что по этому формату проверить нельзя, так и напиши. Попроси таблицу вместо абзаца.

2. Сверка глазами

   Пройди макет сам и отметь, какие ошибки агент пропустил и какие отметил зря. Без такой разметки обучать нечему.

3. Разбор пропусков

   Перечисли агенту пропущенное и спроси: почему ты это не нашёл. Ответ покажет, чего не хватало задаче: правила, примера или исходника.

4. Повтор на другом макете

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

5. Сохранение

   Когда на разных макетах пропуски перестали повторяться, попроси сохранить путь как скилл. Дальше достаточно сказать: примени скилл проверки к этим файлам.

Разницу между «запомни» и «сделай скилл» на обучении спросили отдельно. «Запомни» - агент допишет строку в постоянные правила проекта, и она будет действовать во всех задачах папки. «Сделай скилл» - появится отдельный навык: по документации им служит папка с файлом SKILL.md, где есть название, описание и шаги.

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

Как понять, созрела ли задача для такой инструкции, я подробно разбирал в статье про задачу, которая повторилась третий раз.

Почему каждую проверку нужно держать в своей папке?

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

Я ответил честно: может быть, и подсмотрел. Проверяется просто: дать подобное задание там, где подсмотреть негде. Результат держится - навык, скорее всего, настоящий. Проваливается - знание жило в соседней папке, а агент им только воспользовался.

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

1. Одна сверка - одна папка: макеты, ТЗ, образец этой задачи, и больше ничего.
2. Эталонные ответы для обучения лежат отдельно и подкладываются, только когда ты сам решил их показать.
3. Готовую процедуру принимаешь на свежем макете, которого агент раньше не видел.

Как убедиться, что агент сделал заявленное, а не просто отчитался, разбирал в статье про проверку выполнения задачи.

Когда проверка агентом окупается?

Расчёт простой. Первые прогоны и разбор ошибок отнимают время, которого на одном макете хватило бы на ручную сверку. Выигрыш появляется на объёме.

Важно и то, что остаётся за людьми. Противоречие в ТЗ агент находит, но какая нагрузка правильная, решает технолог или продакт. Подсвеченную строку правит дизайнер. Финальную подпись под макетом ставит тот, кто отвечает за упаковку.

Для руководителя отсюда понятный короткий пилот: одна типовая задача отдела, один ответственный дизайнер, который учит агента, и сравнение «сколько ошибок нашёл человек, сколько агент, сколько оба» на одной партии. Какие ещё задачи отдела можно отдать агенту, смотри в материале про агента в Excel и PowerPoint.

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

Главный вывод

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

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

Какую сверку в твоём отделе люди чаще всего делают вручную?