- Pembahasan kini bergeser dari "prompt engineering" ke "context engineering", sebuah tahap yang lebih maju
- Konteks bukan sekadar kalimat prompt, melainkan semua informasi yang dapat dilihat LLM sebelum menghasilkan jawaban (instruksi, riwayat percakapan, memori jangka panjang, informasi eksternal, alat yang tersedia, dll.)
- Keberhasilan dan kegagalan agen kini lebih bergantung pada kualitas konteks daripada performa model
- Agen yang lebih canggih mengintegrasikan beragam konteks seperti kalender pengguna, email sebelumnya, dan kontak untuk menghasilkan respons yang lebih dekat ke penyelesaian masalah nyata
- Context engineering adalah perancangan sistem dinamis yang disesuaikan dengan situasi, yaitu proses menyediakan informasi dan alat yang tepat kepada LLM pada saat yang tepat
Apa itu Context Engineering
- Belakangan ini, istilah "context engineering" menyebar dengan cepat di bidang AI
- Jika "prompt engineering" sebelumnya berfokus pada perancangan satu pertanyaan atau perintah, context engineering adalah pendekatan yang lebih luas dan lebih kuat
- Tobi Lutke mendefinisikannya sebagai "seni menyediakan semua konteks agar LLM dapat menyelesaikan tugas dengan andal"
Elemen utama konteks
- Dalam sistem agen, keberhasilan operasional sangat ditentukan oleh informasi apa yang dimasukkan ke working memory
- Sebagian besar kegagalan agen bukan disebabkan oleh model, melainkan karena kurangnya konteks yang tepat
Komponen penyusun konteks
- System prompt/instruksi: instruksi dasar, contoh, aturan, dan sebagainya yang mendefinisikan perilaku model
- Prompt pengguna: permintaan atau pertanyaan langsung dari pengguna
- Status/riwayat percakapan: alur percakapan saat ini dan informasi konteksnya
- Memori jangka panjang: percakapan sebelumnya yang berlangsung dalam beberapa tahap, preferensi pengguna, ringkasan proyek terdahulu, serta kumpulan informasi yang dipelajari agar model dapat mengingatnya dalam jangka panjang
- RAG (retrieval-augmented generation): informasi terbaru dan relevan yang diambil dari dokumen eksternal, database, API, dan sebagainya
- Alat yang tersedia: definisi fungsi atau tool bawaan yang dapat dipanggil model (misalnya:
check_inventory, send_email, dll.)
- Output terstruktur: definisi format respons yang harus diikuti model (misalnya: JSON)
Mengapa konteks itu penting
- Faktor yang secara nyata membuat agen AI efektif bukanlah kode yang rumit atau kualitas model, melainkan seberapa tepat konteks yang diberikan
- Agen sederhana untuk "demo" hanya menerima permintaan pengguna dan memberikan respons dasar, sementara agen yang terasa "ajaib" mempertimbangkan konteks yang kaya untuk menghasilkan jawaban yang jauh lebih berguna dan lebih manusiawi
- Perbandingan
- Agen berkualitas rendah (demo): hanya melihat permintaan sederhana dan menghasilkan jawaban kaku. Contoh: pada email "Apakah Anda ada waktu besok?", ia menjawab "Besok saya bisa. Jam berapa yang cocok?" secara mekanis
- Agen berkualitas tinggi (terasa ajaib): dapat memanfaatkan kalender sendiri, riwayat email sebelumnya, identitas lawan bicara, hingga opsi pemanggilan alat yang diperlukan untuk menghasilkan jawaban yang natural dan sesuai situasi. Contoh: "Besok jadwal saya penuh, tetapi Kamis pagi masih kosong, jadi saya sudah mengirim undangan jadwal. Mohon beri tahu jika cocok"
- Dengan demikian, yang menentukan keberhasilan bukanlah algoritme atau model semata, melainkan penyediaan konteks yang benar sesuai tugas
- Sebagian besar kegagalan agen AI bukan berasal dari model, tetapi merupakan hasil dari kegagalan desain konteks
Evolusi dari prompt engineering ke context engineering
- Jika prompt engineering berfokus pada optimasi instruksi teks satu baris, context engineering mencakup rentang yang jauh lebih luas: informasi, alat, dan desain struktural
- Context engineering adalah "keahlian profesional dalam merancang dan membangun sistem yang secara sistematis menyediakan informasi dan alat yang diperlukan, dalam format dan waktu yang tepat, agar LLM dapat menyelesaikan tugas"
Karakteristik context engineering
- Desain sistem menyeluruh: konteks bukan sekadar template prompt, melainkan keluaran dari seluruh sistem yang bekerja sebelum pemanggilan LLM
- Pembuatan dinamis: memilih dan mengolah beragam informasi seperti kalender/email/pencarian web secara real-time sesuai tugas
- Menyediakan informasi dan alat pada saat yang tepat: prinsip "Garbage In, Garbage Out"; penting untuk memastikan tidak ada informasi yang tidak perlu maupun yang terlewat bagi model
- Kejelasan format itu penting: saat memasukkan informasi, diperlukan peringkasan dan struktur alih-alih daftar yang berantakan, dan cara penggunaan alat juga harus disampaikan dengan jelas
Kesimpulan
- Esensi dari pengembangan agen AI yang kuat dan andal bukanlah "prompt ajaib" atau model terbaru, melainkan context engineering (merancang dan menyediakan konteks)
- Ini bukan sekadar masalah teknis, tetapi juga membutuhkan kemampuan desain sistem yang menyeluruh, seperti mendefinisikan informasi, alat, dan output terstruktur yang sesuai dengan kebutuhan dan tujuan bisnis
- Kuncinya adalah menyediakan informasi yang tepat dalam format yang benar pada saat yang tepat agar LLM dapat menyelesaikan tugasnya
Referensi
2 komentar
Terasa sekali seperti cuma ganti nama.
Komentar Hacker News
Saya baru-baru ini menulis posting blog tentang topik ini, silakan lihat tulisan saya - Context Engineering
Menurut saya, tulisan-tulisan Drew Breunig membahas topik ini dengan sangat fantastis
Memang kebetulan waktunya bertepatan dengan saat meme “context engineering” sedang beredar, tetapi sebenarnya pekerjaan itu tidak ada hubungannya dengan meme tersebut
Tulisan How Long Contexts Fail - Mengapa konteks panjang gagal menjelaskan dengan berbagai cara bagaimana konteks panjang menimbulkan masalah, dan bagaimana yang disebut “context rot” terjadi
Tulisan How to Fix Your Context - Cara memperbaiki konteks Anda memberi nama pada berbagai teknik seperti Tool Loadout, Context Quarantine, Context Pruning, Context Summarization, dan Context Offloading, lalu mengusulkan cara untuk memecahkan masalah
Saya rasa posting Drew Breunig benar-benar layak dibaca
Ini sangat penting bukan hanya saat membuat agen Anda sendiri, tetapi juga ketika menggunakan agentic coding sekarang
Keterbatasan dan pola perilaku seperti ini tampaknya akan terus ada untuk sementara waktu
Saya menantikan siapa yang pertama kali akan mengembangkan Logic Core yang mengotomatiskan context engineer
Saya pikir ini juga merupakan “skill seumur jagung”
Pada akhirnya ini akan segera menghilang seperti banyak tren lain
Isu-isu ini di dunia riset LLM dianggap sebagai produk dari LLM saat ini
Riset tentang cara menggunakan jutaan tool sekaligus dan memakai long context yang stabil sudah sedang berjalan
Ke depannya, kecuali untuk kasus khusus yang memerlukan koneksi ke penyedia lain, kemungkinan besar satu agen saja akan cukup untuk kebanyakan situasi
Orang-orang yang merancang sistem agen masa depan berdasarkan LLM saat ini mungkin akan bernasib seperti LangChain
Sama seperti LangChain yang dibuat untuk GPT-3 langsung menjadi usang di era GPT-3.5
Bagi orang yang pernah memakai LLM atau tahu cara kerjanya, ini adalah hal yang cukup jelas
“Skill” bernama prompt engineering juga sejak awal jelas hanya tren sementara dan tidak akan bertahan lama
Pada dasarnya ini tentang memberi input (konteks) dan tindakan (output) kepada LLM, dan situasi ini membutuhkan banyak pekerjaan pipeline
Saya setuju dengan kesimpulan bahwa “membangun agen AI yang kuat dan andal menjauh dari pencarian prompt ajaib atau update model”
Benar bahwa kita harus lebih fokus pada “context engineering yang menyediakan informasi dan tool yang tepat dalam format dan waktu yang tepat”
Tetapi jika “format yang tepat” dan “waktu yang tepat” itu sendiri tidak didefinisikan secara esensial, bukankah itu tetap saja mengejar “solusi ajaib”?
Jika “informasi yang tepat” berarti “informasi yang membuat LLM memberikan jawaban yang cukup akurat”, maka pada dasarnya saya tidak melihat perbedaannya dengan prompt engineering
Untuk mesin non-deterministik seperti ini, saya rasa memang tidak banyak heuristik yang benar-benar bisa diandalkan selain pendekatan “coba prompt lalu lihat hasilnya”
Pada akhirnya ini tetap semacam pola pikir magis tanpa akhir
Walaupun sekarang namanya diganti dari “prompt engineering” menjadi “context engineering”, pada akhirnya tetap saja aktivitas mengutak-atik berbagai hal untuk menemukan sesuatu yang bekerja di ruang yang tidak pasti
Pada dasarnya ini overfitting
Prompt engineering pada akhirnya memang seperti itu
Masalahnya adalah “format yang tepat, waktu yang tepat” tidak didefinisikan secara esensial
Sebagian besar nasihat tentang “cara menggunakan AI dengan baik” sebenarnya berangkat dari masalah ini
Ujung-ujungnya terasa seperti memukul genderang dan melakukan ritual perdukunan
Dalam kerangka teoretis terbaru, proses ini dibagi menjadi dua tahap: eksplorasi (Exploratory) dan penemuan (Discovery)
Tahap eksplorasi bisa dianggap sebagai semacam alat penyemprot materi ke atmosfer
Zat penanda yang mudah diidentifikasi diperkenalkan dengan kecepatan tinggi, biasanya dengan analogi feses
Tahap penemuan kemudian dikonseptualisasikan sebagai analisis terhadap pola penyebarannya
Jika diringkas, dua tahap ini bisa dijelaskan sebagai “asal coba” lalu “cek hasilnya”
Sekarang setelah semua orang sadar bahwa “prompt engineering” bukan skill hebat, rasanya industri AI terus menggeser patokan targetnya
Skill yang baru pada akhirnya adalah “pemrograman”
Sama seperti skill yang lama
Untuk memahami hal-hal ini, tulislah program sendiri
Tulis program untuk melatih LLM, menjalankan inferensi, dan menganalisis perilakunya, maka pemahaman Anda akan makin dalam
Pada awalnya saya punya teori dan hasil yang saya harapkan, tetapi setelah benar-benar melatih LLM dengan berbagai cara, saya mendapatkan hasil dan keyakinan yang sama sekali berbeda
Proses benar-benar mengimplementasikan tool itulah yang membuat perbedaan yang menentukan
Saya sendiri hanya punya pengalaman pemrograman machine learning tingkat menengah, tetapi saya pikir pengalaman benar-benar membuat compiler tingkat menengah sendiri adalah kunci untuk mendapatkan hasil yang baik pada sistem yang kompleks
Menurut Anda bagaimana Karpathy bisa mengetahui semua ini?
Jawabannya ada di blog Karpathy
Mirip dengan nasihat bahwa untuk memahami compiler, Anda harus menulis compiler sendiri
Secara teknis itu benar, tetapi kebanyakan orang tidak ingin mendalaminya sejauh itu
Rasanya diskusi ini makin lama makin mirip forum game seperti WoW, tempat para gamer bereksperimen dengan strategi dan berdebat dengan bahasa kelompok yang aneh
Apa yang disebut strategi itu hampir selalu ditemukan lewat trial and error, lalu dibicarakan dengan bahasa yang hanya dipahami kelompok tersebut
Pemrograman juga makin beradaptasi ke era gamifikasi
Terjadi fenomena ketika power user menjual strategi palsu kepada pemula atau kepada manajemen yang terlalu bermental gamer
Sebenarnya hal serupa juga berulang pada tren software enterprise sebelumnya
Bedanya kali ini, “tren yang dipimpin power user” itu merambah jauh ke wilayah pengaruh/kontrol/workflow yang sebelumnya dimiliki para developer, yaitu para builder
Emosi yang dirasakan developer saat ini mungkin tidak jauh berbeda dari yang dulu dirasakan orang-orang di QA, SRE, atau CS saat tooling atau praktik tertentu dipaksakan pada mereka dengan alasan “ini tren besar!”
Kesimpulan:
“Membangun agen AI yang kuat dan andal bukan soal prompt ajaib atau update model, melainkan context engineering yang menyediakan informasi dan tool yang tepat dalam format dan waktu yang tepat sesuai kebutuhan bisnis”
Sebenarnya prinsip yang sama juga berlaku untuk manusia
Jika Anda memberi informasi yang tepat pada waktu yang tepat, manusia juga akan menyelesaikannya dengan lebih baik
Saya tidak suka tren perbandingan dangkal antara machine learning dan manusia seperti ini
Tidak memberi wawasan, dan juga hampir tidak akurat
Pada akhirnya ini tentang menemukan dan menekan tombol tujuan secara efektif di dalam suatu lingkungan
Tidak terlalu berbeda dari software engineering yang sudah ada
Hanya saja hasilnya lebih non-deterministik
Saya selalu terus-menerus meminta tim UX dan product untuk menjelaskan hal-hal seperti “mockup, requirement, acceptance criteria, sample input/output, dan mengapa fitur ini penting”
Selama kita belum bisa memindai otak dan mengekstrak apa yang diinginkan, menjelaskan dengan benar apa yang diinginkan adalah kebutuhan mutlak di dunia nyata
Ini bukan hal yang bisa sekadar diserahkan pada ‘feeling’
Yang penting bukan lebih banyak konteks, melainkan konteks yang lebih baik
(contoh representatif: X-Y problem)
Bahkan jika Anda memberi konteks yang sangat bagus kepada LLM terbaru, ia tetap bisa gagal
Perusahaan kami sudah mendalami bagian ini selama lebih dari 2 tahun
Fanatisme terhadap gagasan bahwa ‘konteks adalah jawabannya’ sungguh mengejutkan
Pada titik tertentu saya merasa bekerja langsung tanpa AI justru lebih cepat
Setidaknya dari situ ada pelajaran berguna yang tersisa, bukan menghabiskan berjam-jam untuk membuat konteks bagi LLM
Saya penasaran dengan contoh spesifik ketika LLM gagal meskipun sudah diberi konteks yang cukup
Akan bagus jika Anda bisa membagikan contoh konkretnya
Mencari prompt ajaib tidak pernah benar-benar menjadi “prompt engineering”
Pada dasarnya sejak awal ini selalu soal “context engineering”
Banyak orang yang mengaku pakar AI menjual ini sebagai prompt engineering, tetapi sebenarnya mereka tidak benar-benar memahami esensinya
RAG (retrieval-augmented generation) bukan konsep yang tiba-tiba muncul tahun ini
Tool yang membungkus know-how kompleks seperti embedding, vector DB, graph DB, dan lainnya juga makin dipopulerkan
Platform-platform besar juga terus meningkatkan tool terkait dan menyediakan ekosistem yang lebih luas
Rasanya kita selalu membuat konsep baru dari isu yang sama lalu hanya mengganti namanya
Pada akhirnya ini terus terasa seperti ritual dukun, memukul genderang di depan api unggun sambil melafalkan mantra
Rasanya seperti memanggil iblis, dan Anda harus berharap mantra yang tepat dengan kata-kata yang tepat membuatnya mematuhi perintah Anda
Di dalam diri saya ada pergulatan antara jiwa engineer yang menginginkan reliabilitas, repeatability, dan test coverage yang kuat, dengan kompleksitas liar yang tidak bisa dikendalikan saat ini
Saya sangat menghormati orang-orang yang melakukan demo skala besar dengan sistem seperti ini
Ini mengingatkan saya pada masa demo riset kerentanan keamanan dulu
Betapapun matangnya persiapan, hasilnya bisa menyimpang kapan saja di tempat, dan saya ingat berkeringat deras saat presentasi
Ini benar-benar sejalan dengan pengalaman saya
Saat memasukkan konteks ke LLM, saya sering memakai pertanyaan “apakah manusia bisa menyelesaikannya hanya dengan informasi ini?”
Ketika dulu membuat produk text2SQL, saat model gagal, analis data sungguhan pun sering menjawab hal seperti “oh, tabel itu yang lama. Sekarang pakai tabel ini”
Pada akhirnya, LLM juga akan membuat kesalahan jika konteks yang dibutuhkan ‘analis manusia’ tidak tersedia
Jika ada satu hal yang kurang dari topik ini, itu adalah “evaluasi (evaluations)”
Saya masih terkejut melihat proyek AI yang tidak punya evaluasi atau menanganinya dengan serampangan
Evaluasi bahkan lebih penting daripada testing dalam engineering tradisional
Set evaluasi tidak perlu besar, asalkan cukup mencakup domain masalah
Tanpanya, semuanya hanya “tebakan”
Dan saya juga sering bertanya pada diri sendiri, “apakah manusia bisa menyelesaikannya hanya dengan informasi ini?”
Saya pernah berharap LLM menyelesaikan masalah yang bahkan manusia pun tidak bisa pecahkan
Hukum klasik pemrograman komputer
“Saat Anda mencoba membuat programmer bisa coding dalam bahasa Inggris, yang Anda temukan justru programmer ternyata tidak bisa menulis dengan baik bahkan dalam bahasa Inggris”
Ini memang agak bercanda, tetapi ada benarnya juga
Sebagian besar bahasa alami tidak terlalu jelas
Jika Anda bisa menyatakan dengan sangat tepat apa yang Anda inginkan dalam bahasa Inggris, mungkin Anda sejak awal bisa saja langsung menuliskannya dalam bahasa yang ditafsirkan mesin
Jika Anda mengajukan pertanyaan ya/tidak
ada kemungkinan 50% jawabannya salah
Memang ada sifat seperti itu
Saya sering membuat model mengajukan pertanyaan seperti ini terlebih dahulu sebelum benar-benar mulai bekerja
Misalnya, jika ada bagian yang tidak pasti, saya memberinya instruksi untuk bertanya dan meminta contoh pola kode yang sudah digunakan
Saya mengarahkannya agar bisa memakai template yang sudah ada sebagai contoh
Orang-orang yang cosplay sebagai data scientist tidak menginginkan evaluasi
Karena itu, di luar produk yang benar-benar dimonetisasi, hampir tidak ada evaluasi
Sebab mengatakan “raja telanjang” tidak menghasilkan uang
Tetapi untuk kasus yang benar-benar dibutuhkan di dunia kerja, evaluasi pasti dimasukkan