URL: https://www.youtube.com/watch?v=OA-Mc60Rboo 날짜: 2026-09-27 채널: aiDotEngineer
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
==강화학습이 롤아웃 전체의 풍부한 정보를 단일 보상 점수로 압축해 버리는 상황에서, 텍스트로 된 성찰과 Pareto 후보군을 사용해 훨씬 적은 샘플로 AI 시스템을 개선할 수 있는가?==
- 기존의 사전학습·지도 미세조정·강화학습은 대규모 가중치 업데이트와 막대한 예시·롤아웃을 요구한다.
- GEPA(Genetic-Pareto 계열의 reflective prompt optimization)는 체인의 사고, 도구 호출, 환경 응답, 오류 메시지 등 롤아웃의 전체 추적을 읽고 더 나은 프롬프트를 자연어로 제안한다.
- 한 번의 성찰에서 얻은 새 프롬프트를 단순히 최고 점수 하나만 따라가는 대신, 서로 다른 사례에서 강점을 보인 후보들의 Pareto pool에 보존해 지역 최적점 탈출을 돕는다.
- 같은 원리는 프롬프트를 넘어 코드, 에이전트 하니스, 스킬, 수치, 클라우드 스케줄링 정책처럼 텍스트로 표현하고 점수화할 수 있는 모든 대상을 최적화하는 Optimize Anything으로 확장된다.
GEPA는 도메인별 데이터와 실행 피드백이 부족한 현실에서, 작은 수의 문제를 실행하고 그 실행에서 나온 actionable side information을 자연어 최적화기에 제공한다. 발표에 제시된 사례들은 3개 예시와 한 차례 성찰만으로 GRPO의 25,000회 롤아웃 결과보다 두 배 큰 성능 이득을 얻고, ARC-AGI 에이전트를 32.5%에서 89.5%로 올리며, GPT-5 mini 기반 코딩 에이전트를 24%에서 93%로 개선하는 식으로 텍스트 공간의 샘플 효율을 보여준다.
1. 가중치 업데이트 중심 AI의 샘플 효율성 한계
AI가 새 작업을 배우는 전통적 방법은 모델 파라미터를 바꾸는 것이지만, 실제 제품과 에이전트 환경에서는 데이터와 실행 비용이 병목이 된다.
1.1. 새 작업 학습과 막대한 자원 요구
-
표준 학습 패러다임
- 사전학습(Pre-training): 경사하강법으로 가중치를 업데이트하며 수조 개의 토큰을 사용한다.
- 지도 미세조정(Supervised Fine-tuning): 수만 개의 라벨이 붙은 예시가 필요하다.
- 강화학습(Reinforcement Learning): 수학·코딩 같은 영역에서 수십만 회의 롤아웃을 수행하고 보상으로 모델을 업데이트한다.
-
현실의 샘플 부족
- 도메인 지식의 희소성: 특정 하드웨어, 사내 저장소, 전문 업무에 필요한 자료가 인터넷에 충분히 존재하지 않아 SFT용 오프라인 데이터셋을 만들기 어렵다.
- 데이터보다 비싼 실행: 에이전트 파이프라인은 도구를 호출하며 몇 시간씩 실행될 수 있고, 롤아웃 자체나 평가 지표 계산이 느리고 비싸다.
- 온라인 학습의 비현실성: 한 번의 에이전트 실행이 오래 걸리는 상태에서 수십만 롤아웃을 요구하는 온라인 알고리즘은 제품 환경에서 감당하기 어렵다.
1.2. verified-reward RL이 버리는 정보
-
GRPO식 처리 흐름
- 모델과 작업이 주어지면 여러 롤아웃을 병렬로 실행한다.
- 각 롤아웃이 끝날 때 보상 하나를 얻고, GRPO 같은 알고리즘이 보상을 그래디언트로 바꾸어 모델에 적용한다.
-
O(1) 점수로 압축되는 전체 경험
- 롤아웃 안에는 체인의 사고, 실제 도구 호출, 도구에 대한 환경 응답이 들어 있다.
- 환경이 반환한 오류 메시지는 무엇이 잘못됐는지 알려 주는 진단 정보인데도, 최종 0/1 또는 단일 점수로 압축되는 순간 거의 학습에 사용되지 않는다.
- 한 번의 실행이 제공하는 도메인 특화 정보의 양에 비해 가중치 학습이 보존하는 신호는 극히 작다.
1.3. 텍스트 공간의 성찰이라는 대안
-
전체 추적을 읽는 reflective optimization
- 언어 모델 또는 에이전트가 롤아웃의 전체 trace를 읽고 무엇이 잘됐고 무엇이 실패했는지 성찰한다.
- 성찰기는 중간 출력, 오류, 도구 결과를 이용하며 필요하면 회사 지식 베이스나 가이드·교과서에서 검색하는 추가 도구 호출도 수행할 수 있다.
-
프롬프트의 큰 변화와 가중치의 작은 변화
- 한 줄 요약을 생성하라는 프롬프트를 열 줄 요약을 생성하라고 한 단어만 바꿔도 시스템 행동은 크게 달라진다.
- 사람이 자신의 행동을 돌아보고 한 단어를 바꾸는 데는 짧은 시간이 걸리지만, 가중치가 같은 행동 변화를 얻으려면 수천 번의 아주 작은 그래디언트 업데이트가 순차적으로 필요하다.
- 따라서 자연어 업데이트 하나가 행동을 크게 바꾸는 텍스트 공간은 제한된 샘플과 실행 예산에서 유리하다.
2. GEPA: 텍스트 공간에서의 진화적 성찰 최적화
GEPA는 에이전트 프롬프트를 진화적 루프로 개선하며, 점수와 텍스트 피드백을 함께 사용한다.
2.1. GEPA의 기본 아이디어와 성능 비교
-
RL을 텍스트 공간으로 옮긴 구조
- GEPA는 단순한 보상 점수만 받지 않고 점수와 도메인별 텍스트 피드백을 함께 받는다.
- 성찰 모델이 피드백을 읽고 문제의 목적, 입력 해석 방식, 파이프라인의 역할, 데이터에서 얻은 교훈이 담긴 개선 프롬프트를 쓴다.
-
GRPO 대비 샘플 효율
- 세 개의 데이터 포인트만 사용한 한 번의 성찰에서 GEPA가 얻은 성능 이득은 GRPO가 25,000회 롤아웃 후 얻은 이득의 두 배였다.
- 성찰 라운드를 몇 번 더 실행하면 두 방법의 격차가 다시 약 두 배 커졌다.
- 해당 비교에서 모델 자체가 자기 프롬프트를 최적화했으며, 외부 전문가 교사나 별도 expert teacher는 사용되지 않았다.
2.2. GEPA가 발견하는 도메인 명세
-
멀티홉 질의응답의 두 번째 검색 홉
- 입력 질문에서 첫 번째 홉이 한 개의 엔터티나 한 측면을 다루는 문서를 찾으면, 두 번째 홉은 그 문서와 관련된 다른 문서를 회수해야 한다.
- GEPA는 두 번째 홉의 프롬프트에 입력을 해석하는 방식, 현재 파이프라인 구성요소의 목적과 맥락, 데이터에서 관찰한 핵심 교훈을 구체적으로 적었다.
- 모델 엔지니어가 새 모델 출시 후 몇 주 동안 단어를 하나씩 수동으로 바꾸며 찾아야 했던 문제 명세를 약 30분에서 1시간 안에 자동으로 발견했다.
-
프롬프트에 도메인 지식을 증류
- 이전 프롬프트 최적화기가 “좋은 프롬프트를 만들지 않으면 할머니가 화낼 것” 같은 모델의 기벽이나 감정적 문구에 기대는 경우가 있었지만, GEPA는 실제 작업 구조와 데이터 관찰을 명세로 쓴다.
- GPT-4.1 mini에 적용했을 때 수학 작업에서 GPT-4.1의 성능을 넘어섰고, 외부 모델 교사 없이 프롬프트 안에 문제 해결 지식을 증류했다.
2.3. AMD NPU 사례: 인터넷에 없는 하드웨어 지식
-
희소한 문서와 낮은 초기 성능
- AMD의 새 하드웨어 가속기 NPU XDNA2는 프로그래밍 API가 완전히 새로워 인터넷에서 얻을 수 있는 정보가 거의 없었다.
- 당시 선도 모델인 GPT-4는 이 작업을 매우 낮은 수준으로 수행했고, 기존 에이전트의 성공률도 약 4.25%에 머물렀다.
-
실행 피드백에서 찾아낸 금지사항
- 에이전트 코드나 다른 구성요소를 바꾸지 않고 GEPA를 적용해 성능을 30.52%로 올렸다.
- 이는 약 7배 개선이며, 영상 설명에서는 초기 4%에서 30%로 반올림해 제시했다.
- GEPA는 한 단계 만에 AMD가 NPU 프로그래밍에 제공하는 ADF.h 라이브러리가 작업 중인 최신 하드웨어 세대에서는 작동하지 않으므로 포함하지 말라는 사실을 발견했다.
- 인터넷 문서에 없는 이런 세부사항도 도구 호출의 오류와 환경 피드백이 남아 있으면 프롬프트의 실행 규칙으로 바꿀 수 있다.
2.4. 알고리즘 루프와 Pareto pool
-
세 단계의 단순한 실행 루프
- 어떤 에이전트 프레임워크나 원시 LLM 호출로 작성한 AI 파이프라인을 몇 가지 예시에 실행하고, 환경이 제공하는 도메인 특화 피드백을 수집한다.
- LLM 또는 에이전트가 그 피드백을 읽고 더 나은 프롬프트 후보를 제안한다.
- 적어도 하나의 학습 예시에서 승리한 모든 후보를 Pareto pool에 보존한다. 전체 평균 점수가 가장 높은 후보 하나만 남기지 않는다.
-
단순 반복 개선이 지역 최적점에 갇히는 이유
- 시드 프롬프트에서 출발해 매번 현재 노드보다 좋아 보이는 후보만 택하는 LLM 루프는 어느 중간 프롬프트에서 지역 최적점에 도달할 수 있다.
- 다음 개선 제안이 실제로 더 좋지 않으면 루프는 같은 영역을 반복 탐색하고, 결국 모든 검색 예산을 소진한다.
-
Pareto 기반 선택의 효과
- 한 문제에서 강한 후보와 다른 문제에서 강한 후보를 함께 남기면 탐색이 한 방향으로 고착되지 않고 균형 있게 진행된다.
- 네 개 벤치마크에서 GEPA가 얻은 이득의 절반 이상이 Pareto 후보 선택에서 비롯됐고, 단순히 모델을 루프에 넣은 방법보다 성능 이득이 거의 두 배였다.
2.5. 여러 벤치마크에서 확인한 일반성
-
프롬프트 최적화 성능
- 질의응답, 지시 따르기, 주장 검증, 수학 등 선도 모델 회사가 이미 많이 최적화한 작업에서도 프롬프트만 조정해 10% 이상 추가 성능을 얻었다.
- 강력한 기반 모델이어도 도메인에 맞는 명세가 빠져 있으면 텍스트 성찰로 상당한 개선 여지가 남는다.
-
프롬프트를 넘어서는 확장
- 프롬프트는 AI 시스템 행동을 결정하는 텍스트 산출물 중 하나일 뿐이다.
- 에이전트 하니스 전체가 결국 Python이나 JavaScript 파일이라면 같은 방식으로 그 파일을 읽고 실행·평가하고 개선할 수 있다.
- “텍스트로 쓸 수 있고 점수를 매길 수 있다면 GEPA가 최적화할 수 있다”는 일반화가 Optimize Anything의 출발점이 된다.
3. Optimize Anything: 텍스트로 표현되는 모든 시스템의 최적화
Optimize Anything은 GEPA의 성찰·Pareto 탐색을 임의의 텍스트 파라미터와 도메인 평가기에 적용하는 범용 API다.
3.1. 텍스트 파라미터와 evaluator의 결합
-
코드 최적화
- CUDA 커널 코드가 후보 텍스트가 되고 evaluator가 코드를 컴파일하고 프로파일링한다.
- 실행 속도, 컴파일 결과, 프로파일러 정보 같은 actionable side information을 LLM에 보내면 LLM이 개선된 커널 후보를 제안한다.
- 후보를 Pareto pool에 유지하며 수렴할 때까지 실행·성찰·개선을 반복한다.
-
다른 텍스트화 가능한 대상
- 숫자 벡터도 텍스트로 직렬화하면 수치 최적화에 사용할 수 있다.
- 에이전트 하니스 전체, 에이전트 스킬, 프롬프트, 휴리스틱 알고리즘도 텍스트 후보가 된다.
- 클라우드 스케줄링 정책은 정책 또는 휴리스틱을 텍스트로 표현하고, 비용의 음수나 정확도·효율 함수를 점수로 사용할 수 있다.
- 스케줄러 로그의 job trace와 SLA 위반 기록은 다음 후보를 만드는 actionable side information이 된다.
3.2. 최소 API와 피드백 사전
-
사용자가 제공하는 두 가지 핵심 요소
- 해결하고 싶은 문제들의 집합을 전달한다.
- 후보를 평가해 점수 또는 fitness를 반환하는 evaluator function을 전달한다.
-
가능한 부가 정보
- 전문가가 작성한 피드백, 컴파일러 오류 메시지, 프로파일러 메시지, 도구 호출 오류를 그대로 반환할 수 있다.
- 사내 문서나 작업 설명서처럼 글로 쓰인 자료도 반환할 수 있다.
- API의 side information은 열린 dictionary라서 정해진 형식에 얽매이지 않고 도메인이 생성하는 어떤 정보든 담을 수 있다.
- 사용자는 objective와 문제 집합만 정의하고 optimize anything을 호출하면 최적화된 솔루션을 받는다.
3.3. 3D 유니콘과 코드 자체의 개선
-
3D 유니콘 예시
- 목표는 3D 유니콘을 생성하는 Python 프로그램을 작성하는 것이다.
- 후보는 PNG 렌더링을 생성하는 Python 스크립트이며, evaluator는 생성 결과를 평가한다.
- Claude Opus 4.6이 직접 만든 결과와 Optimize Anything이 개선한 결과를 나란히 비교하는 재미를 위한 사례가 제시됐다.
-
에이전트 하니스 발견
- 복잡한 에이전트를 사람이 만들 때는 도구, 도구 설명, 제어 흐름, 프롬프트를 오랫동안 수동 조정해야 한다.
- Optimize Anything은 체인의 사고로 ARC-AGI를 풀던 네 줄짜리 Python 프로그램에서 시작해 16번의 성찰 라운드 안에 정교한 여섯 단계 에이전트를 발견했다.
- 발견된 에이전트는 규칙 가설을 유도하고, 코드를 합성하고, 코드를 실행·추적하고, 자동 디버깅하고, 수정된 코드를 다시 제안한 뒤, 실제 테스트 입력에 실행해 결과를 반환한다.
- Gemini Flash의 ARC-AGI 정확도는 32.5%에서 89.5%로 상승했으며, 발표 화면의 QR 코드로 실행 가능한 예제가 제공됐다.
3.4. MATH-500 에이전트 아키텍처
-
두 단계 에이전트의 자동 발견
- MATH-500에서 GPT-4.1 nano에 Optimize Anything을 적용해 에이전트 파일 자체를 최적화했다.
- 사용자가 한 일은 목표와 작업을 지정한 것뿐이며, 도구를 직접 설계하거나 아키텍처를 수동으로 고르지 않았다.
- Optimize Anything이 두 단계 에이전트를 발견했고 GPT-4.1 nano의 정확도를 약 20% 높였다.
-
핵심 의미
- 최적화 대상은 모델 가중치가 아니라 실행 가능한 에이전트 구조가 될 수 있다.
- 도메인 실행 결과와 오류를 읽는 성찰기가 사람이 설계하던 반복적인 하니스 탐색을 자동화한다.
4. 에이전트 스킬과 배포 시스템에 대한 적용
GEPA는 에이전트가 작업을 반복할 때 재사용할 수 있는 스킬과 여러 문제에 대한 일반화까지 최적화한다.
4.1. Go 저장소 이슈 해결 스킬
-
스킬 학습 목표
- 자연어로 “이 trajectory에서 스킬을 학습하고, 코딩 에이전트가 비슷한 문제를 만났을 때 그 스킬이 도움이 되게 하라”고 정의한다.
- 스킬은 저장소 구조, 테스트 호출 방법, 기능 구현 위치, 빌드 시스템을 포함해 에이전트의 다음 실행을 안내한다.
-
저예산 모델에서의 개선
- 예산 제약 때문에 GPT-5 mini 기반 에이전트로 시작했지만 Go 저장소 이슈 해결 성능이 24%에서 93%로 상승했다.
- 이는 약 3배에 가까운 점프이며, 프롬프트만 고친 것이 아니라 실행 trajectory에서 재사용 가능한 repository skill을 발견한 결과다.
4.2. 모델 간 스킬 전이
-
싼 모델에서 비싼 모델로의 전이
- GPT-5 mini에서 저렴하게 최적화한 스킬을 최신 Claude Sonnet에 적용할 수 있었다.
- 당시 Claude Sonnet 4.5의 이슈 해결 정확도는 100%에 도달했다.
-
정확도와 실행 시간의 동시 개선
- 이슈 해결 시간이 거의 50% 줄어 절반 수준이 됐다.
- 실행 시간이 줄면서 토큰 사용량도 감소했고, 저장소 구조·테스트·빌드 정보가 스킬에 미리 들어 있어 같은 탐색을 매번 반복하지 않아도 됐다.
- 이 기능은 GSkill로 불리며 GEPA 저장소에서 완전한 오픈 소스로 제공된다.
4.3. Optimize Anything의 세 가지 최적화 모드
-
단일 문제 검색(Single-problem search)
- 하나의 행렬 곱셈 커널처럼 특정 후보 하나만 최적화할 때 사용한다.
- evaluator가 그 하나의 작업에서 만드는 점수와 실행 정보를 바탕으로 후보를 개선한다.
-
다중 작업 검색(Multitask search)
- 행렬 곱셈 커널과 내적 커널처럼 서로 관련된 여러 문제를 함께 최적화할 때 사용한다.
- 문제 사이의 정보 전이를 허용해 한 문제에서 얻은 통찰이 다른 문제의 후보 개선에도 기여한다.
-
스킬·일반화 모드
- 배포 시 새로운 종류의 문제가 들어오므로, 학습 예시에서 직접 점수가 높았던 문구만 복사하는 대신 새 문제에도 적용되는 스킬을 만든다.
- 수학 프롬프트 최적화처럼 일부 예시로 훈련하고 완전히 새로운 질의를 배포 단계에서 받아야 하는 경우에 적합하다.
- 이 모드에서 프롬프트, 에이전트 아키텍처, 스킬 등 텍스트 행동 규칙을 함께 최적화할 수 있다.
5. 실제 적용과 비용·품질의 변화
Optimize Anything은 연구 벤치마크뿐 아니라 스케줄링, VLM, 배포 에이전트, 오픈 모델 비용에도 적용된다.
5.1. 클라우드 스케줄링과 수학 최적화
-
클라우드 정책 최적화
- 스케줄링 정책과 휴리스틱을 텍스트 후보로 만들고 job trace와 SLA 위반을 피드백으로 제공한다.
- 전문가가 만든 휴리스틱 대비 비용을 약 40% 줄였다.
-
블랙박스 수학 최적화
- 사용자 정의 solver를 직접 설계하지 않고 텍스트 표현과 evaluator를 조합해 최적화한다.
- Optuna와 비교해 맞먹거나 더 나은 결과를 내는 custom solver를 생성할 수 있었다.
5.2. VLM OCR과 Databricks 배포 사례
-
VLM OCR
- GEPA가 선도 VLM의 OCR 오류율을 약 35% 줄였다.
- 이 결과는 외부에서 검증된 보고서로 제시됐다.
-
Databricks의 비용 절감
- Databricks는 GPT-OSS 120B를 튜닝해 Claude Opus보다 높은 성능을 내면서 비용을 90배 낮췄다.
- 오픈 모델에서의 단순한 개선뿐 아니라 Claude Opus 위에서 얻은 성능 델타도 오픈 모델보다 더 크게 나타났다.
- 모델 가격이 싸다는 이유만으로 얻은 결과가 아니라, 작업 지침과 배포 에이전트를 텍스트 공간에서 정밀하게 조정한 결과다.
5.3. 강한 모델일수록 정밀한 프롬프트가 필요한 이유
-
반대 방향의 가설
- 모델이 더 좋아지면 프롬프트 최적화의 중요성이 낮아질 것이라는 질문이 제기된다.
- 발표자는 오히려 반대라고 답한다.
-
명령 따르기 능력과 명세의 정밀도
- 더 강한 모델은 지시를 더 잘 따르므로, 목표 작업을 정확히 기술한 지시를 제공할 때 능력을 더 많이 발휘한다.
- 실제 사례에서도 더 좋은 프롬프트를 제공했을 때 Claude Opus의 성능 상승폭이 더 높았다.
- 모델이 똑똑해질수록 모호한 지시가 아니라 도메인 목적·예외·절차를 담은 정밀한 명세가 중요해진다.
6. 주관적 작업의 평가와 지속적 개선
객관적인 정답이 없는 작업에서도 생산 trace와 소량의 사람 피드백으로 evaluator를 만들 수 있다.
6.1. 50개 사람이 주석한 trajectory로 LLM judge 만들기
-
생산 trace 수집
- 실제 에이전트가 운영 환경에서 만든 trajectory를 다수 수집한다.
- 모든 trace를 사람이 평가할 필요 없이 약 50개만 골라 자세히 주석한다.
-
주석의 형태
- 어떤 응답이 긴 응답인지, 짧은 응답인지, 좋은 응답인지 표시한다.
- 특정 용어를 사용했는지, 절차를 지켰는지, 원하는 품질 기준을 만족했는지처럼 도메인에 맞는 설명을 덧붙인다.
-
평가기를 다시 최적화에 사용
- GEPA로 사람이 작성한 기준을 반영한 LLM-as-a-judge 프롬프트를 최적화한다.
- 이 judge가 생산 trace를 평가하도록 하고, 그 평가 점수를 다시 에이전트 최적화에 사용한다.
- 새 trace를 모으고 다시 주석·judge 개선·에이전트 개선을 거치는 데이터 플라이휠이 형성된다.
- 이 방식은 이미 일부 선도적인 운영 팀이 사용하는 성공적인 패러다임으로 소개됐다.
6.2. Fast-slow learning: 프롬프트와 가중치의 공동 최적화
-
모델 학습으로의 확장
- reflective optimization으로 실제 모델을 훈련할 수 있는지에 대한 질문에 답하기 위해 “Learning Fast and Slow” 논문이 소개됐다.
- 빠르게 변하는 프롬프트·하니스와 느리게 변하는 모델 가중치를 함께 최적화하는 fast-slow learning을 제안한다.
-
지속적 학습에 필요한 성질
- 한 번에 모든 지식을 가중치에 밀어 넣지 않고, 즉시 바꿀 수 있는 텍스트 하니스와 장기적으로 축적되는 가중치를 함께 사용한다.
- 발표에서는 세부 결과를 다 다룰 시간이 없으므로 관련 논문을 확인하라는 안내가 이어졌다.
7. 생태계, 사용성, 실행 지침
GEPA는 특정 모델이나 에이전트 프레임워크에 묶이지 않고 연구와 제품 환경에 연결되는 공개 도구로 제시됐다.
7.1. 실제 사용과 공개 생태계
-
제품·연구 사용
- GEPA는 공개 이후 여러 기업의 프로덕션 환경에서 사용됐고 여러 논문의 주요 방법론으로 채택됐다.
- Dropbox와 Shopify의 CEO가 GEPA 사용을 언급했으며, OpenAI도 GEPA로 자기개선 AI 시스템을 만드는 방법에 관한 블로그 글을 작성했다.
-
시작 장벽
- 어떤 에이전트 프레임워크와 모델에도 연결할 수 있다.
- 하드 의존성이 전혀 없어 특정 배포 환경에 맞추기 쉽다.
- 문제를 텍스트 후보와 점수 함수로 재구성할 수 있다면 별도의 거대한 가중치 학습 파이프라인 없이 적용을 시작할 수 있다.
7.2. 실전 적용 순서
-
목표와 평가기 정의
- 실제로 개선하고 싶은 문제 집합을 고른다.
- 정확도·비용·실행 시간·오류율·SLA 위반 등 목적에 맞는 fitness/evaluator를 만든다.
-
실행 trace에서 신호를 보존
- 최종 점수만 저장하지 말고 체인의 사고, 도구 결과, 컴파일러·프로파일러·환경 오류, job trace를 evaluator의 side information으로 반환한다.
- 사내 문서와 전문가 피드백도 열린 dictionary에 담아 성찰기가 도메인 맥락을 읽게 한다.
-
탐색과 일반화 관리
- 현재 최고 점수 후보 하나만 덮어쓰지 말고 서로 다른 문제에서 이긴 후보를 Pareto pool에 보존한다.
- 학습 예시의 점수만 높이는 것이 아니라 새 질의·새 저장소·새 실행 환경으로 전이되는 스킬을 최적화한다.
주요 발언 모음
“강화학습은 롤아웃 전체를 하나의 점수로 압축한다. GEPA는 전체 trace를 읽고 무엇이 작동했고 무엇이 작동하지 않았는지 성찰한다.”
“텍스트로 쓸 수 있고 점수를 매길 수 있다면 GEPA가 최적화할 수 있다.”
“모델이 좋아질수록 프롬프트 최적화의 중요성이 내려가는 것이 아니라, 더 정밀한 지시가 더 똑똑한 모델의 능력을 끌어낸다.”
“최적화기에 actionable side information을 가능한 한 많이 제공하라.”
“텍스트 공간에서 최적화하는 것을 두려워하지 말라. 많은 문제가 최적화 문제로 재구성될 수 있다.”
핵심 데이터 & 수치
- 3개 예시 대 25,000회 롤아웃: GEPA는 한 번의 성찰과 세 데이터 포인트로 GRPO가 25,000회 롤아웃 후 얻은 성능 이득의 약 두 배를 얻었다.
- 추가 성찰 효과: 몇 라운드를 더 실행하자 GEPA와 GRPO의 성능 격차가 다시 약 두 배 커졌다.
- 실행 시간: 멀티홉 QA의 도메인 프롬프트 탐색은 파이프라인에 따라 약 30분~1시간 걸렸다.
- AMD NPU XDNA2: 기존 에이전트 약 4.25%에서 30.52%로 상승했으며 약 7배 개선됐다.
- GPT-4.1 mini: 수학 작업에서 최적화된 GPT-4.1 mini가 GPT-4.1을 넘어섰다.
- ARC-AGI: Gemini Flash 기반 에이전트가 4줄짜리 프로그램에서 16회 성찰 후 6단계 에이전트로 발전했고 정확도가 32.5%에서 89.5%로 올랐다.
- MATH-500: GPT-4.1 nano의 에이전트 파일을 최적화해 정확도를 약 20% 개선했다.
- Go 저장소 이슈: GPT-5 mini 에이전트의 이슈 해결 성능이 24%에서 93%로 상승했다.
- Claude Sonnet 4.5 전이: 같은 스킬을 적용해 이슈 해결 정확도 100%, 해결 시간이 거의 50% 단축됐다.
- 클라우드 스케줄링: 전문가 휴리스틱 대비 비용을 약 40% 줄였다.
- VLM OCR: 선도 모델의 OCR 오류율을 약 35% 줄였다.
- Databricks: GPT-OSS 120B가 Claude Opus보다 높은 성능을 내면서 비용은 90배 낮아졌다.
- 주관적 평가: 약 50개 생산 trajectory에 상세한 사람 주석을 달아 LLM judge를 만들 수 있다.
결론 및 시사점
- 강화학습의 최종 보상은 실행 trace에 있는 오류 원인·도구 결과·중간 추론을 지나치게 많이 버리므로, 먼저 그 정보를 텍스트 피드백으로 보존하는 것이 샘플 효율 개선의 출발점이다.
- GEPA는 가중치를 매번 미세하게 움직이는 대신 자연어 프롬프트와 에이전트 파일을 성찰로 크게 수정하고, Pareto pool로 서로 다른 강점을 가진 후보를 유지한다.
- 실제 적용에서는 최종 점수만 반환하지 말고 컴파일러 오류, 프로파일러 정보, 도구 실패, 사내 문서, 전문가 피드백, 운영 trace를 actionable side information으로 evaluator에 연결해야 한다.
- 최적화 대상은 프롬프트뿐 아니라 CUDA 커널, 숫자, 에이전트 하니스, 스킬, 클라우드 정책, LLM judge까지 확장할 수 있다.
- 객관적 정답이 없는 작업도 약 50개의 상세 주석 trace로 judge를 만든 뒤, judge와 에이전트를 번갈아 개선하는 데이터 플라이휠로 다룰 수 있다.
- 강한 기반 모델을 선택하는 것만으로 충분하지 않으며, 모델의 능력을 작업 목적에 맞게 끌어낼 정밀한 도메인 명세가 필요하다.
- 새 AI 시스템을 만들 때 처음부터 대규모 가중치 학습을 전제로 하기보다, 문제 집합·평가기·side information을 정의하고 텍스트 공간에서 빠른 탐색을 시작하는 것이 현실적인 실행 순서다.
