Target pengoptimalan mewakili satu angka yang dimaksimalkan AlphaEvolve selama setiap generasi. Sebelum Anda menulis kode evaluator, jawab tiga pertanyaan berikut:
Nilai apa yang diwakili oleh angka ini?
Bagaimana cara sistem menghitungnya?
Di mana komputasi dijalankan?
AlphaEvolve sangat memerlukan komputasi target terprogram yang otomatis untuk setiap solusi kandidat tanpa intervensi manusia. Otomatisasi ini membuat masalah cocok untuk AlphaEvolve. Jika seseorang harus menilai kualitas solusi secara manual, AlphaEvolve tidak dapat menelusurinya.
Gunakan pertimbangan berikut untuk memperkirakan performa solusi kandidat yang dihasilkan pada berbagai tujuan pengoptimalan dan batasan validasi:
- Dapatkah tujuan pengoptimalan dihitung secara langsung menggunakan logika bisnis atau produk, tanpa memerlukan pengukuran empiris?
- Dapatkah tujuan pengoptimalan diukur secara langsung dengan menjalankan pengujian performa dan beban pada kode solusi yang dihasilkan?
- Dapatkah tujuan pengoptimalan diperkirakan menggunakan fungsi pengganti deterministik yang ditetapkan, metode simulasi yang andal?
- Dapatkah tujuan pengoptimalan diperkirakan dengan merancang fungsi surrogate kustom (seperti model prediktif atau estimator non-deterministik lainnya) yang memerlukan penyesuaian pada pengamatan empiris dan validasi pada data di luar sampel?
Langkah-langkah inti untuk mengukur target Anda
Ikuti pendekatan terstruktur untuk memastikan AlphaEvolve memiliki feedback loop otomatis yang andal untuk memandu penelusurannya. Selesaikan langkah-langkah berikut untuk menetapkan metrik, menentukan cara pengukurannya, dan menentukan tempat eksekusi terjadi.
1. Nyatakan target sebagai skor tunggal yang meningkat seiring peningkatan solusi
Konfigurasi metrik pengoptimalan inti Anda agar diskalakan secara linear atau monotonik dengan peningkatan performa yang sebenarnya sehingga jalur penelusuran memiliki gradien terarah yang jelas.
Pemaksimalan skalar: AlphaEvolve selalu memaksimalkan satu nilai skalar. Ubah apa pun yang Anda pedulikan menjadi satu angka yang lebih tinggi lebih baik. Untuk meminimalkan latensi, biaya, atau error, negasikan:
score = -latency_msMonotonisitas: Skor harus monoton, harus meningkat setiap kali solusi benar-benar menjadi lebih baik. Skor yang bergerak tidak konsisten membuat penelusuran tidak memiliki arah untuk naik.
Eksekusi deterministik: Skor dihitung dalam evaluator Anda, bukan oleh LLM, dan bukan oleh seseorang. Hitung secara deterministik sehingga kandidat yang sama selalu mendapatkan skor yang sama.
Analisis konjoin untuk sasaran subjektif: Jika Anda tidak dapat menulis formula penilaian, tetapi dapat membandingkan dua solusi secara visual, buatlah satu solusi dengan analisis konjoin. Buat pasangan output kandidat, minta pakar domain memilih yang lebih baik di setiap pasangan, sesuaikan regresi logistik pada pilihan tersebut, dan gunakan model yang sesuai sebagai metrik Anda. Hal ini mengubah penilaian subjektif menjadi skor deterministik yang dapat dibedakan. Jangan gunakan rubrik LLM mentah sebagai skor live karena lambat, berisik, dan mudah diretas untuk mendapatkan reward; ringkas rubrik tersebut menjadi fungsi tetap terlebih dahulu.
2. Memilih cara penghitungan skor
Cara Anda menghasilkan angka bergantung pada apa yang Anda ukur. Pilih metode dari tabel yang sesuai dengan tujuan Anda. Hampir setiap deployment nyata menggunakan salah satu dari keempat metode ini, dan banyak yang menggabungkan dua metode, yaitu metode murah untuk mendorong penelusuran dan metode mahal untuk mengonfirmasi pemenang.
| Metode pengukuran | Gunakan saat targetnya adalah… | Cara penghitungan skor | Yang diperlukan untuk menjalankan aplikasi |
|---|---|---|---|
| Penghitungan langsung | Kuantitas yang dapat Anda hitung dalam bentuk tertutup dari output kandidat menggunakan logika bisnis atau produk | Evaluator menjalankan kandidat dan menerapkan formula (jumlah, rasio, jumlah, biaya) | Proses pengontrol itu sendiri — tanpa infrastruktur tambahan |
| Pengujian performa atau beban | Waktu proses, throughput, atau memori kode kandidat itu sendiri | Jalankan kandidat pada hardware representatif dan ukur; batasi pada kebenaran terlebih dahulu | Hardware target (GPU atau TPU atau CPU); pemanasan dan best-of-N untuk mengurangi derau waktu |
| Pengganti / simulasi deterministik | Mahal atau sulit diukur secara langsung, tetapi ada proxy yang andal atau pemutaran ulang kondisi nyata | Menghitung proxy deterministik, atau memutar ulang skenario operasi tetap yang di-seed | Lingkungan apa pun; dapat direproduksi sepenuhnya dengan seed tetap |
| Validasi di luar sampel | Kualitas model atau pipeline data yang dihasilkan kandidat | Latih/sesuaikan kandidat, lalu beri skor pada data yang disimpan atau yang baru dibuat | Stack pelatihan/evaluasi Anda; pembagian pelatihan vs. validasi yang ketat; memvalidasi ulang pemenang pada set yang ditahan |
Untuk mengetahui informasi selengkapnya, lihat pengumuman AlphaEvolve di Google Cloud blog.
Jika tidak ada satu pun yang dapat menghasilkan angka secara otomatis, masalahnya belum siap untuk AlphaEvolve. Tugas utamanya adalah membuat pengganti atau simulasi yang dapat melakukannya.
3. Menangani beberapa sasaran dan batasan
Tujuan sebenarnya biasanya menggabungkan beberapa masalah. Gunakan salah satu dari dua cara berikut untuk menanganinya:
Pencampuran skalar (paling sederhana—direkomendasikan untuk memulai): Ubah skala setiap metrik ke rentang yang sebanding, negasikan metrik yang Anda minimalkan, lalu tambahkan:
score = w1*A - w2*L - w3*M.
Lebih memilih jumlah aditif daripada rasio seperti A/(L⋅M), yang tidak stabil secara numerik.
Menampilkan kamus skor bernama: Biarkan AlphaEvolve mengoptimalkannya secara bersamaan. Evaluator dapat menampilkan beberapa metrik bernama, bukan satu angka:
```JSON
{
"scores": [
{"metric": "accuracy", "score": 0.95},
{"metric": "latency_ms", "score": -120.0}
]
}
```
Nilai yang lebih tinggi lebih baik untuk setiap metrik, jadi negasikan apa pun yang Anda minimalkan. Hal ini memicu penelusuran multi-tujuan yang sebenarnya, bukan sekadar pelaporan: database populasi menyimpan program terbaik per metrik (MAP-Elites), mempertahankan batas Pareto di seluruh metrik, dan mengambil sampel induk secara beragam di berbagai metrik. Model ini juga dapat menarik induk langsung dari batas Pareto saat sampling tersebut diaktifkan. Satu skor judul masih mendorong hill-climb yang dilaporkan, tetapi setiap metrik yang ditampilkan membentuk penelusuran.
Batasi hingga 3–5 metrik: Dengan terlalu banyak metrik, dominasi Pareto akan menurun, hampir setiap program tidak didominasi pada sesuatu dan penelusuran akan mengembara. Menggabungkan atau menghapus metrik di luar batas tersebut.
Pisahkan kebenaran dan kelayakan: Pertahankan kebenaran sebagai batasan yang ketat, bukan bagian dari fungsi reward. Kandidat yang salah atau tidak layak akan mendapatkan skor kegagalan, terlepas dari seberapa cepat atau murahnya. Ini adalah pertahanan utama terhadap agen yang memanipulasi metrik Anda.
Pengoptimalan batasan: Tahan satu tujuan sebagai batasan dan optimalkan tujuan lainnya, dengan menerapkan penalti jika batasan dilanggar. Menjalankan alur kerja ini pada beberapa tingkat batasan akan melacak bagian Pareto.
4. Menentukan tempat evaluator dijalankan
AlphaEvolve tidak pernah menjalankan evaluator Anda secara langsung. Sistem ini mengusulkan program kandidat dan menerima skor; Anda menghosting dan menjalankan kode yang menghitung skor. Lingkungan sepenuhnya merupakan pilihan Anda dan kandidat yang tidak dapat berjalan di Google Cloud bukanlah penghalang. Anda menjalankan evaluator di mana pun tujuan dapat diukur dan mengirimkan kembali skornya.
Untuk memastikan deployment yang efisien dan aman, Anda harus menyelaraskan infrastruktur komputasi dengan strategi pengukuran spesifik Anda sekaligus mematuhi batas eksekusi universal. Gunakan panduan berikut untuk memilih lingkungan eksekusi dan memahami batas operasional inti yang berlaku untuk semua penyiapan.
Mencocokkan lingkungan eksekusi dengan metode pengukuran
Penghitungan langsung atau pengganti: Proses pengontrol itu sendiri, atau satu container Cloud Run.
Pengujian performa atau beban: Hardware target seperti node GPU atau TPU di GKE, hardware lokal atau kustom Anda sendiri, atau alat pihak ketiga atau ISV (misalnya, simulator EDA atau Verilog).
Validasi di luar sampel atau tugas berat: Stack pelatihan Anda didistribusikan di Cloud Run atau GKE, atau di-offload ke Google Cloud batch menggunakan Cluster Toolkit untuk workload HPC atau akselerator yang besar.
Dua batas berlaku terlepas dari lingkungan
Usahakan agar setiap evaluasi berlangsung sekitar 10 menit atau kurang sehingga loop evolusioner terus bergerak. Untuk tujuan yang mahal, gunakan cascade evaluasi untuk memeriksa setiap kandidat, dan jalankan evaluasi lengkap hanya untuk kandidat yang menjanjikan.
Anda memiliki kontrol jaringan, keamanan, dan akses evaluator. AlphaEvolve tidak men-deploy atau mengelola evaluator, di Google Cloud atau di tempat lain.
Setelah Anda memutuskan metrik, cara menghitungnya, dan tempat menjalankannya, lihat pola penerapan evaluator untuk mengetahui cara menyusun evaluator.