2. Dasar-Dasar Membangun Agen

Di Bab 1, kamu melakukan pemanggilan LLM pertamamu dan melihat alur request-response dasar. Sekarang kita perlu memahami apa yang sebenarnya sedang kita bangun: sistem AI agentik. Bab ini membangun konsep-konsep fondasional yang akan kamu gunakan sepanjang buku ini.

Di akhir bab ini, kamu akan memahami:

• Apa yang membuat sebuah sistem AI menjadi "agentik" (dan kenapa ini penting)
• Kenapa framework seperti LangChain dan LangGraph ada
• Bagaimana LLM benar-benar bekerja di balik layar (dan kenapa ini memengaruhi desain agen)
• Ekonomi penggunaan LLM (token, biaya, dan pemilihan model)
• Cara menulis prompt yang efektif untuk sistem agen

Ini adalah bab konseptual - kita akan kembali ke coding praktik di Bab 3. Tapi konsep-konsep ini krusial untuk memahami keputusan desain yang akan kamu ambil saat membangun agen.

2.1) Apa itu AI Agentik? (Chatbot vs Agen)

Saat kebanyakan orang memikirkan "aplikasi AI", mereka membayangkan chatbot: kamu bertanya, AI menjawab, percakapan selesai. Tapi AI agentik pada dasarnya berbeda. Agen (agent) tidak hanya merespons - ia bertindak secara otonom untuk mencapai tujuan.

Perbedaan Inti

Mari mulai dengan definisi yang jelas:

Chatbot: Sistem yang merespons input pengguna dengan teks yang dihasilkan. Interaksinya murni percakapan. Chatbot tidak punya kemampuan untuk mengambil tindakan di dunia nyata selain menghasilkan pesan berikutnya.

Agen: Sistem yang bisa:

1. Memersepsi lingkungannya (misalnya, membaca status pesanan, mengecek inventori)
2. Memutuskan tindakan apa yang harus diambil (misalnya, memilih antara: membuat tiket, mengirim email, atau eskalasi)
3. Bertindak berdasarkan keputusan itu (misalnya, memanggil API, mengupdate database)
4. Beriterasi sampai mencapai tujuan (misalnya, verifikasi pesanan → buat tiket → konfirmasi → selesai)

Perbedaan kuncinya adalah otonomi dan tindakan. Chatbot bersifat reaktif; agen bersifat proaktif.

Contoh Konkret: Dukungan Pelanggan

Mari lihat perbedaan ini dalam praktik.

Pendekatan Chatbot:

Pengguna: "Saya ingin pengembalian dana untuk pesanan #12345"
 
Chatbot: "Saya mengerti Anda ingin pengembalian dana. Untuk memproses ini, silakan:
1. Kunjungi portal pengembalian dana kami di example.com/refunds
2. Masukkan nomor pesanan Anda
3. Pilih alasannya
4. Kirim formulirnya
5. Tunggu 24-48 jam untuk peninjauan manual
 
Ada lagi yang bisa saya bantu?"

Chatbot memberikan informasi tetapi tidak mengambil tindakan. Pengguna harus melakukan semua langkahnya.

Pendekatan Agen:

Pengguna: "Saya ingin pengembalian dana untuk pesanan #12345"
 
Agen (penalaran internal):
1. Pengguna ingin pengembalian dana untuk pesanan #12345
2. Saya perlu memverifikasi bahwa pesanan ini ada
3. [Memanggil get_order_details(order_id="12345")]
4. Pesanan ditemukan, memenuhi syarat untuk pengembalian dana
5. [Memanggil create_refund_ticket(order_id="12345", reason="customer_request")]
6. Tiket dibuat: TICKET-789
 
Agen: "Saya sudah membuat tiket pengembalian dana TICKET-789 untuk pesanan #12345. 
Tim pengembalian dana kami akan memproses ini dalam 3-5 hari kerja. 
Anda akan menerima email konfirmasi sebentar lagi."

Agen mengambil tindakan: ia memverifikasi pesanan, membuat tiket, dan mengonfirmasi hasilnya. Masalah pengguna terselesaikan tanpa langkah manual.

Kenapa Ini Penting untuk Pengembangan

Memahami perbedaan ini membentuk cara kamu mendesain sistem:

Pengembangan Chatbot:

• Fokus pada kualitas respons dan alur percakapan
• Kekhawatiran utama: menghasilkan teks yang membantu dan akurat
• Arsitektur sederhana: prompt → LLM → respons
• Tidak butuh integrasi eksternal

Pengembangan Agen:

• Fokus pada pengambilan keputusan dan eksekusi tindakan
• Kekhawatiran utama: memilih tindakan yang benar, menangani error, menjaga state
• Arsitektur kompleks: persepsi → penalaran → pemilihan aksi → eksekusi → verifikasi
• Membutuhkan integrasi alat, penanganan error, manajemen state

Spektrum Otonomi

Tidak semua agen sama-sama otonom. Ada spektrum:

Level 1: Tindakan dengan Bantuan

• Agen menyarankan tindakan, pengguna menyetujui satu per satu
• Contoh: "Saya bisa membuat tiket pengembalian dana. Mau saya lanjutkan?"
• Pendekatan paling aman untuk operasi berisiko tinggi

Level 2: Otonomi Terbatas

• Agen bertindak dalam batasan yang sudah ditentukan
• Contoh: Bisa membuat tiket dan mengirim email, tapi tidak bisa memproses pengembalian dana di atas $500 atau mengakses sistem pembayaran secara langsung
• Paling umum di sistem produksi (keseimbangan efisiensi dan keamanan)

Level 3: Otonomi Penuh

• Agen bertindak mandiri untuk mencapai tujuan
• Contoh: Menangani seluruh workflow pengembalian dana tanpa intervensi manusia
• Membutuhkan guardrail dan monitoring yang kuat

Karakteristik Kunci Agen

Sebagai rangkuman, sistem AI agentik punya properti inti berikut:

1. Menggunakan Alat: Bisa memanggil fungsi, API, dan layanan eksternal (Tanpa ini, itu hanya chatbot)
2. Berorientasi Tujuan: Bekerja menuju hasil spesifik, bukan sekadar merespons
3. Multi-Step: Memecah tugas kompleks menjadi urutan tindakan
4. Adaptif: Menyesuaikan perilaku berdasarkan hasil antara
5. Stateful: Menjaga konteks lintas beberapa interaksi

Dua yang pertama itu esensial - tanpa alat dan tujuan, kamu tidak punya agen. Sisanya adalah faktor kualitas yang membedakan agen bagus dari agen yang hebat.

Sekarang kamu paham apa itu agen dan kenapa mereka kuat.

2.2) Kenapa LangChain dan LangGraph?

Kamu mungkin bertanya: "Kenapa saya butuh framework? Saya kan bisa panggil OpenAI API langsung?" Mari kita bahas kenapa framework ada dan masalah apa yang mereka selesaikan.

Kompleksitas Pengembangan Agen

Membangun chatbot sederhana dengan raw API call itu mudah:

import openai
 
response = openai.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": "Halo!"}]
)
print(response.choices[0].message.content)

Ini bekerja baik untuk use case dasar. Tapi begitu kamu ingin membangun agen, kompleksitasnya meledak:

Tantangan 1: Workflow Multi-Step Agenmu perlu:

• Mengambil dokumen relevan dari knowledge base
• Memutuskan alat mana yang akan dipanggil berdasarkan intent pengguna
• Menjalankan alat dan menangani error
• Memformat hasil dan merespons pengguna

Setiap langkah butuh orkestrasi yang hati-hati, penanganan error, dan manajemen state.

Tantangan 2: Abstraksi Provider Bagaimana kalau kamu ingin:

• Berpindah dari OpenAI ke Anthropic atau Google?
• Menggunakan model yang berbeda untuk tugas yang berbeda?
• Fallback ke model yang lebih murah kalau model utama gagal?

Dengan raw API call, kamu perlu menulis ulang banyak kode untuk setiap provider.

Tantangan 3: Memori Percakapan Agen perlu mengingat konteks:

• Pesan-pesan sebelumnya dalam percakapan
• Dokumen yang di-retrieve dari query sebelumnya
• Hasil antara dari pemanggilan alat

Mengelola state ini secara manual rawan error dan melelahkan.

Tantangan 4: Integrasi Alat Agenmu perlu:

• Mendefinisikan alat yang tersedia dengan skema
• Membiarkan LLM memilih alat mana yang akan dipanggil
• Mem-parse argumen alat dari output LLM
• Menjalankan alat dengan aman dengan validasi
• Menangani error alat dan logika retry

Ini butuh banyak boilerplate code dan pertimbangan keamanan di setiap langkah.

Tantangan 5: Routing yang Kompleks Agen nyata butuh logika kondisional:

• "Kalau pengguna bertanya tentang pengembalian dana, retrieve dokumen kebijakan"
• "Kalau pengguna ingin pengembalian dana, buat tiket"
• "Kalau pertanyaan off-topic, tolak dengan sopan"

Mengimplementasikan ini dengan if-else akan cepat menjadi sulit dirawat.

Apa yang Disediakan LangChain

LangChain adalah framework untuk membangun aplikasi LLM. LangChain menyediakan:

1. Abstraksi Model

Antarmuka terpadu untuk berbagai provider LLM (OpenAI, Anthropic, Google, dll.).

from langchain_openai import ChatOpenAI
from langchain_anthropic import ChatAnthropic
 
# Antarmuka sama, provider berbeda
openai_llm = ChatOpenAI(model="gpt-5-mini")
anthropic_llm = ChatAnthropic(model="claude-4-5-sonnet")
 
# Keduanya memakai .invoke() dengan format message yang sama
response = openai_llm.invoke([{"role": "user", "content": "Halo"}])

Pindah provider tanpa menulis ulang logika aplikasi.

2. Rantai yang Komposabel (LCEL)

LangChain Expression Language - sintaks untuk menghubungkan komponen menjadi pipeline.

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
 
# Susun pipeline dengan operator | (mirip Unix pipes)
chain = prompt | llm | output_parser
 
# Eksekusi seluruh pipeline dengan satu pemanggilan
result = chain.invoke({"input": "pertanyaan pengguna"})

Bangun workflow kompleks tanpa perlu meneruskan data antar langkah secara manual. Kita akan mempelajari LCEL di Bab 6.

3. Memori Percakapan

Manajemen riwayat pesan untuk percakapan yang stateful.

from langchain_core.chat_history import InMemoryChatMessageHistory
 
# Helper untuk riwayat pesan
history = InMemoryChatMessageHistory()
history.add_user_message("Hai")
history.add_ai_message("Halo!")
 
# Ambil pesan saat dibutuhkan
messages = history.messages
response = llm.invoke(messages)

Abstraksikan penyimpanan pesan dengan helper class alih-alih mengelola list secara manual. Pada tahap ini, history masih di-pass secara eksplisit ke model. Kita akan mengintegrasikannya ke dalam chain di Bab 8. LangGraph (Bab 15+) membuat ini lebih mudah lagi dengan manajemen state bawaan.

4. Integrasi Alat

Sistem berbasis decorator untuk mengekspos fungsi Python ke LLM.

from langchain_core.tools import tool
 
@tool
def create_ticket(order_id: str, reason: str) -> str:
    """Membuat tiket dukungan untuk sebuah pesanan."""
    # Implementasi di sini
    return f"Tiket dibuat untuk {order_id}"
 
# LangChain menangani pembuatan skema dan integrasi LLM

Ubah fungsi Python apa pun menjadi alat yang bisa ditemukan dan dipanggil oleh LLM yang mendukung tool atau oleh agen — tanpa menulis JSON schema secara manual.

5. Document Loader dan Penyimpanan Vektor

Komponen siap pakai untuk memuat dokumen dari berbagai sumber dan menyimpannya sebagai embedding yang bisa dicari.

from langchain_community.document_loaders import TextLoader
from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings
 
# Muat dokumen
docs = TextLoader("support_docs.txt").load()
 
# Buat indeks yang bisa dicari
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(docs, embeddings)
 
# Retrieve dokumen yang relevan
results = vectorstore.similarity_search("kebijakan pengembalian dana")

Bangun sistem RAG menggunakan loader dan penyimpanan vektor yang sudah tersedia alih-alih mengimplementasikan parsing, embedding, dan retrieval dari nol.

Apa yang Disediakan LangGraph

LangGraph memperluas LangChain untuk workflow agen yang kompleks. LangGraph menyediakan:

1. Manajemen State yang Eksplisit

Tentukan semua data agen dalam satu skema bertipe alih-alih menyebarkannya di berbagai variabel.

from typing import TypedDict, Optional
from langchain_core.messages import BaseMessage
from langchain_core.documents import Document
 
class AgentState(TypedDict):
    messages: list[BaseMessage]
    retrieved_docs: list[Document]
    current_step: Optional[str]
 
# Semua data agen ada di sini - satu tempat untuk diperiksa saat debugging

Tidak perlu lagi mencari-cari di mana data berada atau bagaimana data mengalir antar langkah. Perubahan state itu eksplisit: node membaca dari state dan mengembalikan update. IDE kamu melakukan autocomplete nama field, dan type checker menangkap error sebelum runtime.

2. Workflow Berbasis Graf

Bangun workflow dengan mendeklarasikan langkah (node) dan koneksinya (edge), bukan dengan menulis kode orkestrasi.

graph = StateGraph(AgentState)
 
# Definisikan node (langkah dalam workflow kamu)
graph.add_node("retrieve", retrieve_docs)
graph.add_node("answer", generate_answer)
 
# Definisikan edge (transisi antar langkah)
graph.add_edge("retrieve", "answer")

Kamu mendefinisikan strukturnya—"retrieve jalan, lalu answer jalan"—dan LangGraph menangani eksekusinya. Tidak perlu menulis kode orkestrasi untuk meneruskan state antar langkah. Control flow seperti sequencing atau branching dideklarasikan dalam struktur graf itu sendiri.

3. Routing Kondisional

Pengambilan keputusan runtime tentang jalur mana yang diambil dalam workflow.

from langchain_core.messages import BaseMessage
 
def route_request(state):
    last_message = state["messages"][-1].content
    if "refund" in last_message:
        return "create_ticket"
    else:
        return "answer_question"
 
graph.add_conditional_edges(
    "classify",
    route_request,
    {
        "create_ticket": "create_ticket",
        "answer_question": "answer_question",
    }
)

Insight kuncinya: Fungsi routing mengembalikan nama node berikutnya ("create_ticket" atau "answer_question").

Kenapa ini penting: Logika keputusan kamu terpisah dari eksekusi. Ubah aturan routing? Edit satu fungsi. Lihat semua jalur yang mungkin? Lihat definisi graf. Debug jalur mana yang diambil? Periksa execution trace—tanpa menggali nested function call.

4. Checkpointing dan Persistensi

State secara otomatis di-checkpoint setelah setiap langkah, memungkinkan pemulihan saat crash serta workflow pause-resume.

from langgraph.checkpoint.sqlite import SqliteSaver
 
checkpointer = SqliteSaver("agent_state.db")
graph = graph.compile(checkpointer=checkpointer)
 
# State otomatis disimpan di setiap langkah
result = graph.invoke(
    input_state,
    config={"configurable": {"thread_id": "user-123"}}
)

Setelah setiap langkah, LangGraph melakukan checkpoint state saat ini ke penyimpanan persisten. Jika proses crash, eksekusi bisa dilanjutkan dari checkpoint terbaru yang terkait dengan thread ID yang sama.

Checkpointing memungkinkan workflow pause-and-resume, seperti menunggu persetujuan manusia, saat dikombinasikan dengan routing kondisional atau interrupt.

Kapan Menggunakan Masing-Masing Framework

Gunakan LangChain ketika:

• Membangun chain sederhana (prompt → LLM → parser)
• Mengimplementasikan sistem RAG
• Menangani konteks berbasis pesan (mem-pass chat history secara eksplisit)
• Melakukan abstraksi lintas provider LLM

Gunakan LangGraph ketika:

• Membangun workflow agen multi-step
• Mengimplementasikan logika routing kondisional
• Mengelola state yang kompleks antar langkah
• Membutuhkan checkpointing dan pemulihan saat crash

2.3) Cara Kerja LLM (untuk Pembuat Agen)

Untuk membangun agen yang efektif, kamu perlu memahami bagaimana LLM benar-benar bekerja. Ini bukan soal matematika transformer - ini tentang model mental yang membentuk cara kamu mendesain sistem agen.

Mekanisme Inti: Prediksi Token

Berikut insight fundamentalnya: LLM tidak "tahu" fakta seperti database. Mereka memprediksi token berikutnya.

Mari kita uraikan dengan contoh yang konkret.

Input: "The capital of France is"

Yang mungkin kamu kira terjadi:

1. LLM "mencari" ibu kota Prancis di knowledge base-nya
2. LLM "mengambil" jawabannya: Paris
3. LLM mengembalikan "Paris"

Yang sebenarnya terjadi:

1. LLM mengubah input menjadi token: ["The", "capital", "of", "France", "is"]
2. LLM menghitung distribusi probabilitas atas SEMUA token berikutnya yang mungkin
3. Token berikutnya yang paling mungkin: "Paris" (probabilitas tertinggi)
4. LLM melakukan sampling dari distribusi (biasanya memilih probabilitas tertinggi)
5. LLM mengembalikan "Paris"

LLM tidak "tahu" bahwa Paris adalah ibu kota. Ia memprediksi "Paris" sebagai token berikutnya yang paling mungkin berdasarkan pola input.

(Catatan: Tokenisasi dan probabilitas bersifat konseptual dan bervariasi menurut model dan tokenizer.)

Kenapa Ini Penting untuk Agen

Model prediksi token ini punya implikasi besar untuk desain agen:

Implikasi 1: LLM Bisa Berhalusinasi

Karena LLM memprediksi token (bukan mengambil fakta), ia bisa menghasilkan informasi yang terdengar masuk akal tapi salah.

from langchain_openai import ChatOpenAI
 
llm = ChatOpenAI(model="gpt-4o-mini")
response = llm.invoke("Apa ibu kota Atlantis?")
print(response.content)
 
# Catatan: Output aktual bisa bervariasi.
# Model modern mungkin mengenali Atlantis sebagai fiksi dan menolak menjawab.
# Poin utamanya:
# tanpa fact-checking yang eksplisit, LLM bisa menghasilkan informasi salah yang terdengar masuk akal.

Kemungkinan output (historis atau tanpa pembatasan):

Ibu kota Atlantis adalah Etheria. Menurut catatan Plato, Etheria adalah kota pelabuhan yang berada di ujung paling timur pulau itu, dan namanya berasal dari keyakinan bahwa tempat itu menjulang hingga ke langit.

LLM menghasilkan jawaban yang terdengar wajar meskipun Atlantis itu fiksi. Untuk agen, ini berarti:

• Jangan pernah mempercayai output LLM secara membabi buta
• Validasi fakta terhadap sumber yang otoritatif
• Implementasikan guardrail

Implikasi 2: Konteks Itu Segalanya

LLM hanya melihat token yang kamu berikan. Ia tidak punya memori percakapan sebelumnya kecuali kamu menyertakan konteks itu secara eksplisit.

# Pemanggilan pertama
response1 = llm.invoke("Nama saya Alice")
print(response1.content)  # "Senang bertemu denganmu, Alice!"
 
# Pemanggilan kedua (invocation terpisah)
response2 = llm.invoke("Siapa nama saya?")
print(response2.content)  # "Saya tidak punya akses ke nama Anda..."

Pemanggilan kedua tidak punya konteks dari yang pertama. Untuk agen, ini berarti:

• Kamu harus mengelola riwayat percakapan
• Batas context window itu penting
• Manajemen state itu krusial

Implikasi 3: Prompt Itu Instruksi, Bukan Query

Karena LLM memprediksi token, cara kamu merumuskan prompt sangat memengaruhi kualitas output.

# Prompt lemah (gaya query)
response = llm.invoke("kebijakan pengembalian dana")
# Output: "Apa yang ingin Anda ketahui tentang kebijakan pengembalian dana?"
 
# Prompt kuat (gaya instruksi)
response = llm.invoke(
    "Kamu adalah agen dukungan pelanggan. Jelaskan kebijakan pengembalian dana kami dengan jelas dan ringkas."
)
# Output: "Kebijakan pengembalian dana kami mengizinkan pengembalian dalam 30 hari..."

Untuk agen, ini berarti:

• Prompt adalah mekanisme kontrol utama kamu
• Prompt engineering adalah skill inti
• System message menentukan perilaku agen

Implikasi 4: Output Terstruktur Membutuhkan Panduan

LLM secara natural menghasilkan teks bebas. Mendapatkan output terstruktur (JSON, format tertentu) butuh instruksi eksplisit.

# Tanpa panduan struktur
response = llm.invoke("Ekstrak ID pesanan dari: 'Saya ingin pengembalian dana untuk pesanan #12345'")
print(response.content)
# Output: "ID pesanan adalah 12345" (teks biasa, format tidak konsisten)
 
# Dengan panduan struktur
response = llm.invoke(
    'Ekstrak ID pesanan dan kembalikan HANYA sebuah objek JSON dengan format: {"order_id": "..."}\n\n'
    "Teks: 'Saya ingin pengembalian dana untuk pesanan #12345'"
)
print(response.content)
# Output: {"order_id": "12345"} (terstruktur, bisa di-parse)

Untuk agen, ini berarti:

• Gunakan skema untuk membatasi format output
• Tentukan format output secara eksplisit
• Validasi dan parse respons LLM

Teks bebas dioptimalkan untuk manusia. Agen membutuhkan pemformatan eksplisit agar bisa dibaca mesin.

Determinisme, Stokastisitas, dan LLM Modern

LLM pada dasarnya adalah sistem probabilistik. Mereka menghasilkan teks dengan memprediksi token berikutnya yang paling mungkin, bukan dengan menjalankan aturan deterministik. Akibatnya, input yang sama tidak selalu menjamin output yang sama.

Pada model-model lebih awal, developer mengontrol randomness ini secara eksplisit menggunakan parameter seperti temperature. Nilai yang lebih rendah menghasilkan output yang lebih bisa diprediksi, sedangkan nilai yang lebih tinggi mendorong variasi dan kreativitas.

Banyak model berorientasi penalaran modern tidak lagi mengekspos parameter seperti temperature atau top_p. Sebagai gantinya, mereka mengelola strategi decoding dan sampling secara internal untuk memprioritaskan penalaran yang stabil dan terstruktur. Namun, ini bukan berarti model-model ini sepenuhnya deterministik.

Bahkan model-model ini pun tidak menjamin output yang identik. Output bisa bervariasi karena:

• Sampling internal: Model bisa mengikuti jalur penalaran yang berbeda, menghasilkan output yang bervariasi dalam struktur, detail, atau frasa.
• Update model: Provider terus memperbarui model tanpa pemberitahuan, sehingga prompt yang sama bisa menghasilkan respons yang berbeda seiring waktu.
• Safety filter: Moderasi konten bisa membuat model menjawab langsung pada satu kasus tapi berhati-hati, menolak, atau memparafrase pada kasus lain.
• Kebijakan alat: Dalam sistem agen, model bisa memanggil alat yang berbeda—atau tidak memanggil alat sama sekali—untuk input yang sama, mengubah jalur eksekusi.

Apa artinya ini bagi pembuat agen:

Kekhawatiran utamanya bukan tuning parameter—melainkan seberapa konsisten hasilnya. Sistem agen seharusnya didesain dengan asumsi bahwa output LLM bisa bervariasi dalam kata-kata, struktur, atau bahkan kesimpulan kecuali jika dibatasi secara eksplisit.

Ini mengarah ke beberapa prinsip desain konkret untuk sistem agen:

• Jangan pernah bergantung pada kata-kata persis untuk keputusan logika — control flow harus bergantung pada sinyal terstruktur (skema, enum, flag), bukan pada pencocokan frasa spesifik dalam output model.
• Paksa struktur di batas-batas — kapan pun output LLM dikonsumsi oleh kode, batasi dengan skema, validator, atau format ketat agar program tidak pernah perlu “menafsirkan” teks bebas.
• Verifikasi apa pun yang penting — fakta yang memengaruhi uang, izin, atau tindakan yang tidak bisa dibatalkan harus dicek dengan alat atau sistem eksternal, bukan dipercaya dari model saja.
• Perlakukan output LLM sebagai proposal, bukan keputusan — model menyarankan apa yang harus dilakukan, tapi sistem yang memutuskan apakah, kapan, dan bagaimana bertindak.

Dalam sistem agen modern, keandalan datang dari desain sistem, bukan dari tuning parameter. Semakin kritis tugasnya, semakin sedikit kebebasan yang seharusnya dimiliki model—dan semakin banyak struktur yang harus ditegakkan oleh agenmu.

Inti Utama: Bangun agen yang andal melalui skema, validasi, dan integrasi alat—bukan dengan berharap output LLM konsisten.

Di bagian berikutnya, kita akan mengeksplorasi implikasi ekonomi dari pemrosesan berbasis token.

2.4) Token: Sumber Daya Fundamental

Token adalah unit dasar yang diproses LLM. Memahami token itu penting karena token menentukan baik apa yang mungkin (batasan) maupun apa yang mahal (biaya) dalam sistem agen.

Apa Itu Token?

Sebuah token adalah unit teks terkecil yang diproses LLM saat bernalar dan saat menghasilkan keluaran.

Tergantung bahasa dan konteksnya, token bisa merepresentasikan:

• Sebuah kata (agent)
• Bagian dari kata (calculat, ion)
• Angka atau simbol (#, 123)
• Tanda baca atau whitespace

Token bukan karakter dan bukan kata — token adalah unit spesifik model yang dibuat oleh tokenizer.

Setiap informasi yang dikirim ke atau dihasilkan oleh model diukur dalam token:

• Instruksi sistem
• Pesan pengguna
• Dokumen yang di-retrieve
• Deskripsi alat
• Output model

Token adalah mata uang fundamental dari interaksi LLM.

Token sebagai Batasan Sistem

Token bukan hanya biaya—mereka adalah batas keras atas apa yang bisa dilakukan agenmu dalam satu request.

Setiap LLM punya context window: jumlah maksimum token tetap yang bisa diproses sekaligus.

Contoh skenario: Agen dukungan pelangganmu membutuhkan:

• Instruksi sistem: 200 token
• 10 pesan terakhir: ~2.000 token
• 3 artikel bantuan yang di-retrieve: ~1.500 token
• Respons yang dihasilkan: ~200 token
• Total: 3.900 token

Kalau context window modelmu 4.000 token, kamu berada di 97,5% kapasitas. Satu pesan panjang lagi dan sistem berhenti bekerja.

(Model modern biasanya punya context window 128K+ token, tetapi prinsipnya tetap: konteks itu terbatas, dan kamu harus mendesain dengan mempertimbangkan batas ini.)

Apa yang terjadi saat kamu melewati batas:

• Pesan lama terbuang → Agen melupakan konteks sebelumnya, memutus kesinambungan percakapan
• Dokumen yang di-retrieve terpotong → Informasi kritis hilang, memicu jawaban yang salah
• Request gagal total → Sistem tidak bisa merespons sama sekali

Kamu tidak bisa membayar untuk ruang ekstra. Context window adalah batas keras—seperti mencoba memasukkan 2 liter ke botol 1 liter.

Inilah kenapa agen yang berjalan lama harus secara aktif mengelola apa yang tetap berada dalam konteks dan apa yang tidak. Manajemen token adalah pertimbangan arsitektur inti, bukan sekadar detail optimasi.

Apa yang Dipengaruhi Token Secara Langsung

Di luar batas context window langsung, token membentuk dua keputusan desain yang kritis:

1. Strategi Memori: Riwayat Penuh vs Ringkasan

Menyimpan riwayat percakapan penuh mempertahankan detail tetapi membuat penggunaan token terus meningkat.

Alternatif yang umum adalah ringkasan memori:

• Ganti pesan yang lebih lama dengan ringkasan yang ringkas
• Pertahankan intent sambil mengurangi biaya token

Trade-off ini memengaruhi:

• Biaya
• Akurasi
• Konsistensi agen jangka panjang

Karena itu, desain memori adalah masalah manajemen token.

2. Ukuran Chunk RAG dan Strategi Retrieval

Dalam Retrieval-Augmented Generation (RAG), dokumen dipecah menjadi chunk sebelum retrieval.

• Chunk besar

  • Lebih sedikit panggilan retrieval
  • Biaya token per request lebih tinggi
  • Lebih banyak konteks yang tidak relevan

• Chunk kecil

  • Biaya token lebih rendah
  • Presisi lebih tinggi
  • Risiko melewatkan informasi kunci

Ukuran chunk adalah keputusan desain yang kritis — ini berdampak langsung pada biaya dan kualitas jawaban.

Ekonomi Token

Memahami biaya token membantumu membangun sistem yang hemat biaya.

Harga Tipikal (2026):

Insight Kunci: Token output berbiaya 4–8x lebih mahal daripada token input, yang berarti generasi yang tidak terkontrol sering menjadi pendorong biaya terbesar di sistem produksi.

Estimasi Biaya Cepat:

Untuk request tipikal dengan 500 token input dan 50 token output menggunakan GPT-5-mini:

• Input: (500 / 1,000,000) × $0.25 = $0.000125
• Output: (50 / 1,000,000) × $2.00 = $0.0001
• Total: ~$0.000225 per request

Pada 10,000 request/hari: ~$67.5/bulan

Optimasi Biaya dalam Praktik

Strategi 1: Cocokkan Model dengan Kompleksitas Tugas

Gunakan model yang lebih kecil dan murah untuk tugas sederhana:

from langchain_openai import ChatOpenAI
 
# Model mahal untuk penalaran kompleks
complex_llm = ChatOpenAI(model="gpt-5")
 
# Model murah untuk tugas sederhana
simple_llm = ChatOpenAI(model="gpt-5-nano")
 
def get_llm_for_task(task_type):
    if task_type == "complex_reasoning":
        return complex_llm
    else:
        return simple_llm

Strategi 2: Seimbangkan Ukuran Konteks dengan Kualitas

Sertakan hanya konteks yang diperlukan:

# Efisien: Sertakan hanya chunk yang relevan
relevant_chunks = retrieve_top_k(user_question, k=3)  # ~500 token
prompt = f"Konteks: {relevant_chunks}\n\nPertanyaan: {user_question}"

Penting: Pengurangan konteks yang terlalu agresif bisa merusak akurasi jawaban. Seimbangkan penghematan biaya dengan kualitas.

Strategi 3: Kontrol Panjang Output

Batasi seberapa banyak model menghasilkan:

# Biaya terkendali
llm = ChatOpenAI(model="gpt-5-mini", max_tokens=100)
response = llm.invoke(messages)
# Maksimum 100 token output

Inti Utama: Manajemen token bukan hanya tentang menurunkan biaya—ini tentang mendesain sistem agen yang andal dan scalable dalam batas sumber daya yang keras.

Di bagian berikutnya, kita akan mengeksplorasi lanskap model dan belajar memilih model yang tepat untuk tiap tugas.

2.5) Memahami Lanskap Model

Memilih LLM yang tepat untuk agenmu membutuhkan keseimbangan antara:

• Context window: Seberapa banyak teks yang bisa diproses model?
• Biaya: Berapa biaya tiap request?
• Latensi: Seberapa cepat model merespons?
• Kapabilitas: Seberapa baik model bernalar?

Mari kita survei lanskap model 2026.

Keluarga Model Utama

Model OpenAI GPT

Model Anthropic Claude

Model Google Gemini

Fitur Spesifik Provider

OpenAI:

• Paling cocok untuk: Agen general-purpose, workflow multi-domain yang luas, function calling
• Unggul dalam: Penalaran serbaguna, tooling & ekosistem developer yang kuat, update model yang sering

Anthropic:

• Paling cocok untuk: Workflow yang sensitif terhadap keamanan, penalaran terstruktur dan panjang
• Unggul dalam: Analisis mendalam, output metodis, pemikiran panjang dengan alignment yang kuat

Google:

• Paling cocok untuk: Menangani konteks masif dan tugas multimodal
• Unggul dalam: Analisis dokumen skala besar, pemahaman multimodal, pemrosesan throughput tinggi

Mencocokkan Model dengan Tugas

Pilih berdasarkan kompleksitas tugas, ukuran konteks, dan kebutuhan latensi:

Berdasarkan Kompleksitas Tugas

Tugas Sederhana → Model yang dioptimalkan biaya (GPT-5-nano, GPT-5-mini):

• Klasifikasi intent, analisis sentimen, ekstraksi keyword, pemformatan sederhana
• Pilih saat: Biaya adalah kekhawatiran utama

Tugas Menengah → Model seimbang (GPT-5-mini):

• Menjawab pertanyaan, ringkasan, pemilihan alat
• Pilih saat: Perlu menyeimbangkan biaya dan kualitas

Tugas Kompleks → Model berfokus performa (GPT-5, Claude Sonnet, Gemini Pro):

• Penalaran multi-step, generasi kode, analisis detail
• Pilih saat: Kapabilitas penalaran penting, biaya dapat diterima

Kompleksitas Tertinggi → Model premium (Claude Opus):

• Penalaran sangat kompleks, keputusan mission-critical
• Pilih saat: Akurasi adalah yang utama, biaya nomor dua

Berdasarkan Kebutuhan Latensi

Real-Time (~1s atau latensi yang terasa ≤1s) → Model cepat (GPT-5-nano, Gemini Flash):

• Chat yang berhadapan langsung dengan pengguna
• Aplikasi interaktif

Near Real-Time (1-3s) → Kebanyakan model:

• Tugas agen standar

Batch (>3s) → Model yang kapabel:

• Analisis di background

Pertimbangan Context Window

Tugas standar: Semua model utama mendukung 200K+ token, cukup untuk kebanyakan workflow agen.

Kasus spesial:

• Butuh 400K token: keluarga GPT-5 (analisis dokumen penuh, codebase besar)
• Butuh 1M token: model Gemini (buku utuh, kumpulan dokumen masif)

Saran praktis: Bahkan dengan context window besar, selective retrieval (RAG) biasanya menghasilkan hasil yang lebih baik.

Inti Utama

1. Tidak ada satu model "terbaik" → Model yang berbeda unggul untuk tugas yang berbeda
2. Cocokkan model dengan kompleksitas tugas → Jangan overpay untuk tugas sederhana
3. Context window ≠ lebih baik → Gunakan selective retrieval
4. Latensi memengaruhi pengalaman pengguna → Pertimbangkan waktu respons untuk tugas interaktif

Dalam praktik: Kebanyakan agen memakai beberapa model—model murah untuk tugas sederhana, model yang lebih kapabel untuk penalaran kompleks. Kita akan mengimplementasikan ini di bab-bab berikutnya.

Di bagian berikutnya, kita akan belajar mengontrol perilaku model melalui prompting yang efektif.

2.6) Dasar-Dasar Prompting untuk Sistem Agen

Prompt adalah antarmuka utama kamu untuk mengontrol perilaku LLM. Untuk agen, prompting yang efektif itu krusial - ini menentukan apakah agenmu membuat keputusan yang benar, memanggil alat yang tepat, dan menghasilkan output yang andal.

Anatomi sebuah Prompt

Prompt yang lengkap memiliki tiga komponen:

1. System Message (Role dan Constraints) Mendefinisikan persona agen, kapabilitas, dan batasannya.

2. Context (Informasi yang Relevan) Menyediakan informasi yang dibutuhkan untuk menyelesaikan tugas.

3. Instruction (Tugas Spesifik) Memberi tahu agen secara tepat apa yang harus dilakukan.

Mari lihat ini dalam praktik:

from langchain_openai import ChatOpenAI
 
llm = ChatOpenAI(model="gpt-5-mini")
 
response = llm.invoke([
    # System message: Definisikan role dan constraints
    {
        "role": "system",
        "content": """Kamu adalah agen dukungan pelanggan untuk TechCorp.
        
Kapabilitas kamu:
- Menjawab pertanyaan tentang kebijakan pengembalian dana
- Membuat tiket dukungan
- Memberikan panduan troubleshooting
 
Constraints kamu:
- Hanya jawab pertanyaan tentang produk TechCorp
- Jangan pernah membuat janji tentang timeline pengembalian dana
- Selalu sopan dan profesional"""
    },
    
    # User message: Context + Instruction
    {
        "role": "user",
        "content": """Konteks: Pelanggan membeli laptop model X500 pada 2026-01-15.
Hari ini 2026-02-20. Kebijakan pengembalian dana kami mengizinkan pengembalian dalam 30 hari.
 
Instruksi: Pelanggan ingin pengembalian dana. Apa yang harus saya sampaikan kepada mereka?"""
    }
])
 
print(response.content)

Output:

Saya mengerti Anda ingin pengembalian dana untuk laptop model X500. Sayangnya, 
karena pembelian Anda pada 15 Januari dan hari ini 20 Februari, kita sudah 
melewati batas pengembalian 30 hari. Namun, saya dengan senang hati bisa membuat 
tiket dukungan untuk mengeksplorasi opsi lain, seperti layanan garansi atau penukaran. 
Apakah Anda ingin saya melanjutkan dengan itu?

System Message: Menetapkan Perilaku Agen

System message adalah tempat kamu mendefinisikan kepribadian dan kapabilitas agen. Ini bagian terpenting dari prompting agen.

System Message yang Lemah:

system_message = "Kamu adalah asisten yang membantu."

System Message yang Kuat:

system_message = """Kamu adalah agen dukungan pelanggan untuk TechCorp.
 
ROLE:
Kamu membantu pelanggan dengan permintaan pengembalian dana, pertanyaan produk, dan masalah teknis.
 
CAPABILITIES:
- Menjawab pertanyaan menggunakan dokumentasi yang disediakan
- Membuat tiket dukungan saat diperlukan
- Memberikan troubleshooting langkah demi langkah
 
CONSTRAINTS:
- Hanya jawab pertanyaan tentang produk TechCorp
- Jika kamu tidak tahu sesuatu, katakan - jangan pernah menebak
- Selalu cantumkan sumber saat menggunakan dokumentasi
- Jangan pernah menjanjikan timeline atau hasil tertentu
 
TONE:
Profesional, empatik, dan fokus pada solusi.
"""

Kenapa versi yang kuat bekerja lebih baik:

1. Kapabilitas eksplisit → Agen tahu apa yang bisa ia lakukan
2. Constraints jelas → Agen tahu apa yang harus dihindari
3. Tone terdefinisi → Kepribadian konsisten
4. Instruksi spesifik → Mengurangi ambiguitas

Kejelasan Instruksi: Harus Spesifik

LLM mengikuti instruksi secara literal. Instruksi yang samar menghasilkan hasil yang tidak andal.

Instruksi yang Samar:

instruction = "Bantu pelanggan dengan pengembalian dana mereka."

Instruksi yang Spesifik:

instruction = """Analisis permintaan pelanggan dan tentukan:
1. Apakah pesanan memenuhi syarat untuk pengembalian dana? (Cek tanggal pembelian vs kebijakan pengembalian dana)
2. Jika memenuhi syarat: Jelaskan proses pengembalian dana
3. Jika tidak memenuhi syarat: Jelaskan alasannya dan tawarkan alternatif
 
Format respons kamu sebagai:
- Kelayakan: [YA/TIDAK]
- Alasan: [Penjelasan singkat]
- Langkah Berikutnya: [Apa yang harus dilakukan pelanggan]
"""

Manajemen Konteks: Berikan yang Dibutuhkan

Agen butuh konteks untuk mengambil keputusan, tapi terlalu banyak konteks membuang token dan membingungkan model.

Over-Contextualization (Boros):

context = f"""
Sejarah Perusahaan: TechCorp didirikan pada 1995...
Katalog Produk: Kami menjual 500+ produk termasuk...
Kebijakan Pengembalian Dana: {refund_policy_text}
Kebijakan Pengiriman: {shipping_policy_text}
Kebijakan Garansi: {warranty_policy_text}
Riwayat Pelanggan: {full_customer_history}
"""
# 5000+ token, kebanyakan tidak relevan

Konteks Selektif (Efisien):

context = f"""
Kebijakan Relevan: {refund_policy_text}
Detail Pesanan: {order_details}
"""
# 200 token, semuanya relevan

Pemformatan Output: Strukturkan Respons Kamu

Untuk agen, kamu sering membutuhkan output terstruktur (JSON, format spesifik) bukan teks bebas.

Output Tidak Terstruktur (Sulit Di-parse):

response = llm.invoke([
    {"role": "system", "content": "Kamu adalah agen dukungan."},
    {"role": "user", "content": "Haruskah kita membuat tiket untuk permintaan pengembalian dana ini?"}
])
print(response.content)
# Output: "Ya, saya pikir kita harus membuat tiket karena..."
# Masalah: Sulit di-parse, format tidak konsisten

Output Terstruktur (Mudah Di-parse):

response = llm.invoke([
    {"role": "system", "content": """Kamu adalah agen dukungan.
    
Selalu merespons dalam format JSON ini:
{
  "action": "CREATE_TICKET" or "ANSWER_QUESTION" or "ESCALATE",
  "reason": "Penjelasan singkat",
  "response_text": "Apa yang harus disampaikan ke pelanggan"
}"""},
    {"role": "user", "content": "Pelanggan ingin pengembalian dana untuk pesanan #12345, dibeli 40 hari lalu"}
])
print(response.content)

Output:

{
  "action": "CREATE_TICKET",
  "reason": "Pesanan di luar batas 30 hari pengembalian dana, perlu peninjauan manual",
  "response_text": "Saya sudah membuat tiket dukungan untuk meninjau permintaan pengembalian dana Anda. Tim kami akan menghubungi Anda dalam 24 jam."
}

Kita akan memakai skema Pydantic untuk output terstruktur yang robust di Bab 7.

Contoh Few-Shot: Tunjukkan, Jangan Hanya Mengatakan

Untuk tugas kompleks, memberikan contoh lebih efektif daripada instruksi panjang.

Zero-Shot (Instruksi Saja):

prompt = """Ekstrak ID pesanan, nama produk, dan masalah dari pesan pelanggan.
 
Pesan pelanggan: "Laptop X500 saya pesanan #12345 tidak bisa menyala"
"""
# Model mungkin kesulitan dengan format

Few-Shot (Dengan Contoh):

prompt = """Ekstrak ID pesanan, nama produk, dan masalah dari pesan pelanggan.
 
Contoh 1:
Input: "Laptop X500 saya pesanan #12345 tidak bisa menyala"
Output: {"order_id": "12345", "product": "laptop X500", "issue": "tidak bisa menyala"}
 
Contoh 2:
Input: "Pesanan 67890 - ponsel tidak mengisi daya"
Output: {"order_id": "67890", "product": "ponsel", "issue": "tidak mengisi daya"}
 
Sekarang ekstrak dari pesan ini:
Input: "Tablet saya pesanan #11111 layarnya retak"
Output:
"""

Model mempelajari polanya dari contoh dan menerapkannya secara konsisten.

Pola Prompt Engineering untuk Agen

Pola 1: Chain of Thought (Penalaran)

Untuk keputusan kompleks, minta model untuk "berpikir langkah demi langkah":

prompt = """Kamu perlu memutuskan apakah harus membuat tiket dukungan.
 
Pikirkan ini langkah demi langkah:
1. Apa yang diminta pelanggan?
2. Apakah ini bisa dijawab dengan dokumentasi yang ada?
3. Apakah ini memerlukan intervensi manual?
4. Aksi apa yang harus kita ambil?
 
Pesan pelanggan: "Saya ingin pengembalian dana untuk pesanan #12345 tapi saya kehilangan struknya"
 
Penalaran:
"""

Model akan menampilkan penalarannya secara eksplisit, membuat keputusan lebih transparan dan andal.

Pola 2: Generasi yang Dibatasi (Keamanan)

Batasi output yang mungkin dari model:

prompt = """Klasifikasikan intent pelanggan. Respons dengan TEPAT SATU dari opsi berikut:
- REFUND_REQUEST
- PRODUCT_QUESTION
- TECHNICAL_ISSUE
- OFF_TOPIC
 
Pesan pelanggan: "Bagaimana cara reset password saya?"
 
Klasifikasi:
"""

Ini mencegah model menghasilkan output yang tidak terduga. Dengan membatasi opsi output secara eksplisit:

• Mencegah parsing error (selalu salah satu dari empat opsi yang didefinisikan)
• Memblokir tindakan yang tidak diinginkan (mencegah eksekusi tindakan yang tidak didefinisikan)
• Menyederhanakan debugging (ruang output yang terbatas membuat masalah lebih mudah dilacak)

Pola 3: Self-Critique (Kualitas)

Minta model memverifikasi dan memperbaiki output-nya sendiri:

prompt = """Buat respons untuk pelanggan, lalu kritik respons itu.
 
Pesan pelanggan: "Saya ingin pengembalian dana"
 
Langkah 1 - Buat respons:
[Respons kamu di sini]
 
Langkah 2 - Kritik:
- Apakah respons ini akurat?
- Apakah ini membantu?
- Apakah ini mengikuti kebijakan perusahaan?
- Apa yang bisa ditingkatkan?
 
Langkah 3 - Respons final (menggabungkan kritik):
[Respons yang sudah diperbaiki di sini]
"""

Pendekatan multi-step ini sering menghasilkan output yang lebih berkualitas karena:

• Menangkap error lebih awal: Model meninjau penalarannya sendiri sebelum memfinalkan
• Meningkatkan tone dan kejelasan: Refleksi diri membantu mengidentifikasi bahasa yang tidak jelas atau tidak pantas
• Memastikan kepatuhan kebijakan: Langkah kritik memverifikasi kepatuhan terhadap pedoman

Kesalahan Prompting yang Umum

Kesalahan 1: Mengasumsikan Model "Tahu" Sesuatu

LLM tidak punya akses ke informasi real-time atau konteks implisit. Selalu berikan semua data yang diperlukan secara eksplisit.

# Buruk: Mengasumsikan model tahu tanggal saat ini
prompt = "Apakah pesanan ini memenuhi syarat untuk pengembalian dana? Pesanan #12345"
 
# Bagus: Berikan semua informasi yang diperlukan
prompt = f"""Apakah pesanan ini memenuhi syarat untuk pengembalian dana?
Pesanan #12345
dibeli {purchase_date}
Hari ini: {current_date}
Kebijakan: pengembalian 30 hari
"""

Kesalahan 2: Instruksi Ambigu

Kata kerja samar seperti "tangani", "proses", atau "urus" memberi terlalu banyak ruang untuk interpretasi. Jelaskan aksi tepat yang dibutuhkan.

# Buruk: Apa maksud "tangani"?
prompt = "Tangani permintaan pengembalian dana ini"
 
# Bagus: Aksi eksplisit
prompt = "Tentukan apakah permintaan pengembalian dana ini memenuhi syarat. Jika ya, buat tiket. Jika tidak, jelaskan alasannya."

Kesalahan 3: Membebani dengan Konteks

Menyertakan informasi yang tidak relevan membuang token, meningkatkan latensi, dan bisa membingungkan model. Retrieve hanya yang dibutuhkan untuk tugas spesifik.

# Buruk: 10.000 token konteks, kebanyakan tidak relevan
prompt = f"""
{entire_knowledge_base}
 
Pertanyaan: Apa kebijakan pengembalian dana?
"""
 
# Bagus: Retrieve hanya bagian yang relevan
prompt = f"""
{refund_policy_section}
 
Pertanyaan: Apa kebijakan pengembalian dana?
"""

Kesalahan 4: Pemformatan yang Tidak Konsisten

Saat format output bervariasi, kode downstream rusak. Selalu tentukan format persis yang kamu harapkan, terutama untuk data terstruktur.

# Buruk: Kadang JSON, kadang teks biasa
prompt = "Respons dengan keputusanmu"
 
# Bagus: Selalu tentukan format
prompt = 'Respons dalam format JSON: {"decision": "...", "reason": "..."}'

Inti Utama

Prompting yang efektif untuk agen membutuhkan:

1. System message yang jelas → Definisikan role, kapabilitas, constraints
2. Instruksi spesifik → Beri tahu model tepat apa yang harus dilakukan
3. Konteks selektif → Berikan hanya informasi yang relevan
4. Output terstruktur → Tentukan format secara eksplisit
5. Contoh few-shot → Tunjukkan pola yang kamu inginkan
6. Prompt penalaran → Minta berpikir langkah demi langkah

Prompting adalah skill yang membaik dengan latihan. Sepanjang buku ini, kamu akan melihat pola-pola ini diterapkan dalam sistem agen nyata.

Ringkasan Bab

Sekarang kamu memahami konsep-konsep fondasional untuk membangun sistem AI agentik:

AI Agentik vs Chatbot:

• Agen bertindak secara otonom untuk mencapai tujuan
• Agen menggunakan alat dan membuat keputusan multi-step
• Agen menjaga state dan beradaptasi berdasarkan hasil

Kenapa Framework Itu Penting:

• LangChain menyediakan abstraksi model, chain, memori, alat, dan RAG
• LangGraph menambahkan manajemen state, routing, dan checkpointing
• Framework mengurangi boilerplate dan memungkinkan workflow kompleks

Mekanika LLM:

• LLM memprediksi token, bukan mengambil fakta
• Konteks itu eksplisit, bukan implisit
• Prompt adalah instruksi, bukan query
• Output terstruktur membutuhkan panduan
• Context window itu terbatas

Ekonomi Token:

• Token output berbiaya 4–8x lebih mahal daripada token input
• Pilihan model berdampak pada biaya 10-100x
• Konteks selektif menurunkan biaya secara drastis
• Monitoring dan budget mencegah pengeluaran yang tak terkendali

Pemilihan Model:

• Cocokkan model dengan kompleksitas tugas
• Pertimbangkan kebutuhan konteks dan batasan latensi
• Gunakan arsitektur multi-model untuk optimasi biaya
• Mulai dari yang murah, upgrade hanya jika diperlukan

Dasar-Dasar Prompting:

• System message mendefinisikan perilaku agen
• Instruksi spesifik menghasilkan hasil yang andal
• Konteks selektif meningkatkan kualitas dan menurunkan biaya
• Output terstruktur memungkinkan parsing dan validasi
• Contoh few-shot mengajarkan pola secara efektif