Context Engineering: Cho AI đúng thông tin cần thiết, thay vì nhồi nhét càng nhiều càng tốt

Nếu bạn từng xây dựng bất kỳ ứng dụng AI nào phức tạp hơn một câu hỏi đơn lẻ, chắc hẳn bạn đã từng gặp một hiện tượng khá lạ: nhồi thêm thông tin vào prompt nhiều khi lại khiến kết quả tệ đi, chứ không tốt hơn. Càng nhiều tài liệu, càng nhiều lịch sử hội thoại, càng nhiều chỉ dẫn, mô hình lại càng dễ lạc đề, tự mâu thuẫn, hoặc bịa ra chi tiết không có thật. Cái bản năng đưa cho nó tất cả những gì mình có hóa ra lại âm thầm phá hỏng chính điều bạn muốn đạt được.

Đây chính là vấn đề mà context engineering sinh ra để giải quyết. Thuật ngữ này được biết đến rộng rãi từ tháng 6/2025, khi CEO Shopify Tobi Lütke mô tả nó là nghệ thuật cung cấp mọi thứ cần thiết để một tác vụ có thể được giải quyết một cách khả thi, và Andrej Karpathy sau đó công khai đồng tình, gọi đây là nghệ thuật và khoa học tinh tế của việc lấp đầy context window bằng đúng những thông tin cần cho bước tiếp theo. Vài tháng sau, Anthropic chính thức hóa khái niệm này trong tài liệu kỹ thuật của họ.

Bài viết này sẽ giải thích context engineering thực chất là gì, vì sao context window càng lớn cũng không giải quyết được vấn đề gốc rễ, các chiến lược cốt lõi mà giới kỹ thuật đang áp dụng, và điều này có ý nghĩa gì với bất kỳ ai đang sản xuất nội dung mà giờ đây chính các hệ thống AI cũng đọc.

Context Engineering là gì?

Context engineering là việc chọn lọc và duy trì tập hợp token tối ưu, tức là những thông tin mà mô hình ngôn ngữ nhìn thấy, ở từng bước trong quá trình xử lý. Nó bao trùm toàn bộ môi trường thông tin xung quanh mô hình: system prompt, lịch sử hội thoại, tài liệu được truy xuất, định nghĩa các công cụ (tool), bộ nhớ, và trạng thái theo thời gian thực.

Cách rõ ràng nhất để phân biệt nó với prompt engineering là nhìn vào câu hỏi mà mỗi bên đặt ra. Prompt engineering hỏi: nên diễn đạt yêu cầu này thế nào, và chỉ hoạt động trong phạm vi một lượt trao đổi. Context engineering hỏi: ngay lúc này, mô hình cần được tiếp cận những thông tin gì, và hoạt động xuyên suốt cả một tác vụ nhiều bước. Có thể nói prompt engineering thực chất chỉ là một tập con: nó xử lý lớp chỉ dẫn, còn context engineering quản lý toàn bộ hệ thống nuôi thông tin cho mô hình.

Sự dịch chuyển này quan trọng vì các ứng dụng AI đã đi từ chatbot trả lời một lần sang các agent chạy nhiều bước, gọi công cụ, và tích lũy lịch sử liên tục. Khi một hệ thống vận hành qua hàng chục lượt, việc quyết định giữ lại gì, bỏ gì, tóm tắt gì, hay truy xuất thêm gì trở thành bài toán kỹ thuật trung tâm.

Vì sao context window lớn hơn không giải quyết được vấn đề?

Phản biện dễ thấy nhất là: context window ngày càng lớn, có mô hình đã quảng cáo lên tới một hoặc hai triệu token, vậy tại sao còn phải tiết kiệm thông tin làm gì? Câu trả lời là vì chất lượng đầu ra đã suy giảm từ rất lâu trước khi context window bị lấp đầy.

Nghiên cứu về context rot của Chroma đã đánh giá 18 mô hình hàng đầu, bao gồm GPT-4.1, Claude 4, Gemini 2.5 và Qwen3, và phát hiện rằng độ chính xác giảm dần khi độ dài đầu vào tăng lên, ngay cả với những tác vụ đơn giản như truy xuất hay sao chép văn bản. Một mô hình được quảng cáo với context window 200.000 token đã có thể bộc lộ sự suy giảm đáng kể từ rất lâu trước khi chạm ngưỡng đó. Con số marketing chỉ là giới hạn trần, không phải vùng vận hành an toàn.

Vị trí đặt thông tin cũng quan trọng không kém. Nghiên cứu có sức ảnh hưởng lớn Lost in the Middle của Liu và cộng sự cho thấy mô hình sử dụng thông tin hiệu quả nhất khi thông tin đó nằm ở đầu hoặc cuối context, và gặp khó khăn nhất khi đoạn thông tin liên quan bị chôn vùi ở giữa.

Trong tài liệu Effective context engineering for AI agents, Anthropic lý giải nguyên nhân nằm ở ngân sách chú ý (attention budget) có giới hạn. Kiến trúc transformer tạo ra mối quan hệ giữa từng cặp token với nhau, nên khi đầu vào càng dài, độ chú ý càng bị kéo mỏng ra, trong khi bản thân mô hình cũng ít được huấn luyện trên những chuỗi cực dài. Mục tiêu thực tế, theo cách nói của Anthropic, là tìm ra tập hợp nhỏ nhất gồm những token có tín hiệu cao nhất, giúp tối đa hóa khả năng cho ra kết quả tốt. Hãy coi mỗi token là một khoản chi phí trừ vào một ngân sách có hạn.

Một context tốt trông như thế nào?

Tài liệu của Anthropic chia context hiệu quả thành vài thành phần đáng để thiết kế một cách có chủ đích:

• System prompt ở đúng độ cao: tránh cả hai thái cực, logic cứng nhắc liệt kê từng trường hợp cụ thể, lẫn chỉ dẫn mơ hồ giả định rằng mô hình đã hiểu ngữ cảnh của bạn. Nên hướng đến những chỉ dẫn đủ cụ thể để định hướng hành vi, nhưng vẫn đủ linh hoạt để mô hình có không gian phán đoán, được tổ chức thành các phần rõ ràng.
• Công cụ (tool) rõ ràng và tối giản: các tool nên độc lập, chịu lỗi tốt, và không mập mờ về thời điểm sử dụng. Các tool chồng chéo chức năng sẽ tạo ra những điểm quyết định khiến mô hình dễ chọn sai, vì vậy hãy chọn lọc tập hợp nhỏ nhất vừa đủ để hoàn thành công việc.
• Một vài ví dụ mẫu điển hình: một số ví dụ được chọn lọc kỹ, đa dạng, sẽ hiệu quả hơn nhiều so với danh sách dài các trường hợp ngoại lệ, vì ví dụ chính là một bức tranh đáng giá ngàn lời.
• Truy xuất đúng lúc (just-in-time retrieval): thay vì nạp sẵn toàn bộ tài liệu ngay từ đầu, các agent hiệu quả chỉ giữ những tham chiếu nhẹ như đường dẫn file hay câu truy vấn, và chỉ lấy dữ liệu thực tế khi cần đến, ngay tại thời điểm vận hành.

Cách làm này khá giống với cách con người làm việc: chỉ giữ trước mặt những gì thực sự liên quan, còn lại tra cứu khi cần, thay vì cố học thuộc toàn bộ kho tài liệu trước khi bắt tay vào việc.

Bốn chiến lược cốt lõi: Write, Select, Compress, Isolate

Khung tư duy thực tế được áp dụng rộng rãi nhất đến từ LangChain, chia context engineering thành bốn chiến lược:

• Write (Ghi lại): lưu thông tin ra bên ngoài context window để có thể tái sử dụng sau này. Bao gồm các scratchpad ghi chú tạm trong lúc xử lý tác vụ, và bộ nhớ dài hạn tồn tại xuyên suốt nhiều phiên làm việc, như cách Cursor hay ChatGPT tạo bộ nhớ từ các tương tác trước đó.
• Select (Chọn lọc): chỉ kéo lại đúng những thông tin liên quan. Đây chính là retrieval-augmented generation (RAG) áp dụng cho tài liệu, bộ nhớ, và cả mô tả công cụ. Nghiên cứu RAG-MCP cho thấy việc chỉ truy xuất những tool liên quan giúp tăng độ chính xác khi chọn tool lên hơn ba lần, từ 13,62% lên 43,13%, đồng thời giảm hơn một nửa số token trong prompt.
• Compress (Nén lại): chỉ giữ những token mà tác vụ thực sự cần. Ví dụ, Claude Code có bước auto-compact tự động tóm tắt lịch sử khi đã dùng hết khoảng 95% context window. Cắt bớt tin nhắn cũ và rút gọn kết quả tool quá dài dòng cũng là những phiên bản đơn giản hơn của cùng nguyên tắc này.
• Isolate (Tách biệt): chia context ra thành các đơn vị riêng biệt. Các hệ thống multi-agent cho mỗi sub-agent một context window và bộ công cụ riêng, sạch sẽ; còn việc chạy code trong môi trường sandbox giúp giữ những đối tượng nặng như hình ảnh hoàn toàn tách khỏi context chính.

Context có thể hỏng theo những cách nào?

Hiểu rõ các kiểu lỗi sẽ giúp phòng tránh dễ hơn. Drew Breunig đã liệt kê bốn cách phổ biến khiến việc quản lý context thất bại, được LangChain tổng hợp lại:

• Context poisoning (nhiễm độc context): một thông tin bịa (hallucination) lọt vào context, sau đó bị coi như sự thật và lặp lại nhiều lần.
• Context distraction (phân tán context): context quá dài khiến chính khả năng suy luận của mô hình bị suy giảm.
• Context confusion (nhiễu context): thông tin không liên quan làm lệch hướng câu trả lời.
• Context clash (xung đột context): context chứa thông tin mâu thuẫn nhau, kéo mô hình về phía một câu trả lời thiếu nhất quán.

Mỗi kiểu lỗi này đều là một lý do để chọn lọc kỹ càng, thay vì hào phóng nhồi nhét mọi thứ vào context.

Quản lý các tác vụ dài như thế nào?

Với những công việc vượt xa giới hạn một context window, Anthropic mô tả ba kỹ thuật có thể kết hợp hiệu quả với nhau:

• Compaction (nén lịch sử): tóm tắt lịch sử khi gần chạm giới hạn, để agent có thể tiếp tục làm việc mà mất mát thông tin ở mức tối thiểu. Thứ tự ưu tiên ở đây là giữ lại chi tiết quan trọng trước, rồi mới cắt bớt phần dư thừa. Xóa bỏ các kết quả tool đã cũ là điểm khởi đầu an toàn nhất.
• Ghi chú có cấu trúc: để agent tự ghi lại những ghi chú bền vững ra ngoài context window, như một danh sách to-do đang chạy hoặc một file ghi chú, rồi đọc lại sau đó. Công cụ memory (đang trong giai đoạn beta) của chính Anthropic cũng dùng cách tiếp cận dựa trên file để làm điều này.
• Kiến trúc sub-agent: một agent chính điều phối kế hoạch tổng thể, trong khi các sub-agent tập trung xử lý những tác vụ hẹp với context sạch riêng, rồi trả về bản tóm tắt cô đọng, thường chỉ khoảng 1.000 đến 2.000 token. Cách này giúp tách phần tìm kiếm chi tiết ra khỏi phần tổng hợp cuối cùng.

Điều này có ý nghĩa gì với nội dung và marketing?

Context engineering thường được nhìn nhận như một bài toán của người xây dựng agent, nhưng chính những nguyên lý này giờ đây cũng định hình cách nội dung sống sót trong AI search. Khi một answer engine tổng hợp câu trả lời, thực chất nó đang làm context engineering trên chính nội dung của bạn: truy xuất đoạn văn, đánh giá mức độ liên quan, rồi nhồi một ngân sách token tín hiệu cao có giới hạn vào câu trả lời của nó.

Điều này kéo theo một hệ quả trực tiếp. Những phát hiện đằng sau context rot và lost in the middle chính là lý do kỹ thuật vì sao một đoạn nội dung rõ ràng, tự thân đầy đủ, nêu câu trả lời ngay từ đầu, lại dễ được mô hình sử dụng hơn nhiều so với một bài viết dài dòng, vòng vo, chôn vùi ý chính ở đâu đó bên trong. Cùng một cấu trúc giúp nội dung dễ được AI trích dẫn, vốn là cốt lõi của GEO và AEO, cũng chính là thứ mà context engineering nội bộ tưởng thưởng. Viết để dễ truy xuất và viết để phù hợp với ngân sách chú ý hóa ra lại là cùng một kỷ luật.

Nếu bạn muốn nội dung của mình trở thành nguồn tín hiệu cao mà một hệ thống AI sẽ tìm đến, dịch vụ SEO và AI search của chúng tôi được xây dựng chính xác cho mục tiêu đó: cấu trúc nội dung sao cho dễ truy xuất, dễ tin tưởng, và dễ được trích dẫn trên cả Google, ChatGPT lẫn Perplexity. Để biết website của bạn hiện đang ở đâu, hãy liên hệ với chúng tôi để nhận một buổi đánh giá.