정리와 체크리스트

4장에서 배운 것

구조화 출력 — 모델의 답을 자유 문장이 아니라 약속한 구조(JSON)로 받아 내는 것입니다.
스키마 — 데이터의 모양을 적은 명세. 칸, 타입, 허용 값, 필수 여부를 정합니다.
JSON 모드 — response_mime_type="application/json"과 response_schema로 켭니다. 프롬프트가 아니라 config=에 넣습니다.
Pydantic — 스키마를 파이썬 클래스로 쓰고, 맞지 않는 데이터에 ValidationError를 냅니다.
Enum — 허용 값을 목록으로 고정합니다. 즉석에서 지은 라벨을 막습니다.
경계 규칙 — 두 라벨에 걸치는 문의를 어디로 보낼지 정한 규칙. 시스템 프롬프트에 적습니다.

한눈에 보는 핵심

config=types.GenerateContentConfig(
    system_instruction=CLASSIFY_SYSTEM,       # 역할과 경계 규칙
    temperature=1.0,                          # 분류는 낮은 온도
    response_mime_type="application/json",    # 답은 JSON
    response_schema=IntentResult,             # 그 JSON 의 모양
)
result = response.parsed                      # IntentResult 객체

스키마가 보장하는 것	스키마가 보장하지 않는 것
JSON 형식, 칸의 이름과 타입	고른 라벨이 맞는 라벨인지
`intent`가 일곱 라벨 중 하나	옮겨 적은 주문번호가 실제 주문인지
`urgency`가 세 값 중 하나	요약 문장의 표현 (실행마다 다릅니다)

개발자가 정한 것	모델이 한 것
라벨 일곱 개, 경계 규칙, 긴급도 기준	문의 하나하나의 판정
칸의 이름과 설명	주문번호 찾기, 한 줄 요약

체크리스트

[ ] 모델의 답이 문장이면 코드가 분기할 수 없는 이유를 설명할 수 있다.
[ ] "JSON으로 답해"라는 부탁과 스키마 설정이 어떻게 다른지 말할 수 있다.
[ ] response_mime_type과 response_schema가 각각 무엇을 정하는지 말할 수 있다.
[ ] Enum과 str | None을 각각 어떤 칸에 쓰는지 설명할 수 있다.
[ ] Field(description=...)이 주석이 아닌 이유를 설명할 수 있다.
[ ] response.parsed에 무엇이 들어 있는지 안다.
[ ] 라벨 체계에 "기타"가 필요한 이유를 설명할 수 있다.
[ ] 첫 문의가 환불교환으로 분류된 것이 누구의 결정인지 말할 수 있다.
[ ] 긴급도의 판정 기준이 코드의 어디에 적혀 있는지 말할 수 있다.
[ ] lesson04_intent_classifier.py를 실행해 다섯 문의의 결과를 확인했다.

한 줄 핵심

스키마는 답의 모양을 강제합니다. 그 모양 안에 무엇을 넣을지는 우리가 적은 규칙과 설명이 정합니다.