특이 치를 탐지하기위한 IQR의 정확도


11

프로세스의 실행 시간을 분석하는 스크립트를 작성 중입니다. 배포가 확실하지 않지만 프로세스가 "너무 오래"실행되고 있는지 알고 싶습니다. 지금까지 마지막 실행 시간 (n> 30)의 3 표준 편차를 사용했지만 데이터가 정상이 아닌 경우 (그렇지 않은 것으로 보이는 경우) 유용한 것을 제공하지 않는다고 들었습니다. 나는 다른 이상치 테스트를 발견했다.

사 분위 간 범위 (IQR = Q3-Q1)를 찾으십시오. 여기서 Q3은 3 분위이고 Q1은 첫 번째 사 분위수입니다. 그런 다음이 두 숫자를 찾으십시오.

a) Q1-1.5 * IQR b) Q3 + 1.5 * IQR

<a 또는> b 인 경우 점은 특이 치입니다.

내 데이터는 2 초, 3 초, 2 초, 5 초, 300 초, 4 초 등의 경향이 있습니다. 여기서 300 초는 분명히 이상치입니다.

어떤 방법이 더 낫습니까? IQR 방법 또는 표준 편차 방법?


4
@ user603 's answer here을 확인하고 싶을 수 있습니다 . 기울어 진 데이터에 대해이 규칙을 조정하는 방법에 대한 정보 는 포아송 분산 데이터에 대한 상자 그림 변형이 있습니까 ?
gung-Monica Monica 복원

3
이 "IQR"방법은 맹목적으로 적용되지 않았습니다. 이 데이터는 탐색 적 데이터 분석 프로세스 (Nick Cox가 그의 답변에 설명)에 따라 데이터를 대략 대칭 적으로 분포하도록 데이터를 다시 표현하는 방법을 먼저 찾게됩니다.
whuber

2
답변에 대한 귀하의 의견을 바탕으로 올바른 답변은 "아무 것도 아닙니다". 기본 관심사는 특이 치에 대한 것이 아니라 프로세스
whuber


숫자는 시간이 걸리므로 어떤 식 으로든 크기를 조정하지 않으면 절대 대칭이되지 않습니다.
JP 베넷

답변:


14

특이 치에 대한 전체 책이 실제로 있습니다.

일반적인 구체적인 답변은 표준 편차가 특이 치에 의해 풀리기 때문에 SD를 기반으로하는 규칙이 제대로 수행되지 않을 수 있다는 것입니다.

인용 한 사 분위수 +/- 1.5 IQR에 대한 Tukey 규칙은 1970 년대에 중소 규모의 데이터 집합을 사용하여 수작업에서 비롯되었으며 개별적으로 생각할 가치가있는 값을 나타내도록 설계되었습니다. 그것들이 훨씬 더 큰 데이터 세트로 전달되거나 상당한 왜곡을 기대할 때 적용되는지는 확실하지 않습니다.

더 일반적인 대답은 항상 올바른 결정을 내리면 특이 치 규칙이 좋다는 것입니다. 그러나 어떻게 알 수 있습니까?

이것은 논쟁의 여지가 있지만, 다른 사람들과는 매우 다른 것으로 이상 치가 그래프에 튀어 나올 것으로 기대합니다. 그러나 종종 두꺼운 꼬리 분포에서 기대하는 것과 특이 치 이외의 것으로 간주하기에는 너무 거친 것 사이의 차이를 알려주는 것은 종종 어려운 요청입니다. 때로는 변형이 특이 치를 훨씬 더 평범하게 보이게 만듭니다.

또한 강력한 방법을 사용하면 어떤 값이 특이 치라고 불리는 지에 대해 조금 덜 걱정할 수 있지만 일반적으로 특이 치에 대해 걱정할 수 있습니다.


1

배포에 대해서는 확신하지 못하지만 진행중인 프로세스는 쉽게 수집하고 배포 할 수 있습니다. 많은 시간을 절약하고 분석하십시오. 당신이 게시 한 시간을 감안하면 몇 시간 만에 많은 것을 얻을 수 있습니다.

특이 치에 대한 규칙 검색은 그리 일반적 일 필요는 없습니다. 작업에 따라 다를 수 있습니다. 많은 데이터를 수집 할 수 있습니다. 수집하여 조사한 후 프로세스가 너무 긴시기를 결정하십시오. 아마도 IQR 기반 접근 방식은 효과가 있지만 데이터 세트 또는 파라 메트릭 적합을 사용하여 시뮬레이션을 수행하고 제대로 작동하는지 확인할 수 있습니다. SD도 마찬가지입니다. > 50s가 너무 길면 이것이 전부입니다.


여러 프로세스에서 데이터를 수집하고 있습니다. 그들은 각각 다른 분포를 가질 수 있습니다. 기술자에게 상황을 자세히 조사하도록 경고하기 위해 "실행 시간이 너무 큼"이라는 간단한 방법이 필요합니다. 신고해야 할 사항을 표시하는 한 일반적 일 수 있습니다. 오 탐지가 몇 개 있으면 나타납니다. 그러나 거짓 긍정은 최소한으로 유지해야합니다. 너무 많으면 스크립트의 목적을 무효로하기 때문에 모든 결과를 덤프하고 기술자가 그 결과를 얻도록해야합니다. 스크립트의 목적은 "아래로 좁은 것"이다
크리스 bedd

프로세스가 동일한 지 또는 다른지 평가할 수 있습니다. 이들이 매우 다른 경우, 일부 일반적인 규칙은 특정 프로세스가 필요한 것보다 더 자주 경고를 트리거하는 경향이있을 수 있습니다. 이 정보는 실제로 귀하의 질문에 있어야합니다.
John

3
이 문제를 특이 치에 대한 검색으로 특징 짓는 chris는 불의를합니다. 실제로 품질 관리 문제를 해결하고 있습니다 . 주요 차이점은 (1) 분석 할 정적 데이터 세트가 아닌 지속적인 데이터 스트림이 있고 (2) 각 분석의 결과로 수행 할 주기적 조치를 지정하려는 것입니다. 즉, 개입 여부 (및 프로세스 개선) 또는 아닙니다 (및 프로세스를 그대로 실행). 이것이 문제의 본질이라는 것을 이해하면 품질 관리에 관한 거대한 문헌이 관련되어 있으며 다양한 솔루션을 제공합니다.
whuber

+1 @whuber 특이 치는 여기서 관련이 없습니다. 평균 실행 시간이나 백분위 수는 "너무 긴"것과 관련이 없습니다. "너무 긴"항목을 찾는 방법은 사용자에 대한 설문 조사, 엔지니어와의 확인, 바지 추측 등의 내용 일 수 있지만 통계적인 질문은 아닙니다.
Peter Flom
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.