300 Token Đúng Chỗ Thắng 100k Token Nhiễu: Kiến Trúc Kỹ Thuật Context Engineering

Trong kỷ nguyên AI tạo sinh, các tác nhân lập trình (coding agents) ngày càng phổ biến nhưng cũng ngày càng thất bại vì một lý do tưởng chừng đơn giản: nhồi nhét quá nhiều ngữ cảnh (context) vào cửa sổ xử lý. Theo Baruch Sadogursky và Patrick Debois, các hệ thống này không chết vì thiếu dữ liệu, mà chết vì quá thừa dữ liệu nhiễu.

Vấn đề cốt lõi nằm ở chỗ hầu hết các agent đều bị nhồi toàn bộ nội dung repository, toàn bộ lịch sử chat, hoặc toàn bộ file cấu hình vào prompt. Kết quả là mô hình AI bị "mất tập trung", không thể phân biệt đâu là thông tin quan trọng, đâu là code lỗi thời hay doc không còn giá trị. Một cửa sổ 100.000 token đầy rác chắc chắn sẽ thua xa một cửa sổ 300 token được chọn lọc kỹ lưỡng.

Vì Sao Cửa Sổ Ngữ Cảnh Lớn Lại Phản Tác Dụng?

Khi tăng kích thước cửa sổ ngữ cảnh, độ chính xác của mô hình giảm rõ rệt. Các nghiên cứu nội bộ và trải nghiệm thực tế từ nhiều đội ngũ đều cho thấy hiện tượng "lost in the middle" – mô hình chỉ nhớ tốt phần đầu và phần cuối prompt, còn ở giữa thì bỏ sót.

Hệ quả là agent có thể bỏ qua một API contract quan trọng nằm giữa 50.000 dòng code, hoặc áp dụng một pattern đã bị deprecated. Thậm chí tệ hơn, các file markdown như README, ADR (Architecture Decision Records) bị đưa thẳng vào prompt thường chứa thông tin không có cấu trúc, trùng lặp, hoặc đã cũ – tạo ra một "mớ hỗn độn" mà mô hình không thể nào gỡ rối được.

Bốn Trụ Cột Của Context Engineering

Để giải quyết vấn đề này, hai tác giả đề xuất một kiến trúc mới có tên gọi chung là context engineering. Không phải là tăng token, mà là tối ưu hóa chất lượng và cách thức đưa ngữ cảnh vào model. Dưới đây là bốn trụ cột chính:

1. Lazy-Loaded Skills (Kỹ năng tải theo nhu cầu)

Thay vì đưa toàn bộ kỹ năng lập trình của hệ thống vào mỗi lần gọi, hãy thiết kế agent chỉ tải đúng skill khi cần thiết. Ví dụ, nếu agent đang xử lý một task liên quan đến authentication, nó chỉ nên tải module kỹ năng về OAuth, JWT – không cần phải tải cả kỹ năng viết SQL.

Điều này giống như một công nhân bậc thầy chỉ lấy đúng dụng cụ cần dùng trong từng bước, thay vì đeo cả một thắt lưng dụng cụ khổng lồ khi làm việc.

2. Phiên Bản Hóa Context Artifacts

Context artifacts (các file ngữ cảnh được chuẩn bị sẵn – ví dụ như file mô tả kiến trúc, file hướng dẫn chuẩn code) phải được quản lý phiên bản như code thật. Khi kiến trúc hệ thống thay đổi, file ngữ cảnh phải được cập nhật, tag version, và được review như một pull request bình thường.

Bằng cách này, agent luôn làm việc với một snapshot nhất quán về hệ thống, tránh hiện tượng dùng thông tin cũ để sinh code mới. Các đội ngũ nên lưu trữ chúng trong cùng repository với mã nguồn để đảm bảo tính đồng bộ.

3. Externalized Memory Banks (Ngân hàng bộ nhớ ngoài hóa)

Thay vì cố nhồi tất cả mọi thứ vào cửa sổ context, hãy sử dụng một hệ thống bộ nhớ ngoài – có thể là vector database, file markdown có cấu trúc, hoặc một service lưu trữ riêng. Khi agent cần thông tin, nó sẽ truy vấn ngân hàng bộ nhớ này thay vì được cấp sẵn.

Điều này giúp giảm tải token và quan trọng hơn, giúp mô hình luôn lấy đúng thông tin mới nhất thay vì dùng dữ liệu cũ đã được "đóng băng" trong prompt từ đầu phiên làm việc.

"Chúng ta đang đối xử với context như một thùng đựng đồ vô hạn. Thực tế, nó là một nguồn tài nguyên hạn chế cần được quản lý tinh tế." – Ý tưởng chính từ bài trình bày.

4. LLM-as-a-Judge Eval (Đánh giá bằng LLM đóng vai trò giám khảo)

Làm thế nào để biết context hiện tại có tốt hay không? Câu trả lời là dùng chính một mô hình LLM khác (hoặc cùng loại) để đánh giá chất lượng output của agent theo một tiêu chí rõ ràng. Thay vì chờ con người review, hệ thống sẽ tự động chấm điểm xem agent có đi đúng hướng không, có bỏ sót yêu cầu nào không.

Phương pháp này tạo ra một vòng phản hồi tự động, giúp đội ngũ phát hiện sớm các trường hợp context bị nhiễu, thiếu hoặc lỗi thời, từ đó cải thiện dần các artifact đầu vào.

Từ File Markdown Thô Đến Agentic Workflow Đáng Tin Cậy

Điểm mấu chốt mà hai diễn giả nhấn mạnh là: chúng ta không thể kỳ vọng một agent có thể xử lý tốt khi nhận vào một đống file markdown tùy tiện. Cần phải có một quy trình để chuyển hóa các tài liệu thô thành ngữ cảnh có cấu trúc, được chọn lọc và tối ưu.

Một quy trình gợi ý bao gồm: Dọn dẹp và chuẩn hóa tài liệu → Trích xuất thông tin quan trọng thành các file context ngắn gọn → Phiên bản hóa và lưu trữ → Tích hợp cơ chế lazy-load theo task → Đánh giá tự động bằng LLM-as-a-judge → Lặp lại quy trình dựa trên kết quả eval.

Bối Cảnh Cho Đội Ngũ Việt Nam

Tại Việt Nam, nhiều công ty phần mềm đang bắt đầu áp dụng AI vào quy trình phát triển. Tuy nhiên, không ít team vẫn mắc lỗi "nhồi nhét context" – đưa toàn bộ mã nguồn và tài liệu vào agent rồi chờ đợi điều kỳ diệu. Bài học từ bài trình bày này rất đáng giá: hãy bắt đầu nhỏ, tối ưu prompt/văn bản context trước khi nghĩ đến việc nâng cấp model.

Khi làm việc với các dự án outsourcing hoặc sản phẩm có khối lượng tài liệu lớn, việc áp dụng context engineering có thể giúp giảm 30-50% chi phí token và tăng tỷ lệ thành công của agent một cách đáng kể. Đó là một lợi thế cạnh tranh thực sự trong bối cảnh nguồn lực AI còn hạn chế.

Kết Luận

Thông điệp chính của Baruch Sadogursky và Patrick Debois rất rõ ràng: trong kiến trúc agentic, chất lượng context quan trọng hơn số lượng. Một hệ thống biết cách chọn đúng 300 token vào đúng thời điểm sẽ luôn vượt trội hơn một hệ thống cố nhét 100.000 token nhiễu vào cùng lúc.

Để xây dựng được hệ thống đó, các kỹ sư phần mềm và kiến trúc sư cần đầu tư vào việc thiết kế context như một thành phần kiến trúc riêng biệt – có cấu trúc, có phiên bản, có cơ chế tải linh hoạt và có hệ thống đánh giá. Đây chính là tương lai của việc phát triển phần mềm với AI: không phải là "giao toàn bộ cho máy", mà là "giao đúng thứ máy cần, đúng lúc máy cần".