FAPO: 다중 단계 LLM 파이프라인의 완전 자동 프롬프트 최적화

다중 단계 LLM 파이프라인은 Retrieval, Reasoning, Formatting 간의 상호작용으로 프롬프트 단독 최적화만으로는 병목을 해결하기 어렵다. FAPO는 실패를 단계별로 attribution하고 프롬프트 에디트에서 시작해 필요 시 파이프라인 구조를 바꿔가며 반복적으로 최적화를 수행한다.

단락 1: 다중 단계 파이프라인에서 프롬프트 단일 조정만으로는 전체 파이프라인의 성능을 설명하기 어렵고, 각 단계의 실패가 후속 단계에 누적되어 성능 저하를 유발한다. 기존의 프롬프트 최적화는 파이프라인 구조의 변화를 간과하는 경향이 있다.

단락 1: FAPO는 파이프라인을inspectable한 워크플로우로 취급하고, current pipeline의 입력/출력과 중간 산출물을 기록한다. 단락 2: 실패를 단계별로 분류하는 step-attribution 서브에이전트와 제안 후보를 검토·허용 수준(scope contract)에서 검토하는 variant-reviewer가 존재한다. 단락 3: 프롬프트 에디트로 시작해 점차적으로 설정(파라미터)이나 파이프라인 구조의 변경으로 확장하는 계층적 탐색을 수행한다. 단락 4: 프롬프트-레벨의 개선이 충분하지 않을 때에만 파이프라인 구조까지 확장하며, 다중-테넌트 격리와 안전 가드레일을 적용한다.

주요 벤치마크에서 FAPO의 평균 이득은 +14.1pp로 요약된다. HotpotQA, HoVer, IFBench 등에서 프롬프트 수준에서의 개선만으로도 다수의 조합에서 GEPA를 능가했다. HoVer와 IFBench의 경우 구조적 변경이 필요했으며, 24.78pp에서 48.56pp까지의 개선을 보였다. CTIBench-RCM에서 보안 태스크의 경우 GPT-5에서 +4.0pp, Foundation-Sec-8B-Instruct에서 +7.1pp, Foundation-Sec-8B-Reasoning에서 +2.0pp의 향상을 보였다. AIME 벤치마크에서는 GEPA가 우세했고, FAPO의 결과는 불일치로 간주되었다. AIME를 제외한 나머지 벤치마크에서 프롬프트-레벨 최적화의 이점이 입증되었고, 프롬프트-최적화와 파이프라인 구조 최적화 간의 트레이드오프가 관찰되었다.

단락 1: 시스템 개요—FAPO는 Claude Code를 최적화 루프의 오케스트레이터로 사용하고 LangGraph를 파이프라인 표현으로 채택한다. 단락 2: 핵심 메커니즘—step-attribution 에이전트는 각 평가 케이스의 실패를 프롬프트 addressable vs 구조적로 분류하고, dominant failure cluster에 대해 scoped variant를 제안한다. 단락 3: Prior work 대비 차별점—GEPA는 프롬프트 문자열 기반의 고정 DSPy 체계에서 벗어나, FAPO는 실패 증거에 기반한 계층적 탐색과 다 tenant 구성을 통한 재현성, guardrails를 강조한다. 단락 4: 구현 학습 세부사항—테넌트 워크스페이스 구조, EvalConfig, ChainConfig, LangGraph 실행 흐름, run artifacts 및 결과의 step_timings 기록, 차후 재현성 확보를 위한 variant immutability를 도입한다. 단락 5: 이론적 기반—프롬프트-의존성 및 파이프라인 bottleneck의 분리 원칙, 최신 파이프라인 최적화 연구와의 연계, 제한조건 하에서의 탐색 공간 제약 등을 기술한다.

AIME 벤치마크에서의 일관된 개선을 보이지 못했고, 프롬프트-단계의 개선이 충분하지 않아 구조적 변경이 필요하다고 판단되는 경우가 있었다. 또한 프롭션-변형 간의 경로 의존성으로 실행 간 변동성이 커질 수 있으며, 벤치마크와 모델 조합에 따라 성능 차이가 크게 나타날 수 있다.