LLM Orchestration Essentials

> Satu LLM call saja jarang cukup untuk menjalankan sebuah feature production. Orchestration adalah layer engineering yang mengoordinasikan banyak call, tool, model, dan control logic menjadi satu workflow yang reliable. Notebook ini membahas pattern orchestration yang umum dipakai dan kapan masing-masing cocok digunakan.

Apa itu LLM Orchestration?

LLM orchestration adalah praktik mengoordinasikan banyak LLM call — beserta tool, retry, routing, dan state di sekitarnya — menjadi satu workflow yang reliable. Posisinya di atas "panggil API, parse response" dan di bawah "bangun framework custom dari nol."

Begitu sebuah aplikasi butuh lebih dari satu LLM call untuk menyelesaikan satu task — memvalidasi output, memanggil tool, routing ke prompt khusus, retry saat gagal — kita sudah melakukan orchestration, entah pakai framework bernama atau tidak.

Yang biasanya harus ditangani orchestration:

Sequencing — menjalankan step dalam urutan yang benar, output satu step jadi input step berikutnya

Branching — routing ke prompt, tool, atau model berbeda berdasarkan hasil intermediate

Parallelism — menjalankan sub-task independen secara bersamaan lalu menggabungkan hasilnya

Retry dan fallback — menangani output yang malformed, rate limit, atau model yang sedang down

State — membawa context (riwayat percakapan, hasil intermediate) lintas step

Model selection — merutekan task sederhana ke model yang lebih murah/cepat, task kompleks ke model yang lebih kuat

Pattern Orchestration Umum

1. Prompt Chaining Memecah task kompleks menjadi step berurutan, masing-masing dengan prompt yang fokus.

Draft → Kritik → Revisi → Output Final

Cocok kalau task memang secara natural terdiri dari beberapa tahap, dan tiap tahap diuntungkan oleh prompt yang lebih sempit dan sederhana dibanding satu instruksi raksasa. 2. Routing Klasifikasikan input dulu, baru dispatch ke prompt, tool, atau model khusus.

Input → Classifier → { prompt billing | prompt teknis | prompt general }

Berguna kalau sistem menangani beberapa jenis request berbeda yang butuh penanganan berbeda pula. 3. Parallelization Jalankan sub-task independen secara concurrent, lalu agregasi hasilnya.

Dokumen → [Ekstrak entity, Summarize, Klasifikasi sentiment] → Merge

Mengurangi latency ketika sub-task tidak saling bergantung, dan memungkinkan pakai model berbeda per sub-task kalau perlu. 4. Orchestrator-Worker Satu LLM call sentral merencanakan task dan mendelegasikan bagian-bagiannya ke worker khusus (yang bisa berupa LLM call lain atau tool), lalu mensintesis hasilnya.

Task → Orchestrator (merencanakan) → [Worker A, Worker B, Worker C] → Synthesizer

Cocok untuk task open-ended di mana jumlah dan bentuk subtask belum diketahui sejak awal. 5. Evaluator-Optimizer Satu call men-generate, call lain mengevaluasi terhadap kriteria tertentu, dan loop berulang sampai output lolos atau mencapai batas retry.

Generate → Evaluate → (lolos? selesai : generate ulang dengan feedback)

Berguna kalau standar kualitas lebih penting daripada latency — misalnya generated code, terjemahan, atau teks legal.

Contoh Praktis: Routing + Fallback

Contoh singkat yang menunjukkan model routing berdasarkan kompleksitas task, dengan fallback saat gagal:

def classify_complexity(query: str) -> str:
    result = cheap_model.invoke(
        f"Classify this query as 'simple' or 'complex': {query}"
    )
    return result.content.strip().lower()

def handle_query(query: str) -> str:
    complexity = classify_complexity(query)
    model = cheap_model if complexity == "simple" else strong_model

    try:
        return model.invoke(query).content
    except RateLimitError:
        # fallback ke provider/model lain saat gagal
        return fallback_model.invoke(query).content

response = handle_query("Summarize this paragraph in one sentence.")

Di skala yang lebih besar, logic yang sama ini akan berpindah ke framework (LangGraph, state machine custom, sistem worker berbasis queue) — tapi pattern dasarnya, routing sesuai kebutuhan dan fallback saat gagal, tetap sama.

Isu Reliability Khusus Orchestration

Validasi structured output — validasi output JSON/schema sebelum diteruskan ke step berikutnya; retry dengan error validasi dimasukkan kembali ke prompt kalau gagal

Idempotency — step yang memanggil tool eksternal (kirim email, charge kartu) butuh guard supaya tidak dijalankan dua kali saat retry

Timeout dan circuit breaker — satu LLM call yang hang tidak boleh membuat seluruh pipeline ikut hang

Observability — trace setiap step (input, output, latency, cost), karena debug chain multi-step hanya dari log itu menyakitkan — inilah yang jadi tujuan tool seperti [[langsmith-essentials]]

Cost control — orchestration melipatgandakan token spend; lacak cost per workflow run, bukan hanya per call

Kapan Pakai Framework vs Bikin Sendiri

Logic sequential/branching sederhana, sedikit step — plain code sering kali lebih jelas dibanding framework

Cycle, retry, human-in-the-loop, atau state long-running — framework berbasis graph seperti LangGraph mulai worth it

Tool use berat dengan banyak model/provider — orchestration framework dengan retry bawaan dan abstraksi provider menghemat waktu yang nyata

Key Takeaways

Orchestration adalah layer koordinasi di atas single LLM call — sequencing, branching, parallelism, retry, dan state

Segelintir pattern (chaining, routing, parallelization, orchestrator-worker, evaluator-optimizer) mencakup sebagian besar workflow di dunia nyata

Isu reliability — validasi, idempotency, timeout, observability — lebih penting di sini dibanding setup single-call

Mulai dari pattern paling sederhana yang menyelesaikan masalah; tambahkan framework begitu kompleksitas (cycle, state, retry) benar-benar menuntutnya

Resources

Anthropic — "Building Effective Agents": https://www.anthropic.com/research/building-effective-agents

Dokumentasi LangGraph: https://langchain-ai.github.io/langgraph/