Laya 실전 ③: 상태 설계 — JSON, 이메일, 대화, 잘림

dict는 JSON으로 직렬화되어 읽힌다 (예제 11)

dict 상태는 json.dumps(state, ensure_ascii=False)로 직렬화되고, 그 JSON 텍스트가 모델이 읽는 상태가 됩니다. 덕분에 중첩 필드를 가진 주문 레코드를 그대로 넣고 필드에 대해 물어볼 수 있습니다. 단, 텍스트라는 사실도 그대로 적용됩니다: 깊게 중첩된 모호한 필드는 평평한 상태 문자열보다 어렵습니다.

같은 사실, 세 가지 글쓰기 (예제 12)

같은 "이중 결제" 클레임을 ① 한 줄 티켓, ② 서명과 인사말이 달린 이메일, ③ 구조화된 JSON 레코드로 써서 같은 세 질문을 던집니다. department와 refund_requested는 세 버전 모두에서 흔들리지 않지만, churn_risk는 0.5 라인을 넘어갑니다.

이유는 미묘합니다. JSON 레코드는 "해지하겠다"를 문장이 아니라 account_action_if_unresolved: "cancel plan"이라는 조건부 필드로 담고 있고, 인코더에게 그것은 협박이 아니라 필드처럼 읽힙니다. "JSON이 더 나쁘다"가 아니라 필드 이름도 텍스트이며, 구조가 결정에 조용히 개입한다는 뜻입니다. 중요한 답이라면 명시적으로 묻고 confidence를 확인하세요.

이메일은 정리하고 시작한다 (예제 13)

laya.email_state(subject, body, sender)는 상태 dict를 만들어주며, 기본적으로 clean_email_body()로 인용 과거("On ... wrote:" 이후), >로 시작하는 인용 라인, 서명 블록, 기밀 안내문을 걷어냅니다.

정당한 청구 문의에서는 원문이든 정리본이든 같은 판정이 나오고, 정리본이 입력 토큰만 아낍니다. 그런데 무해한 인용 답장이 달린 피싱 미끼에서는 원문 상태가 떠들썩한 인용문과 안내문에 묻혀 billing으로 라우팅됩니다. 정제하면 미끼 자체가 지분을 차지하고 category가 security로, 피싱 확률이 크게 올라갑니다.

같은 메일, 실질적으로 다른 결정 — 정리는 정확도만이 아니라 판단의 방향을 지켜줍니다.

대화는 통째로 상태가 된다 (예제 14)

python

turns = [
    {"role": "user",  "content": "This is the third time I contacted you..."},
    {"role": "agent", "content": "I am sorry for the delay..."},
    {"role": "user",  "content": "I want a full refund today or I am cancelling."},
]
answers = agent.predict(turns, questions)["answers"]  # 대화 전체를 한 번에 판정

요약 단계도, 점점 커지는 프롬프트도 없이 대화 전체의 흐름을 한 번에 판정합니다. 잔잔한 문의와 2차 실패 후 환불 요구와 해지 협박으로 끝나는 동일한 건을 비교하면 noul 세 개가 모두 뒤집히고 escalation score가 2 부근("확실히 화남"과 "격노" 사이)까지 올라갑니다. 새 메시지가 올 때마다 재실행할 수 있는 대화 단위 결정이라는 뜻입니다.

잘림은 답에서 보이지 않는다 (예제 15)

모든 호출은 고정 창을 씁니다: 전체 max_len 토큰 중 질문과 옵션 헤드가 head_max_len까지 가져가고, 상태는 남은 만큼만 가져갑니다. 넘치는 상태는 앞부분만 남고 잘립니다. 예제 15는 첫 문장에 핵심 사실, 마지막 줄에 다른 핵심 사실을 심은 문서로 증명합니다. 앞부분 근거 질문은 제대로 답하고, 마지막 줄에만 근거가 있는 '해지 협박' 질문은 잘린 덕에 확신에 찬 틀린 답을 합니다(confidence까지 높게).

잘림은 usage에만 기록됩니다: truncated, state_tokens, state_tokens_dropped, truncated_questions. 창을 넓히는 방법과, 상태 타입에 따라 잘리는 쪽이 달라지는 화제(리스트는 뒷부분이 보존됩니다)는 ⑧편에서 이어집니다.

다음 편: 호출의 실제 비용, 질문 배칭, 그리고 answer_confidence 게이트 (예제 16–19).