# Dokumentasi Transisi Arsitektur RAG: Sistem A ke Sistem B

Dokumen ini mencatat rekam jejak (*changelog*) dari perbaikan arsitektur yang telah dilakukan untuk menstabilkan sistem RAG, serta peta jalan (*roadmap*) menuju arsitektur produksi kelas *Enterprise* (Sistem B) yang akan diimplementasikan pada platform Web MySRE.

---

## 1. Apa yang Telah Dilakukan (Stabilisasi Sistem A)

Sebelum melangkah ke pembaruan sistem, beberapa perbaikan fundamental telah berhasil dieksekusi untuk memastikan *baseline* (Sistem A) dapat dievaluasi secara matematis.

### a. Resolusi Konflik *Environment Variable* (Konteks Kosong)
**Masalah:** Skrip evaluasi sebelumnya selalu mengembalikan konteks kosong (`['Tidak ada informasi di database.']`).
**Solusi:** Ditemukan bahwa variabel global Windows `SUPABASE_SERVICE_KEY` menimpa kredensial `.env` lokal dan mengarahkan sistem ke *database* lama yang sudah terhapus. Hal ini diperbaiki dengan memaksa inisialisasi eksplisit menggunakan kunci baru langsung ke *instance* `ihrsuvzmfcjxyualsell`.

### b. Mitigasi Limitasi API (Rate Limit 429 & Arrearage 401)
**Masalah:** Sistem evaluasi Ragas memakan jumlah *request* yang sangat masif, memicu pemblokiran harian dari Google Gemini (Limit 1.500 RPD) dan pemblokiran tagihan dari Alibaba DashScope (Arrearage).
**Solusi:** 
- Berpindah sepenuhnya ke salah satu cadangan *Google API Key* yang masih memiliki kuota 100%.
- Mengembangkan skrip `evaluate_ultimate.py` dengan mekanisme **Ultra-Safe Batching**: Membatasi konkurensi menjadi 3 soal per *batch* yang diselingi masa tunggu (*sleep*) 60 detik. Hal ini menjamin skrip beroperasi di bawah batas 15 RPM (Request Per Minute) Google secara aman tanpa *crash*.

### c. Identifikasi Keterbatasan Skema Database
**Penemuan:** Analisis forensik pada Supabase menemukan bahwa tabel `document_chunks` hanya berisi teks mentah. Kolom `embedding` bertipe vektor secara fisik **tidak ada**. Oleh karena itu, arsitektur yang berjalan selama ini adalah **"Hash-Based Metadata Retrieval"**, di mana Chatbot menarik 59 paragraf mentah secara membabi buta tanpa penyaringan semantik.

---

## 2. Apa yang Akan Menjadi Sistem B (Arsitektur Produksi)

Untuk membawa Web MySRE ke standar *Enterprise*, sistem akan di- *upgrade* ke **Sistem B**, yaitu implementasi **Hybrid Vector Search**.

### a. Integrasi Ekstensi `pgvector`
*Database* Supabase akan dipersenjatai dengan ekstensi kecerdasan buatan `vector(768)`. Sebuah fungsi *Remote Procedure Call* (RPC) bernama `match_document_chunks` akan ditanamkan langsung ke dalam inti *database*.

### b. Proses Re-Ingestion (Injeksi Vektor)
Ke-59 paragraf mentah yang ada saat ini akan ditarik, dikirim ke model `models/text-embedding-004` Google untuk diubah menjadi matriks koordinat matematika (Vektor 768 dimensi), lalu disuntikkan kembali ke dalam Supabase.

### c. Refactoring Chatbot (Hybrid Architecture: Cohere + Gemini)
Sistem penarikan dokumen di `agent_orchestrator.py` dirombak total menggunakan arsitektur Hibrida kelas produksi:
1. **Pencarian (Embeddings):** Pertanyaan pengguna diubah menjadi vektor 1024D oleh Cohere. Database mencari 5 paragraf dengan jarak matematis terdekat (paling relevan).
2. **Penyaringan (Metadata Filter):** Pencarian tersebut **dikunci** HANYA pada paragraf yang memiliki `file_hash` yang sedang aktif, menjamin 0% risiko *context bleeding* (tercampurnya informasi dari jurnal lain).
3. **Penjawab (LLM):** 5 paragraf yang sangat padat tersebut diserahkan ke Google Gemini 2.5 Flash yang bertugas membaca dan merangkai jawaban akhir dengan sangat cepat tanpa terkena *Lost in the Middle Syndrome*.

### d. Insiden Mismatch Dimensi & Proses Recovery
**Masalah:** Saat mencoba beralih dari Google Embeddings (768D) ke Cohere Embeddings (1024D), terjadi kesalahan skema karena kolom `embedding` di- *drop* untuk mengubah tipe datanya, yang mengakibatkan hilangnya vektor secara fisik dari *database*. Proses *re-ingestion* sempat terhenti karena API Cohere mengalami *Rate Limit* (1000 *request*/bulan), menyebabkan hilangnya konteks untuk jurnal eksperimen (SciLit).
**Solusi Recovery:** 
1. Mendaftarkan *Cohere API Key* baru yang bersih.
2. Menjalankan kembali skrip `inject_cohere.py` untuk menyuntikkan sisa vektor 1024D secara bertahap dengan jeda 0.5 detik (menghindari 429 Error).
3. Merekonstruksi skrip evaluasi menjadi `evaluate_cohere_full.py` yang sepenuhnya murni menggunakan ekosistem Cohere (Pencarian Vektor Cohere 1024D + LLM `command-r-plus-08-2024`).

### e. A/B Testing & Final Ragas Evaluation
Sebagai pembuktian akademis, Ragas Evaluation akan kembali dijalankan pada Sistem B. Hipotesis utamanya adalah:
- Skor **Context Precision** akan meroket mendekati 1.0 (karena informasi terpenting selalu berada di urutan No. 1 hasil *Vector Search*).
- Skor **Faithfulness** akan semakin stabil karena Chatbot hanya disodorkan 3-5 paragraf paling relevan, menutup ruang bagi LLM untuk berhalusinasi.

Sistem B inilah yang kelak menjadi mesin utama pencarian jurnal di platform Web MySRE.