Speaker Identity Test Plan
이 문서는 화자 분리/인식 PoC를 서비스 레벨로 확장할 때 필요한 테스트 축을 정리한다. 테스트는 모델 정확도만 보지 않고, STT/diarization/identification/safety gate/Cloud A2A/memory/task manager를 단계별로 검증해야 한다.
1. 테스트 계층
| 계층 | 검증 항목 | 성공 기준 |
|---|---|---|
| Audio input | sample rate, mono/stereo 변환 | 16kHz FloatArray 입력 정합성 |
| Diarization | speaker count, segment boundary | 단일/다화자 구분 |
| Identification | speaker score, threshold | 등록 화자 accepted, unknown rejected |
| Stability | session/recent boost | 연속 턴 흔들림 감소 |
| Safety gate | far/overlap/too many/low confidence | 위험 상황 실행 차단 |
| Cloud contract | speaker_context payload | 필드 누락 없이 전달 |
| Memory | speaker별 기록 분리 | 잘못된 사용자 기록 오염 없음 |
| Task Manager | owner/authority/side-effect gate | 다른 speaker의 변경/취소 통제 |
2. 온디바이스 PoC 테스트
테스트 케이스:
| 케이스 | 입력 | 기대 |
|---|---|---|
| 등록 화자 1명 | 같은 사람 WAV 5개 | 등록 성공 |
| 미등록 화자 | 다른 사람 발화 | unknown |
| 동일 화자 연속 발화 | 20초 내 같은 speaker | stability boost 적용 |
| 3명 이상 | speakerCount >= 3 | too many 안내 |
| 겹침 | overlapRatio >= 0.35 | overlap 안내 |
| 먼 거리 | rms/hf_ratio 조건 | distance 안내 |
3. Cloud A2A 계약 테스트
확인 항목:
speaker_context.contract_version존재speaker_state값이 enum 범위인지speaker_confidence가 0~1 범위인지personalization_allowed=false일 때 memory profile을 사용하지 않는지safety_gate=block일 때 side-effect task가 생성되지 않는지
4. 메모리 분리 테스트
시나리오:
user_001: 내 방 청정해줘 -> 안방
user_002: 내 방 청정해줘 -> 아이방
unknown: 내 방 청정해줘 -> 어느 공간인지 확인
검증:
- short-term pair가 speaker별로 분리되는지
- profile candidate가 speaker_id를 포함하는지
- unknown speaker가 다른 speaker profile을 읽지 않는지
- 삭제 시 해당 speaker history/profile이 제거되는지
5. 복합명령 owner 테스트
시나리오:
user_001: 거실 청정하고 10분 뒤에 침실로 와
user_002: 그거 취소해
기대:
- workflow owner는
user_001 user_002의 취소 요청은 바로 실행하지 않음- confirmation 또는 owner takeover 정책으로 분기
6. 릴리즈 게이트
릴리즈 전 최소 조건:
- 등록/인식/unknown/다화자/겹침/먼거리 케이스 통과
- speaker_context payload schema 검증
- memory read/write speaker scope 검증
- Task Manager side-effect gate 검증
- 개인정보 로그 금지 항목 스캔
- 한국어/영어 안내 문구 확인