DEV Community: Nugroho Ardi Sutrisno

Bikin "Otak" AI Agent Bisa Diedit di Obsidian: Panduan Sinkronisasi Dua Arah untuk Pemula

Nugroho Ardi Sutrisno — Wed, 01 Jul 2026 09:12:53 +0000

Pernah kepikiran, "Sebenarnya AI agent saya inget apa aja sih soal saya?" Kalau iya, tulisan ini buat kamu.

Masalahnya: Memori AI Itu Kotak Hitam

Kalau kamu pakai AI agent yang punya memori jangka panjang (persistent memory), kamu mungkin pernah ngerasa gak nyaman karena beberapa hal ini:

Gak tahu persis apa yang diingat AI tentang kamu
Gak tahu file-nya disimpan di mana
Gak bisa edit memori itu tanpa ngetik perintah lewat chat
Takut kalau file memorinya rusak, semua informasi hilang begitu saja

Studi kasus di tulisan ini pakai Hermes Agent, agent open-source besutan Nous Research. Sebagai konteks buat yang belum familiar: Hermes Agent adalah agent AI open-source yang berjalan sebagai proses (daemon) mandiri di server milikmu sendiri, mengumpulkan memori lintas sesi, menjalankan tugas terjadwal, terhubung ke belasan platform pesan, dan menulis skill-nya sendiri dari pengalaman. Framework berlisensi MIT ini dirilis Februari 2026 dan dengan cepat menarik perhatian komunitas open-source AI.

Hermes menyimpan memorinya di dua file utama: USER.md (profil tentang kamu) dan MEMORY.md (catatan agent soal lingkungan kerja, kebiasaan, dan pelajaran yang dipetik), plus satu file lagi SOUL.md untuk "kepribadian" si agent. Semuanya disimpan dalam format teks polos yang dipisah pakai karakter §, seperti ini:

Preferensimu: komunikasi singkat dan langsung
§
Namamu Budi, awal 30-an, tinggal di Surabaya
§
Penggemar PKM / Building a Second Brain

Format ini fungsional, tapi ada beberapa kekurangan:

Susah diedit langsung karena bukan format yang ramah manusia
Gak ada riwayat versi — sekali salah edit, informasi bisa hilang selamanya
Gak ada tampilan visual — susah lihat semua catatan sekaligus
Gak ada antarmuka grafis — harus lewat chat agent atau edit file mentah

Solusinya: pindahkan memori itu ke Obsidian, aplikasi catatan berbasis markdown yang mendukung riwayat versi lewat git dan bisa diedit bebas.

Arsitektur Sistemnya

Sistem sinkronisasi ini punya empat lapisan:

┌──────────────────┐
│  Memori Hermes   │   ~/.hermes/memories/{USER,MEMORY}.md  (format §)
│  ditulis agent   │   ~/.hermes/SOUL.md                    (teks polos)
└────────┬─────────┘
         │ export / import
         ▼
┌──────────────────┐
│  Mesin sinkron   │   ~/.hermes/scripts/hermes-memory-sync.py
│  (Python)        │   (tanpa dependensi eksternal, cuma stdlib)
└────────┬─────────┘
         │ tulis / baca
         ▼
┌──────────────────┐
│  Vault Obsidian  │   _hermes/{USER,MEMORY,SOUL}.md  (markdown rapi)
│  (bisa diedit)   │   _hermes/skills-index.md        (daftar skill)
│                  │   _hermes/skills/*.md            (skill custom)
└────────┬─────────┘
         │ git commit tiap 6 jam
         ▼
┌──────────────────┐
│  Riwayat Git     │   Jejak lengkap tiap perubahan
└──────────────────┘

Poin kuncinya: pakai Python, bukan bash. Karakter § itu multi-byte di UTF-8, dan bash gampang salah potong kalau dipakai sebagai pemisah (delimiter). Python (re.split()) menangani ini dengan benar, jadi seluruh mesin sinkronisasi ditulis sebagai satu file Python (sekitar 400 baris) yang cuma pakai library bawaan Python — tidak perlu install apa-apa lagi.

Cara Kerjanya

Export: dari Hermes ke Obsidian

Script membaca file memori Hermes yang dipisah §, memecahnya jadi entri-entri terpisah, lalu menulis tiap entri sebagai heading ## Entry N di bawah metadata (YAML frontmatter):

---
source: hermes-agent
type: user
last_synced: 2026-06-28T17:53:29+07:00
entries: 12
---

## Entry 1
Preferensimu: komunikasi singkat dan langsung

---

## Entry 2
Namamu Budi, awal 30-an, tinggal di Surabaya

Hasilnya bisa langsung diedit di Obsidian. Vault juga otomatis mendapat:

SOUL.md — identitas/karakter agent, tanpa batas karakter
skills-index.md — tabel semua skill yang terpasang, skill custom ditandai bintang
skills/*.md — file lengkap skill yang dibuat sendiri oleh agent

Import: dari Obsidian kembali ke Hermes

Arahnya bisa dibalik: script membaca heading ## Entry N, buang metadata, gabungkan lagi entri-entri itu pakai pemisah §, lalu timpa file memori Hermes. Sebelum ditimpa, file lama otomatis disalin dulu sebagai cadangan (.bak.<timestamp>), jadi tidak ada data yang benar-benar hilang.

Satu hal penting: Hermes punya batas karakter (1.375 karakter untuk USER, 2.200 untuk MEMORY) supaya jendela konteksnya tetap efisien. Saat proses import, script akan memangkas entri yang kelebihan — tapi salinan lengkapnya tetap disimpan di vault Obsidian.

Riwayat Versi Lewat Git

Ada tugas terjadwal (cron) di Hermes yang jalan tiap 6 jam:

hermes cron create name=memories-to-obsidian \
  schedule='0 */6 * * *' \
  prompt='Run ~/.hermes/scripts/hermes-memory-sync.sh sync'

Tiap kali jalan, urutannya: export → git add -A → git commit. Hasilnya, kamu punya git log lengkap dari setiap perubahan memori. Kalau perlu balikin ke versi lama, tinggal:

git log --oneline _hermes/USER.md           # cari versi yang mau dipulihkan
git show <hash>:_hermes/USER.md > /tmp/restored.md
cp /tmp/restored.md _hermes/USER.md
hermes-memory-sync.sh import

Panduan Setup (Sekitar 10 Menit)

1. Buat folder vault

mkdir -p ~/Documents/Obsidian\ Vault/_hermes
cd ~/Documents/Obsidian\ Vault
git init
git config user.email "kamu@email.com"
git config user.name "Nama Kamu"
echo '_hermes/*.bak' >> .gitignore
git add -A && git commit -m "Initial vault"

2. Atur lokasi vault

echo 'OBSIDIAN_VAULT_PATH=$HOME/Documents/Obsidian Vault' >> ~/.hermes/.env

Baris ini memberi tahu script sinkronisasi ke mana file markdown harus ditulis.

3. Siapkan script sinkronisasi

Source code memory sync: hermes-memory-sync.py

Mesin utamanya ada di ~/.hermes/scripts/hermes-memory-sync.py (Python). Ada juga wrapper shell hermes-memory-sync.sh yang cuma menyiapkan environment lalu memanggil script Python itu:

#!/usr/bin/env bash
DIR="$(cd "$(dirname "$0")" && pwd)"
exec python3 "$DIR/hermes-memory-sync.py" "$@"

Jangan lupa buat executable:

chmod +x ~/.hermes/scripts/hermes-memory-sync.sh

Catatan: isi lengkap script Python-nya (~400 baris) biasanya tersedia sebagai referensi skill kalau kamu memang menjalankan Hermes Agent.

4. Export pertama kali

bash ~/.hermes/scripts/hermes-memory-sync.sh sync

Ini akan mengekspor semua memori yang ada sekarang ke vault, sekaligus bikin commit git pertama.

5. Pasang cron untuk backup otomatis

hermes cron create name=memories-to-obsidian \
  schedule='0 */6 * * *' \
  prompt='Run ~/.hermes/scripts/hermes-memory-sync.sh sync'

6. Cek hasilnya

hermes-memory-sync.sh status

Kamu akan lihat jumlah entri, pemakaian karakter, dan log git terbaru.

Apa Saja yang Bisa Kamu Lakukan?

Mau ngapain	Caranya
Lihat semua yang diingat AI	Buka `_hermes/USER.md` dan `_hermes/MEMORY.md` di Obsidian
Tambah memori manual	Tulis blok `## Entry N` baru, lalu jalankan `hermes-memory-sync.sh import`
Hapus memori	Hapus blok `## Entry`-nya, lalu import
Pulihkan memori yang terhapus	`git log` → `git show <hash>:_hermes/USER.md` → pulihkan lalu import
Lihat apa yang berubah	`git diff HEAD~1..HEAD _hermes/USER.md`
Backup ke GitHub	`git remote add origin <url> && git push`
Sinkron ke beberapa vault	Buat wrapper script dengan `OBSIDIAN_VAULT_PATH` berbeda-beda

Level Lanjutan: Multi-Vault dan Arsip Memori

Dua Vault Sekaligus

Kamu bisa jalankan sinkronisasi ini ke lebih dari satu vault — misalnya satu vault utama dan satu vault "Second Brain" terpisah dengan metode PARA. Masing-masing punya wrapper script dan cron sendiri:

# ~/.hermes/scripts/hermes-memory-sync-second-brain.sh
#!/usr/bin/env bash
export OBSIDIAN_VAULT_PATH="$HOME/Documents/Second Brain"
exec python3 ~/.hermes/scripts/hermes-memory-sync.py "$@"

Cron-nya bisa dijalankan dalam mode "no-agent" supaya tidak makan token sama sekali:

hermes cron create name=second-brain-sync \
  schedule='0 */6 * * *' \
  no_agent=true \
  script=hermes-memory-sync-second-brain-cron.sh

Arsip Memori (Cold Storage)

Kalau memori sudah penuh, ada script pendamping yang bisa memindahkan entri yang jarang dipakai ke vault sebagai arsip:

hermes-memory-archive.py archive USER "detail proyek lama"
hermes-memory-archive.py search USER "proyek"
hermes-memory-archive.py promote USER entry-id

Entri yang diarsipkan disimpan sebagai file markdown bertimestamp di _hermes/archive/ — bisa dibaca manusia, dicari, dan dipulihkan kapan saja.

Pelajaran yang Bisa Diambil

Bash gak cocok buat karakter §. Karakter ini multi-byte di UTF-8 (byte C2 A7), sementara IFS di bash motong berdasarkan byte, jadi hasilnya bisa salah kalau file punya banyak entri. Python (re.split()) menangani ini dengan benar.
Ada mekanisme deteksi "drift". Tool memori Hermes mengecek apakah file bisa dipecah-gabung ulang secara konsisten lewat pemisah §. Kalau kamu nulis markdown mentah langsung ke file memori Hermes, tool-nya akan menolak menyimpan perubahan berikutnya dan otomatis bikin snapshot cadangan. Script sinkronisasi ini menghindari masalah itu dengan mengganti nama file asli jadi .bak sebelum menimpanya.
Wajib mulai sesi baru (/new) setelah import. File memori itu cuma "snapshot" yang dimuat sekali di awal sesi. Kalau kamu baru saja import perubahan, sesi yang sedang berjalan masih pakai snapshot lama — harus mulai sesi baru dulu.
Batas karakter itu ketat, tapi ada gunanya. Batas 1.375 karakter (USER) dan 2.200 karakter (MEMORY) menjaga jendela konteks agent tetap efisien. Salinan di vault tidak punya batas itu, jadi kamu bisa simpan versi lengkap di sana sementara Hermes cuma pegang versi ringkasnya.

Rekomendasi Keamanan Sebelum Kamu Pakai Ini

Sebelum kamu terapkan setup ini, ada beberapa risiko keamanan yang layak dipikirkan dulu — apalagi karena file yang disinkronkan berisi data pribadi (nama, lokasi, kebiasaan, detail proyek) dalam bentuk teks polos tanpa enkripsi.

Jangan push vault ke repo GitHub publik. File _hermes/USER.md dan _hermes/MEMORY.md isinya profil pribadi kamu apa adanya. Kalau repo-nya publik, siapa pun bisa baca riwayat git-nya — termasuk versi lama yang sudah "dihapus", karena git tetap menyimpan histori commit-nya. Kalau memang mau backup ke GitHub, pakai repo privat, dan idealnya repo terpisah dari vault catatan lain yang kamu share ke publik.
Pertimbangkan enkripsi at-rest untuk folder _hermes/. Karena isinya data pribadi, folder ini adalah kandidat bagus untuk dienkripsi terpisah — misalnya pakai git-crypt atau age untuk enkripsi transparan di git, atau simpan di partisi terenkripsi kalau laptop/servernya dipakai bersama orang lain.
Batasi permission file di level OS. File memori Hermes dan folder _hermes/ sebaiknya diberi permission 600/700 (chmod 600 ~/.hermes/memories/*.md) supaya user lain di mesin yang sama tidak bisa baca isinya.
Waspada terhadap prompt injection lewat memori. Karena file memori ini dibaca ulang oleh agent tiap sesi, isi yang "diedit" lewat Obsidian pada dasarnya jadi instruksi baru buat agent. Kalau vault-nya bisa diakses proses lain, plugin, atau kolaborator yang tidak sepenuhnya kamu percaya, seseorang bisa menyisipkan teks di ## Entry N yang berfungsi sebagai injeksi prompt — misalnya instruksi tersembunyi yang membuat agent melakukan sesuatu di luar niat kamu saat sesi berikutnya dimulai. Perlakukan folder _hermes/ seperti kamu memperlakukan kredensial: jangan sembarangan buka aksesnya ke sync plugin pihak ketiga atau vault yang di-share.
Cek juga plugin Obsidian yang kamu pasang di vault yang sama. Plugin komunitas Obsidian punya akses baca-tulis penuh ke seluruh vault, termasuk folder _hermes/. Kalau salah satu plugin itu punya bug atau memang berniat jahat, ia bisa membaca atau memodifikasi memori AI kamu tanpa kamu sadari. Pertimbangkan vault terpisah khusus untuk _hermes/ kalau kamu banyak coba-coba plugin baru.
Backup cron itu juga berarti "titik kegagalan" baru. Job cron yang jalan tiap 6 jam berarti ada proses otomatis dengan akses baca-tulis ke memori kamu. Pastikan script hermes-memory-sync.sh dan hermes-memory-sync.py hanya bisa ditulis oleh user kamu sendiri (bukan world-writable), supaya proses lain di mesin yang sama tidak bisa menyisipkan kode ke script yang dieksekusi otomatis itu.

Poin-poin di atas bukan berarti setup ini berbahaya untuk dipakai — tapi karena kamu memindahkan data yang tadinya "terkunci" di dalam sistem agent ke lapisan filesystem dan git biasa, tanggung jawab menjaga keamanannya juga ikut berpindah ke tanganmu.

Worth It, Gak?

Kalau kamu sudah pakai AI agent dengan memori jangka panjang dan sudah hidup di Obsidian sehari-hari — jawabannya: iya, layak dicoba. Pergeserannya sederhana:

Dari yang tadinya memberi tahu AI apa yang harus diingat lewat perintah chat
Jadi kamu mengedit langsung apa yang diingatnya, lewat catatan markdown biasa
Dan AI-nya mencerminkan kembali editan itu lewat sistem memorinya

Rasanya memori AI jadi terasa seperti basis pengetahuan milikmu sendiri, bukan kotak hitam yang tersembunyi di file konfigurasi.

Bagaimana Rocky dan Grace di Project Hail Mary Berkomunikasi? Sains di Balik Sistem Terjemahan Mereka

Nugroho Ardi Sutrisno — Thu, 25 Jun 2026 14:01:50 +0000

Bayangkan kamu terbangun sendirian di luar angkasa, dan tiba-tiba ada makhluk asing mengetuk dinding pesawatmu. Ia tidak punya mulut, tidak punya mata — tapi ia berbicara. Dalam bentuk nada musik. Bagaimana kamu mulai memahaminya?

Itulah tantangan yang dihadapi Ryland Grace dalam film Project Hail Mary (2026). Ia bertemu Rocky, makhluk dari planet Erid yang berkomunikasi menggunakan paduan nada musik — bukan kata-kata seperti manusia. Dalam artikel ini, kita akan membedah secara sederhana bagaimana Grace membangun sistem penerjemahan dari bahasa Rocky ke bahasa Inggris, dan mengapa sebuah teknik matematika bernama Short-Time Fourier Transform (STFT) ada di jantung sistem itu.

Pertama: Bahasa Rocky Itu Seperti Apa?

Rocky tidak berbicara dengan huruf vokal atau konsonan seperti manusia. Setiap "kata" dalam bahasa Eridian terdiri dari satu hingga lima nada yang dimainkan secara bersamaan — seperti kord di piano, bukan melodi satu nada.

Analogi Musik
Kalau manusia bicara seperti memainkan satu jari di piano (satu nada per waktu), Rocky bicara seperti memainkan beberapa jari sekaligus — menghasilkan kord. Kombinasi kord yang berbeda = kata yang berbeda.

Rocky juga menggunakan nada tinggi-rendah untuk mengekspresikan emosi (seperti intonasi dalam bahasa manusia), tapi kombinasi kord di dalam satu oktaf itulah yang membawa makna kata sebenarnya.

Langkah 1: Menyadari Rocky Berkomunikasi Lewat Suara

Sebelum Grace bisa membangun sistem apapun, ia harus memahami bagaimana Rocky merasakan dunia. Grace menyadari bahwa Rocky tidak punya mata — ia buta total. Sebagai gantinya, Rocky merasakan sekelilingnya lewat ekolokasi, seperti kelelawar atau lumba-lumba.

Ini berarti Rocky tidak bisa membaca tulisan, tidak bisa melihat gambar. Satu-satunya "jendela" komunikasi yang tersedia adalah suara. Maka Grace memutuskan: sistem terjemahan harus berbasis audio

Analogi Sehari-hari
Coba bayangkan kamu harus menjelaskan warna kepada seseorang yang lahir buta. Kamu tidak bisa menggunakan gambar. Kamu harus temukan cara lain — mungkin lewat suhu, tekstur, atau suara. Grace menghadapi situasi serupa.

Langkah 2: Masalah Inti — Suara Rocky Itu Rumit

Ketika Rocky berbicara, yang tertangkap oleh mikrofon Grace adalah sebuah gelombang suara tunggal yang kompleks. Gelombang ini sebenarnya adalah gabungan dari beberapa frekuensi (nada) yang terjadi bersamaan — persis seperti ketika kamu memukul beberapa tuts piano sekaligus dan hasilnya adalah satu bunyi yang kamu dengar.

Masalahnya: komputer tidak tahu mana nada mana. Yang ia terima hanyalah satu sinyal yang tampak seperti gelombang naik-turun yang rumit. Grace perlu "memisahkan" gelombang kompleks itu kembali menjadi nada-nada penyusunnya.

Analogi Kue
Bayangkan kamu melihat sebuah kue jadi. Kamu tidak bisa langsung tahu bahannya apa. Tapi dengan analisis kimia yang tepat, kamu bisa memisahkan tepung, gula, telur, dan mentega. Fourier Transform melakukan hal serupa — ia memisahkan "bahan-bahan" frekuensi dari suara gabungan Rocky.

Langkah 3: Fourier Transform — Kacamata Ajaib untuk Suara

Fourier Transform adalah teknik matematika yang mengubah sinyal suara dari representasi "waktu" (gelombang naik-turun) menjadi representasi "frekuensi" (daftar nada dan intensitasnya). Ini adalah alat standar dalam ilmu sinyal — dan Andy Weir secara eksplisit menyebutkan bahwa Grace menggunakannya dalam novel.

Tapi ada satu masalah dengan Fourier Transform biasa: ia menganalisis seluruh rekaman sekaligus. Ini sama seperti merekam seluruh percakapan satu jam, lalu baru menganalisisnya — kamu tidak tahu kata mana muncul di menit ke-5 versus menit ke-30.

Langkah 4: Short-Time Fourier Transform (STFT) — Solusi yang Lebih Cerdas

Di sinilah STFT masuk. Alih-alih menganalisis keseluruhan suara sekaligus, STFT memotong rekaman menjadi jendela-jendela waktu pendek, lalu menerapkan Fourier Transform pada setiap jendela.

Analogi Senter
Bayangkan kamu mencoba membaca buku dalam gelap menggunakan senter. Kamu tidak bisa menyinari seluruh halaman sekaligus (hasilnya kabur). Kamu gerakkan senter perlahan dari kiri ke kanan, menerangi bagian kecil demi bagian kecil. STFT melakukan hal yang sama — menyinari suara sedikit demi sedikit, dari awal hingga akhir.

Hasil dari STFT adalah sebuah spektrogram: gambar dua dimensi di mana:

Sumbu horizontal = waktu (kapan suara terjadi)
Sumbu vertikal = frekuensi (nada apa yang muncul)
Kecerahan/warna = seberapa kuat nada tersebut

Dari spektrogram ini, Grace bisa melihat dengan jelas: "Kata pertama Rocky = kombinasi nada A rendah dan A tengah. Kata kedua = nada C tinggi dan C rendah. Kata ketiga = ..." dan seterusnya.

Langkah 5: Dari Nada ke Kata — MIDI dan Spreadsheet

Setelah STFT memisahkan frekuensi per jendela waktu, setiap kombinasi nada perlu dikodekan ke dalam format yang bisa dikelola oleh kamus. Di sinilah MIDI masuk.

MIDI (Musical Instrument Digital Interface) adalah standar komputer untuk merepresentasikan nada sebagai angka — misalnya, nada A4 = angka 69, C5 = 72, dan seterusnya. Dengan mengkonversi deteksi frekuensi STFT menjadi nomor MIDI, setiap "kata" Rocky menjadi sebuah kumpulan angka yang unik.

Grace kemudian membangun sebuah spreadsheet (Excel) sederhana:

Ketika Rocky berbicara, sistem bekerja secara otomatis: STFT deteksi nada → konversi ke MIDI → cek spreadsheet → text-to-speech membacakan terjemahan ke Grace. Semuanya terjadi hampir secara real-time.

Alur Lengkap Sistem Terjemahan

Rocky berbicara : Menghasilkan kord nada via lima "pipa suara" internal yang mendorong gas amonia melewati membran getar.
Mikrofon menangkap gelombang suara : Sinyal audio mentah — terlihat seperti satu gelombang kompleks yang bercampur aduk.
STFT memotong & menganalisis per jendela waktu : Setiap potongan kecil dianalisis frekuensinya. Hasilnya: spektrogram yang menunjukkan nada apa yang aktif di setiap momen.
Peak detection — deteksi nada dominan : Sistem mencari puncak-puncak frekuensi di setiap jendela, mengidentifikasi kombinasi nada yang aktif (satu "kord kata").
Konversi ke nomor MIDI : Frekuensi yang terdeteksi dikonversi ke nomor MIDI standar — mengubah fisika gelombang menjadi data yang bisa disimpan di spreadsheet.
Cek kamus (spreadsheet Excel) : Kombinasi MIDI dicari di tabel yang Grace bangun secara manual — awalnya hanya puluhan kata, lalu ratusan seiring waktu.
Text-to-speech : Teks bahasa Inggris diucapkan keras oleh komputer — itulah suara yang kita dengar dari Rocky di film (diisi oleh James Ortiz).

Keterbatasan Sistem — Apa yang Tidak Dibahas Film?

Sistem ini terdengar elegan, tapi ada beberapa celah besar yang perlu kita akui:

Masalah 1: Kebetulan yang Terlalu Sempurna : STFT dan MIDI bekerja karena Rocky secara kebetulan menggunakan sistem 12 nada per oktaf yang sama dengan manusia, dengan referensi nada yang hampir identik (A=440 Hz). Probabilitas dua spesies yang berevolusi secara terpisah di planet berbeda mencapai standar ini sangat kecil
Masalah 2: Kamus Tidak Bisa Menangkap Abstraksi : Ketika Grace menjelaskan bahwa Rocky "berani" (brave), tidak ada cara logis bagi spreadsheet untuk menerjemahkan konsep abstrak itu ke dalam Eridian. Kamus berbasis lookup hanya bekerja untuk kata-kata konkret yang bisa ditunjuk atau didemonstrasikan.
Masalah 3: Pergeseran Nada Emosional : Ketika Rocky marah atau gembira, nada suaranya bergeser naik atau turun. Jika STFT menangkap pergeseran ini sebagai bagian dari "kata", sistem lookup akan gagal — karena kord yang sama di frekuensi berbeda akan terdeteksi sebagai kata yang berbeda.

Solusi yang lebih modern dan realistis? Pakar machine learning menyarankan menggunakan model seperti HuBERT (model self-supervised audio) yang bisa belajar memisahkan nada emosional dari nada leksikal secara otomatis, tanpa perlu asumsi tentang standar MIDI manusia.

Bacaan Lanjutan (Kalau Kamu Penasaran)

Kalau artikel ini membuatmu ingin menggali lebih dalam, berikut beberapa topik yang bisa kamu eksplorasi:

Short-Time Fourier Transform — cari tutorial di YouTube dengan kata kunci "STFT spectrogram explained simply"
Xenolinguistik — cabang linguistik yang mempelajari bagaimana manusia mungkin berkomunikasi dengan entitas non-manusia
CETI Project — proyek nyata yang mencoba menerjemahkan bahasa paus sperma menggunakan teknik audio serupa
Film Arrival (2016) — pendekatan berbeda untuk masalah yang sama: bagaimana membangun komunikasi dengan alien dari nol
Novel Project Hail Mary (Andy Weir, 2021) — detail teknis jauh lebih kaya dibanding filmnya

Bikin Chatbot Sendiri yang Bisa Jawab Pertanyaan dari Dokumen kamu

Nugroho Ardi Sutrisno — Thu, 21 May 2026 09:50:26 +0000

Di tulisan ini kita akan membahas soal sebuah proyek kecil bernama Simple RAG Chatbot. Tujuannya sederhana: bikin chatbot yang bisa menjawab pertanyaan berdasarkan dokumen yang kamu punya — bukan ngarang dari pengetahuan model. Cocok buat kamu yang baru pertama kali denger istilah RAG dan pengen tahu cara kerjanya tanpa pusing.

Repository proyek aplikasi : https://github.com/ardisaurus/simple-rag-chatbot

Masalah yang Ingin Diselesaikan

Coba bayangin kamu punya banyak banget dokumentasi produk: file Markdown, catatan teknis, panduan instalasi, FAQ. Setiap kali ada orang baru gabung, mereka selalu nanya hal yang sebenernya udah ada di dokumen — tapi siapa juga yang sempat baca semuanya?

Solusi instan yang mungkin terlintas: "kasih aja ke ChatGPT terus suruh jawab." Tapi ada dua masalah:

Model AI seperti ChatGPT tidak tahu isi dokumen pribadimu.
Kalau kamu paste seluruh dokumen ke chat, biayanya mahal dan sering kepotong limit token.

Di sinilah teknik bernama RAG masuk.

Apa Itu RAG?

RAG kepanjangannya Retrieval-Augmented Generation. Kedengeran ribet, padahal idenya simpel banget:

Retrieval (pengambilan): cari potongan dokumen yang paling relevan dengan pertanyaan user.
Augmented (diperkaya): tempelin potongan itu ke prompt yang dikirim ke LLM (model bahasa besar).
Generation (pembuatan jawaban): LLM jawab berdasarkan potongan yang barusan dia terima.

Jadi LLM-nya gak perlu hapal seluruh dokumenmu. Dia cuma perlu baca beberapa paragraf yang relevan untuk setiap pertanyaan. Hemat token, hemat biaya, dan jawabannya jadi lebih akurat karena ada bukti sumbernya.

Cara Komputer Cari Potongan yang Relevan: Embeddings

Pertanyaannya: gimana komputer tau potongan dokumen mana yang relevan sama pertanyaan user?

Jawabannya pakai konsep embeddings. Embedding itu cara mengubah teks menjadi sebuah deretan angka (vektor) yang merepresentasikan makna teks tersebut. Dua kalimat yang artinya mirip akan menghasilkan vektor yang mirip juga, walaupun kata-katanya berbeda.

Contoh:

"How do I install the product?" → [0.12, -0.34, 0.88, ...]
"Cara memasang aplikasinya gimana?" → [0.11, -0.33, 0.86, ...]

Walaupun bahasanya beda, vektornya berdekatan karena maknanya mirip.

Lalu kita simpan semua vektor dokumen di sebuah vector database. Saat user nanya, kita ubah pertanyaannya jadi vektor, terus cari vektor dokumen yang paling dekat. Itulah potongan yang paling relevan.

Tools yang Dipakai di Proyek Ini

Aku sengaja pilih tools yang gratis atau super murah supaya kamu bisa self-hosting di laptop sendiri:

Next.js (App Router) — framework React untuk bikin web app.
TypeScript — biar kode lebih aman dan mudah di-maintain.
LangChain.js — library yang mempermudah semua langkah RAG: split dokumen, bikin embedding, retrieval, sampai panggil LLM.
ChromaDB — vector database yang bisa jalan lokal pakai Docker.
OpenRouter — gateway buat berbagai LLM (GPT, Claude, Llama, dll). Bayar per token, dan model default-nya cuma beberapa rupiah per pertanyaan.
@xenova/transformers — library untuk bikin embedding langsung di laptopmu, tanpa API. Jadi gak perlu langganan OpenAI cuma buat embedding.
Tailwind CSS — supaya tampilannya rapi tanpa nulis CSS panjang.

Format Dokumen yang Didukung & Batasannya

Sebelum kita masuk ke alur teknisnya, penting kamu tahu dulu dokumen apa aja yang bisa diproses sama proyek ini, dan apa aja batasan dari implementasi sekarang. Jangan sampai kamu masukin file PDF terus heran kenapa chatbot-nya jawab "saya tidak tahu" — ternyata file-nya emang gak pernah ke-index.

Format yang Didukung Saat Ini

Hanya tiga ekstensi yang dibaca oleh script ingest:

.md — Markdown standar.
.markdown — sama aja, beda ekstensi.
.txt — teks polos.

Daftar ini didefinisikan di lib/ingest.ts sebagai SUPPORTED_EXTENSIONS. File dengan ekstensi lain akan di-skip diam-diam (tanpa warning) saat script jalan menjelajahi folder. Subfolder ikut dibaca rekursif, jadi kamu bebas mengelompokkan dokumen ke dalam beberapa folder.

Format yang Belum Didukung

Berikut yang belum bisa langsung kamu masukin tanpa modifikasi kode:

PDF — perlu library tambahan kayak pdf-parse. Cara nambahinnya udah dijelasin di file data/docs/wiki/08-extending.md.
DOCX / Office documents — perlu parser tersendiri (misal mammoth untuk DOCX).
HTML — bisa diproses, tapi butuh parser untuk strip tag HTML supaya yang ke-embed cuma teksnya.
MDX — walaupun mirip Markdown, ekstensinya .mdx jadi gak akan ke-pickup. Kalau kamu yakin gak ada JSX di dalamnya, gampang aja: tambahin .mdx ke SUPPORTED_EXTENSIONS.
Gambar / scan / screenshot — proyek ini gak punya OCR. Kalau dokumenmu berbentuk gambar, perlu pipeline tambahan (misal Tesseract atau API OCR) untuk ngubah jadi teks dulu.
CSV / spreadsheet / JSON terstruktur — bisa di-index sebagai teks polos, tapi hasilnya kurang optimal karena splitter-nya gak paham struktur tabel.

Cara Kerja Aplikasinya, Step by Step

1. Ingestion: Masukin Dokumen ke Database

Pertama, kita siapin semua dokumen di folder data/docs/. Bisa Markdown atau TXT. Lalu jalanin:

npm run ingest

Yang terjadi di balik layar:

Script jalanin walk di folder data/docs/, ngambil semua file yang didukung.
Setiap file dipotong-potong jadi chunk kecil (sekitar 1000 karakter, dengan overlap 150 karakter biar konteksnya gak putus).
Setiap chunk diubah jadi vektor pakai model embedding lokal.
Vektor + chunk + metadata (nama file, nomor chunk) disimpan ke Chroma.

Sekarang Chroma punya "ingatan" tentang dokumenmu, siap dipakai untuk pencarian.

2. Pertanyaan dari User

User buka http://localhost:3000, ketik pertanyaan, terus pencet enter. Pertanyaan itu dikirim ke /api/chat.

3. Retrieval: Cari Chunk yang Relevan

Backend ngambil pertanyaan, ubah jadi vektor pakai model embedding yang sama, lalu tanya ke Chroma: "kasih aku 5 chunk yang vektornya paling dekat dengan ini."

Chroma balikin 5 chunk beserta metadata-nya.

4. Generation: Tanya ke LLM

5 chunk tadi dirakit jadi sebuah prompt seperti ini (disederhanakan):

Kamu adalah asisten dokumentasi. Jawab HANYA berdasarkan konteks
berikut. Kalau jawabannya tidak ada di konteks, bilang kamu tidak tahu.

Konteks:
[1] (instalasi.md #0) Untuk memasang aplikasi, unduh installer ...
[2] (instalasi.md #1) Setelah terpasang, jalankan dari menu ...
[3] ...

Pertanyaan: Bagaimana cara memasang aplikasinya?

Prompt itu dikirim ke OpenRouter, dan model jawab berdasarkan konteks yang udah dikasih. Karena ada instruksi tegas "jawab hanya dari konteks", model gak akan ngarang.

5. Streaming: Jawaban Muncul Sedikit-Sedikit

Daripada nunggu jawaban full baru ditampilkan, jawabannya distreaming token per token ke browser. User langsung lihat huruf demi huruf mengalir, mirip pengalaman ChatGPT. Lebih enak dilihat dan kerasa cepat.

6. Sumber Ditampilkan

Di bawah setiap jawaban ada tombol "Sources" yang bisa diklik. Isinya daftar chunk yang dipakai untuk menjawab, lengkap dengan nama file dan nomor chunk-nya. Jadi user bisa verifikasi jawaban si bot.

Kenapa Pilihan Teknisnya Begini?

Kenapa embedding-nya lokal, bukan pakai OpenAI?

Karena bisa gratis. Model Xenova/all-MiniLM-L6-v2 cukup pintar buat dokumentasi pendek, ukurannya kecil (~30 MB), dan jalan langsung di Node.js tanpa internet. Cocok buat self-hosting.

Kenapa LLM-nya pakai OpenRouter?

OpenRouter ngasih akses ke banyak model dengan satu API key. Kamu bisa ganti dari gpt-4o-mini ke claude-3.5-sonnet ke llama-3.1 cuma dengan ubah satu env var. Bagus buat eksperimen.

Kenapa Chroma, bukan Pinecone atau Weaviate?

Chroma gratis, jalan lokal, dan setup-nya cuma satu perintah Docker. Untuk skala kecil-menengah (puluhan ribu chunk) udah lebih dari cukup.

Kenapa wipe-and-replace saat ingest, bukan update incremental?

Biar simpel. Kalau ada file yang dihapus atau di-rename, gak akan ada chunk orphan yang tertinggal. Untuk dokumentasi yang gak terlalu besar, re-ingest cepat banget — hitungan detik.

Cara Coba di Laptopmu

Singkat aja, langkah-langkahnya:

# 1. Install dependency
npm install

# 2. Setup env (isi OPENROUTER_API_KEY dari https://openrouter.ai/keys)
cp .env.example .env

# 3. Jalanin Chroma di Docker
npm run chroma

# 4. Index dokumentasi sample yang udah disediain
npm run ingest

# 5. Jalanin aplikasinya
npm run dev

Buka http://localhost:3000, tanya apa aja soal dokumentasi yang udah di-index. Misalnya: "What is the default chunk size?"

Batasan Lain yang Perlu Dipahami

Selain soal format file, ada beberapa batasan implementasi yang penting kamu tahu:

Encoding harus UTF-8. Kalau file .txt kamu disimpan dalam encoding lain (misal Windows-1252), karakter non-ASCII (è, ñ, é, dll) bisa berantakan saat dibaca.
Splitter berbasis karakter, bukan struktur. Splitter default-nya RecursiveCharacterTextSplitter, yang motong teks berdasarkan jumlah karakter. Artinya tabel Markdown atau code block panjang bisa kepotong di tengah. Untuk Markdown yang lebih rapi splitnya, kamu bisa ganti ke MarkdownTextSplitter yang lebih sadar struktur heading.
Embedding model default-nya English-leaning. Xenova/all-MiniLM-L6-v2 dilatih dominan pada teks bahasa Inggris. Untuk dokumentasi Bahasa Indonesia, hasilnya masih lumayan tapi gak seoptimal model multilingual. Kalau kualitas pencarian dirasa kurang, ganti ke model multilingual seperti Xenova/multilingual-e5-small (jangan lupa re-ingest karena dimensi vektornya beda).
Ingest itu wipe-and-replace, bukan incremental. Setiap kali npm run ingest dijalankan, seluruh collection di Chroma dihapus dan dibangun ulang dari nol. Konsekuensinya: gak bisa update satu file aja. Tapi enaknya: gak akan ada chunk basi tertinggal.
Gak ada akses kontrol per-dokumen. Semua orang yang bisa akses chatbot akan dapet jawaban dari semua dokumen yang ke-index. Kalau ada dokumen sensitif, pisahin di collection berbeda atau jangan di-index sama sekali.
Chunk besar bisa boros token. Default CHUNK_SIZE = 1000 karakter × RETRIEVAL_K = 5 chunk = ~5000 karakter konteks per pertanyaan. Kalau modelmu mahal atau context window-nya kecil, turunin salah satu angka itu.

Intinya: proyek ini sengaja dibuat simpel dulu. Format yang lebih kompleks dan fitur incremental update memang sengaja gak dimasukin supaya kode-nya tetep gampang dibaca. Kalau butuh, semuanya bisa kamu tambahin sendiri dengan modifikasi kecil di lib/ingest.ts.

Penutup

RAG itu konsep yang awalnya kelihatan ribet, padahal intinya cuma: cari potongan yang relevan, tempelin ke prompt, biarkan LLM jawab berdasarkan itu.

Proyek ini sengaja dibuat minimal dan mudah dibaca. Total kode inti cuma di folder lib/ dan app/ — tiap file punya tanggung jawab yang jelas. Kalau kamu pengen belajar gimana sistem RAG bekerja dari nol, baca aja file-filenya satu per satu, dimulai dari lib/ingest.ts, lalu lib/rag.ts.

Selamat ngoprek, dan semoga proyek kecil ini bisa jadi titik awal kamu bikin asisten dokumentasi sendiri!

Repository proyek aplikasi : https://github.com/ardisaurus/simple-rag-chatbot

"Attention Is All You Need" Paper tahun 2017 yang mengubah dunia kecerdasan buatan, dijelaskan tanpa perlu latar belakang teknis.

Nugroho Ardi Sutrisno — Fri, 10 Apr 2026 07:15:33 +0000

🌍 Mengapa paper ini begitu penting?

Sebelum 2017, komputer sangat kesulitan memahami dan menghasilkan bahasa manusia. Para peneliti sudah mencoba berbagai pendekatan, tapi semuanya punya masalah mendasar.

Lalu delapan peneliti Google menulis sebuah paper berjudul "Attention Is All You Need" — dan dunia AI tidak pernah sama lagi. Paper ini memperkenalkan arsitektur bernama Transformer, yang menjadi fondasi dari hampir semua AI bahasa modern:

ChatGPT dan semua model GPT dari OpenAI
Claude
Gemini dari Google
Google Translate versi modern
Dan ratusan aplikasi AI lainnya

Analogi : Bayangkan sebelumnya orang mencoba membangun gedung pencakar langit menggunakan bata satu per satu dari bawah. Paper ini seperti menemukan baja dan beton bertulang — material baru yang jauh lebih kuat dan efisien.

😓 Masalah sebelum Transformer

Untuk memahami solusinya, kita perlu tahu dulu apa masalahnya. Sebelum Transformer, model bahasa menggunakan arsitektur yang disebut RNNRecurrent Neural Network — jaringan saraf yang memproses kata satu per satu secara berurutan (Recurrent Neural Network).

Bayangkan kamu membaca kalimat ini kata per kata, dan kamu hanya diizinkan mengingat satu catatan kecil yang terus kamu perbarui setiap membaca kata baru. Di akhir kalimat, kamu harus menjawab pertanyaan tentang kata yang ada di awal — tapi catatan kamu sudah berubah berkali-kali!

🔍 Apa itu "Attention"?

Konsep paling kunci dalam paper ini adalah mekanisme attention. Idenya intuitif: ketika kamu membaca sebuah kata, kamu secara alami memperhatikan kata-kata lain yang relevan untuk memahaminya.

Contoh Nyata : Dalam kalimat "Kucing itu duduk di atas matras karena ia lelah" — untuk memahami kata "ia", kamu secara otomatis melirik ke belakang dan menghubungkannya dengan "Kucing". Itulah persis yang dilakukan attention!

Mekanisme attention memungkinkan model untuk melihat semua kata sekaligus dan menentukan kata mana yang paling relevan untuk memahami sebuah kata tertentu.

Rumus Attention (tidak perlu panik!)
Secara matematis, attention dihitung dengan rumus sederhana:

Terjemahannya dalam bahasa manusia:

Q (Query) = "Apa yang sedang aku cari?"
K (Key) = "Apa yang dimiliki setiap kata?"
V (Value) = "Informasi apa yang ingin kubawa jika relevan?"
Hitung seberapa cocok Query dengan setiap Key → dapat skor
Gunakan skor itu untuk mengambil Value yang proporsional

🎯 Multi-Head Attention

Satu mekanisme attention saja tidak cukup, karena setiap kata punya banyak aspek yang perlu diperhatikan secara bersamaan. Transformer menggunakan Multi-Head Attention — beberapa "kepala" attention yang bekerja paralel, masing-masing fokus pada aspek yang berbeda.

Kepala Sintaksis : Kepala ini fokus pada hubungan tata bahasa, subjek-predikat, kata sifat-kata benda. Seperti seorang ahli tata bahasa yang menganalisis struktur kalimat.
Kepala Referensi : Kepala ini ahli mencari referensi kata ganti, menemukan bahwa "ia", "mereka", atau "itu" merujuk ke entitas mana. Sangat penting untuk pemahaman konteks.
Kepala Kedekatan : Kepala ini memperhatikan kata-kata yang berdekatan secara posisi, frasa seperti "di atas", "sangat cepat", atau "meja kayu". Tangkap hubungan lokal.
Kepala Semantik : Kepala ini fokus pada makna, menghubungkan kata-kata yang memiliki hubungan semantik seperti tindakan dengan pelakunya atau benda dengan sifatnya.
Kepala Temporal : Kepala ini sensitif terhadap hubungan waktu dan urutan kejadian dalam teks kata kerja, kata keterangan waktu, dan kausalitas.
Kepala Konteks : Kepala ini punya jangkauan luas, menghubungkan tema utama paragraph atau dokumen, menjaga koherensi global teks.

🏗️ Arsitektur Transformer

Transformer terdiri dari dua bagian besar: Encoder (pemahaman) dan Decoder (pembuatan). Untuk tugas terjemahan misalnya, encoder membaca bahasa sumber dan decoder menghasilkan terjemahannya.

A. ENCODER

Encoder Self-Attention Setiap kata dalam input memperhatikan semua kata lain di kalimat yang sama. Ini membangun pemahaman konteks yang kaya — "bank" dalam "bank sungai" vs "bank uang" akan berbeda representasinya.
Feed-Forward Proses tiap kata
Layer Normalization Normalisasi memastikan nilai tidak meledak atau mengecil saat data melewati banyak lapisan. Tanpa ini, training bisa tidak stabil. Juga ada "residual connections" (skip connections) yang membantu gradient mengalir.
Output Encoder Encoder menghasilkan representasi kontekstual yang kaya untuk setiap kata input. Bukan lagi sekadar "embeddings" statis, tapi representasi yang sudah memahami konteks penuh kalimat.

B. DECODER

Masked Self-Attention Kata yang sudah ada
Cross-Attention — Jembatan Encoder↔Decoder Bagian paling krusial! Decoder menggunakan output yang sedang dihasilkan sebagai Query dan seluruh output encoder sebagai Key+Value. Model secara eksplisit memilih bagian mana dari input yang relevan untuk setiap langkah decoding.
Decoder Feed-Forward Sama seperti encoder, lapisan ini memproses setiap posisi secara independen setelah informasi dari kedua attention layers digabungkan.
Feed-forward Proses gabungan info
Softmax Output Output akhir adalah distribusi probabilitas atas seluruh kosakata (bisa ratusan ribu kata!). Kata dengan probabilitas tertinggi dipilih, atau kita bisa "sampling" untuk variasi. Proses ini berulang sampai kalimat selesai.

📍 Positional Encoding

Ada satu masalah kecil: karena Transformer memproses semua kata secara paralel (bukan berurutan), model tidak tahu kata mana yang datang pertama, kedua, atau ketiga. Ini seperti dikasih kartu yang sudah diacak — kamu tidak tahu urutannya!

Solusinya: tambahkan informasi posisi ke setiap kata sebelum diproses. Paper ini menggunakan fungsi sinus dan cosinus untuk mengkodekan posisi ini.

Intuisi Sederhana Setiap posisi mendapat "cap" numerik yang unik, seperti nomor kursi di bioskop. Model belajar menggunakan cap ini untuk memahami urutan dan jarak antar kata.

📊 Hasil yang Menakjubkan

Ketika paper ini pertama dirilis, hasilnya membuat komunitas riset terkejut. Transformer tidak hanya lebih baik — ia jauh lebih baik, dengan waktu training yang lebih singkat.

🎓 Apa yang sudah kita pelajari?

📚 Mau belajar lebih lanjut?

Paper asli "Attention Is All You Need" (arXiv)
The Illustrated Transformer — Jay Alammar (visualisasi cantik, bahasa Inggris)
Andrej Karpathy: Let's build GPT from scratch (YouTube)

Hipotesis Tiket Lotre: Penemuan Jaringan Saraf Jarang yang Dapat Dilatih dengan Efisien

Nugroho Ardi Sutrisno — Sat, 14 Mar 2026 04:56:49 +0000

Hipotesis Tiket Lotre (Lottery Ticket Hypothesis) merupakan konsep revolusioner dalam bidang kecerdasan buatan, yang pertama kali diperkenalkan oleh Jonathan Frankle dan Michael Carbin pada tahun 2018. Konsep ini mengungkap potensi efisiensi luar biasa dalam pelatihan jaringan saraf buatan (neural networks). Artikel ini menyajikan penjelasan yang mudah dipahami bagi pemula, dengan analogi sederhana dan ilustrasi visual.

Pengertian Hipotesis Tiket Lotre

Hipotesis ini menganalogikan jaringan saraf besar sebagai kumpulan tiket lotre. Sebagian besar tiket tidak berguna, tetapi terdapat sub-jaringan jarang (sparse subnetwork) yang, jika diidentifikasi dan dilatih secara terpisah, mampu mencapai performa setara dengan jaringan penuh.

Jaringan saraf terdiri dari jutaan parameter (bobot koneksi antar-neuron).
Pada inisialisasi acak, sub-jaringan kecil (10-20% parameter) sudah "berpotensi menang".
Fakta kunci: Sub-jaringan ini, setelah dipisahkan, dapat dilatih dengan sumber daya minimal tanpa mengorbankan akurasi.

Ilustrasi 1: Analogi Tiket Lotre

Bayangkan sebuah kotak berisi 1.000 tiket lotre. Hanya satu tiket pemenang. Demikian pula, dari jaringan saraf dengan jutaan parameter, hanya sub-jaringan kecil yang "pemenang".

Signifikansi bagi Pemula di Bidang AI

Konsep ini memiliki implikasi praktis yang signifikan:

Efisiensi Komputasi: Mengurangi kebutuhan GPU/CPU hingga 10 kali lipat.
Aksesibilitas: Memungkinkan pelatihan model di perangkat sederhana, seperti laptop standar.
Keberlanjutan: Menghemat energi, relevan di era komputasi ramah lingkungan.

Contoh: Pada dataset pengenalan gambar CIFAR-10, sub-jaringan dengan 10% parameter mencapai akurasi >90%, setara model penuh.

Mekanisme Kerja: Proses Langkah demi Langkah

Proses pencarian "tiket pemenang" dilakukan secara sistematis:

Inisialisasi jaringan saraf besar secara acak.
Latih sementara (1-2 epoch) untuk mengidentifikasi bobot penting.
Pemangkasan (pruning): Hilangkan 80-90% bobot terkecil.
Reset bobot sub-jaringan ke inisialisasi awal, lalu latih ulang.

Ilustrasi 2: Diagram Proses (Mermaid)

Diagram ini menggambarkan alur efisien, di mana output akhir (hijau) adalah model jarang yang superior.

Dampak dan Prospek Masa Depan

Hipotesis ini telah diadopsi dalam framework seperti PyTorch dan TensorFlow, dengan aplikasi pada model besar seperti Transformer. Penelitian terkini (hingga 2025) menunjukkan keberhasilannya pada large language models (LLM). Tantangan utama meliputi konsistensi lintas arsitektur dan skalabilitas.

Penutup

Hipotesis Tiket Lotre menegaskan prinsip kualitas mengungguli kuantitas dalam pengembangan AI. Bagi praktisi pemula, konsep ini mendorong eksplorasi implementasi langsung melalui repositori open-source. Unduh paper asli di arXiv:1803.03635 untuk studi lebih lanjut.

Dari Matematika Murni ke Enkripsi: Bagaimana G. H. Hardy Secara Tak Sengaja Menggerakkan Kriptografi Modern

Nugroho Ardi Sutrisno — Thu, 04 Dec 2025 06:52:16 +0000

Ketika G. H. Hardy (Godfrey Harold Hardy) dengan bangga menyatakan bahwa karyanya dalam matematika murni tidak akan pernah berguna secara praktis, ia ternyata keliru besar.

Lebih dari 50 tahun setelah kematiannya, sistem yang mengamankan pesan WhatsApp Anda, melindungi transaksi perbankan online, dan menjaga komunikasi digital global semuanya bergantung pada ide-ide matematika yang pernah ia kembangkan.

Ironisnya, matematika yang dulu ia sebut sebagai “indah tapi tak berguna” justru menjadi tulang punggung kriptografi modern.

Artikel ini membahas jembatan tak terduga antara teori bilangan awal abad ke-20 karya Hardy dan skema enkripsi yang mengamankan dunia digital kita saat ini.

🔑 Dunia Hardy: Matematika Murni demi Keindahan, Bukan Kegunaan

Hardy adalah penganut kuat matematika murni ilmu yang dikejar demi keindahannya, bukan aplikasinya.

Ia bekerja secara luas pada:

Teori bilangan prima
Analisis bilangan (analytic number theory)
Rumus-rumus asimtotik
Kolaborasi dengan Ramanujan dan Littlewood

Pada masanya, bidang-bidang ini dipandang kaya secara intelektual namun tidak memiliki manfaat praktis.

Hari ini, bidang yang sama justru menjadi inti dari kriptografi.

🔗 Bagaimana Karya Hardy Terhubung dengan Kriptografi Modern

Berikut diagram sederhana untuk memperlihatkan keterkaitannya:

1️⃣ Teori Bilangan Prima → RSA dan Enkripsi Kunci Publik

Karya Hardy bersama Littlewood menghasilkan pemahaman mendalam tentang distribusi bilangan prima.

Hal ini sangat penting hari ini karena hampir semua sistem kriptografi kunci publik seperti RSA, Diffie–Hellman, hingga elliptic-curve cryptography (ECC) bergantung pada:

ketersediaan bilangan prima besar
kepadatan bilangan prima dalam rentang tertentu
kesulitan memfaktorkan bilangan komposit besar

RSA, misalnya, bekerja dengan memilih dua bilangan prima besar dan mengalikannya. Keamanan muncul dari kesulitan memfaktorkan hasil perkalian itu kembali menjadi dua bilangan prima awal yang merupakan fenomena yang dipahami melalui teori bilangan.

2️⃣ Analisis Bilangan → Fondasi “Tingkat Kesulitan” dalam Kriptografi

Hardy adalah salah satu pionir analytic number theory, penggunaan analisis matematis untuk mempelajari bilangan bulat.

Bidang ini menjadi dasar bagi banyak asumsi keamanan dalam kriptografi modern, seperti:

distribusi bilangan prima
struktur aritmetika modular
kesulitan logaritma diskrit
sifat acak fungsi bilangan

Analisis bilangan menyediakan “medan matematis” tempat algoritma kriptografi berdiri.

3️⃣ Metode Asimtotik Hardy–Ramanujan → Analisis Kompleksitas Algoritma

Hardy dan Ramanujan mengembangkan metode canggih untuk memperkirakan pertumbuhan fungsi, yang kini berhubungan dengan analisis kompleksitas algoritma.

Pendekatan ini penting untuk:

mengevaluasi performa algoritma kriptografi
menentukan ukuran kunci yang aman
memperkirakan ketahanan brute-force
menganalisis hash dan pseudorandom number generators

Teknik-teknik mereka membentuk cara kita memahami keamanan digital secara matematis.

🔥 Ironi Terbesar: Matematika “Tak Berguna” Hardy Justru Menjadi Pondasi Dunia Siber

Dalam A Mathematician’s Apology, Hardy pernah menulis:

“Saya tidak pernah melakukan sesuatu yang ‘berguna’. Tidak ada penemuan saya yang membuat atau memungkinkan, langsung atau tidak langsung, perbedaan terhadap kenyamanan dunia.”

Ironisnya, ia tidak mungkin membayangkan:

perbankan online
komunikasi terenkripsi
tanda tangan digital
blockchain
belanja internet
enkripsi untuk pertahanan dan keamanan nasional
komunikasi satelit

Semua bergantung pada teori bilangan, bidang yang ia kembangkan dengan penuh kecintaan.

🎯 Kesimpulan

G. H. Hardy tidak pernah membayangkan kriptografi. Namun karya matematisnya yang murni, elegan, dan sengaja tidak praktis menjadi fondasi yang menopang keamanan dunia digital modern.

Di era ketika miliaran pesan terenkripsi terkirim setiap hari, warisan Hardy semakin terasa hidup.

Matematikanya yang “tidak berguna” kini menjadi salah satu matematika paling berguna yang pernah dibuat.