kyeongmin
9410576e60
- 후보 3개 (FAISS 2 + Opus 1) → 컨테이너에 맞게 재구성 → 실제 렌더링 → Kei 스크린샷 판단 - 14건 문제 진단 포함 (블록 의미 왜곡, height_cost 부정확, 컨테이너 불일치 등) - 미해결 사항 확정: 텍스트=Kei 편집, 선택=스크린샷, 전부 안맞으면=정확도 최고로 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
177 lines
7.0 KiB
Markdown
177 lines
7.0 KiB
Markdown
# Phase P: 블록 재구성 + 실제 렌더링 비교 선택
|
||
|
||
> 작성일: 2026-03-27
|
||
> 상태: 계획 수립 중 (사용자 승인 대기)
|
||
> 선행 완료: Phase O (컨테이너 기반 레이아웃)
|
||
|
||
---
|
||
|
||
## 핵심 원칙
|
||
|
||
**"블록을 컨테이너에 맞게 재구성하고, 실제 렌더링해보고, Kei가 목적에 맞는 것을 고른다."**
|
||
|
||
```
|
||
컨테이너 58px 확정 (Phase O)
|
||
↓
|
||
후보 3개 선택 (FAISS 2개 + Opus 1개)
|
||
↓
|
||
3개 블록을 각각 58px에 맞게 재구성
|
||
(폰트, 패딩, 항목 수, 레이아웃 변형)
|
||
↓
|
||
재구성된 3개를 실제 렌더링 (Selenium)
|
||
↓
|
||
Kei가 "당초 목적에 가장 적합한 것은?" 선택 → 최종 1개
|
||
```
|
||
|
||
---
|
||
|
||
## 이것이 해결하는 문제들
|
||
|
||
| 문제 | 왜 해결되나 |
|
||
|------|-----------|
|
||
| P-1: 키워드 반응으로 잘못된 블록 선택 | 3개를 실제 렌더링해서 Kei가 목적 기준으로 최종 선택. 키워드 반응으로 골라도 목적에 안 맞으면 탈락 |
|
||
| P-4: 블록이 콘텐츠 의미 왜곡 | compare-pill-pair에 "혼용 문제"를 넣어봤더니 의미가 안 맞으면 Kei가 탈락시킴 |
|
||
| P-5/6/7: height_cost 부정확 | catalog의 height_cost를 믿지 않음. 실제 렌더링으로 확인 |
|
||
| P-8: 58px에 콘텐츠 전달 불가 | 블록을 58px에 맞게 재구성하므로 어떤 블록이든 넣을 수 있음 |
|
||
| P-14: 피드백 루프 무력 | 처음부터 맞는 걸 고르니까 피드백 필요성 감소 |
|
||
|
||
---
|
||
|
||
## 단계별 상세
|
||
|
||
### P-Step 1: 후보 선택
|
||
|
||
각 topic에 대해 후보 3개를 뽑는다.
|
||
|
||
**FAISS 2개:**
|
||
- 기존 `search_blocks_for_topics()`로 검색
|
||
- topic의 purpose, relation_type, expression_hint를 쿼리에 포함 (이미 Phase M에서 구현)
|
||
- 상위 2개 선택
|
||
|
||
**Opus 1개:**
|
||
- 기존 `_opus_block_recommendation()`에서 Kei가 추천한 블록
|
||
- 도메인 지식 + 콘텐츠 성격 기반
|
||
|
||
**중복 제거:** FAISS 결과에 Opus 추천이 이미 포함되어 있으면 FAISS 3번째를 올림. 항상 서로 다른 3개.
|
||
|
||
### P-Step 2: 블록 재구성
|
||
|
||
각 후보 블록을 해당 topic의 **컨테이너 크기에 맞게 재구성**한다.
|
||
|
||
**재구성 항목:**
|
||
- 폰트 크기: 컨테이너 높이에 따라 조정 (Phase O `_determine_typography()` 사용)
|
||
- 패딩: 컨테이너 높이에 따라 조정
|
||
- 항목 수: 컨테이너에 들어가는 만큼만 (Phase O `_calculate_block_constraints()` 사용)
|
||
- 글자 수: 항목당 최대 글자 수 계산
|
||
- 레이아웃: 세로 → 가로 전환 등 (컨테이너 가로/세로 비율에 따라)
|
||
|
||
**이 단계에서 텍스트도 채운다:**
|
||
- 각 후보 블록의 슬롯에 맞게 Kei 편집자가 텍스트를 채움
|
||
- 3개 블록 × 같은 원본 텍스트 → 3개 다른 편집 결과
|
||
- 또는: 1회 편집 후 3개 블록 슬롯에 재배치 (API 호출 절약)
|
||
|
||
### P-Step 3: 실제 렌더링
|
||
|
||
재구성된 3개 블록을 각각 Selenium으로 렌더링한다.
|
||
|
||
**측정 항목:**
|
||
- 실제 높이(scrollHeight) vs 컨테이너 높이
|
||
- overflow 여부
|
||
- 렌더링 결과 스크린샷 (base64 PNG)
|
||
|
||
**렌더링 방법:**
|
||
- `render_standalone_block(block_type, data)`로 각 블록 단독 렌더링
|
||
- 컨테이너 크기를 감싼 div 안에서 렌더링
|
||
- `slide_measurer.py`의 기존 Selenium 인프라 재사용
|
||
|
||
### P-Step 4: Kei 최종 선택
|
||
|
||
렌더링된 3개 결과를 Kei(Opus)에게 보여주고 최종 선택.
|
||
|
||
**Kei에게 전달하는 정보:**
|
||
- 이 topic의 원래 목적 (purpose, relation_type, expression_hint)
|
||
- 3개 렌더링 결과 (스크린샷 이미지 또는 HTML 요약)
|
||
- 각 블록의 overflow 여부
|
||
- 원본 콘텐츠
|
||
|
||
**Kei 판단 기준:**
|
||
1. 당초 목적에 적합한가? (문제 제기인데 비교 블록이면 부적합)
|
||
2. 콘텐츠 의미가 왜곡되지 않는가?
|
||
3. 컨테이너에 맞게 렌더링되었는가?
|
||
|
||
**Kei API 호출:** 1회. 3개를 한꺼번에 보여주고 1개 선택.
|
||
|
||
---
|
||
|
||
## 파이프라인 흐름 변경
|
||
|
||
```
|
||
현재:
|
||
1A → 1B → 컨테이너 → A-2(Kei 1개 확정) → 블록 스펙 → 3(편집) → 4(렌더링) → 측정 → 5(검수)
|
||
|
||
Phase P 후:
|
||
1A → 1B → 컨테이너
|
||
→ 각 topic마다:
|
||
후보 3개 (FAISS 2 + Opus 1)
|
||
→ 3개 재구성 (컨테이너에 맞게)
|
||
→ 3개 렌더링 (Selenium)
|
||
→ Kei 최종 선택 (목적 적합성)
|
||
→ 선택된 블록으로 전체 슬라이드 조립
|
||
→ 4(CSS 조정 + 최종 렌더링)
|
||
→ 측정
|
||
→ 5(검수)
|
||
```
|
||
|
||
---
|
||
|
||
## 기존 코드 영향
|
||
|
||
| 파일 | 변경 |
|
||
|------|------|
|
||
| `pipeline.py` | Step A-2 단일 선택 → topic별 3후보 + 렌더링 + Kei 선택 루프로 변경 |
|
||
| `design_director.py` | `_opus_block_recommendation()` — 기존 유지. 추가로 단일 topic 추천 함수 필요 |
|
||
| `block_search.py` | 기존 유지. topic별 상위 2개 추출 함수 추가 |
|
||
| `renderer.py` | `render_standalone_block()` — 기존 유지. 컨테이너 감싼 렌더링 함수 추가 |
|
||
| `slide_measurer.py` | 기존 유지. 단일 블록 높이 측정 함수 추가 |
|
||
| `space_allocator.py` | `finalize_block_specs()` — 기존 유지. 후보별 스펙 계산에 재사용 |
|
||
| `content_editor.py` | 기존 유지. 후보별 텍스트 채우기에 재사용 |
|
||
| `kei_client.py` | 3후보 비교 선택 프롬프트 함수 신규 |
|
||
|
||
---
|
||
|
||
## 하드코딩 검증
|
||
|
||
| 항목 | 하드코딩? | 근거 |
|
||
|------|---------|------|
|
||
| 후보 수 3개 (FAISS 2 + Opus 1) | 구조적 설계 | 블록 추가해도 변경 불필요. 3개는 비교에 적절한 수 |
|
||
| 블록 재구성 (폰트/패딩/항목수) | 동적 계산 | Phase O `_determine_typography()`, `_calculate_block_constraints()` 사용 |
|
||
| 최종 선택 | Kei 판단 | 코드가 선택하지 않음 |
|
||
| 컨테이너 크기 | Kei 비중에서 동적 계산 | Phase O `calculate_container_specs()` |
|
||
|
||
---
|
||
|
||
## 비용 분석
|
||
|
||
| 항목 | 현재 | Phase P 후 |
|
||
|------|------|-----------|
|
||
| Kei API 호출 | 1A + 1B + A-2 + 3(편집) + 5(검수) = 5회 | + topic별 최종 선택 1회 × 5topics = +5회. 총 ~10회 |
|
||
| Selenium 렌더링 | 1회 (전체 슬라이드) | + topic별 3후보 × 5topics = +15회. 단독 블록이라 빠름 (~50ms/회) |
|
||
| Sonnet 호출 | 4단계 CSS 1회 | 변경 없음 |
|
||
| 총 시간 증가 | — | Selenium +750ms, Kei API +5회 (각 ~30초) ≈ +2.5분 |
|
||
|
||
---
|
||
|
||
## 미해결 사항 (사용자 논의 필요)
|
||
|
||
1. **3개 후보에 텍스트를 어떻게 채우나?**
|
||
- 방법 A: Kei 편집자를 3회 호출 (각 블록 슬롯에 맞게) — 정확하지만 느림
|
||
- 방법 B: 1회 편집 후 3개 블록 슬롯에 기계적 재배치 — 빠르지만 슬롯 구조가 다르면 부정확
|
||
- 방법 C: Kei 편집자 1회 호출에 "3개 블록 각각의 슬롯에 맞게" 한꺼번에 요청 — 중간
|
||
|
||
2. **Kei 최종 선택에 스크린샷을 보여줄까, HTML 요약을 보여줄까?**
|
||
- 스크린샷: Opus 멀티모달로 실제 렌더링을 보고 판단 — 정확
|
||
- HTML 요약: 텍스트 기반 — 빠르지만 시각 판단 불가
|
||
|
||
3. **3개 후보가 전부 목적에 안 맞으면?**
|
||
- Kei가 "없음"을 선택할 수 있게 할까? 그러면 추가 후보를 어디서?
|