Na-launch na ang S&P500 Agent MVP: Sumasagot ng mga Financial Questions na Naka-ground sa SEC Data

Update (2026): Ang S&P 500 Agent ay na-retire na. Ang post na ito ay nagdodokumento ng orihinal na MVP launch para sa historical purposes. Si Sydney ngayon ay nakatuon sa blog content at mga produkto ni Chandler. Subukan ang kasalukuyang Sydney →

---

Kumusta,

Masaya akong ibahagi na mula noong huling post ko tungkol sa aking pakikibaka sa pagtatrabaho sa S&P500 Agent, handa na ang MVP version! :D Hayaan niyong i-walk through ko kayo sa kung ano ang kayang gawin ng minimum viable product na ito at kung paano ito nagkabuo.

Ano ang Kayang Gawin ng MVP na Ito?

1. Sumisid sa Isang Dekada ng Data: Ang database ng agent ay kasama ang huling 10 taon ng company facts na isinumite sa SEC EDGAR. Maganda, di ba?
2. Maaasahang mga Sagot: Dahil naka-ground ito gamit ang aktwal na facts na isinumite sa SEC, mapagkakatiwalaan mo ang kalidad ng mga sagot.
3. Fact-Check Friendly: Palaging may kasamang reference data ang agent sa kanyang final answer. Kaya kung skeptical ka, maaari mo itong suriin mismo!
4. Kaya ang Mahihirap na Tanong: Kaya nitong harapin ang semi-complex na queries tulad ng "Compare the revenue of Apple and Microsoft between 2020 - 2022?" o "How did Microsoft's operating margin change from 2020 to 2022?" Bakit semi-complex ang mga ito? Well, kailangan ng agent na "mag-reason" at hatiin ang mga malawak na tanong na ito sa mas maliliit, maghanap ng info mula sa database, at pagkatapos ay pagsamahin ang lahat.
   • Halimbawa, para masagot ang unang tanong, kailangan malaman ng agent ang indibidwal na kita ng kumpanya para sa bawat taon 2020, 2021 at 2022 at pagkatapos ay gawin ang paghahambing.
5. Naka-update (Halos): Ang cut-off date ay Agosto 2024. Anumang isinumite sa SEC pagkatapos noon ay wala sa MVP version na ito.
6. HTML streaming: Gumagana na ang streaming! Yay! :D Sa lumabas, natively sinusuportahan ng DRF at React ang streaming, kaya sa langgraph, mayroon na tayong responsive conversation flow, na ipinapakita sa madaling basahing format. Matagal na akong nahirapan sa html streaming.

Isang Sulyap sa Loob

Kung nagbabasa ka pa rin sa puntong ito, malamang gusto mong malaman pa tungkol sa kung paano ko binuo ang MVP na ito at nalampasan ang ilan sa mga hamong nabanggit ko dati. Kaya, maging medyo technical tayo!

1. Na-slim Down na Data: Sa halip na gumamit ng buong 10-K o 10-Q reports, ginagamit ko ang "Facts" na isinumite sa SEC. Ibig sabihin ang database natin ay mas maliit nang malaki - wala pang 2GB! Sa ibaba ang ilang halimbawa ng mga isinumite mula sa mga public companies sa 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"

Ibig sabihin din nito na hindi ko kailangan ng malaking scale, mabilis na vector store, na napakamahal (sa hanay ng $600 - $700/buwan)

2. Cloud SQL postgreSQL bilang pangunahing database: Ginagamit ko ang Cloud SQL PostgreSQL bilang pangunahing database. Dahil gumagamit na ako ng Cloud Run CI/CD mula sa GCP, may katuturan na manatili sa mga alok ng Google. Ito ay bagong konsepto sa akin kaya kailangan kong matuto kung paano gumawa ng database migration mula local patungo sa cloud at pagkatapos kung paano i-configure ang backend para gumana sa Cloud SQL database gamit ang private IP. Nakatulong ang dokumentasyon mula sa GCP.

3. React Kasama ang Django: Ito ang unang beses kong matagumpay na nai-deploy ang parehong React frontend at Django Rest Framework (DRF) backend na may Cloud SQL database. Naging paglalakbay ng pagsubok at pagkakamali ito, pero malaking tulong ang ChatGPT's o1-preview at Anthropic Claude 3.5 Sonnet. Talagang makapangyarihan sila, lalo na kapag binibigyan mo ng sapat na konteksto ng problemang nilulutas mo.

4. Matalinong Agent: Ang agent ay binuo gamit ang Langgraph. May dalawa itong pangunahing tools: Google Search at isang Financial Question Answering tool. Siya ang nagdedesisyon kung alin ang gagamitin base sa tanong mo.

5. Paano nage-generate ang mga SQL queries?

Hindi straightforward ang pag-convert ng generic/malawak na tanong ng user sa angkop na SQL queries, na akma para sa database. Isa sa mga pangunahing dahilan ay dahil kapag ang mga kumpanya ay nagsusumite ng financial facts sa SEC, gumagamit sila ng financial concepts/terminologies na hindi intuitive sa ordinaryong tao.

Halimbawa, ang "revenue" ay maaaring i-represent ng maraming facts tulad ng:

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

At sa iba't ibang kumpanya, maaari nilang piliin na gumamit ng iba't ibang labels para sa parehong konsepto. Halimbawa, ginagamit ng Apple ang "Revenue from Contract with Customer, Excluding Assessed Tax" vs ginagamit ng Tesla ang "Revenue".

O kapag nagtatanong ka ng "operating margin", iyon ay maaaring hindi fact na isinusumite ng kumpanya sa SEC. Sa halip, nagsusumite sila ng total revenue at Operating Income (Loss).

Isa pang sitwasyon ay kapag nagpalitan ng pangalan ang mga kumpanya sa paglipas ng panahon kaya kailangan mong tiyakin na ang mga SQL queries ay kasama pareho ang lumang pangalan at bagong pangalan.

Kaya paano ko tinuturuan ang machine na pumili ng tamang fact/label para sa isang partikular na malawak na tanong?

Gumagamit ako ng hybrid search sa Weaviate para mahanap ang mga pinakanauugnay na facts o labels at ibalik ang mga ito sa LLM model.

6. Mahalaga ang Break Down Testing

Bago ang final deployment sa production, binagsak ko ang proseso sa mga hakbang at sinubukan ang bawat isa:

1. Local test ng DRF backend na may local database.

2. Docker container backend test na may local database.

3. Paglipat ng PostgreSQL database sa Cloud SQL at pag-test nito.

4. Docker container backend test na may Cloud SQL.

5. React front end local test.

6. React front end na may production backend at Cloud SQL.

7. Paglipat ng React front end sa Wordpress sa production.

8. End-to-end testing.

Kailangan kong matutunan ang step-by-step approach na ito sa mahirap na paraan. Sa simula, nilaktawan ko ang ilang hakbang at sinubukan sa mas malalaking chunks, pero hindi matukoy ng mga language models (LLM) kung saan eksaktong nagkamali.

Ano ang Susunod?

1. I-fix ang cold start problem: Sa ngayon, tumatagal ng kaunti bago masagot ng agent ang unang tanong. Nagtatrabaho ako sa isang cost-effective na solusyon.
2. Ipakita ang mga interim steps sa mga users: Habang sumasagot ng mga kumplikadong tanong tulad ng "Compare the revenue of Apple and Microsoft between 2020 and 2022," tumatagal bago ma-generate ng agent ang final answer. Ang pagpapakita ng mga hakbang na pinagtatrabahuhan ng agent sa real-time ay maaaring magpaganda ng user experience.
3. I-enrich ng 10-K/10-Q text content: Plano kong magsama ng mas maraming relevant na textual content mula sa 10-K at 10-Q filings para magbigay ng mas detalyadong mga sagot.

Iyon na muna sa akin. Subukan ang MVP version at sabihin sa akin kung ano ang tingin niyo! Sinubukan niyo na bang bumuo ng kahit ano gamit ang financial data o SEC filings? Gusto kong marinig ang inyong karanasan — mag-drop ng komento sa ibaba o mag-email sa akin nang direkta (chandler@chandlernguyen.com).

Maraming salamat,

Chandler