Lompat ke konten Lompat ke sidebar Lompat ke footer

Modul 3: Sumber dan Klasifikasi Data

 


Analitik Data untuk Pengembangan Chatbot Layanan Akademik

Pendahuluan

Perkembangan teknologi informasi mendorong institusi pendidikan untuk meningkatkan kualitas layanan akademik melalui pemanfaatan sistem berbasis kecerdasan buatan, salah satunya chatbot. Chatbot berbasis aturan (rule-based) dapat digunakan untuk melayani pertanyaan mahasiswa, mengelola informasi akademik, serta menganalisis pola keluhan. Untuk mendukung fungsi tersebut, diperlukan pengelolaan dan analisis data yang tepat berdasarkan struktur dan karakteristiknya.

A. Klasifikasi Struktur Data

Dalam studi kasus ini, terdapat tiga jenis data yang diklasifikasikan sebagai berikut:

1. Log Percakapan (Chat History)

Kategori: Data Tidak Terstruktur (Unstructured Data)
Analisis:
Log percakapan berupa teks bebas antara mahasiswa dan staf tidak memiliki format baku. Struktur kalimat, panjang pesan, dan konteks sangat bervariasi. Oleh karena itu, data ini memerlukan teknik pengolahan lanjutan seperti text mining atau natural language processing untuk dapat dianalisis.

2. Tabel Relasional (NIM, Nama, IPK)

Kategori: Data Terstruktur (Structured Data)
Analisis:
Data disusun dalam bentuk tabel dengan atribut yang jelas dan konsisten. Setiap entitas memiliki format yang seragam, sehingga mudah diakses, dikelola, dan dianalisis menggunakan sistem manajemen basis data (DBMS).

3. File JSON dari Server Kalender Akademik

Kategori: Data Semi-Terstruktur (Semi-Structured Data)
Analisis:
Format JSON menggunakan struktur key-value yang terorganisir, namun fleksibel. Data ini tidak sepenuhnya terikat pada skema tabel seperti data terstruktur, tetapi tetap memiliki pola yang dapat dikenali sehingga relatif mudah diproses.

B. Analisis dengan Problem-Based Approach

Ditemukan lonjakan kata kunci “error”, “lambat”, dan “gagal login” pada portal e-learning setiap Minggu malam. Analisis dilakukan dengan pendekatan Problem-Based sebagai berikut:

1. Visualized Problem

Terjadi peningkatan signifikan jumlah keluhan pada waktu tertentu, yaitu Minggu malam. Hal ini menunjukkan adanya indikasi masalah sistem yang bersifat temporal.

2. Pattern Problem

Pola kejadian bersifat berulang dan konsisten setiap minggu. Hal ini mengindikasikan bahwa masalah bukan bersifat insidental, melainkan sistemik.

3. Linked Problem

Masalah kemungkinan berkaitan dengan beberapa faktor, antara lain:

  • Deadline pengumpulan tugas mingguan

  • Lonjakan jumlah pengguna secara bersamaan

  • Beban server yang meningkat secara signifikan

4. Deep Problem

Akar permasalahan yang lebih mendalam dapat meliputi:

  • Kapasitas infrastruktur server yang tidak memadai

  • Tidak adanya mekanisme load balancing

  • Kurangnya optimasi performa sistem e-learning

C. Pemanfaatan Open Data

Pemanfaatan data terbuka (open data) dapat meningkatkan kualitas analisis dan pengambilan keputusan.

Contoh Implementasi:
Tim pengembang dapat memanfaatkan dataset publik terkait pola penggunaan internet dari instansi pemerintah atau lembaga riset.

Analisis dan Integrasi:

  • Menggabungkan data eksternal dengan data internal kampus

  • Mengidentifikasi waktu puncak penggunaan internet

  • Membandingkan pola akses mahasiswa dengan tren nasional

Manfaat:

  • Memprediksi lonjakan trafik sistem

  • Menentukan waktu optimal untuk maintenance

  • Meningkatkan performa chatbot dan sistem e-learning


1. Latihan

a) Perbedaan Legacy Systems vs Cloud Applications dan data ingestion

Legacy systems
Sistem lama. Biasanya on-premise. Arsitektur monolitik. Data tersimpan di database internal. Integrasi sulit. Skalabilitas terbatas.
Metode ingestion: batch ETL dominan. Data diambil periodik dari database atau file. Sering gunakan dump, scheduled job, atau middleware khusus. Real-time jarang karena keterbatasan API.

Cloud applications
Berbasis internet. Arsitektur modular atau microservices. Skalabel dan elastis. Integrasi mudah lewat API.
Metode ingestion: API-based ingestion dan streaming. Data masuk real-time melalui REST API, webhook, atau message broker. Bisa juga batch, tetapi umumnya near real-time dengan pipeline otomatis.

b) Mengapa tidak boleh berhenti di Visualized dan Pattern Problem

Visualized problem hanya menunjukkan gejala. Misal grafik lonjakan error.
Pattern problem menunjukkan pola berulang. Misal error selalu muncul tiap Minggu malam.

Keduanya belum menjawab sebab utama. Tanpa akar masalah, solusi hanya reaktif dan sementara. Sistem akan terus bermasalah.

Urgensi menemukan deep problem
Deep problem mengidentifikasi root cause. Misal overload server karena jadwal submit tugas bersamaan. Atau konfigurasi sistem tidak optimal.
Dengan mengetahui akar, solusi menjadi presisi. Bisa berupa redesign sistem, load balancing, atau perubahan kebijakan akademik. Dampaknya lebih permanen dan efisien.

2. Studi Kasus

a) Klasifikasi struktur data

Log percakapan WhatsApp
Kategori: tidak terstruktur.
Alasan: berbentuk teks bebas. Tidak ada skema tetap. Sulit diproses tanpa NLP.

Tabel relasional (NIM, nama, IPK)
Kategori: terstruktur.
Alasan: memiliki skema jelas. Kolom dan tipe data tetap. Mudah di-query.

File JSON dari server kalender
Kategori: semi-terstruktur.
Alasan: memiliki format key-value. Struktur fleksibel, tetapi masih terorganisir.

b) Problem-Based Approach pada kasus lonjakan error

Visualized problem
Terlihat lonjakan kata “error”, “lambat”, “gagal login” setiap Minggu malam.

Pattern problem
Pola berulang mingguan. Waktu spesifik. Kemungkinan terkait aktivitas rutin mahasiswa.

Linked problem
Terhubung dengan sistem e-learning. Kemungkinan saat deadline tugas. Beban server meningkat. Juga terkait autentikasi dan database.

Deep problem
Akar masalah kemungkinan pada kapasitas server yang tidak memadai saat peak load. Bisa juga karena query tidak efisien atau tidak ada load balancing. Atau kebijakan deadline serentak memicu trafik ekstrem.

c) Pemanfaatan Open Data

Contoh: gunakan data publik dari pemerintah tentang penetrasi internet dan pola penggunaan waktu online mahasiswa.
Integrasi ke sistem analitik chatbot.
Manfaat: memprediksi waktu puncak penggunaan. Tim bisa mengatur kapasitas server sebelum lonjakan. Juga bisa memberi rekomendasi jadwal deadline yang lebih tersebar.
Hasilnya lebih proaktif, bukan reaktif.

 

Posting Komentar untuk "Modul 3: Sumber dan Klasifikasi Data"