Bikin Chatbot Sendiri yang Bisa Jawab Pertanyaan dari Dokumen kamu

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!