카드 발급 신청 Dialog Act¶

dm/scenario/card_issuance.json과 현재 공통 runtime 기준입니다. 전체 enum은 Dialog act 정의를 참고합니다.

사용 위치¶

Card issuance scenario는 node condition에서 dialog act를 직접 사용하지 않습니다. Act는 다음 공통 계층에서 소비됩니다.

Global policy
Task dialog-act router
Implicit slot 추론
NLG speech-act rule
종료 intent 보정

주요 act별 동작¶

Act	카드 신청에서의 역할
`inform`	이름, 소득, 주소 등 일반 정보 제공
`affirm`	약관 동의·신청 진행 긍정, implicit `yes` 후보
`confirm`	명시적 확인, implicit 긍정 후보
`deny`, `negate`	약관·신청 거부 또는 직전 질문 부정
`correct`	앞서 입력한 카드·소득·주소 정정
`question`	상품, 수집 이유, 배송 방식 등에 대한 질문
`request`	취소나 설명 요청
`request_alt`	다른 카드·배송 방식·대안 요청
`repeat`	직전 질문 반복
`help`	진행 방법 설명 요청
`greeting`	인사
`thank`	감사
`goodbye`	작별 화법
`silence`	무응답 fallback
`null`	이해 불가 fallback

긍정 응답¶

affirm / confirm

짧은 “네”는 현재 node에 따라 의미가 다릅니다.

Current node	기대 slot
`final_confirmation`	`terms_agreed=yes`
`process_application`	`application_confirmed=yes`
다른 수집 node	직전 질문의 정보에 대한 긍정일 뿐, 임의 slot 값 생성 금지

NLU prompt는 직전 질문을 보고 동의 slot 하나만 채우도록 지시합니다.

부정 응답¶

deny / negate

Current node	“아니요” 해석
`select_card_type`	카드 선택 거절 또는 정정, 취소로 단정하지 않음
`income_verification`	직장·근무 정보 부정 또는 정정
`final_confirmation`	`terms_agreed=no`, 신청 취소
`process_application`	`application_confirmed=no`, 신청 취소

부정 act 자체가 global cancellation을 일으키는 것은 아닙니다. NLU intent 또는 slot condition이 routing을 결정합니다.

정정¶

correct는 사용자가 기존 정보를 바로잡는 발화입니다.

“골드 말고 일반카드로 할게요”
“연소득은 천이 아니라 삼천만원이에요”
“배송지는 회사가 아니라 집이에요”

Task policy는 사용자 정정을 우선 처리하도록 NLG에 지시합니다. Slot entity가 다시 추출되면 기존 값이 nlu_refilled source로 갱신될 수 있습니다.

현재 scenario에는 최종 확인 node에서 특정 수집 node로 되돌아가는 수정 transition은 없습니다. 정정이 정상 반영되려면 NLU가 수정 slot entity를 직접 반환해야 합니다.

질문¶

question이면 필요한 slot 질문을 반복하기 전에 사용자 질문에 답해야 합니다.

질문 예	답변 범위
왜 생년월일이 필요한가요?	신청 정보 확인 목적, 주민등록번호는 수집하지 않음
골드카드 혜택은요?	scenario에 선언된 적립·라운지 범위
빠른배송 비용은요?	3천원, 1~2일
이게 실제 승인인가요?	간이 사전 심사이며 실제 승인이 아님

Scenario에 없는 상품 혜택, 신청번호, 승인일, 배송일을 만들어 답하면 안 됩니다.

request와 request_alt¶

Act	예	처리
`request`	“신청 취소해주세요”	취소 intent와 함께 global routing
`request`	“설명해주세요”	현재 단계 설명 후 수집 재개
`request_alt`	“다른 카드도 알려주세요”	선언된 카드 대안 설명
`request_alt`	“다른 배송 방법은요?”	일반·빠른 배송 비교

Task node에서 사용자 요구 act가 발생하고 같은 턴 slot update가 없다면 dialog-act handler가 먼저 응답하고 현재 node에 머물 수 있습니다.

repeat와 help¶

Act	Runtime 동작
`repeat`	가능한 경우 `last_bot_question` 반복
`help`	현재 node 목적과 필요한 입력을 설명

개인정보 수집 단계에서 help 요청에 주민등록번호나 비밀번호를 추가로 요구하면 안 됩니다.

Silence와 null¶

Act	Fallback 종류	기본 처리
`silence`	`no_input`	공통 무응답 안내
`null`	`not_understood`	공통 이해 불가 안내

두 fallback 모두 LLM이 먼저 현재 맥락에 맞는 응답을 생성합니다. node 문구나 공통 안내는 LLM 호출 실패 때만 쓰는 안전망입니다.

각 수집 node의 max_fallback_retries:

Node	값
`welcome`	2
개인정보·카드·소득·주소·약관	2
`process_application`	1
terminal node	0

Fallback 재시도와 node의 required-slot max_turns는 별도 제한입니다. 재시도 소진 시 context.fallback_exhausted가 설정되고 전역 전이가 application_cancelled로 보냅니다.

ImplicitAnswerPolicy¶

Entity가 없을 때 act로 첫 미수집 slot을 추론할 수 있습니다.

affirm / confirm → positive value
deny / negate    → negative value

yes와 no는 runtime이 인식하는 긍정·부정 문자열이므로 두 동의 slot과 정합성이 있습니다.

주의:

개인정보나 금액 slot에서 짧은 “네”만으로 값을 만들면 안 됩니다.
NLU가 현재 node의 동의 slot을 직접 yes/no entity로 반환하는 것이 가장 안전합니다.
Implicit 추론은 첫 미수집 slot 하나만 대상으로 합니다.

Goodbye와 종료¶

goodbye act만으로 현재 scenario의 global transition이 직접 일치하지는 않습니다.

Scenario routing 조건:

nlu.intent == user_wants_to_end

따라서 작별 표현은 NLU가 user_wants_to_end intent로 분류해야 application_cancelled로 이동합니다. goodbye는 NLG의 작별 화법에는 영향을 줄 수 있습니다.

Terminal node¶

승인, 거절, 취소 node에서:

새 slot을 수집하지 않음
추가 질문을 만들지 않음
정식 승인으로 오인시키지 않음
명시적 transition이 없으면 terminal 판정으로 완료

Terminal node에 들어온 뒤 act가 question이더라도 현재 scenario에는 다시 업무 node로 돌아가는 edge가 없습니다.

현재 주의점¶

Dialog act는 node condition에서 직접 사용하지 않으며 routing은 intent와 slot이 담당합니다.
정정 전용 복귀 edge가 없어 NLU entity refill에 의존합니다.
Enum membership을 state 저장 시 강제하지 않습니다.
goodbye act만 반환하고 종료 intent가 없으면 취소 routing이 보장되지 않습니다.
Terminal response는 node 이동 시점 때문에 사용자가 기대하는 턴보다 늦게 생성될 수 있습니다.

회귀 확인¶

약관 질문의 “네/아니요”가 terms_agreed에 반영됨
최종 신청 질문의 “네/아니요”가 application_confirmed에 반영됨
“골드 말고 일반”이 correct로 처리되고 취소되지 않음
상품·배송 질문에 먼저 답한 뒤 수집을 이어감
repeat가 직전 질문을 복원함
silence/null 재시도 후 required slot 흐름이 유지됨