Context engineering adalah praktik menentukan semua yang dilihat model bahasa saat menjawab: bukan hanya pertanyaan yang kamu ketik, tapi juga instruksi di sekitarnya, dokumen dan hasil tool yang disisipkan ke dalamnya, memori yang tersimpan tentang pengguna, dan percakapan sejauh ini. Semua itu berbagi satu context window, dan model menjawab dari teks itu dan tidak dari yang lain. Istilah ini menyebar pada tahun 2025, seiring makin banyaknya produk AI yang menjadi agen yang menyusun sebagian besar konteksnya secara otomatis.
Prompt engineering sebagian besar tentang cara merumuskan permintaan. Context engineering tentang apa yang seharusnya ada di depan model di setiap pemanggilan, dan dalam urutan apa.
Dari prompt ke konteks
Di aplikasi chat, kamu sendiri yang menulis sebagian besar konteksnya: aplikasinya menambahkan prompt sistem dan riwayat, dan kamu menambahkan sisanya. Di sebuah aplikasi, keseimbangannya terbalik. Pengguna mengetik satu kalimat, lalu kode di sekitar model menambahkan instruksi, profil pengguna, tiga artikel bantuan yang ditemukan lewat pencarian, daftar tool yang tersedia, dan output dari pemanggilan tool terakhir. Kalimat pengguna itu bisa jadi hanya sebagian kecil dari apa yang dibaca model.
Ketika sistem seperti itu menjawab dengan buruk, perbaikannya jarang ada di pilihan kata. Penyebab yang umum adalah model mendapat materi yang salah: fakta yang hilang, hasil tool yang sudah usang, atau dokumen tidak relevan yang terlihat relevan bagi mesin pencarinya.
Apa yang masuk ke context window
Satu pemanggilan biasa di aplikasi AI berisi sebagian atau semua hal berikut, kira-kira dengan urutan ini:
- Instruksi sistem: peran, aturan, dan format output, biasanya tetap untuk seluruh aplikasi. Lihat prompt sistem.
- Definisi tool: nama, deskripsi, dan parameter dari tool yang boleh dipanggil model.
- Contoh: beberapa contoh input dan output yang menunjukkan perilaku yang diharapkan.
- Memori: fakta yang tersimpan dari sesi-sesi sebelumnya, seperti paket, bahasa, atau preferensi pengguna.
- Dokumen yang diambil: bagian-bagian yang ditemukan dengan mencari di basis pengetahuan untuk pertanyaan ini (retrieval-augmented generation, atau RAG).
- Riwayat percakapan: giliran-giliran sebelumnya, baik apa adanya maupun yang sudah diringkas.
- Hasil tool: output dari pencarian, eksekusi kode, atau pemanggilan API yang dilakukan selama tugas ini, seperti dalam loop ReAct.
- Pesan saat ini: apa yang baru saja ditanyakan pengguna.
Blok di bawah ini adalah satu konteks yang sudah disusun untuk asisten dukungan pelanggan. Matikan bagian-bagiannya satu per satu. Tanpa bagian konteks, model tidak mungkin tahu paket langganan pelanggannya; tanpa bagian input, model tidak punya fakta produk, dan batasannya memintanya mengatakan hal itu alih-alih menebak.
Halo Dana, mode offline adalah bagian dari paket Pro, dan akunmu saat ini memakai paket Free, jadi fitur itu belum tersedia untukmu. Dengan Pro, catatan yang kamu buat selama penerbangan akan tersinkron otomatis begitu ponselmu kembali terhubung. Ada satu batasan yang perlu kamu tahu: lampiran yang lebih besar dari 20 MB tidak tersedia saat offline.
Perhatikan bahwa jawaban yang benar bergantung pada penggabungan dua sumber: memori (paket Free) dan sebuah dokumen (mode offline hanya untuk Pro). Tidak ada yang cukup sendirian, dan itu hal yang umum. Sebagian besar context engineering adalah memastikan bagian-bagian yang saling membutuhkan datang bersamaan.
Empat cara sebuah konteks bisa salah
- Informasi yang hilang. Model mengisi celah dengan tebakan yang masuk akal, dan dari situlah banyak halusinasi berasal. Tambahkan faktanya, atau beri tahu model apa yang harus dilakukan ketika sebuah fakta tidak ada.
- Materi yang terlalu banyak. Setiap paragraf yang tidak relevan memakan token dan bersaing memperebutkan perhatian. Liu dkk. 2023, "Lost in the Middle: How Language Models Use Long Contexts", menemukan bahwa model-model yang mereka uji memakai informasi di awal atau akhir input yang panjang dengan lebih andal daripada informasi di tengahnya. Model yang lebih baru menangani input panjang dengan lebih baik, tapi mengirim beberapa bagian yang menjawab pertanyaan tetap lebih murah, dan lebih mudah dipakai model, daripada menempel seluruh manualnya.
- Informasi yang usang. Hasil tool dari sepuluh langkah lalu bisa menggambarkan file atau saldo yang sudah berubah sejak itu. Kalau model melihat kedua versinya, model bisa memakai yang lama.
- Pertentangan. Dua dokumen saling bertentangan, atau memori mengatakan satu hal dan pengguna mengatakan hal lain. Beri tahu model sumber mana yang menang, misalnya "pesan terbaru pengguna mengalahkan memori yang tersimpan".
Mengurutkan konteks
Urutan mengubah hasil sekaligus biaya.
- Bagian yang stabil di depan. Instruksi sistem, definisi tool, dan materi referensi yang tetap jarang berubah di antara pemanggilan. Beberapa penyedia API menawarkan prompt caching, yang memakai ulang hasil pemrosesan dari bagian awal input yang identik, jadi awalan yang tidak berubah membuat pemanggilan berulang lebih murah dan lebih cepat.
- Materi yang panjang sebelum pertanyaan. Untuk dokumen yang panjang atau sekumpulan besar bagian dokumen, taruh materinya lebih dulu dan pertanyaan serta instruksi akhirnya sesudahnya. Panduan prompting dari Anthropic, misalnya, menyarankan urutan ini untuk input yang panjang, dengan pertanyaan tepat sebelum model mulai menulis.
- Beri label setiap bagian. Bungkus setiap sumber dengan tag seperti
<document>,<memory>, atau<tool_result>, beserta nama sumbernya. Label membuat model bisa membedakan data dari instruksi dan memungkinkan kamu memintanya menyebutkan dari mana sebuah jawaban berasal. Delimiter dan tag XML membahas format-formatnya.
Memangkas konteks yang panjang
Setiap giliran chat mengirim ulang seluruh riwayatnya, jadi sesi yang panjang terus membesar sampai ada yang harus dibuang. Tergantung aplikasinya, aplikasi bisa meringkas atau membuang pesan-pesan lama, atau memintamu memulai chat baru. Kamu mendapat hasil yang lebih baik dengan memangkasnya secara sengaja.
- Simpan beberapa giliran terakhir kata demi kata dan ganti giliran yang lebih lama dengan ringkasan.
- Begitu sebuah hasil tool sudah dipakai, ganti dengan catatan satu baris tentang apa yang ditunjukkannya.
- Pertahankan identifier yang persis di setiap ringkasan: nama file, nama fungsi, ID, pesan error, dan angka. Ringkasan yang menyebut "file konfigurasinya" padahal riwayatnya menyebut
settings.prod.yamlkehilangan satu detail yang justru penting. - Di aplikasi chat, ketika percakapannya mulai melantur, mulai chat baru dengan catatan serah terima. Prompt di bawah ini menulisnya.
Tujuan: mengganti pengecekan manual di formulir pendaftaran dengan satu skema validasi bersama yang dipakai oleh browser dan server.
Keputusan
- Satu file skema,
signupSchema.ts, di-import olehSignupForm.tsxdanapi/signup.ts, supaya kedua kumpulan aturannya tidak bisa menyimpang. - Pesan error tetap kata demi kata, karena pusat bantuan mengutipnya.
Keadaan saat ini
- Validasi di browser sudah memakai skema dan
SignupForm.test.tsxlolos. - Server masih memanggil
validateSignup()yang lama diapi/signup.ts.
Detail persis: password butuh minimal 8 karakter dan satu angka. Teks error email: "Please enter a valid email address."
Langkah berikutnya: ganti validateSignup() dengan skemanya dan jalankan tes API.
Pertanyaan terbuka: apakah email yang sudah terdaftar harus mengembalikan 409 atau 400?
Memori antar sesi
Memori adalah konteks yang bertahan lebih lama dari sebuah percakapan: fakta yang ditulis ke penyimpanan di akhir satu sesi lalu dimuat di sesi berikutnya. Aplikasi chat menawarkan versinya masing-masing, seperti memori yang tersimpan atau instruksi proyek yang ditambahkan ke setiap chat dalam sebuah proyek. Di aplikasimu sendiri, memori adalah tabel atau file catatan yang dibaca dan disisipkan oleh kodemu. Ada dua aturan yang membuatnya tetap berguna: simpan fakta yang tetap benar (paket, bahasa, stack yang disukai), bukan transkrip; dan muat hanya yang relevan dengan tugas saat ini, karena memori bersaing memperebutkan ruang yang sama dengan semua hal lainnya.
Menyusun konteks di kode
Di sebuah aplikasi, context engineering adalah kode biasa. Sketsa dengan SDK Python milik Anthropic ini menaruh aturan tetap dan memori di prompt sistem, hanya menyimpan riwayat yang terbaru, dan menaruh dokumen-dokumen berlabel sebelum pertanyaannya.
import anthropic
client = anthropic.Anthropic()
MODEL = "your-model-id" # e.g. from your provider's model list
def build_context(question, docs, history, memory, max_messages=6):
documents = "\n".join(
f'<document source="{d["source"]}">\n{d["text"]}\n</document>' for d in docs
)
system = (
"You are the support assistant for Acme Notes. Answer only from the documents. "
"If they do not cover the question, say so.\n"
f"<memory>\n{memory}\n</memory>"
)
# history holds complete user/assistant pairs, so an even slice starts with a user turn
recent = history[-max_messages:]
user = f"<documents>\n{documents}\n</documents>\n\n{question}"
return system, recent + [{"role": "user", "content": user}]
# question, docs, history and memory come from your application
system, messages = build_context(question, docs, history, memory)
response = client.messages.create(model=MODEL, max_tokens=1024, system=system, messages=messages)
print(response.content[0].text)
Setiap keputusan di fungsi itu (dokumen mana, berapa banyak pesan, di mana memori ditaruh) adalah pilihan context engineering, dan masing-masing layak diuji dengan pertanyaan-pertanyaan sungguhan, sama seperti kamu menguji perubahan pada kata-kata instruksinya.
Pertanyaan yang sering diajukan
Apa itu context engineering?
Context engineering adalah pekerjaan memilih, mengurutkan, dan memangkas semua yang diterima model bahasa dalam sebuah pemanggilan: instruksi sistem, contoh, dokumen yang diambil, definisi dan hasil tool, memori yang tersimpan, riwayat percakapan, dan pesan pengguna. Model menjawab hanya dari teks itu, jadi apa yang ada di dalamnya, dan apa yang tidak dimasukkan, menentukan kualitas jawabannya.
Apa bedanya context engineering dengan prompt engineering?
Prompt engineering sebagian besar tentang merumuskan kata-kata instruksinya. Context engineering mencakup seluruh input, yang sebagian besar disusun oleh kode dan bukan diketik oleh orang: dokumen mana yang diambil, hasil tool mana yang disimpan, seberapa banyak riwayat yang dimasukkan, dan dalam urutan apa. Di chat, kamu sendiri yang menulis sebagian besar konteksnya; di aplikasi atau agen, sebagian besarnya dipilih oleh sistem di sekitar model.
Apakah konteks yang lebih banyak selalu lebih baik?
Tidak. Materi yang tidak relevan atau sudah usang bersaing dengan bagian-bagian yang penting, memakan token, dan bisa bertentangan dengan keadaan terbaru. Riset tentang input yang panjang menemukan bahwa model bisa melewatkan informasi yang ditaruh di tengah konteks yang panjang. Masukkan apa yang dibutuhkan tugasnya, beri label, dan buang yang sudah tidak dibutuhkan.
Kenapa chat yang panjang makin lama makin buruk?
Seluruh percakapan dikirim ulang di setiap giliran, jadi kesalahan lama, ide yang sudah ditinggalkan, dan kode yang sudah diganti tetap ada di konteks dan terus memengaruhi balasan. Begitu chat melampaui context window, aplikasinya harus membuang atau meringkas pesan-pesan lama. Memulai chat baru dengan ringkasan singkat tentang keputusan dan keadaan terbaru sering kali lebih berhasil daripada melanjutkan.
Apa itu RAG dalam context engineering?
RAG (retrieval-augmented generation) berarti mencari bagian-bagian yang relevan dengan pertanyaan di dokumen-dokumenmu sendiri lalu menyisipkannya ke konteks sebelum model menjawab. Ini salah satu alat utama context engineering: model mendapat fakta terbaru dan spesifik yang tidak mungkin diketahuinya dari pelatihan, dan kamu bisa memintanya menjawab hanya dari bagian-bagian itu.
