Aplikasi large language model jarang gagal hanya karena prompt kelebihan satu token. Kegagalan biasanya terjadi karena pertumbuhan context ditangani tanpa prioritas. Riwayat chat membesar, retrieval mengembalikan lebih banyak passage, hasil tool menjadi panjang, dan pada akhirnya aplikasi memangkas teks mana pun yang paling mudah dipotong.

Desain yang lebih aman memperlakukan context window sebagai anggaran dengan alokasi eksplisit. Tujuannya bukan mengisi setiap token yang tersedia, melainkan mempertahankan informasi yang mengendalikan perilaku sekaligus menyisakan ruang yang cukup untuk jawaban lengkap.

Cadangkan kapasitas output terlebih dahulu

Jika model menerima context window sebesar C token, cadangkan ruang jawaban sebelum menyusun input:

input_budget = context_limit - reserved_output - safety_margin

Safety margin mencakup perbedaan tokenizer, framing message, metadata tool, dan perubahan kecil pada prompt. Tanpanya, request yang tampak muat saat development dapat gagal setelah library menambahkan wrapper atau pengguna mengirim teks yang sangat padat.

Jangan menentukan cadangan output dari ruang yang kebetulan tersisa. Tentukan terlebih dahulu seberapa besar ruang jawaban yang dibutuhkan produk.

Tetapkan prioritas alih-alih memangkas secara buta

Urutan yang berguna untuk banyak asisten adalah:

  1. instruksi sistem dan keamanan;
  2. request pengguna saat ini;
  3. bukti yang diperlukan untuk menjawab request;
  4. structured state yang relevan;
  5. riwayat percakapan terbaru;
  6. detail percakapan lama dan contoh opsional.

Urutan tepatnya bergantung pada produk, tetapi harus ditentukan secara sengaja.

Pertahankan instruksi kontrol secara utuh

Instruksi sistem, schema, dan kontrak tool biasanya harus diperlakukan sebagai satu kesatuan yang tidak boleh dipotong. Menghapus separuh paragraf kebijakan dapat mengubah maknanya. Jika teks kontrol terlalu besar untuk model yang dituju, kurangi control surface tersebut pada tahap desain aplikasi alih-alih memotongnya secara dinamis saat runtime.

Pertahankan request saat ini

Percakapan lama biasanya kurang penting dibanding turn saat ini. Request baru seharusnya tidak kehilangan separuh instruksinya hanya karena dua puluh message sebelumnya dipertahankan secara verbatim.

Ketika aplikasi mendukung attachment panjang, pisahkan instruksi saat ini dari bukti yang dilampirkan agar masing-masing dapat diberi anggaran secara independen.

Anggarkan retrieval berdasarkan kegunaan

Sistem retrieval sering mengembalikan jumlah chunk yang tetap. Pendekatan ini mengabaikan seberapa banyak context yang dikonsumsi setiap hasil.

Lebih baik gunakan loop seleksi yang memperhitungkan token:

selected = []
used = 0

for chunk in ranked_chunks:
    cost = token_count(chunk.text)
    if used + cost > evidence_budget:
        continue
    selected.append(chunk)
    used += cost

Pendekatan ini lebih aman daripada memotong string bukti yang sudah digabung di tengah passage, karena pemotongan semacam itu dapat menghilangkan qualifier atau citation.

Utamakan kepadatan informasi daripada bukti berulang

Lima passage yang mengulang fakta yang sama mungkin kurang berguna dibanding tiga passage yang mencakup bagian berbeda dari pertanyaan. Jika memungkinkan, kombinasikan relevance ranking dengan deduplikasi atau keragaman sumber.

Hal ini meningkatkan kepadatan informasi dan menyisakan lebih banyak ruang untuk reasoning dan output.

Kompres riwayat menjadi state jika memungkinkan

Ringkasan free-form berguna, tetapi dapat diam-diam membuang detail. Aplikasi bergaya workflow sering lebih diuntungkan oleh state eksplisit:

{
  "deployment_target": "staging",
  "rollout": "canary",
  "rollback_required": true
}

Kemudian sertakan hanya field yang relevan dengan request saat ini. Pendekatan ini lebih mudah diperiksa dan diperbarui daripada berulang kali meringkas transcript yang terus membesar.

Buat truncation dapat diamati

Manajemen context harus menghasilkan metrik, bukan perilaku yang tidak terlihat. Pengukuran yang berguna meliputi:

  • token input sebelum trimming;
  • token yang dihapus per bagian;
  • chunk hasil retrieval yang dipertimbangkan dan dipertahankan;
  • turn riwayat yang dibuang;
  • token output yang dicadangkan;
  • request yang mendekati batas model.

Sinyal ini menunjukkan apakah aplikasi secara rutin beroperasi di tepi context window.

Jika sebagian besar passage hasil retrieval selalu dibuang, menaikkan nilai top-k retriever tidak akan membantu. Jika riwayat mendominasi setiap prompt, ekstraksi state eksplisit mungkin lebih bermanfaat daripada model yang lebih besar.

Hindari pendekatan berdasarkan jumlah karakter

Karakter, kata, dan token saling berkaitan tetapi tidak dapat dipertukarkan. Kode, JSON, identifier, dan teks non-Inggris dapat mengalami tokenisasi yang sangat berbeda.

Gunakan tokenizer atau API penghitungan token yang terkait dengan model yang digunakan jika tersedia. Jika penghitungan presisi tidak memungkinkan, sisakan margin lebih besar dan perlakukan estimasi sebagai perkiraan.

Perlakukan pergantian model sebagai perubahan anggaran

Berpindah ke model dengan context window lebih besar tidak menghilangkan kebutuhan akan budgeting. Window yang lebih besar dapat meningkatkan latensi dan biaya, serta mempermudah masuknya materi yang tidak relevan.

Upgrade model sebaiknya memicu context regression test. Masukkan percakapan panjang yang representatif, kumpulan hasil retrieval, dan output tool yang verbose ke prompt builder, lalu verifikasi bagian mana yang tetap bertahan.

Kesalahan umum

Tidak mencadangkan ruang jawaban

Prompt dapat muat tetapi hanya menyisakan ruang terlalu sedikit untuk respons yang diminta. Cadangkan kapasitas output sebelum mengisi input.

Mempertahankan riwayat hanya karena mudah

Riwayat verbatim memang sederhana, tetapi nilainya biasanya menurun seiring waktu. Utamakan turn terbaru ditambah state eksplisit yang diperlukan untuk kontinuitas.

Memotong bukti pada batas sembarang

Pertahankan unit bukti secara utuh. Jika sebuah chunk terlalu besar, lakukan rechunking di upstream atau rangkum secara sengaja.

Menganggap context lebih banyak selalu memperbaiki jawaban

Context tambahan juga dapat membawa lebih banyak noise. Ukur kualitas jawaban, latensi, dan biaya alih-alih menjadikan panjang context maksimum sebagai target.

Kebijakan budgeting yang praktis

Kebijakan produksi dapat mengikuti urutan deterministik:

  1. cadangkan token output dan safety margin;
  2. tambahkan instruksi sistem dan request saat ini;
  3. alokasikan anggaran bukti yang terbatas;
  4. tambahkan structured state yang relevan;
  5. isi kapasitas tersisa dengan riwayat terbaru;
  6. catat apa yang dihilangkan.

Context window adalah batas kapasitas, bukan tempat penyimpanan dokumen. Aplikasi menjadi lebih andal ketika menentukan apa yang layak menggunakan kapasitas tersebut sebelum prompt mencapai model.

Kecerdasan Buatan LLM Prompt Engineering RAG