Tóm tắt nhanh

  • Databricks đưa độ tươi dưới một giây của Feature Store vào trọng tâm của serving feature. Điều này nhắc các đội ngũ rằng workflow ít code chỉ hữu ích khi feature lúc suy luận vẫn phù hợp với thực tế vận hành.
  • Chất lượng model offline không đảm bảo chất lượng quyết định nếu feature phục vụ cho inference bị cũ hoặc khác với feature lúc huấn luyện.
  • Lập danh sách feature online, đặt ngưỡng tuổi dữ liệu cho từng feature và kiểm thử fallback khi feature không sẵn sàng.

Điều gì đã xảy ra

No-code và low-code có thể rút ngắn thời gian tạo mô hình, nhưng không tự giải quyết bài toán phục vụ feature. Databricks đặt trọng tâm vào việc Feature Store phục vụ feature với độ tươi dưới một giây, một yêu cầu đặc biệt quan trọng khi quyết định phụ thuộc vào trạng thái mới của hệ thống.

Vì vậy, “từ dữ liệu đến dashboard” không phải toàn bộ kiến trúc ML. Với use case online, dữ liệu dùng để suy luận cần được xem như một sản phẩm vận hành riêng.

Độ tươi feature nghĩa là gì?

Feature là biến đầu vào mô hình: ví dụ tín hiệu giao dịch, trạng thái người dùng hoặc chỉ số hoạt động. Nếu giá trị được phục vụ không phản ánh trạng thái cần ra quyết định, dự đoán có thể kém hữu ích dù mô hình đã được huấn luyện tốt.

Hai luồng dữ liệu mới và chậm đi vào một mô hình.
Hai luồng dữ liệu mới và chậm đi vào một mô hình.

Bài viết Databricks Feature Store và độ tươi dưới một giây làm rõ rằng freshness là thuộc tính của đường phục vụ, không chỉ của bảng dữ liệu offline.

Khác biệt giữa demo và vận hành

Workflow AWS dùng dữ liệu giao dịch, biến đổi trực quan, Canvas và dashboard là một mẫu tốt cho phân tích và quy trình xem xét. Nhưng nếu một mô hình cần phản ứng ngay trong lúc tương tác xảy ra, đội ngũ phải xác định feature nào phải cập nhật nhanh, ai sở hữu chúng và khi không lấy được feature thì hệ thống làm gì.

Không nên suy ra từ cụm “dưới một giây” rằng mọi bài toán đều cần hoặc sẽ đạt mức đó. SLA phù hợp phải xuất phát từ quyết định cụ thể, không phải từ năng lực của nền tảng.

Những câu hỏi kiến trúc cần trả lời

  • Feature nào dùng chung giữa training và inference?
  • Độ trễ chấp nhận được của từng feature là bao nhiêu?
  • Có theo dõi tuổi dữ liệu tại thời điểm dự đoán không?
  • Khi feature trễ, thiếu hoặc lỗi, hệ thống fallback thế nào?

Bắt đầu từ tính quan sát được

Trước khi tối ưu tốc độ, hãy đo độ tuổi feature, tỷ lệ thiếu và sự khác biệt giữa dữ liệu training với dữ liệu phục vụ. Một dashboard có thể cho thấy outcome; observability của feature mới giải thích liệu model đã nhận đúng ngữ cảnh khi dự đoán hay chưa.

Trong 5 phút

  • Databricks nhấn mạnh Feature Store có thể phục vụ feature với độ tươi dưới một giây.
  • Freshness là vấn đề của đường inference, không chỉ của kho dữ liệu.
  • Use case online cần SLA, fallback và monitoring riêng cho feature.
  • Hãy đo tuổi và độ đầy đủ của feature trước khi tối ưu hiệu năng.

Nguồn tham khảo

Vì sao developer cần quan tâm

Chất lượng model offline không đảm bảo chất lượng quyết định nếu feature phục vụ cho inference bị cũ hoặc khác với feature lúc huấn luyện.

  1. 1Lập danh sách feature online, đặt ngưỡng tuổi dữ liệu cho từng feature và kiểm thử fallback khi feature không sẵn sàng.