← Docs hub

A2A RL-Like Feedback Improvement Opportunities

이 문서는 A2A Planner/Orchestrator/TaskManager 구조에서 강화학습과 유사한 개선 루프를 어디에 붙일 수 있는지 기획/구조 관점으로 정리한다.

중요한 전제는 아래다.

현재 단계에서 말하는 RL은 “바로 온라인 강화학습으로 기기 행동을 학습시킨다”가 아니다. A2A의 판단, 실행, 실패, 사용자 반응을 state -> action -> feedback -> policy update 루프로 기록하고, 안전한 영역부터 offline evaluation, contextual bandit, human feedback 기반 calibration으로 서비스 품질을 개선하는 구조다.

즉, A2A에서의 강화학습 유사 구조는 아래처럼 봐야 한다.

state:
  recognized_text, voice_context, workflow_context, device_context,
  memory_context, capability_registry, ranked_top_flows

action:
  route family 선택, agent/skill 선택, ask/execute/deny,
  second-pass 실행 여부, follow-up 질문, device workflow plan,
  replan/abort/retry/ask_user 결정

feedback:
  사용자 correction, follow-up 성공 여부, task completed/failed,
  cancellation, retry, latency, route benchmark label,
  TaskManager reason_code, proactive suggestion accept/reject

policy update:
  prompt/axis/cue 조정, registry 우선순위 보정,
  second-pass gate 조정, follow-up strategy 조정,
  proactive gate threshold 조정, memory promotion policy 조정

1. 왜 A2A는 RL-like 개선에 적합한가

A2A는 이미 “판단 -> 실행 -> 결과” 구조를 갖고 있다.

따라서 별도 RL 시스템을 먼저 만들지 않아도, A2A event와 benchmark를 잘 설계하면 “정책 개선 루프”를 만들 수 있다.

2. 가장 중요한 개선 공간

2.1 Route Family 정책 개선

가장 현실적인 1순위다.

현재 우리가 많이 다룬 경계는 아래다.

DEF <-> STT_NULL
ODL <-> SCH
DQR <-> FRG
UNS <-> DEF/FRG
STT_NULL <-> ODL

이 경계는 reward signal을 만들기 좋다.

적용 방식은 곧바로 모델 학습이 아니라 아래 순서가 안전하다.

1. interaction trace에 route decision과 user outcome을 기록한다.
2. family transition error와 user correction pattern을 모은다.
3. 정답지/benchmark와 online feedback을 분리해서 본다.
4. prompt/cue/second-pass gate 후보를 offline replay로 비교한다.
5. 충분히 안전한 변경만 배포한다.

2.2 Ask vs Execute 정책 개선

기기 제어에서는 “바로 실행할지, 되물을지”가 핵심이다.

사용자: 거실
현재 schedule workflow active: yes -> slot answer로 수용
현재 workflow 없음: no -> follow-up 또는 STT_NULL

이 판단은 contextual bandit 문제로 볼 수 있다.

여기서 중요한 reward는 단기 정확도만이 아니다.

wrong device execution penalty > unnecessary clarification penalty

즉, 실행형 family에서는 과실행 penalty를 크게 둬야 한다. 반면 대화형 DEF에서는 과차단 penalty가 커진다.

2.3 Second-Pass Gate 개선

second_pass_family_judge, replyability_judge, object_typer는 비용이 있는 판단이다. 매번 돌리면 latency와 token cost가 증가하고, 너무 적게 돌리면 회색지대가 흔들린다.

개선 목표:

필요한 애매한 케이스에는 second pass를 열고,
명확한 specialist anchor가 있는 케이스에는 second pass가 방해하지 않게 한다.

RL-like feedback:

적용 방식:

• 당장은 needs_second_pass gate를 rule로 고정하기보다, trace 기반으로 “second pass가 실제로 도움이 된 조건”을 분석한다.
• 조건은 발화 원문이 아니라 runner_up, confidence, stt_null_subtype, replyability, target_scope, specialist_anchor 같은 의미 feature를 사용한다.

2.4 Follow-up Question Strategy

멀티턴 schedule, device target, STT_NULL_SOFT에서 어떤 질문을 던질지도 학습 가능한 영역이다.

구체적인 정책, 문구 원칙, feedback metric은 A2A Follow-up Question Strategy에서 별도로 관리한다.

예:

어느 공간을 청정할까요?
몇 시에 실행할까요?
다시 한 번 말씀해 주세요.
거실 청정을 말씀하신 걸까요?

좋은 follow-up은 사용자가 짧게 답해도 slot이 채워진다. 나쁜 follow-up은 사용자를 다시 길게 말하게 만든다.

feedback:

기획적으로는 follow-up 문구를 A/B test하기 좋다. 단, 기기 실행과 연결된 경우에는 사용자 안전을 우선해야 한다.

2.5 TaskManager Replan Policy

TaskManager event/reason은 RL-like feedback의 가장 좋은 source다.

예:

{
  "eventName": "FAILED",
  "taskMethod": "setMoveTo",
  "reason_code": "PATH_BLOCKED",
  "requires_cloud_decision": true
}

Cloud Planner는 이 feedback을 보고 다음 action을 고른다.

개선 루프:

reason_code
-> replan action
-> user response / task outcome
-> reason-action success table
-> replan policy 개선

이 영역은 안전하게 시작할 수 있다. 왜냐하면 학습 대상이 “무슨 일을 새로 실행할까”가 아니라 “실패 상황에서 어떤 복구 정책이 잘 먹혔는가”이기 때문이다.

2.6 Proactive Suggestion Gate

향후 proactive 영역은 RL-like 구조가 특히 잘 맞는다.

state:

battery_delta
movement_failures_recent
cleaning_frequency_by_room
time_of_day
air_quality_delta
user_recent_acceptance

action:

제안하지 않음
가벼운 알림
확인 질문
자동 실행 후보 제시
즉시 실행

feedback:

accepted
ignored
rejected
cancelled
disabled_proactive
later_success

초기 정책은 반드시 보수적이어야 한다.

suggestion > confirmation > execution

사용자 신뢰가 쌓이기 전에는 자동 실행보다 “제안”과 “확인”에 reward를 모으는 것이 안전하다.

2.7 Memory Promotion Policy

memory/personalization에서도 RL-like 개선 공간이 있다.

문제:

한 번 말한 선호를 long-term profile로 저장하면 오염된다.
너무 보수적으로 저장하면 개인화가 안 된다.

policy action:

저장하지 않음
short-term만 저장
mid-term candidate로 승격
long-term candidate 생성
사용자 확인 후 long-term confirmed

feedback:

이건 classical RL보다는 preference learning / bandit / policy threshold calibration에 가깝다.

3. A2A의 RL-like telemetry schema

개선 루프를 만들려면 먼저 trace를 표준화해야 한다.

3.1 Planner decision trace

{
  "trace_id": "a2a-turn-001",
  "session_id": "session-1",
  "recognized_text": "거실 청정 예약해줘",
  "state_features": {
    "last_route": "SCH",
    "active_workflow": "schedule_create",
    "device_context_available": true,
    "memory_context_available": true,
    "top_ranked_flows": ["SCH.SCH.schedule_create", "ODL.ODL.device_execution"]
  },
  "policy_decision": {
    "selected_family": "SCH",
    "selected_agent": "SCH",
    "selected_skill": "schedule_create",
    "turn_mode": "multi_turn",
    "ask_follow_up": true,
    "missing_slots": ["time"]
  },
  "cost": {
    "planner_latency_ms": 1200,
    "llm_calls": 1,
    "second_pass_used": false
  }
}

3.2 Outcome feedback trace

{
  "trace_id": "a2a-turn-001",
  "outcome": {
    "user_followed_up": true,
    "slot_filled": true,
    "task_created": true,
    "task_completed": null,
    "user_corrected": false,
    "user_cancelled": false
  },
  "feedback_score": {
    "task_success": 1.0,
    "clarification_quality": 1.0,
    "wrong_execution_penalty": 0.0,
    "latency_penalty": -0.1,
    "overall": 0.9
  }
}

이 score는 처음부터 모델 학습에 쓰지 않아도 된다. 우선 dashboard와 offline comparison에 쓰면 된다.

4. 적용 가능한 개선 루프

4.1 Offline replay loop

가장 안전하다.

기존 benchmark / live trace
-> 후보 prompt/cue/registry 변경
-> offline replay
-> family transition 비교
-> 안전성 gate 통과 시 배포

장점:

• 실제 사용자에게 위험하지 않다.
• 정답지와 trace를 동시에 비교할 수 있다.
• prompt/axis 변경의 부작용을 family별로 볼 수 있다.

4.2 Human review feedback loop

현재 우리가 수동으로 하던 정답지 검수를 제품화하는 방향이다.

low-confidence / high-cost / high-risk mismatch
-> reviewer label
-> label reason
-> benchmark update
-> axis guideline update

여기서 중요한 것은 단순 정답 family만 저장하지 않는 것이다.

review_label = ODL
review_reason = "하이나무 + 공간명 + device target"
boundary = "ODL vs STT_NULL"
policy_note = "assistant call + room anchor는 ODL recovery candidate"

이 reason이 있어야 다음 축 조정이 룰베이스가 아니라 semantic policy가 된다.

4.3 Contextual bandit loop

중간 단계로 적합하다. 전체 sequence RL보다 안전하고 단순하다.

적용 후보:

• ask vs execute
• second-pass 실행 여부
• follow-up 문구 선택
• proactive 제안 강도
• route family candidate ranking

제약:

• device execution family는 safety guardrail 아래에서만 실험한다.
• 자동 실행 action은 초기에 bandit 대상에서 제외하고, “질문/제안/설명” action부터 시작한다.

4.4 Offline RL / simulator loop

장기 방향이다.

조건:

• 충분한 trace가 쌓여야 한다.
• device/task simulator 또는 replay environment가 있어야 한다.
• reward hacking을 막는 safety constraint가 있어야 한다.

적용 후보:

• 복합 task sequencing
• failure recovery policy
• proactive timing
• long-horizon personalization

현 시점에서는 바로 제품에 적용하기보다 연구/시뮬레이터 과제로 분리하는 것이 안전하다.

5. Reward 설계 원칙

5.1 실행형 AI에서는 penalty 비대칭이 필요하다

wrong execution penalty
  > unnecessary clarification penalty
  > slightly verbose answer penalty

특히 ODL/TaskManager 실행은 잘못되면 실제 기기가 움직인다. 따라서 STT_NULL이나 clarification이 약간 많아지는 것보다 잘못된 실행이 더 큰 손실이다.

5.2 reward는 family별로 다르게 둔다

5.3 사용자 만족만 reward로 쓰면 위험하다

사용자가 “그냥 해줘”라고 해도 안전하지 않은 실행은 막아야 한다. 따라서 reward는 아래를 함께 봐야 한다.

user satisfaction
+ task success
+ safety constraint
+ privacy constraint
+ latency/cost
+ explainability

6. 제품화 로드맵

Phase 0. Trace만 남긴다

목표:

• 학습하지 않는다.
• state/action/outcome schema를 고정한다.
• benchmark와 live trace를 같은 관점으로 본다.

필요 작업:

• Planner decision trace 표준화
• TaskManager event feedback 연결
• user correction/cancel/retry signal 수집
• family transition dashboard

Phase 1. Offline calibration

목표:

• 기존처럼 수동 축 조정을 하되, trace와 benchmark로 재현 가능하게 만든다.

필요 작업:

• prompt/cue/registry 변경별 offline replay
• family별 confusion/transition 비교
• “정답지 변경”과 “정책 변경” 분리
• reviewer reason schema 도입

Phase 2. Safe contextual bandit

목표:

• 실행 위험이 낮은 선택부터 bandit으로 개선한다.

대상:

• follow-up 문구
• second-pass 실행 gate
• proactive suggestion wording
• non-device response style

제외:

• 자동 기기 실행
• safety-critical device action
• privacy-sensitive memory promotion

Phase 3. Task recovery policy learning

목표:

• TaskManager failure reason에 따른 recovery action을 개선한다.

대상:

• PATH_BLOCKED -> ask user / retry / abort
• LOW_BATTERY -> charge first / continue / shrink plan
• ROOM_NOT_FOUND -> room clarification

필요:

• reason_code별 outcome table
• retry success rate
• user acceptance/rejection signal

Phase 4. Proactive policy optimization

목표:

• context delta와 user acceptance를 기반으로 proactive suggestion timing을 개선한다.

주의:

• 자동 실행보다 제안/확인 중심으로 시작한다.
• user fatigue penalty를 반드시 둔다.
• 사용자가 끄기/줄이기를 선택하면 강한 negative feedback으로 반영한다.

7. 현재 구조에서 바로 추가해야 할 산출물

8. 우리가 피해야 할 것

9. 결론

A2A에서 강화학습과 유사한 개선 공간은 충분하다. 다만 제품 관점의 안전한 순서는 아래다.

1. Trace / feedback schema 고정
2. Offline benchmark replay와 human review loop
3. Semantic decision boundary calibration 자동화 보조
4. Low-risk contextual bandit
5. Task failure recovery policy 개선
6. Proactive suggestion gate 최적화
7. Simulator 기반 offline RL 연구

가장 먼저 할 일은 모델 학습이 아니라, “좋은 판단/나쁜 판단”을 나중에 학습 가능한 형태로 기록하는 것이다. 현재 A2A의 Planner, Runtime, TaskManager, Memory 구조는 이미 이 루프를 만들 수 있는 관측점과 action point를 가지고 있다.