[개발 공부] / F-beta score: Precision과 Recall의 무게를 바꾸는 지표.md

F-beta score: Precision과 Recall의 무게를 바꾸는 지표

조회

2026년 7월 13일 | 개발 공부


희귀 장애를 잡는 분류 모델 두 개를 비교하다가 Precision 0.88, Recall 0.42인 모델과 Precision 0.64, Recall 0.73인 모델 앞에서 멈췄다. 전자는 경보를 적게 틀리지만 실제 장애를 절반 넘게 놓치고, 후자는 더 많이 잡는 대신 오탐이 늘어난다. F1 score 하나로 접으면 두 값에 같은 무게가 들어가지만, 운영에서 두 실수의 비용은 같지 않았다. F-beta score는 Precision과 Recall의 조화평균을 유지하면서, β 값으로 어느 쪽을 더 중요하게 볼지 조절하는 지표다.

나는 처음에 β=2라면 Recall을 두 배로 반영한다고 이해했다. 계산식에는 β가 아니라 beta²가 들어가므로 이 설명은 정확하지 않다. β가 1보다 크면 Recall 쪽 실패를 더 강하게 벌주고, 1보다 작으면 Precision 쪽 실패를 더 강하게 벌준다고 해석하는 편이 안전하다. 숫자 하나를 고르는 문제가 아니라 놓친 양성과 잘못 울린 경보 중 어느 비용을 먼저 줄일지 선언하는 일에 가깝다.

F0.5, F1, F2에서 두 모델의 점수가 달라지는 비교 도식
Figure 1. β가 커질수록 Recall이 높은 모델 B가 유리해지고, β가 작으면 Precision이 높은 모델 A가 유리해진다.

F1에서 β 하나를 더한 이유

F1은 Precision과 Recall의 조화평균이다. 둘 중 하나가 낮으면 산술평균보다 점수가 더 크게 내려가서, 양성 예측의 정확성과 양성 회수율을 함께 보기에 좋다. 문제는 두 항의 중요도가 같다는 가정이다. 의료 스크리닝의 1차 선별, 보안 침해 탐지, 설비 고장 조기 경보처럼 false negative가 비싼 작업에서는 Recall을 더 밀어야 할 수 있다. 반대로 자동 차단이나 자동 삭제처럼 false positive가 사용자 피해로 바로 이어지면 Precision을 더 엄격히 봐야 한다.

F-beta는 이 비대칭을 하나의 식 안에 넣는다. 계산은 (1 + beta²) × Precision × Recall / (beta² × Precision + Recall)이다. β=1이면 익숙한 F1이 된다. β=2는 Recall 쪽을 더 중시하는 F2, β=0.5는 Precision 쪽을 더 중시하는 F0.5로 자주 쓴다. 이름은 비슷하지만, 같은 가중치의 F1과 다른 업무 질문을 던지는 셈이다.

같은 두 모델의 순서가 뒤집히는 지점

앞의 모델 A는 Precision 0.88, Recall 0.42다. 모델 B는 Precision 0.64, Recall 0.73이다. F0.5로 계산하면 A는 0.722, B는 0.656이라 A가 앞선다. F1에서는 A가 0.569, B가 0.682로 순서가 뒤집힌다. F2에서는 A가 0.469, B가 0.710으로 차이가 더 벌어진다. 계산식이 모델을 갑자기 좋게 만드는 것은 아니다. 평가자가 무엇을 실패로 볼지 바꾸면서 순위가 달라진 것이다.

모델 Precision Recall F0.5 F1 F2
A 0.88 0.42 0.722 0.569 0.469
B 0.64 0.73 0.656 0.682 0.710

이 표를 보고 “우리 서비스는 놓침이 싫으니 F2를 쓰자”로 바로 끝내면 위험하다. β를 바꾸면 같은 score threshold에서도 모델 순위가 달라질 수 있고, threshold를 움직이면 Precision과 Recall 자체가 다시 변한다. β 선택과 threshold 선택은 연결되어 있지만 같은 결정은 아니다. 업무 비용으로 β를 먼저 정하고, validation set에서 그 기준에 맞는 threshold를 고정한 뒤 test set을 보는 순서가 덜 새어 나간다.

β를 test 결과에 맞추면 생기는 문제

모델 A가 F0.5에서 이기고 모델 B가 F2에서 이긴다는 결과를 이미 본 뒤, 마음에 드는 모델이 이기는 β를 골라서는 안 된다. 그것은 평가 지표 선택이 아니라 test set에 대한 또 다른 튜닝이다. 실무에서는 “한 건 놓칠 때의 비용”과 “한 건 잘못 알릴 때의 비용”, 사람이 하루에 검토할 수 있는 후보 수, 최소 Recall 같은 운영 조건을 먼저 적어야 한다.

β를 비용 비율로 곧장 환산하는 것도 조심스럽다. F-beta는 confusion matrix의 실제 금액을 직접 최소화하는 cost-sensitive loss가 아니다. prevalence가 달라지면 Precision이 함께 흔들리고, 같은 F2라도 배포 트래픽에서 발생하는 경보 수는 크게 달라질 수 있다. 비용이 명확하다면 expected cost나 utility 표를 별도로 계산하고, F-beta는 모델 간 비교를 압축하는 보조 지표로 두는 편이 낫다.

불균형 데이터에서 G-mean과 다른 질문

F-beta와 G-mean은 모두 불균형 분류에서 자주 보이지만 보는 축이 다르다. G-mean은 양성 Recall과 음성 Recall의 기하평균이라 두 클래스를 모두 회수하는지를 묻는다. F-beta는 양성으로 예측한 결과의 Precision과 실제 양성의 Recall을 묶는다. 따라서 음성 클래스 전체의 회수 균형을 직접 보고 싶다면 G-mean이나 Balanced Accuracy가 더 잘 맞고, 양성 후보 목록의 품질과 누락 비용을 함께 보고 싶다면 F-beta가 더 직접적이다.

양성 비율이 매우 낮으면 Precision은 prevalence 변화에 민감하다. 실험 데이터의 양성 비율과 실제 배포 비율이 다르면 F-beta도 예상보다 크게 움직일 수 있다. 그래서 나는 F2가 올랐다는 한 줄 옆에 양성 support, prevalence, Precision, Recall, 경보 건수를 같이 둔다. PR curve에서 운영 가능한 구간이 있는지도 확인한다. 지표 하나가 좋아졌는데 사람이 검토할 후보가 세 배로 늘었다면 그 변화는 모델 성능과 운영 비용을 함께 설명해야 한다.

평가 로그에 남길 최소 항목

내 평가표에는 beta, threshold, positive support, prevalence, Precision, Recall, F-beta를 한 묶음으로 남긴다. β를 정한 근거는 “F2 사용”보다 구체적으로 적는다. 예를 들어 “장애 누락 비용이 오탐 검토 비용보다 크고, Recall 0.70 미만은 배포하지 않음”처럼 최소 조건을 함께 써 둔다. threshold가 validation set에서 선택됐는지, test set에는 고정 적용됐는지도 기록한다.

모델 비교는 평균 F2 한 개로 끝내지 않는다. 여러 seed나 bootstrap 표본에서 순위가 유지되는지 보고, 특정 하위 그룹에서 Precision이 무너지는지 확인한다. 운영 시점에는 실제 경보 수와 missed positive 추정치를 다시 붙인다. F-beta의 장점은 복잡한 trade-off를 한 숫자로 접는 데 있지만, 바로 그 압축 때문에 어떤 실패가 가려졌는지 원래 두 값을 함께 보아야 한다.

F-beta를 공부하고 나서 가장 크게 바뀐 것은 지표 선택 순서였다. 예전에는 여러 점수를 계산한 뒤 가장 설명하기 좋은 값을 골랐다. 지금은 false positive와 false negative 중 무엇이 더 비싼지, 최소한 지켜야 할 Precision 또는 Recall이 무엇인지부터 적는다. 그 다음 β와 threshold를 고정한다. β는 결과표를 꾸미는 숫자가 아니라 모델이 져야 하는 실패를 미리 정하는 계약이라는 해석이 내게는 가장 실용적이었다.

댓글

홈으로 돌아가기

검색 결과

"" 검색 결과입니다.