TypeSafe Jev 4/10: 평가할 재료를 state에 어떻게 담을까 | DAKER 커뮤니티
Jev에서 질문을 잘 만드는 일만큼 중요한 것이, 모델이 무엇을 보고 판단할지 정리하는 일입니다. 같은 질문이라도 어떤 재료를 함께 넣느냐에 따라 평가의 맥락이 달라지기 때문입니다.
이번 글은 Jev의 state가 무엇인지, 한 요청 안에서 어떤 방식으로 묶어 넣는 것이 좋은지 간단히 정리합니다. 티켓 대화, 주문 정보, 정책 문서처럼 서로 관련된 재료를 한곳에 모아 두면 질문도 더 또렷해집니다.
state는 모델이 평가할 대상입니다
state는 System One 모델에게 평가하라고 넘기는 내용입니다. 지원 메시지, 본문 구간, 앱의 현재 상태처럼 무엇이든 될 수 있으며, API의 state 필드에 질문과 함께 넣습니다.
state에는 판단의 재료를 담고, 질문은 그 재료를 어떻게 볼지 정합니다.
한 요청에서는 하나의 state를 여러 질문이 함께 봅니다
각 요청은 하나의 state를 하나 이상의 질문에 대해 평가합니다. 모든 질문은 같은 state를 보고, 서로 독립적으로 평가됩니다. 그래서 Choice·Score·Noul을 한 요청에 함께 섞을 수도 있습니다.
즉, 재료는 한 번만 넘기고 그 재료를 두고 여러 각도의 판단을 물을 수 있습니다.
state는 문자열, 객체, 배열로 넣을 수 있습니다
state의 형태는 크게 세 가지입니다.
문자열
메시지 하나, 기사 한 단락, 짧은 구절처럼 단일 텍스트를 넣을 때 적합합니다. 예시는 "My card was charged twice."입니다.
객체
이름 있는 필드, 관련 레코드, 앱 상태를 함께 담을 수 있습니다. 대부분의 요청에는 이 방식이 권장됩니다. 무엇이 어떤 정보인지 필드 이름으로 드러낼 수 있어, 질문과의 대응도 더 분명해집니다.
배열
메시지나 레코드의 시퀀스를 다룰 때 쓸 수 있습니다.
Python에서는 문자열·dict·list를 그대로 client.system_one(state=...)에 넘기면 됩니다. 전문가 패널에게 판단을 부탁하기 전에 보여줄 자료를 정리한다고 생각하면 이해하기 쉽습니다.
관련 정보는 한 state에 함께 담는 것이 좋습니다
문서 예시는 티켓 대화, 주문 청구, 환불 정책을 하나의 JSON 객체로 묶습니다. 결정이 여러 부분을 비교해야 한다면, 그 재료들을 따로 떼어 두기보다 함께 넣는 편이 자연스럽습니다.
결정이 비교를 필요로 한다면, 비교 대상도 같은 state 안에 있어야 합니다.
객체 하나만으로도 대화·주문·정책을 모두 담을 수 있습니다. 이렇게 두면 모델이 필요한 맥락을 한 번에 볼 수 있습니다.
내용과 질문은 분리해서 생각합니다
state에는 내용과 근거 사실을 두고, 질문은 그 재료에 대한 판단을 정의합니다. 예를 들어 환불 요청과 정책 문서는 state에 넣고, 고객이 환불을 요청했는가, 정책이 이를 지원하는가는 질문으로 둡니다.
이 구분이 분명할수록 같은 state를 재사용해 여러 판단을 안정적으로 물을 수 있습니다.
현재는 텍스트 중심으로 다룹니다
Jev는 텍스트만 받습니다. state는 문자열, JSON 객체, 또는 텍스트 값의 배열이어야 합니다. 이미지·오디오·비디오는 아직 지원되지 않습니다.
또한 주 학습 언어는 영어입니다. CJK를 포함한 다른 언어도 받을 수 있지만, 현재 정확도는 더 낮다고 Models 문서에 안내되어 있습니다.
정리하며
실제 티켓·주문·정책 샘플을 하나 골라, 문자열 하나로 넣을지 JSON 객체로 나눌지 먼저 스케치해 보면 좋습니다. 이때는 필드 이름을 설명적으로 짓는 데 집중하면 됩니다.
참고 자료
이전: 3/10 빠른 구조화 결정 모델 · 다음: 5/10 Choice·Score·Noul 세 가지
여러분은 state를 설계할 때 문자열과 JSON 객체 중 어느 쪽이 더 다루기 편하다고 느끼시는지 궁금합니다.