Ваш тезис про верхний предел автономности хорошо ложится на генерацию изображений, где «неверное понимание» выглядит особенно коварно.
У нас был такой случай. В API модели есть параметр разрешения, и мы решили включить его для всех задач — на демо-примерах он давал заметно лучший результат. Оказалось, что это не настройка вывода, а переключатель режима: получив его, модель перестаёт править исходник и начинает собирать кадр заново. На одиночном портрете это дало выигрыш, а на групповом снимке из кадра пропал один из двух человек.
Самое неприятное здесь именно то, о чём вы пишете. Задача завершилась со статусом success, файл валиден, разрешение соответствует запрошенному, лицо в кадре есть, картинка красивая. Ни один автоматический проверяющий на нашей стороне не имел шанса это поймать — oracle был человеческим, и то случайно: мы заметили, потому что гоняли A/B и смотрели пары глазами.
Из этого мы вынесли две вещи. Первая — для правки изображений напрашивается очень дешёвый oracle: посчитать лица на входе и на выходе и сравнить. Детектор лиц у нас и так был для других целей, а закрыл бы он именно тот класс ошибок, который дороже всего. Вторая — градиент автономности, кажется, стоит строить не только по оси «время и накопленное доверие», но и по типу входа. У нас один и тот же параметр на одиночном портрете был безопасен, а на групповом снимке — нет, и глобальная настройка «включить всем» тут была заведомо неправильной постановкой вопроса.
Вопрос по автоматике отключения: как вы отличаете низкую утилизацию «пользователь взял десять карт под маленькую модель» от низкой утилизации «задача сейчас в фазе загрузки и препроцессинга данных»? По окну наблюдения, по паттерну метрик или как-то ещё?
И второй момент, вы его упомянули вскользь: пользователь после отключения может просто снова запустить такую же машину. Это в итоге чем-то закрылось — квотами, ценообразованием, разговором — или осталось на уровне «отключаем и надеемся»?
Ваш тезис про верхний предел автономности хорошо ложится на генерацию изображений, где «неверное понимание» выглядит особенно коварно.
У нас был такой случай. В API модели есть параметр разрешения, и мы решили включить его для всех задач — на демо-примерах он давал заметно лучший результат. Оказалось, что это не настройка вывода, а переключатель режима: получив его, модель перестаёт править исходник и начинает собирать кадр заново. На одиночном портрете это дало выигрыш, а на групповом снимке из кадра пропал один из двух человек.
Самое неприятное здесь именно то, о чём вы пишете. Задача завершилась со статусом success, файл валиден, разрешение соответствует запрошенному, лицо в кадре есть, картинка красивая. Ни один автоматический проверяющий на нашей стороне не имел шанса это поймать — oracle был человеческим, и то случайно: мы заметили, потому что гоняли A/B и смотрели пары глазами.
Из этого мы вынесли две вещи. Первая — для правки изображений напрашивается очень дешёвый oracle: посчитать лица на входе и на выходе и сравнить. Детектор лиц у нас и так был для других целей, а закрыл бы он именно тот класс ошибок, который дороже всего. Вторая — градиент автономности, кажется, стоит строить не только по оси «время и накопленное доверие», но и по типу входа. У нас один и тот же параметр на одиночном портрете был безопасен, а на групповом снимке — нет, и глобальная настройка «включить всем» тут была заведомо неправильной постановкой вопроса.
Интересный кейс, спасибо за детали про MIG.
Вопрос по автоматике отключения: как вы отличаете низкую утилизацию «пользователь взял десять карт под маленькую модель» от низкой утилизации «задача сейчас в фазе загрузки и препроцессинга данных»? По окну наблюдения, по паттерну метрик или как-то ещё?
И второй момент, вы его упомянули вскользь: пользователь после отключения может просто снова запустить такую же машину. Это в итоге чем-то закрылось — квотами, ценообразованием, разговором — или осталось на уровне «отключаем и надеемся»?