𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗔𝗿𝗲 𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝗛𝘂𝗴𝗲

People use the word agent for everything.

A function that calls a tool is an agent. A chatbot with memory is an agent. A script with a loop is an agent.

This mistake leads to bad engineering. Teams over-engineer simple tasks and under-engineer complex ones. I see teams spend weeks on agent orchestration for workflows that only need one good prompt.

Here is my definition of a real agent.

An agent has an objective. It does not just follow instructions. It decides what to do next. It handles failure. It knows when to stop.

Use these benchmarks:

  • If a human must guide every step, it is a chat interface.
  • If the system recovers from a failed tool call, it is moving toward an agent.
  • If the system breaks a goal into tasks and delegates them, it is a real agent.

Most successful agents are narrow. They do one job well. They handle customer support triage or document extraction. They are not general reasoning engines.

Successful teams focus on these three things:

  • Tool design: How clean is the interface?
  • Failure handling: What happens when a tool returns nothing?
  • Observability: Can you trace why the agent made a decision?

Unsuccessful teams just swap one model for a newer one and expect better results. They ignore the system design.

Frameworks like LangChain or CrewAI change every month. The framework matters less than the pattern.

Use these patterns:

  • Plan then execute: Separate the reasoning step from the execution step.
  • Separate retrieval from reasoning: Fetching context is a different job than using it.
  • Explicit handoffs: Use structured logs when one agent passes work to another.

The framework is just scaffolding. The architecture is the building.

RAG is standard, but chunking is often broken. If you split documents poorly, the model loses context. This leads to hallucinations.

If your RAG results are useless, check your chunking and metadata. The model is rarely the problem.

Models will get better. Context windows will grow. Token costs will drop.

None of that solves the real engineering challenge. You must build systems that behave correctly when you are not watching.

Focus on governance, observability, and reliable tool use. The best engineers will not be model researchers. They will be systems designers who build reliable AI.

Jendela konteks semakin besar, inilah alasan mengapa hal itu mengubah segalanya

Jendela konteks dari Large Language Models (LLM) sedang berkembang pada tingkat yang belum pernah terjadi sebelumnya. Kita telah beralih dari model yang nyaris tidak bisa mengingat beberapa paragraf menjadi model yang dapat menyerap seluruh perpustakaan buku dalam satu prompt tunggal.

Ini bukan sekadar pencapaian teknis; ini adalah pergeseran paradigma dalam cara kita membangun aplikasi berbasis AI.

Apa itu jendela konteks?

Secara sederhana, jendela konteks adalah jumlah informasi yang dapat "diproses" atau "diingat" oleh LLM pada satu waktu tertentu selama percakapan atau satu prompt tunggal. Anggap saja ini seperti memori jangka pendek dari AI tersebut.

Jika Anda memberikan prompt yang melebihi jendela konteks, model akan "melupakan" bagian awal percakapan untuk memberi ruang bagi informasi baru.

Evolusi Jendela Konteks

  • LLM Awal (era GPT-3): Jendela konteks berkisar sekitar 2.048 token. Ini berarti Anda hanya bisa melakukan percakapan yang sangat singkat atau memberikan konteks yang sangat terbatas.
  • Era Menengah (GPT-4, Claude 2): Jendela berkembang menjadi 8k, 32k, dan akhirnya 128k token. Ini memungkinkan instruksi yang jauh lebih kompleks dan dokumen yang lebih panjang.
  • Era Saat Ini (Gemini 1.5 Pro, Claude 3): Kita sekarang melihat jendela sebesar 200k, 1M, bahkan 2M token.

RAG vs. Konteks Panjang: Perdebatan Besar

Selama beberapa tahun terakhir, standar industri untuk memberi LLM akses ke data eksternal adalah Retrieval-Augmented Generation (RAG).

RAG bekerja dengan cara:

  1. Memecah dokumen Anda menjadi potongan-potongan kecil (chunks).
  2. Menyimpannya dalam database vektor.
  3. Saat pengguna mengajukan pertanyaan, mencari potongan yang paling relevan.
  4. Memasukkan potongan-potongan tersebut ke dalam jendela konteks LLM.

RAG sangat efisien dan hemat biaya, tetapi memiliki keterbatasan. RAG sangat bergantung pada kualitas langkah pengambilan (retrieval). Jika sistem retrieval gagal menemukan potongan yang tepat, LLM tidak akan pernah melihat informasi yang dibutuhkannya.

Konteks Panjang (Long Context) mengambil pendekatan yang berbeda. Alih-alih mencari potongan informasi, Anda cukup memasukkan seluruh dataset ke dalam jendela konteks.

Mengapa Konteks Panjang Mengubah Segalanya

  1. Tidak ada lagi kesalahan pengambilan (retrieval errors): Anda tidak perlu khawatir apakah pencarian vektor Anda menemukan informasi yang "tepat". Model memiliki akses ke semuanya.
  2. Penalaran yang lebih baik atas data yang kompleks: LLM dapat melihat hubungan antara bagian-bagian dokumen yang berjauhan, sesuatu yang sering kali hilang dalam RAG.
  3. Arsitektur yang lebih sederhana: Anda tidak perlu mengelola database vektor yang kompleks atau strategi chunking untuk setiap tugas.

Masalah "Lost in the Middle"

Namun, konteks panjang bukanlah solusi ajaib. Para peneliti telah mengidentifikasi sebuah fenomena yang disebut "Lost in the Middle".

Studi menunjukkan bahwa banyak LLM sangat mahir dalam mengambil informasi dari bagian awal atau bagian akhir jendela konteks yang panjang, tetapi mereka kesulitan menemukan informasi yang terkubur di tengah-tengah. Ini berarti, meskipun Anda memberikan 1 juta token, model mungkin tetap melewatkan detail krusial yang terletak pada token ke-500.000.

Masa Depan Pengembangan AI

Kita sedang bergerak menuju dunia di mana perbedaan antara "pelatihan" (training) dan "inferensi" (inference) menjadi kabur. Dengan jendela konteks yang masif, Anda secara efektif dapat "melatih" model pada dataset tertentu hanya dengan memberikannya dalam prompt.

Seiring dengan terus berkembangnya jendela konteks, fokus bagi para pengembang akan bergeser dari bagaimana cara mengambil informasi menjadi bagaimana cara menyusun informasi agar model dapat melakukan penalaran secara paling efektif.