Skip to content
··5 phút đọc

S&P500 Agent MVP ra mắt: Trả lời câu hỏi tài chính dựa trên dữ liệu SEC

Tôi xây một AI agent trả lời câu hỏi tài chính sử dụng 10 năm dữ liệu SEC — và cuối cùng giải quyết được thách thức streaming để làm nó real-time và kiểm chứng được.

Cập nhật (2026): S&P 500 Agent đã được khai tử. Bài viết này ghi lại lần ra mắt MVP gốc cho mục đích lịch sử. Sydney giờ tập trung vào nội dung blog và sản phẩm của Chandler. Thử Sydney hiện tại →


Xin chào,

Tôi vui mừng chia sẻ rằng kể từ bài viết cuối về vật lộn khi làm S&P500 Agent, phiên bản MVP đã sẵn sàng! :D Hãy để tôi giới thiệu sản phẩm khả dụng tối thiểu này có thể làm gì và nó ra đời thế nào.

MVP này có thể làm gì?

  1. Đào sâu vào một thập kỷ dữ liệu: Database của agent bao gồm 10 năm company facts được nộp cho SEC EDGAR. Khá hay phải không?
  2. Câu trả lời đáng tin cậy: Vì nó được grounded bằng số liệu thực tế nộp cho SEC, bạn có thể tin chất lượng câu trả lời.
  3. Dễ kiểm chứng: Agent luôn bao gồm dữ liệu tham chiếu trong câu trả lời cuối cùng. Nên nếu bạn muốn kiểm tra, bạn có thể tự xác minh!
  4. Xử lý câu hỏi phức tạp: Nó có thể giải quyết các câu hỏi bán phức tạp như "So sánh doanh thu của Apple và Microsoft từ 2020 - 2022?" hoặc "Biên lợi nhuận hoạt động của Microsoft thay đổi thế nào từ 2020 đến 2022?" Tại sao đây là bán phức tạp? Agent cần "suy luận" và chia nhỏ các câu hỏi rộng thành câu nhỏ hơn, tra cứu thông tin từ database, rồi ghép lại.
    • Ví dụ, để trả lời câu hỏi đầu tiên, agent cần biết doanh thu từng công ty cho mỗi năm 2020, 2021 và 2022 rồi thực hiện so sánh.
  5. Cập nhật (gần như): Ngày cutoff là tháng 8 2024. Bất cứ thứ gì nộp cho SEC sau đó không có trong phiên bản MVP này.
  6. HTML streaming: Streaming hoạt động! Yay! :D Hóa ra, DRF và React hỗ trợ streaming nguyên bản, nên với langgraph, chúng ta có luồng hội thoại phản hồi nhanh, hiển thị ở định dạng dễ đọc. Tôi đã vật lộn với html streaming một thời gian.

Nhìn bên trong

Nếu bạn vẫn đọc đến đây, có lẽ bạn muốn biết thêm về cách tôi xây MVP này và vượt qua một số thách thức đã đề cập trước đó. Vậy hãy đi vào kỹ thuật một chút!

  1. Thu gọn dữ liệu: Thay vì dùng báo cáo 10-K hoặc 10-Q đầy đủ, tôi dùng "Facts" được nộp cho SEC. Nghĩa là database nhỏ hơn đáng kể - dưới 2GB! Bên dưới là ví dụ về những gì các công ty đại chúng nộp cho 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"
  \},
  "AdditionalPaidInCapitalCommonStock": {
    "label": "Additional Paid in Capital, Common Stock"

Điều này cũng có nghĩa tôi không cần vector store quy mô lớn, nhanh, rất đắt (trong khoảng $600 - $700/tháng)

2. Cloud SQL PostgreSQL làm database chính: Tôi dùng Cloud SQL PostgreSQL làm database chính. Vì tôi đã dùng Cloud Run CI/CD từ GCP, có lý khi gắn với các dịch vụ của Google. Đây là khái niệm hoàn toàn mới với tôi nên tôi phải học cách migrate database từ local lên cloud và cách cấu hình backend để làm việc với Cloud SQL database sử dụng private IP. Tài liệu từ GCP rất hữu ích.

3. React gặp Django: Đây là lần đầu tiên tôi thành công deploy cả React frontend và Django Rest Framework (DRF) backend với Cloud SQL database. Đó là hành trình thử và sai, nhưng ChatGPT o1-preview và Anthropic Claude 3.5 Sonnet đã giúp rất nhiều. Chúng thực sự rất mạnh, đặc biệt khi bạn cho đủ bối cảnh về vấn đề đang giải quyết.

4. Agent thông minh: Agent được xây bằng Langgraph. Nó có hai tool chính: Google Search và Financial Question Answering tool. Nó quyết định dùng tool nào dựa trên câu hỏi.

5. SQL query được tạo thế nào?

Không đơn giản để chuyển câu hỏi chung/rộng của người dùng thành SQL query phù hợp cho database. Một trong những lý do chính là khi công ty nộp financial facts cho SEC, họ dùng khái niệm/thuật ngữ tài chính không trực quan với người bình thường.

Ví dụ, "doanh thu" có thể được đại diện bởi nhiều facts như:

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

Và giữa các công ty, họ có thể chọn dùng label khác nhau cho cùng khái niệm. Ví dụ, Apple dùng "Revenue from Contract with Customer, Excluding Assessed Tax" vs Tesla dùng "Revenue".

Hoặc khi bạn hỏi về "biên lợi nhuận hoạt động", đó có thể không phải là fact mà công ty nộp cho SEC. Thay vào đó, họ nộp tổng doanh thu và Operating Income (Loss).

Tình huống khác là khi công ty đổi tên theo thời gian nên bạn cần đảm bảo SQL query bao gồm cả tên cũ và tên mới.

Vậy làm sao tôi hướng dẫn máy chọn đúng fact/label cho câu hỏi rộng?

Tôi dùng hybrid search với Weaviate để tìm các facts hoặc labels liên quan nhất và gửi lại cho mô hình LLM.

6. Test từng bước là chìa khóa

Trước khi deploy cuối cùng lên production, tôi chia quy trình thành các bước và test từng bước:

1. Test local của DRF backend với database local.

2. Test Docker container backend với database local.

3. Migrate PostgreSQL database lên Cloud SQL và test.

4. Test Docker container backend với Cloud SQL.

5. Test local React front end.

6. React front end với production backend và Cloud SQL.

7. Migrate React front end sang Wordpress trong production.

8. Test end-to-end.

Tôi phải học cách tiếp cận từng bước này theo cách khó. Ban đầu, tôi bỏ qua một số bước và test theo khối lớn hơn, nhưng các mô hình ngôn ngữ (LLM) không thể chỉ ra chính xác vấn đề ở đâu.

Tiếp theo là gì?

  1. Sửa vấn đề cold start: Hiện tại, agent mất một chút thời gian để trả lời câu hỏi đầu tiên. Tôi đang tìm giải pháp tiết kiệm chi phí.
  2. Hiển thị bước trung gian cho người dùng: Khi trả lời câu hỏi phức tạp như "So sánh doanh thu Apple và Microsoft từ 2020 đến 2022," agent mất thời gian để tạo câu trả lời cuối cùng. Hiển thị các bước agent đang làm trong thời gian thực có thể cải thiện trải nghiệm người dùng.
  3. Bổ sung nội dung text 10-K/10-Q: Tôi dự định bao gồm thêm nội dung text liên quan từ hồ sơ 10-K và 10-Q để cung cấp câu trả lời chi tiết hơn.

Đó là tất cả từ tôi cho bây giờ. Hãy dùng thử phiên bản MVP ở đây và cho tôi biết bạn nghĩ gì! Bạn đã thử xây thứ gì với dữ liệu tài chính hoặc hồ sơ SEC chưa? Tôi rất muốn nghe kinh nghiệm của bạn — comment bên dưới hoặc email trực tiếp cho tôi (chandler@chandlernguyen.com).

Thân mến,

Chandler

Đọc tiếp

Hành trình
Kết nối
Ngôn ngữ
Tùy chọn