Netflix hiện đang sở hữu một kho lưu trữ khổng lồ chứa hàng triệu giờ raw production footage (cảnh quay thô). Đối với các nhà biên tập và sản xuất phim, việc tìm lại một cảnh quay cụ thể—ví dụ như “một cảnh trong nhà bếp có nhân vật A” hoặc “khoảnh khắc im lặng đầy căng thẳng trước trận chiến”—giữa hàng ngàn giờ dữ liệu thô từng là một pain point mang tính thủ công, tiêu tốn rất nhiều thời gian.
Để giải quyết bài toán này, Netflix đã xây dựng một hệ thống tìm kiếm thông minh dựa trên Multimodal AI. Tuy nhiên, điểm cốt lõi làm nên sự thành công của hệ thống này không chỉ nằm ở bản thân các thuật toán AI, mà là ở Systems Engineering (Kỹ thuật hệ thống): Làm thế nào để hợp nhất, đồng bộ hóa và index dữ liệu từ nhiều mô hình AI khác nhau nhằm phục vụ real-time query với độ trễ cực thấp.
1. Tại Sao Lại Dùng Ensemble Approach?
Thay vì sử dụng một monolithic model (mô hình nguyên khối) khổng lồ vốn cực kỳ tốn kém, khó train và kém linh hoạt, Netflix chọn cách tiếp cận kết hợp nhiều mô hình chuyên biệt chạy song song (Ensemble of specialized AI models). Mỗi mô hình được tối ưu hóa để làm tốt nhất một nhiệm vụ duy nhất:
Scene Classification: Phân loại bối cảnh không gian/thời gian (phòng khách, bãi biển, trời mưa, ban đêm…).
Dialogue Transcription (ASR): Tự động chuyển đổi lời thoại từ âm thanh thành text.
Thách thức hệ thống: Khó khăn thực sự nằm ở chỗ: Mỗi mô hình lại trả ra output formats khác nhau và hoạt động trên các time intervals hoàn toàn lệch nhau. Ví dụ: Mô hình Object Detection quét mỗi 0.5 giây/lần, Scene Classification trả kết quả theo từng scene dài vài phút, còn ASR thì chạy liên tục theo dòng chảy câu chữ. Việc kết nối các đầu ra rời rạc, asynchronous này thành một trục thời gian chung chính là bài toán hóc búa nhất.
2. Kiến Trúc Decoupled Pipeline 3 Giai Đoạn
Để đảm bảo hệ thống có scalability cao và không bị bottleneck khi xử lý lượng video khổng lồ, Netflix thiết kế một quy trình 3 giai đoạn hoàn toàn tách biệt (Decoupled Pipeline).
Hình 1: Mô hình kiến trúc tổng thể 3 giai đoạn từ tiếp nhận dữ liệu thô đến lập chỉ mục tìm kiếm trực tuyến.
Giai Đoạn 1: Ingestion & Transactional Persistence
Toàn bộ raw annotations và embeddings sinh ra từ các mô hình AI sẽ ngay lập tức được đẩy qua các high-availability ingestion pipelines và lưu trữ trực tiếp dưới dạng Key-Value vào Apache Cassandra.
Mục tiêu tối thượng của giai đoạn này là ưu tiên tuyệt đối cho write throughput. Việc đẩy thẳng dữ liệu vào Cassandra giúp hệ thống AI có thể liên tục xả dữ liệu ra mà không bị nghẽn bởi các bước xử lý logic phía sau.
Giai Đoạn 2: Offline Data Fusion (Trái Tim Của Hệ Thống)
Bài Toán Thực Tế: Vì Sao Cần "Fusion"?
Khi dữ liệu thô (raw annotations) được ingest vào Apache Cassandra, chúng tồn tại ở trạng thái vô cùng hỗn loạn về mặt thời gian (misaligned timestamps):
Mô hình A (Object Detection): Hoạt động ở mức 24 frames/second (fps). Nó có thể nhận diện một "khẩu súng" trong vỏn vẹn 0.04 giây.Mô hình B (Scene Classification): Trả về kết quả cho một đoạn dài. Ví dụ: từ
00:00:00 đến 00:02:30 là "Cảnh hành động ngoài trời".Mô hình C (ASR): Trả về text dạng streaming liên tục với start/end time không cố định.
Nếu nạp thẳng đống dữ liệu này vào Elasticsearch, việc query chéo (cross-query) các điều kiện sẽ gần như bất khả thi. Bạn không thể dễ dàng viết một câu query: "Tìm đoạn hội thoại X, khi đang ở ngoài trời, và có xuất hiện khẩu súng".
Đó là lý do Netflix xây dựng Offline Data Fusion Engine để thực hiện kỹ thuật Temporal Bucketing (gộp cụm theo thời gian) thông qua các Asynchronous Workers.
Quá trình Data Fusion được chạy ngầm bởi các Asynchronous Workers (ví dụ: Apache Spark, Flink hoặc hệ thống Event-driven nội bộ). Quá trình này chia làm 3 bước cốt lõi:
Bước 1: Data Extraction & Normalization
Timestamp Normalizer: Chuyển đổi mọi định dạng thời gian (frame number, milliseconds, start/end range) về một hệ quy chiếu chung duy nhất là millisecond tuyệt đối tính từ đầu video.
Đây là phép thuật cốt lõi. Hệ thống chia nhỏ timeline của video thành các Fixed-size Buckets. Ở Netflix, kích thước tối ưu được chọn là 1 Giây (1-Second Bucket).
Thuật toán sẽ duyệt qua từng raw annotation và xem nó "rơi" vào những bucket nào.Ví dụ xử lý Overlap (Giao thoa): Nếu Scene model nói "Nhà bếp" diễn ra từ giây 0 đến giây 10. Label "Nhà bếp" này sẽ được broadcast (nhân bản) và nhét vào 10 buckets liên tiếp (từ bucket 00:00:00 đến 00:00:10).
Ví dụ xử lý Point-in-time (Điểm thời gian): Nếu Face model nhận diện nhân vật "Joey" ở exacly
00:01:24.300. Label "Joey" sẽ chỉ được ném gọn vào đúng bucket 00:01:24.Bước 3: Aggregation & Confidence Scoring (Hợp nhất và Đánh giá độ tin cậy)
Khi tất cả dữ liệu của 1 giây đã nằm gọn trong 1 bucket, tiến trình Fusion Logic bắt đầu làm việc để dọn dẹp data:
Deduplication (Khử trùng lặp): Nếu model nhận diện được 10 cái "dao" trong cùng 1 giây (do quét ở 24 fps), Fusion engine sẽ gộp lại thành một entity "knife" duy nhất cho giây đó.Threshold Filtering: Các mô hình AI luôn trả về Confidence Score (Độ tin cậy: ví dụ 98% là Joey, 40% là Chandler). Lúc này, Fusion logic sẽ áp dụng các ruleset để drop (vứt bỏ) các label có score thấp hơn ngưỡng cho phép, tránh việc đẩy "rác" (noise) vào bộ máy tìm kiếm.
Kết quả đầu ra: Payload "Unified Record"
Sau khi hợp nhất, hệ thống nén toàn bộ thông tin của 1 Bucket thành một Payload dạng JSON document. Document này cực kỳ phẳng (flat) và giàu thông tin (enriched), hoàn toàn hoàn hảo cho việc index của Elasticsearch.
Sơ đồ text mô tả Data Fusion Engine:
Plaintext
[ 1. RAW DATA (Cassandra) ] -> Dữ liệu lệch pha thời gian ▼[ 2. OFFLINE DATA FUSION ENGINE (Async Workers) ] ┌─────────▼─────────┐ │ Data Extractor │ (Kéo dữ liệu thô theo block) └─────────┬─────────┘ ┌─────────▼─────────┐ │ Time Normalizer │ (Quy đổi tất cả mốc thời gian về ms) └─────────┬─────────┘ │ Temporal Bucketing ┌───────┼───────┐ ▼ ▼ ▼ [B 1] [B 2] [B 3] <-- Gộp vào các Bucket cố định 1-Giây │ (VD: Bucket 00:01:24) ┌─────────▼─────────┐ │ Fusion Logic │ (Khử trùng lặp & Đánh giá Confidence Score) └───────────────────┘
Sau khi hợp nhất, payload đầu ra là một Unified Record dạng JSON cực kỳ phẳng (flat) và giàu thông tin (enriched):
JSON
{ "video_id": "nx_810932_stranger_things_s4e1", "bucket_timecode": "00:01:24", "duration_ms": 1000, "entities": { "characters": [{"name": "Joey", "max_confidence": 0.98}], "objects": [{"type": "knife", "max_confidence": 0.85}], "scene_context": "kitchen, indoors, tension" }, "asr_transcript": "Where are we going?", "searchable_vector": [0.124, -0.432, 0.891, "...1024 dimensions..."]}
Giai Đoạn 3: Search Indexing
Các JSON Payload (Unified Records) này ngay lập tức được push vào Elasticsearch. Lúc này, mỗi một giây của bộ phim đã trở thành một document có cấu trúc rõ ràng, sẵn sàng phục vụ cho các truy vấn phức tạp.
3. Cơ Chế Hybrid Search
Hình 3: Cơ chế xử lý truy vấn kết hợp (Hybrid Search Query Pipeline) và Tầm nhìn tương lai MediaFM.
Keyword Search: Dành cho việc tìm chính xác tên nhân vật, entity hoặc một câu thoại cụ thể. Hệ thống áp dụng fuzzy dialogue matching để xử lý các lỗi chính tả hoặc từ ngữ nghe gần giống nhau do ASR dịch sai.
Vector Search (Semantic Search): Dành cho các truy vấn mang tính trừu tượng về bối cảnh hoặc cảm xúc (VD: “khoảng lặng căng thẳng”). Hệ thống biến query thành một vector và thực hiện Approximate Nearest-Neighbor (ANN) search.
Người dùng có thể tinh chỉnh linh hoạt các bộ lọc union/intersection, cấu hình confidence thresholds của AI để lọc nhiễu, giúp tìm ra chính xác frame cần thiết với sub-second latency.
Fuzzy dialogue matching cho phép hệ thống tìm ra các kết quả "gần đúng" hoặc "tương đối giống" với từ khóa truy vấn, thay vì đòi hỏi phải khớp chính xác từng ký tự 100% (Exact match).
1. Tại Sao Netflix Lại Cần Fuzzy Matching?
Trong một hệ thống phụ thuộc vào AI như Netflix, dữ liệu đầu vào không bao giờ hoàn hảo. Có hai nguyên nhân chính khiến việc tìm kiếm chính xác (Exact match) bị thất bại:
Lỗi từ mô hình ASR (Automatic Speech Recognition): Các mô hình chuyển đổi giọng nói thành văn bản rất dễ bị sai lệch do tiếng ồn môi trường (tiếng cháy nổ, tiếng mưa), giọng địa phương (accents), hoặc diễn viên nói lầm bầm.
Lỗi chính tả từ người dùng (User Typos): Các nhà biên tập phim khi tìm kiếm có thể gõ sai chính tả do vội vàng (ví dụ gõ "Joye" thay vì "Joey").
Nếu hệ thống chỉ sử dụng Exact match, kết quả trả về sẽ là 0 (Zero results). Các đoạn phim quý giá sẽ bị ẩn giấu vĩnh viễn chỉ vì một lỗi sai khác biệt một ký tự. Fuzzy Matching ra đời để cứu vãn sự sai số tất yếu này của AI
2. Giải pháp kĩ thuật
Levenshtein Distance
Fuzzy Matching trong Elasticsearch (và các search engine nói chung) thường hoạt động dựa trên một thuật toán toán học gọi là Levenshtein Distance (Khoảng cách Edit).
Edit Distance là số lượng thao tác tối thiểu (bao gồm: thêm, xóa, hoặc thay thế một ký tự) cần thiết để biến đổi chuỗi chữ này thành chuỗi chữ khác.
Ví dụ minh họa:
Từ người dùng tìm kiếm: "DANGER"
Văn bản do ASR dịch lưu trong database: "DANDER"
Để biến "DANDER" thành "DANGER", hệ thống chỉ cần thay thế 1 ký tự ('D' thành 'G').
=> Edit Distance = 1.
Trong cấu hình Elasticsearch của Netflix, các kỹ sư sẽ cài đặt một tham số gọi là fuzziness (ngưỡng dung sai). Nếu họ đặt fuzziness = 2, hệ thống sẽ chấp nhận tất cả các từ khóa trong database có Edit Distance ≤ 2 so với từ khóa tìm kiếm. Nhờ đó, dù ASR dịch sai "Danger" thành "Dander" hay "Ranger", Elasticsearch vẫn sẽ lôi đoạn phim đó ra và trả về cho người dùng.
Phonetic Matching (Khớp theo ngữ âm)
Bên cạnh Edit Distance dựa trên mặt chữ, Fuzzy Dialogue Matching cho các hệ thống hội thoại (speech-to-text) thường được kết hợp thêm các thuật toán Phonetic Algorithms (như Soundex hoặc Metaphone).
Kỹ thuật này không so sánh mặt chữ, mà so sánh cách phát âm của từ đó. Hệ thống sẽ mã hóa các từ có âm thanh giống nhau về chung một mã chuỗi (ví dụ: các âm 'C' và 'K' có thể được mã hóa giống nhau).
Ví dụ: Người dùng tìm chữ "Knight" (Hiệp sĩ), nhưng ASR nghe và ghi lại thành "Night" (Ban đêm). Mặt chữ khác nhau hoàn toàn ở đầu, nhưng về mặt ngữ âm (Phonetic) lại giống hệt nhau. Kỹ thuật này sẽ giúp hệ thống hiểu rằng đây có thể là một cú "match" hợp lệ.4. Architectural Trade-offs & Tương Lai (MediaFM)
Không có kiến trúc nào là hoàn hảo. Netflix đã chấp nhận những đánh đổi mang tính chiến lược:
Latency vs. Throughput: Việc xử lý Data Fusion được đẩy toàn bộ về offline batch processing. Khi video mới được upload, dữ liệu search không khả dụng ngay lập tức, nhưng đổi lại hệ thống có thể ingest hàng petabyte raw data mà không bị crash pipeline.
Ensemble Accuracy vs. Infrastructure Complexity: Việc vận hành, monitor hàng chục mô hình AI độc lập tạo ra một gánh nặng Ops rất lớn.
Sự trỗi dậy của MediaFM: Để giải quyết sự cồng kềnh của kiến trúc Ensemble, Netflix đang thử nghiệm MediaFM (Netflix Media Foundational Model). Đây là một mô hình tri-modal (audio, video, text) chạy trên nền tảng Transformer. MediaFM có khả năng tự động học ngữ cảnh theo thời gian để tạo ra một single unified embedding (vector nhúng duy nhất), hứa hẹn sẽ thay thế hoàn toàn hạ tầng đa mô hình phức tạp như hiện nay.
Lời Kết
Giá trị cốt lõi của hệ thống này nằm ở việc thay đổi hoàn toàn cost curve of creative iteration (chi phí lặp lại sáng tạo). Khi mọi elements trong video từ khuôn mặt, câu thoại đến bối cảnh đều có thể được query bằng một cú click, rào cản lớn nhất của việc sáng tạo nội dung không còn là khâu mò mẫm tìm kiếm dữ liệu cũ. Đây chính là chìa khóa vàng giúp Netflix khai thác và tái sử dụng tối đa giá trị kho tài sản số khổng lồ của mình.
0 Nhận xét