Lanjut ke konten
Samkarsa Logbook

Ketik untuk mencari…

↑↓untuk navigasi
Esc

v1.0.0-010 : [DONE] Plan Optimasi Parsing & Jurnal Mandiri

Rencana perbaikan komprehensif untuk mengatasi halusinasi OCR, mempercepat latensi parsing (NLP), dan mengotomatisasi jurnal mandiri (QRIS/Transfer).

Jualan,Blonjo,Sajen3mnt baca

Mempercepat proses parsing transaksi (NLP) dengan menghapus pengiriman konteks COA (Chart of Accounts) yang berlebihan ke LLM, serta mengoptimalkan sistem agar sepenuhnya mengandalkan pembentukan jurnal mandiri (berbasis aturan/heuristik) di backend Sajen, tanpa membebani LLM.

[!IMPORTANT] Penghapusan injeksi COA ke LLM berarti LLM tidak akan pernah lagi mencoba menebak kode akun spesifik. LLM hanya akan mengkategorikan transaksi secara umum (contoh: sales, purchase, expense) dan mendeteksi metode pembayaran (cash, tempo). Pembentukan jurnal (Debit/Kredit) akan 100% diambil alih oleh backend sajen. Mohon konfirmasi apakah Anda setuju dengan pendekatan ini.

Kita akan menghapus logika fallback di mcp-server/src/index.ts yang memaksa pengambilan seluruh baris COA dari database jika coaContext kosong. Ini akan memangkas ukuran prompt secara drastis (menghemat ribuan token) sehingga respons LLM menjadi jauh lebih cepat.

Kita akan menghapus sama sekali pengiriman coa string dari accounting.py ke MCP, sehingga payload menjadi sangat ringan. LLM hanya akan menerima teks dari user, tanggal hari ini, dan riwayat transaksi (jika ada).

Saat meninjau kode untuk transaksi transfer/QRIS dan operasional, ditemukan bug pada get_auto_journal_entries di accounting.py:

  1. QRIS/Transfer pada Penjualan: Saat ini, pengalihan (redirect) Kas (1-1101) ke Bank (1-1102) hanya terjadi jika line.side == "credit" (yaitu saat uang keluar/pembelian). Jika pelanggan membayar via QRIS (uang masuk / debit), sistem gagal mengalihkannya dan tetap mencatatnya sebagai Kas Tunai. Kita harus menghapus batasan line.side == "credit".
  2. Beban Operasional: Saat ini semua pengeluaran operasional (semua akun berawalan 6-) secara keliru di-override paksa menjadi Beban Listrik, Air & Internet (6-1301). Kita harus memperbaiki logikanya agar AI Parser dapat mendeteksi kategori spesifik beban.

Untuk melacak perkembangan performa aplikasi ke depannya, berikut adalah rincian metrik waktu proses OCR (end-to-end latency) berdasarkan arsitektur v1.0.0-010:

  1. Upload File & Penjadwalan Task (Sajen API): ~50 - 100 ms
    • Gambar diterima dari frontend dan disimpan ke media penyimpanan lokal. Celery Worker dipicu. Sangat cepat.
  2. Fase 1: Pre-processing & Visual Matching (OpenCV): ~100 - 300 ms
    • Menghitung Hash gambar dan pencocokan dengan database template MCP. Sangat cepat karena berjalan di lokal jaringan (backend & MCP).
  3. Fase 2: AI Vision Inference (BOTTLENECK UTAMA): ~6.000 - 13.000 ms (6 - 13 detik)
    • Network Latency (~1-3 detik): Mengirim payload gambar beresolusi tinggi (2-5 MB) dari MCP ke eksternal API (Google Gemini).
    • LLM Processing (~5-10 detik): Waktu tunggu (inference) Gemini membaca gambar, mengenali tabel, dan mengekstrak teks. Semakin banyak item, semakin lama.
  4. Fase 3: Strukturisasi JSON LLM Text (BOTTLENECK KEDUA): ~0 ms ATAU ~2.000 - 5.000 ms
    • Jika Gemini Vision gagal memformat JSON dengan benar (misal: memberikan kalimat pembuka), pipeline akan memanggil Gemini Text sekali lagi untuk merapikan teks mentah menjadi JSON terstruktur.
    • (Note: Lewat optimasi v010 ini, Fase 3 hampir sepenuhnya di-bypass karena LLM Vision langsung memberikan JSON yang valid).
  5. Database Save & Return: ~50 ms
    • Menyimpan hasil JSON ke database dan membalas status COMPLETED ke frontend.

Total Estimasi Waktu Proses OCR (End-to-End):

  • Skenario Terbaik (Fase 3 di-bypass, koneksi cepat): ~6,2 Detik
  • Skenario Terburuk (Fase 3 terpanggil, koneksi padat): ~15 - 18 Detik

Catatan: Parameter waktu ini akan digunakan sebagai perbandingan (baseline) untuk mengukur seberapa efisien optimasi-optimasi (seperti kompresi gambar otomatis atau dynamic bounding box OpenCV) yang akan kita implementasikan di versi-versi mendatang.