저는 AI가 생성한 발견 사항들—코드 리뷰 코멘트나 '이것은 버그다'라는 주장 같은 것들—에 대해 검토 패스(review pass)를 수행합니다. 이 과정에서 에이전트들이 두 번째 패스로 각 발견 사항을 저에게 보여지기 전에 반박하려고 시도합니다. 아이디어는 간단합니다. 몇몇 독립적인 회의론자들을 생성하여, 각각 그 발견 사항이 틀렸다고 주장하도록 하고, 다수결 투표를 통과하는 발견 사항만 유지하는 것입니다. 이는 단일하고 자신감 넘치는 에이전트가 지속적으로 만들어내는, 그럴듯하지만 실제로는 잘못된 것들—완벽하게 읽히고, 실제 라인 번호를 인용하며, 어떤 입력에서도 실제로 발생하지 않는 버그를 설명하는 발견 사항—을 포착합니다.

한동안은 효과적이었습니다. 검증이 없던 상태에서 3표 다수결 검증으로 전환하자 엄청난 양의 오탐지(false positives)가 줄어들었습니다. '버그'가 실제로 발생할 수 없는 시나리오이거나, 코드가 하는 일을 잘못 해석한 경우 같은 종류였습니다. 이것은 쉬운 승리였습니다. 그러자 저는 더 나아가려고 했습니다. 5개의 검증기, 7개의 검증기를 사용하며, 투표 수가 많을수록 정밀도가 계속 높아질 것이라고 가정했습니다. 하지만 그렇지 않았습니다. 3개 정도를 넘어서는 지점부터는 동일한 검증기를 추가해도 오탐지율이 거의 움직이지 않았고, 단지 발견 사항당 토큰 비용만 더 많이 들었습니다.

같은 투표가 많아진다고 도움이 되지 않는 이유

검증기들은 어떤 면에서도 독립적이지 않았습니다. 그들은 동일한 프롬프트—'이 주장을 반박하려고 노력하고, 불확실하면 기각으로 기본 설정하라'—를 3번, 5번, 7번 실행한 것일 뿐입니다. 같은 틀(framing), 같은 사각지대(blind spots), 그리고 근본적인 주장이 잘못되었을 때조차도 올바른 어휘(특정 라인 번호, 명명된 함수, 그럴듯하게 들리는 실패 모드)를 사용하기 때문에 엄격해 들리는 발견 사항을 받아들이는 동일한 경향성을 가지고 있습니다. 만약 검증기 #1이 올바른 심볼들을 이름으로 언급하는 발견 사항에 속으면, 검증기 #2부터 #7까지도 정확히 같은 이유로 똑같은 것에 속습니다. 당신은 독립적인 의견을 샘플링하는 것이 아닙니다. 당신은 동일한 편향된 주사위를 다시 굴리고 그 일치를 '신뢰도'라고 부르는 것입니다.

이것이 적대적 검증(adversarial verification)이 실제로 직면하는 실패 모드입니다. 이 방법은 _검증기 프롬프트(verifier prompt)_가 감지할 수 있는 오류만 포착하며, 아무리 많이 요청해도 그 프롬프트가 구조적으로 놓치기 쉬운 것은 눈이 멀어버립니다. 상관관계가 있는 실패에 대한 다수결 투표는 평균화되지 않습니다. 단지 더 명백한 권위로 공유된 사각지대를 확인시켜 줄 뿐입니다. 하나의 반박자 형태의 프롬프트를 속이는 발견은 모든 반박자 형태의 프롬프트를 속일 가능성이 높습니다.

실제로 수치를 움직인 것

개수(count)가 아니라 관점의 다양성(Diversity of vantage point)입니다. N개의 동일한 '이것을 반박해 보시오' 에이전트 대신, 저는 검증을 진정으로 다른 몇 개의 렌즈에 걸쳐 분할했습니다. 각 렌즈는 같은 발견 사항을 다른 각도에서 평가하도록 지시받았습니다:

Lens: correctness (정확성) — 스타일은 무시하고 실제 코드 경로를 고려했을 때 이 주장이 성립하는가?
Lens: reproducibility (재현 가능성) — 설명된 실패를 유발할 수 있는 구체적인 입력을 구성할 수 있는가? 만약 구성할 수 없다면, 명시적으로 그렇게 말하라.
...

세 개의 검증기, 세 가지 다른 실패 모드를 포착하기 위함이며, 같은 실패 모드가 빠져나갈 세 번의 기회가 아닙니다. '이것을 구체적으로 재현하는가?'를 통과한 발견은 '이것이 실제로 정확성 문제인가?'를 통과한 발견과는 다른 종류의 오탐지(false positive)를 포착합니다. 구성 가능한 재현 사례가 없는 그럴싸하게 들리는 버그는, 심지어 정확성 렌즈(원래 탐지기가 했던 것처럼 코드를 고립적으로 읽는 방식)가 이를 무시했을지라도, 재현 가능성 렌즈에서 죽습니다.

기계적인 변화는 작습니다 — 에이전트 호출 횟수도 같고, 투표 구조도 같습니다 — 하지만 틀을 잡는 방식이 다릅니다: 저는 '내가 기본적으로 같은 질문을 몇 번이나 할 수 있을까?'라고 묻는 대신, '이 주장이 실패할 수 있는 구조적으로 다른 방법은 몇 가지이며, 각각에 검증기(verifier)를 할당했는가?'라고 묻기 시작했습니다. 특히 코드 리뷰 발견 사항의 경우, 정확성(correctness)/재현 가능성(reproducibility)/실제 영향도(actual-impact)만으로도 동일한 프롬프트 투표가 놓치고 있던 대부분을 포착할 수 있었으며, 더 큰 검증기군(verifier fleet)은 필요하지 않았습니다.

일반화 가능한 부분

이것은 코드 리뷰에 국한된 이야기가 아닙니다. '첫 번째 패스의 실수를 잡기 위한 두 번째 패스'를 추가하는 모든 파이프라인은, 만약 두 번째 패스가 자신과 구조적으로 동일하게 반복된다면 같은 한계에 부딪힙니다. 세 명의 동일한 심사위원은 세 가지 의견을 내는 것이 아니라, 추가적인 확신을 가진 하나의 심사위원일 뿐입니다. 검증 단계가 정체되는 것(더 많은 투표를 던져도 정밀도가 오르지 않는 경우)을 목격한다면, 해결책은 보통 더 많은 투표가 아닙니다. 그것은 현재의 검증기 프롬프트로는 구조적으로 볼 수 없는 근본적인 주장이 틀릴 수 있는 구체적인 방법이 무엇인지 묻고, 정확히 그것만을 찾는 것이 임무인 검증기를 작성한 다음, 비로소 실제로 더 많은 투표자가 필요한지 아니면 단지 다른 종류의 투표자가 필요했는지 결정하는 것입니다.