작은 LLM의 추론을 코드 검증 단계로 나눈 실험

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

이 프로젝트는 Qwen3-4B-Instruct와 LoRA를 사용해 작은 모델의 한 번짜리 추론을 여러 단계의 호출로 나누고, 각 호출 사이에 코드 기반 사실 검증과 산술 계산을 배치했습니다. 동일 가중치 비교에서 인증 기준 통과율은 0/16에서 6/16으로 높아졌고, 외부 holdout 문제에서도 harness가 5개로 one-pass 1개와 Qwen3-4B-Thinking 2개를 앞섰으며 토큰 비용은 최대 1,360으로 측정됐습니다. 그러나 자체 생성 문제에서 얻은 strict-clean 성능은 holdout에서 양쪽 모두 0/16으로 재현되지 않았고, 앞 단계의 제약을 뒤 선택 단계가 위반하는 cross-stage contradiction도 남았습니다. 따라서 코드로 사실과 계산을 고정하는 효과는 확인됐지만, 단계 간 논리 일관성과 일반화는 아직 해결되지 않은 과제입니다.

주요 논점

01찬성소수

동일한 Qwen3-4B-Instruct와 LoRA 가중치에서도 모델 호출을 작은 단계로 나누고 코드 검사를 삽입하면 one-pass보다 인증 기준 통과율과 외부 holdout 성적이 높아졌습니다. 사실 추출, 산술 계산, 출력 조립을 코드로 분리한 점이 개선의 핵심으로 제시됐습니다.

02반대소수

자체 생성 문제에서 얻은 0%에서 88%까지의 strict-clean 상승은 외부 holdout에서 재현되지 않았고, 두 평가군 모두 0/16을 기록했습니다. 또한 단계별 검증을 통과한 정보가 최종 선택 단계에서 모순되는 문제가 계속 남았습니다.

03중립분열

하네스는 작은 모델의 비용과 출력 통제를 개선할 가능성을 보였지만, 현재 결과만으로 규모를 구조가 대체한다고 결론 내리기는 어렵습니다. cross-stage contradiction이 모델 가중치의 한계인지 추가적인 일관성 검사로 줄일 수 있는지는 아직 확인되지 않았습니다.

합의점 vs 논쟁점

합의점

사실 검증과 산술 계산처럼 원문 일치 여부와 수치 처리가 명확한 작업은 코드로 분리할수록 출력 통제가 쉬워집니다. 작성자의 실험에서는 추출된 숫자를 원문과 대조하고 계산 결과를 anchor block에 기록하는 방식이 사용됐습니다. 반면 단계 사이의 선택 일관성은 같은 방식만으로 해결되지 않았습니다.
자체 생성 문제에서 얻은 성능은 외부 holdout 문제로 반드시 확인해야 합니다. 이 글에서는 자체 문제의 strict-criterion 결과가 holdout에서 0/16으로 재현되지 않았습니다. 작성자는 이 실패를 README에 승리 결과와 같은 비중으로 기록했습니다.

논쟁점

4B 모델에서 cross-stage contradiction이 가중치 자체의 특성인지, 아니면 더 강한 단계 간 일관성 검사로 줄일 수 있는지는 결론이 나지 않았습니다. Qwen3-4B-Thinking도 이 오류를 부분적으로만 피했습니다. 7B에서 14B 사이의 규모 증가가 모순을 없애는지 줄이기만 하는지는 추가 실험이 필요합니다.
harness가 Qwen3-4B-Thinking보다 낮은 토큰 비용으로 holdout 점수를 앞섰지만, 평가 문제가 16개뿐이고 strict-criterion 결과는 양쪽 모두 0/16이었습니다. 따라서 비용 대비 성능 우위와 일반화 실패가 동시에 존재합니다. 이 결과가 특정 문제 형식에 국한되는지도 더 넓은 문제군에서 확인해야 합니다.

실용적 조언

작은 모델 파이프라인에서는 모델이 숫자와 사실을 직접 계산하거나 기억하게 두지 말고, 추출 단계와 코드 검증 단계를 분리하는 편이 안전합니다. 숫자는 원문에 verbatim으로 존재하는지 검사하고, 산술 결과는 코드가 계산해 anchor block에 기록하도록 구성할 수 있습니다. 마지막 출력에는 이미 infeasible로 판정한 선택지를 다시 고르지 못하게 하는 guard와 숫자 형식 검사를 추가해야 합니다.
자체 생성 문제의 성능을 제품 품질로 해석하기 전에 하네스를 고정하고 별도 작성자가 만든 holdout 문제를 투입해야 합니다. 평가 프롬프트와 판정값을 고정하면 반복 측정에서 judge의 변동을 줄일 수 있습니다. 단, 단계별 결과가 서로 모순되지 않는지 확인하는 검사는 사실 일치 검사와 별도로 설계해야 합니다.

섹션별 상세

작성자는 작은 LLM에 한 번의 긴 추론을 맡기는 대신, 사실 추출·검증·산술 계산·제약 식별·선택·신뢰도 추정을 각각 작은 호출로 나누는 verification harness를 만들었습니다. 각 모델 호출 사이에서 코드가 숫자의 원문 일치 여부와 최소 60% 단어 포함률을 검사하고, 검증되지 않은 문장은 제거합니다. 마지막 조립도 생성 모델이 아니라 템플릿과 숫자 검사, 이미 불가능하다고 판정한 선택지를 다시 고르지 못하게 하는 guard로 처리해 출력 오류를 줄이는 구조입니다.

작성자가 한 달 동안 같은 문제를 사용해 측정한 결과, 질문 부분만 줄이고 문제 자체는 유지했을 때 strict-clean 결과가 0%에서 88%까지 단조롭게 상승했습니다. 같은 가중치를 사용한 one-pass와 harness 비교에서는 인증 기준을 통과한 결과가 0/16에서 6/16으로 늘었고, paired p≈0.008이 기록됐습니다. 이는 모델의 순수한 규모보다 호출별 입력 크기와 코드 기반 제약 처리가 작은 모델의 검증 가능한 출력에 영향을 줄 수 있음을 시사합니다.

외부 제3자가 작성한 16개 holdout 문제에서는 harness가 5개, Qwen3-4B-Thinking이 2개, one-pass가 1개를 기록했으며, 토큰 비용도 harness의 5개 호출 합계가 최대 1,360토큰으로 Qwen3-4B-Thinking의 답변당 측정값 1,525토큰보다 낮았습니다. 그러나 작성자가 직접 생성한 문제에서 성립한 strict-criterion 성능은 holdout에서 양쪽 모두 0/16으로 무너졌습니다. 하네스를 holdout 문제가 존재하기 전에 git commit으로 고정하고 외부 audit 결과 8건을 모두 공개한 점은 이 실패를 사후 조정이 아닌 재현 가능한 한계로 다루게 합니다.

가장 오래 남은 오류는 사실 검증 실패가 아니라 cross-stage contradiction입니다. 모델이 앞 단계에서 binding constraint를 정확히 찾아도 뒤 단계의 선택에서 그 제약을 어길 수 있으며, guard를 추가하면 모순이 다음 표면으로 이동했습니다. 작성자는 4B 규모에서 이 현상이 가중치의 특성일 가능성을 제기하고, reasoning-trained sibling도 이를 일부만 줄였다고 기록했지만, 7B에서 14B로 규모를 키우면 사라지는지는 공개 질문으로 남겼습니다.

용어 해설

검증 하네스(Verification Harness): — 모델 호출 사이에 코드를 삽입해 추출된 사실을 원문과 대조하고, 산술 계산·출력 제약·금지 선택을 자동 검사하는 실행 구조입니다. 생성 결과를 그대로 신뢰하지 않는 것이 핵심입니다.
앵커 블록(Anchor Block): — 검증된 사실을 바탕으로 코드가 계산 결과와 핵심 제약을 고정해 두는 중간 데이터 블록입니다. 이후 추론 단계는 이 블록만 받아 사실과 계산 결과가 바뀌지 않게 합니다.
단계 간 모순(Cross-Stage Contradiction): — 앞선 단계에서 올바르게 식별한 제약이나 사실을 뒤의 선택 단계가 위반하는 오류입니다. 각 단계의 사실 검증만으로는 단계 사이의 논리적 일관성까지 보장하기 어렵습니다.
LLM 평가자(LLM Judge): — 고정된 프롬프트를 사용해 모델 출력의 정합성이나 기준 충족 여부를 판정하는 별도 언어 모델입니다. 이 글에서는 캐시된 판정값으로 반복 평가의 변동을 줄였습니다.
홀드아웃 문제(Holdout Problems): — 하네스와 문제 생성 과정에 사용하지 않고 평가 단계에서 처음 투입하는 검증용 문제 세트입니다. 자기 생성 문제에만 맞춘 성능인지 외부 문제에서도 유지되는지 확인하는 데 쓰입니다.

언급된 리소스

GitHubNikhiljangra07/cube-program