Проверил, на этом примере сработало. После уточнения центров перед оценкой и сборкой групп исходная картинка с подписью прочиталась без изменений. Спасибо за идею. На перспективных искажениях пока не проверял.
Да, такие сочетания встречаются и внутри QR. Поэтому одного совпадения 1:1:3:1:1 недостаточно: jsQR проверяет узор по нескольким направлениям. В нашем случае и эти проверки пропустили фрагмент подписи. Спасибо за картинку.
Проверки есть, но именно форму треугольника при ранжировании групп jsQR 1.4.0 не оценивает: учитывает похожесть узоров и различие их размеров. Жёсткое требование равных сторон отсекало бы и настоящие QR, снятые под углом. Проверка геометрии здесь могла бы помочь, но её допуски нужно проверять на перспективных искажениях.
Речь о сечении большого углового квадрата, не о линии через весь QR. Через его центр чередование чёрного и белого даёт 1:1:3:1:1; jsQR проверяет его по горизонтали, вертикали и диагоналям. На вашей схеме отмечены выравнивающие узоры и синхронизирующие дорожки. Они не отменяют этот этап поиска.
Проверил на исходном растре: первые три группы оказались одной и той же тройкой в разном порядке. Перебор всех пяти сформированных групп тоже не помог. Здесь нужно менять ещё и формирование групп, а не только перебирать готовый список. Время на камере не измерял.
В сравнении с worker_threads стоит поправить важный момент: у каждого Node Worker собственные V8 isolate и event loop. Проверил на Node 24: пока один воркер занят синхронным циклом, второй отвечает на сообщения. Оба работают в одном процессе.
Сравнивали ваш вариант с заранее созданным пулом Node workers на той же задаче? Snapshot может дать выигрыш на инициализации, но параллельное выполнение в отдельных JS-кучах доступно и без перехода к deno_core. Сейчас в статье это выглядит как преимущество, которого у Node нет.
Проверил команду из CI на минимальном проекте. При npm run knip -- --tsConfig tsconfig.base.json npm дописывает аргументы после tee knip-report.txt, поэтому --tsConfig получает tee, а не Knip. У меня этот запуск падает даже без неиспользуемого кода.
Если убрать повторный --tsConfig, получается обратная проблема: в sh без pipefail неиспользуемый файл попадает в отчёт, но npm run knip возвращает 0, потому что последним успешно отработал tee.
В рабочем CI у вас есть дополнительная обработка кода возврата Knip, которая не вошла в пример? Для проверки, которая должна блокировать MR, это важная деталь.
Вы показываете снижение температуры с 42 до 30 градусов как результат перехода на видео. Но по ходу ещё отключаете скрытые анимации, ограничиваете CSS-подсказку и заменяете часть иконок статикой. А сколько останется от этих 12 градусов разницы, если оставить Lottie, но убрать ту же лишнюю работу? Без такого замера непонятно, что именно выиграло: видео или исправленная реализация.
Проверил вашу картинку. У вас числовой режим, у меня байтовый, поэтому рисунки разные. QR в статье получены тем самым кодом из архива. Повторы справа тоже оттуда, это не ошибка картинки. Для сравнения нужно выставить ещё и байтовый режим, одной версии и маски недостаточно.
К инкрементальному запуску я бы добавил ещё один небольшой набор: мутации, которые возвращают уже исправленные реальные ошибки. При проверке QR-кодировщика мы вернули в изолированную копию неверное число блоков для версии 8-H: пять вместо шести. Размер матрицы и суммарные 242 кодовых слова остались правильными, но два декодера уже не смогли восстановить исходную строку. Для такого контрольного дефекта заранее известно, какое поведение неверно: можно проверить, что регрессионный тест ловит именно поломку, а не просто выполняет нужные строки.
Такой набор не заменяет автоматические мутации, но помогает проверить тесты на ошибках, которые разработчики действительно допускали. Пробовали в команде сохранять подобные «исторические» мутации рядом с обычными прогонами Pitest, особенно для табличных констант?
Самое сложное начинается после отчёта: как доказать, что риск действительно закрыт и не вернулся через два релиза? Есть ли у вас обязательная повторная проверка, срок жизни результата аудита или автоматические контроли, после которых замечание можно считать закрытым не на бумаге, а в работающей системе?
Заинтересовал ai:ap: модель формирует инструкции, а локальный скрипт меняет файловую систему. Планируете ограничивать такие действия набором разрешённых операций и рабочим каталогом, а перед применением показывать полный diff? Иначе самая удобная функция может одновременно стать самой опасной — особенно если модель увидит содержимое недоверенного файла.
Да, я начал с механизма раньше, чем показал сам сценарий. Он простой: человек один раз сканирует код камерой, а интерфейсу нужно показать название товара. Полный код можно отправить во внешний товарный API — тогда его оператор получает код, IP и время. Можно скачать справочник целиком. Мы выбрали третий вариант: наружу уходит только префикс, а браузер забирает один небольшой фрагмент базы.
Но у этого решения было ещё одно предположение: что для короткой сессии «один код и закрыли» начальная загрузка 429 КиБ достаточно существенна, чтобы ради неё усложнять схему. В статье это не подтверждено замерами. Поэтому техническая задача описана, а ответ на более важный вопрос — зачем здесь нужна такая сложность — действительно остался недоказанным. Эту развилку следовало поставить до устройства файлов.
Согласен: при общем размере 429 КиБ это самое спорное место схемы. Шарды появились из предположения «один скан — один маленький запрос», но без замера времени первого скана на типичной мобильной сети это именно гипотеза, а не доказанная экономия. Целый файл при этом заметно проще и даёт настоящую приватность, а версия в URL плюс долгий immutable-кэш убирает цену на повторных посещениях. ETag тоже поможет, хотя при проверке свежести всё равно останется сетевой round trip.
Запрос настоящего шарда вместе с N случайными — интересный промежуточный вариант: сервер будет знать только то, что нужный префикс находится среди N. Но такая защита быстро слабеет на повторных сканах — наборы можно пересекать, размеры и популярность шардов сильно различаются, а случайный файл иногда окажется не килобайтным, а одним из тяжёлых. Если сохранять нарезку, я бы скорее склеивал редкие префиксы в группы близкого размера или дополнял ответы до фиксированного размера.
Так что да: пока замеры не покажут заметный выигрыш первого скана, 1387 шардов больше похожи на переусложнение. Для базы в несколько сотен килобайт один файл, вероятно, честнее.
Ветка уже наполовину ушла в спор, какие из восьми абсурдов абсурдны по-настоящему. Мне это кажется самостоятельным результатом, может и не тем, за которым вы шли: перечислить невозможности заранее не выходит — на каждую находится страна-исключение или афера с долгожителями.
У меня похожая задача решается с другого конца — формальными проверками, которым не нужно знание о мире. Я собираю товарный справочник из открытой выгрузки, и первый фильтр там не смысловой, а арифметический: контрольная цифра номера. В одной выгрузке на 37 892 записи её не прошли 5 120 номеров, 13,5 %. Оговорюсь: это не значит, что все 5 120 — мусор поставщика. Часть почти наверняка мои же потери на разборе: срезанные ведущие нули, UPC-A и EAN-8, попавшие в проверку как EAN-13. Но проверка стоит миллисекунды, ничего не знает про товары и даёт границу, за которой запись дальше по конвейеру уже никто не оспорит.
Вторая половина того же правила — приоритет ошибок: показать чужой товар из-за опечатки в чужой базе хуже, чем не показать ничего, поэтому непрошедшие записи просто выбрасываются.
Понимаю, что аналогия хромает в главном: контрольная цифра работает только потому, что избыточность заложили в номер заранее, а у «плотность 400 000 чел/км²» никакой контрольной суммы нет. Поэтому и спрашиваю про другое: в ваших прогонах встречался случай, когда конвейер отказывался отвечать вместо того, чтобы достроить правдоподобное? Со стороны кажется, что дешевле добиваться отказа, чем более умного детектора абсурда, — но у вас данных по прогонам больше.
Точность посчитана на закрытом наборе из восьми типов, а в бою почти всегда приезжает девятый — документ, которого в списке нет вообще. Метод берёт минимум расстояния, то есть отвечает всегда, и ошибка тут уже не «перепутал полис с заявлением», а «уверенно назвал полисом чужую бумагу». У нас в распознавании кодов камерой это было главным источником неверных срабатываний: пока не появился абсолютный порог на меру близости и явный ответ «не знаю», ближайший класс назначался чему угодно, вплоть до узора на упаковке. Причём порог пришлось подбирать не по своей выборке, а по распределению меры на заведомо чужих входах — они ведут себя иначе, чем плохие свои, и по одним только своим порог ставится слишком мягким. Вы смотрели, как выглядит минимальное расстояние ДТВО для документов вне этих восьми типов — отделяется ли оно от своих настолько, чтобы можно было вводить отказ?
Добавлю сценарий, где форма ломается без единой фабрики: объекты, которые ты не создавал сам, а получил из JSON.parse. Мы разбираем товарные выгрузки прямо в браузере — 32 772 позиции в 1387 файлах, и файлы собраны разными выгрузчиками, так что порядок ключей в них гуляет. Кода при этом один вариант, литералов нет вообще, а call site, читающий одно и то же поле, всё равно видит несколько форм: форму задал не программист, а текст входного файла. Лечится нормализацией — прогнать распарсенное через фабрику с фиксированным порядком полей, — но со стороны это выглядит как лишнее копирование миллиона объектов, и без вашей статьи объяснить, зачем оно, тяжело. А сам нормализующий проход не мерили? Интересно, с какого числа чтений на объект он начинает окупаться.
Зацепил приём с оценкой надёжности по величине корреляционного отклика — у нас в распознавании кодов камерой похожий дешёвый гейт оказался важнее самого декодера. Кадр отбрасывается до попытки разбора, и только так удаётся держать 8 кадров в секунду: декодировать всё подряд просто не успеваешь. Но у такого гейта есть неприятная особенность: низкий отклик одинаково даёт и смазанный кадр, и честно пустой участок без деталей, а это разные ситуации — во втором случае ронять кадр не нужно, нужно ехать дальше. У нас это вылезло на пороге около 110 точек на код: ниже него отклик падал не от смазывания, а оттого, что различать было нечего, и по одному числу эти два случая не отделялись. Вы как-то разводите «размыто» и «нет деталей», или на микроскопе пустых участков в маршруте практически не бывает?
Спасибо за файл с расчётом, методика применимая. Одно наблюдение по самому весомому компоненту — надёжности. У нас в распознавании кодов камерой воспринимаемая надёжность оказалась почти не связана с частотой ошибок: при точности за 90 % пользователи переставали верить сканеру после первой же неверной выдачи. Помогло не улучшение модели, а отказ показывать одиночное чтение: результат подтверждается тремя одинаковыми подряд, разбор идёт 8 кадров в секунду, задержка меньше секунды и не замечается — зато видимых ошибок почти не осталось. То есть один и тот же процент сбоев даёт разную «зрелость» в зависимости от того, успевает ли ошибка стать видимой пользователю. Формулировки блока надёжности этого, кажется, не различают: индекс можно поднять, не починив ни одного бага, просто спрятав сбой за повтором или откатом — что, кстати, для пользователя честный выигрыш, но для приоритизации разработки сигнал совсем другой. Вы такие случаи как-то разводите — сверяете индекс с объективной телеметрией по сбоям?
Про верифицируемость добавлю наблюдение из смежной задачи — распознавания штрихкодов, где формальная проверка встроена прямо в формат. У EAN-13 есть контрольная цифра, и её очень легко принять за доказательство правильного чтения. На деле она надёжно ловит только одиночную ошибку: когда испорчено несколько цифр, по нашим замерам примерно каждый десятый битый номер проходит проверку и выглядит валидным. Мы из-за этого перестали доверять одному чтению и показываем результат только после трёх одинаковых подряд — контроль пришлось вынести из формата в процедуру. Формальные признаки документа работают так же: сходимость дат и наличие печати отсекают явный брак, но не отличают «распознано верно» от «распознано неверно, но правдоподобно», а именно второй случай доходит до аналитика незамеченным. Как у вас эти два сигнала разведены в интерфейсе — численная уверенность по символам и результат формальных проверок показываются раздельно или сводятся в одну оценку?
Проверил, на этом примере сработало. После уточнения центров перед оценкой и сборкой групп исходная картинка с подписью прочиталась без изменений. Спасибо за идею. На перспективных искажениях пока не проверял.
Да, такие сочетания встречаются и внутри QR. Поэтому одного совпадения 1:1:3:1:1 недостаточно: jsQR проверяет узор по нескольким направлениям. В нашем случае и эти проверки пропустили фрагмент подписи. Спасибо за картинку.
Проверки есть, но именно форму треугольника при ранжировании групп jsQR 1.4.0 не оценивает: учитывает похожесть узоров и различие их размеров. Жёсткое требование равных сторон отсекало бы и настоящие QR, снятые под углом. Проверка геометрии здесь могла бы помочь, но её допуски нужно проверять на перспективных искажениях.
Речь о сечении большого углового квадрата, не о линии через весь QR. Через его центр чередование чёрного и белого даёт 1:1:3:1:1; jsQR проверяет его по горизонтали, вертикали и диагоналям. На вашей схеме отмечены выравнивающие узоры и синхронизирующие дорожки. Они не отменяют этот этап поиска.
Проверил на исходном растре: первые три группы оказались одной и той же тройкой в разном порядке. Перебор всех пяти сформированных групп тоже не помог. Здесь нужно менять ещё и формирование групп, а не только перебирать готовый список. Время на камере не измерял.
В сравнении с
worker_threadsстоит поправить важный момент: у каждого Node Worker собственные V8 isolate и event loop. Проверил на Node 24: пока один воркер занят синхронным циклом, второй отвечает на сообщения. Оба работают в одном процессе.Сравнивали ваш вариант с заранее созданным пулом Node workers на той же задаче? Snapshot может дать выигрыш на инициализации, но параллельное выполнение в отдельных JS-кучах доступно и без перехода к
deno_core. Сейчас в статье это выглядит как преимущество, которого у Node нет.Проверил команду из CI на минимальном проекте. При
npm run knip -- --tsConfig tsconfig.base.jsonnpm дописывает аргументы послеtee knip-report.txt, поэтому--tsConfigполучает tee, а не Knip. У меня этот запуск падает даже без неиспользуемого кода.Если убрать повторный
--tsConfig, получается обратная проблема: в sh без pipefail неиспользуемый файл попадает в отчёт, ноnpm run knipвозвращает 0, потому что последним успешно отработал tee.В рабочем CI у вас есть дополнительная обработка кода возврата Knip, которая не вошла в пример? Для проверки, которая должна блокировать MR, это важная деталь.
Вы показываете снижение температуры с 42 до 30 градусов как результат перехода на видео. Но по ходу ещё отключаете скрытые анимации, ограничиваете CSS-подсказку и заменяете часть иконок статикой. А сколько останется от этих 12 градусов разницы, если оставить Lottie, но убрать ту же лишнюю работу? Без такого замера непонятно, что именно выиграло: видео или исправленная реализация.
Проверил вашу картинку. У вас числовой режим, у меня байтовый, поэтому рисунки разные. QR в статье получены тем самым кодом из архива. Повторы справа тоже оттуда, это не ошибка картинки. Для сравнения нужно выставить ещё и байтовый режим, одной версии и маски недостаточно.
К инкрементальному запуску я бы добавил ещё один небольшой набор: мутации, которые возвращают уже исправленные реальные ошибки. При проверке QR-кодировщика мы вернули в изолированную копию неверное число блоков для версии 8-H: пять вместо шести. Размер матрицы и суммарные 242 кодовых слова остались правильными, но два декодера уже не смогли восстановить исходную строку. Для такого контрольного дефекта заранее известно, какое поведение неверно: можно проверить, что регрессионный тест ловит именно поломку, а не просто выполняет нужные строки.
Такой набор не заменяет автоматические мутации, но помогает проверить тесты на ошибках, которые разработчики действительно допускали. Пробовали в команде сохранять подобные «исторические» мутации рядом с обычными прогонами Pitest, особенно для табличных констант?
Самое сложное начинается после отчёта: как доказать, что риск действительно закрыт и не вернулся через два релиза? Есть ли у вас обязательная повторная проверка, срок жизни результата аудита или автоматические контроли, после которых замечание можно считать закрытым не на бумаге, а в работающей системе?
Заинтересовал ai:ap: модель формирует инструкции, а локальный скрипт меняет файловую систему. Планируете ограничивать такие действия набором разрешённых операций и рабочим каталогом, а перед применением показывать полный diff? Иначе самая удобная функция может одновременно стать самой опасной — особенно если модель увидит содержимое недоверенного файла.
Да, я начал с механизма раньше, чем показал сам сценарий. Он простой: человек один раз сканирует код камерой, а интерфейсу нужно показать название товара. Полный код можно отправить во внешний товарный API — тогда его оператор получает код, IP и время. Можно скачать справочник целиком. Мы выбрали третий вариант: наружу уходит только префикс, а браузер забирает один небольшой фрагмент базы.
Но у этого решения было ещё одно предположение: что для короткой сессии «один код и закрыли» начальная загрузка 429 КиБ достаточно существенна, чтобы ради неё усложнять схему. В статье это не подтверждено замерами. Поэтому техническая задача описана, а ответ на более важный вопрос — зачем здесь нужна такая сложность — действительно остался недоказанным. Эту развилку следовало поставить до устройства файлов.
Согласен: при общем размере 429 КиБ это самое спорное место схемы. Шарды появились из предположения «один скан — один маленький запрос», но без замера времени первого скана на типичной мобильной сети это именно гипотеза, а не доказанная экономия. Целый файл при этом заметно проще и даёт настоящую приватность, а версия в URL плюс долгий immutable-кэш убирает цену на повторных посещениях. ETag тоже поможет, хотя при проверке свежести всё равно останется сетевой round trip.
Запрос настоящего шарда вместе с N случайными — интересный промежуточный вариант: сервер будет знать только то, что нужный префикс находится среди N. Но такая защита быстро слабеет на повторных сканах — наборы можно пересекать, размеры и популярность шардов сильно различаются, а случайный файл иногда окажется не килобайтным, а одним из тяжёлых. Если сохранять нарезку, я бы скорее склеивал редкие префиксы в группы близкого размера или дополнял ответы до фиксированного размера.
Так что да: пока замеры не покажут заметный выигрыш первого скана, 1387 шардов больше похожи на переусложнение. Для базы в несколько сотен килобайт один файл, вероятно, честнее.
Ветка уже наполовину ушла в спор, какие из восьми абсурдов абсурдны по-настоящему. Мне это кажется самостоятельным результатом, может и не тем, за которым вы шли: перечислить невозможности заранее не выходит — на каждую находится страна-исключение или афера с долгожителями.
У меня похожая задача решается с другого конца — формальными проверками, которым не нужно знание о мире. Я собираю товарный справочник из открытой выгрузки, и первый фильтр там не смысловой, а арифметический: контрольная цифра номера. В одной выгрузке на 37 892 записи её не прошли 5 120 номеров, 13,5 %. Оговорюсь: это не значит, что все 5 120 — мусор поставщика. Часть почти наверняка мои же потери на разборе: срезанные ведущие нули, UPC-A и EAN-8, попавшие в проверку как EAN-13. Но проверка стоит миллисекунды, ничего не знает про товары и даёт границу, за которой запись дальше по конвейеру уже никто не оспорит.
Вторая половина того же правила — приоритет ошибок: показать чужой товар из-за опечатки в чужой базе хуже, чем не показать ничего, поэтому непрошедшие записи просто выбрасываются.
Понимаю, что аналогия хромает в главном: контрольная цифра работает только потому, что избыточность заложили в номер заранее, а у «плотность 400 000 чел/км²» никакой контрольной суммы нет. Поэтому и спрашиваю про другое: в ваших прогонах встречался случай, когда конвейер отказывался отвечать вместо того, чтобы достроить правдоподобное? Со стороны кажется, что дешевле добиваться отказа, чем более умного детектора абсурда, — но у вас данных по прогонам больше.
Точность посчитана на закрытом наборе из восьми типов, а в бою почти всегда приезжает девятый — документ, которого в списке нет вообще. Метод берёт минимум расстояния, то есть отвечает всегда, и ошибка тут уже не «перепутал полис с заявлением», а «уверенно назвал полисом чужую бумагу». У нас в распознавании кодов камерой это было главным источником неверных срабатываний: пока не появился абсолютный порог на меру близости и явный ответ «не знаю», ближайший класс назначался чему угодно, вплоть до узора на упаковке. Причём порог пришлось подбирать не по своей выборке, а по распределению меры на заведомо чужих входах — они ведут себя иначе, чем плохие свои, и по одним только своим порог ставится слишком мягким. Вы смотрели, как выглядит минимальное расстояние ДТВО для документов вне этих восьми типов — отделяется ли оно от своих настолько, чтобы можно было вводить отказ?
Добавлю сценарий, где форма ломается без единой фабрики: объекты, которые ты не создавал сам, а получил из JSON.parse. Мы разбираем товарные выгрузки прямо в браузере — 32 772 позиции в 1387 файлах, и файлы собраны разными выгрузчиками, так что порядок ключей в них гуляет. Кода при этом один вариант, литералов нет вообще, а call site, читающий одно и то же поле, всё равно видит несколько форм: форму задал не программист, а текст входного файла. Лечится нормализацией — прогнать распарсенное через фабрику с фиксированным порядком полей, — но со стороны это выглядит как лишнее копирование миллиона объектов, и без вашей статьи объяснить, зачем оно, тяжело. А сам нормализующий проход не мерили? Интересно, с какого числа чтений на объект он начинает окупаться.
Зацепил приём с оценкой надёжности по величине корреляционного отклика — у нас в распознавании кодов камерой похожий дешёвый гейт оказался важнее самого декодера. Кадр отбрасывается до попытки разбора, и только так удаётся держать 8 кадров в секунду: декодировать всё подряд просто не успеваешь. Но у такого гейта есть неприятная особенность: низкий отклик одинаково даёт и смазанный кадр, и честно пустой участок без деталей, а это разные ситуации — во втором случае ронять кадр не нужно, нужно ехать дальше. У нас это вылезло на пороге около 110 точек на код: ниже него отклик падал не от смазывания, а оттого, что различать было нечего, и по одному числу эти два случая не отделялись. Вы как-то разводите «размыто» и «нет деталей», или на микроскопе пустых участков в маршруте практически не бывает?
Спасибо за файл с расчётом, методика применимая. Одно наблюдение по самому весомому компоненту — надёжности. У нас в распознавании кодов камерой воспринимаемая надёжность оказалась почти не связана с частотой ошибок: при точности за 90 % пользователи переставали верить сканеру после первой же неверной выдачи. Помогло не улучшение модели, а отказ показывать одиночное чтение: результат подтверждается тремя одинаковыми подряд, разбор идёт 8 кадров в секунду, задержка меньше секунды и не замечается — зато видимых ошибок почти не осталось. То есть один и тот же процент сбоев даёт разную «зрелость» в зависимости от того, успевает ли ошибка стать видимой пользователю. Формулировки блока надёжности этого, кажется, не различают: индекс можно поднять, не починив ни одного бага, просто спрятав сбой за повтором или откатом — что, кстати, для пользователя честный выигрыш, но для приоритизации разработки сигнал совсем другой. Вы такие случаи как-то разводите — сверяете индекс с объективной телеметрией по сбоям?
Про верифицируемость добавлю наблюдение из смежной задачи — распознавания штрихкодов, где формальная проверка встроена прямо в формат. У EAN-13 есть контрольная цифра, и её очень легко принять за доказательство правильного чтения. На деле она надёжно ловит только одиночную ошибку: когда испорчено несколько цифр, по нашим замерам примерно каждый десятый битый номер проходит проверку и выглядит валидным. Мы из-за этого перестали доверять одному чтению и показываем результат только после трёх одинаковых подряд — контроль пришлось вынести из формата в процедуру. Формальные признаки документа работают так же: сходимость дат и наличие печати отсекают явный брак, но не отличают «распознано верно» от «распознано неверно, но правдоподобно», а именно второй случай доходит до аналитика незамеченным. Как у вас эти два сигнала разведены в интерфейсе — численная уверенность по символам и результат формальных проверок показываются раздельно или сводятся в одну оценку?