Cara Membangun AI Percakapan Tanpa Selalu Bergantung pada LLM

Ketika membangun chatbot berbasis data perusahaan, salah satu tantangan terbesar bukanlah menjawab pertanyaan pertama, melainkan memahami pertanyaan berikutnya.

Contoh sederhana:

User: Berapa tiket Peri bulan ini?

AI menjawab:

120 tiket.

Lalu user bertanya lagi:

Untuk Nida?

Atau:

Yang closed?

Atau bahkan:

Bulan lalu?

Manusia langsung memahami bahwa pertanyaan kedua masih membahas jumlah tiket, hanya saja mengganti PIC atau menambahkan filter.

Sebaliknya, komputer melihatnya hanya sebagai kalimat:

"Untuk Nida?"

Tanpa konteks, kalimat tersebut hampir tidak memiliki arti.

Banyak sistem langsung mengirim seluruh riwayat percakapan ke LLM agar model menebak maksudnya. Cara ini memang bekerja, tetapi memiliki beberapa kelemahan:

biaya inference meningkat
latency bertambah
hasil tidak selalu konsisten
sulit diprediksi
sulit diuji (non-deterministic)

Padahal, untuk banyak aplikasi enterprise, kita justru menginginkan hasil yang selalu sama.

Di sinilah konsep Stateful Structured Context dan Deterministic Merge menjadi sangat berguna.

Apa itu Stateful Structured Context?

Alih-alih menyimpan percakapan dalam bentuk teks biasa, setiap pertanyaan diterjemahkan menjadi representasi terstruktur (structured context).

Misalnya pertanyaan:

Berapa tiket Peri bulan Juni?

diubah menjadi:

{
  "intent": "ticket_count",
  "metric": "count",
  "entity": "ticket",
  "filters": {
    "pic": "peri"
  },
  "date_range": {
    "start": "2026-06-01",
    "end": "2026-06-30"
  }
}

Yang disimpan bukan lagi kalimatnya.

Yang disimpan adalah makna dari pertanyaan tersebut.

Context ini disebut conversation state.

Mengapa Structured Context Lebih Baik?

Bayangkan percakapan berikut.

User:

Berapa tiket Peri bulan ini?

State menjadi:

{
  "metric": "count",
  "filters": {
    "pic": "peri"
  },
  "date":"bulan_ini"
}

Kemudian user bertanya:

Untuk Nida?

Kalimat tersebut sendiri sebenarnya tidak lengkap.

Namun parser hanya menemukan:

{
  "filters":{
      "pic":"nida"
  }
}

Karena kita masih memiliki state sebelumnya, maka cukup dilakukan proses merge.

Hasil akhirnya menjadi:

{
  "metric":"count",
  "filters":{
      "pic":"nida"
  },
  "date":"bulan_ini"
}

Pertanyaan lengkap yang akan dieksekusi berubah menjadi:

Berapa tiket Nida bulan ini?

Tanpa perlu meminta bantuan LLM.

Deterministic Merge

Inilah inti dari pendekatan ini.

Alih-alih meminta AI "menebak", sistem melakukan merge berdasarkan aturan yang pasti.

Misalnya:

State lama

{
  "metric":"count",
  "filters":{
      "pic":"peri",
      "status":"open"
  },
  "date":"bulan_ini"
}

User baru:

Yang closed.

Parser menghasilkan:

{
    "filters":{
        "status":"closed"
    }
}

Merge menghasilkan:

{
  "metric":"count",
  "filters":{
      "pic":"peri",
      "status":"closed"
  },
  "date":"bulan_ini"
}

Tidak ada probabilitas.

Tidak ada halusinasi.

Tidak ada interpretasi acak.

Semuanya mengikuti aturan yang jelas.

Bukan Replace, Tetapi Patch

Konsep ini mirip seperti HTTP PATCH.

State lama:

{
  "pic":"peri",
  "month":"juni"
}

Patch:

{
  "pic":"nida"
}

Hasil:

{
  "pic":"nida",
  "month":"juni"
}

Hanya field yang berubah yang diganti.

Sisanya tetap dipertahankan.

Dangling Query

Masalah berikutnya adalah pertanyaan yang tidak lengkap.

Misalnya:

Yang closed?
Yang open?
Yang terbesar?
Bulan lalu?
Hari ini?
Untuk Nida?
Per aplikasi?
Detailnya?
Yang batal?

Semua kalimat di atas tidak memiliki subjek.

Tanpa context, sistem tidak akan tahu maksudnya.

Namun dengan state yang tersimpan, parser hanya perlu mengenali perubahan apa yang diminta.

Query Rewriting

Setelah merge selesai, sistem dapat membangun ulang pertanyaan lengkap.

Contoh:

State:

{
    "metric":"count",
    "entity":"ticket",
    "filters":{
        "pic":"peri"
    }
}

User:

Yang bulan Mei?

Rewrite menjadi:

Berapa jumlah tiket Peri bulan Mei?

Barulah query lengkap tersebut diteruskan ke database, API, atau RAG.

Mengapa Tidak Menggunakan LLM Saja?

LLM memang mampu melakukan query rewriting.

Namun pendekatan deterministic memiliki beberapa keunggulan.

1. Konsisten

Input yang sama selalu menghasilkan output yang sama.

Tidak ada variasi jawaban.

2. Cepat

Merge JSON hanya membutuhkan waktu beberapa mikrodetik.

Jauh lebih cepat dibanding inferensi model.

3. Murah

Tidak memerlukan token.

Tidak ada biaya tambahan.

4. Mudah Diuji

Developer dapat membuat unit test sederhana.

Contoh:

Input:

state = {
    "pic":"peri"
}

patch = {
    "pic":"nida"
}

Output selalu:

{
    "pic":"nida"
}

Tidak ada unsur probabilitas.

Kapan LLM Digunakan?

LLM tetap sangat berguna.

Namun posisinya berubah menjadi fallback, bukan solusi utama.

Contohnya ketika user bertanya:

Kalau tingginya berapa?

Kalimat ini ambigu.

Apakah yang dimaksud:

tinggi gedung?
tinggi badan?
tinggi gunung?
tinggi tiket?
tinggi container?

Karena parser tidak menemukan entity yang jelas, sistem dapat meminta bantuan LLM untuk menentukan apakah:

masih berkaitan dengan konteks sebelumnya,
membutuhkan klarifikasi,
atau merupakan topik baru.

Dengan demikian, LLM hanya digunakan pada kasus yang benar-benar memerlukan pemahaman bahasa alami.

Arsitektur yang Disarankan

User
   │
   ▼
Intent Detection
   │
   ▼
Entity Parser
   │
   ▼
Structured Patch
   │
   ▼
Deterministic Merge
   │
   ▼
Conversation State
   │
   ▼
Query Rewriter
   │
   ▼
Database / API / RAG

Jika parser gagal memahami maksud pengguna, barulah alur dialihkan ke LLM sebagai mekanisme fallback.

Keuntungan untuk AI Enterprise

Pendekatan ini sangat cocok diterapkan pada AI internal perusahaan karena:

tidak bergantung penuh pada LLM
latency sangat rendah
hasil konsisten
mudah diaudit
mudah dibuat unit test
mudah dikembangkan
biaya operasional lebih kecil
lebih aman karena context tersimpan secara lokal

Bahkan pada banyak kasus, lebih dari 80% percakapan lanjutan dapat diselesaikan hanya dengan parser dan deterministic merge tanpa memanggil model bahasa sama sekali.

Penutup

Banyak orang menganggap AI percakapan harus selalu melibatkan model bahasa besar di setiap interaksi. Padahal, untuk kebutuhan enterprise, pendekatan yang lebih efektif sering kali adalah menggabungkan Stateful Structured Context dengan Deterministic Merge.

Dengan menyimpan makna percakapan dalam bentuk struktur data dan memperbaruinya melalui aturan yang deterministik, sistem menjadi lebih cepat, lebih hemat biaya, dan jauh lebih mudah diprediksi. LLM tetap memiliki peran penting, tetapi digunakan sebagai pelengkap ketika benar-benar diperlukan, bukan sebagai solusi untuk setiap pertanyaan.

Pendekatan ini menjadikan AI bukan sekadar mampu "berbicara", tetapi juga mampu memahami konteks secara konsisten, layaknya sebuah sistem yang dirancang untuk kebutuhan operasional perusahaan yang menuntut keandalan tinggi.

Stateful Structured Context + Deterministic Merge