Size: a a a

2020 July 16

А

Алексей in QA juniors
Andrew Gasov
А вот это не совсем так работает. Точнее так, но это зависит от уровня тестирования.
Если мы говорим про тестирование как финальный этап обучения модели - то да, всё верно.
Но зачем там участие куак, когда оно является частью сборочных пайплайнов - не очень понятно.
Если мы говорим о тестировании системы, а не модели, то там ассерты конкретных кейсов не менее важны, чем общие метрики.
Ассерты там только на АПИ системы, если это так можно назвать. То есть например обработка фрейма должна идти не более например 15мс, это подходит под ассерт. А вот распознание объекта категории Х и получение его параметров в реальном времени по мере перемещения его по сцене - это уже КПИ тесты, так как детектирование имеет вероятностные факторы, и ассертить тут можно лишь какие то базовые вещи "сцене есть грузовик, система должна сообщить что вроде как видит грузовик с такой то вероятностью". И дальше строим графики которые показывают например вероятность существования грузовика за промежуток времени, сравниваем с результатами других моделей, смотрим изменения и тп. У нас количественно КПИ тестов больше например (без учета тестов прошивок железа и тп низкоуровневых слоев)
источник

А

Алексей in QA juniors
Andrew Gasov
Помимо количества данных есть ещё и качество этих данных, правильная обработка результатов, и ещё куче всего, но в качестве упрощенного представления - тоже да. :)
качество данных это конечно боль. как и аутсорсные аннотаторы. У нас есть отдел, который выборочно контролирует глазами результаты, ну и машинно парсит данные на предмет совсем грубоых косяков. но все равно всякое случается...
источник

AG

Andrew Gasov in QA juniors
Алексей
Ассерты там только на АПИ системы, если это так можно назвать. То есть например обработка фрейма должна идти не более например 15мс, это подходит под ассерт. А вот распознание объекта категории Х и получение его параметров в реальном времени по мере перемещения его по сцене - это уже КПИ тесты, так как детектирование имеет вероятностные факторы, и ассертить тут можно лишь какие то базовые вещи "сцене есть грузовик, система должна сообщить что вроде как видит грузовик с такой то вероятностью". И дальше строим графики которые показывают например вероятность существования грузовика за промежуток времени, сравниваем с результатами других моделей, смотрим изменения и тп. У нас количественно КПИ тестов больше например (без учета тестов прошивок железа и тп низкоуровневых слоев)
Ассерты там могут быть много на что, зависит от целей.
У нас, например, на одном из проектов был скрипт, который отдельно собирал наиболее частотные кейсы по каждому из сценариев и прогонял через модель именно ассертами.
Потому что это оказалось проще, чем дробить метрики по приоритетным\неприоритетным кейсам.
А красивая оценка по TP\TN\FP\FN, к сожалению, не показывет динамику (какие кейсы ты стал детектить хуже, какие лучше).
источник

AG

Andrew Gasov in QA juniors
Алексей
качество данных это конечно боль. как и аутсорсные аннотаторы. У нас есть отдел, который выборочно контролирует глазами результаты, ну и машинно парсит данные на предмет совсем грубоых косяков. но все равно всякое случается...
Размечали данные силами врачей, помогла только двойная слепая разметка + супервизор.
По сути - х3 к стоимости обработки, но иначе такой трешак получался.
источник

А

Алексей in QA juniors
Andrew Gasov
Ассерты там могут быть много на что, зависит от целей.
У нас, например, на одном из проектов был скрипт, который отдельно собирал наиболее частотные кейсы по каждому из сценариев и прогонял через модель именно ассертами.
Потому что это оказалось проще, чем дробить метрики по приоритетным\неприоритетным кейсам.
А красивая оценка по TP\TN\FP\FN, к сожалению, не показывет динамику (какие кейсы ты стал детектить хуже, какие лучше).
Ну тут от назначения проекта конечно зависит, и вообще от проекта. Например приходящие заинтересованные в технологии ребята зачастую хотят именно"красивая оценка по TP\TN\FP\FN". А у нас больше упор идет на maturity алгоритмов, и на сравнение динамики детектирования. Ну и на edge кейсы, куда уж без них.
источник

a

ailin in QA juniors
Кто из регионов по какому графику вы работаете? Как обычно с графиком работы на проектах у новичков? Жесткий он?
источник

ВМ

Вова Мозгин... in QA juniors
5/2 обычный с 10 до 19
источник

a

ailin in QA juniors
Изначально речь шла о графике 9-18, но потом когда стало понятно что команда из мск, поменяли на 10-19. Интересно, как у других, можно ли варьировать время, плюс/минус час
источник

S

SilentVet in QA juniors
ailin
Изначально речь шла о графике 9-18, но потом когда стало понятно что команда из мск, поменяли на 10-19. Интересно, как у других, можно ли варьировать время, плюс/минус час
у моей жены вообще свободный график, главное чтоб время отработал
источник

S

SilentVet in QA juniors
хоть ночью работай
источник

a

ailin in QA juniors
Вот и мне пока непонятно, так как новичок, насколько важна синхронизация по времени с командой
источник

a

ailin in QA juniors
Как процесс происходит
источник

S

SilentVet in QA juniors
у нее это отдельно с участниками проекта просто обговаривается
источник

AI

Anonymous Incognito in QA juniors
ailin
Кто из регионов по какому графику вы работаете? Как обычно с графиком работы на проектах у новичков? Жесткий он?
источник

АБ

Арсений Батыров... in QA juniors
ailin
Изначально речь шла о графике 9-18, но потом когда стало понятно что команда из мск, поменяли на 10-19. Интересно, как у других, можно ли варьировать время, плюс/минус час
Новичкам нет, остальным по ситуации
источник

♪_Ω_©mm™_Ω_♪... in QA juniors
😂
источник

TE

Tatiana Evmenova in QA juniors
у нас синхронизированы определенные рабочие часы у всех
источник

TE

Tatiana Evmenova in QA juniors
в середине дня
источник

AG

Andrew Gasov in QA juniors
Арсений Батыров
Новичкам нет, остальным по ситуации
Это в индрайвере такая дифференциация штанов?
источник

TE

Tatiana Evmenova in QA juniors
а остальные время -на усмотрение, в плане начинаешь пораньше или попозже
источник