三個月後：仲喺寫code，仲喺學嘢，仲係（有時）卡住

更新（2026年）： S&P 500金融chatbot項目最終retired。Sydney返咗嚟，而家專注於blog內容同產品。試Sydney →

---

我一直喺debate應唔應該寫呢個關於我coding旅程嘅update。進度唔算flashy或者externally visible——咁點解要寫？

Well，可能呢篇文會serve as一個好嘅reminder俾未來嘅自己——進度有時會slow down，成長往往係burst式嘅。

自從我4月中關於build self-evaluating chatbot嘅上一篇文以嚟，我上咗幾個courses：

• React Basics by Meta on Coursera
• React Advanced by Meta on Coursera
• Django web framework
• The Full Stack

點解揀呢啲courses？

我想分享我揀呢啲courses背後嘅個人經驗同思考過程。我希望呢個可以幫到你哋中走緊（或者將會走）類似旅程嘅人。

變得更擅長指示機器

由我開始接觸coding到而家已經大約10個月，同時仲有full time工作。（你可以閱讀更多關於我點樣由零coding經驗build自己嘅Chatbot：Lessons Learned，2023年10月發佈。）

冇Generative AI嘅幫助我absolutely做唔到（無論係chatGPT定Anthropic Claude定Microsoft CoPilot in Visual Studio Code。）但越寫越多code，我越意識到雖然呢啲foundational models powerful，佢哋仲係好似intern。佢哋未擅長planning或解決ambiguous tasks。我哋嘅instructions越specific，output就越好。

即係話我需要越嚟越specific咁俾coding instructions。但點做？到目前為止，我一直用自然語言describe我想要嘅嘢。雖然喺basic level有用，但對more complex tasks就唔夠。

咁下一個logical question就係學乜？

Focus喺我想解決嘅商業/用戶問題

我嘅chatbot（代號Sydney）喺呢個網站上面好慢（可能「係」好慢）。慢嘅情況出現喺：

• Start up time
• 同對話過程中

冇enable streaming，所以用戶要等相對長嘅時間先見到完整答案。

所以我嘅目標好簡單：令佢快同responsive。

我嘅目標好簡單：令佢快同responsive。但冇更多foundational knowledge，好難將呢個break down成manageable problems嚟solve。所以我決定學多啲關於scalable、secure同快嘅front-end frameworks、back-end frameworks同full stack（包括databases）。

我對React同Django嘅經驗

• React：React比Django相對容易學同deploy。（廢話！）而家嘅chatbot front end用React，我發現Claude同ChatGPT可以handle大部分coding tasks without issues。用React喺production environment deploy都幾simple，chatbot頁面喺對話時seem更responsive。
• Django：Django同Django Rest Framework（DRF）嘅learning curve更steep，特別係涉及Cloud SQL database嘅deployment同確保security。Django嘅comprehensive nature意味住以適當security level deploy需要啲時間。但我仲係做唔到streaming HTML answers work with DRF in production environment！雖然我可以用WebSockets做到，但嗰個approach同DRF差太遠，所以我未adopt。

所以如果你知道一個framework或answer點令Langgraph streaming同simple front end work，話我知！

我4月提到嘅金融Chatbot呢？

好消息係呢個項目引起咗你哋好多人嘅興趣——我收到大量questions同comments。壞消息？我離完成仲好遠 T.T 原因如下：

1. 平衡retrieval quality、vector store月費同embedding cost

好似我喺4月嗰篇文提到，我喺evaluate Weaviate嘅Serverless Cloud Vector Store。佢係要真金白銀嘅。對呢個項目，我likely要：

• Data Volume：超過1,000萬，可能1,250萬-1,500萬data objects。
• Cost Estimate：用512嘅vector dimension，月費可能由$600到$750。

呢個金額對production environment嘅公司嚟講manageable，但對side project嚟講可能太steep。所以我需要搵方法降低cost。

根據Weaviate pricing嘅運作方式，兩個levers係：減少data objects數量或減少vector dimension。兩者都有唔同嘅tradeoffs。

減少data objects嘅方法

• Aggressive Text Cleaning：減少10K同10Q filings嘅overall text size可以幫到，考慮到我哋deal with S&P 500嘅500間公司，每間都有過去10年嘅多個filings。我覺得呢個option已經exhaust咗。
• 增大Chunk Size：由256增加到512、1,000、2,000或3,000，可以將data objects減少2x、4x或10x。但可能降低retrieval quality，因為larger chunks tend to be less precise。

減少vector dimension嘅方法

減少vector dimension似乎同retrieval quality直接相關——dimension越低，retrieval quality越差。我仲喺experiment唔同嘅embedding models好似OpenAI嘅「text-embedding-3-small」同「text-embedding-3-large」with various dimensions。如果你有好推薦，share吓！

用OpenAI嘅「text-embedding-3-large」model都會增加embedding phase嘅cost。例如，用1024嘅vector dimension為23間公司嘅10K/10Q filings（過去10年）generate embeddings，cost我$4.5。即係成個S&P 500可能要$100+。（係，我係有啲孤寒。你之前唔知嘅咩 :P ？）

2. Query translation、structuring、retrieval期間嘅latency

Query translation同structuring越elaborate，我哋能generate越好嘅search terms/Content search terms，帶嚟更高質嘅retrieval。但同時都增加latency。

• Query translation係我哋ask model將initial user question translate成對retrieval更好嘅sub questions嘅步驟。例如，original question「How did Airbnb's operating margin change from 2020 to 2022?」model可以generate sub questions：

[
"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係我哋ask model將呢啲questions turn成search query或content search query for retrieval，加上相關filters嘅步驟。用上面嘅例子，對question 1，model可能return：

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

對於retrieval，return越多results，model process嘅時間就越長。Return少啲results意味住更快嘅response times但potentially更低質嘅answers due to a lack of context。

總結

仲有更多我tackle緊嘅嘢，但呢篇文已經比預期長，所以就到呢度。

你都係一邊full time工作一邊學coding嗎？當一切都seem equally重要嗰陣，你點決定next學乜？

祝好，

Chandler