Ba tháng sau: Vẫn code, vẫn học, vẫn bị kẹt (đôi khi)

Cập nhật (2026): Dự án chatbot tài chính S&P 500 cuối cùng đã được khai tử. Sydney trở lại và giờ tập trung vào nội dung blog và sản phẩm. Thử Sydney →

---

Tôi đã tranh luận liệu có nên viết bài cập nhật này về hành trình code hay không. Tiến bộ không hào nhoáng hay thấy rõ từ bên ngoài — vậy tại sao phải bận tâm?

À, có lẽ bài viết này sẽ là lời nhắc tốt cho tôi trong tương lai rằng tiến bộ có thể chậm lại đôi khi và sự phát triển thường xảy ra theo từng đợt.

Kể từ bài viết cuối về xây chatbot tự đánh giá giữa tháng 4, tôi đã đăng ký một số khóa học:

• React Basics của Meta trên Coursera
• React Advanced của Meta trên Coursera
• Django web framework
• Full Stack

Tại sao chọn những khóa học này?

Tôi muốn chia sẻ kinh nghiệm cá nhân và quá trình suy nghĩ khi chọn các khóa này. Hy vọng nó có thể giúp những ai đang (hoặc sẽ) trên hành trình tương tự.

Trở nên giỏi hơn trong việc hướng dẫn máy

Đã khoảng 10 tháng kể từ khi tôi bắt đầu code, trong khi vẫn có công việc toàn thời gian. (Bạn có thể đọc thêm về Cách tôi xây Chatbot mà không có kinh nghiệm code: Bài học kinh nghiệm đăng tháng 10 2023 ở đây.)

Tôi chắc chắn KHÔNG THỂ làm được mà không có sự giúp đỡ của AI tạo sinh (dù là chatGPT hay Anthropic Claude hay Microsoft CoPilot trong Visual Studio Code.) Tuy nhiên, càng code nhiều, tôi càng nhận ra rằng mặc dù các mô hình nền tảng này mạnh mẽ, chúng vẫn giống thực tập sinh. Chúng chưa giỏi lập kế hoạch hay giải quyết các nhiệm vụ mơ hồ. Hướng dẫn của chúng ta càng cụ thể, output càng tốt.

Điều đó có nghĩa tôi cần trở nên cụ thể hơn với hướng dẫn code. Nhưng bằng cách nào? Cho đến giờ, tôi đã mô tả những gì tôi muốn bằng ngôn ngữ tự nhiên. Dù điều này hoạt động ở mức cơ bản, nó không đủ cho các nhiệm vụ phức tạp hơn.

Vậy câu hỏi logic tiếp theo là học gì?

Tập trung vào vấn đề kinh doanh/người dùng tôi đang cố giải quyết

Chatbot của tôi (tên code Sydney) cho website này đã (có lẽ "đang") chậm. Sự chậm xảy ra ở cả:

• Thời gian khởi động
• Và trong cuộc hội thoại

Streaming chưa được bật, nên người dùng phải đợi khá lâu để thấy câu trả lời hoàn chỉnh.

Nên mục tiêu của tôi đơn giản: làm cho nó nhanh và phản hồi tốt.

Mục tiêu đơn giản: làm cho nó nhanh và phản hồi tốt. Nhưng không có kiến thức nền tảng, rất khó chia nhỏ thành các vấn đề có thể giải quyết. Đó là lý do tôi quyết định học thêm về framework front-end có khả năng mở rộng, bảo mật và nhanh, framework back-end, và full stack (bao gồm database).

Kinh nghiệm với React và Django cho đến giờ

• React: React tương đối dễ học và deploy hơn so với Django. (Dĩ nhiên!) Front end chatbot hiện tại dùng React, và tôi thấy Claude và ChatGPT có thể xử lý hầu hết các nhiệm vụ code mà không gặp vấn đề. Deploy trong môi trường production với React cũng khá đơn giản, và trang chatbot có vẻ phản hồi tốt hơn trong hội thoại.
• Django: Django và Django Rest Framework (DRF) có đường cong học tập dốc hơn, đặc biệt với deployment liên quan đến Cloud SQL database và đảm bảo bảo mật. Bản chất toàn diện của Django có nghĩa là deploy với mức bảo mật phù hợp mất thời gian. Tuy nhiên, tôi vẫn KHÔNG THỂ làm cho streaming HTML answers hoạt động với DRF trong môi trường production! Dù tôi có thể làm được bằng WebSockets, cách tiếp cận đó khác biệt đáng kể so với DRF, nên tôi chưa áp dụng.

Vậy nếu bạn biết framework hoặc giải pháp nào để Langgraph streaming hoạt động với front end đơn giản, cho tôi biết!

Còn Chatbot tài chính tôi đề cập hồi tháng 4 thì sao?

Tin tốt là dự án này đã thu hút sự quan tâm của nhiều bạn — tôi nhận được nhiều câu hỏi và nhận xét. Tin xấu? Tôi còn lâu mới hoàn thành T.T Đây là lý do:

1. Cân bằng chất lượng retrieval, chi phí vector store hàng tháng, và chi phí embedding

Như đề cập trong bài tháng 4, tôi đang đánh giá Weaviate Serverless Cloud Vector Store. Nó tốn tiền thật. Cho dự án này, tôi có thể cần:

• Khối lượng dữ liệu: Hơn 10 triệu, có thể 12.5 - 15 triệu data objects.
• Ước tính chi phí: Với vector dimension 512, chi phí hàng tháng có thể từ $600 đến $750.

Số tiền này quản lý được cho công ty trong môi trường production nhưng có thể quá cao cho side project như này. Nên tôi cần tìm cách giảm chi phí.

Dựa trên cách định giá Weaviate, hai đòn bẩy là: giảm số lượng data objects hoặc giảm vector dimension. Cả hai đều có đánh đổi khác nhau.

Cách giảm data objects

• Dọn text mạnh tay: Giảm kích thước text tổng thể trong hồ sơ 10K và 10Q có thể giúp, xét rằng chúng ta đang xử lý 500 công ty trong S&P 500, mỗi công ty có nhiều hồ sơ trong 10 năm qua. Tôi nghĩ đã cạn kiệt tùy chọn này.
• Tăng chunk size: Bằng cách tăng chunk size từ 256, lên 512 lên 1.000 lên 2.000 hoặc 3.000, tôi có thể giảm số data objects gấp 2x, 4x hoặc 10x. Tuy nhiên, điều này có thể giảm chất lượng retrieval, vì chunk lớn hơn thường kém chính xác hơn.

Cách giảm vector dimension

Giảm vector dimension dường như tương quan trực tiếp với chất lượng retrieval — dimension càng thấp, chất lượng retrieval càng kém. Tôi vẫn đang thử nghiệm với các mô hình embedding khác nhau như OpenAI "text-embedding-3-small" và "text-embedding-3-large" với các dimension khác nhau. Nếu bạn có gợi ý tốt, hãy chia sẻ!

Dùng mô hình "text-embedding-3-large" từ OpenAI cũng thêm chi phí trong giai đoạn embedding. Ví dụ, tôi tốn $4.5 để tạo embeddings cho hồ sơ 10K/10Q của 23 công ty trong 10 năm qua với vector dimension 1024. Điều này có nghĩa có thể tốn khoảng $100+ cho toàn bộ S&P 500. (Vâng, tôi hơi keo kiệt. Bạn chưa biết sao :P?)

2. Độ trễ trong query translation, structuring, retrieval

Query translation và structuring càng công phu, cụm từ tìm kiếm / Content search terms chúng ta tạo ra càng tốt, dẫn đến retrieval chất lượng cao hơn. Tuy nhiên, điều này cũng tăng độ trễ.

• Query translation là bước chúng ta yêu cầu mô hình dịch câu hỏi ban đầu thành sub questions tốt hơn cho retrieval. Ví dụ, với câu hỏi gốc "Biên lợi nhuận hoạt động của Airbnb thay đổi thế nào từ 2020 đến 2022?" mô hình có thể tạo sub questions như:

[
"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 là bước chúng ta yêu cầu mô hình chuyển các câu hỏi này thành search query hoặc content search query cho retrieval, cùng với các filter liên quan. Sử dụng ví dụ trên, cho câu hỏi 1, mô hình có thể trả về

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

Cho retrieval, càng nhiều kết quả trả về, mô hình xử lý càng lâu. Trả về ít kết quả hơn nghĩa là thời gian phản hồi nhanh hơn nhưng có thể chất lượng câu trả lời thấp hơn do thiếu bối cảnh.

Kết thúc

Tôi đang giải quyết thêm nhiều thứ, nhưng vì bài viết đã dài hơn dự kiến, tôi sẽ dừng ở đây.

Bạn cũng đang học code khi làm việc toàn thời gian? Bạn quyết định học gì tiếp theo như thế nào khi mọi thứ đều cảm thấy quan trọng như nhau?

Thân mến,

Chandler