Насколько точен IQR для обнаружения выбросов


11

Я пишу сценарий, который анализирует время выполнения процессов. Я не уверен в их распространении, но хочу знать, выполняется ли процесс «слишком долго». До сих пор я использовал 3 стандартных отклонения времени последнего запуска (n> 30), но мне сказали, что это не дает ничего полезного, если данные не являются нормальными (что, похоже, не так). Я нашел другой тест на выбросы, в котором говорится:

Найти межквартильный диапазон, который равен IQR = Q3 - Q1, где Q3 - третий квартиль, а Q1 - первый квартиль. Затем найдите эти два числа:

а) Q1 - 1,5 * IQR b) Q3 + 1,5 * IQR

Точка является выбросом, если <a или> b

Мои данные обычно бывают такими, как 2 с, 3 с, 2 с, 5 с, 300 с, 4 с, .... где 300 с, очевидно, являются выбросом.

Какой метод лучше? Метод IQR или метод стандартного отклонения?


4
Вы можете проверить ответ @ user603 здесь: есть ли вариант коробчатого графика для распределенных по Пуассону данных для получения информации о том, как настроить это правило для искаженных данных.
gung - Восстановить Монику

3
Этот метод «IQR» никогда не предназначался для слепого применения. Это часть процесса исследовательского анализа данных (описанного Ником Коксом в его ответе), в ходе которого вы сначала найдете способ переразметить данные, чтобы сделать их приблизительно симметрично распределенными.
whuber

2
Исходя из ваших комментариев к ответам, правильный ответ «ни того, ни другого», потому что ваша основная задача не в выбросах, а в процессе.
whuber

Связанный: Обнаружение выбросов с использованием стандартных отклонений является оборотной стороной этого вопроса
user56reinstatemonica8

Числа являются time_taken, поэтому они никогда не будут симметричными, если вы не измените их масштаб.
JP Bennett

Ответы:


14

Там действительно целые книги о выбросах.

Обычный конкретный ответ таков: стандартное отклонение определяется выбросами, поэтому любое правило, основанное на SD, может работать плохо.

Правила Тьюки для квартилей +/- 1,5 IQR, которые вы цитируете, были созданы вручную с небольшими и средними наборами данных в 1970-х годах и были разработаны для указания значений, о которых вы можете подумать индивидуально. Не ясно, что они переносятся на гораздо большие наборы данных или что они применяются, когда вы ожидаете значительной асимметрии.

Более общий ответ заключается в том, что правило выброса хорошо, если оно всегда принимает правильные решения, но как вы можете это определить?

Это спорная территория, но я ожидаю, что на графике будут выделяться выбросы, которые сильно отличаются от других. Но это часто (обычно?) Трудный вызов, чтобы определить разницу между тем, что вы ожидаете в дистрибутиве с тяжелыми хвостами, и тем, что слишком дико, чтобы воспринимать что-либо кроме постороннего. Иногда трансформация делает внешний вид гораздо более обычным.

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


1

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

Ваш поиск правила для выброса не должен быть настолько общим. Это может быть специфичным для вашей задачи. Вы можете собрать много данных. Соберите его, изучите, а затем решите, когда процесс будет слишком долгим. Возможно, подойдет подход, основанный на IQR, но вы можете использовать свой набор данных или параметрическое соответствие для моделирования и проверки, хорошо ли он работает. То же самое касается SD. Возможно, что> 50-е - это слишком долго, и это все, что вам нужно.


Я собираю данные о нескольких процессах. Они могут иметь разные распределения. Мне просто нужен простой способ сказать «слишком большое время работы», чтобы предупредить техников о необходимости дальнейшего изучения. Он может быть общим, если он помечает вещи, которые должны быть помечены. Если появятся несколько ложных срабатываний, пусть будет так. Однако количество ложных срабатываний должно быть сведено к минимуму, поскольку, если их слишком много, это наносит ущерб цели сценария, и я должен просто выбросить все результаты и позволить техническим специалистам это сделать. Цель сценария - «сузить
круг

Вы можете оценить, являются ли процессы одинаковыми или разными. Если они действительно очень разные, то какое-то общее правило может привести к тому, что определенный процесс будет вызывать предупреждение чаще, чем необходимо. Эта информация действительно должна быть в вашем вопросе.
Джон

3
Характеризуя эту проблему как поиск отклонений, Крис делает ее несправедливой: вы на самом деле решаете проблему контроля качества . Принципиальные отличия: (1) у вас есть непрерывный поток данных, а не статический набор данных для анализа, и (2) вы намереваетесь указать периодические действия, которые необходимо предпринять в результате каждого анализа: то есть вмешиваться (и пытаться улучшить процесс) или нет (и пусть процесс работает как есть). Понимание того, что это характер вашей проблемы, показывает, что огромная литература по контролю качества актуальна, предоставляя богатый ассортимент решений.
whuber

+1 @whuber. Выбросы здесь не актуальны. Ни среднее время пробега, ни процентиль не связаны с тем, что «слишком долго». Способом выяснить, что является «слишком длинным», может быть опрос пользователей, или проверка с инженерами, или просто догадки, или что-то еще, но это не статистический вопрос.
Питер Флом - Восстановить Монику
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.