Перейти к содержанию
Содержание

Два контролёра проверили одни заказы: сравните решения попарно

Два сотрудника независимо проверили одни и те же заказы и отметили наличие ошибок сборки. Сравнение двух процентов теряет важную информацию: на каких именно заказах решения разошлись. Сохраните пары, прежде чем делать вывод о различиях в работе контроля.

Подготовьте независимые решения по одной выборке

Для каждого заказа нужны ID и два исхода: «ошибка есть» или «ошибки нет». Оба контролёра должны оценивать одно и то же состояние заказа по одинаковому определению ошибки. Второй не должен исправлять заказ до завершения обеих оценок или переписывать свой ответ после обсуждения с первым.

Два контролёра проверили одни заказы: сравните решения попарно

Заказы должны быть отдельными единицами наблюдения. Повторные строки одного заказа не добавляют независимых проверок. Если заказы объединены общей причиной, например одним инцидентом комплектования, обсудите зависимость наблюдений с аналитиком до выбора теста.

Отдельно сохраните заказы без одного из решений. Пропуск не означает отсутствие ошибки. Не подменяйте парную выборку двумя группами разных заказов: для независимых групп подходит другой план, например проверка различия тестом Фишера.

Составьте таблицу решений

Решение AB: ошибка естьB: ошибки нет
Ошибка естьab
Ошибки нетcd

В каждой ячейке количество заказов, а не ошибок внутри заказа. Сумма 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

0 / 1500

Популярные статьи