Structured Output Benchmark(SOB): JSON은 맞는데 값은 틀린다

Show HN: A new benchmark for testing LLMs for deterministic outputs

Apr 29, 2026•khurdula•View Original

TL;DR Highlight

28개 LLM 테스트 결과 JSON 통과율은 97%+인데 값 정확도는 15~30%p 낮았다

Who Should Read

LLM으로 송장·회의록·PDF에서 JSON을 뽑아 DB에 넣는 파이프라인을 운영하며 모델 선택에 고민인 백엔드 개발자

Core Mechanics

JSON 파싱 통과는 변별력이 없다
- 대부분의 최신 모델이 통합 리더보드에서 JSON Pass 95%+를 기록했다.
- Value Accuracy(필드 값이 정답과 정확히 일치하는 비율)는 JSON Pass보다 15~30%p 낮았다.
구조 지표는 99%인데 값은 틀린다
- Path Recall, Structure Coverage, Type Safety가 ~99%여도 leaf 값(최하위 필드 값)의 20~30%가 틀릴 수 있다.
- 레코드 전체가 완전히 맞는 Perfect Response는 최상위 모델도 절반 안팎이다.
1위는 비싼데 격차는 작다
- Value Accuracy 1위는 Gemini-3.1-Pro 82.0%, 이어서 GLM-5.1 80.6%, GLM-4.7 80.4%, Qwen3.5-35B 80.1%다.
- Qwen3.5-35B, GLM-4.7, Gemini-2.5-Flash는 리더 대비 정답 필드당 비용이 6~11배 낮고 정확도 손실은 최대 약 2%p라고 한다.
모달리티마다 승자가 다르다
- 텍스트 최고 84.5%(Gemini-3.1-Pro), 이미지 67.2%(Gemma-4-31B), 오디오 23.7%(Gemini-2.5-Flash)였다.
- 이미지·오디오는 텍스트로 정규화한 컨텍스트를 모델에 넣은 결과다.
세대가 올라도 개선은 작다
- GPT-5.5는 GPT-5.4보다 통합 Value Accuracy가 0.3%p 낮았다.
- Claude-Opus-4.7은 Opus-4.6보다 1%p 미만 높았다.
그럴듯한 오답이 가장 위험하다
- 오디오 사례에서 정답 "15 to 35 years"를 모델이 "25 to 35"로 답했다.
- 타입도 스키마도 맞아서 필드 단위 검증 없이는 못 잡는다.

Community Reactions

JSON 요청 전에 문제를 먼저 풀게 했다는 경험
- 에이전트 상태 머신에서 코드 스니펫을 JSON에 담을 때, 먼저 코드를 만들게 하고 따로 JSON으로 감싸면 품질이 훨씬 높았다는 경험이다.
- 파싱과 포맷팅을 한 번에 시키는 게 취약하다는 의견이며, 중간 표현을 넣은 벤치마크와 BAML 비교를 보고 싶다고 했다.
리더보드 선정과 중립성에 의문이라는 의견
- Opus 4.7 등 주요 모델이 빠진 듯 보여 선택적이라는 지적이 있었다.
- 만든 회사의 Interfaze가 리더보드에 있어 중립성을 어떻게 검증하냐는 질문도 있었다.
운영에서 틀리는 건 파싱이 아니라 값이라는 경험
- JSON 통과율이 97%여도 기준값 없이는 레코드 단위로 오답 신호가 없다는 의견이다.
- 유효하지만 틀린 데이터가 실제로 프로덕션에 도달한다고 했다.
구조화 디코딩은 왜 안 쓰나라는 질문과 회의론
- 구조화 디코딩(constrained decoding)을 쓰면 되지 않느냐는 질문이 있었다.
- 일반 환각 벤치마크의 부분집합일 뿐이라거나 결정적 출력을 원하면 LLM을 쓰지 말라는 반론도 있었다.

How to Apply

파이프라인 샘플 50건으로 필드 정확도 재기
- 오늘 실제 입력 50건에 사람이 확인한 정답 JSON을 붙여라.
- JSON 통과율 말고 필드별 exact match를 스크립트로 계산해 비교하라.
저가 모델을 같은 샘플로 A/B 하기
- 현재 모델과 Qwen3.5-35B, GLM-4.7, Gemini-2.5-Flash 중 후보를 같은 샘플로 돌려라.
- 정확도 차이와 정답 필드당 비용을 함께 표로 만들어 교체를 결정하라.
추출을 두 단계로 나눠 비교하기
- 1단계에서 자유 형식으로 값을 뽑고 2단계에서 JSON으로 변환하는 호출을 만들어 단일 호출과 비교하라.
원문 근거 인용 필드를 스키마에 추가하기
- 중요 필드마다 원문 발췌 필드를 추가하고 값이 발췌에 실제로 있는지 코드로 검증하라.

Try It

복사해서 바로 해보기

# Claude/ChatGPT에 붙여넣기 (SOB 아이디어의 간이 버전: 필드 단위 근거 검증)

아래 {{문서}}에서 {{스키마}}에 맞는 JSON을 추출해라.
규칙:
1. 각 필드마다 값과 함께 문서에서 그대로 복사한 근거 문장(evidence)을 넣어라.
2. 문서에 없으면 값은 null, evidence는 ""로 둬라. 추측하지 마라.
3. 숫자·기간·날짜는 문서 표기를 바꾸지 마라.
4. 출력은 JSON만.
그다음 별도 단계로 각 필드의 value가 evidence와 정확히 일치하는지 하나씩 검사해 불일치 필드를 나열해라.

{{문서}}

Terminology

Value AccuracyJSON의 말단 필드 값이 검증된 정답과 정확히 같은 비율이다. 시험에서 답안지 서식이 아니라 정답 맞힌 개수를 세는 것과 같다.

Perfect Response한 레코드의 모든 필드가 정확히 맞은 비율이다. 한 칸이라도 틀리면 그 문제는 0점인 시험과 같다.

Faithfulness값이 원문에 근거하고 지어낸 게 아닌 정도다.

Structured hallucination타입과 스키마는 맞고 그럴듯하지만 틀린 값이다. 형식 검사를 통과해서 찾기 어렵다.

Reasoning-locked 모델추론 기능을 완전히 끌 수 없어 최소 설정으로 돌린 모델이다. 예: GPT-5, Gemini-3.1-Pro.

Related Resources

Structured Output Benchmark(SOB): JSON은 맞는데 값은 틀린다

Show HN: A new benchmark for testing LLMs for deterministic outputs

Apr 29, 2026•khurdula•View Original

TL;DR Highlight

28개 LLM 테스트 결과 JSON 통과율은 97%+인데 값 정확도는 15~30%p 낮았다

Who Should Read

LLM으로 송장·회의록·PDF에서 JSON을 뽑아 DB에 넣는 파이프라인을 운영하며 모델 선택에 고민인 백엔드 개발자

Core Mechanics

JSON 파싱 통과는 변별력이 없다
- 대부분의 최신 모델이 통합 리더보드에서 JSON Pass 95%+를 기록했다.
- Value Accuracy(필드 값이 정답과 정확히 일치하는 비율)는 JSON Pass보다 15~30%p 낮았다.
구조 지표는 99%인데 값은 틀린다
- Path Recall, Structure Coverage, Type Safety가 ~99%여도 leaf 값(최하위 필드 값)의 20~30%가 틀릴 수 있다.
- 레코드 전체가 완전히 맞는 Perfect Response는 최상위 모델도 절반 안팎이다.
1위는 비싼데 격차는 작다
- Value Accuracy 1위는 Gemini-3.1-Pro 82.0%, 이어서 GLM-5.1 80.6%, GLM-4.7 80.4%, Qwen3.5-35B 80.1%다.
- Qwen3.5-35B, GLM-4.7, Gemini-2.5-Flash는 리더 대비 정답 필드당 비용이 6~11배 낮고 정확도 손실은 최대 약 2%p라고 한다.
모달리티마다 승자가 다르다
- 텍스트 최고 84.5%(Gemini-3.1-Pro), 이미지 67.2%(Gemma-4-31B), 오디오 23.7%(Gemini-2.5-Flash)였다.
- 이미지·오디오는 텍스트로 정규화한 컨텍스트를 모델에 넣은 결과다.
세대가 올라도 개선은 작다
- GPT-5.5는 GPT-5.4보다 통합 Value Accuracy가 0.3%p 낮았다.
- Claude-Opus-4.7은 Opus-4.6보다 1%p 미만 높았다.
그럴듯한 오답이 가장 위험하다
- 오디오 사례에서 정답 "15 to 35 years"를 모델이 "25 to 35"로 답했다.
- 타입도 스키마도 맞아서 필드 단위 검증 없이는 못 잡는다.

Community Reactions

JSON 요청 전에 문제를 먼저 풀게 했다는 경험
- 에이전트 상태 머신에서 코드 스니펫을 JSON에 담을 때, 먼저 코드를 만들게 하고 따로 JSON으로 감싸면 품질이 훨씬 높았다는 경험이다.
- 파싱과 포맷팅을 한 번에 시키는 게 취약하다는 의견이며, 중간 표현을 넣은 벤치마크와 BAML 비교를 보고 싶다고 했다.
리더보드 선정과 중립성에 의문이라는 의견
- Opus 4.7 등 주요 모델이 빠진 듯 보여 선택적이라는 지적이 있었다.
- 만든 회사의 Interfaze가 리더보드에 있어 중립성을 어떻게 검증하냐는 질문도 있었다.
운영에서 틀리는 건 파싱이 아니라 값이라는 경험
- JSON 통과율이 97%여도 기준값 없이는 레코드 단위로 오답 신호가 없다는 의견이다.
- 유효하지만 틀린 데이터가 실제로 프로덕션에 도달한다고 했다.
구조화 디코딩은 왜 안 쓰나라는 질문과 회의론
- 구조화 디코딩(constrained decoding)을 쓰면 되지 않느냐는 질문이 있었다.
- 일반 환각 벤치마크의 부분집합일 뿐이라거나 결정적 출력을 원하면 LLM을 쓰지 말라는 반론도 있었다.

How to Apply

파이프라인 샘플 50건으로 필드 정확도 재기
- 오늘 실제 입력 50건에 사람이 확인한 정답 JSON을 붙여라.
- JSON 통과율 말고 필드별 exact match를 스크립트로 계산해 비교하라.
저가 모델을 같은 샘플로 A/B 하기
- 현재 모델과 Qwen3.5-35B, GLM-4.7, Gemini-2.5-Flash 중 후보를 같은 샘플로 돌려라.
- 정확도 차이와 정답 필드당 비용을 함께 표로 만들어 교체를 결정하라.
추출을 두 단계로 나눠 비교하기
- 1단계에서 자유 형식으로 값을 뽑고 2단계에서 JSON으로 변환하는 호출을 만들어 단일 호출과 비교하라.
원문 근거 인용 필드를 스키마에 추가하기
- 중요 필드마다 원문 발췌 필드를 추가하고 값이 발췌에 실제로 있는지 코드로 검증하라.

Try It

복사해서 바로 해보기

# Claude/ChatGPT에 붙여넣기 (SOB 아이디어의 간이 버전: 필드 단위 근거 검증)

아래 {{문서}}에서 {{스키마}}에 맞는 JSON을 추출해라.
규칙:
1. 각 필드마다 값과 함께 문서에서 그대로 복사한 근거 문장(evidence)을 넣어라.
2. 문서에 없으면 값은 null, evidence는 ""로 둬라. 추측하지 마라.
3. 숫자·기간·날짜는 문서 표기를 바꾸지 마라.
4. 출력은 JSON만.
그다음 별도 단계로 각 필드의 value가 evidence와 정확히 일치하는지 하나씩 검사해 불일치 필드를 나열해라.

{{문서}}

Terminology

Value AccuracyJSON의 말단 필드 값이 검증된 정답과 정확히 같은 비율이다. 시험에서 답안지 서식이 아니라 정답 맞힌 개수를 세는 것과 같다.

Perfect Response한 레코드의 모든 필드가 정확히 맞은 비율이다. 한 칸이라도 틀리면 그 문제는 0점인 시험과 같다.

Faithfulness값이 원문에 근거하고 지어낸 게 아닌 정도다.

Structured hallucination타입과 스키마는 맞고 그럴듯하지만 틀린 값이다. 형식 검사를 통과해서 찾기 어렵다.

Reasoning-locked 모델추론 기능을 완전히 끌 수 없어 최소 설정으로 돌린 모델이다. 예: GPT-5, Gemini-3.1-Pro.

Structured Output Benchmark(SOB): JSON은 맞는데 값은 틀린다

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources

Structured Output Benchmark(SOB): JSON은 맞는데 값은 틀린다

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources