최적화 타겟은 각 세대에서 AlphaEvolve가 극대화하는 단일 숫자를 나타냅니다. 평가자 코드를 작성하기 전에 다음 세 가지 질문에 답하세요.
이 숫자는 어떤 값을 나타내나요?
시스템에서 이 값을 어떻게 계산하나요?
계산은 어디에서 실행되나요?
AlphaEvolve는 사람의 개입 없이 모든 후보 솔루션에 대해 자동화된 프로그래매틱 타겟 계산을 엄격하게 요구합니다. 이 자동화로 인해 문제가 AlphaEvolve에 적합하게 됩니다. 사람이 솔루션의 품질을 수동으로 판단해야 하는 경우 AlphaEvolve는 솔루션을 검색할 수 없습니다.
다양한 최적화 목표 및 검증 제약조건에서 생성된 후보 솔루션의 실적을 추정하려면 다음 고려사항을 사용하세요.
- 경험적 측정이 필요 없이 비즈니스 또는 제품 로직을 사용하여 최적화 목표를 직접 계산할 수 있나요?
- 생성된 솔루션의 코드에서 성능 및 부하 테스트를 실행하여 최적화 목표를 직접 측정할 수 있나요?
- 결정론적 서로게이트 함수를 사용하여 최적화 목표를 추정할 수 있나요? 신뢰할 수 있는 시뮬레이션 방법이 있나요?
- 경험적 관찰에 대한 조정과 샘플 외 데이터에 대한 검증이 필요한 맞춤 서로게이트 함수 (예: 예측 모델 또는 기타 비결정론적 추정기)를 설계하여 최적화 목표를 추정할 수 있나요?
타겟 정량화를 위한 핵심 단계
AlphaEvolve가 검색을 안내하는 안정적인 자동화된 피드백 루프를 갖도록 구조화된 접근 방식을 따르세요. 다음 단계를 완료하여 측정항목을 설정하고, 측정 방법을 정의하고, 실행이 발생하는 위치를 결정하세요.
1. 솔루션이 개선됨에 따라 증가하는 단일 점수로 타겟 표현
검색 경로에 명확한 방향 그라데이션이 있도록 핵심 최적화 측정항목을 실제 실적 향상에 따라 선형 또는 단조롭게 확장하도록 구성합니다.
스칼라 극대화: AlphaEvolve는 항상 하나의 스칼라 값을 극대화합니다. 관심 있는 모든 것을 더 높을수록 더 좋은 단일 숫자로 변환합니다. 지연 시간, 비용 또는 오류를 최소화하려면 이를 부정합니다.
score = -latency_ms단조성: 점수는 단조로워야 하며 솔루션이 실제로 개선될 때마다 증가해야 합니다. 일관성 없이 이동하는 점수는 검색에 상승할 방향을 제공하지 않습니다.
결정론적 실행: 점수는 평가자에서 계산되며 LLM이나 사람이 계산하지 않습니다. 동일한 후보가 항상 동일한 점수를 받도록 결정론적으로 계산합니다.
주관적 목표에 대한 컨조인트 분석: 스코어링 수식은 작성할 수 없지만 두 솔루션을 눈으로 비교할 수 있는 경우 컨조인트 분석을 사용하여 솔루션을 빌드합니다. 후보 출력 쌍을 생성하고, 도메인 전문가가 각 쌍에서 더 나은 솔루션을 선택하도록 하고, 이러한 선택에 로지스틱 회귀를 적용하고, 적용된 모델을 측정항목으로 사용합니다. 이렇게 하면 주관적 판단이 결정론적이고 미분 가능한 점수로 바뀝니다. 원시 LLM 기준표는 느리고, 노이즈가 많고, 보상 해킹이 빠르므로 실시간 점수로 사용하지 마세요. 먼저 고정 함수로 증류하세요.
2. 점수 계산 방법 선택
숫자를 생성하는 방법은 측정하는 대상에 따라 다릅니다. 목표와 일치하는 방법을 표에서 선택합니다. 거의 모든 실제 배포는 이러한 네 가지 중 하나를 사용하며, 많은 배포는 검색을 유도하는 저렴한 방법과 우승자를 확인하는 데 드는 비용이 많이 드는 방법 두 가지를 결합합니다.
| 측정 방법 | 타겟이 다음과 같은 경우 사용 | 점수가 생성되는 방법 | 실행에 필요한 항목 |
|---|---|---|---|
| 직접 계산 | 비즈니스 또는 제품 로직을 사용하여 후보의 출력에서 폐쇄형으로 계산할 수 있는 수량 | 평가자가 후보를 실행하고 수식 (합계, 비율, 개수, 비용)을 적용합니다. | 컨트롤러의 자체 프로세스(추가 인프라 없음) |
| 성능 또는 부하 테스트 | 후보 코드 자체의 런타임, 처리량 또는 메모리 | 대표 하드웨어에서 후보를 실행하고 측정합니다. 먼저 정확성을 확인합니다. | 타겟 하드웨어 (GPU 또는 TPU 또는 CPU), 타이밍 노이즈를 줄이기 위한 워밍업 및 최적의 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
환경과 관계없이 두 가지 한도가 적용됨
진화 루프가 계속 이동하도록 각 평가를 약 10분 이하로 유지하세요. 비용이 많이 드는 목표의 경우 모든 후보에 대한 평가 캐스케이드 검사를 사용하고, 유망한 후보에 대해서만 전체 평가를 실행합니다.
평가자의 네트워킹, 보안, 액세스 제어는 사용자가 소유합니다. AlphaEvolve는 평가자를 배포하거나 관리하지 않습니다. on Google Cloud 또는 다른 곳에서.
측정항목, 계산 방법, 실행 위치를 결정한 후 평가자 구현 패턴 에서 평가자를 구성하는 방법을 참고하세요.