Skip to content
Konsultasi

AI yang tahu lagi kerjain apa: grounding ke commit terbaru

Adityo Guni Waluyo

Chat AI blog yang jawab 'lagi kerjain apa' dari commit history lokal — port sempit, cache version namespace, dan mining istilah dari commit message.

Satu fitur chat AI di blog ini: pengunjung bisa nanya apa aja soal isi situs. Beberapa hari terakhir saya tes pertanyaan paling natural yang ada: “lagi kerjain apa?” Jawaban yang keluar selalu nyempit ke artikel yang udah dipublish, padahal commit terakhir yang benar-benar lagi dikerjakan belum tentu jadi artikel. LLM-nya nggak salah; data grounding-nya emang cuma artikel dan knowledge base. Sumber yang paling jujur buat pertanyaan “lagi kerjain apa” justru commit history.

Dugaan pertama: tinggal tempel commit ke prompt

Dugaan awal saya simpel banget: tambahin blok commit terbaru ke prompt, beres. Tapi begitu dipikir, ada dua masalah yang bikin solusi itu rapuh.

Pertanyaan “lagi kerjain apa” itu repetitif: bakal ditanya berkali-kali, dan tiap kali jawab harus baca tabel commit dari database. Natural kalau kena cache. Nah, di sinilah dugaan kedua saya meleset. Saya kira cukup delete cache key tiap ada commit baru masuk. Ternyata pola delete-per-key rawan stale read pas traffic tinggi: user nembak key yang udah expired atau lagi di-rewrite. Dok Redis soal pola cache-aside bilang justru sebaliknya: biarkan cache-nya expire alami dan repopulate di baca berikutnya, jangan coba jaga sinkron terus-menerus [6].

Isu kedua: arsitektur. Modul articles di API ini nggak boleh import modul activity secara langsung. Jadi butuh jembatan yang sempit.

Port kecil, adapter, dan version namespace

Solusinya tiga lapis. Pertama, port ActivityCommitReader di modul articles. Bentuk datanya kecil: repo, message, timestamp. Adapternya SqlModelActivityReader tinggal translate ke repository milik modul activity. Prinsip dependency injection-nya konsisten dengan panduan FastAPI: application scope dibangun lewat lifespan dan app.state, dependensi tinggal membagikan handle, bukan membangun pool baru tiap request [3].

Kedua, deteksi intent. Fungsi _is_work_query nge-match frasa bahasa Indonesia dan Inggris, seperti “sedang dikerjakan” dan “lagi kerjakan”, “what are you working on”, dan beberapa varian lain. Kalo match, pipeline narik commit 3 hari terakhir (maksimal 30 commit, 5 repo) dari sync GitHub lokal, bukan panggilan GitHub API di waktu tanya.

Ketiga, cache invalidation. Tiap sync GitHub nemu commit baru, namespace versi act di Redis di-bump. Semua key jawaban “lagi kerjain apa” versi lama langsung orphan dan nggak akan dibaca lagi, expire sendiri lewat TTL. Pola yang sama kayak rekomendasi Redis buat shared deployment: prefix key per aplikasi biar service nggak saling timpa [6], dan generasi key di-retire sekaligus pas data grounding berubah [2].

# github_sync.py — potongan
if total_new > 0:
    redis_core.bump_version("act")

Istilah commit jadi query artikel

Bonus yang nggak saya rencanakan dari awal: kata-kata dari commit message bisa dipakai buat nyari artikel terkait. Fungsi _work_terms nambang istilah dari message commit, stopword difilter (update, fix, feat, merge, dan seterusnya), urutan commit terbaru dijaga, maksimal 6 istilah. Istilah itu jadi query pencarian artikel dengan skor minimum 0.5.

Pendekatan mining-query-dari-data ini nyambung dengan konsep query expansion di full-text search: search dijalankan dua kali, istilah dari dokumen paling relevan ditambahkan ke pencarian kedua [1]. MySQL nyebut mekanismenya blind query expansion: frasa pencarian kedua adalah frasa awal plus dokumen paling relevan dari pencarian pertama [4]. Cocok buat query pendek dan pencarian eksploratif [5].

Satu hal yang saya pegang di commit ini: activity store boleh mati, jawaban tetap keluar. Baca commit dibungkus try/except. Kalo gagal, cuma logger.warning dan pipeline lanjut tanpa blok aktivitas. Pertanyaan “lagi kerjain apa” bakal dijawab sebisanya dari artikel dan knowledge base, kayak sebelumnya.

Angka-angka batasnya — 3 hari, 30 commit, 5 repo, 6 istilah, skor 0.5) emang heuristik saya sendiri, bukan angka dari dokumentasi mana pun. Angka segitu rasanya cukup buat blog satuan ini; repo lain mungkin butuh penyesuaian.

Sumber

[1] MariaDB Full-Text Index Overview
[2] Configuring the Django Redis Cache Backend
[3] FastAPI Best Practices for Dependency Injection
[4] MySQL 8.4 Full-Text Searches with Query Expansion
[5] How to Use MySQL Full-Text Search
[6] Redis Cache-aside Guide

Artikel terkait