Experience Admission Shadow Phase 1
이 문서는 Goal Composer 연결 전 Phase 1 shadow 기준선을 보존한 역사 문서다. 현재 제한적 live 구현은 Experience Goal Composer Live Slice 2026-08-02에서 확인한다.
간접적인 목표 발화를 곧바로 실행하지 않고, 장기 Experience 후보인지 먼저 관찰하는 Cloud A2A 진입 계약의 1차 구현이다.
당시 상태
| 항목 | 상태 |
|---|---|
| Main Router 출력 | 선택적 experience_request |
| 실행 모드 | shadow 고정 |
| 기존 family/route 영향 | 없음 |
| Planner step 영향 | 없음 |
| TaskManager dispatch | 금지 |
| Session/console trace | 연결 |
| Goal Composer 연결 | 미연결 |
| Experience Supervisor 활성화 | 미연결 |
이 Phase 1 단계는 새 Agent나 family를 추가하지 않았다. Main Router의 기존 1회 판단 결과에 작은 관찰 객체만 선택적으로 포함하므로 별도 LLM 호출도 추가하지 않는다.
실제 shadow 측정에서는
A2A_EXPERIENCE_ADMISSION_SHADOW_REQUIRED=true를 사용한다. 이때만 같은 Router
응답 schema에서 admission 객체를 필수화해 누락과 과승격을 모두 측정한다.
기본값은 false이므로 운영 요청의 출력 토큰과 응답 계약을 상시 늘리지 않는다.
출력 계약
{
"experience_request": {
"mode": "shadow",
"admission_status": "candidate",
"request_signal": "indirect",
"goal_summary": "원하는 결과의 의미 요약",
"desired_effects": ["의미 효과"],
"constraints": ["제약"],
"needs_confirmation": true,
"admission_reason": "indirect_goal_with_action_request",
"shadow_only": true,
"dispatch_allowed": false
}
}
admission_status는 다음 세 값만 허용한다.
| 상태 | 의미 |
|---|---|
candidate |
사용자가 실제 outcome을 요청했고 Experience 조합 후보임 |
needs_clarification |
행동 목표는 있으나 효과 또는 민감한 부작용 확인이 필요함 |
not_admitted |
비슷한 표현이지만 서술·대화·단일 동작이므로 승격하지 않음 |
안전 경계
모델이 실행 필드나 잘못된 플래그를 반환해도 정규화기가 다음을 강제한다.
mode=shadowshadow_only=truedispatch_allowed=false- 임의
steps제거 - 후보가 아닌 경우 목표·효과·제약 제거
따라서 admission 결과는 route, follow-up, TTS, device task와 workflow를 바꿀 수
없다. 장시간 experience 정책은 기존 bounded Experience Supervisor 계약의
소유이며 base router가 생성하지 않는다.
의미 경계
특정 문장이나 어미를 trigger로 사용하지 않는다. 다음 의미를 모델이 함께 판단한다.
- 사용자가 결과를 실제로 요청했는가
- 여러 capability, 관찰, 동의 또는 재계획 가능성이 있는가
- 단순 서술, 과거 사건, 취향 공유, 가정, 정보 질문인가
- 명확한 단일 capability 요청이라 기존 route만으로 충분한가
당시 desired_effects는 자유 형식 의미 요약이었다. Phase 1 테스트는 특정 문자열
일치를 강제하지 않고 후보 상태에서 하나 이상의 효과가 있는지만 확인한다.
효과 ontology와 capability grounding은 Goal Composer 단계에서 별도로 도입한다.
데이터 흐름
Main Router
-> experience_request 선택 출력
-> structural sanitizer
-> 기존 route/plan은 그대로 진행
-> session_state.experience_admission_shadow
-> local shim trace
-> positive/near-negative shadow 평가
검증
| 검증 | 결과 |
|---|---|
| admission 및 batch evaluator | 25 passed |
| Router·TaskManager·Supervisor·replan·shim 회귀 | 173 passed |
| schema/fixture JSON parse | 통과 |
| diff whitespace 검사 | 통과 |
| Gemini shadow r5 | 34/40 = 85.0% |
| Positive recall | 19/20 = 95.0% |
| Near-negative rejection | 15/20 = 75.0% |
| Shadow safety violation | 0 |
40건 shadow suite는 positive 20건과 near-negative 20건으로 구성된다. Cloud
/text만 호출해 반환된 기존 route task는 실기기에 전달하지 않는다. 기존 ODL
route가 만든 task 자체는 admission 부작용이 아니며, admission 객체의
dispatch_allowed=false와 비실행 구조를 별도로 검사한다.
r5 평균 지연은 4101.6ms, p50은 3351.0ms였다. optional r2 대비 평균은 약
380ms 증가했지만 최대 지연 outlier와 모델 변동이 있어 통제된 A/B 수치로
간주하지 않는다. 별도 LLM 호출은 추가하지 않았고 측정 모드에서 동일 Router의
출력 schema와 상한만 확장했다. 실제 token 사용량은 현재 batch artifact에 노출되지
않아 추가 계측이 필요하다.
잔여 실패는 positive 누락 1건과 near-negative 과승격 5건이다. 따라서 현재 판정은
shadow 관찰과 분석에는 Go, Goal Composer·Supervisor·device 실행 연결에는
No-Go다.
다음 승격 조건
- positive 후보 누락률과 near-negative 과승격률 검수
- 기존 family/plan baseline 불변 확인
- admission 객체가 실행 필드를 만들지 않고 dispatch를 허용하지 않는지 확인
- 실패를 문장 예외가 아닌 의미 경계 문제로 분류
- 통과 후에만 Goal Composer와 capability grounding 설계 시작
관련 문서: