LLM 코드 리뷰어 평가: 정밀도(Precision), 재현율(Recall) 및 라우팅(Routing)을 위한 오프라인 하네스 (Harness)

측정할 수 없다면, 라우팅할 수 없습니다. 왜 오프라인 평가(Offline evaluation)가 시간이 지남에 따라 개선되는 코드 리뷰어와 팀이 한 스프린트(Sprint) 내에 무시해 버리는 코드 리뷰어를 가르는 차이점인지 알아보겠습니다. 채팅 평가는 '이것이 도움이 되었습니까?'라는 질문에 대한 엄지척(Thumbs-up)과 같이 특별한 정답(Ground truth) 없이 느낌(Vibes)에 의존합니다. 코드 리뷰에는 더 엄격한 무언가가 필요합니다. 5개의 실제 버그를 찾아내고 1개의 가짜 경고를 내보내는 리뷰어는 유용하지만, 1개의 실제 버그를 찾아내고 5개의 가짜 경고를 내보내는 리뷰어는 한 스프린트 내에 무시됩니다. 오프라인 평가는 리뷰어를 배포하기 전에 질문에 답을 제공합니다. 이는 특정 변경 사항을 어떤 모델로 라우팅(Routing)할지, 언제 에스컬레이션(Escalate)할지, 그리고 시스템이 시간이 지남에 따라 나아지고 있는지 아니면 나빠지고 있는지를 알려줍니다. 이것 없이는 모든 라우팅 결정이 추측에 불과합니다.

평가 세트(Evaluation set) 구축하기
인간의 승인/거절(Accept/reject) 결과가 포함된 과거의 풀 리퀘스트(Pull requests)부터 시작하십시오. 이것이 여러분의 정답(Ground truth)입니다. 공격적으로 필터링하십시오: 작성자가 몇 초 만에 무시한 댓글, 리뷰어가 나중에 틀렸음을 인정한 댓글, 이후 삭제된 코드에 대한 댓글 등을 제외하십시오. 남은 것은 인간의 라벨(Label)이 점수를 매기기에 충분히 신뢰할 수 있는 (diff, finding, accept/reject) 트리플(Triples) 세트입니다.

세 가지 슬라이스(Slice)가 세트의 유용성을 결정합니다.
변경 유형 (Change type): null-safety 회귀(Regressions)를 완벽하게 잡아내는 모델은 동시성(Concurrency) 버그를 완전히 놓칠 수 있으며, 그 반대도 마찬가지입니다. 만약 평가 세트의 90%가 스타일 관련 지적(Style nits)이라면, 그 점수는 정확성(Correctness)에 대해 아무것도 알려주지 않습니다.
파일 소유권 (File ownership): 팀마다 서로 다른 코드를 작성하며, 백엔드 서비스(Backend services)에서 높은 점수를 받는 평가자가 프론트엔드 컴포넌트(Frontend components)에서는 폭락할 수 있습니다.
언어 (Language): Python 리뷰어는 타입을 선택적 어노테이션(Optional annotations)으로 처리하지만, TypeScript 리뷰어는 이를 구조적 계약(Structural contracts)으로 취급합니다.
단일 통합 점수는 슬라이스별 실패를 숨깁니다. 슬라이스를 나누고 별도로 점수를 매기십시오.

점수 매기기: 정밀도(Precision), 재현율(Recall), 그리고 중요한 차원들
정밀도(Precision)와 재현율(Recall)은 서로 트레이드오프(Trade-off) 관계에 있습니다. 코드 리뷰에서는 재현율(Recall)보다 정밀도(Precision)가 더 중요합니다. 놓친 실제 버그는 기회비용입니다.

잘못된 플래그(bogus flag)는 신뢰 비용이며, 신뢰는 비선형적으로 붕괴합니다. 단 하나의 풀 리퀘스트(pull request)에서 두세 개의 잘못된 코멘트만 발생해도 개발자가 반사적으로 봇을 무시하기 시작하기에 충분하며, 일단 그러한 습관이 형성되면 리뷰어의 신호 대 잡음비(signal-to-noise ratio)는 아무도 읽지 않기 때문에 무의미해집니다. 어떤 출력이라도 개발자에게 전달되기 전에 재현율(Recall)은 0.7 이상, 정밀도(Precision)는 0.85 이상을 목표로 하십시오.

다단계 라벨링(Multi-tier labeling). 모든 발견 사항이 동일한 가치를 지니는 것은 아니며, 모든 것을 수락/거절(accept/reject)로 통합하면 신호(signal)를 잃게 됩니다. 실제로는 3단계 체계가 더 효과적입니다. 사실관계가 틀렸거나 해로운 발견에는 '강한 거절(Hard Reject)', 유효하지만 가치가 낮은 제안(스타일 지적, 미미한 개선 사항, 기술적으로는 맞지만 우선순위가 낮은 사항)에는 '약한 거절(Soft Reject)', 그리고 유용한 포착에는 '수락(Accept)'을 적용합니다. 3단계 체계를 사용하면 서로 다른 엄격도 수준에서 정밀도(Precision)를 계산할 수 있습니다. '강한 거절'만 고려한 정밀도는 진정으로 해로운 거짓 양성(false positive)의 비율을 포착하며, '약한 거절 + 강한 거절' 정밀도는 개발자의 허용 범위를 더 폭넓게 포착합니다. 이 두 수치는 서로 다른 이야기를 들려주며, 보정(calibration)을 위해 둘 다 중요합니다.

N개 샘플에 대한 자기 일관성(Self-consistency over N samples). 동일한 디프(diff)를 리뷰어에게 여러 번 실행해 보십시오. 매번 다른 발견 사항을 생성한다면, 해당 모델은 해당 작업에 대해 사양이 미달(underspecified)된 것입니다. 낮은 자기 일관성은 운영 환경에서의 높은 거짓 양성(false-positive) 비율과 상관관계가 있으며, 이는 정답(ground truth)에 대비한 전체 정밀도/재현율을 측정하는 것보다 비용이 적게 드는 신호입니다. 이를 모델 버전 및 슬라이스(slice)별로 추적하십시오.

심각도 인지 정밀도(Severity-aware precision).

리뷰어가 루프(loop) 안에 머물지 여부를 예측하는 숫자는 거의 항상 가공되지 않은 정밀도(raw precision)입니다. 신뢰도 교정(Confidence calibration)이 필요합니다. 리뷰어는 자신이 무엇을 모르는지 알아야 합니다. 낮은 신뢰도로 생성된 코멘트는 면책 조항(disclaimer)과 함께 노출하기보다는 라우팅 계층(routing layer)에서 억제되어야 합니다. 어쨌든 노출하는 것이 유혹적일 수 있지만(더 높은 커버리지), 이미 도구를 불신하는 개발자에게 면책 조항은 아무런 무게감을 갖지 못합니다. 오프라인 평가 세트(offline eval set)에서 임계값(threshold)을 교정하십시오. 정밀도가 0.85 이상으로 유지되는 가장 낮은 신뢰도 점수는 얼마입니까? 그보다 낮은 것은 모두 버리십시오.

평가에서 라우팅으로. 오프라인 평가(Offline evaluation)는 일회성 관문이 아닙니다. 이는 프로덕션 환경에서 라우팅 결정(routing decisions)을 이끄는 메커니즘입니다. 분류 라우터(classification router)는 단순한 변경 사항은 저렴하고 빠른 모델로 보내고, 복잡한 변경 사항은 프런티어 모델(frontier model)로 보냅니다. 하지만 분류 정책(classification policy) 자체도 평가가 필요합니다. 무엇이 "복잡함"을 정의하는 임계값입니까? 폴백 체인(fallback chain)은 자기 일관성(self-consistency)이 떨어질 때 저렴한 모델에서 비싼 모델로 에스컬레이션(escalation)되지만, 이 에스컬레이션 임계값 또한 평가가 필요합니다. 두 임계값 모두 하이퍼파라미터(hyperparameters)이며, 오프라인 평가(offline eval)는 이를 튜닝하는 방법입니다.

평가 기반의 A/B 라우팅(Evaluation-driven A/B routing)이 이 모든 것을 하나로 묶습니다. 오프라인 평가 세트를 유지하고, 관련 슬라이스(slice)별로 모든 모델 변체(variant)를 이에 대해 점수화한 뒤, 슬라이스당 가장 높은 점수를 기록한 변체로 프로덕션 트래픽을 라우팅하십시오. 새로운 모델이 출시될 때, 평가 세트는 사용자가 확인하기 전에 그것이 업그레이드인지 아니면 퇴보(regression)인지를 알려줍니다. 특정 슬라이스의 성능이 저하되면 트래픽은 자동으로 다시 전환됩니다. 이것이 수동 개입 없이 모델 업데이트에 적응하는 유일한 라우팅 전략입니다. 앙상블 불일치(Ensemble disagreement) 그 자체가 하나의 라우팅 신호입니다.

저렴한 모델이 변경 사항을 승인했지만 Frontier model이 무언가를 지적한다면, 어떤 모델이 "정확한지"와 관계없이 그 불일치(disagreement)는 표면화할 가치가 있습니다. 평가 세트(eval set)에서 시간에 따라 추적되는 모델 쌍 간의 불일치율(Disagreement rate)은 종종 원시 정밀도(raw precision)의 변화보다 더 빠르게 회귀(regression)를 포착합니다. 예를 들어, 지난주에 95%의 일치율을 보였던 두 모델이 현재 80%의 일치율을 보인다면 무언가 변했다는 뜻이며, 평가 세트만으로는 무엇이 변했는지 알 수 없을 수도 있습니다. 이 평가 하네스(evaluation harness)는 프로덕션 환경에서의 에이전트 기반 코드 리뷰(agentic code review)에 관한 동반 기사에서 설명된 라우팅(routing) 결정에 정보를 제공합니다. 즉, 오프라인 평가 점수가 모델 라우터(model router)와 폴백 체인(fallback chain)의 임계값(thresholds)을 직접적으로 결정합니다.

폐쇄형 피드백 루프 (The closed feedback loop)
오프라인 평가 세트는 노후화됩니다. 코드베이스는 진화하고, 오래된 패턴은 쓸모없게 되며, 새로운 패턴이 등장합니다. 프로덕션에서 수락되거나 기각된 모든 코멘트는 반드시 정답 세트(ground truth set)로 피드백되어야 합니다. 기각된 코멘트는 부정적 예시(negative example)가 됩니다. 즉, 차이점은 없으나 동일한 발견 사항에 대해 정답(ground truth)이 '거절'인 경우입니다. 다음에 모델이 유사한 내용을 제안하면, 오프라인 평가(offline eval)가 개발자가 확인하기 전에 이를 포착합니다. 수락된 코멘트는 긍정적 예시(positive example)가 되어 해당 패턴을 강화합니다. 저장소의 과거 리뷰 스레드에 대한 검색 증강 생성(Retrieval-augmented generation, RAG)을 통해 유사한 과거 코멘트를 찾아낼 수 있으며, 이를 통해 모델이 인간 리뷰어가 약간 다른 표현으로 이미 기각했던 발견 사항을 제안할 때 이를 더 쉽게 식별할 수 있습니다.

이 피드백 루프는 대부분의 팀이 투자를 소홀히 하는 부분입니다. 그들은 평가 세트를 한 번 구축하고 리뷰어를 배포한 뒤, 평가를 정적인 산출물로 취급합니다. 그러면 리뷰어의 성능은 정체되고, 팀은 더 이상 신뢰하지 않게 되며, 프로젝트는 보류됩니다. 이 루프는 릴리스가 거듭될수록 개선되는 리뷰어와 한 분기 내에 비활성화되는 리뷰어를 가르는 차이점입니다. 루프가 없다면 오탐률(false-positive rate)은 기반 모델이 생성하는 대로 나타날 뿐입니다. 루프가 있다면, 릴리스마다 오탐률이 하향 추세를 그리게 됩니다.

남겨진 과제 (Open challenges)
정답 드리프트 (Ground truth drift). 작년의 풀 리퀘스트(pull requests)로 구축된 평가 세트는 작년의 패턴을 평가할 뿐입니다.

코드베이스에 새로운 모듈이 추가되거나, 언어가 변경되거나, 새로운 프레임워크를 채택함에 따라 정답(ground truth)은 노후화됩니다. 최근의 운영 환경에서의 거절(dismissals) 및 승인(accepts) 사례를 샘플링하여 주기적으로 레이블을 다시 지정(re-labeling)하면 세트의 관련성을 유지할 수 있습니다. 신선도 가중치(freshness weighting, 최근 사례가 오래된 사례보다 더 높은 비중을 가짐)를 적용하는 것은 더 가벼운 대안이 될 수 있습니다. 이 기사는 원래 prakharsingh.github.io/notes/evaluating-llm-code-reviewers/ 에서 게시되었습니다.