동일한 JSON 스키마를 다섯 제공자에 보낸 후의 구조적 검증 결과

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

동일한 JSON 스키마를 다섯 제공자에 동일한 방식으로 150회 요청하여 출력의 구조적 일관성을 자동 검증한 결과 스키마 통과가 99건으로 가장 많았고 필드 누락이 35건, JSON 문법 오류가 16건, 제공자/API 오류가 1건으로 집계되었다. 검증은 생성된 응답을 JSON으로 파싱한 뒤 사전 정의된 스키마 규칙과 대조하여 통과·결함 유형을 분류하는 방식으로 이루어졌으며 이로써 파싱 실패와 필드 누락이 주요 실패 모드임이 확인되었다. 이 결과는 LLM 기반 구조화 출력 파이프라인에서 스키마 검증을 자동화함으로써 잘못된 레코드의 전파를 차단하고 프롬프트·후처리 전략을 수치적으로 개선할 수 있음을 시사하지만, 제공자별 세부 설정과 반복 분포가 제시되지 않아 원인 분석과 최적화는 추가 실험이 필요하다.

섹션별 상세

실험 목적은 동일한 JSON 스키마에 대한 다양한 LLM 제공자의 출력 일관성을 정량화하는 것이었다. 입력으로는 support_ticket.schema의 필드(category, priority, entities[], confidence)가 주어졌고 각 제공자별로 동일한 워크플로를 150회 실행하여 출력 JSON을 수집했다. 수집된 출력은 단일 계약(contract)에 대하여 자동 스키마 검증을 수행하여 통과·필드 누락·잘못된 JSON·제공자/API 오류로 분류하였다. 이 방식은 구조적 파싱 안정성을 측정하는 실용적 검증 프로세스로 작동하였다.

스키마 검증 처리 과정은 입력된 LLM 출력을 JSON 파서로 구문 분석한 뒤 사전 정의된 스키마 규칙과 대조하는 방식으로 진행되었다. 파싱 단계에서 JSON 문법 오류가 발생하면 '잘못된 JSON'로 분류되었고, 문법은 통과하지만 일부 필드가 누락되면 '필드 누락'으로 집계되었다. 최종적으로 모든 검증 결과는 카운트되어 각 오류 유형의 빈도와 전체 통과율이 산출되었다. 이 절차는 자동화된 계약 준수 검사로서 파이프라인 안정성 판단에 직접적으로 활용 가능하다.

정량적 결과는 총 150회 실행 중 스키마 통과가 99건으로 가장 많았고 필드 누락이 35건, 잘못된 JSON이 16건, 제공자/API 오류는 1건으로 집계되었다. 이 수치들은 동일 스키마·동일 워크플로 조건 하에서도 출력 형식의 불완전성이 유의미하게 발생함을 보여주며 특히 필드 누락과 JSON 문법 오류가 주요 실패 모드임이 확인되었다. 집계 결과는 제공자별 편차 가능성을 시사하되 이미지에 제시된 집계는 제공자별 세부 분포를 명시하지 않기 때문에 개별 모델 특성 판단은 추가 데이터가 필요하다.

실무적 의미는 LLM을 통해 구조화된 데이터를 얻을 때 스키마 검증을 자동화하는 것이 필수적이라는 점이다. 스키마 검증을 삽입하면 파싱 실패를 조기에 탐지하고 downstream 시스템으로 전파되는 잘못된 레코드를 줄일 수 있으며, 오류 유형 통계를 통해 프롬프트·후처리 전략을 보정할 근거를 제공한다. 다만 이미지 자료는 제공자별 결과를 요약하여 보여주나 세팅(프롬프트 템플릿, 온도 등)과 제공자별 반복 분포가 표기되지 않아 실제 원인 분석과 최적화는 추가 실험과 로그 검토가 요구된다.

이미지 분석

Infographic
이미지는 왼쪽에 검증 대상 스키마 필드(category, priority, entities[], confidence)를 제시하고 중앙에 다섯 개 제공자 목록을 배치한 뒤 오른쪽에 오류 유형별 집계 수치를 시각적으로 연결하였다. 이미지에 명시된 수치는 총 150회 실행을 기준으로 스키마 통과 99건, 필드 누락 35건, 잘못된 JSON 16건, 제공자/API 오류 1건으로서 자동 검증 파이프라인의 주요 실패 모드를 정량화하여 전달한다. 이 인포그래픽은 실험 설계(동일 스키마·여러 제공자·여러 실행)와 결과 요약을 결합하여 구조적 일관성 문제를 빠르게 파악하도록 설계되었다.
동일한 JSON 스키마를 여러 제공자에 보낸 뒤 150회 워크플로 실행 결과를 스키마 통과·필드 누락·잘못된 JSON·제공자/API 오류로 분류한 요약 인포그래픽이다.

용어 해설

JSON Schema: — JSON Schema는 JSON 데이터의 구조와 필수 필드를 선언하는 형식이다. 스키마는 각 필드의 이름·자료형·반복 여부 등을 규정하여 입력과 출력에서 구조적 일관성을 검증할 수 있게 한다. LLM 출력의 구조적 검증과 자동 파싱 파이프라인에서 계약(contract) 역할을 하여 downstream 처리 오류를 줄인다.
Schema Validation: — 스키마 검증은 생성된 JSON이 사전 정의된 스키마 규칙을 만족하는지 확인하는 과정이다. 검증 절차는 필수 필드 존재 확인, 자료형 일치 검사, 중첩 구조의 일관성 검사로 이루어지며 자동화된 도구로 시행하면 대량 결과를 집계할 수 있다. LLM 출력의 유효성 판단과 오류 분류(결측 필드, 잘못된 JSON 등)에 핵심적 역할을 한다.
Model Output Variability: — 모델 출력 변동성은 동일한 프롬프트나 스키마를 줬을 때 발생하는 응답 형식·내용의 차이를 의미한다. 이 변동성은 온도·토큰 제한·리턴 포맷 지시 방식·모델 아키텍처 차이에서 기인하며 파싱 실패·필드 누락·잘못된 JSON의 주요 원인이 된다. 변동성을 정량화하면 어떤 제공자에서 구조적 일관성이 높은지 판단할 수 있다.

동일한 JSON 스키마를 다섯 제공자에 보낸 후의 구조적 검증 결과

TL;DR

섹션별 상세

이미지 분석

용어 해설

관련 토론

댓글

관련 기사

70B 모델로 엄격한 JSON 스키마 유효성 확보한 운영 경험

판단에 주소를 부여하는 Schema Coding: LLM 외부 판단 백엔드 설계

한 번에 거대한 중첩 JSON을 요청하면 출력 중단으로 모든 답변이 손실되는 '포맷 택스' 문제가 발생한다는 경험 공유

369개 필드 추출 과제에서 최첨단 모델은 0%를 기록했고 Groq에서 구동한 27B 오픈 모델은 85%를 기록했다

비결정적 동작과 환각을 억제하는 로컬 검증 중심 아키텍처 공유