JSON 응답에서 안정적인 워크플로로

먼저 수신 시스템부터 시작하세요

모델에게 JSON을 요청하기 전에, 다음 시스템이 무엇을 필요로 하는지 결정하세요. 필드 이름, 타입, 필수 필드, 누락된 정보의 표현 방식을 선택하세요. 예측 가능한 객체는 그 의미가 작업에 맞을 때만 유용합니다. 소비하는 애플리케이션과 함께 작은 버전 관리 스키마를 유지하세요.

명시적인 형태를 요청하세요

플레이그라운드에서 JSON을 선택하고 예상 필드를 설명하세요. 예를 들어, summary 문자열, next_steps 문자열 배열, missing_information 배열을 요청하세요. 결과는 외부 추측이 아닌 제공된 소스를 사용해야 한다고 명시하세요. 다음 객체는 예시일 뿐, 모델이 생성한 결과가 아닙니다.

코드

{
  "summary": "The launch date has not been supplied.",
  "next_steps": ["Confirm the owner and launch date."],
  "missing_information": ["owner", "launch_date"]
}

구문, 구조 및 근거 검증

먼저 JSON을 파싱하세요. 그런 다음 예상치 못한 타입, 누락된 필수 필드, 비즈니스 한도를 초과한 문자열을 거부하세요. 마지막으로 사실 필드를 소스와 대조하여 확인하세요. 스키마는 객체의 형태를 검증하지만, 날짜나 담당자가 사실인지 입증할 수는 없습니다. 다음 단계에서 추적성이 필요하면 소스 식별자를 보존하세요.

실패	복구
잘못된 JSON	파서 오류와 원래 작업을 포함하여 한 번 재시도
필드 누락	필수 형태를 요청하거나 검증 오류 반환
지원되지 않는 사실	알 수 없음으로 표시; 소스 근거 요청
잘린 출력	예산을 늘리거나 추출 범위 축소

불완전한 출력은 불완전한 것으로 처리하세요

중단된 응답은 문자열이나 객체 중간에서 끝날 수 있습니다. 실행하거나 자신감 있게 조용히 복구하지 마세요. 제공자 통합에서는 완료 상태를 검사하고 오류를 유지하세요. 추론은 출력 토큰을 소비하므로 높은 노력을 사용할 때는 이를 예산에 포함하세요. API 가이드에서 응답 처리를 설명합니다.

부작용 전에 경계를 두세요

파싱된 객체가 자동으로 이메일을 보내거나, 주문을 변경하거나, 명령을 실행해서는 안 됩니다. 권한과 비즈니스 동작을 독립적으로 검증하세요. 애플리케이션에 필요한 경우 승인 단계를 사용하세요. 자동화를 활성화하기 전에 음성 케이스—잘못된 타입, 알 수 없는 식별자, 추가 필드, 중단된 스트림—를 테스트하세요. 애플리케이션의 책임에 대해서는 도구 호출 섹션을 읽으세요.