Contents
Vì sao context là một tài nguyên phải tiêu dè sẻn, không phải một cái thùng để nhồi?
Có một phản xạ gần như ai làm việc với mô hình ngôn ngữ cũng từng có. Kết quả ra sai, mình thêm. Thêm một ví dụ nữa cho rõ ý. Thêm một ràng buộc nữa cho chắc. Dán thêm một đoạn tài liệu phòng khi nó cần. Prompt phình ra từng dòng, và cảm giác yên tâm tăng theo độ dài. Niềm tin ngầm ở đây là: nhiều thông tin hơn thì mô hình hiểu rõ hơn.
Niềm tin đó sai ở một điểm cốt lõi, và đây là chủ đề của bài viết này. Trong nhiều trường hợp, thêm thông tin vào context không cải thiện kết quả mà còn làm nó tệ đi. Nguyên tắc dẫn đường không phải là cung cấp nhiều nhất có thể, mà là tìm tập token tín hiệu cao nhỏ nhất đủ để mô hình ra đúng kết quả. Luận điểm trung tâm có thể phát biểu gọn: chất lượng một prompt được quyết định bởi phần ta đã loại bỏ, nhiều hơn phần ta đã thêm vào.
Bài viết đi theo ba lớp. Trước hết là khái niệm và cơ chế khiến điều này đúng. Sau đó là dẫn chứng từ nghiên cứu và thực nghiệm. Cuối cùng là phần áp dụng, biến nguyên tắc thành một quy trình dùng được trong công việc hằng ngày.
Lớp 1: Khái niệm và cơ chế
Context là một tài nguyên hữu hạn
Cách hữu ích nhất để nghĩ về context không phải là một kho chứa, mà là một ngân sách. Anthropic, trong bài viết về context engineering cho agent, gọi đây là ngân sách chú ý hữu hạn (finite attention budget). Mỗi token bạn đưa vào đều tiêu một phần của ngân sách đó. Tiêu vào token quan trọng thì đáng. Tiêu vào token thừa thì không, và tệ hơn, phần tiêu đó kéo theo lợi ích biên giảm dần cho mọi token còn lại.
Đây là điểm phân biệt giữa hai khái niệm hay bị gộp làm một.
- Prompt engineering quan tâm bạn diễn đạt thế nào với mô hình tại một thời điểm.
- Context engineering quan tâm mô hình thấy gì khi bạn nói, và là một bài toán rộng hơn: quản lý toàn bộ tập token đi vào cửa sổ, gồm system prompt, tài liệu, lịch sử hội thoại, kết quả tool …
Ví dụ, khi nhìn dưới góc tài nguyên, câu hỏi không còn là “thêm gì nữa cho chắc”, mà là “token nào đáng nằm trong ngân sách này”.
Vì sao thêm token lại làm loãng
Cơ chế nằm ở kiến trúc transformer. Trong một transformer, mỗi token phải tham chiếu đến mọi token khác để tính mức độ liên quan. Quan hệ này tăng theo bình phương: thêm một token không phải là phép cộng vào danh sách, mà là phép nhân số liên kết mô hình phải cân nhắc. Khi context dài ra, cùng một lượng năng lực chú ý phải trải mỏng trên nhiều cặp quan hệ hơn. Phần dành cho mỗi token, kể cả token quan trọng, ít đi.
Hệ quả là một thứ phản trực giác. Một đoạn tài liệu không liên quan, để đó “cho chắc”, không phải một phương án dự phòng vô hại. Mô hình vẫn đọc nó, vẫn điều kiện hóa lên nó, và vẫn có thể bám vào nó để trả lời lệch hướng. Mọi token thừa là một nguồn nhiễu, không phải một lựa chọn an toàn miễn phí.
Một phép so sánh giúp hình dung nhanh. Hãy nghĩ về một thám tử và một nhân chứng. Nhân chứng tốt kể đúng ba chi tiết giải được vụ án: biển số xe, mốc giờ, hướng bỏ chạy. Nhân chứng tệ kể hai trăm chi tiết, trong đó có cả màu trời và tiếng chó sủa nhà bên. Cả hai đều thành thật. Nhưng người thứ hai chôn vùi manh mối thật giữa một đống dữ kiện vô nghĩa, và thám tử, với trí nhớ làm việc có hạn, bắt đầu lạc. Context bạn đưa vào prompt chính là lời khai đó. Sự chú ý của mô hình là phần ngân sách hữu hạn bạn đang tiêu thay cho nó.
Lớp 2: Dẫn chứng
Luận điểm “ít hơn thì tốt hơn” nghe dễ thành một câu nói cho sang. Phần này dẫn ba nhóm bằng chứng cho thấy nó là hiện tượng đo được, không phải khẩu hiệu.
Context Rot: độ chính xác tụt trước khi cửa sổ đầy
Nghiên cứu của Chroma về hiện tượng được gọi là context rot ghi nhận một điều quan trọng: khi số token trong context tăng, khả năng truy hồi chính xác của mô hình giảm, và sự suy giảm này xuất hiện trước cả khi chạm giới hạn cứng của cửa sổ. Nói cách khác, cửa sổ còn nửa trống không có nghĩa là nửa đã dùng vẫn hoạt động tốt. Mô hình có thể đã đãng trí với chi tiết bạn đặt ở giữa, dù về kỹ thuật nó vẫn “nhìn thấy” token đó.
Đây là chỗ cần tách bạch ba mức: nhìn thấy, chú ý, và hiểu. Một token nằm trong cửa sổ thì mô hình nhìn thấy nó. Nhưng nhìn thấy không bảo đảm mô hình chú ý tới nó, và chú ý cũng chưa phải là hiểu. Tăng dung lượng cửa sổ chỉ tác động lên mức thứ nhất. Hai mức sau không tự động cải thiện theo.
Khoảng cách giữa dung lượng quảng cáo và năng lực thực
Các mô hình hiện đại quảng cáo cửa sổ hàng trăm nghìn đến hàng triệu token. Con số đó là dung lượng trên giấy tờ, không phải năng lực sử dụng thực tế. Một phân tích của Databricks ghi nhận độ chính xác bắt đầu tụt quanh mốc khoảng 32K token với nhiều mô hình, sớm hơn rất nhiều so với trần triệu token. Điều này tạo ra một độ dốc hiệu năng, không phải một vách đứng: mô hình vẫn dùng được ở context dài, nhưng độ chính xác cho truy hồi thông tin và suy luận tầm xa giảm dần so với khi context ngắn.
Một bằng chứng kinh điển bổ trợ cho điều này là hiện tượng “lost in the middle” mà nhóm nghiên cứu ở Stanford mô tả: mô hình truy xuất tốt nhất thông tin nằm ở đầu và cuối context, và kém nhất với thông tin nằm ở giữa. Càng kéo dài context, vùng giữa càng phình to, và càng nhiều dữ kiện rơi vào vùng mù đó.
Lời của chính những người xây mô hình
Đáng chú ý là nguyên tắc này không đến từ phía phản biện bên ngoài, mà từ chính đội ngũ xây dựng. Anthropic phát biểu thẳng rằng vì mô hình bị ràng buộc bởi một ngân sách chú ý hữu hạn, context engineering tốt nghĩa là tìm tập token tín hiệu cao nhỏ nhất đủ để tối đa khả năng ra đúng kết quả mong muốn. Trong tài liệu kỹ thuật của họ, context được mô tả là một tài nguyên quý, hữu hạn, với lợi ích biên giảm dần. Mọi từ thừa, mọi mô tả tool dư, mọi mẩu dữ liệu cũ đều làm hiệu năng kém đi.
Ba nhóm bằng chứng này hội tụ về cùng một kết luận, từ ba hướng độc lập. Đo độ chính xác theo độ dài, ta thấy context rot. Đo khoảng cách giữa cửa sổ và năng lực, ta thấy trần thực tế thấp hơn nhiều con số quảng cáo. Hỏi chính người thiết kế, họ xác nhận đây là một bài toán tài nguyên.
Lớp 3: Nguyên tắc áp dụng
Hiểu cơ chế mới là một nửa. Phần còn lại là biến nó thành thói quen. Dưới đây là năm nguyên tắc rút ra, sắp theo thứ tự dễ áp dụng dần.
1. Rà soát và cắt token thừa trước mỗi lần gọi
Trước khi gửi một prompt, đặt một câu hỏi với từng khối thông tin: nếu bỏ khối này, kết quả có đổi không? Nếu câu trả lời là không, hãy bỏ. Quy trình này nghe đơn giản nhưng đi ngược phản xạ tự nhiên là thêm cho chắc. Hãy coi nó như rà soát ngân sách, không phải dọn dẹp cho gọn mắt. Mỗi khối giữ lại phải kiếm được chỗ của nó.
2. Lấy đúng lúc thay vì nạp sẵn
Thay vì đổ toàn bộ tài liệu vào prompt từ đầu, hãy giữ các tham chiếu nhẹ như đường dẫn tệp, truy vấn cơ sở dữ liệu, hay endpoint…, rồi để hệ thống nạp đúng phần cần đúng thời điểm. Chiến lược lấy đúng lúc đánh đổi một chút độ trễ để lấy về một context sạch hơn nhiều. Với agent chạy dài, đây thường là khác biệt giữa một hệ thống ổn định và một hệ thống trôi dần khỏi quỹ đạo.
3. Giữ toolset và tài liệu ở mức tối thiểu
Một quan sát thực hành đáng nhớ: nếu chính kỹ sư còn phân vân nên chọn tool nào trong số hai mươi tool, thì mô hình càng khó chọn đúng. Mỗi tool thừa, mỗi tài liệu thừa là một khả năng chọn nhầm và một nguồn nhiễu. Thiết kế tool cho agent nên tuân cùng kỷ luật như thiết kế interface cho con người: chức năng rõ, không chồng chéo, phạm vi gọn.
4. Đo bằng eval, đừng đo bằng cảm giác
Khi cắt context, rất dễ rơi vào ảo giác cải thiện. Cách duy nhất để biết một thay đổi thật sự tốt hơn là chạy nó qua một tập eval cố định và so điểm. Không cần một bộ eval đồ sộ. Một tập nhỏ vài chục ca tiêu biểu, chạy lại mỗi lần đổi prompt, đã đủ giữ cho việc tối ưu context không trở thành đoán mò. Nếu không có eval, thứ bạn cải thiện thường là cảm giác về context, chứ chưa chắc là bản thân context.
Trong AI, eval (viết tắt của Evaluation – đánh giá) là quá trình đo lường độ chính xác, hiệu suất và chất lượng của mô hình trí tuệ nhân tạo. Nó đóng vai trò như một bài kiểm tra để đảm bảo AI hoạt động đúng yêu cầu và đưa ra câu trả lời an toàn, chính xác trong thực tế.
5. Coi cắt là một kỹ năng, không phải một thao tác
Thêm thì dễ và cho cảm giác an toàn. Cắt đòi hỏi bạn phải hiểu cái gì thật sự quan trọng, và đó là phán đoán chứ không phải động tác. Đây là lý do prompt loãng thì nhiều, prompt sắc thì hiếm. Người viết prompt giỏi không phải người biết nhồi nhiều thông tin nhất, mà người biết bỏ đúng thứ cần bỏ.
Tạm kết
Năm năm nữa, cửa sổ triệu token sẽ thành hàng phổ thông, ai cũng có. Khi dung lượng trở thành thứ gần như miễn phí, lợi thế không còn nằm ở chỗ bạn nhét được bao nhiêu vào, mà ở kỷ luật bạn cắt được bao nhiêu ra. Đó là một dịch chuyển âm thầm về nơi đặt giá trị: từ khả năng cung cấp sang khả năng chọn lọc.
Quay lại phản xạ ở đầu bài. Lần tới khi một kết quả ra sai và bạn định thêm một đoạn nữa cho chắc, hãy thử điều ngược lại trước. Bỏ bớt một thứ. Rất có thể thứ làm hỏng câu trả lời không phải cái còn thiếu, mà là cái lẽ ra đã phải cắt.
Cảm ơn bạn đã đọc bài viết này!
Related Posts:
