구조화 출력 실패는 유효성 비율만으로 진단할 수 없다

무엇인가

이 논문은 호스팅 LLM에서 구조화 출력을 받기 위해 프롬프트에 Pydantic 스키마를 명시하고, 응답을 검증한 뒤 실패하면 검증 오류를 붙여 재시도하는 이른바 프롬프트 강제 파이프라인을 다룬다. 제약 디코딩이나 벤더 네이티브 구조화 출력도 있지만, 교차 필드 검사와 커스텀 제약, 벤더·모델·엔드포인트 전환을 고려하면 애플리케이션 측 검증은 남는다. 문제는 실무가 파이프라인 신뢰도를 단일 유효성 비율로 요약해, 왜 실패했고 어떤 개입이 효과적인지를 가린다는 점이다.

어떻게 동작하나

연구는 identify, gather, answer 세 노드의 순차 파이프라인을 쓴다. 각 노드마다 Pydantic 모델이 있고 시스템 프롬프트에 JSON Schema를 넣어 JSON만 요구한다. 응답은 Pydantic의 기본 lax 모드 model_validate_json으로 검증하고, 실패하면 검증 오류를 덧붙여 최대 3회 더 재시도한다. 중간 스키마에는 식별자 정규식 ^[a-z][a-z0-9_]{2,30}$, 열거형, coverage_notes 250자·answer 400자·fact 400자 상한, 리스트 길이와 숫자 범위, 네 가지 교차 필드 검사, supporting_entity_ids의 항목별 식별자 패턴 검사가 들어간다. 이 항목별 검사만 프롬프트에 드러나지 않고 재시도 피드백으로만 보인다. 제약 표면을 바꾼 변형도 둔다. medium_v2는 세 문자 상한을 1000·1200·800으로 올려 Sonnet 4.6에만 적용하고, medium_v3_loose_regex는 식별자 패턴을 하이픈까지 허용하도록 풀되 31자 상한은 유지해 gpt-5.6-sol과 terra에 적용한다.

무엇과 다른가

실패 원인을 나누기 위해 검증에 실패한 시도만 대상으로 결정론적 분류기를 적용한다. 1단계는 원문 응답의 행동 패턴을 우선 판정한다. 선행 공백 뒤 삼중 백틱으로 시작하면 markdown_wrap, 중괄호·대괄호·펜스로 시작하지 않고 20자 이상의 산문 뒤에 중괄호 JSON이 있으면 prose_preamble, 파싱된 객체의 루트 키에 JSON Schema 메타 키워드가 둘 이상이면 schema_mirroring이다. 2단계는 Pydantic 오류 유형을 regex_pattern, length_bound, enum_violation, missing_field, range_bound, parse_error 등으로 매핑한다. 오류가 여러 개면 다수 범주를 택하고 동률이면 첫 발생을 택한다. 범주는 제약의 의도가 아니라 인코딩 방식에 따른다. 31자를 넘는 식별자는 max_length가 아니라 정규식 수량자 위반이므로 regex_pattern으로 분류된다. 1단계 우선 규칙 때문에 펜스 안에 길이 위반이 있어도 markdown_wrap으로 기록되어, 이 범주는 추가 결함이 없음이 아니라 엄격 파싱 실패를 뜻한다. 분류기는 개발 단계 손 라벨 144개와 140/144(97.2%) 일치했고, 동결 뒤 사전 등록한 held-out 100개에서는 69/100(69.0%, 범주 빈도 가중 73.4%) 일치에 그쳤다. 사후 점검에서 분류기가 범주 정의나 우선순위를 잘못 적용한 사례는 없었고, 18건은 표시된 출력만으로 검증기가 보고한 길이 초과를 확인할 수 없었다.

어떻게 쓰나

실험은 OpenAI의 gpt-4o, gpt-4o-mini, gpt-5.6-luna·sol·terra와 Anthropic의 claude-haiku-4-5-20251001, sonnet-4-6, sonnet-5, opus-4-8 등 9개 모델/API 구성으로 수행됐다. 질문은 HotpotQA의 validation split distractor 구성 첫 레코드와 FinanceBench의 PatronusAI/financebench 공개 샘플 첫 레코드를 썼고, evidence는 2,000자로 절단했으며 셔플하지 않았다. 보고 기준은 18개 구성의 3,997회 시도와 1,126회 실패이고, 전체 코퍼스는 20개 셀 4,396회 시도다. 30회 미만 베이스라인 실행 셀은 파일럿으로 제외했고, 60회의 프롬프트 변형 실행은 4.4절 외에는 제외했다. 가능한 곳에서는 temperature=0을 요청했지만 일부 모델은 파라미터를 거부해 제공자 기본값으로 실행됐다. 시도는 독립이 아니어서 질문 단위 클러스터 부트스트랩 2,000회로 95% 구간을 냈고, 이 설계는 모델 능력 순위가 아니라 특정 엔드포인트 구성 간 비교다.

전제와 한계

핵심 결과는 유효성 비율이 실패의 질을 가린다는 것이다. 시도 가중 실패율은 28.2%(95% CI 26.3–30.1)지만 Haiku 4.5가 1,126개 실패 중 878개를 차지해, 이를 제외하면 9.3%이고 9개 중간 티어 실패율의 비가중 평균은 16.7%다. 재시도 루프 아래 973회 실행 중 948회가 세 노드를 모두 완료했고, Haiku 4.5는 시도 실패율 66.1%에도 166회 중 142회를 완료했지만 완료 실행당 9.36회 시도가 들었다(전체 풀링 4.22회). 첫 시도만 보면 2,896회 중 2,192회(75.7%)가 검증을 통과했고, 순수 포맷 실패를 복구로 치면 85.8%가 된다. Haiku 4.5의 첫 시도 475회는 모두 코드 펜스로 시작해 하나도 통과하지 못했고, 두 번째 시도에서도 165/475가 펜스를 유지했지만 세 번째부터는 길이 위반만 남았다.

지배 범주로 묶으면 구성은 네 프로파일로 나뉜다. Haiku 4.5와 Sonnet 5는 markdown_wrap, 세 GPT-5.6 모델과 gpt-4o-mini는 regex_pattern, Opus 4.8과 Sonnet 4.6은 length_bound, gpt-4o는 schema_mirroring이 지배적이다. gpt-4o와 gpt-4o-mini는 같은 세대지만 프로파일이 다르고, gpt-4o-mini·Sonnet 4.6·gpt-4o는 실패율 13.6%·15.7%·16.0%로 구간이 겹치는데도 지배 범주가 다르다. 과제 분포도 프로파일을 바꾼다. Sonnet 5는 FinanceBench 21.1%, HotpotQA 21.6%로 실패율이 비슷하지만 HotpotQA에서는 43개 실패 중 81.4%가 markdown_wrap이고, FinanceBench 24개 실패에서는 length_bound 41.7%, regex_pattern 33.3%, markdown_wrap 25.0%로 뚜렷한 지배 범주가 없다. 제약을 바꾸면 같은 모델의 프로파일도 바뀐다. Sonnet 4.6은 중간 스키마에서 length_bound가 28개 실패 중 18개였는데, medium_v2로 상한을 올리자 length_bound가 0이 되고 regex_pattern이 24개 중 14개로 지배적이 되었으며 실패율은 15.7%에서 7.4%로 내려갔다. 상한에 걸린 값은 coverage_notes 8건이 251–315자(평균 9.0% 초과), answer 9건이 417–500자(평균 15.2% 초과), fact 1건이 480자였다. 저장된 중간 출력 178개를 medium_v2 스키마로 오프라인 재검증하자 18개 length_bound 실패가 모두 통과했고, 기존 통과 출력이 실패로 바뀌지 않았으며 남은 10개는 원래의 regex_pattern·enum_violation·prose_preamble 사례였다.

가장 실무적인 발견은 포맷 실패가 밑에 깔린 스키마 위반을 숨긴다는 점이다. 681개 펜스 실패 중 펜스를 제거한 뒤 검증을 통과한 것은 48.0%뿐이고, 나머지는 파싱 오류 메시지에 드러나지 않는 길이·패턴 위반을 품고 있었다. 펜스를 억제하는 프롬프트 절제 실험은 실패를 길이 위반 쪽으로 옮기는 것처럼 보였지만, 저자들은 그것이 이미 있던 위반을 드러낸 것과 일치한다고 해석한다. 따라서 펜스 제거를 복구로 세면 복합 실패를 해결된 것으로 오독하고, 1차 라벨만 보면 프롬프트 절제가 실패 모드를 이동시킨 것처럼 보이며, 스키마 오류를 한 클래스로 뭉치면 문자 클래스를 풀어도 같은 패턴에 인코딩된 길이 초과가 남는 것을 놓친다. 논문은 검증기·스키마·재시도·평가 설계를 위한 네 가지 엔지니어링 실천을 도출하는데, 세 가지는 데이터로 뒷받침되고 재시도 피드백에 관한 하나는 제안일 뿐 검증되지 않았다.

한계도 분명하다. 이 연구는 프롬프트 강제와 사후 검증만 다루고 제약 디코딩과 벤더 네이티브 구조화 출력은 평가하지 않는다. 따라서 디코더 수준 강제가 이 실패들을 막을 수 없다는 주장이 아니다. 설계가 완전 교차되지 않아 일부 변형은 특정 모델에만 적용됐고, 모델 간 비교는 일반적 능력 순위가 아니라 특정 API 구성의 비교다. 시도는 재시도와 질문 반복 때문에 독립이 아니며, 고정된 질문 접두부가 벤치마크 전체를 대표하지도 않는다. 일부 지배 범주 비율은 실패 수가 적어 불안정하다. 예를 들어 Opus 4.8의 76.9%는 13개 실패에 근거한다. 식별자 정규식 변형 비교는 실패가 3·6·5·4건뿐이라 정밀한 비교 추론에 부족하고, 분류기의 타입 오류 매핑은 코퍼스에 해당 오류가 없어 검증되지 않았다. held-out 인간 일치도 69.0%도 길이 라벨을 사람이 눈으로 확인하기 어렵다는 점을 보여준다.