세 에이전트가 모두 같은 답을 내놓았습니다. 다수결이면 신뢰도가 충분히 높다고 볼 수 있나요?

같은 답의 개수보다 답이 어떤 독립적인 근거에서 나왔는지 보겠습니다. 같은 모델이 같은 문서와 프롬프트를 보고 세 번 실행되면 같은 오해를 반복할 수 있습니다. 각 시도가 독립이라는 전제가 없으면 다수결의 통계적 이점을 그대로 적용할 수 없습니다. 모델을 바꾸는 것만으로도 오류 독립성이 자동 보장되지는 않습니다.

다른 역할보다 다른 검증 방법

예를 들어 최신 프로토콜의 필수 기능을 묻는데 세 에이전트가 같은 오래된 튜토리얼을 읽었다면 모두 틀린 답에 동의할 수 있습니다. 한 작업은 규범 명세와 변경 이력을 대조하고, 다른 작업은 실제 SDK 계약이나 재현 테스트를 확인하는 식으로 증거 방법을 나누는 편이 의미 있습니다. '전문가', '비평가'라는 역할명만 다르고 자료와 방법이 같으면 다양성이 제한됩니다.

독립 검토를 원하면 먼저 한 결론을 다른 검토자에게 보여 주어 따라가게 하지 않습니다. 각자 근거를 만든 뒤 통합자가 충돌하는 전제를 비교합니다. 반면 발견된 구체적 결함을 반박 검증하는 작업은 원래 주장을 보여 주는 것이 목적에 맞습니다. 독립 탐색과 적대적 재검증을 같은 패턴으로 취급하지 않겠습니다.

투표 밖의 기준을 둡니다

코드가 컴파일되는지, 실제 요청이 중복 반영되는지처럼 결정적으로 확인할 수 있는 사실은 투표하지 않고 실행·정적 검사로 확인합니다. 문체나 설명 품질은 여러 평가를 참고할 수 있지만, 근거 없는 소수 의견도 다수 의견도 그 자체로 정답은 아닙니다. 중요한 외부 행동은 모델 합의만으로 승인하지 않고 정책과 사용자 권한을 통과해야 합니다.

평가에서는 에이전트별 오류율뿐 아니라 같은 과제에서 함께 실패하는 비율, 추가 검토가 새 결함을 찾는 비율, 잘못된 다수결이 올바른 답을 덮는 비율을 봅니다. 예산이 고정되어 있으면 세 번 생성보다 한 번 생성과 실제 테스트가 더 유리할 수 있습니다. 여러 시도 중 하나만 성공하면 되는 pass@k와 모든 실행이 안정적으로 성공해야 하는 지표도 다릅니다. 합의는 증거를 검토하는 신호이지 근거·테스트·인가를 대체하는 보증이 아니라는 것이 결론입니다.

실행 사례로 확인합니다

두 검토자가 모두 놓친 결함을 제3의 검토자가 찾았다고 해서 그 검토자가 모든 과제에서 더 정확한 것은 아닙니다. 과제별 증거를 비교하고, 새 방법이 추가로 잡은 결함과 새로 만든 오탐을 같이 집계합니다. 독립성을 높이려는 설계도 비용이 있으므로 한쪽은 원문 계약, 다른 쪽은 실제 실패 재현처럼 역할에 맞는 증거를 확보합니다. 결과 통합에서 다수 의견을 먼저 적고 반대 근거를 지우면 검토의 이점이 사라집니다. 최종 답에는 확인된 사실과 남은 불확실성을 표시하고, 해결되지 않은 쟁점이 실행 안전성에 중요하면 작업을 보류합니다. 여러 에이전트의 존재보다 근거가 충돌할 때 멈출 수 있는 절차가 중요합니다.