Tatlong buwan pagkatapos: Nagco-code pa rin, nag-aaral pa rin, naiipit pa rin (minsan)

Update (2026): Ang S&P 500 financial chatbot project ay kalaunan ay na-retire. Bumalik si Sydney at ngayon ay nakatuon sa blog content at mga produkto. Subukan si Sydney →

---

Pinag-debate ko kung isusulat ko pa ang update na ito tungkol sa aking coding journey. Ang progreso ay hindi naman kapansin-pansin o externally visible—kaya bakit pa?

Well, baka magsilbing magandang paalala ito para sa aking kinabukasang sarili na maaaring bumagal ang progreso minsan at ang paglago ay madalas nangyayari sa mga bugso.

Mula noong huling post ko tungkol sa pagbuo ng self-evaluating chatbot noong kalagitnaan ng Abril, nag-dive ako sa ilang kurso:

• React Basics ng Meta sa Coursera
• React Advanced ng Meta sa Coursera
• Django web framework
• The Full Stack

Bakit ang Mga Kursong Ito?

Gusto kong ibahagi ang aking mga personal na karanasan at thought process sa pagpili ng mga kursong ito. Sana makatulong ito sa inyo na nasa (o magiging nasa) katulad na paglalakbay.

Pagiging Mas Magaling sa Pag-instruct sa Machine

Halos 10 buwan na mula noong nagsimula akong mag-code, habang may full time job. (Maaari niyong basahin pa ang Paano Ko Binuo ang Sarili Kong Chatbot nang Walang Coding Experience: Mga Aral na Natutunan na nai-publish noong Okt 2023 dito.)

Siguradong HINDI ko ito magagawa nang walang tulong ng Generative AI (maging chatGPT o Anthropic Claude o Microsoft CoPilot sa Visual Studio Code.) Gayunpaman, habang lalo akong nagco-code, lalo kong nare-realize na bagama't makapangyarihan ang mga foundational models na ito, parang mga intern pa rin sila. Hindi pa sila magaling sa planning o paglutas ng ambiguous na gawain. Kapag mas specific ang ating mga instructions, mas maganda ang output.

Ibig sabihin, kailangan kong maging lalong specific sa aking coding instructions. Pero paano? Sa ngayon, inilalarawan ko ang gusto ko sa natural language. Bagama't gumagana ito sa basic na antas, hindi sapat para sa mas kumplikadong mga gawain.

Pagkatapos ang susunod na lohikal na tanong ay ano ang dapat aralin?

Mag-focus sa Business/User Problems na Sinusubukan Kong Lutasin

Ang aking chatbot (code-named Sydney) para sa website na ito ay (marahil "ay") mabagal. Ang kabagalan ay nangyayari pareho sa:

• Start up time
• At habang nag-uusap

Hindi naka-enable ang streaming, kaya kailangan mag-antay ng mga users ng medyo mahabang panahon para makita ang kumpletong sagot.

Kaya ang layunin ko ay (ay) simple: gawin itong mabilis at responsive.

Ang layunin ko ay simple: gawin itong mabilis at responsive. Pero nang walang mas maraming foundational knowledge, mahirap itong hatiin sa mga manageable na problema para lutasin. Kaya ko nagdesisyong matuto pa tungkol sa scalable, secure, at mabilis na front-end frameworks, back-end frameworks, at ang full stack (kasama ang mga databases).

Ang Mga Karanasan Ko sa React at Django sa Ngayon

• React: Ang React ay medyo mas madaling aralin at i-deploy kumpara sa Django. (Duh!) Ang kasalukuyang chatbot front end ay gumagamit ng React, at natuklasan ko na kaya ni Claude at ChatGPT ang karamihan ng coding tasks nang walang problema. Simple din ang deployment sa production environment gamit ang React, at mukhang mas responsive ang chatbot page habang nag-uusap.
• Django: Ang Django at Django Rest Framework (DRF) ay may mas matarik na learning curve, lalo na sa deployment na may Cloud SQL database at pagtiyak ng seguridad. Ang komprehensibong kalikasan ng Django ay nangangahulugan na ang deployment na may tamang antas ng seguridad ay tumagal ng ilang oras. Gayunpaman, HINDI ko pa rin magawang gumana ang streaming HTML answers sa DRF sa production environment! Bagama't magawa ko ito gamit ang WebSockets, malayo ang approach na iyon mula sa DRF, kaya hindi ko pa ito inampon.

Kaya kung may alam kayong framework o sagot kung paano gagawin ang Langgraph streaming na gumana sa simpleng front end, sabihin niyo sa akin!

Paano Na ang Financial Chatbot na Nabanggit Ko Noong Abril?

Ang magandang balita ay kinagiliwan ng marami sa inyo ang proyektong ito — marami akong natanggap na tanong at komento. Ang masamang balita? Malayo pa ako sa pagkumpleto nito T.T Narito ang dahilan:

1. Pagbabalanse ng retrieval quality, buwanang gastos ng vector store, at gastos ng embedding

Gaya ng nabanggit sa Abr post, ine-evaluate ko ang Weaviate's Serverless Cloud Vector Store. Nagkakahalaga talaga ito ng pera. Para sa proyektong ito, malamang na nakatingin ako sa:

• Data Volume: Mahigit 10 milyon, posibleng 12.5 - 15 milyong data objects.
• Cost Estimate: Na may vector dimension na 512, ang buwanang gastos ay maaaring maging $600 hanggang $750.

Ang halagang ito ay kaya para sa isang kumpanya sa production environment pero maaaring masyadong mahal para sa side project tulad nito. Kaya, kailangan kong maghanap ng mga paraan para ibaba ang gastos.

Base sa kung paano gumagana ang Weaviate pricing, ang dalawang levers ay: pagbawas ng bilang ng data objects o pagbawas ng vector dimension. Pareho ang mga ito ay may iba't ibang tradeoffs.

Mga paraan para bawasan ang data objects

• Aggressive Text Cleaning: Ang pagbawas ng kabuuang text size sa 10K at 10Q filings ay maaaring makatulong, kung isasaalang-alang na may 500 kumpanya tayo sa S&P 500, bawat isa ay may maraming filings sa nakaraang 10 taon. Sa tingin ko, naubos ko na ang opsyon na ito.
• Pagpapalaki ng Chunk Size: Sa pagpapalaki ng chunk size mula 256, hanggang 512 hanggang 1,000 hanggang 2,000 o 3,000, mababawasan ko ang bilang ng data objects ng 2x, 4x o 10x. Gayunpaman, maaari nitong ibaba ang retrieval quality, dahil ang mas malalaking chunks ay hindi gaanong precise.

Mga paraan para bawasan ang vector dimension

Ang pagbawas ng vector dimension ay mukhang direktang nakaugnay sa retrieval quality — kapag mas mababa ang dimension, mas masama ang retrieval quality. Nag-eeksperimento pa rin ako sa iba't ibang embedding models tulad ng OpenAI's "text-embedding-3-small" at "text-embedding-3-large" na may iba't ibang dimensions. Kung may magandang rekomendasyon kayo, ibahagi niyo!

Ang paggamit ng "text-embedding-3-large" model mula sa OpenAI ay nagdadagdag din sa gastos sa embedding phase. Halimbawa, nagkakahalaga ako ng $4.5 para mag-generate ng embeddings para sa 23 kumpanyang 10K/10Q filings sa nakaraang 10 taon na may vector dimension na 1024. Ibig sabihin maaaring magkakahalaga ng $100+ para sa buong S&P 500. (Oo, medyo kuripot ako. Hindi pa ba ninyo alam iyon dati :P ?)

2. Latency sa query translation, structuring, retrieval

Kapag mas elaborate ang query translation at structuring, mas maganda ang search terms / Content search terms na mai-generate natin, na nagreresulta sa mas mataas na kalidad na retrieval. Gayunpaman, nadaragdagan din ang latency.

• Ang query translation ay ang hakbang na hinihiling natin sa model na i-translate ang paunang tanong ng user sa mga sub questions na mas angkop para sa retrieval. Halimbawa, sa orihinal na tanong na "How did Airbnb's operating margin change from 2020 to 2022?" ang model ay maaaring mag-generate ng sub questions tulad ng:

[
"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?"
]

• Ang query structuring ay ang hakbang na hinihiling natin sa model na gawing search query o content search query ang mga tanong para sa retrieval, kasama ang mga relevant na filters. Gamit ang halimbawa sa itaas, para sa tanong 1, maaaring ibalik ng model ang

\{
    "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"
\}

Para sa retrieval, habang mas marami ang mga resultang ibinalik, mas matagal ang kinakailangan para i-process ng model. Ang pagbabalik ng mas kaunting resulta ay nangangahulugan ng mas mabilis na response times pero potensyal na mas mababang kalidad ng mga sagot dahil sa kakulangan ng konteksto.

Pagtatapos

May iba pa akong tinatackle, pero dahil mas mahaba na ang post na ito kaysa inaasahan, dito na muna ako magtatapos.

Nag-aaral ka rin bang mag-code habang nagtatrabaho nang full time? Paano mo dinedecide kung ano ang susunod na aaralin kapag lahat ng bagay ay parehong importante?

Maraming salamat,

Chandler