Context Window

Mô hình không đọc chữ, nó đọc token. Và mỗi lượt gọi, nó chỉ nhìn được một lượng token hữu hạn — đó là context window. Con số này tính gộp tất cả: chỉ dẫn hệ thống, tài liệu bạn dán vào, toàn bộ lịch sử hội thoại từ đầu, và cả phần câu trả lời sắp sinh ra. Không phải chỉ tính phần bạn vừa gõ.

Cửa sổ đầy thì ứng dụng phải cắt bớt thứ gì đó, thường là phần cũ nhất, và thường là cắt lặng lẽ. Đó là lý do mô hình "quên" điều bạn nói hai mươi lượt trước.

Token được đếm thế nào

Token là mảnh của từ, không phải từ. Với tiếng Anh, ước lượng quen thuộc là một token khoảng bốn ký tự, tức là ba phần tư của một từ. Với tiếng Việt thì tốn hơn đáng kể, vì dấu thanh và cách cắt âm tiết khiến một từ thường ngốn hai tới ba token.

Con số thực tế phụ thuộc vào bộ tách token của từng mô hình, nên đừng dùng nó như một hằng số. Nhưng để ước lượng nhanh khi bàn phạm vi, một trang A4 tiếng Việt dày chữ rơi vào khoảng 700 tới 1.000 token là con số dùng được. Cứ nhân lên rồi so với giới hạn của mô hình đang dùng.

Token cũng là đơn vị tính tiền, tính riêng phần vào và phần ra. Một tính năng tóm tắt tài liệu dài chạy 4.800 lượt mỗi ngày là một khoản chi phí có thật, và BA nên tính nó ra con số trước khi tính năng vào backlog.

Vì sao dán cả BRD 200 trang vào chat lại hỏng

Hai lý do, độc lập với nhau.

Lý do thứ nhất là tràn. Một BRD 200 trang tiếng Việt rơi vào khoảng 150.000 tới 200.000 token. Nhiều mô hình hiện nay nhận được lượng đó, nhưng nếu bạn còn hội thoại qua lại vài chục lượt phía sau thì tổng vượt ngưỡng. Lúc đó công cụ chat thường tự cắt phần đầu hội thoại đi mà không báo. Bạn tưởng nó vẫn nhớ yêu cầu bạn đặt ra ở lượt thứ ba, thực tế thì không.

Lý do thứ hai đau hơn: nhét vừa không có nghĩa là dùng tốt. Mô hình chú ý tới phần đầu và phần cuối của khối văn bản tốt hơn hẳn phần giữa. Dân làm mô hình gọi đây là lost in the middle, và bạn thấy nó ngay trong công việc: hỏi "tài liệu này có bao nhiêu quy tắc tính phí" với một BRD dài, mô hình liệt kê rất đúng các quy tắc ở chương đầu và chương cuối, bỏ sót đúng những cái nằm ở chương 7 giữa tài liệu.

Và nó không nói là mình bỏ sót. Nó đưa ra một danh sách trông đầy đủ.

Ví dụ thực tế

Đợt rà soát một FRD hệ thống quản lý kho, 176 trang, BA cần liệt kê toàn bộ quy tắc kiểm tra tồn kho rải rác trong tài liệu. Cách làm đầu tiên là dán nguyên file rồi hỏi một câu. Ra 9 quy tắc.

Cách làm thứ hai mất nhiều thời gian hơn nhưng ra kết quả dùng được: cắt tài liệu theo chương, mỗi lần đưa hai chương, hỏi đúng một câu, ghi kết quả ra một bảng. Mười hai lượt, khoảng 40 phút. Ra 23 quy tắc, trong đó có 4 cái mâu thuẫn nhau giữa chương 5 và chương 11 — thứ mà cách làm đầu tiên không bao giờ phát hiện.

Chênh lệch 9 với 23 là lý do vì sao mình không tin bản tóm tắt một phát của tài liệu dài, kể cả khi mô hình quảng cáo cửa sổ cả triệu token.

Cách làm việc gọn trong cửa sổ

• Chia nhỏ theo cấu trúc tự nhiên của tài liệu: chương, mục, điều. Cắt theo số trang là cắt giữa câu.
• Đặt câu hỏi và ràng buộc quan trọng ở cuối prompt, ngay sau khối tài liệu. Vị trí cuối được chú ý tốt hơn.
• Mỗi lượt một nhiệm vụ. Vừa tóm tắt vừa tìm mâu thuẫn vừa đề xuất sửa trong một câu hỏi thì cả ba đều làng nhàng.
• Mở hội thoại mới khi đổi chủ đề. Kéo lê một hội thoại 80 lượt qua ba chủ đề khác nhau thì tốn token, và mô hình cũng bắt đầu lẫn chủ đề này sang chủ đề kia.
• Khi dữ liệu vượt quá vài trăm trang, đừng dán nữa, dựng RAG. Đó chính là bài toán RAG sinh ra để giải.

Một mẹo nhỏ hay dùng: cuối mỗi phiên làm việc dài, bảo mô hình viết lại một bản tóm tắt các quyết định và ràng buộc đã chốt, lưu ra file, rồi mở phiên mới dán bản tóm tắt đó vào làm phần mở đầu. Bạn giữ được thứ cần giữ mà không phải chở theo cả nghìn lượt hội thoại cũ.