제약 디코딩의 성능 영향은 제약 유형과 제거되는 출력 공간에 달려 있다
Constrained Decoding: Harmful or Beneficial? Revisiting Its Impact on LLM Performance
무엇인가
이 논문은 LLM이 JSON 같은 정해진 형식을 안정적으로 내도록 토큰을 마스킹하는 제약 디코딩이 추론 성능을 본질적으로 떨어뜨리는지 묻는다. 산업 응용에서는 함수 호출, 도구 사용, 데이터 추출을 위해 구조적 출력이 필요하지만, 기존 연구에서는 JSON 안에서 추론할 때 정확도가 크게 떨어진다는 관찰이 있었다. 저자들은 이 문제를 하나로 뭉뚱그리지 않고 출력 구조를 강제하는 형식 제약, 데이터 타입·길이 등으로 유효하지 않은 답을 마스킹하는 유효성 제약, 추론 경로를 제한하는 추론 제약으로 나눈다.
어떻게 동작하나
방법의 핵심은 제약 디코딩이 허용 토큰만 남기고 확률을 재정규화하는 과정을 수식으로 분석하는 것이다. 입력 x와 고정된 추론 R, 정답 Y*가 있을 때 각 단계에서 허용된 토큰 확률의 합 Z_t를 곱한 값이 제약 하 정답 확률을 결정한다. 정답이 제약 C를 만족하면 기대 정확도는 P(Y*)를 Z_t들의 곱으로 나눈 값이 되어 제약 없는 경우보다 작지 않다. 또한 정답 경로에서 양의 확률을 가진 잘못된 토큰이 실제로 마스킹되면 Z_t의 곱이 1보다 작아져 정확도가 엄밀히 증가한다. 형식 제약은 문법적으로 잘못된 토큰을 제거하고, 유효성 제약은 정답 공간에 대한 의미 정보를 더해 잘못된 답을 더 많이 제거한다. 추론 제약은 좋은 추론 경로를 전부 배제하면 해롭고, 정답 경로만 남기면 완벽해지며, 일부만 남기는 실제 경우에는 효과가 불확정하다.
무엇과 다른가
실험은 Qwen, Gemma, Llama, SmolLM 네 계열의 11개 오픈소스 모델(1.7B~32B)로 구성된다. 10개 모델은 과제 해결에, Qwen3-32B는 NL-to-Format의 추출 모델로 쓰였다. 데이터셋은 GSM8K, Last Letter Concatenation, 경쟁 수학 문제 AIME2026, 이름을 4개에서 8개로 확장한 LastLetter-Extended다. AIME2026과 LastLetter-Extended는 모델 공개 이후에 나오거나 만들어져 데이터 누출 가능성을 줄였다. 디코딩 전략은 reason 필드를 넣는 JSON, 자유 추론 후 포맷팅하는 2단계 NL-to-Format, 트리거 토큰으로 모드를 전환하는 단일 패스 InWriting이며 Litelines와 outlines-core를 사용했다. 평가는 정확도와 함께 파싱률, 형식 이득, 유효성 이득, 추론 이득을 본다.
어떻게 쓰나
결과의 핵심은 동일한 프롬프트와 기대 출력 형식을 맞춘 사과 대 사과 비교에서 제약 디코딩이 일관되게 제약 없는 디코딩과 같거나 더 나았다는 점이다. JSON과 자유 추론 사이의 겉보기 성능 격차는 디코더 수준 마스킹보다 프롬프트와 출력 형식의 비동등성에서 주로 발생했다. 형식 제약과 유효성 제약을 함께 쓰면 제약 없는 경우를 꾸준히 앞섰고, 특히 유효성 제약은 최대 17.4% 향상을 보이며 형식 제약보다 일관된 이득을 냈다. 형식 제약은 모델이 이미 형식을 잘 따를 때 효과가 작고, 유효성 제약은 정답 공간에 대한 정보를 더해 틀린 답을 맞는 답으로 바꿀 수 있기 때문이다. JSON은 같은 자유 추론 단계에서 일반 텍스트와 비슷하거나 더 나았고, 제약 디코딩은 텍스트 생성의 2단계 추출에서도 파싱률을 개선했다. 추론 제약은 “Let’s think step by step”을 강제할 때 GSM8K와 AIME2026에서 대체로 향상됐지만, Qwen3.5-4B의 AIME2026에서는 6.6% 하락해 모델·과제 의존성이 확인됐다.
전제와 한계
비용 측면도 분명히 다룬다. JSON 제약은 생성 시작부터 끝까지 허용 토큰을 계산하고 마스킹해야 하며 제약이 복잡할수록 오버헤드가 커진다. NL-to-Format은 추가 LLM 호출이 필요해 토큰 사용량이 거의 두 배로 늘고, InWriting은 실험에서 15개 미만의 토큰만 추가하면서 최종 출력에만 제약을 적용해 자유 추론의 유연성과 계산 효율의 균형을 노린다.
개발자 관점에서 이 논문은 구조적 출력의 성능 저하를 디코더 자체의 한계로 단정하지 말고, 비교 조건을 동일하게 맞추라고 요구한다. JSON 스키마를 쓸 때는 형식만 강제하는 제약과 타입·길이·허용값 등 유효성 제약을 구분해야 한다. 정답 가능 공간을 과제 구조에서 특정할 수 있다면 유효성 제약이 추출 안정성과 정확도를 함께 높일 수 있다. 반면 추론 제약은 유익한 경로를 사전에 알기 어렵고 대안 경로를 배제할 수 있으므로, 검증된 과제와 모델에서만 제한적으로 적용해야 한다. 파싱률뿐 아니라 토큰 수와 지연 시간도 함께 측정해야 한다.
저자들이 밝힌 한계는 분명하다. 이론적 보장은 같은 프롬프트와 기대 출력 형식, 그리고 정답이 제약을 만족한다는 전제 아래 성립하며, 제약이 정답을 배제하면 성능은 오히려 나빠질 수 있다. 유효성 제약의 이득은 과제 구조로 유효 답 공간을 특정할 수 있을 때 커지고, 추론 제약은 모델과 과제에 따라 결과가 갈리며 유익한 추론 경로를 식별하려면 사실상 오라클 지식이 필요할 수 있다. 또한 더 넓은 도메인과 과제, 다양한 제약 유형으로 검증해야 하고, 구조가 복잡해질수록 계산·토큰 비용이 증가한다는 점도 남은 과제다.