LLM과 JSON 출력

요새는 agentic LLM이니 tool calling이니 이런 것들이 프론티어이지만 LLM 초기에는 JSON(또는 모종의 구조화된 출력)을 내뱉게 하는 것도 힘들었다.

• 규칙성 없는 순수 next-token 샘플링이었음
  • 잘못된 JSON이 나와도 기계적인 검증 절차 없이 그냥 출력됨
• 오타 하나로 전체가 파싱 오류가 나는 일이 빈번했음
• "질문 → JSON 답" 데이터가 많이 없었음
• Sure! Here's your JSON: 같은 서두를 붙이는 경우가 많아, 이를 제거하기도 어려웠음
• 출력 JSON이 길어질수록 instruction following 능력이 저하됐었음
• BPE 토큰 경계가 JSON 문법 단위와 어긋났음
  • 예를 들어 {", key, ":와 같은 식으로 토큰이 쪼개져, 모델이 JSON 구조를 학습하지 못함
  • 이 어긋남 자체는 지금도 존재하며, 현대 엔진이 토큰-문법 정렬을 별도로 처리하는 이유임

이를 우회하기 위한 여러 편법들이 존재했었다.

• 각 key 별로 value를 단답형으로 질문하게 해서 코드 레벨에서 JSON을 엮어냄
• 우선 답변을 하게 한 뒤, JSON을 regex로 감지해내거나, 최대한 살릴 수 있는 부분을 살려내서 사용함
• LLM이 답변하기 더 쉬운 YAML이나 TOML 형태로 답변하게 한 뒤 추출해서 변환함
• 잘 나올 때까지 통째로 재생성... (output-level rejection)

이를 근본적으로 해결하려는 연구는 두 갈래로 진행됐다.

• 모델 레벨(가중치). 스키마 예제와 tool calling 데이터를 포스트트레이닝(행동 교정)에 넣어 JSON을 더 잘 출력하게 만드는 것.
• 디코딩 레벨(인퍼런스 엔진). 애초에 잘못된 토큰이 나올 수 없게 샘플링을 막는 것.

디코딩 레벨의 시조는 사실 LLM 붐 이전인 PICARD(2021)로, SQL 생성용이었다. 토큰을 하나 뽑은 후 파서로 검사하고, 불합격이면 기각하고 다시 뽑는 token-level rejection 방식이다.

이후 LLM과 구조화된 출력의 필요가 폭증하자, 2022–2023년에 도구들이 쏟아졌다. 예를 들어 Jsonformer는 중괄호, 키, 따옴표 같은 구조 토큰은 코드가 직접 삽입하고 LLM은 value 빈칸만 생성하게 했다 (구조 부분은 아예 생성을 안 시킴). 그러나 결과적으로 다음 방식으로 정리되었다.

Constrained Decoding

문법을 유한 상태 기계로 보고, 각 상태에서 허용되는 토큰 집합 테이블을 생성 시작 전에 미리 컴파일해 둔다. 런타임에는 매 스텝 토큰을 전수 검사하는 대신 테이블 조회만 한다.

• 모델의 포워드 패스
  • 트랜스포머가 어텐션과 MLP를 계산해 로짓(다음 토큰 후보들 각각에 대한 점수)을 출력한다.
  • GPU에서 실행되며, constrained decoding이 전혀 건들지 않는다.
• 인퍼런스 엔진의 로짓 처리
  • 포워드 패스와 샘플링 사이에서, 현재 JSON이 어느 상태까지 출력됐는지 추적하고, 사전 컴파일된 테이블에서 해당 상태의 마스크를 조회해 JSON을 '고장낼' 후보들의 로짓에 −∞를 가산한다.
  • 상태 추적과 마스크 산출은 CPU의 문법 엔진이 담당하고, 마스크는 GPU 위의 로짓 텐서에 적용된다.
• 인퍼런스 엔진의 샘플링
  • 살아남은 로짓을 softmax 처리하여 다음 토큰을 최종 선정한다.

즉 토큰을 골라놓고 적법한지 검사하는 게 아니라, 적법한 후보만 남겨놓고 고르는 것. 모델은 자신이 제약받고 있다는 사실조차 모른다.

상용 API는 여기에 모델 레벨을 결합했다. OpenAI 자료에 따르면 gpt-4o-2024-08-06을 포스트트레이닝에서 복잡한 스키마 예제로 훈련해 스키마 준수율을 93%까지 높였고, 남은 갭은 로짓 처리 레이어(constrained decoding)로 100%를 보장한다. 즉

• 가중치가 품질을
• 마스크가 보증을

담당하는 이중 장치이다.