Почему 10/10 не всегда означает качество модели

Канал о системном и бизнес-анализе, продуктовом мышлении и архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT. Все вопросы - @innokentyB

pass rateкачество моделиремонт

Я довольно долго считал «10 из 10» самым понятным результатом теста модели. Все сценарии приняты, значит, конфигурация работает.

После разбора первичных записей эта цифра стала для меня гораздо менее удобной.

В одном эксперименте все три маршрута получили 10 принятых результатов из 10. Но первому маршруту понадобилось три ремонта, второму два, третьему один. Итоговый pass rate одинаковый, а путь к нему разный.

Поэтому 10/10 здесь описывает не модель отдельно, а всю связку: модель, контракт результата, проверку, ремонт и повторную проверку.

Исторический набор показал другую проблему со знаменателем. В нём сохранилась 21 запись. Только четыре содержали полный результат, который можно было допустить к оценке качества. Остальные 17 были незавершёнными или повреждёнными. Раньше я складывал их в один ряд с полными, но плохими ответами модели.

Теперь я развожу три вопроса:

  1. Агент завершил работу и вернул целый результат?
  2. Результат прошёл заранее заданные проверки?
  3. Человек принял его для исходной задачи?

«10 из 10» отвечает только внутри конкретного контура проверки. Без числа ремонтов, исходного знаменателя и границы человеческой приёмки эта цифра не доказывает качество модели.

Мне понадобилось несколько десятков прогонов, чтобы перестать читать pass rate отдельно от процесса, который его произвёл.

Читайте так же