추론 시간과 후보 에이전트 수를 늘리면 어려운 작업을 더 잘 해결하나요? 테스트 시점 계산량 확대를 어떻게 평가하나요?

실행 시 더 오래 추론하거나 여러 후보를 만들고 검증하는 방식은 어려운 과제의 성공 가능성을 높일 수 있지만 항상 개선되지는 않습니다. 추가 계산이 무엇을 탐색하고 어떤 검증으로 좋은 결과를 고르는지 명확해야 합니다. 모델이 같은 잘못된 전제를 길게 반복하면 비용만 늘고, 외부 도구 실행까지 반복하면 중복 효과와 안전 위험도 커질 수 있습니다.

계산을 어디에 쓸지 선택합니다

한 모델의 추론 예산을 늘리는 방법, 독립 후보를 여러 개 만드는 방법, 도구로 사실을 확인하는 방법, 평가·수정 루프는 서로 다른 선택입니다. 코드 문제라면 후보를 여러 개 만든 뒤 실제 테스트로 선택할 수 있지만 문서 사실 문제는 더 오래 생각하는 것보다 최신 원문을 읽는 것이 필요할 수 있습니다. 검증기가 약하면 잘못된 후보를 자신 있게 고르는 비용이 추가됩니다.

후보 생성은 가능한 한 부수 효과가 없는 격리 환경에서 하고, 실제 외부 변경은 검증된 한 결과를 승인된 경로로 실행합니다. 여러 후보가 각각 결제를 시도하게 만드는 것은 탐색이 아니라 여러 번의 실행입니다. 병렬 탐색은 지연을 줄일 수 있어도 총 계산량과 비용은 증가하므로 공통 예산과 취소 규칙을 둡니다. 같은 모델·자료로 만든 후보의 오류 상관도 확인합니다.

한계 효용을 측정합니다

예산을 단계적으로 늘리며 성공률·안전 위반·지연·성공당 비용이 어떻게 변하는지 곡선을 봅니다. 쉬운 과제는 추가 계산이 거의 필요 없고 어려운 과제 일부에서만 이득이 클 수 있으므로 유형별로 나눕니다. 추론 예산이라는 설정값이 제공자마다 같은 실제 토큰·시간을 뜻하지 않을 수 있어 관측 사용량을 함께 기록합니다.

pass@k가 올라갔다고 단일 실행의 신뢰도가 같아진 것은 아닙니다. 후보 선택 비용과 실패 시도, 검증기의 오류를 포함해 운영에서 사용자가 받는 결과를 평가합니다. 개선이 멈추거나 같은 상태가 반복되면 중단하고 새 근거·문제 분해·사람 확인을 선택합니다. 최근의 계산량 확대 논의는 모델 능력과 도구·harness 설계가 함께 영향을 준다는 맥락으로 다루겠습니다. 계산을 많이 쓰는 것 자체가 품질의 증거가 아니라, 추가 자원이 실제 어떤 불확실성을 줄였는지가 판단 기준입니다.

실행 사례로 확인합니다

검색형 작업에서 후보 열 개가 모두 같은 출처를 요약했다면 계산량은 늘어도 정보 다양성은 거의 늘지 않을 수 있습니다. 반대로 작은 검증 스크립트 하나가 모든 후보의 잘못된 수치를 잡을 수 있습니다. 예산 배분을 모델 호출 수만으로 정하지 않고 어떤 검증이 결정적인지 봅니다. 코드 후보가 테스트를 통과해도 테스트가 요구를 충분히 다루지 않으면 최고 점수 선택이 틀릴 수 있으므로 검증기의 한계도 함께 평가합니다. 추가 계산량의 효과를 보고할 때는 후보 생성·선택·재실행을 모두 포함하고, 결과를 고르는 데 사람이 들인 시간도 숨기지 않습니다. 계산 확대와 검증 강화는 함께 설계해야 합니다.