strategy-mapping.md

RouteFit — Strategy Mapping & Explainability Logic

입력 조건 → 전략 후보 필터·점수화 → 왜 채택 / 왜 탈락 설명 생성의 SSOT. 결과 화면의 "왜 이 전략인가"·"Decision Trace"·"신뢰도 근거"는 전부 이 문서의 규칙에서 나온다. 관련: methodology.md(비용·품질·제약식) · ux-spec.md(결과 요건) · assumptions.md(벤더 사실)

핵심 원칙: 선호는 신호일 뿐, 제약(constraint)이 이긴다. 선호와 조건이 충돌하면 뒤집고 그 이유를 설명한다.

---

1. 전략 후보 (7종 + 보류)

#	전략	층위	성격
S1	단일 고성능 100%	—	품질 상한 / 비용 기준선
S2	단일 경량 100%	—	비용 하한 / 품질 위험
S3	Rule + Semantic Routing	생성 前	자체 구축, 데이터 적어도 가능
S4	Learned Router (RouteLLM 계열)	생성 前	자체 구축, 평가 데이터 필요
S5	Quality Cascade (FrugalGPT형)	생성 後	경량 후 품질 미달 에스컬레이션
S6	Routing + Cascade Hybrid	前+後	품질 안전망 + 비용 절감
S7	관리형 라우터	벤더	Bedrock / Foundry / Model Optimizer
S0	라우팅 보류	—	트래픽·비용 작으면 라우터 오버헤드가 손해

관리형(S7)은 운영방식=관리형일 때 후보에 오르되, 자체 구축(S3~S6)과 항상 frontier에서 나란히 비교된다.

---

2. Hard Constraint Filter (탈락 → Decision Trace에 사유 기록)

조건	탈락시키는 후보	탈락 사유 문구
데이터 반출 불가/제한	S7 관리형(클라우드)	"데이터 반출 제한과 충돌 — 로컬 처리 필요"
최대 컨텍스트 > 모델 지원	해당 모델 규칙	"컨텍스트 길이 미달"
멀티모달/tool calling 필요한데 미지원	해당 모델	"필수 기능 미지원"
P95 지연 < 캐스케이드 2회 호출 예상	S5/S6 (지연 민감)	"허용 지연 초과 위험"
평가 데이터 없음	S4 Learned를 차선으로 강등(탈락 아님)	"평가 데이터 부족 — 학습형 강점 못 살림"

관리형+특정 클라우드를 선호했는데 반출 제한으로 S7이 탈락하면: "관리형을 선호하셨지만 데이터 반출 제한에서는 Bedrock이 탈락합니다. 대신 로컬 Semantic Router + 자체 모델을 권장합니다." ← 선호를 존중하되 뒤집고 설명.

---

3. 규칙 기반 우선 추천 (§6, soft 점수 가점)

기업 조건	우선 오르는 전략
관리형 + AWS, 영어 중심, 동일 패밀리로 충분	S7 Bedrock Intelligent Prompt Routing
관리형 + Azure, 다양한 후보 관리형 운영	S7 Foundry Model Router
관리형 + Google, Gemini 중심	S7 Gemini Enterprise Agent Platform — Model Optimizer
업무 카테고리 명확 + 데이터 적음	S3 Rule + Semantic
업무 예시는 있으나 선호 데이터 없음	S3 Embedding Semantic
강/약 선호 비교 데이터 보유	S4 Learned Router
품질 하락 허용 거의 없음	S6 Routing + Cascade Hybrid
모든 요청 유사 + 품질 요구 일정	S1 단일 / 정적 라우팅
데이터 반출 불가	S3 로컬 Semantic + 자체 모델
자체 GPU로 대·소 모델 서빙	S5→ Speculative Cascade 검토 (참고)
트래픽 적고 모델비 낮음	S0 라우팅 보류

---

4. 점수화 (§10 제약식)

Minimize 월 비용(§1–§9)
Subject to: 예상 품질 ≥ 최소 기준 · P95 ≤ 허용지연 · 반출정책 · 컨텍스트 · 기능요구

각 살아남은 후보에 대해:

• 비용 = methodology §1–§9로 시나리오 계산 (보수/기준/공격)
• 품질 = §11 업무별 성공률 × 업무 비율 (평가 데이터 없으면 벤치마크 추정)
• 운영 복잡도 / 종속성 / 데이터 준비도 = 감점 요인
• 선호 가점 = 운영방식 선호와 일치 시 소폭 가산 (제약을 못 이김)

품질 우선순위(비용/균형/품질)가 비용 vs 품질 가중을 조절. 최종 = 제약 통과 + Pareto 무릎점(knee) 우선. 정답 하나가 아니라 frontier 위 여러 점을 제시.

---

5. 설명 생성 (결과 화면으로 직결)

각 후보는 계산 시 구조화된 사유 객체를 남긴다:

{
  strategy: "S6",
  status: "picked" | "alternative" | "rejected" | "baseline",
  reasons: [ { text, source: "input:data_export" | "§6" | "§10" | "§1-9" } ],
  reject_reason?: "데이터 반출 제한과 충돌",
  cost: {conservative, base, aggressive},
  quality_est: 0.xx,
  confidence_factors: {...}
}

• "왜 이 전략인가" = picked 후보의 reasons (출처 태그 그대로 노출)
• Decision Trace = 전체 후보의 status + reject_reason
• 이 구조가 없으면 결과를 그리지 않는다 (설명 없는 추천 금지).

---

6. 신뢰도 등급 도출

축	근거	등급 규칙
가격 계산	공식 API 가격 기반	항상 높음 (manual seed 시 표기)
사용량 계산	사용자 입력 기반	입력 완전=높음 / 프리셋 의존=보통
품질 예측	평가 데이터 유무	자체 평가셋=높음 / 벤치마크 추정=보통 / 기타 업무=보통 강제

종합 = 세 축의 최저값 근처. 화면엔 축별 분해 + 종합 뱃지 + "무엇을 하면 올라가는지"(예: 자체 평가 데이터 확보)를 함께 표시.

---

갱신 로그

• 2026-07-13: 최초 작성. 후보 7+보류, hard filter·§6 규칙·§10 점수화·구조화 사유·신뢰도 도출 확정. 선호<제약 원칙 명문화.