AI Feature Launch Readiness

AI vs. non-AI ROI 비교 수행하기(Conduct an AI vs. non-AI ROI comparison)

당신은 {{feature_name}}에 대한 AI ROI 비교를 수행하고 있습니다. Non-AI baseline은 {{non_ai_baseline}}입니다.

## Dimensions
| Dimension | Non-AI baseline | AI option | Delta |
|-----------|----------------|-----------|-------|
| Accuracy (correct outcome) | | | |
| Consistency (같은 input에 같은 output) | | | |
| Cost (call당, user당, 월간) | | | |
| Latency (p50, p99) | | | |
| Development cost (ship까지 eng week) | | | |
| Ongoing cost (eval, monitoring, model drift) | | | |
| Failure mode severity (틀렸을 때 무슨 일이 벌어지는가) | | | |
| Reversibility (나쁜 output이 나왔을 때 사용자가 회복 가능한가) | | | |

## Decision rules
- AI wins cleanly: accuracy delta >20%, cost delta 10%, cost delta 10x
- Demo-only: 데모에선 인상적이지만 ROI는 마이너스 — non-AI 버전을 먼저 ship

## Quality floor
AI 품질이 어떤 load-bearing dimension에서든 non-AI보다 낮다면:
- AI가 이길 수 있는 constrained scope가 있는가?
- 둘을 섞는 human-in-the-loop path가 있는가?

## Output
1. 채워진 비교 표
2. Recommendation (AI / hybrid / non-AI)
3. 12개월 안에 가장 바뀔 가능성이 높은 가정 1개 (모델 비용, capability 등)
4. 이 판단을 뒤집을 reversal trigger (어떤 새 데이터가 생기면 call을 바꾸는가)

출시 전 AI 기능 평가 루브릭 설계하기(Design an AI feature evaluation rubric before shipping)

당신은 {{product_name}}의 {{product_name}}에 대한 출시 전 루브릭을 만드는 AI 평가 설계자입니다. 사용자 태스크: {{user_task}}.

## Step 1 — 태스크 셋
다음에 걸친 실제 사용자 입력 30~100개 테스트 셋 만들기:
- Happy path (명확한 입력, 명백한 의도)
- Edge case (모호한 입력, 비정상 표현)
- Adversarial (jailbreak, prompt injection, 범위 외)
- 대표적 에러 모드 (오타, 미지원 언어, 누락 컨텍스트)

## Step 2 — 점수화 기준
3~5개 차원 정의, 각각 1-5:
- Correctness (올바른 것을 답했는가?)
- Completeness (완전히 답했는가?)
- Faithfulness (환각하지 않았는가?)
- Safety (적절히 거절했는가?)
- 사용자 대면 품질 (사용자가 만족할 것인가?)

## Step 3 — 골든 답안
30개 happy-path 태스크에 대해:
- 이상적 답안 작성 (또는 수용 가능한 변형 2~3개)
- 무엇이 좋은지/나쁜지 주석

## Step 4 — 회귀 가드레일
- 출시할 차원당 최소 점수
- 모든 모델/프롬프트 변경에 대한 자동 diff
- 무작위 샘플에 대한 인간 리뷰 주기

## Step 5 — 출력
1. 태스크 셋 스펙
2. 점수 예시가 있는 루브릭
3. Pass/fail 출시 기준
4. 우리가 용인할 단일 실패 모드 (그리고 이유)
5. 출시 후 드리프트(drift) 모니터링 계획

golden dataset으로 AI 기능 eval 실행하기(Run an AI feature eval with golden dataset)

당신은 {{ai_feature}}에 대한 formal eval을 진행하고 있습니다. 목표는 방어 가능한 quality number를 만드는 것입니다.

## Step 1 — Dataset
- 실제 production input 100-500개
- Use case 전반에 균형 있게 분포
- 도메인 전문가가 만든 ground-truth label (PM이 아님)
- Held-out test split (prompt iteration에는 사용하지 않음)

## Step 2 — Scoring
### Automatic metrics
- Exact match (가능한 경우)
- 텍스트 생성용 ROUGE/BLEU
- Custom task-specific metric

### LLM-judge
- 먼저 라벨된 예시 50개로 LLM judge를 calibration
- Judge와 human label의 일치도를 spot-check(85% 이상이어야 함)

### Human scoring
- Blind 방식(어떤 model/prompt인지 모르게)
- 항목당 annotator 3명, aggregate 사용
- Anchor example이 포함된 5점 rubric

## Step 3 — Statistical rigor
- Confidence interval (bootstrap)
- 95% confidence를 위한 sample size
- 2개 초과 variant를 테스트한다면 multiple comparison correction

## Step 4 — Reporting
- Overall quality score (0-100 또는 pass rate)
- 카테고리별 점수
- Confidence interval
- 해당 시 variant 비교
- 모델이 신뢰할 수 없는 category 1개

## Output
1. Eval spec (dataset, metric, judge setup)
2. Scoring rubric
3. Report template
4. 헤드라인 숫자에 가장 큰 영향을 주는 eval 결정 1개(metric 선택 등)

사용자를 위한 AI 제품 고지 패턴 설계하기

{{ai_feature}}에 대한 AI 고지 패턴을 설계한다고 생각하세요.

## 1단계 — 고지 메커니즘
- 결과물을 AI 생성이라고 표시(시각 + 텍스트)
- 신뢰도 표시(높음/중간/낮음 또는 숫자)
- 출처 인용(결과가 어디에서 왔는지)
- 거절 표면(AI가 무엇을 하지 않으며 왜 그런지)
- 오버라이드 제공(사용자가 수정하거나 거절할 수 있게)

## 2단계 — 배치 위치
| 메커니즘 | 위치 | 시점 |
|-----------|-------|------|
| AI 라벨 | 모든 AI 출력 | 항상 |
| 신뢰도 | 사용자가 결과를 실행하기 전 | 모델이 불확실할 때 |
| 인용 | 출력 내 인라인 | 주장성 내용이 있을 때마다 |
| 거절 | 사용자가 범위를 벗어난 요청을 할 때 | 시도 시 |
| 오버라이드 | 모든 출력 | 항상 사용 가능 |

## 3단계 — 피해야 할 안티패턴
- 과도하게 확신하는 표현("확실히", "항상")
- 가짜 겸손(실제로는 신뢰할 만한데 낮은 신뢰도로 표시)
- 숨겨진 AI(AI 출력을 인간처럼 위장)
- 고지 피로(경고가 너무 많아 사용자가 무시함)

## 4단계 — 테스트
사용자 10명에게 플로를 실행하게 하세요:
- AI 고지를 인지했는가?
- 신뢰 수준을 적절히 조절했는가?
- 어떻게 오버라이드하는지 알았는가?
- 신뢰도 신호가 실제 경험과 맞았는가?

## 출력
1. 고지 메커니즘 명세
2. 배치 규칙
3. 특히 감사해야 할 안티패턴 3개
4. 사용자 테스트 계획

AI 기능을 위한 human-in-the-loop 안전망 설계하기(Design a human-in-the-loop safety net for an AI feature)

당신은 {{ai_feature}}를 위한 HITL safety net을 설계하고 있습니다. 틀렸을 때의 stakes는 {{stakes}}입니다.

## Step 1 — Task taxonomy
작업을 다음 tier로 분류하세요:
- **Tier A (Auto)**: stakes는 낮고 model confidence는 높음 → AI가 독립적으로 실행
- **Tier B (Review)**: stakes가 중간이거나 confidence가 중간 → AI가 제안하고 사람이 승인
- **Tier C (Hybrid)**: stakes가 높고 인간의 judgment가 필요함 → AI가 초안을 만들고 사람이 다시 씀
- **Tier D (Human-only)**: AI가 하기엔 너무 위험하거나 judgment 비중이 큼

## Step 2 — Confidence thresholds
각 tier별 숫자 threshold를 정의하세요:
- Model confidence score
- Output 길이 / 복잡도 heuristic
- User-signal check (첫 사용자, 민감한 계정 등)

## Step 3 — Review UI design
Tier B 작업에 대해:
- AI 제안을 명확히 표시해 보여주기
- One-click accept / edit / reject
- 학습 데이터로 쓸 feedback signal 수집

## Step 4 — Escalation triggers
- 모델이 uncertain하다고 표시함
- 사용자가 "not confident"를 표시함
- 패턴 감지(연속 3회 reject) → AI 자동 일시정지
- Adversarial input 감지

## Step 5 — Feedback loop
- Reject 데이터 → eval set 확장
- Edit 데이터 → prompt/model fine-tune 후보
- Accept 데이터 → confidence threshold calibration

## Output
1. Task tier 표
2. Confidence threshold 규칙
3. Review UI spec
4. B에서 A로 가장 먼저 확장할 tier 1개(그리고 그 이유)
5. 장기적으로 계속 C에 둘 tier 1개