Jev state

허용되는 구조

가장 단순한 state은 "내 카드에 금액이 두 번 청구되었습니다." 같은 일반 문자열이다. 사례가 텍스트 한 덩어리라면 문자열을 사용한다. 이름이 붙은 필드, 관련 레코드, 애플리케이션 state가 있다면 메시지와 주문 ID를 함께 담는 식으로 JSON 객체를 사용한다. 메시지나 레코드의 연속에는 텍스트 배열을 사용한다. Python에서는 그에 맞는 string, dict, list를 client.system_one(state=...)에 전달한다.

TypeSafe의 state 페이지는 각 부분에 설명적인 이름을 붙일 수 있도록 대부분의 요청에 객체를 권장한다. 지원 대화, 두 번 승인된 결제가 있는 주문, 환불 정책을 한 객체에 담을 수 있다. 그래도 하나의 state다. 판단에 각 부분의 비교가 필요하다면 관련 정보를 함께 넣는다. 필드 이름에 두 번째 질문을 숨기지 않는다.

Jev은 텍스트만 받는다. State은 문자열, JSON 객체 또는 텍스트 값 배열이어야 한다. 이미지, 오디오, 동영상은 지원하지 않는다. 주요 학습 언어는 영어이며 CJK 문자를 포함한 다른 언어도 사용할 수 있지만 정확도는 낮다. 이 언어 관련 안내는 모델 카드를 참조하고, 픽셀 데이터는 먼저 필드로 변환해 요청에서 제외한다.

콘텐츠와 질문 분리

State에는 콘텐츠와 뒷받침 자료를 넣고, 판단은 질문으로 정의한다. 환불 요청과 정책은 state에 넣은 뒤 고객이 환불을 요청했는지, 정책상 환불이 가능한지 질문한다. 질문을 state 데이터 덩어리에 붙여 넣어도 Jev은 여전히 instructions 필드에 답하며, 32k의 state+가장 긴 질문 예산을 소모하는 위치에 프롬프트만 중복된다.

관련 없는 세부 정보로 가득 찬 큰 state은 jev-1.13에 문서화된 실패 유형이다. 무관한 내용이 방해 요소로 작용해 정확도가 떨어지고, 데이터 덩어리가 비대해지면 어느 필드가 오답을 유발했는지 찾기도 어려워진다. 먼저 코드에서 필터링하고 질문에 필요한 필드만 보낸다. 필터링할 수 없다면 TypeSafe의 RAG 구절 분류 쿡북처럼 본 판단 전에 Noul으로 구절의 관련성을 평가할 수 있다.

컨텍스트 길이에는 한도가 있습니다. Jev 1.13은 전체 요청에 64k 토큰, state과 가장 긴 질문을 합친 내용에 32k 토큰을 허용합니다. Speculative fan-out은 간결한 state을 기준으로 짧은 질문 여러 개를 묶습니다. 마지막 고객 메시지와 청구 내역 2줄만 필요할 때 문의 기록 전체를 첨부하는 것보다 저렴하고 정확합니다.

state로 구성한 지원 기록

문서에 명시된 객체는 ticket.subject, from/text 쌍으로 이루어진 ticket.messages, order.id, amount와 status를 포함한 order.charges, 문장 형태의 refund_policy를 사용합니다. 그러면 중복 청구 사례는 정책을 매번 다시 설명해야 하는 채팅이 아니라, 이 객체를 대상으로 한 Nouls와 Choices의 집합이 됩니다. 금액은 코드에서 이미 알고 있으므로, Jev는 환불을 요청하는 표현인지, 정책 문장이 적용되는지만 판단합니다.

Doom 같은 게임 루프에서 state는 프레임이 아니라 세계를 나타내는 구조화된 텍스트입니다. TypeSafe 데모는 이 텍스트를 초당 약 10회 입력합니다. Wikiracing에서 state은 문서와 후보 링크입니다. 스마트 홈 어시스턴트에서 state은 사용자의 발화와 메모리에 이미 저장된 기기 목록입니다. 어느 데모도 Jev에 픽셀을 전송하지 않습니다.

데이터베이스의 필드가 숫자형이라도 판단 대상이 의미라면("이 색이 경고처럼 보이는가") 이름을 붙인 구간이나 계산된 숫자를 보내고, 16진수 계산은 코드에서 처리하세요. jev-1.13은 영어 색상명에 비해 RGB 삼중값과 16진수 값을 제대로 읽지 못합니다. 날짜도 마찬가지입니다. Choice로 구성 요소를 추출한 뒤 코드에서 비교하세요.

예산과 언어

64k 요청 창에는 state와 모든 질문이 들어갑니다. 32k 창에는 state와 가장 긴 질문 하나가 들어갑니다. 20k 분량의 정책 PDF를 state에 통째로 넣으면 질문 맵을 위한 공간이 거의 남지 않고, 관련 없는 세부 정보로 인한 실패도 발생합니다. 먼저 검색한 뒤 판단에 필요한 두 문단만 보내세요.

현재 정확도가 가장 높은 언어는 영어입니다. 티켓이 일본어나 한국어라면 표본을 실행해 Noul와 Choice confidence를 그래프로 그리고, 그 히스토그램이 영어 결과와 비슷해질 때까지 사람이 검토하도록 하세요. 모델은 해당 텍스트도 처리하며, CJK라는 이유로 알리지 않고 거부하지는 않습니다.

텍스트 배열은 시퀀스용이지, 두 번째 스키마를 숨겨 넣는 용도가 아닙니다. 이름 있는 구성 요소가 필요하면 객체를 사용하세요. 하나의 덩어리만 필요하면 문자열을 사용하세요. 이미지 URL을 문자열에 섞어도 Jev에 시각 기능이 생기지 않으며, Jev가 잘못 읽을 URL 토큰만 추가됩니다. 워커에서 가져와 설명한 뒤 그 설명을 보내세요.

로그에만 필요한 필드는 state에서 제외하세요. 질문 ID가 이미 결합 키 역할을 합니다. State에는 사람으로 구성된 평가단이 읽을 근거만 담아야 합니다. 이 원칙을 지키면 티켓 대화가 길어도 state와 가장 긴 질문을 합친 32k 예산 안에 머물 수 있습니다.

영리한 인코딩보다 이름 있는 필드가 낫습니다. order_id, charges[].status, refund_policy는 사용자와 Jev 모두 읽을 수 있습니다. 같은 사실을 하나로 이어 붙인 문자열도 허용되지만 더 나쁩니다. 문서에 명시된 지원 티켓 객체를 본보기로 삼으세요. ticket, order, policy를 두고, 그 이름을 가리키는 질문을 작성하면 됩니다.

판단에 필요 없는 개인 식별 정보는 제거하세요. Jev은 고객 요청으로 학습되지 않지만, 자체 로그에는 여전히 해당 정보가 남습니다. state을 줄이면 jaggedness 문제를 해결하는 동시에 개인정보 보호에도 도움이 됩니다.

텍스트 배열은 이름 있는 슬롯의 집합이 아니라 시퀀스입니다. 이름이 필요하면 객체를 사용하세요.