파이프라인: evaluate-pipeline
파이프라인의 구조적 요소를 절제 실험(Ablation Study)으로 검증하여 최적 구성을 도출한다.
사용 방법
- 계획 수립:
/pipeline--plan-evaluation을 실행하고, 검증할 파이프라인의 구조도를 입력한다. 설계자 승인을 거쳐 실험 계획서가 생성된다. - 실험 실행:
/pipeline--run-evaluation을 실행하면, 계획서를 기반으로 절제 변형을 자동 실행하고 LLM-as-Judge 평가 후 최적화 리포트를 생성한다.
구조도
Loading diagram...
Loading diagram...
구조 설계 결정
| 유형 | 적용 내용 |
|---|---|
| Multi-Step | 계획(plan)과 실행(run)을 별도 스킬로 분리 (총 9단계) |
| Role Split | ablation-runner(산출물 생성)와 evaluation-judge(품질 평가)를 분리 |
| Dedicated Agent | 2개 전문 에이전트 (ablation-runner, evaluation-judge) |
| Human Gate | 계획 단계에서 3회 이상 설계자 승인 (제외 확인, 도메인 차원 승인, 최종 계획 승인) |
특이사항
파이프라인 구조
- 메타 파이프라인: 이 파이프라인은 다른 파이프라인을 검증하기 위한 파이프라인이다. 즉, "파이프라인의 파이프라인"이며, 이론적으로 자기 자신도 검증 대상이 될 수 있다.
- 2개 스킬 분리: 계획 단계(plan)는 설계자와 여러 차례 대화하며 승인을 받아야 하고, 실행 단계(run)는 자동으로 돌아간다. 성격이 다른 두 단계를 별도 스킬로 분리하여, 계획만 먼저 세워두고 실행은 나중에 할 수 있다.
평가 신뢰성
- Blind Evaluation: 심사위원(evaluation-judge)에게 "어느 것이 원래 파이프라인의 출력인지" 알려주지 않는다. 마치 블라인드 테스트처럼, 선입견 없이 순수하게 품질만으로 판단하도록 하기 위함이다.
- 모델 비대칭: 절제 변형을 실행하는 ablation-runner는 의도적으로 낮은 사양의 모델(Sonnet)을 사용한다. "저사양 모델의 단순 프롬프트 한 방으로도 비슷한 품질이 나온다면, 그 파이프라인 구조는 불필요하다"는 검증 논리이다.
실험 설계
- 4가지 휴리스틱: 어떤 요소를 먼저 제거할지 사전에 영향력을 추정한다. 수확 체감 법칙(반복할수록 효과 감소), Optional 표시(선택적 단계), 중복 신호(비슷한 역할이 겹침), 하류 의존성 부재(이후 단계가 참조하지 않음) 4가지 기준을 사용한다.
- 순차적 누적 제거: 영향력이 가장 낮다고 추정된 요소부터 하나씩 제거하되, 이전에 제거한 것은 계속 제거된 상태로 유지한다. 이렇게 하면 요소 간 상호작용(A를 빼면 B도 무의미해지는 경우)까지 포착할 수 있다.
- 조기 중단: 누적 제거 과정에서 품질 하락이 유의미한 수준(5점 이상)에 도달하면, 그 이후의 테스트는 건너뛴다. 이미 "여기부터는 제거하면 안 된다"는 경계를 찾았기 때문이다.
비용 최적화
- Baseline 재사용: 파이프라인을 이전에 실행한 적이 있고 산출물이 파일로 저장되어 있다면, 이를 Baseline으로 재사용한다. 비교 기준을 만들기 위해 파이프라인을 처음부터 다시 돌릴 필요가 없으므로 토큰을 절약할 수 있다.