직접 작성한 가상의 학습 예제입니다. 모델 결과는 미리 입력하지 않았습니다.
수정 가능한 시작점
- 1 · 확인할 글
- 월간 구독료가 두 번 청구됐어요. 두 건의 결제를 확인해 주실 수 있나요?
- 2 · 질문
- 어떤 종류의 의견인가요?
- 3 · 선택지 2~6개 정의
- 버그 또는 오류
- 기능 요청
- 결제 및 청구
- 사용 도움 요청
- 긍정적인 의견
- 기타
표시된 수치는 모델의 판단 확률이며 측정된 정확도나 보장이 아닙니다. ‘예/아니요’는 작성한 기준에 대응하며, 선택지 확률은 제공한 선택지 안에서만 비교됩니다.
필요한 결정부터 정하기
정해진 목록에서 범주 하나가 필요하면 Choice, 하나의 예/아니요 진술을 판단하려면 Noul을 사용합니다. 공식 인터페이스에서 Choice는 선택지 확률 분포를, Noul은 예 확률을 반환합니다. 둘 다 다음 행동을 실행하지 않습니다.
‘어느 팀이 먼저 처리할까?’와 ‘결제 문제가 있는가?’는 다른 질문입니다. 결국 담당자가 한 명이어야 해도 결제 문제와 앱 오류는 동시에 존재할 수 있습니다.
예제 바꾸기
피드백 템플릿은 Choice로 시작합니다. 전달 정책을 적고 명확한 메시지, 여러 문제가 섞인 메시지, 범위 밖 메시지를 비교하세요. Noul을 시험하려면 예/아니요로 전환하고 한 속성만 물으며 그 속성을 설명하도록 규칙을 바꿉니다. 유형만 바꾸는 것으로 충분하지 않습니다.
여러 라벨이 동시에 맞을 수 있으면 별도 질문으로 정보를 보존할 수 있습니다. 이 편집기는 한 번에 질문 하나를 실행합니다. 여러 질문의 통합은 자신의 애플리케이션이나 공식 Playground에서 다루세요.
맥락에 맞게 해석하기
Choice는 제공한 선택지에, Noul은 예에 해당하는 진술에 상대적인 결과입니다. 서로 다른 질문의 값을 공통된 품질 점수처럼 비교하지 마세요. 맥락이 부족하면 두 방식 모두 영향을 받습니다.
흔한 설계 오류
‘긴급하거나 청구 문제인가?’는 독립된 속성을 섞습니다. 예만으로 어느 속성인지 알 수 없습니다. 질문을 나누고 긴급성과 담당 부서의 관계는 코드로 결정하세요. 반대로 별도 예/아니요 답만으로 혼합 메시지의 담당자가 정해지지도 않습니다. 이 예제는 설계 조언이며 성능 측정 결과가 아닙니다.
이어서 읽기: Jev로 고객 피드백 분류하기
출처와 더 읽을거리
이 가이드는 공식 문서와 링크된 커뮤니티 보고를 근거로 합니다. 커뮤니티의 관찰 내용은 해당 작성자의 보고임을 명시합니다.
출처를 확인하는 방법