SeniMate Slot¶

dm/scenario/senimate_weather.json 기준의 현재 슬롯 설계입니다.

전역 slots registry¶

Slot	Policy	Type	Values	의미
`daily_life`	optional	string	—	일상 안부와 생활 상태
`meal_status`	optional	enum	`adequate`, `skipped`	식사 섭취 상태
`health_status`	optional	enum	`adequate`, `complaint`	건강 상태
`pain_level`	optional	enum	`none`, `mild`, `moderate`, `severe`	통증·불편 정도
`health_issue`	optional	string	—	건강 관련 이슈 또는 불편한 점
`symptom`	optional	string	—	사용자가 말한 증상

전역 slots는 정의 registry이고 실제 수집 대상은 각 노드의 collect_slots가 결정합니다.

노드별 수집 대상¶

Node	collect_slots	Executor
`greeting_introduction`	—	`SkillExecutor`
`daily_life_check`	`daily_life`	`TaskOrientedExecutor`
`meal_check`	`meal_status`	`TaskOrientedExecutor`
`health_check`	`health_status`, `pain_level`, `health_issue`, `symptom`	`TaskOrientedExecutor`
`general_conversation`	—	`GeneralResponseExecutor`
`conversation_closure`	—	`GeneralResponseExecutor`

6개 슬롯은 각각 하나의 수집 노드에 배정되어 있습니다.

Slot 의미와 NLU 경계¶

daily_life¶

인정 범위가 넓습니다.

기분과 하루 상태
날씨에 대한 생활 반응
심심함·무료함
수면
외출과 소일거리
만나는 사람
TV·라디오 등 활동

일상 발화를 식사나 건강 슬롯으로 옮기지 않습니다.

meal_status¶

직전 질문이 식사 주제일 때만 채웁니다.

음식명, 먹었다, 챙겨 먹었다 → adequate
안 먹었다, 못 먹었다, 거름  → skipped

일상·기분 답변은 meal_status로 저장하지 않습니다.

health_status¶

괜찮다, 문제 없다 → adequate
아프다, 불편하다  → complaint

pain_level¶

통증·불편·피로의 정도를 나타냅니다.

부정 형태의 확인 질문에 사용자가 동의하거나 “없어”, “괜찮아”라고 답하면 none을 우선 고려합니다.

health_issue와 symptom¶

건강 불편이 있을 때만 수집합니다.

health_issue: 불편한 부위나 건강 문제
symptom: 피로, 졸음, 눈 피로처럼 사용자가 말한 증상

이미 말한 증상을 두고 새로운 증상 목록을 확장해 묻지 않습니다.

Optional 정책의 의미¶

6개 슬롯은 모두 optional이므로 blocking_missing은 항상 비어 있습니다.

영향	현재 동작
`missing_slots`	required 미수집 경로이므로 발생하지 않음
`turn_limit_blocking`	발생하지 않음
일반 진행	슬롯이 없어도 진행 가능
체류 보완	세 수집 노드의 `min_turns=2`
명시적 optional 포기	“모르겠다/기억 안 난다”면 `optional_abandoned` 가능

Task dialog act 중 question, request, request_alt, repeat, help, correct는 required 슬롯 여부와 무관하게 동작합니다. silence와 null은 executor 이전의 FallbackPolicy가 처리합니다.

Routing에서 사용하는 슬롯¶

Health self-loop¶

{
  "and": [
    {"field": "slots.health_status", "operator": "equals", "value": "complaint"},
    {"field": "slots.symptom", "operator": "is_empty"},
    {"field": "slots.health_issue", "operator": "is_empty"}
  ]
}

불편하다고 했지만 증상과 이슈를 모두 못 들었으면 health_check에 머뭅니다.

Closure resume¶

마무리 노드에서 system.conversation_resuming=true이면 conversation_closure.next_nodes가 다음 슬롯의 미수집 여부를 순서대로 봅니다.

slots.daily_life is_empty   → daily_life_check
slots.meal_status is_empty  → meal_check
slots.health_status is_empty → health_check
그 외                       → general_conversation

pain_level, health_issue, symptom은 마무리 재개 단계 선택에는 직접 사용하지 않습니다.

Slot 값이 채워지는 경로¶

경로	Source	설명
현재 수집 대상 entity	`nlu`	정상 경로
현재 대상 밖 entity	`nlu_auto` / `nlu_refilled`	NLU가 함께 추출한 값
짧은 긍정·부정 추론	`affirm_inferred` / `deny_inferred`	entity가 없을 때 첫 미수집 슬롯

현재 SlotUpdatePolicy는 collect_slots 밖의 entity도 저장할 수 있습니다. NLU prompt의 주제-slot guard가 중요한 이유입니다.

암묵 추론 주의점¶

infer_implicit_slot_value()는 node condition에서 값을 찾지 못하면 다음 기본값을 사용합니다.

affirm → adequate
deny   → skipped

Slot	허용값과의 정합성
`meal_status`	일치
`health_status`	`skipped`는 허용값 아님
`pain_level`	두 기본값 모두 허용값 아님
`daily_life`	string이지만 의미가 부자연스러움

첫 미수집 슬롯 하나만 추론하므로 현재 health_check에서는 보통 health_status가 먼저 대상이 됩니다. 런타임은 enum values를 저장 시 강제하지 않으므로 개선이 필요한 공통 정책입니다.

completion_slots¶

health_check는 다음 값을 선언합니다.

{
  "completion_slots": ["health_issue", "symptom"]
}

현재 사용:

NLU 입력 context
기대 슬롯 로깅

현재 사용하지 않는 곳:

TaskPolicyPipeline의 완료 판정

즉 건강 불편 시 최소 하나를 듣게 하는 실제 보장은 node self-loop condition이 담당합니다.

개선 후보¶

Slot별 implicit answer mapping을 schema로 명시
Enum values를 state 저장 전에 검증
completion_slots를 실제 task 완료 정책과 연결하거나 제거
collect_slots 밖 entity 자동 저장 범위 제한