최적화 타겟은 각 세대에서 AlphaEvolve가 극대화하는 단일 숫자를 나타냅니다. 평가자 코드를 작성하기 전에 다음 세 가지 질문에 답하세요.
이 숫자는 어떤 값을 나타내나요?
시스템에서 어떻게 계산하나요?
어디에서 계산이 실행되나요?
AlphaEvolve는 사람의 개입 없이 모든 후보 솔루션에 대해 자동화된 프로그래매틱 타겟 계산을 엄격하게 요구합니다. 이 자동화로 인해 이 문제가 AlphaEvolve에 적합해집니다. 사람이 솔루션의 품질을 수동으로 판단해야 하는 경우 AlphaEvolve가 솔루션을 검색할 수 없습니다.
다양한 최적화 목표와 검증 제약 조건에서 생성된 후보 솔루션의 성능을 추정할 때는 다음 사항을 고려하세요.
- 최적화 목표를 경험적 측정 없이 비즈니스 또는 제품 로직을 사용하여 직접 계산할 수 있나요?
- 생성된 솔루션의 코드에 성능 및 부하 테스트를 실행하여 최적화 목표를 직접 측정할 수 있나요?
- 확정적 대리 함수, 확립된 신뢰할 수 있는 시뮬레이션 방법을 사용하여 최적화 목표를 추정할 수 있나요?
- 실증적 관찰에 대한 조정과 아웃오브샘플 데이터에 대한 검증이 필요한 맞춤 대리 함수 (예: 예측 모델 또는 기타 비결정적 추정기)를 설계하여 최적화 목표를 추정할 수 있나요?
타겟을 정량화하기 위한 핵심 단계
구조화된 접근 방식을 따라 AlphaEvolve가 검색을 안내하는 안정적인 자동화된 피드백 루프를 갖도록 하세요. 다음 단계를 완료하여 측정항목을 설정하고, 측정 방법을 정의하고, 실행이 발생하는 위치를 결정합니다.
1. 타겟을 솔루션이 개선될수록 증가하는 단일 점수로 표현
검색 경로에 명확한 방향성 그라데이션이 있도록 핵심 최적화 측정항목을 실제 성능 향상과 함께 선형 또는 단조로 확장되도록 구성합니다.
스칼라 최대화: AlphaEvolve는 항상 하나의 스칼라 값을 최대화합니다. 관심 있는 모든 것을 숫자로 변환하세요. 숫자가 높을수록 좋습니다. 지연 시간, 비용 또는 오류를 최소화하려면 이를 부정하세요.
score = -latency_ms단조성: 점수는 단조여야 합니다. 솔루션이 실제로 개선될 때마다 점수가 상승해야 합니다. 일관성 없이 움직이는 점수는 검색에 상승할 방향을 제시하지 않습니다.
결정적 실행: 점수는 평가자에서 계산되며 LLM이나 사람이 계산하지 않습니다. 항상 동일한 후보가 동일한 점수를 받도록 결정론적으로 계산합니다.
주관적인 목표를 위한 컨조인트 분석: 점수 공식은 작성할 수 없지만 두 솔루션을 눈으로 비교할 수 있는 경우 컨조인트 분석을 사용하여 빌드합니다. 후보 출력 쌍을 생성하고, 도메인 전문가가 각 쌍에서 더 나은 것을 선택하도록 하고, 이러한 선택에 로지스틱 회귀를 적용하고, 적용된 모델을 측정항목으로 사용합니다. 이렇게 하면 주관적인 판단이 결정적이고 미분 가능한 점수로 바뀝니다. 원시 LLM 루브릭은 느리고, 노이즈가 많으며, 보상 해킹이 빠르므로 실시간 점수로 사용하지 마세요. 먼저 고정된 함수로 추출하세요.
2. 점수 계산 방식 선택
숫자를 생성하는 방법은 측정 대상에 따라 다릅니다. 표에서 목표에 맞는 방법을 선택합니다. 거의 모든 실제 배포에서는 이 네 가지 중 하나를 사용하며, 많은 경우 두 가지를 결합합니다. 검색을 유도하는 저렴한 방법과 승자를 확인하는 데 비용이 많이 드는 방법이 있습니다.
| 측정 방법 | 타겟이 다음과 같은 경우에 사용하세요. | 점수가 생성되는 방식 | 실행에 필요한 사항 |
|---|---|---|---|
| 직접 계산 | 비즈니스 또는 제품 로직을 사용하여 후보의 출력에서 폐쇄형으로 계산할 수 있는 수량 | 평가자가 후보를 실행하고 공식 (합계, 비율, 개수, 비용)을 적용합니다. | 컨트롤러 자체 프로세스 - 추가 인프라 없음 |
| 성능 또는 부하 테스트 | 후보 코드 자체의 런타임, 처리량 또는 메모리 | 대표 하드웨어에서 후보를 실행하고 측정합니다. 먼저 정확성을 기준으로 합니다. | 타겟 하드웨어 (GPU 또는 TPU 또는 CPU), 타이밍 노이즈를 줄이기 위한 워밍업 및 best-of-N |
| 결정론적 서러게이트 / 시뮬레이션 | 직접 측정하기에는 비용이 많이 들거나 노이즈가 많지만 신뢰할 수 있는 프록시 또는 실제 조건의 리플레이가 있음 | 결정적 프록시 계산 또는 고정된 시드 운영 시나리오 재생 | 모든 환경, 고정된 시드로 완전히 재현 가능 |
| 아웃샘플 검증 | 후보자가 생성하는 모델 또는 데이터 파이프라인의 품질 | 후보를 학습/적합시킨 다음, 보유 데이터 또는 새로 생성된 데이터에서 점수를 매깁니다. | 학습/평가 스택, 엄격한 학습 대 검증 분할, 보류된 세트에서 승자 재검증 |
자세한 내용은 Google Cloud 블로그의 AlphaEvolve 공지사항을 참고하세요.
이 중 어느 것도 자동으로 숫자를 생성할 수 없다면 아직 AlphaEvolve를 사용할 수 없습니다. 따라서 핵심 작업은 다음을 수행할 수 있는 대리 또는 시뮬레이션을 구성하는 것입니다.
3. 여러 목표와 제약 조건 처리
실제 목표는 일반적으로 여러 우려사항을 혼합합니다. 다음 두 가지 방법 중 하나를 사용하여 처리합니다.
스칼라 혼합 (가장 간단하며 시작하는 데 권장됨): 각 측정항목을 비교 가능한 범위로 조정하고 최소화할 측정항목을 부정하고 더합니다. score = w1*A - w2*L - w3*M
수치적으로 불안정한 A/(L⋅M)와 같은 비율보다 가산 합계를 사용하는 것이 좋습니다.
이름이 지정된 점수의 사전을 반환합니다. AlphaEvolve가 공동으로 최적화하도록 합니다. 평가자는 하나의 숫자 대신 여러 개의 명명된 측정항목을 반환할 수 있습니다.
```JSON
{
"scores": [
{"metric": "accuracy", "score": 0.95},
{"metric": "latency_ms", "score": -120.0}
]
}
```
각각의 값이 높을수록 좋으므로 최소화하는 값은 부정을 취합니다. 이는 보고뿐만 아니라 실제 다중 목표 검색을 트리거합니다. 인구 데이터베이스는 측정항목별 최적의 프로그램을 유지하고 (MAP-Elites) 측정항목 전반에서 파레토 프런티어를 유지하며 다양한 측정항목에서 부모를 다양하게 샘플링합니다. 이 샘플링이 사용 설정된 경우 파레토 프런티어에서 직접 상위 항목을 가져올 수도 있습니다. 보고된 언덕 오르기는 여전히 단일 광고 제목 점수에 의해 결정되지만 반환된 모든 측정항목이 검색을 형성합니다.
3~5개의 측정항목 유지: 측정항목이 너무 많으면 파레토 우위가 거의 모든 프로그램이 어떤 면에서든 우위를 점하지 못하고 검색이 방황하는 방향으로 퇴화합니다. 이 기준점을 초과하는 측정항목은 집계하거나 삭제합니다.
정확성과 가능성 분리: 정확성을 보상 함수의 일부가 아닌 엄격한 게이트로 유지합니다. 잘못되었거나 불가능한 후보자는 얼마나 빠르고 저렴한지와 관계없이 실패 점수를 받습니다. 이는 에이전트가 측정항목을 조작하는 것을 방지하는 기본 방어입니다.
제약 조건 최적화: 한 목표를 제약 조건으로 유지하고 다른 목표를 최적화하며 제약 조건이 위반되면 불이익을 적용합니다. 여러 제약 조건 수준에서 이 워크플로를 실행하면 파레토 프런티어가 추적됩니다.
4. 평가자가 실행되는 위치 결정
AlphaEvolve는 평가자를 직접 실행하지 않습니다. 후보 프로그램을 제안하고 점수를 수신합니다. 점수를 계산하는 코드를 호스팅하고 실행합니다. 환경은 전적으로 선택사항이며Google Cloud 에서 실행할 수 없는 후보는 차단기가 아닙니다. 목표를 측정할 수 있는 곳에서 평가자를 실행하고 점수를 다시 제출합니다.
효율적이고 안전한 배포를 위해서는 범용 실행 제한을 준수하면서 컴퓨팅 인프라를 특정 측정 전략에 맞춰야 합니다. 다음 가이드라인을 사용하여 실행 환경을 선택하고 모든 설정에 적용되는 핵심 운영 경계를 파악하세요.
실행 환경을 측정 방법과 일치시킴
직접 계산 또는 대리: 컨트롤러의 자체 프로세스 또는 단일 Cloud Run 컨테이너입니다.
성능 또는 부하 테스트: GKE의 GPU 또는 TPU 노드, 자체 온프레미스 또는 맞춤 하드웨어, 서드 파티 또는 ISV 도구 (예: EDA 또는 Verilog 시뮬레이터)와 같은 타겟 하드웨어
샘플 외 검증 또는 대규모 작업: 학습 스택이 Cloud Run 또는 GKE에 분산되거나 대규모 HPC 또는 액셀러레이터 워크로드용 클러스터 툴킷을 사용하여Google Cloud batch로 오프로드됩니다.
환경과 관계없이 두 가지 한도가 적용됩니다.
진화 루프가 계속 진행되도록 각 평가를 10분 이내로 유지하세요. 비용이 많이 드는 목표의 경우 평가 캐스케이드를 사용하여 모든 후보자를 확인하고 유망한 후보자에게만 전체 평가를 실행합니다.
평가자의 네트워킹, 보안, 액세스 제어를 소유합니다. AlphaEvolve는 Google Cloud또는 다른 곳에 평가자를 배포하거나 관리하지 않습니다.
측정항목, 계산 방법, 실행 위치를 결정한 후에는 평가자 구현 패턴에서 평가자 구조를 확인하세요.