Constrained Decoding

제약 디코딩은 언어 모델이 각 단계에서 생성할 수 있는 토큰을 제한하여 완성된 출력이 필수 형식과 일치하도록 보장하는 텍스트 생성 기법입니다. 필수 형식은 고정된 레이블 집합, 정규 표현식, 문법 또는 JSON Schema 중 하나일 수 있습니다. 모델은 여전히 어휘에 있는 모든 토큰의 점수를 계산합니다. 토큰을 선택하기 전에 디코더는 형식을 깨뜨릴 수 있는 모든 선택지를 제거합니다. API 백엔드, AI 에이전트, 데이터 추출 파이프라인처럼 모델 출력을 파싱하는 애플리케이션은 모든 응답이 첫 시도에 파싱되도록 이 기법을 사용합니다.

유효하지 않은 토큰 마스킹#

대규모 언어 모델은 토큰을 한 번에 하나씩 생성합니다. 각 단계에서 어휘의 모든 토큰에 대한 점수 또는 로짓을 출력하고, 소프트맥스가 이 점수를 확률로 변환합니다. 제약 디코딩은 샘플링 전에 연산을 하나 추가합니다. 유효한 출력을 만들 수 없는 토큰의 로짓을 음의 무한대로 설정해 확률을 0으로 만들고, 남은 확률을 유효한 토큰에 대해 재정규화합니다.

import torch

# Raw next-token scores from a model over a toy vocabulary
vocab = ["approved", "rejected", "review", "maybe", "{", "}"]
logits = torch.tensor([1.2, 0.4, 0.9, 2.5, 0.1, 0.3])

# The schema allows only the three status labels at this position
allowed = torch.tensor([True, True, True, False, False, False])
masked_logits = logits.masked_fill(~allowed, float("-inf"))

# Softmax renormalizes probability over the valid tokens only
for name, raw, masked in zip(vocab, logits.softmax(-1), masked_logits.softmax(-1)):
    print(f"{name:>9}: {raw:.2f} -> {masked:.2f}")

제약이 없는 모델은 확률의 56%를 "maybe"에 할당합니다. 마스크를 적용하면 "maybe"의 확률은 0이 되고, 허용된 라벨 3개가 원래 점수에 비례해 확률을 나눠 갖습니다. 이에 따라 "approved"의 확률은 15%에서 46%로 높아집니다.

프로덕션 추론 엔진은 생성이 진행되는 동안 제약 상태를 추적합니다. 고정 선택지 목록이나 정규 표현식은 유한 상태 머신으로 컴파일됩니다. JSON 및 기타 중첩 형식에는 스택이 있는 문법이 필요합니다. 여는 중괄호와 짝이 맞아야 닫는 중괄호가 유효하기 때문입니다. 각 토큰을 생성한 후 디코더는 상태를 갱신하고 허용되는 집합을 다시 계산합니다. 토큰화는 길이가 서로 다른 서브워드 조각을 생성하므로 "},과 같은 단일 토큰이 여러 문법 단계를 한꺼번에 포함할 수 있습니다. 따라서 라이브러리는 각 상태에서 유효한 어휘 항목을 미리 계산하여 어휘가 100,000개가 넘더라도 토큰당 비용을 낮게 유지합니다. Brandon Willard와 Rémi Louf는 2023년 대규모 언어 모델을 위한 효율적인 가이드 생성 논문에서 정규 표현식과 문맥 자유 문법을 위한 이 인덱싱 방식을 설명했습니다. 이 논문은 Outlines 라이브러리의 기반이 되었습니다.

제약 조건 선택#

적합한 제약 조건은 애플리케이션이 실제로 사용하는 출력 형식에 따라 달라집니다. 선택지 목록은 답변이 몇 개의 문자열 중 하나여야 하는 분류 및 라우팅에 적합합니다. 정규 표현식은 날짜, ID, 전화번호와 같은 짧은 구조화 값을 처리합니다. 문맥 자유 문법은 SQL, 코드, 도메인별 언어를 설명하며, llama.cpp의 GBNF 문법 형식이 널리 사용되는 예입니다. 필드 이름이 지정된 레코드에는 JSON Schema가 필수 키, 유형, 열거형, 중첩 구조를 지정합니다. OpenAI Structured Outputs와 같은 호스팅 API는 스키마를 받아 생성 중에 이를 적용하며, 대개 전체 JSON Schema 사양 중 문서화된 하위 집합을 지원합니다.

제약 디코딩은 다음과 같은 유사 기법과 혼동되는 경우가 많습니다.

• 구조화된 출력: 생성 시 제약 디코딩을 적용하거나 출력 검증에 실패한 뒤 재시도하여 달성하는, 기계가 읽을 수 있는 응답이라는 더 넓은 목표입니다.
• JSON 모드: 출력이 어떤 형태로든 구문상 유효한 JSON이 되도록 제한하므로 키, 유형, 값은 여전히 확인해야 합니다.
• 프롬프트 엔지니어링: 지침에 형식을 요청하면 모델은 대부분 이를 따릅니다. 스키마 제약 요청에서도 일반적으로 프롬프트에 필드를 설명하므로 모델이 각 필드의 의미를 알 수 있습니다.
• 함수 호출: 호출 코드가 정확한 필드 이름을 요구하므로 도구 이름과 인수는 스키마 제약의 가장 일반적인 대상입니다.

실제 적용 시의 절충점#

형식이 보장된다고 해서 내용까지 보장되는 것은 아닙니다. 스키마는 {"total": 1290.00}이 숫자가 되도록 강제할 수 있지만 그 숫자가 틀릴 수 있으며, 제약된 모델도 유효한 필드 안에서 자연스럽게 환각을 일으킬 수 있습니다. 따라서 애플리케이션은 생성 후에도 비즈니스 규칙을 검증해야 합니다.

제약 조건이 모델이 자연스럽게 작성할 문장에서 벗어나도록 유도하면 답변 품질도 낮아질 수 있습니다. 최종 답변을 첫 번째 필드로 요구하는 스키마는 중간 추론을 위한 여지를 남기지 않으므로, 스키마에서는 추론이나 메모를 위한 자유 형식 텍스트 필드를 답변 필드 앞에 두는 경우가 많습니다. 출력 길이에도 주의해야 합니다. 생성이 객체 중간에서 토큰 한도에 도달하면 제약 조건과 관계없이 결과가 유효하지 않으므로, 구조화된 요청에서는 전체 구조를 담을 여유를 두고 최대 길이를 설정합니다. 매우 크거나 재귀가 깊은 스키마는 컴파일 시간이 길어지므로 요청마다 새 스키마를 만드는 시스템에서는 이를 고려해야 합니다.

멀티모달 모델이 이미지에 관한 필드를 반환해야 하는 경우에도 비전 애플리케이션은 같은 메커니즘을 사용합니다. Ultralytics LLM 인터페이스는 요청 인수를 변경 없이 OpenAI 호환 API로 전달하므로, 이미지 요청과 함께 전달하는 JSON Schema는 비전-언어 모델의 답변을 hazard 및 severity과 같은 필드로 제한하고, 같은 프레임에서 얻은 YOLO26 탐지 결과와 결합할 수 있도록 합니다.