# 📊 Evaluasi Performa Chat Stream iRCFA *Analisis Kinerja & Kepatuhan Format Model PLN-RCFA-30B* --- ````carousel # 📋 Slide 1: Ringkasan Eksekutif & Skenario Uji ### **Latar Belakang Pengujian** Pengujian dilakukan untuk mengukur performa, stabilitas, dan kepatuhan format model chat stream iRCFA baru yang memproses logika Root Cause Failure Analysis (RCFA) 7-Tahap. ### **Detail Skenario** * **Equipment Target:** `HP FEEDWATER HEATER NO.5` (Location Tag: `3FW-H050`) * **Sensor Utama:** `DELTA FEED WATER FLOW` * **Metode Uji:** Simulasi percakapan multi-turn (8 Pertanyaan Sekuensial) * **API Route:** `/stream_create` (generator streaming langsung ke database lokal) > [!NOTE] > Pengujian menyimulasikan seluruh alur analisis gangguan mulai dari kondisi awal, pembacaan historis sensor, pencarian failure mode, verifikasi root cause, perumusan mitigasi CAPA, hingga estimasi konsekuensi terburuk. # ⚡ Slide 2: Key Performance Indicators (KPI) Metrik performa kunci yang berhasil direkam selama simulasi percakapan 8-turn: | Parameter Kunci | Hasil Pengukuran | Deskripsi | | :--- | :--- | :--- | | **Total Latensi Alur** | **310.11 Detik** (~5.17 Menit) | Durasi total untuk menyelesaikan 8 turn | | **Rata-rata Latensi / Turn** | **38.76 Detik** | Waktu pemrosesan rata-rata per pertanyaan | | **Rata-rata TTFT** | **8.40 Detik** | *Time to First Token* (respons awal mulai streaming) | | **Total Tokens Terpakai** | **7,808 Tokens** | Total token prompt + response di seluruh percakapan | | **Rata-rata Output Tokens** | **966.6 Tokens / Turn** | Rata-rata panjang respons yang dihasilkan model | > [!TIP] > Rata-rata TTFT sebesar **8.40s** dinilai sangat baik untuk model 30B lokal, memberikan umpan balik visual yang cepat kepada pengguna saat pertama kali menanyakan status. # 📈 Slide 3: Performa Turn-by-Turn Detail performa per pertanyaan dari total 8 pertanyaan sekuensial yang diujikan: | Turn | Topik Pertanyaan | TTFT (s) | Latensi (s) | Tokens (P/R) | Fase Akhir | Export Button | | :---: | :--- | :---: | :---: | :---: | :--- | :---: | | **1** | Kondisi HP Feedwater No.5 saat ini? | 3.23 | 49.22 | 8 / 2126 | 3. Potential Root Causes | ❌ | | **2** | Kondisi sensor 7 hari yang lalu? | 4.85 | 83.13 | 9 / 2294 | 3. Potential Root Causes | ✅ | | **3** | Kenaikan Delta Flow -> Failure Mode? | 10.42 | 31.06 | 14 / 649 | 3. Potential Root Causes | ✅ | | **4** | Penyebab dari failure mode? | 8.52 | 35.43 | 6 / 888 | 3. Potential Root Causes | ✅ | | **5** | Tindakan untuk memastikan penyebab? | 9.21 | 24.55 | 9 / 421 | 6. CAPA (Containment) | ✅ | | **6** | Langkah mitigasi permasalahan? | 9.88 | 27.10 | 7 / 436 | 6. CAPA (Containment) | ✅ | | **7** | Langkah yang ekonomis & feasible? | 10.44 | 33.52 | 10 / 490 | 6. CAPA (Containment) | ✅ | | **8** | Konsekuensi jika tidak ada mitigasi? | 10.68 | 26.10 | 12 / 429 | 6. CAPA (Containment) | ✅ | > [!WARNING] > Turn 2 memiliki latensi tertinggi (**83.13s**) karena menghasilkan data tabel sensor historis yang sangat detail untuk 7 hari ke belakang (mencakup 8 jenis sensor berbeda). # 🔗 Slide 4: Alur Transisi Fase RCFA Model secara dinamis mengubah fase analisisnya (event phase) dari pencarian parameter fisik awal hingga CAPA: ```mermaid graph TD Start((Mulai Chat)) --> Turn1[Turn 1: Get Current Reliability] Turn1 --> Phase1["Fase 1: Failure Prediction"] Phase1 --> Phase2["Fase 2: Sensor Data Mapping"] Phase2 --> Phase3["Fase 3: Potential Root Causes & Physical Parameters"] Turn2[Turn 2: Sensor Historis 7 Hari] --> Phase3 Turn3[Turn 3: Failure Mode Delta Flow] --> Phase3 Turn4[Turn 4: Analisis Penyebab / Causes] --> Phase3 Turn5[Turn 5: Verifikasi & Tindakan] --> Phase6["Fase 6: CAPA"] Turn6[Turn 6: Mitigasi Masalah] --> Phase6 Turn7[Turn 7: Feasibility & Ekonomi] --> Phase6 Turn8[Turn 8: Risiko Tanpa Mitigasi] --> Phase6 Phase6 --> End((Selesai Analisis)) style Phase3 fill:#f9f,stroke:#333,stroke-width:2px style Phase6 fill:#bbf,stroke:#333,stroke-width:2px ``` > [!NOTE] > Transisi fase berjalan konsisten dengan model yang mendeteksi perubahan konteks dari identifikasi masalah (Fase 3) ke perumusan aksi pencegahan/CAPA (Fase 6). # 🛡️ Slide 5: Kepatuhan Format & Aturan Bisnis Evaluasi kepatuhan respons model terhadap standar tampilan UI & Aturan PLN: ### **1. Kepatuhan Bahasa & Istilah Teknis** * **Bahasa Utama:** Bahasa Indonesia formal dan profesional. * **Istilah Teknis Bahasa Inggris (Preserved):** Model mempertahankan istilah industri asli seperti *Leakage*, *Valve Malfunction*, *Containment*, *Corrective*, *Preventive*, *MTBF*, dan *MTTR* tanpa memaksakan terjemahan harfiah. ### **2. Kehadiran Tombol Aksi** * `` berhasil disisipkan secara konsisten mulai dari **Turn 2 hingga Turn 8**. * Ini memastikan user dapat mengekspor laporan analisis kapan saja setelah data historis terkumpul. ### **3. Kepatuhan GFM Markdown Tables** * **Temuan Khusus:** Script mencatat `has_html_tables: true` untuk semua respons. * **Hasil Investigasi:** Ini adalah *false-positive* dari validator karena model menuliskan pemikiran sistemnya di dalam blok `` (membahas aturan *"tidak boleh menggunakan tag ``"* sehingga kata kunci `
` ikut terdeteksi). * **Verifikasi Visual:** Output Markdown aktual ke pengguna 100% menggunakan GFM Table standar (`|` dan `-`) dan sepenuhnya bebas dari tag HTML table sesungguhnya serta bebas dari tag `
` yang dilarang. # 💡 Slide 6: Rekomendasi & Langkah Optimasi Untuk meningkatkan performa chat stream iRCFA ke depan, direkomendasikan langkah-langkah berikut: ```mermaid mindmap root((Optimasi iRCFA)) 1. Latensi & Streaming Optimasi TTFT di bawah 5 detik untuk semua turn Caching data sensor historis yang berat 2. Blok Pemikiran Memisahkan blok pemikiran /think sebelum pemrosesan parser kepatuhan format 3. Fase RCFA Penyempurnaan transisi otomatis hingga Fase 7 / Laporan Akhir ``` 1. **Caching Data Sensor:** Karena Turn 2 (sensor historis) memakan waktu 83.13 detik, disarankan menerapkan mekanisme caching data sensor mentah atau pagination waktu. 2. **Peningkatan Parser Kepatuhan:** Ubah fungsi validasi format agar membuang tag `...` terlebih dahulu sebelum melakukan scanning tag HTML table, sehingga menghindari deteksi false-positive. 3. **Penyelarasan Prompt Tahap Akhir:** Tambahkan panduan tegas agar model secara eksplisit melangkah ke Fase 7 (*Output Laporan*) pada turn terakhir. ````