MiniMax M3 nhồi cả triệu token vào một câu hỏi — có nghĩa là bạn xoá luôn RAG không?
Mỗi lần một model mới khoe "context 1 triệu token", sẽ có một anh dev nhắn tôi: "Vậy là dẹp được RAG rồi đúng không sếp?" Câu trả lời ngắn là: không. Câu trả lời dài đáng để bạn đọc, vì nó quyết định kiến trúc — và hoá đơn — của con bot tra cứu tài liệu mà bạn sắp bán.
Tuần này MiniMax (Trung Quốc) công bố MiniMax M3 — một model open-weight với cửa sổ context 1 triệu token, và điểm đáng chú ý không phải con số 1M (đã có vài model khoe trước đó), mà là nó thật sự đứng ngang nhóm proprietary trên các bài long-context benchmark. Các "1M open" đời trước thường rớt rất sâu ở bài kiểm tra recall — nhồi vào được nhưng tìm lại không ra. Lần này khác (nguồn: the-decoder, 02.06.2026, qua bản tin AI nội bộ tôi theo dõi).
Tóm tắt cho người bận
- Context 1 triệu token nghĩa là bạn có thể đút thẳng nguyên một bộ tài liệu dài — hợp đồng, sổ tay nội bộ, vài trăm trang FAQ — vào một lần hỏi, không cần cắt nhỏ.
- MiniMax M3 đáng nói vì nó mở trọng số (tự host được, kể cả trên server đặt tại VN) và là model mở đầu tiên không "xạo" về long-context — nhồi vào rồi vẫn tìm lại đúng.
- Nhưng "context dài" không xoá được RAG. Nó đổi chỗ chi phí từ kỹ thuật (đi xây pipeline truy hồi) sang tiền mặt (trả token cho mỗi lượt hỏi). Với bot trả lời cả nghìn tin/ngày, đánh đổi đó thường lệch về phía RAG.
Context dài và RAG thực ra giải hai bài khác nhau
Người ta hay đặt chúng cạnh nhau như hai lựa chọn thay thế. Sai. Chúng giải hai vấn đề khác nhau.
RAG (truy hồi rồi mới trả lời) trả lời câu: trong kho tài liệu khổng lồ, đoạn nào liên quan tới câu hỏi này? Bạn cắt tài liệu thành mẩu, đánh chỉ mục, mỗi lượt hỏi chỉ lôi vài mẩu liên quan đưa cho model. Model chỉ đọc đúng phần cần.
Context dài trả lời câu: cho model đọc hết một lúc thì nó có hiểu được toàn cảnh không? Không cần đoán trước đoạn nào liên quan — cứ đưa hết, model tự lọc trong đầu.
Cái hay của M3 là nó làm cho vế thứ hai trở nên khả thi với model mở. Trước đây nếu nhồi 800 trang vào một model "1M giả", nó sẽ quên mất trang 300 khi bạn hỏi về trang 300. Giờ thì không.
Khi nào context dài thật sự thay được RAG
Tôi neo vào con bot CSKH spa mình đang chạy thật cho khách. Có những tình huống context dài thắng rõ:
- Kho tài liệu nhỏ và ổn định. Một cái spa có bảng giá, danh mục liệu trình, chính sách hoàn tiền — gộp lại có khi chỉ 30–50 trang. Toàn bộ "tri thức" của bot vừa gọn trong context. Dựng RAG cho ngần đó tài liệu là bắc thang lên trời để hái quả trên cành thấp: tốn công xây pipeline, tốn chỗ chạy vector DB, để giải một bài mà đút thẳng vào prompt là xong.
- Câu hỏi cần đọc xuyên suốt cả tài liệu. "So sánh giúp tôi gói A trang 5 với điều khoản hủy ở trang 40" — RAG dễ lôi nhầm hoặc lôi thiếu mẩu, context dài đọc cả hai cùng lúc nên trả lời mạch lạc hơn.
- Khách đòi data-residency. M3 mở trọng số nên host được trên server VN. DN làm hồ sơ pháp lý, hợp đồng nhạy cảm có thể nhồi nguyên bộ tài liệu vào model tự host, không gửi gì ra cloud nước ngoài.
Khi nào bạn vẫn phải chunk
Và đây là phần mà mấy bài "khỏi cần RAG" lờ đi:
- Kho tài liệu lớn hoặc thay đổi liên tục. Nếu khách có 5.000 trang và mỗi tuần thêm vài chục, bạn không thể nhồi 5.000 trang vào mỗi lượt hỏi. RAG chỉ lôi đúng phần cần — context dài bắt model đọc lại từ đầu mỗi lần.
- Bot trả lời số lượng lớn. Đây là chỗ chết người với túi tiền. Bạn trả token cho mỗi token trong context, mỗi lượt gọi. Nhồi 200.000 token tài liệu vào một câu hỏi "spa mở mấy giờ" là đốt tiền: khách hỏi giờ mở cửa, bạn bắt model đọc lại 200 trang. Một con bot CSKH chạy nghìn tin/ngày mà làm vậy thì hoá đơn token sẽ dạy cho bạn bài học về RAG nhanh hơn bất kỳ bài blog nào.
- Cần độ chính xác trích dẫn. RAG cho bạn biết câu trả lời đến từ mẩu tài liệu nào — dễ kiểm, dễ chỉ nguồn cho khách. Context dài trả lời "từ đâu đó trong 800 trang", khó truy.
Lưu ý thẳng: các benchmark long-context "ngang proprietary" của M3 là MiniMax tự công bố tại thời điểm ra mắt, chưa có kiểm chứng độc lập diện rộng. Đừng cược kiến trúc sản phẩm vào một bảng điểm nhà sản xuất tự chấm — hãy tự chạy thử trên đúng loại tài liệu của khách trước.
Góc builder: tôi sẽ làm gì với M3
Không phải "context dài thay RAG", mà là dùng đúng cái cho đúng tầng:
- Bot kho tri thức nhỏ (spa, phòng khám, cửa hàng): context dài + model mở rẻ là lựa chọn gọn. Bỏ luôn vector DB, đút thẳng tài liệu, đỡ một mớ hạ tầng.
- Bot tra cứu tài liệu lớn cho DN: vẫn RAG để lọc, nhưng mở rộng kích thước mỗi mẩu nhờ context giờ rộng rãi. Trước đây cắt mẩu nhỏ vì sợ tràn; giờ lôi vài mẩu lớn, model M3 đọc thoải mái mà không quên. RAG + context dài đi cùng nhau, không loại trừ.
- Khách đòi data-residency: đây là lợi thế thật của trọng số mở. Tự host M3 trên VPS đặt tại VN, nhồi tài liệu nhạy cảm vào, không một byte rời khỏi máy chủ của khách. Đây là thứ bạn bán được giá cao hơn so với gọi API nước ngoài.
Câu hỏi đúng không phải "model có 1M token chưa", mà là "mỗi lượt hỏi của khách cần model đọc bao nhiêu, và tôi trả tiền cho phần đọc đó kiểu gì". Trả lời được câu đó, bạn tự biết khi nào nhồi thẳng, khi nào phải chunk — và không bị mỗi cái headline model mới làm lung lay kiến trúc.
Đó cũng là kiểu quyết định "chọn đúng kiến trúc cho đúng bài toán" mà tôi dạy kỹ trong mini-course miễn phí — vì con bot đầu tiên bán được tiền không phải con bot dùng model xịn nhất, mà là con bot không đốt sạch lợi nhuận vào hoá đơn token.
Nguồn tham khảo (qua bản tin AI nội bộ tôi theo dõi hằng ngày): the-decoder.com — MiniMax M3, 02.06.2026. Các con số benchmark long-context là do MiniMax tự công bố lúc ra mắt, chưa kiểm chứng độc lập diện rộng.