Agent S&P500 MVP Diluncurkan: Menjawab Pertanyaan Keuangan Berdasarkan Data SEC

Update (2026): Agent S&P 500 telah di-retire. Postingan ini mendokumentasikan peluncuran MVP asli untuk tujuan historis. Sydney sekarang fokus pada konten blog dan produk Chandler. Coba Sydney saat ini →

---

Hai,

Saya senang berbagi bahwa sejak postingan terakhir tentang perjuangan saya mengerjakan Agent S&P500, versi MVP sudah siap! :D Biarkan saya memandu kamu melalui apa yang bisa dilakukan minimum viable product ini dan bagaimana ia tercipta.

Apa yang Bisa Dilakukan MVP Ini?

1. Mendalami Satu Dekade Data: Database agent ini mencakup 10 tahun terakhir fakta perusahaan yang diajukan ke SEC EDGAR. Keren kan?
2. Jawaban yang Andal: Karena di-ground menggunakan fakta aktual yang diajukan ke SEC, kamu bisa mempercayai kualitas jawabannya.
3. Mudah untuk Fact-Check: Agent selalu menyertakan data referensi dalam jawaban akhirnya. Jadi kalau kamu merasa skeptis, kamu bisa memeriksanya sendiri!
4. Menangani Pertanyaan Rumit: Ia bisa menangani query semi-kompleks seperti "Bandingkan pendapatan Apple dan Microsoft antara 2020 - 2022?" atau "Bagaimana operating margin Microsoft berubah dari 2020 ke 2022?" Mengapa ini semi-kompleks? Nah, agent perlu "bernalar" dan memecah pertanyaan luas ini menjadi yang lebih kecil, mencari info dari database, dan kemudian menyatukannya.
   • Misalnya, untuk menjawab pertanyaan pertama, agent perlu mengetahui pendapatan individual perusahaan untuk setiap tahun 2020, 2021 dan 2022 dan kemudian melakukan perbandingan.
5. Terkini (Hampir): Tanggal cut-off adalah Agustus 2024. Apa pun yang diajukan ke SEC setelah itu tidak ada dalam versi MVP ini.
6. HTML streaming: Streaming berfungsi! Hore! :D Ternyata, DRF dan React secara native mendukung streaming, jadi dengan langgraph, kita punya alur percakapan yang responsif, ditampilkan dalam format yang mudah dibaca. Saya sudah berjuang dengan html streaming cukup lama.

Mengintip di Balik Layar

Kalau kamu masih membaca sampai sini, kamu mungkin ingin tahu lebih banyak tentang bagaimana saya membangun MVP ini dan mengatasi beberapa tantangan yang saya sebutkan sebelumnya. Jadi, mari kita sedikit teknis!

1. Data yang Diramping: Alih-alih menggunakan laporan 10-K atau 10-Q lengkap, saya menggunakan "Facts" yang diajukan ke SEC. Ini berarti database kita secara signifikan lebih kecil - kurang dari 2GB! Di bawah ini beberapa contoh apa yang diajukan perusahaan publik ke SEC:

  "AccruedRoyaltiesCurrent": \{
    "label": "Accrued Royalties, Current"
  \},
  "AccumulatedDepreciationDepletionAndAmortizationPropertyPlantAndEquipment": \{
    "label": "Accumulated Depreciation, Depletion and Amortization, Property, Plant, and Equipment"
  \},
  "AccumulatedOtherComprehensiveIncomeLossNetOfTax": \{
    "label": "Accumulated Other Comprehensive Income (Loss), Net of Tax"
  \},
  "AccumulatedOtherComprehensiveIncomeLossOtherThanTemporaryImpairmentNotCreditLossNetOfTaxAvailableforsaleDebtSecurities": \{
    "label": "Accumulated Other Comprehensive Income (Loss), Other than Temporary Impairment, Not Credit Loss, Net of Tax, Available-for-sale, Debt Securities"
  \},
  "AdditionalPaidInCapitalCommonStock": {
    "label": "Additional Paid in Capital, Common Stock"

Ini juga berarti saya tidak perlu menggunakan vector store berskala besar yang cepat, yang sangat mahal (di kisaran $600 - $700/bulan)

2. Cloud SQL PostgreSQL sebagai database utama: Saya menggunakan Cloud SQL PostgreSQL sebagai database utama. Karena saya sudah menggunakan Cloud Run CI/CD dari GCP, masuk akal untuk tetap menggunakan layanan Google. Ini konsep baru bagi saya jadi saya harus belajar cara melakukan migrasi database dari lokal ke cloud dan kemudian cara mengkonfigurasi backend untuk bekerja dengan database Cloud SQL menggunakan IP privat. Dokumentasi dari GCP sangat membantu.

3. React Bertemu Django: Ini adalah pertama kalinya saya berhasil men-deploy frontend React dan backend Django Rest Framework (DRF) dengan database Cloud SQL. Ini perjalanan trial and error, tapi o1-preview dari ChatGPT dan Claude 3.5 Sonnet dari Anthropic sangat membantu. Mereka memang sangat powerful, terutama ketika kamu memberinya konteks yang cukup tentang masalah yang kamu selesaikan.

4. Agent Cerdas: Agent ini dibangun menggunakan Langgraph. Ia punya dua tool utama: Google Search dan tool Financial Question Answering. Ia memutuskan mana yang digunakan berdasarkan pertanyaanmu.

5. Bagaimana query SQL dihasilkan?

Tidak mudah mengubah pertanyaan pengguna yang generik/luas menjadi query SQL yang sesuai, cocok untuk database. Salah satu alasan utamanya adalah karena ketika perusahaan mengajukan fakta keuangan ke SEC, mereka menggunakan konsep/terminologi keuangan yang tidak intuitif bagi orang biasa.

Misalnya, "revenue" bisa diwakili oleh beberapa fakta seperti:

• Revenue
• Revenue from Contract with Customer, Excluding Assessed Tax
• Revenue from related Parties
• Deferred Revenue
• dll...

Dan di seluruh perusahaan, mereka bisa memilih untuk menggunakan label yang berbeda untuk konsep yang sama. Misalnya, Apple menggunakan "Revenue from Contract with Customer, Excluding Assessed Tax" vs Tesla menggunakan "Revenue".

Atau ketika kamu bertanya tentang "operating margin", itu mungkin bukan fakta yang diajukan perusahaan ke SEC. Sebaliknya, mereka mengajukan total revenue dan Operating Income (Loss).

Situasi lain adalah ketika perusahaan mengubah nama mereka seiring waktu jadi kamu perlu memastikan query SQL mencakup nama lama dan nama baru.

Jadi bagaimana saya menginstruksi mesin untuk memilih fakta/label yang tepat untuk pertanyaan luas tertentu?

Saya menggunakan hybrid search dengan Weaviate untuk menemukan fakta atau label yang paling relevan dan mengirimkannya kembali ke model LLM.

6. Break Down Testing Adalah Kunci

Sebelum deployment akhir ke produksi, saya memecah proses menjadi langkah-langkah dan menguji masing-masing:

1. Tes lokal backend DRF dengan database lokal.

2. Tes backend Docker container dengan database lokal.

3. Migrasi database PostgreSQL ke Cloud SQL dan mengujinya.

4. Tes backend Docker container dengan Cloud SQL.

5. Tes lokal front end React.

6. Front end React dengan backend produksi dan Cloud SQL.

7. Migrasi front end React ke Wordpress di produksi.

8. Pengujian end-to-end.

Saya harus belajar pendekatan langkah demi langkah ini dengan cara yang sulit. Awalnya, saya melewatkan beberapa langkah dan menguji dalam chunk yang lebih besar, tapi language model (LLM) tidak bisa menunjukkan dengan tepat di mana masalahnya.

Apa selanjutnya?

1. Perbaiki masalah cold start: Saat ini, butuh sedikit waktu bagi agent untuk menjawab pertanyaan pertama. Saya sedang mengerjakan solusi yang hemat biaya.
2. Tunjukkan langkah interim ke pengguna: Saat menjawab pertanyaan kompleks seperti "Bandingkan pendapatan Apple dan Microsoft antara 2020 dan 2022," butuh waktu bagi agent untuk menghasilkan jawaban akhir. Menunjukkan langkah-langkah yang sedang dikerjakan agent secara real-time mungkin meningkatkan pengalaman pengguna.
3. Perkaya dengan konten teks 10-K/10-Q: Saya berencana menyertakan lebih banyak konten tekstual yang relevan dari filing 10-K dan 10-Q untuk memberikan jawaban yang lebih detail.

Itu saja dari saya untuk saat ini. Coba versi MVP dan beri tahu saya pendapatmu! Pernahkah kamu mencoba membangun sesuatu dengan data keuangan atau filing SEC? Saya ingin mendengar pengalamanmu — tinggalkan komentar di bawah atau email saya langsung (chandler@chandlernguyen.com).

Salam,

Chandler