스키마는 '데이터가 어떻게 생겼는지' 매뉴얼로 이해할 수 있습니다. 구체적인 내용은 책임지지 않지만, 구조, 필드, 타입, 계층 구조, 제약 조건을 정의합니다. 모델이 자유롭게 재생을 멈추길 원하면서도 솔직히 특정 형식으로 출력하려면 스키마가 중요한 역할을 합니다. 그래서 JSON, 구조화된 출력, 함수 호출, 툴 호출에 대해 이야기할 때 항상 이 부분을 언급합니다.
정확히 무엇을 제한하는 건가요?
| 제약 조건 | 스키마는 무엇을 말하고 있나요? |
|---|---|
| 필드 | 어떤 열쇠가 있어야 하는지, 이름이 뭐야 |
| 유형 | 문자열, 숫자, 불리언, 배열, 객체 중 하나인가요? |
| 레벨 | 어떤 밭이 함께 묶여 있고, 누가 누구의 자식인지 |
| 규칙 | 필요한 값, 빈 값, 그리고 특정 값으로만 취할 수 있는 항목 |
왜 JSON과 툴 호출 모두에 나타나나요?
이 두 유형의 시나리오는 '괜찮은' 것이 아니라 '프로그램을 바로 선택할 수 있다'고 원하기 때문입니다. 모델이 자연어를 출력하면 사람들은 그것을 이해할 수 있지만 프로그램이 포착하지 못할 수도 있습니다; 스키마에서는 모델이 단순히 답변을 작성하는 것이 아니라 정의된 컨테이너에 값을 채웁니다. 도구 호출은 특히 이 점에 의존하는데, 매개변수 이름, 매개변수 유형, 필요한 관계가 잘못되면 오류가 발생할 수 있기 때문입니다.
그게 프롬프트와 무슨 관련이 있을까요?
프롬프트는 모델에게 "당신은 무엇을 할 것인가?"라고 말하는 것입니다; 스키마는 모델에 "당신이 생성하는 데이터가 어떻게 보여야 하는지"라고 알려주는 것과 비슷합니다. 두 가지 방법은 종종 함께 사용되지만, 작동 방식은 다릅니다. 프롬프트에만 의존할 때는 연락처 정보를 출력할 수 있지만, name, phone, email 같은 고정 키를 안정적으로 제공하지 않을 수 있습니다; 스키마가 추가되면 출력이 프로그램이 기대하는 것에 더 가까워집니다.
흔한 오해
- 오해 1: 스키마가 있으면 결과가 신뢰할 만하다. 사실, 이 기관은 형식을 더 잘 억제하며, 사실 자체가 정확한지 책임지지 않는다.
- 신화 2: 스키마는 오직 개발자만의 것. 사실, 고정 테이블 추출, 배치 분류, 자동화된 워크플로우를 하고 있는 한 이미 영향을 받고 있습니다.
- 오해 3: JSON을 말하는 다른 말일 뿐입니다. 좀 더 정확히 말하면, JSON이 매개체이고 스키마가 규칙입니다.
따라서 스키마의 진정한 가치는 출력물을 '더 깔끔하게 보이게' 만드는 것이 아니라, 모델 결과가 프로그램, 테이블, 툴체인에 더 쉽게 반영되도록 만드는 데 있습니다. 이 글은 흔한 현상을 설명합니다: 왜 AI가 정보를 추출하는지, 어떤 사람들은 산문 한 조각을 얻고, 또 어떤 사람은 데이터베이스에 직접 저장할 수 있는 데이터를 얻는 이유입니다.
