Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Topik dan strategi lanjutan ## Topik di halaman ini + [Multi-objective optimasi](#advanced-prompt-optimization-multi-objective) + [Mengoptimalkan prompt multi-putaran dan bertahap](#advanced-prompt-optimization-multi-turn) ## Multi-objective optimasi Advanced Prompt Optimization menerima satu metrik per run — skor skalar tunggal per sampel. Namun, ini secara implisit mendukung optimasi multi-tujuan (multi-dimensi): Anda dapat menggabungkan beberapa tujuan menjadi satu skalar (metrik komposit) dan layanan mengoptimalkan prompt terhadap bundel itu. Bagian ini mencakup pola yang kami rekomendasikan, kapan masing-masing sesuai, dan mode kegagalan yang harus diperhatikan. Ini berlaku di seluruh vertikal — di mana pun Anda peduli tentang lebih dari satu hal pada saat yang sama: akurasi\+nada, kebenaran panggilan alat\+keamanan, kesetiaan\+keringkasan, keramahan latensi\+kelengkapan, dan banyak lagi. ### Mengapa satu metrik sebenarnya multi-tujuan Dua fakta tentang sistem membuat ini berfungsi: + **Metrik mengembalikan nilai float tunggal per sampel.** Loop umpan balik optimasi membaca skalar ini sebagai sinyal pengoptimalan. Anda dapat menghitungnya dari sejumlah sub-skor di bawah tenda. + **Kedua backend metrik sudah menggabungkan sub-skor secara internal.** + Nilai LLM-as-a-Judge template default pada tiga dimensi (Akurasi Jawaban, Kelengkapan Jawaban, Kualitas Ekspresi), menetapkan bobot, dan memancarkan `Overall` skor tunggal yang dinormalisasi ke [0, 1]. Kriteria khusus digabungkan ke dalam skalar yang sama. Untuk informasi selengkapnya, lihat [Kustom LLM-as-a-judge](advanced-prompt-optimization-evaluation.md#advanced-prompt-optimization-evaluation-llmj). + Metrik Lambda/ kode khusus mengembalikan satu nomor, dan Anda mengontrol cara penghitungannya — termasuk gabungan sub-tujuan apa pun. Jadi “satu metrik per run” adalah kontrak tentang bentuk sinyal, bukan batasan untuk apa Anda dapat mengoptimalkan. ### Pola untuk menggabungkan beberapa tujuan menjadi satu metrik Pilih satu berdasarkan bagaimana tujuan Anda berhubungan satu sama lain. #### Pola 1 — Jumlah tertimbang (paling umum) `final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ`, dengan bobot yang dijumlahkan menjadi 1. **Kapan menggunakan:** Tujuan kira-kira independen dan Anda dapat memberi peringkat. Trade-offs dapat diterima — meningkatkan satu dengan mengorbankan yang lain tidak apa-apa selama jumlahnya naik. **Memilih bobot:** + Berat menurut pentingnya bagi pengguna, bukan berdasarkan frekuensi dalam kumpulan data. + Mulai kasar: `0.5 / 0.3 / 0.2` baik-baik saja. Jangan terlalu menyetel bobot — itu masalah pengoptimalan yang terpisah. **Contoh (agentic/penggunaan alat):** ``` final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance ``` #### Pola 2 — Hard-fail gerbang (kritis terhadap keselamatan) Tentukan satu atau lebih tujuan gerbang. Jika ada gerbang yang gagal, skornya adalah 0 (atau beberapa lantai) terlepas dari sisanya. Jika tidak, skor adalah jumlah tertimbang dari tujuan yang tersisa. ``` if not safety_check_passed: return 0.0 if wrong_tool_called_for_destructive_action: return 0.0 return 0.6 * accuracy + 0.4 * tone ``` **Kapan menggunakan:** Setidaknya satu tujuan tidak dapat dinegosiasikan (kebocoran PII, akun salah dimodifikasi, penolakan pada konten yang dilarang). Gunakan ini setiap kali prompt “baik rata-rata” tidak dapat diterima jika gagal pada bilah pengaman bahkan sesekali. **Mengapa ini mengalahkan bobot saja: Dengan bobot** saja, pengoptimal dapat menukar keselamatan dengan kualitas dan masih mendaki skor. Sebuah gerbang membuat trade-off tidak mungkin dilakukan dengan konstruksi. #### Pola 3 - Kendala\+hadiah () Pareto-style Pilih tujuan yang paling penting sebagai hadiah. Ekspresikan sisanya sebagai kendala yang, ketika dilanggar, kurangi dari hadiah (daripada memusatkannya). ``` reward = task_accuracy penalty = 0.0 if response_too_long: penalty += 0.1 if missed_required_disclosure: penalty += 0.2 return max(0.0, reward - penalty) ``` **Kapan menggunakan:** Anda ingin satu tujuan utama untuk memimpin, tetapi tujuan sekunder lunak masih harus membentuk prompt. Kurang rapuh dari gerbang keras, kurang ambigu dari jumlah tertimbang. #### Pola 4 - Lambda luar, LLM-as-a-Judge dalam (direkomendasikan untuk campuran struktural fuzzy\+) Metrik Lambda menghitung sub-skor deterministik (regex, parse JSON, validasi skema) dan memanggil LLM-as-a-Judge sub-evaluasi untuk bagian fuzzy (nada, kesetiaan, bantuan) di dalam fungsi Lambda. Kemudian menggabungkan mereka menjadi satu skalar. ``` def compute_score(prompt, prediction, gold, ...): structural = grade_format_and_tools(prediction) # 0..1 from regex semantic = call_llm_judge(prediction, gold, criteria) # 0..1 from LLMJ if structural < 1.0 and is_safety_critical(prompt): return 0.0 return 0.6 * semantic + 0.4 * structural ``` **Kapan menggunakan:** Tujuan Anda mencampur “mudah diuji dalam kode” (format, nama alat, panjang, keberadaan kutipan) dengan “membutuhkan model untuk menilai” (nada, kesetiaan, bantuan). Ini seringkali lebih bersih daripada meminta satu LLM-as-a-Judge prompt untuk menghasilkan skor komposit tunggal, karena bagian deterministik tidak akan melayang run-to-run. #### Pola 5 - Multi-dimension LLM-as-a-Judge (tidak ada Lambda) Gunakan LLM-as-a-Judge aliran bawaan, secara opsional dengan a `customLLMJConfig.customLLMJPrompt` yang menentukan dimensi dan bobot Anda sendiri. Hakim memancarkan skor per dimensi dan`Overall`; sistem mem-parsing `Overall` (atau dimensi rata-rata jika `Overall` hilang) menjadi skalar [0, 1]. **Kapan menggunakan:** Semua tujuan Anda semantik/fuzzy dan Anda tidak memiliki sub-pemeriksaan deterministik. Tercepat untuk penulis. Perhatikan varians hakim — jalankan kembali kumpulan data yang sama dua kali dan lihat stabilitas skor sebelum mempercayainya sebagai sinyal pengoptimalan. ### Memilih pola | \# | Kau punya... | Gunakan | | --- | --- | --- | | 1 | 2—4 tujuan kabur, semuanya semantik | Pola 5 (multi-dimensi LLM-as-a-Judge) | | 2 | 2—4 tujuan pencampuran struktural dan semantik | Pola 4 (Lambda LLM-as-a-Judge luar\+dalam) | | 3 | Setidaknya satu kriteria yang tidak dapat dinegosiasikan safety/correctness | Pola 2 (gerbang gagal keras) — gabungkan dengan 1 atau 4 | | 4 | Satu tujuan utama yang jelas\+preferensi lunak | Pola 3 (kendala \+ hadiah) | | 5 | Beberapa tujuan independen yang hampir sama | Pola 1 (jumlah tertimbang) | Anda dapat menggabungkan pola. Metrik produksi yang khas adalah “jumlah tertimbang\+gerbang keselamatan yang sulit gagal.” ### Mode kegagalan untuk diperhatikan + **Hadiah peretasan pada bentuk permukaan.** Jika sub-skor Anda adalah “apakah respons mengandung kata 'yakin',” pengoptimal akan menulis prompt yang memaksa “yakin” ke setiap output. Lebih suka sub-skor berdasarkan hasil (nama alat, nilai slot, validitas struktural) daripada kehadiran kata kunci. + **Hakim melayang.** LLM-as-a-Judge Metrik multi-dimensi yang bobotnya bervariasi per panggilan (karena hakim diminta untuk memilihnya) memberikan sinyal optimasi yang bising. Sematkan bobot dalam kriteria khusus Anda, atau pindahkan bobot dimensi ke dalam kode Lambda. + **Skor komposit jenuh.** Jika metrik mencapai 0,95 dengan cepat dan tetap di sana, sub-skor Anda terlalu lunak. Kencangkan rubrik; pertimbangkan untuk menaikkan bilah maksimum (misalnya, kredit sebagian menjadi 0, bukan 1) sehingga pengoptimal memiliki ruang kepala. + **Sub-objectives konflik secara langsung.** “Keringkasan” vs. “kelengkapan” adalah trade-off yang nyata. Pola jumlah tertimbang memilih titik operasi di perbatasan itu; jika Anda tidak menyukainya, ubah bobotnya. ### Pre-launch daftar periksa + Hitung metrik pada prompt awal melalui kumpulan data lengkap dan periksa rata-rata per dimensi, bukan hanya skalar. Jika satu dimensi sudah jenuh, pertimbangkan untuk menjatuhkannya dari bundel. + Spot-check 5 sampel dengan tangan. Apakah putusan metrik sesuai dengan penilaian Anda? Jika tidak, perbaiki metrik sebelum mengoptimalkan prompt. ## Mengoptimalkan prompt multi-putaran dan bertahap Advanced Prompt Optimization mengoptimalkan template prompt tunggal terhadap evaluasi per sampel. Ini tidak secara native turn-aware — itu tidak dapat mengulangi dialog atau mengoptimalkan perilaku pada giliran tertentu secara native. *Prompt bertahap* adalah templat prompt di mana percakapan atau alur kerja multi-putaran menggunakan kembali prompt yang sama secara bergantian, dan prompt itu sendiri berisi instruksi untuk setiap tahap, langkah, atau fase alur kerja. Untuk mengoptimalkan petunjuk ini, ratakan status dialog ke dalam variabel input template, panggang instruksi sistem yang ingin Anda sempurnakan`promptTemplate`, dan selidiki belokan yang benar-benar Anda pedulikan dengan respons referensi per sampel. Pola ini vertikal-agnostik. Ini berlaku di mana pun model dipanggil berulang kali dengan konteks yang berkembang — alur layanan pelanggan, loop penggunaan alat agen, penalaran multi-langkah, bimbingan belajar, giliran asisten kode, QA berbasis dokumen, alur kerja triase, dan banyak lagi. ### Apa yang sebenarnya dioptimalkan oleh Advanced Prompt Optimization + **Input:** Sebuah `promptTemplate` string dengan `{{placeholder}}` variabel. + **Per sampel:** Masing-masing `evaluationSamples[i]` memberikan nilai untuk variabel-variabel tersebut dan a`referenceResponse`. Pengoptimal menjalankan inferensi, evaluasi, umpan balik, dan penulisan ulang secara independen per sampel, kemudian mengumpulkan metrik di seluruh sampel. + **Keluaran:** Sebuah halus`promptTemplate`. Variabel, dataset, dan metrik adalah input tetap; hanya template yang berubah. Apa pun yang Anda inginkan dioptimalkan harus hidup di dalam `promptTemplate` dirinya sendiri. Hal-hal yang bervariasi per sampel (riwayat percakapan, kueri pengguna saat ini, konteks yang diambil) adalah`{{variables}}`. Instruksi sistem yang ingin disempurnakan adalah bagian dari template — tidak pernah variabel input, atau layanan tidak memiliki apa pun untuk ditulis ulang. Jika Anda ingin layanan meningkatkan perilaku pada gilirannya N, nyatakan belokan N sebagai variabel prompt-plus-input-render untuk satu sampel, dengan menjadi output model turn-N yang diinginkan. `referenceResponse` ### Pola A - Stage-at-a-time (starter yang disarankan) Optimalkan satu fase dialog pada satu waktu. Setiap sampel evaluasi mewakili satu titik keputusan dalam fase itu. “Tahap” di sini adalah apa pun yang dapat Anda gambarkan dengan serangkaian kriteria keberhasilan yang koheren. Contoh dengan vertikal: + **Agentic/penggunaan alat:** giliran pembentukan rencana, giliran pemilihan alat, giliran interpretasi hasil-alat, giliran jawaban akhir. + **Dukungan pelanggan:** asupan, verifikasi, tindakan, konfirmasi, penutupan. + **Bimbingan bimbingan/pendidikan: menilai-pengetahuan**, menjelaskan konsep-konsep, memeriksa pemahaman, meringkas. + **Dokumen QA:** jawaban berdasarkan pengambilan, klarifikasi tindak lanjut, giliran kutipan. + **Asisten pengkodean:** klarifikasi spesifikasi, pembuatan kode, kode-review/fix, tes-tulis. #### Kapan menggunakan Pattern A + Anda dapat menyebutkan fase yang berbeda dengan kriteria keberhasilan yang berbeda. + Satu fase adalah menyeret kualitas ke bawah dan Anda ingin memperbaikinya tanpa mengganggu orang lain. + Anda menginginkan iterasi cepat dan sinyal umpan balik yang ketat dan dapat di-debug. #### Bentuk templat Instruksi sistem khusus tahap dimasukkan ke dalam templat (inilah yang ditulis ulang oleh layanan). Hanya riwayat percakapan dan giliran saat ini yang merupakan variabel. Struktur di bawah ini adalah ilustrasi, tidak ditentukan. Gunakan pembatas atau tata letak apa pun yang paling ditangani model Anda. Satu-satunya persyaratan adalah: (a) instruksi sistem yang ingin Anda optimalkan langsung di dalam template, dan (b) variabel per sampel direferensikan sebagai. `{{variablename}}` ``` You are an assistant in the {STAGE_NAME} phase of a multi-turn task. - ...the policy / goals / format / tool-use rules for this phase... - ...constraints the model must satisfy at this point in the conversation... Conversation so far: {{conversation_so_far}} User's current message: {{user_query}} ``` #### Bentuk sampel ``` { "inputVariables": [ {"conversation_so_far": "user: ...\nassistant: ...\n... (turns 1..N-1)"}, {"user_query": "...the user input that triggers this stage..."} ], "referenceResponse": "...the assistant output that satisfies the stage's success criteria..." } ``` #### Pro dan kontra **Kelebihan:** Sinyal umpan balik yang ketat, petunjuk yang lebih kecil, pengoptimalan berjalan lebih cepat, lebih mudah untuk membuat metrik terfokus. **Cons:** Tidak catch cross-stage drift; Anda akan menjalankan layanan sekali per tahap dan mungkin memerlukan tes integrasi akhir. ### Pola B - Percakapan rata penuh (lanjutan) Optimalkan satu prompt monolitik besar yang memiliki seluruh kebijakan multi-tahap. Setiap sampel adalah dialog penuh hingga giliran probe. #### Kapan menggunakan Pola B + Prompt produksi Anda sudah monolitik dan Anda tidak ingin membaginya. + Anda ingin pengoptimal melihat bagaimana putaran sebelumnya yang diatur kemudian berubah, sehingga penulisan ulangnya mempertahankan aliran lintas tahap. + Kebenaran pada giliran probe tergantung pada konteks yang dibangun di seluruh tahapan (misalnya, “pada belokan N, fakta yang benar harus sudah direferensikan” atau “alat yang tepat pasti sudah dipanggil”). #### Bentuk templat Prompt sistem multi-fase monolitik penuh berada di dalam template. Layanan menulis ulang badan ini selama pengoptimalan. Sejarah dan giliran saat ini tetap variabel. Pilih tata letak apa pun yang ditangani model Anda dengan baik; persyaratannya hanya bahwa instruksi yang akan dioptimalkan adalah bagian dari templat dan data per sampel direferensikan melalui. `{{name}}` ``` You are an assistant for {TASK}. The conversation may proceed through phases: 1. {PHASE_1} — ... 2. {PHASE_2} — ... 3. {PHASE_3} — ... (...the entire multi-phase policy, tool-use rules, tone, formatting, refusal rules...) Conversation so far (turns 1..N-1, with role tags): {{conversation_so_far}} User's current message: {{user_query}} ``` #### Bentuk sampel (probe di setiap belokan N) ``` { "inputVariables": [ {"conversation_so_far": "user: ...\nassistant: ...\n[tool_call: X(...)]\n... (turns 1..N-1)"}, {"user_query": "...the user input at turn N..."} ], "referenceResponse": "...desired assistant output at turn N..." } ``` #### Mengapa Pola B dapat bekerja lebih baik daripada Pola A + Pengoptimal melihat perkembangan tahap`conversation_so_far`, sehingga umpan balik pengoptimalan dapat beralasan di seluruh tahapan sekaligus. + Satu prompt yang dioptimalkan digunakan tanpa menyatukan beberapa prompt tahapan yang dioptimalkan bersama-sama, mengurangi pasca-pemrosesan untuk Anda. #### Peringatan untuk Pola B + **Stochasticity di belokan sebelumnya.** Giliran asisten produksi mungkin tidak selalu cocok `conversation_so_far` dengan kaleng. Perlakukan sejarah kalengan sebagai lintasan yang diharapkan; dalam produksi, penyimpangan di belokan sebelumnya dapat membatalkan pengoptimalan. Gunakan tangkapan percakapan nyata yang representatif daripada jalur bahagia yang disintesis. + **Biaya token.** Sejarah panjang biaya inferensi balon per percobaan. Layanan ini menjalankan banyak kandidat × sampel × iterasi. Anggarkan sesuai dengan itu, dan pertimbangkan untuk memotong ke putaran K terbaru ditambah ringkasan jika biaya adalah hambatan. + **Bias respons referensi.** `referenceResponse`seharusnya apa yang akan dikatakan asisten yang benar mengingat sejarah itu. Jika respons referensi Anda terlalu sempit (hanya satu frasa yang dapat diterima), pengoptimal akan terlalu cocok untuk itu. Lebih suka metrik yang menilai hasil (nama alat, nilai slot, keputusan) daripada kecocokan bentuk permukaan jika memungkinkan. ### Tool-call verifikasi pada giliran tertentu Layanan melihat output teks asisten. Untuk menilai “apakah model memanggil alat X dengan argumen kanan pada belokan N,” pilih salah satu: + **Konvensi dalam output:** Mintalah asisten memancarkan token terstruktur seperti `X(arg=...)` dan memberi nilai dengan regex/JSON parse dalam metrik Lambda. Termurah, paling dapat diandalkan. + **LLM-as-a-Judge kriteria khusus:** Berikan a `customLLMJPrompt` yang bertanya kepada hakim: “Apakah respons (a) memberi nama alat`X`, (b) menyertakan argumen`arg`, (c) cocok dengan kata-kata yang diperlukan`Y`?” Setiap sub-cek adalah \+1; agregat. Mudah untuk penulis, lebih banyak varians. + **Metrik Lambda dengan simulasi hilir:** Jika Anda memiliki harness eksekusi alat, jalankan keluaran model melaluinya dan skor pada efek samping yang diamati. Kesetiaan tertinggi, sebagian besar pengaturan. Untuk kriteria komposit di banyak belokan atau banyak sub-pemeriksaan (kebenaran dan nada dan kelengkapan alat), lihat bagian. [Multi-objective optimasi](#advanced-prompt-optimization-multi-objective) ### Jalur yang direkomendasikan + **Mulailah dengan Pola A** di atas panggung yang paling menyakiti kualitas. Dapatkan metrik yang berfungsi, kumpulan data sampel 20—50, dan satu pengoptimalan dijalankan secara end-to-end. Ini memvalidasi kumpulan data dan metrik Anda sebelum Anda berinvestasi dalam proses Pola B yang lebih besar. + **Kemudian jalankan Pola B sekali** dengan prompt monolitik penuh dan metrik komposit multi-tujuan untuk menangkap regresi lintas tahap yang dapat dilewatkan oleh Pola A. + **Iterasi dataset sebelum iterasi prompt.** Jika layanan menulis ulang menanjak metrik Anda tetapi perilaku produksi tidak membaik, metrik atau kumpulan data sering kali menjadi masalah. ### Kapan tidak menggunakan Advanced Prompt Optimization untuk multi-turn + **Kebijakan dialog/bug state-machine** (logika transisi tahap yang salah): penulisan ulang prompt datar tidak dapat memperbaikinya. Perbaiki layer orkestrasi terlebih dahulu. + **Skema alat salah:** Layanan tidak akan mengubah definisi alat. Itu hanya dapat mengubah prompt yang meminta model untuk menggunakannya. + **Pergeseran antara riwayat kalengan dan riwayat langsung:** Jika percakapan nyata sangat berbeda dari sampel evaluasi Anda setelah beberapa putaran, sinyal pengoptimalan Pola B lemah. Menangkap jejak produksi nyata yang dapat diterima untuk menjalankan pengoptimalan dapat membantu di sini selain keadaan ideal. + **Perilaku yang diperlukan bergantung pada status pribadi** yang tidak pernah dilihat pengoptimal (misalnya, data akun pengguna yang hanya dipelajari model melalui panggilan alat): buat status itu eksplisit `conversation_so_far` untuk sampel probe, atau terima bahwa layanan hanya dapat menyetel perilaku permukaan. ### Daftar periksa pemula + Pilih probe yang ternyata Anda pedulikan. Masing-masing menjadi satu atau lebih sampel. + Tentukan Pola A atau B (atau keduanya — A terlebih dahulu, lalu B). + Bangun 20\+ sampel representatif dengan `referenceResponse` nilai realistis `conversation_so_far` dan bersih.