언어 모델(Language model)이 더 신뢰할 수 있게 만들고 싶을 때 누구나 시도하는 기술이 있습니다. 바로 모델을 몇 번 실행한 뒤 다수의 답변을 채택하는 것입니다. 자기 일관성 (Self-consistency). 다섯 번 샘플링하고, 투표하여, 승자를 출시하는 방식이죠. 이는 모든 "LLM을 더 정확하게 만드는 방법" 포스트에 등장하는 내용입니다.

저는 모델의 실패 경계선(failure frontier)에 있는 문제들을 대상으로 이 방식과 대안을 비교 측정했으며, 그 결과는 통념과는 정반대였습니다: 다수결 투표 (Majority voting)는 거의 도움이 되지 않았으며, 단일 최적 추론기 (single best reasoner)보다 점수가 더 낮았습니다. 실제로 효과가 있었던 방식 — 가장 잘 검증된 (verified) 답변을 유지하는 것 — 은 다수결보다 22점이나 높았습니다.

다음은 동일한 고정 모델, 동일한 문제에 대해 Python으로 계산된 정답 (ground truth)을 기준으로 채점한 데이터입니다 (따라서 채점은 모델이 스스로 숙제를 채점하는 것이 아니라 객관적입니다):

모델 주변의 스캐폴드 (Scaffold)	정확도 (Accuracy)
단일 패스 (single pass, 하나의 샘플)	28%
...

투표는 아무것도 하지 않았을 때보다 +2점을 얻었습니다. 검증기 (verifier)는 +22점을 얻었습니다.

투표가 실패하는 구체적인 이유

문제들은 부분집합 합 (subset-sum) 문제였습니다 — 지름길이 없는 진정한 탐색(search)이며, 신중한 추론만으로 근사치를 구할 수 있는 종류의 작업입니다. 투표가 왜 실패했는지 살펴보았을 때, 두 가지 실패 모드 (failure modes)가 답변에 그대로 나타나 있었습니다.

상관관계가 있는 오류 (Correlated errors). 여러 문제에서 다섯 명의 추론기 모두가 동일한 오답을 반환했습니다 — 그들이 모두 빠져든 흔한 탐욕적 지역 최적점 (greedy local optimum)이었죠. 다수결 투표는 만장일치의 실수를 바로잡을 수 없습니다. 편향 (bias)을 공유하는 다섯 개의 샘플은 다섯 개의 의견이 아니라, 오차 범위가 있는 하나의 의견일 뿐입니다.

정답이 소수파인 경우. 두 문제에서는 다섯 명의 에이전트 중 정확히 한 명만이 진정한 최적해를 찾아냈고, 4 대 1의 비율로 투표에서 밀렸습니다. 다수결 투표는 단순히 정답을 놓친 것이 아니라, 정답을 적극적으로 버렸습니다. 정답을 보았음에도 불구하고 그것이 희귀하다는 이유로 폐기해 버린 것입니다.

두 번째 부분이 바로 모두가 오해하는 지점입니다. 어떤 검색(search)이나 최적화(optimization) 작업에서든, 최적해(optimum)를 찾는 것은 드문 일이지만 그것을 *확인(checking)*하는 것은 쉽습니다. 이러한 비대칭성(asymmetry)이 핵심이며, 투표(voting)는 이를 인지하지 못합니다. 투표는 '정답이지만 희귀한 답변'을 '오답이지만 희귀한 답변'과 동일하게 취급합니다. 즉, 다수결로 밀어내야 할 노이즈(noise)로 간주하는 것입니다.

대신 무엇을 해야 하는가

만약 정답을 검증할 수 있다면, 투표하지 말고 *검증(verify)*하십시오. N개의 시도를 생성하고, 각각을 확인한 뒤, 통과하는 것 중 가장 좋은 것을 유지하십시오. 이 문제들에서 모든 에이전트(agent)의 답변은 구성적으로 유효한 하한선(constructively valid lower bound)이었습니다(실제로 특정 합계 값을 나타내는 부분집합을 보여주었습니다). 따라서 검증기(verifier)의 역할은 말 그대로 "가장 큰 유효한 주장(largest valid claim)을 유지하는 것"이었습니다. 이는 희귀한 정답을 묻어버리는 대신 포착해 냅니다.

이것은 제가 발명한 영리한 속임수가 아닙니다. 프런티어 연구소(frontier labs)들이 실제로 수행하는 방식입니다. 즉, 많이 생성하고, 검증하고, 가장 좋은 것을 유지하는 것입니다. 이것이 바로 검증 가능한 모든 작업에서 "샘플링 후 투표(sample-and-vote)\

테스트 시간 연산(test-time compute)을 사용하는 모든 시스템에 제가 적용할 핵심 교훈은 다음과 같습니다: 더 많은 샘플을 사용하는 것이 해결책이 아닙니다. 올바른 집계기(aggregator)에 샘플을 사용하는 것이 해결책입니다. 검증기(verifier)는 드물게 나타나는 정답을 최종 배포되는 정답으로 전환합니다. 반면 투표(vote)는 그 정답을 이상치(outlier)로 만들어 삭제해 버립니다.