최적화 타겟은 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 또는 가속기 워크로드를 위해 Cluster Toolkit을 사용하여Google Cloud 배치로 오프로드된 학습 스택입니다.
환경에 관계없이 두 가지 한도가 적용됩니다.
진화 루프가 계속 진행되도록 각 평가를 약 10분 이내로 유지합니다. 비용이 많이 드는 목표의 경우 평가 캐스케이드를 사용하여 모든 후보를 확인하고 유망한 후보에 대해서만 전체 평가를 실행합니다.
평가자의 네트워킹, 보안, 액세스 제어를 소유합니다. AlphaEvolve는 Google Cloud또는 다른 곳에서 평가자를 배포하거나 관리하지 않습니다.
측정항목, 계산 방법, 실행 위치를 결정했으면 평가자 구현 패턴에서 평가자를 구성하는 방법을 참조하세요.