← Docs hub

A2A Follow-up Question Strategy

이 문서는 A2A Planner가 언제 사용자에게 follow-up을 물어야 하는지, 어떤 형태로 물어야 하는지, 그리고 그 결과를 어떻게 feedback으로 쌓아 서비스 개선에 활용할지 정리한다.

핵심 원칙은 아래다.

Follow-up은 “못 알아들어서 다시 묻는 것”이 아니라, 실행 위험을 줄이고 slot을 완성하며 context를 복구하기 위한 정책적 action이다.

따라서 A2A에서 follow-up은 route decision과 같은 수준의 planner action으로 취급해야 한다.

state:
  recognized_text, active_workflow, slot_state, device_context, memory_context

action:
  answer now / execute now / ask follow-up / ask confirmation / retry prompt

outcome:
  slot filled / user corrected / user cancelled / task success / repeated failure

1. Follow-up이 필요한 경우

Follow-up은 크게 6가지 경우에 필요하다.

Follow-up을 하지 않아야 하는 경우도 명확히 둔다.

2. 질문 우선순위

질문은 한 번에 하나의 blocking point만 해결해야 한다. 다만 자연스럽게 두 slot을 같이 물을 수 있으면 한 문장에 묶는다.

우선순위:

1. 안전 확인이 필요한 side effect
2. workflow를 계속할지 취소할지
3. 실행 target
4. 시간/반복 등 schedule semantics
5. action/value parameter
6. 표현/대화 의도 clarification

예:

나쁜 질문:
  어느 방에서, 몇 시에, 반복할지, 어떤 모드로, 정말 실행할지 알려주세요.

좋은 질문:
  무엇을 언제 예약할까요? 예: 고정청정 매일 밤 10시

3. Follow-up 타입별 정책

3.1 Slot Fill Prompt

사용처:

• SCH schedule create/update/delete
• device workflow에서 room/action/value가 빠짐
• active workflow가 missing slot을 기다림

원칙:

• 이미 채운 slot은 다시 묻지 않는다.
• 가장 좁은 missing slot만 묻는다.
• 사용자가 짧게 답해도 채울 수 있게 예시를 준다.
• target과 time이 둘 다 없을 때만 두 개를 같이 묻는다.

예시:

3.2 Scoped Clarification Prompt

사용처:

• STT_NULL_SOFT
• weak device/workflow/public/conversation scope가 남아 있음
• 바로 실행하거나 답변하면 과추론 위험이 있음

원칙:

• 남아 있는 scope를 반영한다.
• 단정하지 않는다.
• “다시 말해달라”보다 좁게 묻는다.

예시:

3.3 Confirmation Prompt

사용처:

• 기기 side effect가 크거나 범위가 넓음
• “전부”, “다”, “전체”, “초기화”, “삭제”, “취소” 등 영향 범위가 큼
• schedule 삭제/수정 target은 있으나 irreversible 느낌이 있음

원칙:

• confirmation은 slot 질문과 다르다.
• 사용자가 “응/아니”로 답할 수 있게 한다.
• 실행할 내용을 구체적으로 반복한다.

예시:

전체 공간 청정을 중지할까요?
등록된 고정청정 스케줄을 삭제할까요?
거실과 안방 청정을 모두 시작할까요?

3.4 Disambiguation Prompt

사용처:

• “그거”, “저거”, “아까 거”가 여러 후보를 가리킴
• 등록된 schedule이 여러 개
• room/target 후보가 여러 개

원칙:

• 후보가 2~3개면 선택지를 제시한다.
• 후보가 많으면 scope부터 좁힌다.
• 후보를 만들 수 없으면 generic clarification으로 떨어뜨린다.

예시:

어떤 스케줄을 삭제할까요? 고정청정, 웰컴, 나이트 모드 중에서 말씀해 주세요.
어느 공간을 말씀하신 걸까요? 거실인가요, 안방인가요?

3.5 Repair Prompt

사용처:

• STT_NULL_HARD 또는 STT_NULL_GENERIC
• target scope가 거의 없음
• whole-intent repair가 필요

원칙:

• STT_NULL_HARD는 plain retry가 낫다.
• STT_NULL_GENERIC은 한 번 더 구체적으로 말해달라고 한다.
• 같은 repair가 반복되면 다른 방식으로 유도한다.

예시:

잘 못 들었어요. 다시 한 번 말씀해 주세요.
요청하신 내용을 조금 더 구체적으로 말씀해 주세요.
기기 동작인지, 스케줄인지 다시 말씀해 주세요.

3.6 Replan Recovery Prompt

사용처:

• TaskManager event가 FAILED, BLOCKED, PAUSED, NEEDS_USER_INPUT 계열
• requires_cloud_decision=true
• reason_code가 사용자 결정이 필요한 상황

원칙:

• 실패 원인을 짧게 설명한다.
• 가능한 다음 action을 1~2개만 제시한다.
• 자동 재시도보다 사용자 결정이 필요한 경우를 구분한다.

예시:

4. Family별 Follow-up 전략

5. Follow-up 문구 원칙

5.1 좋은 follow-up

좋은 follow-up은 아래 조건을 만족한다.

• 짧다.
• 하나의 blocking point만 묻는다.
• 사용자가 한두 단어로 답해도 slot이 찬다.
• 시스템이 아는 slot은 다시 묻지 않는다.
• 실행될 내용을 과하게 추정하지 않는다.
• 기기 실행이면 side effect를 명확히 말한다.

예:

언제 예약할까요? 예: 매일 밤 10시
어느 공간을 청정할까요?
전체 공간 청정을 중지할까요?

5.2 나쁜 follow-up

나쁜 follow-up은 아래와 같다.

• 이미 아는 정보를 다시 묻는다.
• 여러 질문을 한 번에 던진다.
• 사용자가 길게 설명해야 답할 수 있다.
• system assumption이 너무 강하다.
• 실행 여부와 정보 수집 질문이 섞인다.

예:

정확한 작업 대상과 시간과 반복 여부와 모드 값을 모두 알려주세요.
거실 청정을 예약하시는 게 맞나요? 몇 시에 할까요? 매일인가요?

6. Follow-up Feedback Metric

Follow-up 전략은 감으로 정하면 안 된다. 아래 지표를 남겨야 한다.

6.1 Outcome trace 예시

{
  "trace_id": "a2a-followup-001",
  "follow_up": {
    "type": "slot_fill",
    "family": "SCH",
    "asked_slot": ["time"],
    "prompt": "언제 예약할까요? 예: 매일 밤 10시"
  },
  "next_turn_outcome": {
    "user_text": "매일 밤 10시",
    "slot_filled": ["repeat", "time"],
    "workflow_completed": true,
    "user_corrected": false,
    "user_cancelled": false
  },
  "score": {
    "slot_fill_success": 1.0,
    "turn_cost": -0.1,
    "overall": 0.9
  }
}

7. Follow-up Policy State Machine

START
  -> current utterance self-sufficient?
       yes -> answer/execute
       no
  -> active workflow exists?
       yes -> continuation/correction/cancel/topic-shift 판단
       no
  -> missing slot exists?
       yes -> slot fill prompt
       no
  -> weak scope survives?
       yes -> scoped clarification
       no
  -> STT collapse?
       hard -> retry prompt
       generic -> generic clarification
  -> unsupported?
       yes -> unsupported explanation or alternative

8. 적용 우선순위

9. 현재 소스와 연결되는 지점

10. 결론

Follow-up 전략의 목표는 질문을 많이 하는 것이 아니다.

필요한 순간에,
가장 좁은 질문으로,
다음 turn에서 slot이나 intent가 확정되게 만들고,
잘못된 device execution을 막는 것

이 전략을 feedback trace와 연결하면 follow-up 자체가 서비스 개선 대상이 된다. 즉, 어떤 질문이 slot을 잘 채우는지, 어떤 질문이 사용자를 취소하게 만드는지, 어떤 질문이 과실행을 막았는지를 데이터로 볼 수 있다.