← Docs hub

Speaker Identity Service Scenarios

화자 분리/인식은 단독 기능으로 출시하기보다, 기존 음성 기능의 정확도와 안전성을 높이는 context layer로 확장하는 편이 가치가 크다. 이 문서는 서비스 시나리오를 기능별로 정리한다.

1. 단일 화자 안전 실행

시나리오:

사용자: 거실 청정해줘
speaker_state: identified
speaker_count: 1
safety_gate: pass

처리:

1. STT와 speaker identification이 모두 안정적이다.
2. 온디바이스 dictionary 또는 Cloud A2A가 기능을 분류한다.
3. ApiCallValidator/Device API를 거쳐 기능을 실행한다.
4. memory_update는 해당 speaker의 short-term 기록으로 저장된다.

서비스 효과:

• 오작동 감소
• 사용자별 기록 연결
• “내 방”, “평소처럼” 같은 표현의 확장 기반

2. 다화자/겹침 차단

시나리오:

두 명 이상이 동시에 말함
speaker_state: overlap 또는 multi_speaker
safety_gate: reprompt/block

처리:

1. DiarizationEngine이 여러 speaker segment를 감지한다.
2. overlap ratio 또는 speaker count가 threshold를 넘는다.
3. 온디바이스는 기능 실행 대신 재시도 안내를 한다.
4. Cloud A2A로 보내더라도 side-effect task는 금지한다.

서비스 효과:

• 가족 구성원 간 동시 발화로 잘못된 명령 실행 방지
• TV/주변 대화로 인한 오동작 방지

3. 개인화 명령

시나리오:

사용자: 내 방 청정해줘
speaker_id: user_001
profile: my_room_alias = 안방

처리:

1. speaker confidence가 충분한지 확인한다.
2. memory_context.long_term.profile_items에서 speaker scope의 alias를 찾는다.
3. “내 방”을 “안방”으로 해석한다.
4. 전체 기능 실행은 기존 ODL/온디바이스 경로를 따른다.

주의:

• confidence가 낮으면 “어느 공간을 청정할까요?”로 확인해야 한다.
• profile 적용 여부를 로그에 남긴다.

4. 권한 기반 제한

시나리오:

guest: 홈 잠금 꺼줘
authority_level: guest

처리:

1. speaker가 guest 또는 unknown으로 판단된다.
2. 기능이 보안/잠금/개인 기록/스케줄 관리처럼 권한이 필요한지 확인한다.
3. 바로 실행하지 않고 제한 안내 또는 보호자 확인을 요구한다.

서비스 효과:

• 민감 기능 보호
• 가족 구성원별 권한 차등 적용

5. 복합명령 소유자 관리

시나리오:

아빠: 거실 청정하고 10분 뒤에 침실로 와
아이: 그거 취소해

처리:

1. 첫 발화에서 workflow_owner_speaker_id = 아빠를 기록한다.
2. Task Manager는 step workflow를 생성한다.
3. 후속 취소 발화가 다른 speaker에서 오면 takeover/confirmation 정책을 적용한다.
4. 권한이 허용되면 취소하고, 아니면 workflow owner 확인을 요청한다.

서비스 효과:

• 복합명령 실행 중 다른 사람이 끼어드는 상황 제어
• 장시간 task의 책임 주체 명확화

6. 감정/긴급성 확장 후보

화자 인식과 직접 동일하지는 않지만, 같은 audio context 계층에서 확장 가능한 영역이다.

후보:

• 발화 속도 증가
• 에너지 상승
• 반복 호출
• 비정상적으로 짧은 명령
• 특정 speaker의 평소 패턴과 다른 발화

서비스 예:

• “도와줘”가 특정 고령 사용자에게서 긴급하게 들어오면 Safe Care/보호자 알림 후보로 분류
• 일반 대화와 긴급 요청을 분리

주의:

• 감정 추정은 보조 신호로만 사용해야 한다.
• 의료/안전 판단을 단정하면 안 된다.