다단계 LLM 파이프라인은 검색·추론·서식 단계 사이의 상호작용으로 실패한다. 따라서 프롬프트만 손보는 최적화는 사슬 속 병목을 놓칠 수 있다. FAPO는 표준화된 코드베이스 안에서 Claude Code가 파이프라인을 최적화하도록 하는 프레임워크다. 파이프라인을 평가하고, 중간 단계를 들여다보고, 실패를 진단하고, 범위가 정해진 변경을 제안하고, 반복적으로 검증한다.
다단계 LLM 파이프라인은 이제 보안·기업 분석·지식 업무에서 흔하다. 호출 수가 늘수록 실패는 어느 단계에서든 발생해 하류로 전파되며, 단일턴 프롬프트 튜닝 이상의 것을 요구한다.
목표를 "하나의 성공한 탈옥 사례를 찾는 것"에서 "한 파이프라인 변형이 N개 평가 사례 전반에서 내는 평균 점수를 높이는 것"으로 바꾸면, 귀속(attribution)이 필수가 된다.
프롬프트 공간 탐색은 이미 탈옥(jailbreaking) 문헌에서 폭넓게 탐구되었다. 레드티밍에서는 고정된 질의 예산 아래 적어도 하나의 프롬프트가 탈옥을 유발할 때까지 후보를 생성·정교화하는 Best-of-N 방식이 흔하다. FAPO는 이 닫힌 루프 탐색 패턴은 유지하되 목표를 전환한다. 이 전환은 옵티마이저가 드문 성공 샘플을 착취하는 대신 반복되는 실패를 설명해야 함을 의미한다.
기존 도구는 공백을 남긴다. HELM·BIG-bench·AgentBench 같은 평가 스위트는 모델 능력을 측정할 뿐 고정된 검사 가능 파이프라인의 설계를 최적화하지 않는다. DSPy는 LLM 모듈을, GEPA는 파이프라인 내부 프롬프트를 최적화하지만, 어느 것도 단계 수준 실패를 들여다본 뒤 표준 코드 작업공간 안에서 프롬프트나 파이프라인 구조를 바꾸도록 설계되지 않았다.
FAPO는 LLM 파이프라인을 검사 가능한 워크플로로 취급한다. 각 단계의 입력·출력·로그를 기록하므로, 옵티마이저는 실패를 프롬프트·상류 증거 출처·사슬 자체 중 어디에 귀속시킬지 국소화할 수 있다.
같은 러너가 여러 과제를 평가하되, 각 과제는 자체 작업공간에 프롬프트·예제·채점 규칙·변경 규칙을 보관한다. 중간 단계를 기록해, 오답이 검색·추론·서식·최종 응답 중 어디서 나왔는지 옵티마이저가 직접 본다.
프롬프트 편집에서 시작하고, 기록된 실패가 프롬프트로 충분치 않음을 보일 때만 설정·사슬 변경으로 이동한다. 작업공간이 변경 가능/불가능을 명시하며, 검토자가 모든 제안 변형을 평가 전에 점검한다.
최적화는 테넌트(tenant) 단위로 조직된다. 테넌트는 평가 기준과 워크플로를 가진 하나의 과제다. 핵심 엔진은 src/hephaestus/ 아래 공유 런타임으로, 사례 로딩·프롬프트 렌더링·프로바이더 어댑터 호출·LangGraph 사슬 실행·채점 검증·실행 산출물 기록·실패 귀속을 담당한다. 테넌트 작업공간(tenants/<tenant_id>/)은 사슬 코드·프롬프트/사슬 변형·데이터셋 변환·채점기·평가 설정·테스트·운영 문서·최적화 이력 등 과제 로컬 자료를 담는다.
테넌트 플레이북은 최적화 중 가장 중요한 정책 문서로 취급되며 FAPO 기능을 무효화(override)할 수 있다. 모든 변형과 점수는 테넌트 디렉터리에 기록되어 이전 실행에 대한 완전한 가시성을 제공하고, 테넌트는 서로 격리되어 한 테넌트의 가정이 다른 테넌트에 영향을 주지 않는다.
FAPO는 평가 대상 과제 모델과 분리된 오케스트레이션 계층으로 Claude Code를 사용한다. 세 핵심 에이전트 — optimization(루프 구동), step-attribution(실패 분류: 프롬프트 해결 가능 vs 구조적), variant-reviewer(범위·플레이스홀더·유출·채점 호환성 점검) — 가 루프를 이룬다.
현재 변형을 학습 분할에서 실행, 최종 출력과 중간단계 증거 수집
실패를 파이프라인 단계·수정 유형별로 분류·군집화
지배적 실패 군집에 대해 범위가 정해진 변형 하나 제안
독립 검토자가 범위·플레이스홀더·유출·채점 호환성 점검
집계 검증 점수로 이전 최고 변형과 비교, 유지·기각·에스컬레이션
옵티마이저는 귀속 보고서를 보고 허용된 수준 중에서 선택한다. 프롬프트 변경이 가장 단순하므로 먼저 시도하고, 그것이 불충분해 보이고 범위 계약이 허용하며 귀속이 프롬프트로 고치기 어려운 병목을 식별할 때만 상위 수준으로 올라간다.
가장 단순한 옵션. 항상 먼저 시도한다. 간결성 규칙, 필수 응답 규칙, 형식 가이드 등.
검색 깊이(hop 수) 등 파라미터 조정. 프롬프트 편집이 불충분할 때 범위 계약이 허용하면 이동한다.
파이프라인 단계 추가·구조 변경. 귀속이 구조적 병목을 지목할 때만 수행한다. 예: 검색 사슬 확장, 결정론적 제약 강제 노드 추가.
FAPO를 GEPA와 비교한다. 두 시스템은 동일한 사슬 구조·기준 프롬프트·과제 모델·샘플링·지표·분할에서 출발한다. 과제 모델은 GPT-4.1-mini, GPT-5.4-mini, Gemma 3-12B다. 예산은 시도당 50개 변형 또는 10라운드다.
Multi-hop QA (HotpotQA). 두 개의 BM25 검색 노드(k=7)와 네 개의 LLM 노드로 이뤄진 6노드 LangGraph 사슬이다. 지표는 정확 일치(EM)다.
HoVer. 여러 위키 문서에 걸친 증거로 주장을 지지/반박 분류하는 다중 홉 사실 검증이다.
IFBench. 검증 가능한 지시 따르기다. 각 프롬프트의 명시적 제약을 최종 답이 충족하는지 채점하므로 형식·제약 강제가 핵심 실패 모드다.
Papillon. 프라이버시 의식적 위임이다. 로컬+API 모델 앙상블로 라우팅할 때 답 품질을 유지하며 PII 유출을 제한한다.
LiveBench-Math. 오염 제한 수학 추론이다. 추론 오류 또는 최종답 추출 오류에서 실패가 잦다.
AIME. 짧은 정확답을 요구하는 경시대회형 수학이다. 엄격한 답 형식 아래 다단계 기호·수치 추론을 강조한다.
CTIBench-RCM (보안). CVE 설명을 CWE ID로 매핑하는 263개 클래스 분류다. 프롬프트 편집으로만 제한한다. GPT-5, Foundation-Sec-8B-Instruct/Reasoning에서 실행한다.
세 과제 모델(GPT-4.1-mini, GPT-5.4-mini, Gemma 3-12B) 평균이다. 주황색 레일은 FAPO가 프롬프트 편집을 넘어 파이프라인 변경으로 에스컬레이션한 벤치마크다. AIME만이 GEPA가 앞선 유일한 벤치마크다.
HoVer에서는 귀속이 불충분한 검색 커버리지를 식별했다. FAPO는 기준 3홉 검색 사슬을 4–5홉으로 확장하고 멀티쿼리 BM25 검색과 개체 인식 구제를 도입했다. IFBench에서는 형식 실패를 식별해, 지시 제약을 강제하는 결정론적 후처리 노드를 추가했다. 이 변경들은 HoVer +24.78~+48.56pp, IFBench +19.84~+38.95pp의 향상을 낳았다.
나머지 벤치마크에서는 최적화가 프롬프트 수준에 머물렀고, FAPO는 프롬프트 전용 비교 12건 중 9건을 이겼다(6건은 평균±표준편차 범위 비중첩). AIME는 세 모델 모두에서 GEPA가 앞선 유일한 벤치마크로, 기준선 대비 혼재된 결과가 잡음 범위에 들어 결론을 내리지 않는다. 작은 표본에 대한 과적합이 원인일 수 있다고 추정한다.
| 벤치마크 | 모델 | 기준선 | GEPA | FAPO | Δ |
|---|---|---|---|---|---|
| HotpotQA | GPT-4.1-mini | 37.11 | 67.56 | 72.67 | +5.11 |
| GPT-5.4-mini | 55.56 | 56.22 | 69.56 | +13.34 | |
| Gemma 3-12B | 56.56 | 61.66 | 62.78 | +1.12 | |
| HoVer 구조 | GPT-4.1-mini | 43.89 | 59.67 | 84.44 | +24.78 |
| GPT-5.4-mini | 26.33 | 31.78 | 80.33 | +48.56 | |
| Gemma 3-12B | 24.89 | 54.00 | 86.67 | +32.67 | |
| IFBench 구조 | GPT-4.1-mini | 25.74 | 54.76 | 93.71 | +38.95 |
| GPT-5.4-mini | 24.49 | 48.36 | 86.05 | +37.70 | |
| Gemma 3-12B | 34.69 | 42.46 | 62.30 | +19.84 | |
| LiveBench-Math | GPT-4.1-mini | 50.25 | 61.78 | 73.56 | +11.78 |
| GPT-5.4-mini | 31.76 | 57.26 | 67.00 | +9.73 | |
| Gemma 3-12B | 30.80 | 38.66 | 45.30 | +6.64 | |
| AIME | GPT-4.1-mini | 51.11 | 52.67 | 48.89 | −3.78 |
| GPT-5.4-mini | 30.00 | 38.44 | 33.78 | −4.67 | |
| Gemma 3-12B | 16.67 | 18.67 | 18.22 | −0.44 | |
| Papillon | GPT-4.1-mini | 68.39 | 90.72 | 94.29 | +3.57 |
| GPT-5.4-mini | 87.79 | 88.82 | 95.07 | +6.26 | |
| Gemma 3-12B | 67.15 | 92.65 | 95.47 | +2.81 |
HotpotQA는 EM. Δ = FAPO − GEPA. 구조 = 프롬프트 탐색이 불충분함을 확인한 뒤 허용된 파이프라인 최적화를 사용. 18건 중 15승, 그중 11승은 평균±표준편차 비중첩.
귀속 서브에이전트가 개발셋에서 세 가지 실패 범주를 식별했다: 근접 실패(장황한 답, 13건), 기권(답변 거부, 8건), 오답(17건). 프롬프트 편집이 어떻게 검증 EM을 끌어올렸는지 보여준다.
기준선(variant-001)은 검증 EM 39.22%였다. variant-002는 답 간결성 제약으로 근접 실패를 다뤄 검증 EM을 65.7%로, variant-003은 "항상 답해야 한다" 규칙으로 기권 실패를 다뤄 70.3%로 끌어올렸다. 두 번의 반복 후 귀속 시스템은 남은 실패를 검색 제약(구조적)으로 표시했고, 추가 프롬프트 전용 반복이 도움이 되기 어려움을 가리켰다. 표 2의 검증 선택 HotpotQA 변형은 프롬프트 전용으로 남았다.
System: Your input fields are: 1. question (str) 2. summary_1 (str) 3. summary_2 (str) Your output fields are: 1. reasoning (str) 2. answer (str) ...주어진 필드로부터 answer 필드를 생성하시오.
System: 가능한 가장 짧은 답으로 다중 홉 질문에 답하시오. 핵심 규칙: 1. 항상 답해야 함. "unknown", "none", "N/A", "정보 부족"이라 말하지 말 것. 2. 부분 정보만 있어도 최선의 추론. 3. 비교 질문에 한 개체만 알면 그것으로 답. 답 형식 규칙 (정확히 준수): - 개체명·숫자·날짜·yes/no만 출력. - 전체 문장으로 답하지 말 것. - yes/no는 소문자. who는 풀네임만. - 요약의 철자를 정확히 복사.
프롬프트 전용 범위에서 세 모델을 독립 최적화했다(총 88개 변형). 최적 전략은 모델마다 다르다. 같은 과제라도 최적 프롬프트가 갈린다.
흔한 CWE 혼동쌍에 대한 NVD 매핑 규칙을 추가한다(예: 버퍼 오버플로 → CWE-787). 4줄 프롬프트가 23줄로 성장한다.
규칙 추가가 오히려 형식 추출을 해쳐, NVD 매핑 관례만 언급하는 2줄짜리 짧은 프롬프트가 최적이다(기준선의 절반).
"standard NVD abstraction level"이라는 문구 하나가 제거 실험에서 +2.9pp를 설명한다. Instruct 프롬프트와 거의 동일하다.
남은 오류 대부분은 모호한 CWE 라벨에서 비롯된다. 특히 버퍼 오버플로 설명에서 CWE-787 대 CWE-121/122가 그렇다. 이 결과는 동일한 과제·동일한 채점에서도 모델별로 최적 프롬프트가 근본적으로 다를 수 있음을 보여준다. 작은 모델에는 규칙을 더하는 것이 형식 추출을 방해해 오히려 손해였고, 더 짧은 프롬프트가 이겼다.
FAPO와 GEPA는 옵티마이저 설계와 허용 탐색 공간이 다르다. 이 비교는 정확한 공정성 매치라기보다 재현된 벤치마크 비교로 읽어야 한다.
FAPO는 GEPA보다 넓은 최적화 범위를 가진다(고정 DSPy 프로그램 내 명령 문자열 탐색에 한정된 GEPA와 달리). 비CTIBench-RCM 과제에서 FAPO는 동일 기준 파이프라인에서 출발하되 프롬프트를 먼저 시도한 후에만 사슬 파라미터·구조 수정이 허용되었다. 프롬프트 전용 부분집합에서도 FAPO가 12건 중 9건 우세하다. 이는 Claude Code 오케스트레이터의 깊은 반복적 추론 덕분으로 본다.
프롬프트 우선 탐색이 파이프라인 변경으로 에스컬레이션될 때 실행 간 변동이 크다. 이는 최적화 궤적의 경로 의존성을 반영한다. 어떤 시도는 구조적 개입을 발견하고, 어떤 시도는 프롬프트 수준에 머문다. 큰 표준편차는 매끄러운 분산이 아니라 구조적 개입을 발견했는지 여부를 주로 반영한다.
GPT-4.1-mini가 6개 중 4개 기준 벤치마크에서 GPT-5.4-mini를 앞선다. 동일한 16,000 토큰 예산이지만 프로바이더가 다르게 계산한다. GPT-5.4-mini는 숨은 추론+가시 출력을 합산하는 공유 예산이라, AIME·LiveBench-Math에서 매우 짧거나 형식이 깨진 답(중앙값 78 토큰)을 내 엄격한 추출 채점에 실패한다. 예산을 24k–28k로 올리고 높은 추론 노력을 켜야 경쟁력을 가졌다.
재현한 GEPA 점수는 발표 결과와 −3.78~+7.97pp 차이가 난다. 리플렉터 모델을 Amazon Bedrock의 Claude Opus 4.6(기본 설정)으로 교체했는데, 이는 HoVer·IFBench에서 GEPA를 강화했을 수 있다. 원 논문은 단일 시도, 본 연구는 3회 평균±표준편차를 보고한다.
자동 탈옥은 프롬프트를 이산 행동 공간으로 다루고, 검증기·점수를 피드백으로 삼아 테스트시간 연산으로 그 공간을 탐색한다. 기술적 계보는 보편적 적대 트리거에서 시작해 AutoPrompt·GCG의 토큰 수준 탐색, PAIR·TAP의 의미 수준 반복, AutoDAN의 유전 알고리즘으로 이어진다. 최근 시스템(EvoX, AdaEvolve, Claudini)은 이중 용도 연결을 명시화한다. Claudini는 Claude Code 에이전트로 화이트박스 적대 공격을 반복 발견하며, FAPO가 건설적 파이프라인 개선에 적용하는 것과 동일한 평가–분석–제안–반복 루프를 쓴다.
FAPO는 이 탐색 패턴의 건설적 연속이다. 평가–분석–제안–반복 루프는 유지하되, 목표를 하나의 배포 가능한 파이프라인 변형의 집계 검증 성능으로 바꾼다. 드문 성공적 실패의 확률을 최대화하는 대신, 과제 제약을 보존하며 사례 전반의 평균 행동을 개선한다.
플레이북을 읽고 범위 계약을 정의하며, 허용 최적화 지점을 선택하고 변형 생성·평가·결과 기록으로 루프를 구동한다.
규칙 기반 귀속과 LLM 검사로 평가 결과·실패 모드를 분석하고, 실패를 군집화하며 다음 최적화 수준을 추천한다.
범위 준수·플레이스홀더 무결성·유출·채점 호환성·상태 프로토콜·임포트 안전을 독립 검토한다.
테넌트 평가 설정을 실행하고 점수 요약과 출력 디렉터리를 반환한다.
비기준 변형·산출물을 제거해 작업 디렉터리를 기준선으로 복원한다(git 이력은 보존).
저장소 전역 가이드를 정의한다. 프로젝트 목적, 평가 워크플로, 코드 스타일, 테넌트 데이터 안전, GitHub 관례를 포함한다.
다단계 LLM 파이프라인은 검색·추론·서식·제어 흐름 사이의 상호작용으로 실패하며, 개선에는 고립된 프롬프트 하나를 튜닝하는 것 이상이 필요하다.
FAPO는 그 실패를 재현 가능한 최적화 루프로 바꾸는 Claude Code 기반 프레임워크다. 파이프라인을 평가하고, 중간 단계를 검사하고, 병목을 진단하고, 범위가 정해진 변경을 제안하고, 결과 변형을 검증한다. 프롬프트 편집에서 시작해, 귀속이 파이프라인 자체가 성능을 제약함을 가리킬 때만 구조로 에스컬레이션한다. 이 절차는 18개 모델–벤치마크 비교 중 15건에서 GEPA를 능가하고, CTIBench-RCM에서 세 보안 모델의 성능을 향상시킨다. 이는 파이프라인 인식·증거 근거 최적화가 범용 및 보안 중심 과제 모두에 기여할 수 있으며, FAPO가 더 신뢰할 수 있는 다단계 LLM 시스템을 향한 실용적 경로임을 보여준다.