LongLive-RAG: Khi RAG không chỉ dành cho text nữa

Nếu bạn đã từng nghịch với các model sinh video AI, chắc bạn biết cái cảm giác xem một clip dài mà nhân vật cứ... biến dạng dần. Ban đầu trông ổn, nhưng đến giây thứ 10-15 thì khuôn mặt bắt đầu mờ, màu tóc đổi, quần áo thay đổi kiểu dáng. Đó không phải bug ngẫu nhiên đó là một vấn đề cấu trúc rất cơ bản trong cách các model AR (autoregressive) video diffusion hoạt động.

Một paper vừa drop trên HuggingFace hôm 2/6 LongLive-RAG đề xuất một cách tiếp cận khá thú vị để giải quyết chuyện này, và cái hay là nó mượn đúng cái concept mà dân backend/AI engineer chúng ta đã quen thuộc: RAG.

Vấn đề gốc rễ: Sliding window là con dao hai lưỡi

Các model sinh video dài hiện tại (như các AR video diffusion backbone) thường dùng sliding-window attention để tiết kiệm memory và compute. Logic rất hợp lý: thay vì attend toàn bộ sequence dài, chỉ nhìn vào N frame gần nhất.

Nhưng đây chính là chỗ vấn đề bắt đầu. Imagine cái flow như này:

1. Frame 1-10 generate ra ổn
2. Frame 11-20 condition vào frame 1-10 vẫn ổn
3. Frame 21-30 chỉ nhìn được frame 11-20, không còn thấy frame 1-10 nữa
4. Nếu frame 11-20 có một chút drift (hơi sai màu da, hơi sai góc mặt), thì frame 21-30 sẽ coi cái sai đó là "đúng" và drift thêm
5. Cứ thế tích lũy...

Các tác giả gọi đây là irreversible generation trajectory một khi window hiện tại đã bị nhiễm lỗi, toàn bộ những gì generate sau đó chỉ có thể condition vào cái trajectory đã hỏng đó. Không có cách nào quay lại.

Theo kinh nghiệm của mình khi làm việc với các pipeline xử lý sequence dài, đây là dạng lỗi tích lũy (accumulated error) rất khó debug vì từng bước nhỏ trông có vẻ ổn, nhưng nhìn end-to-end thì drift rõ rệt.

RAG cho video nghe lạ nhưng hợp lý

Đây là chỗ mình thấy cái paper này khá clever. Thay vì cố gắng fix sliding window attention (vốn rất tốn compute nếu mở rộng window), họ frame lại bài toán hoàn toàn:

*Thay vì chỉ nhìn vào recent window, hãy treat toàn bộ latents đã generate trước đó như một dynamic, searchable history*.

Nghe quen không? Đúng rồi đây về bản chất là RAG, nhưng thay vì retrieve text chunks từ vector database, bạn retrieve video latents từ lịch sử generation.

Flow của LongLive-RAG trông như này:

• Khi generate block mới, model tạo ra một query embedding từ context hiện tại
• Query này được dùng để search trong toàn bộ historical latents đã generate
• Retrieve về những latents relevant nhất không nhất thiết phải là gần nhất về mặt thời gian
• Generator condition vào cả recent window lẫn retrieved latents

Cái điểm mấu chốt ở đây: retrieved latents không bị giới hạn bởi vị trí temporal. Nếu frame 1-5 có context quan trọng (ví dụ khuôn mặt nhân vật rõ nét), model vẫn có thể retrieve về dùng khi đang generate frame 50-60, dù sliding window thông thường đã bỏ qua chúng từ lâu.

Window Temporal Delta Loss cái trick để retrieval không bị lazy

Một vấn đề tiềm ẩn khi làm retrieval trên video: các frame liên tiếp nhau về mặt thời gian thường rất giống nhau về mặt visual. Nếu không cẩn thận, model sẽ học cách embed mà chỉ capture local similarity tức là frame 20 và frame 21 sẽ có embedding gần nhau, nhưng frame 20 và frame 1 (dù có cùng nhân vật) lại bị xa nhau.

Kết quả? Retrieval chỉ pull về những frame gần nhất, không khác gì sliding window gốc.

Để fix cái này, nhóm tác giả introduce Window Temporal Delta Loss một loss function được thiết kế để:

• Suppress redundant local similarity (phạt nếu embeddings của các frame trong cùng window quá giống nhau)
• Encourage embeddings capture meaningful temporal changes (khuyến khích model học những gì thực sự thay đổi có ý nghĩa theo thời gian)

Mình thấy cái này hay ở chỗ nó giải quyết đúng cái failure mode của retrieval trên sequential data. Trong NLP RAG, bạn cũng có vấn đề tương tự khi các chunks gần nhau về mặt semantic thì thường cũng gần nhau về mặt position nhưng video còn extreme hơn vì adjacent frames literally là cùng một cảnh.

Overhead như thế nào?

Đây là câu hỏi thực tế nhất khi evaluate bất kỳ technique nào. Tác giả claim rằng retrieval step chỉ add "a small overhead relative to generation".

Lý do overhead nhỏ là vì:

Tradeoff ở đây là memory bạn cần lưu toàn bộ latent history. Với video dài, cái này không nhỏ. Nhưng so với việc phải extend attention window (quadratic cost), đây vẫn là bargain tốt hơn nhiều.

Anh em lưu ý: nếu deploy production với video cực dài (hàng trăm giây), memory management của phần latent history này sẽ là một engineering challenge không nhỏ. Paper chưa nói nhiều về cách handle cái này ở scale lớn.

Kết quả và ý nghĩa thực tế

Theo paper, LongLive-RAG đạt best average VBench-Long rank so với các AR long video generation methods khác, và hoạt động được trên nhiều AR backbone khác nhau tức là nó là một general framework, không phải tied vào một architecture cụ thể.

Cái này quan trọng vì nó có nghĩa là:

• Các team đang build trên top của existing AR video models có thể potentially plug LongLive-RAG vào mà không cần retrain từ đầu
• Khi các backbone mạnh hơn ra đời, framework này vẫn applicable

Về mặt conceptual, đây cũng là lần đầu tiên (theo tác giả) có ai formulate self-generated latent history như content-addressable retrieval memory trong open-ended AR video generation. Cái framing này thú vị vì nó mở ra một hướng nghiên cứu mới: nếu bạn có thể retrieve latents, bạn cũng có thể làm nhiều thứ khác với cái memory đó edit, inject, hoặc thậm chí share across different generation sessions.

Mình không biết paper này sẽ trở thành standard hay không, nhưng cái insight cốt lõi treat generation history như a searchable database thay vì một fixed window là một cách nghĩ rất đúng hướng. Dân làm distributed systems hay backend chắc thấy cái này rất familiar: đây về bản chất là bài toán stateful vs stateless processing, và solution là externalize state ra một store có thể query được.

Nếu bạn đang làm gì đó liên quan đến video AI hoặc long-sequence generation, paper này đáng đọc full. Link gốc ở HuggingFace papers: 2606.02553.