Rekayasa konteks: pekerjaan sebelum perintah

Istilah yang ada saat ini, dalam dunia kecil agen AI, adalah rekayasa konteks.

Sepertinya ada label lain yang diciptakan untuk menjual sesuatu yang sudah kami lakukan. Sebagian memang demikian. Namun, seperti yang sering terjadi, label tersebut menarik perhatian karena memberi nama pada rasa sakit yang nyata.

Yang menyakitkan adalah ini: model tidak gagal hanya karena mereka "tidak berpikir". Seringkali mereka gagal karena kami mengirim mereka untuk bekerja dengan ruangan yang salah.

Kami memberi mereka instruksi lama. Kami menyembunyikan file penting darinya. Kami memberikan mereka dokumen yang terlalu panjang dan tidak menyebutkan apa yang penting. Kami menunjukkan kepada mereka log tanpa prioritas. Kami memberi mereka sepuluh alat tanpa menjelaskan kapan menggunakannya. Lalu kita kaget jika agen tersebut bergerak seperti orang yang terbangun di apartemen tak dikenal.

Promptnya adalah frasa yang Anda ucapkan padanya. Konteksnya adalah dunia yang Anda persiapkan di sekitarnya.

Dari rekayasa cepat hingga rekayasa konteks

Rekayasa cepat sering kali dianggap sebagai tulisan. Pilih kata yang tepat, tanyakan dengan cara yang benar, tambahkan contoh, tentukan formatnya.

Rekayasa konteks lebih dekat dengan arsitektur.

Anda tidak hanya bertanya “bagaimana cara merumuskan permintaannya?”. Ia bertanya:

• informasi apa yang benar-benar dibutuhkan?
• apa itu kebisingan?
• apa yang perlu dipulihkan dengan cepat?
• apa yang harus diingat?
• alat apa yang harus diekspos?
• instruksi mana yang stabil dan mana yang bergantung pada tugasnya?
• bagaimana cara membuat agen memahami apa yang otoritatif?

Ini adalah perubahan yang halus namun besar. Karena ketika Anda bekerja dengan agen, konteks bukanlah blok statis. Itu berubah di setiap langkah.

Agen membuka file, mempelajari sesuatu, menjalankan pengujian, menerima kesalahan, memperbarui rencana, memanggil alat, menemukan ketergantungan. Pada setiap putaran dia harus memutuskan apa yang harus dibawa dan apa yang tidak.

Ini adalah rekayasa.

Konteksnya bukan tempat pembuangan sampah

Templat dengan jendela konteks besar memberi kita godaan: ayo masukkan semuanya.

Itu bisa dimengerti. Jika saya mempunyai sejuta token, mengapa saya harus memilih?

Karena meskipun Anda bisa memasukkan semuanya, bukan berarti semuanya membantu. Memang benar, kebisingan mempunyai konsekuensi. Ini memerlukan token, memerlukan perhatian, memerlukan latensi, dan memerlukan kualitas. Seorang model bisa tersesat dalam detail yang tidak relevan seperti kita ketika kita membuka dua puluh tab dan tidak ingat lagi alasannya.

Konteks yang baik memiliki hierarki:

1. instruksi dan kebijakan sistem;
2. tujuan tertentu;
3. status saat ini;
4. data yang relevan;
5. kendala;
6. alat yang tersedia;
7. melacak keputusan yang sudah diambil.

Tidak perlu memperlakukan semuanya pada tingkat yang sama. Perintah pengguna lebih berharga daripada catatan lama. Tes yang gagal kini bernilai lebih dari sekadar preferensi estetika tiga bulan lalu. Kebijakan keamanan lebih berharga daripada jalan pintas produksi.

Rekayasa konteks juga berarti memberi bobot, bukan sekedar data.

Memori: ingat lebih sedikit, ingat lebih baik

Memori pada agen adalah salah satu topik yang paling licin.

Sebagai pengguna, Anda ingin agen mengenal Anda. Anda ingin dia mengingat nadanya, rencananya, kesepakatannya, hal-hal yang sudah diputuskan. Sebagai seorang insinyur, Anda tahu bahwa setiap memori yang persisten juga mempunyai risiko: bisa saja salah, lama, terlalu pribadi, terlalu umum, dan tidak dapat diverifikasi.

Memori yang berguna setidaknya harus memiliki tiga kualitas:

• asal: dari mana informasi ini berasal?
• tanggal: kapan kebenarannya?
• tujuan: jenis tugas apa yang sebaiknya digunakan?

Tanpa ketiga hal ini, ingatan menjadi takhayul.

Saya suka menganggap memori agen sebagai buku kerja, bukan sebagai pikiran ajaib. Ada catatan sementara, keputusan yang dikonfirmasi, preferensi gaya, kendala teknis, tautan ke sumber. Beberapa hal kedaluwarsa. Beberapa perlu ditulis ulang. Beberapa harus dihilangkan karena agen salah menyimpulkannya.

Sistem yang baik harus membuat pemeliharaan ini normal. Tidak heroik.

Pengambilan dan alat bukanlah hal yang sama

Ketika kita berbicara tentang konteks, sering kali kita langsung tertuju pada RAG. Penyematan, basis data vektor, pemotongan, pemeringkatan ulang.

Semuanya berguna. Namun pengambilan hanyalah salah satu cara untuk membawa informasi ke model. Dia bukan satu-satunya.

Agen bisa mendapatkan konteks dengan membaca file, menanyakan API, memanggil server MCP, membuka browser, menjalankan pengujian, mencari di Slack, melihat dasbor, bertanya kepada manusia.

Bagian yang menarik adalah menentukan rute mana yang akan digunakan dan kapan.

Jika agen perlu menjawab pertanyaan historis, mungkin pengambilan saja sudah cukup. Jika dia harus memperbaiki bug, dia harus membaca kode sebenarnya. Jika dia perlu memahami mengapa penerapan gagal, dia perlu melihat log baru. Jika Anda perlu menulis surat kepada pelanggan, Anda perlu mengetahui nada, riwayat, dan status tiket. Jika dia harus bertindak dalam produksi, dia harus meminta izin.

Konteks bukanlah database. Ini adalah alur kerja.

Agen yang baik juga tahu cara mengabaikannya

Tanda kedewasaan agen adalah kemampuan untuk mengatakan: Saya tidak memerlukan informasi ini.

Kelihatannya sepele, namun sangat sulit. Banyak sistem agen yang terakumulasi. Setiap panggilan alat menambahkan teks. Setiap kesalahan tetap berada di buffer. Setiap file yang dibaca menambah tumpukan. Pada akhirnya model tersebut memiliki sejarah yang sangat panjang dan tidak ada petanya.

Kompresi diperlukan. Sintesis perantara diperlukan. Itu perlu terstruktur.

Bukan "hanya itu yang terjadi", tetapi:

• objektif masih berlaku;
• hipotesis saat ini;
• file sudah diperiksa;
• keputusan yang diambil;
• risiko terbuka;
• tindakan selanjutnya.

Hal ini membuat agen tidak terlalu teatrikal dan lebih membantu. Bukan karena dia terlihat lebih pintar, tapi karena dia bekerja dengan meja yang rapi.

Rekayasa konteks untuk tim, bukan untuk seniman yang cepat

Alasan mengapa topik ini menarik minat saya adalah karena topik ini mengalihkan tanggung jawab dari individu ke sistem.

Dalam rekayasa cepat, orang yang paling bisa berbicara dengan model sering kali menang. Dalam rekayasa konteks, tim yang paling baik mengatur pekerjaannya adalah pemenangnya: dokumentasi, konvensi, isu, log, pengujian, kepemilikan, penamaan, sumber.

Repositori yang bersih menjadi konteks yang lebih baik. Masalah yang ditulis dengan baik akan menjadi bahan bakar yang lebih baik. Runbook yang diperbarui menghemat token dan kecemasan. Changelog yang jelas mengurangi halusinasi.

Ini adalah berita baik dan agak tidak menyenangkan. Indah karena menghargai praktik yang baik. Tidak nyaman karena Anda tidak dapat menyelesaikan semuanya dengan perintah yang cerdas.

Agen memperkuat kebersihan sistem yang mereka temukan.

Bagaimana saya akan menerapkannya besok

Jika saya memperkenalkan rekayasa konteks ke dalam proyek nyata, saya akan mulai dari hal-hal kecil:

• file instruksi proyek yang singkat dan terpelihara;
• contoh yang baik mengenai keluaran yang diharapkan;
• daftar alat yang tersedia dan kasus penggunaannya;
• keputusan arsitektur ditulis dengan cara yang dapat dikutip;
• terbitan dengan konteks wajib minimum;
• mudah untuk mengambil log dan tes;
• memori persisten yang dapat dimodifikasi oleh manusia.

Lalu saya akan mengukur hal sederhana: berapa kali agen harus meminta klarifikasi atau pergi ke arah yang salah?

Jika ini sering terjadi, saya tidak akan langsung menambahkan model yang lebih besar. Saya akan melihat konteksnya.

Bacaan saya

Rekayasa konteks adalah kata yang berlebihan, ya. Tapi konsepnya masuk akal.

Hal ini mengingatkan kita bahwa kecerdasan seorang agen tidak hanya terletak pada modelnya saja. Letaknya pada lingkungan yang kita persiapkan untuknya: apa yang dilihatnya, apa yang diingatnya, apa yang boleh ia lakukan, apa yang dilarang ia lakukan, sumber mana yang ia akui benar.

Bagian kemanusiaannya adalah: mempersiapkan konteks dengan baik adalah salah satu bentuk kepedulian. Ini memberi tahu agen, tetapi juga tim, "Saya tidak ingin Anda menebak-nebak, saya ingin Anda mendapatkan apa yang Anda butuhkan."

Kurang ajaib. Kamar yang lebih bersih. Agen membutuhkannya sama seperti kita.

Sumber

• Blog LangChain: Bangkitnya rekayasa konteks
• Simon Willison: Rekayasa konteks
• Protokol Konteks Model: Pendahuluan
• [Antropik: Membangun agen yang efektif](https://www.anthropic.com/engineering/building- Effective-agents)
• OpenAI: Alat baru untuk agen bangunan