LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개

Who Should Read

LLM을 이용해 문서, 이미지, 음성에서 구조화된 데이터를 추출하는 파이프라인을 개발하거나 운영 중인 백엔드·ML 엔지니어. 특히 JSON 출력의 정확성이 다운스트림 시스템에 영향을 주는 프로덕션 환경을 다루는 개발자에게 유용하다.

Core Mechanics

• 기존 벤치마크들(JSONSchemaBench, StructEval 등)은 '응답이 파싱 가능한 JSON인가', '스키마를 통과하는가'만 확인하는데, 이 기준만으로는 값이 틀린 완벽한 JSON도 100점을 받을 수 있어 실제 프로덕션 신뢰성을 측정하지 못한다.
• SOB는 텍스트(HotpotQA 5,000건), 이미지(olmOCR-bench 209건), 오디오(AMI Meeting Corpus 115건) 세 가지 모달리티에서 동일한 스코어링 파이프라인으로 평가해서, OCR·스크린샷·회의 녹취 등 실제 입력 환경을 반영한다.
• 이미지와 오디오 레코드는 텍스트로 정규화한 뒤 평가하므로, 비전·ASR(음성 인식) 능력이 아닌 순수한 구조화 출력 능력만 격리해서 측정할 수 있다.
• 7가지 지표를 따로 보고한다: Value Accuracy(정확한 값 일치), JSON Pass Rate(파싱 가능 여부), Type Safety(타입 일치), Structure Coverage(구조 포함 여부), Path Recall(필수 키 포함 여부), Faithfulness(소스 기반 여부), Perfect Response(전체 레코드 완벽 일치). 프로덕션에서 가장 중요한 건 Value Accuracy다.
• 점수 인플레이션을 막는 두 가지 게이트가 있다. JSON 파싱 자체가 실패하면 하위 시맨틱 지표를 전부 0으로 처리하고, Value Accuracy는 모델이 실제로 반환한 필드에만 점수를 주되 누락된 경로는 오답으로 간주한다.
• 스키마 난이도를 easy(1.0), medium(2.0), hard(3.0)으로 태깅해서 최종 리더보드에 가중치를 적용하므로, 복잡한 중첩 구조를 잘 처리하는 모델이 더 높은 점수를 받는다.
• 모든 평가는 temperature 0.0, max output 2048 토큰, 추론/thinking 기능 비활성화 조건에서 실행해서 순수 구조화 출력·추출 능력만 반영한다.
• 리더보드 상위권 결과: 1위 GPT-5.4(Overall 0.870, Value Acc 0.798), 2위 GLM-4.7(0.861, 0.804), 3위 Qwen3.5-35B(0.861, 0.801), 4위 Gemini-2.5-Flash(0.860, 0.796), 5위 Qwen3-235B(0.857, 0.786). 구조적 지표(JSON Pass, Path Recall 등)는 대부분 모델에서 천장에 가깝고, Value Accuracy와 Perfect Response에서 차이가 갈린다.

Evidence

• '입력 파싱'과 'JSON 포맷팅'을 한 번의 LLM 호출로 동시에 시키는 것은 취약하다는 경험담이 공유됐다. 먼저 작업을 수행한 뒤 별도 LLM 호출로 JSON으로 감싸는 2단계 방식을 쓰자 품질이 크게 올랐다는 경험이 있으며, 특히 JSON 안에 HTML/JS/Python 코드 스니펫을 담아야 하는 에이전틱 상태 머신에서 이 차이가 두드러졌다고 한다.
• Claude Opus 4.6/4.7, Gemini 2.5 Pro처럼 최신 프런티어 모델이 빠져 있다는 지적이 여러 댓글에서 나왔다. 선정 기준(예: 비용, 시기)을 명시하지 않은 채 'Top 5'를 제시하면 혼란을 줄 수 있다는 비판이다.
• Qwen3.5-35B가 GPT-5.4, GLM-4.7과 거의 동등한 점수를 내면서도 훨씬 저렴하다는 점에서, JSON 추출 특화 작업에서는 비용 대비 최고의 모델일 수 있다는 의견이 주목받았다.
• 이 벤치마크가 기존 일반 환각(hallucination) 벤치마크와 실질적으로 다른 가치를 제공하는지 의문을 제기하는 댓글도 있었다. '결정론적 출력이 필요하면 LLM을 쓰지 말라'는 극단적인 반론도 나왔으나, 실무에서는 LLM 없이 비정형 데이터를 구조화하기 어려운 경우가 많아 이 벤치마크의 실용성이 있다는 반박도 있었다.
• structured decoding(모델 출력 토큰을 스키마에 맞게 강제하는 기법)을 왜 사용하지 않았냐는 질문이 나왔는데, 이는 실제 API 환경에서의 능력을 측정하려는 벤치마크 설계 의도와 관련된 논점이다.

How to Apply

• 인보이스, 의료 기록, 회의 녹취 등에서 JSON을 추출하는 파이프라인을 구축 중이라면, SOB 리더보드의 Value Accuracy와 Perfect Response 컬럼을 기준으로 모델을 선택하라. 전체 Overall 점수보다 이 두 지표가 프로덕션 신뢰성을 더 직접적으로 반영한다.
• 비용이 중요한 상황에서 JSON 추출 작업을 대량으로 처리해야 한다면, Qwen3.5-35B를 GPT-5.4의 대안으로 고려할 만하다. 리더보드 기준으로 거의 동등한 정확도를 훨씬 낮은 비용으로 제공할 가능성이 있다.
• LLM 한 번의 호출로 입력 파싱과 JSON 출력을 동시에 처리하는 구조에서 오류가 잦다면, 먼저 자유 텍스트로 작업을 완료한 뒤 별도의 LLM 호출로 결과를 JSON으로 변환하는 2단계 접근 방식을 실험해 보라.
• 자체 LLM 파이프라인의 구조화 출력 품질을 측정하고 싶다면, SOB의 7가지 지표 체계(JSON Pass → Structure Coverage → Path Recall → Type Safety → Value Accuracy → Faithfulness → Perfect Response)를 내부 평가 프레임워크의 계층적 기준으로 차용할 수 있다.

Terminology

관련 논문

• MTG Bench: LLM들이 Magic: The Gathering을 얼마나 잘 플레이하는지 테스트

  카드 게임 MTG의 규칙 준수 능력으로 LLM의 복잡한 규칙 추론 능력을 측정하는 독창적인 벤치마크로, gpt-5.5가 95.4점으로 1위를 차지했다.

• ALIGNBEAM: Cross-Vocabulary Logit Mixing을 통한 Inference-Time Safety Alignment 전이

  도메인 파인튜닝으로 망가진 LLM 안전성을, 재학습 없이 추론 시점에 작은 안전 모델에서 빌려와 복구하는 방법.

• iPad가 Tailscale에 연결되어 있었다: WebRTC 디버깅 이야기

  WebRTC 데이터 채널에서 iPad만 응답을 못 받는 희귀 버그를 추적한 결과, webrtc-rs의 하드코딩된 MTU 상수와 Tailscale의 IPv6 Fragment 패킷 드롭이 동시에 작용한 복합 버그였다는 2주간의 디버깅 실화.

• LLM이 고전적인 Hyperparameter 최적화 알고리즘을 이길 수 있을까?

  LLM 기반 하이퍼파라미터 최적화 에이전트와 CMA-ES, TPE 같은 고전 알고리즘을 직접 비교한 연구로, LLM 단독으로는 고전 방법을 이기지 못하지만 두 방법을 합친 하이브리드 'Centaur'가 최고 성능을 낸다는 결론이 나왔다.

• 눈이 보는 것, LLM이 놓치는 것: Human Perception을 이용한 Adversarial Text Attack

  Bold, 하이라이트, 공백 배치 같은 타이포그래피 트릭으로 GPT-4o, Llama Guard 등 10개 콘텐츠 모더레이션 시스템을 99% 이상 우회할 수 있다.

• Claude가 rsync의 버그를 증가시켰는가? 데이터 분석

  rsync 프로젝트에 Claude AI가 도입된 이후 버그가 늘었다는 소셜 미디어 주장을 실제 데이터와 통계 분석으로 검증한 글로, 결론적으로 Claude 도입 후 릴리즈가 역사적 분포에서 유독 버그가 많다는 통계적 근거는 없었다.

Related Resources

• SOB 원문 블로그 포스트
• BAML - BoundaryML 구조화 출력 라이브러리
• JSONSchemaBench
• AMI Meeting Corpus