Context Engineering là gì? Từ prompt đến context

Định nghĩa

Context Engineering là thực hành lựa chọn, cấu trúc và đưa thông tin đúng vào Context Window để AI có thể thực hiện tác vụ với độ chính xác cao. Đây là sự chuyển dịch paradigm từ câu hỏi "viết prompt sao cho hay" sang "đưa gì cho AI để nó hiểu đúng và làm đúng".

Giải thích chi tiết

Khi prompt không còn là bottleneck

Sau 6 tháng nghiên cứu Prompt Engineering, bạn nhận ra một sự thật phũ phàng: cùng một câu hỏi "tối ưu", GPT-4 trả lời hay hơn GPT-3.5 đúng 30%, nhưng cùng model GPT-4 với context đầy đủ so với context sơ sài khác biệt đến 400%.

Prompt Engineering giống như cách bạn hỏi đường: "Anh/chị cho em hỏi đường đến nhà sách như thế nào?". Context Engineering là việc bạn đưa bản đồ, địa chỉ cụ thể, hoặc dẫn người hỏi đến tận nơi. Cái sau luôn hiệu quả hơn, bất kể bạn hỏi lịch sự hay không.

Context Window: "RAM" chứ không phải "ổ cứng"

Người mới hay hiểu nhầm AI "nhớ" được cuộc trò chuyện dài. Sự thật là Context Window giống RAM máy tính hơn: khi bạn mở conversation mới, RAM xóa sạch. AI không "học" được từ lần dùng trước trừ khi bạn đưa thông tin đó vào lại.

Context Engineering quản lý "RAM" này: quyết định trong 128K token (khoảng 200 trang A4), bạn sẽ dành chỗ cho cái gì? Để lại toàn bộ code repository hay chỉ file liên quan? Đưa 100 email cũ hay chỉ 3 email quan trọng nhất? Đọc thêm về giới hạn này trong bài Context Window.

Token Economics: Chi phí ẩn của thông tin

Mỗi token trong context đều tốn tiền và tốn thời gian xử lý (latency). Đưa 10.000 token vào prompt có thể khiến thời gian phản hồi tăng gấp 3 và chi phí tăng gấp 10 so với 1.000 token.

Nhưng bỏ bớt context để tiết kiệm tiền lại khiến AI trả lời sai, phải sửa đi sửa lại — tốn tiền hơn nhiều. Context Engineering là nghệ thuật tìm "sweet spot": đưa đủ để AI hiểu, bỏ đủ để không tốn kém. Tìm hiểu cách tính chi tiết trong Token và Pricing.

Information Architecture: Thứ tự là vua

Không phải cứ nhét dữ liệu vào là xong. LLM có "recency bias" (nhớ thông tin cuối cùng hơn) và "primacy bias" (chú ý đầu tiên). Đưa hướng dẫn quan trọng ở giữa đoạn text dài tương đương với việc giấu nó đi.

Context Engineering bao gồm việc sắp xếp: đặt instruction rõ ràng ở đầu hoặc cuối, để "few-shot examples" (ví dụ mẫu) theo thứ tự từ dễ đến khó, và loại bỏ "noise" (thông tin nhiễu) như định dạng file rườm rà.

Ví dụ thực tế

Phân tích hợp đồng pháp lý

Prompt: "Đánh giá rủi ro trong điều khoản thanh toán này"

Trường hợp A - Không có Context Engineering:

• Chỉ gửi prompt trên (20 token)
• AI trả lời: "Bạn nên kiểm tra thời hạn thanh toán, phạt trễ hạn, và điều khoản bảo lãnh. Hãy đảm bảo quyền lợi cân bằng giữa hai bên..." (Generic, vô dụng)

Trường hợp B - Có Context Engineering:

• Context bao gồm: Toàn văn hợp đồng (3.000 token) + Điều 246 Bộ luật Dân sự liên quan đến thanh toán (200 token) + 2 case tương tự đã xảy ra tranh chấp (800 token)
• AI trả lời: "Điều 4.2 có mâu thuẫn với Điều 246 BLDS: yêu cầu thanh toán trước 15 ngày nhưng không có quy định bảo lãnh. Case #2023/HC đã tuyên bố vô hiệu điều khoản tương tự. Rủi ro: 85% khả năng bị khiếu nại..."

Chi phí: Trường hợp B tốn gấp 200 lần token input, nhưng giá trị pháp lý tạo ra cao gấp 1000 lần.

Chatbot kỹ thuật cho công ty SaaS

Tình huống: Khách hàng báo lỗi "Server bị chậm"

Không có Context Engineering: AI trả lời: "Bạn vui lòng kiểm tra kết nối mạng và khởi động lại máy chủ thử nhé." (Template, khách hàng đã thử 10 lần)

Có Context Engineering: Context được inject gồm:

• Log lỗi 500 dòng gần nhất từ server của user (3.000 token)
• Gói dịch vụ của khách (Pro/Enterprise) để biết resource limit
• 5 ticket gần nhất cùng user để biết lịch sử sửa chữa
• Tài liệu internal về lỗi "Slow Query" mùa cao điểm

AI trả lời: "Phát hiện 47 slow queries từ database user_logs lúc 14:32. Với gói Pro của bạn, limit là 100 concurrent connections nhưng hiện tại đang có 147. Lỗi này giống ticket #4021 tháng trước — giải pháp là scale lên gói Enterprise hoặc implement caching theo guide /docs/cache-redis..." (Chính xác, actionable)

Code review với context đầy đủ

Prompt: "Review đoạn code này và tìm bug"

def process_payment(user_id, amount):
    user = get_user(user_id)
    if user.balance >= amount:
        user.balance -= amount
        save(user)

Context nghèo nàn: Chỉ đoạn code trên → AI bảo "có thể thiếu try-catch".

Context giàu có:

• Toàn bộ file payment.py (để thấy hàm save không có transaction)
• Schema database (để thấy race condition giữa get và save)
• Business rule: "Không được phép balance âm dưới mọi trường hợp"
• 3 PR gần nhất thay đổi cùng file (để thấy logic đã từng bị refactor lại)

Kết quả: AI phát hiện race condition nghiêm trọng và suggest dùng atomic transaction hoặc Redis lock — lỗi production có thể gây mất tiền.

Ứng dụng

Developer xây dựng AI-powered tools

Bạn không cần fine-tune model đắt tiền. Thay vào đó, xây dựng RAG để tự động lấy code từ repository, tài liệu API, và coding standards đưa vào context trước khi gọi LLM. Kết quả code generation chính xác hơn 80% so với zero-shot prompting.

Product Manager viết PRD cho AI

Khi dùng AI viết User Stories, đừng chỉ gõ "Viết user story cho feature đăng nhập". Hãy đưa context gồm: Persona cụ thể (độ tuổi, thiết bị), ràng buộc kỹ thuật (phải hỗ trợ SSO), và 3 user story tốt nhất từ sprint trước (few-shot). AI sẽ viết story phù hợp business logic thay vì template chung chung.

Data Analyst tự động hóa báo cáo

Thay vì copy-paste số liệu vào chat, dùng Context Engineering để đưa schema database, định nghĩa metrics (cách tính "churn" của công ty bạn khác công ty khác), và 3 báo cáo mẫu đúng chuẩn format. AI sẽ tạo SQL query và phân tích phù hợp semantic của business bạn.

So sánh

Kết luận: Prompt Engineering và Context Engineering không loại trừ nhau mà bổ trợ. Prompt Engineering là "kỹ năng cơ bản" để giao tiếp, Context Engineering là "kỹ năng nâng cao" để xây dựng sản phẩm. Khi bạn chuyển từ "dùng AI cho vui" sang "xây AI cho doanh nghiệp", Context Engineering trở thành yếu tố quyết định thành bại.

Bài viết liên quan

Cùng cụm: Nền tảng Context

Đọc tiếp