Содержание
Два контролёра проверили одни заказы: сравните решения попарно
Два сотрудника независимо проверили одни и те же заказы и отметили наличие ошибок сборки. Сравнение двух процентов теряет важную информацию: на каких именно заказах решения разошлись. Сохраните пары, прежде чем делать вывод о различиях в работе контроля.
Подготовьте независимые решения по одной выборке
Для каждого заказа нужны ID и два исхода: «ошибка есть» или «ошибки нет». Оба контролёра должны оценивать одно и то же состояние заказа по одинаковому определению ошибки. Второй не должен исправлять заказ до завершения обеих оценок или переписывать свой ответ после обсуждения с первым.
Заказы должны быть отдельными единицами наблюдения. Повторные строки одного заказа не добавляют независимых проверок. Если заказы объединены общей причиной, например одним инцидентом комплектования, обсудите зависимость наблюдений с аналитиком до выбора теста.
Отдельно сохраните заказы без одного из решений. Пропуск не означает отсутствие ошибки. Не подменяйте парную выборку двумя группами разных заказов: для независимых групп подходит другой план, например проверка различия тестом Фишера.
Составьте таблицу решений
| Решение A | B: ошибка есть | B: ошибки нет |
|---|---|---|
| Ошибка есть | a | b |
| Ошибки нет | c | d |
В каждой ячейке количество заказов, а не ошибок внутри заказа. Сумма a+b+c+d должна совпасть с числом полных пар. Диагональ a+d показывает совпадения, а b+c все расхождения. Сохраните долю расхождений (b+c)/(a+b+c+d) рядом с таблицей.
Здесь буквы обозначают фактические количества вашей проверки. Если b больше c, A чаще отмечал ошибку там, где B её не отмечал. Это описание решений, а не доказательство большей точности A.
Проверьте направленность расхождений
Тест Макнемара проверяет равенство предельных распределений парных бинарных исходов. Он использует несовпавшие пары. В документации statsmodels exact=True включает точную биномиальную проверку; поправка correction относится к приближённому варианту с exact=False.
Согласуйте порог значимости до просмотра результата. Пример ниже принимает четыре ваших количества, не создавая учебных результатов. Нужен Python с установленным statsmodels.
from statsmodels.stats.contingency_tables import mcnemar
a, b, c, d = map(int, input("a b c d: ").split())
n = a + b + c + d
if min(a, b, c, d) < 0 or n == 0:
raise ValueError("Нужны неотрицательные количества и полные пары")
print("Доля расхождений:", (b + c) / n)
print("Разность долей отметок ошибки A и B:", (b - c) / n)
if b + c == 0:
print("Расхождений нет; направления для сравнения не наблюдалось")
else:
result = mcnemar([[a, b], [c, d]], exact=True)
print("p-value:", result.pvalue)
Разделите вывод теста и качество контроля
Малое p-value относительно выбранного порога даёт основание отвергнуть равенство предельных распределений в рамках модели теста. Большое p-value не доказывает одинаковую работу: несовпавших пар может быть мало.
Тест не измеряет согласие целиком. Одинаковые количества расхождений в двух направлениях могут сочетаться с большим общим числом несовпадений. Поэтому таблица и доля расхождений остаются в отчёте независимо от p-value.
Чтобы понять, кто верно обнаружил ошибку, нужен отдельный разбор с проверяемым эталоном: состав заказа, товар, количество и зафиксированное состояние. Без него нельзя назвать более строгого контролёра более точным. Разберите спорные заказы, уточните критерии и сохраните новую версию инструкции отдельно от исходных оценок.
Результат задачи: связанная по ID выборка, таблица четырёх исходов, доля и направление расхождений, параметры теста и список случаев для разбора. Он позволяет отличить систематическое различие решений от вопроса о фактической правильности проверки.
Комментарии 0