Belajar AI Engineer - Context Engineering

#Pendahuluan

Di episode 7 kalian membangun RAG yang benar. Episode ini mengajarkan disiplin yang membedakan proyek demo dari produk produksi: context engineering — memperlakukan context window sebagai sumber daya langka yang harus dikelola dengan anggaran, bukan wadah yang diisi seadanya.

Mengapa penting? Karena konteks adalah biaya terbesar produk AI. Konteks yang panjang memperlambat respons, membengkakkan biaya per request, dan — kontra-intuitif — justru menurunkan akurasi ketika berisi hal yang tidak relevan. Engineer senior menghabiskan sebagian besar waktunya di sini: memangkas, mengompres, dan men-cache.

#Context Window Sebagai Anggaran

Setiap request adalah kombinasi dari beberapa lapisan konteks:

1. System prompt — instruksi global (statis).
2. Riwayat percakapan — pesan user/assistant sebelumnya.
3. Retrieved context — dokumen dari RAG.
4. Input saat ini — pertanyaan/perintah pengguna.
5. Output — jawaban model.

Disiplinnya: alokasikan anggaran eksplisit per lapisan:

Anggaran konteks

BUDGET = {
    "system": 500,
    "riwayat": 3000,
    "retrieved": 2500,
    "input": 500,
    "output": 1000,
}
MAX_KONTEKS = sum(BUDGET.values())
print(f"total anggaran: {MAX_KONTEKS} token")

Dengan anggaran ini, kita tahu apa yang harus dipangkas saat aplikasi mendekati batas — biasanya riwayat percakapan adalah korban pertama.

#Pemangkasan dan Kompresi Riwayat

Riwayat percakapan tumbuh tanpa henti. Tiga strategi yang umum:

1. Sliding window: hanya simpan N pesan terakhir.
2. Summary: ringkas pesan lama menjadi satu ringkasan.
3. Hybrid: ringkas lama + simpan detail pesan terakhir.

Sliding window sederhana

from openai import OpenAI
 
client = OpenAI()
MAX_HISTORY = 6  # 3 pasang user/assistant
 
def keep_last(messages: list[dict], n: int) -> list[dict]:
    system = [m for m in messages if m["role"] == "system"]
    rest = [m for m in messages if m["role"] != "system"]
    return system + rest[-n:]
 
def summarize_old(messages: list[dict]) -> str:
    r = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content":
            "Ringkas percakapan ini ke 2 kalimat: " + repr(messages)}],
        max_tokens=80,
    )
    return r.choices[0].message.content
 
def trim(messages: list[dict]) -> list[dict]:
    if len(messages) <= MAX_HISTORY + 1:
        return messages
    system = [m for m in messages if m["role"] == "system"]
    lama = messages[1:-MAX_HISTORY]
    baru = messages[-MAX_HISTORY:]
    ringkasan = {"role": "system", "content":
        "Ringkasan percakapan sebelumnya: " + summarize_old(lama)}
    return system + [ringkasan] + baru

Perhatikan pola hybrid: pesan lama dirangkum dan disuntikkan sebagai satu pesan system tambahan, sementara pesan terakhir tetap utuh. Model tetap punya konteks, tapi dengan biaya token yang jauh lebih kecil.

#Prompt Caching

Semua penyedia LLM besar menawarkan prompt caching: prefix prompt yang identik tidak dihitung penuh pada request berikutnya (dengan potongan harga hingga 90% untuk token yang di-cache). Prefix harus byte-identical — jadi tempatkan hal statis (system prompt, dokumen umum, riwayat lama) di depan, dan bagian yang berubah-ubah di belakang:

[bAGIAN STATIS] system prompt + dokumen umum
[bAGIAN DINAMIS] pertanyaan pengguna

Agar caching efektif, jangan menaruh bagian dinamis di tengah — urutan konstan membuat cache selalu terpukul (cache hit).

#Semantic Caching

Level optimasi berikutnya: jangan memanggil LLM sama sekali jika pertanyaan yang sama (atau hampir sama) sudah pernah dijawab. Simpan jawaban di vector DB, cari dengan kesamaan, dan langsung kembalikan jawaban cache jika skornya melewati ambang batas:

Caching semantik jawaban

from openai import OpenAI
import chromadb
 
client = OpenAI()
cache = chromadb.Client().get_or_create_collection("jawaban-cache")
THRESHOLD = 0.92
 
def get_answer(q: str) -> str:
    qv = client.embeddings.create(model="text-embedding-3-small", input=q)
    hasil = cache.query(query_embeddings=[qv.data[0].embedding], n_results=1)
 
    if hasil["documents"][0]:
        skor = 1 - hasil["distances"][0][0]  # cosine distance -> similarity
        if skor >= THRESHOLD:
            return f"(cache) {hasil['documents'][0][0]}"
 
    jawaban = llm_call(q)  # panggilan LLM biasa
    cache.upsert(ids=[q], documents=[jawaban], embeddings=[qv.data[0].embedding])
    return jawaban

Ini strategi pembunuh biaya di produksi: pertanyaan FAQ yang dijawab 10.000 kali sehari cukup dipanggil LLM sekali. Kita dalami lagi di episode 22.

#Common Pitfalls

• Mengisi konteks tanpa anggaran: ukur token tiap lapisan; jangan biarkan riwayat "tumbuh liar".
• Ringkasan yang membuang data: arsipkan data lengkap, ringkasan hanya untuk prompt.
• Caching dengan prefix tak stabil: cache hanya bekerja pada prefix yang identik byte-demi-byte.
• Threshold cache terlalu rendah: ambang rendah mengembalikan jawaban yang tidak relevan. Kalibrasi dengan evaluasi (episode 9).

#Penutup

Inti yang harus dibawa pulang:

• Konteks = anggaran: alokasikan token per lapisan (system, riwayat, retrieved, input, output).
• Trim + summary menjaga riwayat tetap relevan dan murah.
• Prompt caching memangkas biaya token berulang (prefix statis di depan).
• Semantic caching menghindari panggilan LLM berulang untuk pertanyaan mirip.

Di episode 9 selanjutnya kita memasang alat ukur: evaluation & metrics — LLM-as-judge, RAGAS, golden datasets, dan regression testing agar setiap perubahan prompt atau pipeline terukur. Sampai jumpa di episode 9!