Gemini 4 Argon có context 1 triệu token: Google đang xây model cho agent chạy dài

Một agent sửa phần mềm qua nhiều vòng phải giữ được yêu cầu, những thay đổi đã làm và kết quả kiểm tra trước đó. Khi lượng thông tin vượt cửa sổ ngữ cảnh, hệ thống phải chọn phần nào giữ, phần nào tóm tắt và phần nào tìm lại.

Tài liệu Gemini API mô tả Gemini 4 Argon với cửa sổ chung 1.048.576 token cho đầu vào và đầu ra. Đây là một ngân sách kết hợp, không phải hai khoản độc lập đều lớn một triệu token.

Đọc đúng giới hạn trước khi lập kế hoạch

Tài liệu nêu đầu ra đồng bộ mặc định tối đa 65.536 token; chế độ long decode hỗ trợ đầu ra dài hơn, vẫn trong giới hạn ngữ cảnh chung. Bởi vậy, gửi gần đầy cửa sổ bằng dữ liệu đầu vào sẽ làm giảm chỗ dành cho phần tiếp tục sinh.

Ví dụ giả định, nếu một ứng dụng cần giữ rất nhiều tài liệu và còn muốn một báo cáo dài, nó phải phân bổ ngân sách cho cả hai. Không thể dựa vào dòng “1M” rồi mặc định model đọc tối đa và viết tối đa trong cùng một yêu cầu.

Token là đơn vị model sử dụng để xử lý nội dung, không đồng nhất với số từ hay số trang. Khối lượng văn bản, hình ảnh và dữ liệu khác cần được đánh giá theo cơ chế của API, thay vì quy đổi bằng một tỷ lệ cố định cho mọi đầu vào.

Cửa sổ lớn hỗ trợ điều gì trong công việc dài?

Một tác vụ nhiều bước tạo thêm thông tin theo thời gian: phản hồi công cụ, lỗi, giả thuyết và quyết định đã chấp nhận. Giữ được thông tin liên quan giúp giảm nhu cầu bắt đầu lại hoặc hỏi lại điều đã biết.

Trong công bố trên Google Cloud ngày 13/10, Google nhấn mạnh công việc phần mềm và các dự án nhiều bước. Đây là định hướng sản phẩm của hãng; mức hiệu quả trong một ứng dụng cụ thể cần được kiểm tra trên chính tác vụ của ứng dụng ấy.

Có thể hình dung agent sửa một chức năng rồi chạy kiểm tra, nhận lỗi và điều chỉnh. Ngữ cảnh đủ lớn cho phép giữ lại yêu cầu gốc cùng kết quả gần đây. Nhưng nếu agent diễn giải sai yêu cầu, việc giữ nhiều dữ liệu hơn không tự sửa được lỗi ấy.

Context không phải bộ nhớ vĩnh viễn

Cửa sổ ngữ cảnh chứa thông tin được đưa vào lần xử lý hiện tại. Nó không tự tạo một cơ chế lưu lâu dài cho mọi phiên làm việc. Ứng dụng vẫn cần quyết định thông tin nào lưu, cách lấy lại và khi nào một kết quả cũ đã hết hiệu lực.

Trong ví dụ phần mềm, trạng thái mã nguồn sau khi sửa là một đối tượng cần quản lý riêng. Bản mô tả trong hội thoại không thể thay cho trạng thái thực của tệp. Agent cần đọc kết quả công cụ và kiểm tra rằng thay đổi vẫn phù hợp với môi trường.

Tương tự, một tài liệu cũ và bản cập nhật mới có thể cùng nằm trong cửa sổ. Model không đương nhiên biết bản nào có thẩm quyền nếu ứng dụng không cung cấp thời gian và nguồn rõ ràng.

Agent chạy dài vẫn cần điểm dừng và kiểm chứng

Argon hỗ trợ các khả năng như gọi hàm, thực thi mã và đầu ra có cấu trúc. Những tính năng ấy cung cấp cách nối model với hệ thống, nhưng quyền thực hiện hành động nằm ở cách ứng dụng thiết kế công cụ và phạm vi truy cập.

Model card của Google vẫn liệt kê các hạn chế như thông tin sai do model tạo ra, chậm hoặc timeout. Cửa sổ lớn là năng lực tiếp nhận, không phải lời bảo đảm mọi nội dung được dùng chính xác.

Vì vậy, đánh giá agent không nên chỉ đo độ dài đầu vào. Cần xem nó hoàn tất đúng bao nhiêu tác vụ, có bỏ sót yêu cầu không, phục hồi sau lỗi như thế nào và có nhận biết khi cần phản hồi của người dùng hay không.

Từ thông số lớn tới tác vụ hoàn thành

Các hệ thống dùng context dài cũng cần xem chi phí và thời gian thực hiện. Một câu trả lời dài hơn hoặc đọc nhiều dữ liệu hơn chỉ có giá trị nếu giúp đưa công việc tới kết quả đúng.

Bước tiếp theo là thử trên các tác vụ có trạng thái và tiêu chí hoàn thành rõ: cùng dữ liệu, cùng công cụ và cùng yêu cầu kiểm tra. Khi đó mới có thể biết cửa sổ một triệu token giảm bao nhiêu công việc tóm tắt hoặc tìm lại, và có cải thiện tỷ lệ hoàn thành hay không.

Ảnh Gemini 4 Argon: Google Cloud, từ bài công bố chính thức. Thông số API được kiểm tra ngày 14/10/2026; ví dụ phân bổ ngữ cảnh là giả định giải thích.