Tiga bulan kemudian: Masih coding, masih belajar, masih stuck (kadang-kadang)

Update (2026): Proyek chatbot keuangan S&P 500 akhirnya di-retire. Sydney kembali dan sekarang fokus pada konten blog dan produk. Coba Sydney →

---

Saya sudah berdebat apakah perlu menulis update tentang perjalanan coding saya ini. Kemajuannya belum spektakuler atau terlihat dari luar — jadi ngapain repot?

Yah, mungkin postingan ini akan jadi pengingat yang bagus untuk diri saya di masa depan bahwa kemajuan bisa melambat kadang-kadang dan pertumbuhan sering terjadi secara bertahap.

Sejak postingan terakhir saya tentang membangun chatbot self-evaluating di pertengahan April, saya sudah mendalami beberapa kursus:

• React Basics oleh Meta di Coursera
• React Advanced oleh Meta di Coursera
• Django web framework
• The Full Stack

Mengapa Kursus-Kursus Ini?

Saya ingin berbagi pengalaman dan proses berpikir saya di balik memilih kursus-kursus ini. Harapan saya agar ini bisa membantu yang sedang (atau akan) menjalani perjalanan serupa.

Menjadi Lebih Baik dalam Menginstruksi Mesin

Sudah sekitar 10 bulan sejak saya terjun ke coding, sambil punya pekerjaan full time. (Kamu bisa baca lebih lanjut tentang Bagaimana Saya Membangun Chatbot Sendiri Tanpa Pengalaman Coding: Pelajaran yang Dipetik yang dipublikasikan Oktober 2023 di sini.)

Saya pasti TIDAK BISA berhasil tanpa bantuan Generative AI (baik itu chatGPT atau Anthropic Claude atau Microsoft CoPilot di Visual Studio Code.) Namun, semakin banyak saya coding, semakin saya menyadari bahwa meskipun model-model dasar ini powerful, mereka masih seperti intern. Mereka belum bagus dalam perencanaan atau menyelesaikan tugas yang ambigu. Semakin spesifik instruksi kita, semakin baik output-nya.

Itu berarti saya perlu menjadi semakin spesifik dengan instruksi coding saya. Tapi bagaimana? Sejauh ini, saya mendeskripsikan apa yang saya mau dalam bahasa natural. Meskipun ini bekerja di level dasar, ini tidak memadai untuk tugas yang lebih kompleks.

Lalu pertanyaan logis selanjutnya adalah apa yang harus dipelajari?

Fokus pada Masalah Bisnis/Pengguna yang Saya Coba Selesaikan

Chatbot saya (dengan kode nama Sydney) untuk situs ini dulu (mungkin "masih") lambat. Kelambatan terjadi di:

• Waktu startup
• Dan selama percakapan

Streaming tidak diaktifkan, jadi pengguna harus menunggu waktu yang relatif lama untuk melihat jawaban lengkap.

Jadi tujuan saya dulu (dan sekarang) sederhana: buatlah cepat dan responsif.

Tujuan saya sederhana: buatlah cepat dan responsif. Tapi tanpa pengetahuan dasar yang lebih banyak, sulit untuk memecah ini menjadi masalah-masalah yang bisa dikelola. Itulah mengapa saya memutuskan untuk belajar lebih banyak tentang framework front-end yang skalabel, aman, dan cepat, framework back-end, dan full stack (termasuk database).

Pengalaman saya dengan React dan Django sejauh ini

• React: React relatif lebih mudah dipelajari dan di-deploy dibanding Django. (Ya iyalah!) Front end chatbot saat ini menggunakan React, dan saya menemukan bahwa Claude dan ChatGPT bisa menangani sebagian besar tugas coding tanpa masalah. Deployment di lingkungan produksi dengan React juga cukup sederhana, dan halaman chatbot tampak lebih responsif selama percakapan.
• Django: Django dan Django Rest Framework (DRF) memiliki kurva belajar yang lebih curam, terutama dengan deployment yang melibatkan database Cloud SQL dan memastikan keamanan. Sifat Django yang komprehensif berarti deployment dengan level keamanan yang tepat membutuhkan waktu. Namun, saya masih TIDAK BISA membuat streaming HTML berfungsi dengan DRF di lingkungan produksi! Meskipun saya bisa membuatnya berjalan menggunakan WebSockets, pendekatan itu menyimpang terlalu jauh dari DRF, jadi saya belum mengadopsinya.

Jadi kalau kamu tahu framework atau solusi bagaimana membuat streaming Langgraph berfungsi dengan front end sederhana, beri tahu saya!

Bagaimana dengan Chatbot Keuangan yang Saya Sebut di April?

Kabar baiknya adalah proyek ini telah menarik minat banyak dari kamu — saya menerima banyak pertanyaan dan komentar. Kabar buruknya? Saya masih jauh dari menyelesaikannya T.T Ini alasannya:

1. Menyeimbangkan kualitas retrieval, biaya bulanan vector store, dan biaya embedding

Seperti disebutkan di postingan April, saya sedang mengevaluasi Serverless Cloud Vector Store dari Weaviate. Ini memang membutuhkan uang sungguhan. Untuk proyek ini, saya kemungkinan melihat:

• Volume Data: Lebih dari 10 juta, mungkin 12,5 - 15 juta objek data.
• Estimasi Biaya: Dengan dimensi vektor 512, biaya bulanan bisa berkisar antara $600 hingga $750.

Jumlah ini bisa dikelola untuk perusahaan di lingkungan produksi tapi mungkin terlalu mahal untuk proyek sampingan seperti ini. Jadi, saya perlu mencari cara untuk menurunkan biayanya.

Berdasarkan cara kerja harga Weaviate, dua tuas utamanya adalah: mengurangi jumlah objek data atau mengurangi dimensi vektor. Keduanya datang dengan tradeoff yang berbeda.

Cara mengurangi objek data

• Pembersihan Teks Agresif: Mengurangi ukuran teks keseluruhan dalam filing 10K dan 10Q bisa membantu, mengingat kita berurusan dengan 500 perusahaan di S&P 500, masing-masing dengan beberapa filing selama 10 tahun terakhir. Saya rasa saya sudah menghabiskan opsi ini.
• Memperbesar Ukuran Chunk: Dengan memperbesar ukuran chunk dari 256, ke 512 ke 1.000 ke 2.000 atau 3.000, saya bisa mengurangi jumlah objek data sebanyak 2x, 4x atau 10x. Namun, ini bisa menurunkan kualitas retrieval, karena chunk yang lebih besar cenderung kurang presisi.

Cara mengurangi dimensi vektor

Mengurangi dimensi vektor tampaknya berkorelasi langsung dengan kualitas retrieval — semakin rendah dimensinya, semakin buruk kualitas retrieval-nya. Saya masih bereksperimen dengan model embedding yang berbeda seperti "text-embedding-3-small" dan "text-embedding-3-large" dari OpenAI dengan berbagai dimensi. Kalau kamu punya rekomendasi bagus, tolong bagikan!

Menggunakan model "text-embedding-3-large" dari OpenAI juga menambah biaya selama fase embedding. Misalnya, saya menghabiskan $4,5 untuk menghasilkan embedding untuk filing 10K/10Q 23 perusahaan selama 10 tahun terakhir dengan dimensi vektor 1024. Ini berarti bisa menghabiskan sekitar $100+ untuk seluruh S&P 500. (Ya, saya agak pelit. Belum tahu sebelumnya ya? :P)

2. Latensi selama query translation, structuring, retrieval

Semakin rumit query translation dan structuring, semakin baik istilah pencarian/Content search yang bisa kita hasilkan, menghasilkan retrieval berkualitas lebih tinggi. Namun, ini juga meningkatkan latensi.

• Query translation adalah langkah di mana kita meminta model untuk menerjemahkan pertanyaan awal pengguna menjadi sub-pertanyaan yang lebih baik untuk retrieval. Misalnya, dengan pertanyaan asli "Bagaimana operating margin Airbnb berubah dari 2020 ke 2022?" model bisa menghasilkan sub-pertanyaan seperti:

[
"What was Airbnb's operating margin in the 10-K filing for the year 2020?",
"What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"What was Airbnb's operating margin in the 10-K filing for the year 2022?"
]

• Query structuring adalah langkah di mana kita meminta model untuk mengubah pertanyaan-pertanyaan ini menjadi search query atau content search query untuk retrieval, bersama dengan filter yang relevan. Menggunakan contoh di atas, untuk pertanyaan 1, model mungkin mengembalikan

\{
    "content_search": "What was Airbnb's operating margin in the 10-K filing for the year 2021?",
    "company_conformed_name": "Airbnb, Inc.",
    "form_type": "10-K",
    "conformed_period_of_report": "2021-12-31"
\}

Untuk retrieval, semakin banyak hasil yang kita kembalikan, semakin lama waktu yang dibutuhkan model untuk memproses. Mengembalikan lebih sedikit hasil berarti waktu respons lebih cepat tapi jawaban berpotensi lebih rendah kualitasnya karena kurangnya konteks.

Penutup

Ada lebih banyak yang saya kerjakan, tapi karena postingan ini sudah lebih panjang dari yang diharapkan, saya akan menutupnya di sini.

Apakah kamu juga belajar coding sambil bekerja full time? Bagaimana kamu memutuskan apa yang harus dipelajari selanjutnya ketika semuanya terasa sama pentingnya?

Salam,

Chandler