Bayangkan sebuah organisasi telah menggunakan sistem helpdesk selama bertahun-tahun.

Setiap hari pengguna mengirimkan berbagai laporan:

"Tidak bisa login."

"Password sudah benar tapi tetap gagal masuk."

"Setelah ganti password aplikasi malah tidak bisa dibuka."

"User saya terkunci."

"Login gagal setelah salah password beberapa kali."

Bagi petugas helpdesk yang berpengalaman, laporan-laporan tersebut mungkin terlihat berbeda tetapi memiliki pola masalah yang serupa.

Sekarang bayangkan jumlah tiketnya bukan 100 atau 1.000, tetapi 300.000 tiket.

Di dalam ratusan ribu tiket tersebut sebenarnya terdapat sesuatu yang sangat berharga: pengetahuan organisasi.

Masalahnya, pengetahuan tersebut tersembunyi di dalam data historis.

Bagaimana AI dapat membantu mengubah ratusan ribu tiket menjadi knowledge base yang dapat digunakan kembali?

Tiket Helpdesk Sebenarnya Adalah Knowledge

Sebuah tiket biasanya tidak hanya berisi keluhan.

Di dalamnya dapat terdapat:

Masalah
   ↓
Analisis
   ↓
Tindakan
   ↓
Solusi
   ↓
Hasil

Misalnya:

Masalah:
User tidak dapat login setelah beberapa kali salah password.

Analisis:
Account mengalami lock.

Solusi:
Unlock account dan meminta user melakukan login kembali.

Informasi seperti ini sangat berharga.

Jika kasus yang sama muncul kembali enam bulan kemudian, organisasi sebenarnya tidak perlu selalu memulai analisis dari nol.

Masalah serupa mungkin pernah terjadi:

Hari ini
   ↓
"Tidak bisa login setelah salah password"

Historis
   ↓
Tiket #18271
Tiket #38192
Tiket #82173
Tiket #193821

Persoalannya adalah menemukan tiket yang relevan dari ratusan ribu tiket tersebut.

Di sinilah AI mulai berguna.

Mengapa Pencarian Keyword Saja Tidak Cukup?

Pendekatan paling sederhana adalah pencarian berdasarkan kata.

Misalnya pengguna melaporkan:

tidak bisa login setelah salah password

Sistem kemudian mencari tiket yang mengandung:

login
password

Pendekatan ini dapat bekerja untuk kasus sederhana.

Namun bahasa manusia tidak selalu konsisten.

Masalah yang sama dapat ditulis:

Tidak bisa login

atau:

Gagal masuk aplikasi

atau:

Account terkunci

atau:

User tidak dapat mengakses sistem

atau bahkan:

Setelah beberapa kali salah memasukkan password,
aplikasi menolak akses.

Secara kata, kalimat-kalimat tersebut berbeda.

Tetapi secara makna, sebagian dapat mengarah pada masalah yang sama.

Inilah perbedaan penting antara:

Keyword Search

dan:

Semantic Search

Keyword search mencari kata yang sama.

Semantic search mencoba mencari makna yang mirip.

Dari Kalimat Menjadi Angka

Komputer pada akhirnya bekerja dengan angka.

Karena itu, agar mesin dapat membandingkan makna sebuah tiket, teks perlu direpresentasikan dalam bentuk numerik.

Proses ini disebut embedding.

Secara sederhana:

"Tidak bisa login setelah salah password"
                ↓
           Embedding Model
                ↓
[0.021, -0.142, 0.882, 0.173, ...]

Kalimat lain:

"Account terkunci setelah gagal login"
                ↓
           Embedding Model
                ↓
[0.018, -0.137, 0.861, 0.181, ...]

Vektor sebenarnya dapat memiliki ratusan atau bahkan ribuan dimensi tergantung model embedding yang digunakan.

Yang penting bukan angka individualnya, melainkan posisi relatif antar-vektor.

Teks dengan makna yang mirip cenderung memiliki representasi yang lebih dekat.

Konsep sederhananya:

"Tidak bisa login"
        ●
       / \
      /   \
     ●     ●
"Login     "Account
gagal"      terkunci"


                         ●
                    "Printer rusak"

Masalah login berada relatif berdekatan.

Masalah printer berada jauh karena konteksnya berbeda.

Similarity: Mengukur Kemiripan Masalah

Setelah tiket diubah menjadi vector embedding, sistem dapat menghitung tingkat kemiripan antar-tiket.

Salah satu metode yang umum digunakan adalah cosine similarity.

Secara konseptual:

Ticket A
"Tidak bisa login"

Ticket B
"Gagal masuk aplikasi"

Similarity → tinggi

Sedangkan:

Ticket A
"Tidak bisa login"

Ticket C
"Printer tidak mencetak"

Similarity → rendah

Misalnya hasil pencarian:

Query:
"User terkunci setelah salah password"

Hasil:

0.94 → Account lock setelah gagal login
0.91 → User tidak dapat login karena account locked
0.88 → Reset password dan unlock user
0.54 → Password expired
0.21 → Printer tidak dapat digunakan

Angka tersebut bukan berarti AI "mengerti" masalah persis seperti manusia.

Angka itu menunjukkan seberapa dekat representasi semantik query terhadap data yang tersimpan menurut model embedding yang digunakan.

Perbedaan ini penting.

AI tidak membaca tiket seperti seorang teknisi membaca tiket. AI melakukan representasi matematis terhadap teks dan mencari pola kedekatan di dalam representasi tersebut.

Masalahnya: Data Tiket Tidak Selalu Bersih

Jika memiliki 300.000 tiket, jangan langsung memasukkan semuanya ke vector database.

Data tiket dunia nyata biasanya cukup berantakan.

Contohnya:

Selamat pagi admin.

Mohon bantuannya user kami tidak bisa login.

Username:
ABC123

Email:
user@example.com

Sudah dicoba beberapa kali tetapi masih gagal.

Mohon segera dibantu karena urgent.

Terima kasih.

Informasi utama sebenarnya hanya:

user tidak bisa login setelah beberapa kali mencoba

Bagian seperti:

Selamat pagi
Mohon bantuannya
Mohon segera dibantu
Terima kasih

tidak banyak membantu dalam memahami inti masalah.

Karena itu dibutuhkan preprocessing.

Tahap 1 — Membersihkan Data

Pipeline sederhana dapat dimulai dari:

Raw Ticket
    ↓
Cleaning
    ↓
Normalization
    ↓
Meaning Extraction
    ↓
Embedding

Cleaning dapat mencakup:

• menghapus salam,
• menghapus signature,
• menghapus alamat email jika tidak relevan,
• menghapus nomor telepon,
• menghilangkan karakter yang tidak diperlukan,
• memperbaiki spasi,
• dan membuang bagian template yang berulang.

Namun cleaning juga tidak boleh terlalu agresif.

Misalnya tiket:

Error 400 ketika submit dokumen

Jika semua angka dihapus:

Error ketika submit dokumen

informasi penting justru hilang.

400 dapat menunjukkan HTTP status tertentu.

Begitu pula istilah seperti:

HTTP 500
ORA-00942
ERR_CONNECTION_TIMEOUT
AL01
APP-403

dapat menjadi informasi penting.

Karena itu preprocessing sebaiknya memahami karakteristik domain.

Tahap 2 — Normalisasi Bahasa

Pengguna tidak selalu menulis istilah dengan cara yang sama.

Contohnya:

ga bisa login
gak bisa login
nggak bisa login
tidak bisa login
login tidak berhasil

Semua dapat dinormalisasi menjadi:

tidak bisa login

Contoh lain:

pwd
passwd
password
kata sandi

Dalam konteks tertentu dapat dipetakan ke istilah yang sama.

Normalisasi membantu mengurangi variasi bahasa yang sebenarnya tidak membawa perbedaan makna.

Namun sekali lagi, aturan normalisasi harus memahami domain.

Tahap 3 — Mengambil Inti Masalah

Satu tiket terkadang memiliki deskripsi panjang.

Misalnya:

Selamat pagi.

Kami dari kantor cabang sedang melakukan proses transaksi.
Sejak pagi aplikasi dapat digunakan seperti biasa.

Namun ketika user melakukan proses submit, muncul pesan
error dan proses tidak dapat dilanjutkan.

Sudah dicoba logout kemudian login kembali tetapi masalah
masih terjadi.

Mohon bantuannya.

Untuk proses pencarian, kita dapat mencoba mendapatkan representasi inti seperti:

proses submit gagal dan menampilkan error

Proses ini dapat dilakukan menggunakan:

• rule-based preprocessing,
• NLP,
• model klasifikasi,
• LLM,
• atau kombinasi beberapa metode.

Tujuannya bukan sekadar memperpendek teks.

Tujuannya adalah mempertahankan informasi yang paling relevan terhadap masalah.

Tahap 4 — Membuat Embedding

Setelah teks cukup bersih, setiap tiket dibuat menjadi vector embedding.

Contohnya:

Ticket #10001
"account terkunci setelah gagal login"
        ↓
Embedding
        ↓
Vector A

Ticket #10002
"submit dokumen gagal dengan error 400"
        ↓
Embedding
        ↓
Vector B

Ticket #10003
"status pembayaran belum berubah"
        ↓
Embedding
        ↓
Vector C

Kemudian vector disimpan bersama metadata tiket.

Misalnya:

{
  "ticket_id": "10001",
  "category": "ACCESS",
  "application": "PORTAL",
  "problem": "account terkunci setelah gagal login",
  "solution": "unlock account",
  "status": "CLOSED"
}

Metadata tersebut nantinya sangat penting.

Karena pencarian yang baik tidak selalu hanya berdasarkan similarity.

Tahap 5 — Menyimpan ke Vector Database

Embedding dapat disimpan pada teknologi yang mendukung vector search.

Arsitekturnya secara sederhana:

300.000 Tickets
       ↓
Preprocessing
       ↓
Normalization
       ↓
Meaning Extraction
       ↓
Embedding Model
       ↓
Vector Database

Sekarang kita memiliki representasi semantik dari histori masalah.

Ketika tiket baru masuk:

New Ticket
    ↓
Preprocessing
    ↓
Embedding
    ↓
Similarity Search
    ↓
Top Similar Tickets

Sistem dapat mencari tiket lama yang paling mendekati masalah baru.

Tetapi Similarity Saja Belum Cukup

Misalnya query:

Tidak bisa submit dokumen

Semantic search mungkin menemukan:

0.93 → Tidak bisa submit dokumen pada Aplikasi A
0.92 → Submit gagal pada Aplikasi B
0.91 → Dokumen gagal dikirim pada Aplikasi C

Ketiganya terlihat mirip.

Tetapi pengguna sebenarnya sedang menggunakan Aplikasi A.

Karena itu metadata dapat digunakan sebagai filter.

Semantic Similarity
        +
Application = Aplikasi A
        +
Status = CLOSED
        +
Solution != NULL

Hasilnya menjadi lebih relevan.

Konsep ini sangat penting dalam membangun knowledge base.

Semantic similarity mencari kemiripan makna, sedangkan metadata membantu memberikan konteks.

Dari Similar Ticket Menjadi Knowledge Base

Pada tahap ini kita sebenarnya baru memiliki mesin pencarian tiket yang lebih pintar.

Knowledge base membutuhkan langkah berikutnya.

Misalnya ditemukan 500 tiket yang berkaitan dengan masalah login.

AI atau proses analitik dapat membantu menemukan pola:

LOGIN PROBLEM
│
├── Wrong Password
│
├── Account Locked
│
├── Password Expired
│
├── User Not Registered
│
├── Permission Problem
│
└── Authentication Service Error

Kemudian dari masing-masing kelompok dapat ditemukan:

Masalah
Penyebab
Solusi
Frekuensi
Aplikasi
Waktu kejadian

Contohnya:

Problem:
Account Locked

Typical Symptoms:
- gagal login
- salah password beberapa kali
- account locked

Common Solution:
- unlock account
- reset password jika diperlukan

Historical Cases:
8.421 tickets

Sekarang data tiket mulai berubah menjadi knowledge.

Classification Membantu Memberikan Struktur

Semantic search sangat berguna untuk menemukan kasus serupa.

Tetapi jika organisasi memiliki kategori solusi yang cukup jelas, kita juga dapat menggunakan classification.

Misalnya terdapat kategori:

ACCESS_ACCOUNT_LOCK
ACCESS_PASSWORD_RESET
PAYMENT_PENDING
DOCUMENT_SUBMISSION_ERROR
NETWORK_TIMEOUT

Historical ticket dapat digunakan sebagai training data:

Ticket Text
      +
Solution Label
      ↓
Machine Learning
      ↓
Classifier

Ketika tiket baru masuk:

"User tidak bisa login setelah beberapa kali salah password"
                    ↓
                Classifier
                    ↓
ACCESS_ACCOUNT_LOCK
Confidence: 0.92

Classification dan semantic search sebenarnya dapat saling melengkapi.

Contohnya:

                  New Ticket
                      ↓
              Meaning Extraction
                      ↓
              ┌───────┴────────┐
              ↓                ↓
        Classification   Semantic Search
              ↓                ↓
       Predicted Issue    Similar Tickets
              └───────┬────────┘
                      ↓
               Knowledge Retrieval

Classifier membantu menjawab:

"Ini kemungkinan masalah apa?"

Semantic search membantu menjawab:

"Kasus seperti ini pernah terjadi di mana?"

Confidence Score: AI Tidak Harus Selalu Menjawab

Misalnya classifier menghasilkan:

ACCESS_ACCOUNT_LOCK     0.91
PASSWORD_RESET          0.06
OTHER                   0.03

Sistem cukup yakin bahwa masalah berkaitan dengan account lock.

Tetapi bagaimana jika:

ACCESS_ACCOUNT_LOCK     0.38
PASSWORD_RESET          0.34
OTHER                   0.28

Dalam kondisi seperti ini, memaksa AI memberikan keputusan justru berbahaya.

Kita dapat menentukan threshold:

Confidence >= 0.85
        ↓
Automatic Recommendation

Sedangkan:

Confidence < 0.85
        ↓
Need More Information
        atau
Human Review

Konsep ini penting dalam implementasi AI di dunia nyata.

Sistem yang baik bukan sistem yang selalu memberikan jawaban.

Sistem yang baik juga harus mengetahui kapan hasilnya belum cukup meyakinkan untuk digunakan secara otomatis.

RAG: Membawa Knowledge ke LLM

Setelah memiliki mekanisme retrieval, kita dapat menghubungkannya dengan Large Language Model menggunakan pendekatan Retrieval-Augmented Generation (RAG).

Alurnya:

User Question
      ↓
Embedding
      ↓
Vector Search
      ↓
Relevant Historical Cases
      ↓
Context
      ↓
LLM
      ↓
Answer

Misalnya pengguna bertanya:

Kenapa user saya tidak bisa login setelah salah password?

Vector search menemukan beberapa historical ticket:

Case #12821
Account locked setelah 5 kali gagal login.
Solution: unlock account.

Case #28912
User tidak dapat login karena account locked.
Solution: unlock melalui admin portal.

Case #81291
Account locked setelah kesalahan password berulang.
Solution: unlock account dan login kembali.

Informasi tersebut kemudian diberikan sebagai context kepada LLM.

LLM tidak hanya mengandalkan pengetahuan umum model, tetapi memperoleh referensi dari historical knowledge organisasi.

Jangan Membiarkan LLM Mengarang Solusi

Salah satu prinsip penting dalam implementasi RAG adalah membatasi jawaban berdasarkan context yang tersedia.

Contohnya:

Jika solusi ditemukan dalam knowledge base:
→ gunakan solusi tersebut

Jika tidak ditemukan:
→ jangan membuat prosedur baru
→ minta informasi tambahan
→ atau eskalasi ke petugas

Arsitekturnya dapat dibuat:

Question
   ↓
Retrieval
   ↓
Relevant Knowledge Found?
   │
   ├── YES → LLM generates grounded answer
   │
   └── NO  → Ask / Escalate

Dengan pendekatan seperti ini, LLM berfungsi sebagai lapisan bahasa dan reasoning di atas knowledge, bukan sebagai sumber kebenaran tunggal.

Tiket Baru Juga Harus Menjadi Knowledge Baru

Knowledge base tidak boleh berhenti pada 300.000 tiket awal.

Setiap hari akan muncul tiket baru.

Historical Tickets
       +
New Tickets
       ↓
Knowledge Pipeline
       ↓
Updated Knowledge Base

Namun tidak semua tiket baru harus langsung masuk.

Idealnya hanya tiket yang telah:

Resolved
   ↓
Validated
   ↓
Solution Confirmed
   ↓
Knowledge Eligible

yang digunakan.

Hal ini menghindari tiket yang:

• belum selesai,
• salah diagnosis,
• memiliki solusi sementara,
• atau tidak memiliki penyelesaian yang jelas

masuk sebagai knowledge yang dianggap benar.

Dari Reactive Support Menjadi Proactive Knowledge

Pada sistem helpdesk tradisional:

Masalah terjadi
      ↓
User membuat tiket
      ↓
Helpdesk menganalisis
      ↓
Masalah diselesaikan
      ↓
Tiket ditutup

Setelah tiket ditutup, pengetahuan sering berhenti di database.

Dengan knowledge system:

Masalah terjadi
      ↓
Tiket dibuat
      ↓
Masalah diselesaikan
      ↓
Solusi divalidasi
      ↓
Masuk Knowledge Base
      ↓
Digunakan untuk kasus berikutnya

Lebih jauh lagi, data tersebut dapat dianalisis untuk menemukan pola.

Misalnya:

8.421 tiket → Account Lock
5.912 tiket → Password Reset
4.283 tiket → Payment Pending
3.872 tiket → Submission Error

Pertanyaan berikutnya bukan lagi:

"Bagaimana menyelesaikan tiket ini?"

Tetapi:

"Mengapa masalah ini terus menghasilkan ribuan tiket?"

Di sinilah AI mulai memberikan nilai yang lebih besar.

Knowledge Base Bukan Tujuan Akhir

Jika terdapat 8.000 tiket mengenai account lock, membuat AI yang dapat menjawab cara melakukan unlock memang membantu.

Tetapi solusi yang lebih baik mungkin adalah memperbaiki sistem authentication agar pengguna dapat melakukan self-service recovery.

Jika terdapat 10.000 tiket mengenai status pembayaran, mungkin yang perlu diperbaiki bukan chatbot-nya.

Mungkin integrasi payment system yang perlu diperbaiki.

AI dapat membantu menemukan pola:

300.000 Tickets
       ↓
AI Analysis
       ↓
Recurring Problems
       ↓
Root Cause Analysis
       ↓
System Improvement

Dengan demikian, knowledge base bukan hanya digunakan untuk menjawab masalah lebih cepat.

Knowledge base juga dapat menjadi sumber informasi untuk mengurangi jumlah masalah itu sendiri.

AI Tidak Mengubah Data Menjadi Pengetahuan Secara Ajaib

Mengubah 300.000 tiket menjadi knowledge base bukan proses:

Upload Data
    ↓
AI
    ↓
Selesai

Proses sebenarnya lebih dekat dengan:

              300.000 Tickets
                     ↓
              Data Cleaning
                     ↓
               Normalization
                     ↓
            Meaning Extraction
                     ↓
          ┌──────────┴──────────┐
          ↓                     ↓
   Classification          Embedding
          ↓                     ↓
    Issue Category        Vector Search
          └──────────┬──────────┘
                     ↓
             Knowledge Retrieval
                     ↓
                   RAG
                     ↓
                   LLM
                     ↓
             Suggested Answer
                     ↓
              Human / Rules
                     ↓
             Validated Solution
                     ↓
             Knowledge Update

Setiap lapisan memiliki fungsi yang berbeda.

Embedding membantu mencari kemiripan.

Classifier membantu mengenali kategori.

Vector search membantu menemukan historical cases.

RAG membawa knowledge yang relevan ke LLM.

LLM membantu memahami dan menyajikan informasi dalam bahasa yang lebih natural.

Dan manusia tetap diperlukan untuk memastikan bahwa knowledge yang digunakan memang benar.

Dari Data Historis Menjadi Aset Organisasi

Ratusan ribu tiket helpdesk sering dianggap sekadar histori operasional.

Padahal di dalamnya terdapat rekaman tentang:

• masalah yang paling sering terjadi,
• bagaimana masalah tersebut diselesaikan,
• aplikasi mana yang paling banyak bermasalah,
• pola kesalahan pengguna,
• pola gangguan sistem,
• efektivitas solusi,
• hingga peluang perbaikan proses.

Dengan pengelolaan yang tepat:

Ticket
   ↓
Data
   ↓
Information
   ↓
Knowledge
   ↓
Decision
   ↓
Improvement

AI dapat membantu mempercepat perjalanan tersebut.

Namun teknologi seperti embedding, vector database, machine learning, RAG, dan LLM hanyalah alat.

Nilai sebenarnya muncul ketika organisasi mampu mengubah histori penyelesaian masalah menjadi pengetahuan yang dapat ditemukan, digunakan kembali, divalidasi, dan terus diperbaiki.

Pada titik itu, 300.000 tiket bukan lagi sekadar 300.000 baris data.

Ia menjadi pengalaman organisasi yang dapat digunakan kembali.