Xây dựng các ứng dụng AI thực sự hiệu quả không nằm ở việc tạo ra một câu lệnh (prompt) hoàn hảo, mà nằm ở việc kiểm soát thông tin bạn cung cấp cho mô hình. Nếu bạn từng tham gia một cuộc trò chuyện dài với một trợ lý ảo, để rồi nhận ra nó đã quên mất điều bạn nói mười phút trước, bạn đã nếm trải cảm giác khi kỹ thuật ngữ cảnh (context engineering) thất bại. Thật dễ để cho rằng AI có trí nhớ kém. Nhưng thực tế, bạn đã chạm phải giới hạn cứng của cửa sổ ngữ cảnh (context window).

Để xây dựng các hệ thống luôn đáng tin cậy và phản hồi nhanh chóng, bạn cần hiểu ba nguyên tắc cơ bản: token, cửa sổ ngữ cảnh (context window), và sự khác biệt giữa ngữ cảnh (context) và bộ nhớ (memory).

Token mới là đơn vị tiền tệ thực sự

Một token không phải là một từ. Khi bạn gửi văn bản đến một mô hình, một bộ tách token (tokenizer) sẽ chia nhỏ nó thành các phần. Những từ ngắn và phổ biến như "cat" hay "the" có thể chỉ chiếm một token. Một thuật ngữ kỹ thuật phức tạp như "internationalization" sẽ bị chia thành nhiều phần. Dấu câu, khoảng trắng và các ký tự đặc biệt cũng đều được tính. Điều này rất quan trọng vì token chi phối mọi thứ: hóa đơn API của bạn, tốc độ phản hồi và chất lượng đầu ra.

Một nhà phát triển lập kế hoạch chi phí bằng cách đếm số từ là đang "mò mẫm trong bóng tối". Một câu lệnh dài 100 từ chứa đầy các dấu ngoặc mã nguồn và tên biến dài có thể làm tăng lượng token vượt xa mong đợi. Đó là lý do tại sao các bộ tokenizer tồn tại như những công cụ độc lập. Trước khi triển khai một tính năng, hãy chạy các dữ liệu đầu vào (payload) điển hình của bạn qua một bộ tokenizer. Bạn sẽ thường thấy rằng các hướng dẫn hệ thống (system instructions), mã mẫu (boilerplate) và lịch sử trò chuyện tiêu tốn ngân sách nhiều hơn cả truy vấn thực tế của người dùng. Hãy coi token là một nguồn tài nguyên khan hiếm ngay từ ngày đầu tiên.

Cửa sổ ngữ cảnh là một chiếc bảng trắng có kích thước cố định

Cửa sổ ngữ cảnh là tổng lượng thông tin mà một mô hình có thể nhìn thấy trong một yêu cầu duy nhất. Hãy coi nó như một chiếc bảng trắng có kích thước cố định. Bạn có thể lấp đầy nó bằng các quy tắc hệ thống, lịch sử trò chuyện, các tài liệu được truy xuất và câu hỏi hiện tại. Nhưng một khi bề mặt đã được lấp đầy, sẽ có thứ gì đó phải nhường chỗ. Các ghi chú cũ phải bị xóa đi, được chụp ảnh lại rồi tóm tắt, nếu không chiếc bảng sẽ bị tràn.

Các mô hình hiện đại quảng cáo cửa sổ ngữ cảnh dao động từ vài nghìn token đến hàng trăm nghìn token. Thật dễ để lầm tưởng rằng một cửa sổ lớn hơn đồng nghĩa với việc lưu trữ không giới hạn. Nhưng không phải vậy. Chiếc bảng trắng vẫn có các cạnh. Khi lịch sử vượt quá giới hạn, ứng dụng phải loại bỏ các tin nhắn cũ hoặc nén chúng lại. Hiểu được ràng buộc này sẽ giúp bạn ngừng coi cửa sổ ngữ cảnh như một cơ sở dữ liệu và bắt đầu coi nó như một không gian làm việc chủ động.

Ngữ cảnh không phải là bộ nhớ

Đây là một sự phân biệt khiến ngay cả những nhà phát triển dày dạn kinh nghiệm cũng nhầm lẫn. Bản thân mô hình là không lưu trạng thái (stateless). Nó không nhớ bạn từ hôm qua, tuần trước, hay mười phút trước trong một phiên làm việc khác. Khi một AI có vẻ như nhớ rằng bạn thích Python hơn JavaScript, hoặc bạn thích các câu trả lời ngắn gọn, thì bộ nhớ đó nằm ở lớp ứng dụng (application layer), chứ không phải ở mô hình.

Ứng dụng lưu trữ những sự thật đó trong cơ sở dữ liệu, bộ nhớ đệm (cache) hoặc kho lưu trữ bộ nhớ. Trong mỗi yêu cầu mới, nó sẽ đưa các dữ liệu hồ sơ liên quan trở lại câu lệnh. Mô hình chỉ đơn giản là đang đọc một kịch bản bao gồm cả các lời thoại từ hồi một. Nó không có một "cái tôi" tồn tại vĩnh viễn. Một khi bạn đã nắm vững sự phân tách này, kiến trúc của bạn sẽ thay đổi. Bạn sẽ ngừng yêu cầu mô hình phải ghi nhớ và bắt đầu thiết kế các hệ thống có khả năng lấy đúng ngữ cảnh vào đúng thời điểm.

Tại sao nhiều ngữ cảnh hơn có thể phản tác dụng

Lẽ thường cho thấy rằng càng nhiều thông tin nền thì câu trả lời sẽ càng tốt hơn. Nhưng thường thì điều ngược lại lại xảy ra. Ngữ cảnh dư thừa tạo ra nhiễu. Nếu bạn đưa cho mô hình toàn bộ mã nguồn trong khi bạn chỉ cần sửa một hàm duy nhất, bạn đang buộc nó phải tìm kiếm tín hiệu trong một đống nhiễu. Các nhà nghiên cứu đã xác định được hiệu ứng "Lost in the Middle" (Bị lạc ở giữa): các mô hình thường chú ý kỹ hơn đến các chi tiết ở đầu và cuối câu lệnh, trong khi thông tin bị chôn vùi ở giữa sẽ bị làm loãng hoặc bị bỏ qua. Đây không phải là một lỗi mà bạn có thể vá bằng cách dùng từ ngữ khéo léo. Đó là một hành vi cấu trúc hiện hữu trong các kiến trúc dựa trên transformer.

Các câu lệnh cồng kềnh cũng gây thiệt hại trực tiếp cho bạn. Mỗi token bổ sung đều yêu cầu tính toán. Độ trễ tăng lên. Chi phí leo thang. Sự kiên nhẫn của người dùng giảm xuống. Một câu lệnh nhồi nhét các tài liệu không liên quan sẽ gây ra sự mâu thuẫn, làm mô hình xao nhãng bởi các chi tiết bên lề và làm tăng khả năng câu trả lời tập trung sai vấn đề. Khối lượng lớn là kẻ thù của sự chính xác.

Cách thiết kế ngữ cảnh tốt hơn

Kỹ thuật ngữ cảnh tốt là một bài tập về việc biên tập một cách quyết liệt. Dưới đây là cách để đưa nó vào thực tế.

Chỉ gửi những gì nhiệm vụ yêu cầu. Nếu người dùng hỏi về chính sách hoàn tiền, đừng đưa vào sổ tay nhân viên, tài liệu API và bản sao tiếp thị của quý trước. Sự liên quan quan trọng hơn sự toàn diện.

Sử dụng RAG để truy xuất các tài liệu liên quan. Retrieval-Augmented Generation cho phép bạn tìm kiếm trong một cơ sở kiến thức lớn và chỉ đưa các đoạn văn khớp nhất vào prompt. Thay vì đổ cả một cuốn hướng dẫn dài hàng ngàn trang vào cửa sổ chat, bạn nhúng (embed) các tài liệu của mình, thực hiện tìm kiếm ngữ nghĩa (semantic search) dựa trên truy vấn của người dùng và chỉ bao gồm ba đoạn văn phù hợp nhất. Mô hình sẽ nhận được chính xác những gì nó cần, và ngân sách token của bạn vẫn được giữ nguyên.

Tóm tắt các cuộc hội thoại cũ. Toàn bộ bản ghi chat rất tốn kém và gây nhiễu. Hãy thay thế lịch sử tin nhắn dài dòng bằng các bản tóm tắt liên tục. Ví dụ, thay vì đưa cho mô hình ba mươi tin nhắn qua lại, hãy lưu trữ một đoạn văn duy nhất: "Người dùng đã hỏi về triển khai Django, gặp lỗi tệp tĩnh và đã sửa lỗi phân quyền. Vấn đề hiện tại là lỗi di chuyển cơ sở dữ liệu (database migration) trên Postgres 14." Bản tóm tắt đó giúp duy trì trạng thái mà không làm rối bảng trắng.

Tách biệt bộ nhớ dài hạn khỏi cuộc chat đang diễn ra. Các tùy chọn của người dùng, cài đặt dự án và lịch sử tài khoản nên nằm trong một kho lưu trữ bộ nhớ bên ngoài. Hãy truy vấn kho lưu trữ đó một cách có chọn lọc. Cửa sổ ngữ cảnh (context window) trực tiếp chỉ nên chứa nhiệm vụ tức thời và ngữ cảnh cá nhân ngắn gọn nhất cần thiết để duy trì tính liên tục.

Theo dõi việc sử dụng token trong môi trường production. Sự gia tăng đột biến về độ trễ thường bắt nguồn trực tiếp từ việc ngữ cảnh bị phình to. Hãy thiết lập cảnh báo khi các yêu cầu tiến gần đến giới hạn của mô hình. Xem lại nhật ký (logs) để xác định các prompt chứa thông tin thừa. Tối ưu hóa luôn bắt đầu với cùng một câu hỏi: chúng ta có thể loại bỏ điều gì mà không làm hỏng nhiệm vụ?

Bài học thực tế

Các ứng dụng AI tốt nhất không chiến thắng nhờ có cửa sổ ngữ cảnh lớn nhất. Chúng chiến thắng nhờ quản lý ngữ cảnh một cách kỷ luật. Một chiếc bảng trắng khổng lồ sẽ trở nên vô dụng nếu nó bị phủ kín bởi những nét vẽ nguệch ngoạc. Hãy xây dựng các hệ thống có khả năng truy xuất, tóm tắt và lọc. Người dùng của bạn sẽ nhận được câu trả lời nhanh hơn, chi phí hạ tầng của bạn sẽ dễ dự đoán hơn, và cuối cùng thì các mô hình của bạn sẽ tập trung vào những gì thực sự quan trọng.

Nguồn: AI Context Engineering: Tokens, Context Windows, & Memory

Cộng đồng: GyaanSetu AI trên Telegram