← Docs hub

A2A Router Axis Tuning Roadmap

이 문서는 A2A Planner의 family routing 성능을 높이기 위해 우리가 실제로 반복한 “축 튜닝” 작업을 로드맵 형태로 정리한다.

핵심은 정답 문자열을 외우게 만드는 것이 아니라, 발화가 어느 의미 경계에 걸리는지 검증셋으로 확인하고, 그 결과를 cue, prompt, system contract, benchmark artifact에 다시 반영하는 closed-loop를 만드는 것이다.

1. 전체 사이클

테스트셋 확정
-> full-run / holdout 실행
-> family별 성능과 오분류 transition 추출
-> 실제 오분류 행 검수
-> 정답지 오류와 router 오류 분리
-> 의미축 재정의
-> cue / prompt / system contract 반영
-> focused set 재검증
-> full-run / holdout 재검증
-> 문서와 artifact 고정

이 사이클은 한 번에 끝나지 않는다. DEF <> STT_NULL, ODL <> SCH, DQR <> FRG, UNS, STM/ETR처럼 경계가 다른 family마다 실패 비용이 다르기 때문에, 전체 정확도만 보지 않고 transition 단위로 반복해야 한다.

2. 1단계: 테스트셋과 정답지 기준 고정

먼저 “무엇을 맞췄다고 볼 것인가”를 고정했다.

중요한 점은 라우터 성능이 낮게 보일 때, 바로 prompt를 고치지 않았다는 것이다. 먼저 정답지가 최신 정책과 맞는지 확인했다.

예를 들어 최신 기준에서는 알람 켜줘/꺼줘는 단순 즉시 제어이면 ODL이고, 내일 7시에 알람 맞춰줘처럼 등록/수정/삭제/조회 workflow이면 SCH다. 과거 holdout 정답셋이 알람 단어만 보고 SCH로 라벨링되어 있으면, 현재 라우터가 틀린 것이 아니라 정답셋 정책이 오래된 것이다.

3. 2단계: 결과를 transition으로 본다

full-run 결과는 전체 accuracy보다 먼저 아래 형태로 본다.

대표적으로 크게 보던 transition은 아래와 같다.

4. 3단계: 실제 행을 보고 정답지 오류와 router 오류를 분리

오분류 transition만 보면 부족하다. 실제 발화를 한 건씩 보면서 아래 네 가지로 나눴다.

예시:

이 단계가 없으면 “성능 개선”이 실제로는 “오래된 정답지에 맞춘 과적합”이 될 수 있다.

5. 4단계: 의미축을 재정의한다

우리가 말한 “축 이동”은 특정 단어를 추가하는 것이 아니라, 판단 질문의 우선순위를 바꾸는 작업이다.

5.1 DEF <> STT_NULL

핵심 질문:

첫 응답이 자연스럽게 가능한가,
아니면 전체 의도를 다시 물어야 하는가?

조정 방향:

5.2 ODL <> SCH

핵심 질문:

지금 바로 실행할 제어인가,
미래/반복/시간 slot이 있는 workflow인가?

조정 방향:

5.3 DQR <> FRG

핵심 질문:

기기/제품 지식인가,
외부 public 정보인가?

조정 방향:

5.4 ODL <> STT_NULL

핵심 질문:

LLM이 복구해도 안전한 기기 명령인가,
실행하면 과추론 위험이 큰가?

조정 방향:

6. 5단계: cue는 의미 evidence로만 조정한다

cue는 family를 직접 고르는 rule이 아니다. cue는 Planner에게 줄 evidence를 만든다.

좋은 cue 조정:

피한 작업:

7. 6단계: prompt와 system contract에 반영한다

cue만 바꾸면 안 된다. LLM Planner가 cue를 어떻게 써야 하는지도 같이 고정해야 한다.

예시 prompt 방향:

짧은 발화라도 인사/반응/감정/메타 응답이 가능하면 STT_NULL로 닫지 말라.
하지만 긴 STT 잔여물에서 단어 몇 개만 보고 target/action을 새로 만들지 말라.
기기 실행은 capability/catalog와 안전하게 연결될 때만 선택하라.
알람/예약/스케줄은 단어가 아니라 생성/수정/삭제/조회 workflow인지 판단하라.

8. 7단계: focused set -> full-run -> holdout 순서로 검증한다

검증은 작은 것부터 큰 것으로 간다.

중요한 운영 원칙:

• DEF가 좋아졌는데 STT_NULL이 무너지면 실패다.
• ODL이 좋아졌는데 SCH/UNS 과실행이 늘면 실패다.
• FRG가 좋아졌는데 긴 노이즈를 public lookup으로 과승격하면 실패다.
• 기존 정답셋 정책이 낡았으면 라우터를 억지로 맞추지 말고 정답셋 version을 올린다.

9. 8단계: 릴리즈 기준

축 튜닝 결과는 아래가 있어야 release candidate로 본다.

10. 운영 로드맵

Phase 0. Baseline 고정

목표:

• 현재 branch, prompt snapshot, answer set version, full-run artifact를 고정한다.
• expected_family, selected_family, source, response, reason을 같은 결과 파일에서 볼 수 있게 한다.

산출물:

• baseline CSV/XLSX
• family별 성능표
• mismatch transition table

Phase 1. 정답지 검수

목표:

• 최신 정책과 충돌하는 라벨을 보정한다.
• “정답 변경”과 “라우터 수정”을 섞지 않는다.

검수 축:

• 알람 단순 제어는 ODL, schedule 등록/수정/삭제/조회는 SCH
• 외부 날씨/지역 날씨는 현재 정책상 ODL로 유지
• 외부 제품/공개 지식/번역/수학은 FRG
• 제품/기기 기능/사용법/업데이트/연결은 DQR
• 첫 응답 가능 대화는 DEF, 전체 의도 복구 필요는 STT_NULL

Phase 2. 큰 transition부터 튜닝

목표:

• 건수가 큰 DEF <> STT_NULL을 먼저 본다.
• 그 다음 ODL <> SCH, DQR <> FRG, ODL <> STT_NULL, UNS를 본다.

주의:

• 특정 예시를 맞추기 위한 row-level rule을 만들지 않는다.
• cue는 반복 가능한 semantic pattern일 때만 추가한다.
• prompt는 cue를 해석하는 경계 설명으로 보강한다.

Phase 3. Prompt/Cue/System 동시 정렬

목표:

• deterministic cue와 LLM prompt가 서로 다른 기준을 말하지 않게 한다.
• main_router.response_schema.json, capability registry, skill registry, planner prompt의 책임을 맞춘다.

예:

cue는 "스케줄 단어가 있음"을 evidence로만 제공한다.
prompt는 "생성/수정/삭제/조회 workflow일 때 SCH"라고 판단 기준을 제공한다.
schema는 planner가 그 판단을 steps/slots로 표현하게 한다.

Phase 4. 회귀 검증

목표:

• focused set에서 좋아진 수정이 full-run과 holdout에서도 유지되는지 본다.
• family별 이득/손실을 같이 본다.

판단:

• 개선 family만 보지 않는다.
• 실패 비용이 큰 ODL 과실행과 UNS 누락은 별도 gate로 본다.
• DEF/STT_NULL은 중복정답 가능성을 따로 기록한다.

Phase 5. 운영 지식화

목표:

• 축 조정 결과를 다음 사람이 재현할 수 있게 남긴다.
• 왜 적용했고 왜 적용하지 않았는지를 같이 기록한다.

남길 것:

• cue inventory
• 적용/미적용 판단표
• answer set change log
• benchmark result
• mismatch sample
• prompt snapshot

11. 다음 고도화 과제

관련 문서

• Semantic Boundary Calibration Playbook
• Benchmark and Router Evolution
• A2A Planner Deep Dive
• A2A Planner Research Reading List
• A2A RL-Like Feedback Improvement Opportunities