유효한 JSON만으로는 충분하지 않습니다. 구조화된 LLM 출력을 평가하세요.

최근 연구에서는 형식과 의미를 분리합니다.

2026년 6월 소프트웨어 엔지니어링 사전 인쇄에서는 생성된 출력의 구문, 구조 및 의미 오류를 구별합니다. 2026년 8월 연구에서는 스키마 설명이 분류 동작에 어떻게 영향을 미치는지 조사했습니다. 둘 다 프롬프트를 통해 구조화된 출력 및 버전 관리 스키마의 내용을 평가하는 데 동기를 부여합니다. 어느 쪽도 보편적인 최고의 스키마 디자인을 확립하지 못합니다.

증거: 소프트웨어 엔지니어링 LLM의 구조적 출력 제어에 대한 실증 연구 [1]귀하의 프롬프트가 유일한 프롬프트는 아닙니다: LLM이 구조화된 출력 스키마 설명에 얼마나 가중치를 두나요? [2]

소비자에게 실제로 필요한 계약서를 작성하세요

Rubrex는 허용되는 유형, 필수 필드, 열거형, Null 동작 및 교차 필드 규칙을 정의할 것을 권장합니다. 그런 다음 값이 입력에 어떻게 기반을 두어야 하는지 정의합니다. 유효한 날짜가 반드시 올바른 날짜는 아닙니다. 허용된 상태 코드는 여전히 증거에 부적절할 수 있습니다.

누락된 정보를 표시하는 방법을 지정합니다. 모든 필드가 필수이지만 소스에 값이 부족한 경우 모델은 값을 만들도록 압력을 받을 수 있습니다. 스키마와 애플리케이션은 누락, 알 수 없음, 적용할 수 없음 및 해당 상태가 서로 다른 의미를 갖는 추출 실패를 구별해야 합니다.

유효성 검사기와 의미론적 증거 결합

구조적 요구 사항에 대해 파서 및 스키마 유효성 검사기를 사용하십시오. 가능한 경우 일관된 합계 또는 유효한 식별자 관계와 같은 결정적 교차 필드 검사를 추가합니다. 추출된 사실의 경우 주석이 달린 소스 범위 또는 다른 신뢰할 수 있는 참조와 값을 비교하세요.

필드별 결과 및 모든 필수 필드의 정확성을 보고합니다. 9개의 올바른 필드와 1개의 잘못된 지불 대상이 있는 기록은 90% 정확하다고만 유용하게 설명되지 않습니다. 판독 시 오류 심각도와 다운스트림 결과를 보존합니다.

예시: 갱신일이 누락됨

계약 추출기는 갱신 날짜를 반환해야 하지만 문서에는 통지 기간만 지정되어 있습니다. 모델은 스키마를 만족하는 그럴듯한 날짜를 내보냅니다. 구조 레이어가 통과됩니다. 증거 기반 계층이 실패합니다.

적절한 경우 명시적으로 알 수 없는 상태를 허용하고 검토에 필요한 소스 증거를 포함하도록 출력 계약을 수정합니다. 명시적인 갱신 날짜가 있는 문서와 갱신 날짜가 없는 문서를 모두 테스트합니다. 수정 사항은 추출 가능한 정보를 잃지 않고 지원되지 않는 값을 방지해야 합니다.

프롬프트 및 스키마 변경 사항을 하나의 릴리스 표면으로 처리

시스템 지침과 모순되는 부분이 있는지 필드 설명을 검토하세요. 스키마, 프롬프트, 모델 및 소비자의 버전을 함께 지정합니다. 이전 및 새 문서 템플릿, 중첩 개체, 빈 컬렉션 및 부분 오류를 테스트합니다. 스키마 마이그레이션에는 기존 레코드와 다운스트림 코드가 새 상태를 해석하는 방법이 포함되어야 합니다.

일반적인 질문