Context engineering: chọn phần dữ liệu khách hàng mà model được thấy

Thử hình dung tuần thứ hai của bạn ở site khách hàng. Agent hỗ trợ đơn hàng chạy ổn trong demo, nhưng sang dữ liệu thật thì bắt đầu trả lời sai chính sách đổi trả. Điều lạ là file chính sách nằm ngay trong context, cùng với lịch sử chat, ba bảng dữ liệu đơn hàng và cả bộ FAQ.

Phản xạ đầu tiên của nhiều kỹ sư là sửa prompt: thêm chữ in hoa, thêm “hãy đọc kỹ chính sách”. Thường cách này không ăn thua, vì vấn đề không nằm ở cách bạn nói với model mà ở những gì model đang phải đọc.

Kỹ năng sửa đúng chỗ đó có tên là context engineering, và FDE nào làm việc với dữ liệu khách hàng đều cần có nó.

Prompt nói “làm gì”, context quyết định “biết gì”

Câu “hãy đọc kỹ chính sách” chỉ thay đổi cách bạn nói với model. Nó không thay đổi chuyện model đang phải đọc một file chính sách lẫn giữa lịch sử chat, bảng đơn hàng và FAQ. Elastic tách đúng chỗ này: prompt engineering lo phần giao tiếp, còn context engineering lo việc model được tiếp cận thông tin gì khi sinh câu trả lời.

Prompt engineering nhận context window như thứ có sẵn, còn context engineering chủ động chọn lọc nó. Ở agent đổi trả, chọn lọc nghĩa là quyết định có đưa ba bảng đơn hàng vào hay không, đưa cả bộ FAQ hay chỉ vài đoạn.

Anthropic gọi đó là việc chọn lọc và duy trì bộ token tối ưu trong lúc model suy luận, còn Prompting Guide nhấn mạnh việc thiết kế gồm cả chỉ dẫn lẫn context đi kèm.

Vì thế DataHub xếp prompt engineering là một thành phần của context engineering, không phải ngược lại: prompt bảo model làm gì, context quyết định model biết gì khi làm việc đó. Khi agent sai ở khách hàng, câu hỏi đầu tiên nên là “model đã thấy gì ở bước này?”, chưa phải “prompt viết sao cho hay hơn?”.

Vì sao nhồi thêm dữ liệu lại làm agent tệ đi?

Trực giác bảo rằng đưa model càng nhiều dữ liệu khách hàng thì nó càng hiểu bối cảnh. Anthropic chỉ ra điều ngược lại: khi context dài ra, khả năng model nhớ lại chính xác thông tin trong đó giảm xuống, hiện tượng họ gọi là context rot. Theo họ, LLM có một “attention budget” phải dùng dần khi đọc lượng context lớn.

Quay lại agent đổi trả. File chính sách có mặt trong context, nhưng nó phải tranh phần chú ý với hàng chục lượt chat cũ và hàng nghìn dòng đơn hàng không liên quan đến câu hỏi. Model không hỏng. Nó chỉ bị pha loãng.

LangChain, dẫn lời Andrej Karpathy, mô tả context engineering là nghệ thuật và khoa học của việc lấp context window bằng đúng thông tin cần cho bước tiếp theo. Chữ quan trọng ở đây là “bước tiếp theo”. Context không phải một kho cố định nạp một lần lúc khởi động, mà được lắp lại cho từng bước.

Bốn câu hỏi trước mỗi lần gọi model

LangChain gom các chiến lược context engineering thành bốn nhóm: write, select, compress và isolate. Bạn có thể dùng chúng như một checklist khi thiết kế agent cho khách hàng.

Tên gọi là của LangChain; cách hiểu dưới đây là cách áp bốn nhóm đó vào agent của khách. Write, hiểu theo nghĩa này, là ghi thông tin ra ngoài window để dùng lại sau, gần với phần bộ nhớ mà Prompting Guide xếp vào context engineering, gồm bộ nhớ ngắn hạn (quản lý trạng thái và lịch sử) và bộ nhớ dài hạn.

Select là chỉ kéo vào phần dữ liệu liên quan đến bước đang chạy. Compress là thu gọn những gì đã có, chẳng hạn bằng compaction mô tả ngay dưới đây. Isolate, theo cách đọc của checklist này, là tách các phần việc ra để mỗi phần chỉ mang context của riêng nó.

Hai kỹ thuật cụ thể từ Anthropic giúp bạn làm phần select và compress. Kỹ thuật đầu là just-in-time retrieval: agent chỉ giữ các định danh nhẹ, như ID đơn hàng hay đường dẫn tài liệu, và chỉ nạp dữ liệu thật khi cần, thay vì nạp sẵn mọi thứ.

Kỹ thuật còn lại là compaction: khi cuộc hội thoại gần chạm giới hạn window, tóm tắt nội dung của nó rồi chạy tiếp với bản tóm tắt.

Làm lại agent đổi trả, từng dòng một

Dưới đây là cách lắp context cho agent đổi trả sau khi áp dụng checklist. Đoạn code chỉ là phác thảo minh hoạ, nhưng cấu trúc thì có thể đem dùng thật.

def build_context(ticket, state):
    blocks = []

    # Chỉ dẫn cố định, ngắn, không lẫn dữ liệu
    blocks.append(("instructions", RETURN_AGENT_RULES))

    # Write: đọc lại ghi chú tiến độ thay vì toàn bộ lịch sử
    blocks.append(("progress_notes", state.notes))

    # Compress: lịch sử dài thì thay bằng bản tóm tắt
    history = state.history
    if count_tokens(history) > HISTORY_LIMIT:
        history = summarize(history)
    blocks.append(("conversation", history))

    # Select: chỉ những đoạn chính sách khớp với ticket
    blocks.append(("policy", search_policy(ticket.text, top_k=3)))

    # Just-in-time: chỉ đưa ID, chi tiết để agent tự gọi tool
    blocks.append(("order_ref", {"order_id": ticket.order_id}))

    return render_with_tags(blocks)

Thay đổi đầu tiên là bảng đơn hàng biến mất khỏi context. Agent chỉ thấy order_id, và khi thật sự cần ngày giao hay trạng thái thanh toán, nó gọi tool get_order(order_id) để lấy đúng bản ghi đó. Hàng nghìn dòng không liên quan không còn tranh chú ý với file chính sách.

Thay đổi thứ hai là cấu trúc. Prompting Guide liệt kê việc cấu trúc input và output, như dùng delimiter hay JSON schema, là một thành phần của context engineering. Hàm render_with_tags bọc mỗi khối trong một thẻ mang tên riêng như policy hay conversation, để model phân biệt được đâu là quy tắc, đâu là lời khách nói, đâu là dữ liệu hệ thống.

Output cũng nên có schema, chẳng hạn {"decision": ..., "policy_clause": ...}, để bạn kiểm tra được agent đã dựa vào điều khoản nào.

Thay đổi thứ ba là isolate. Nếu agent vừa phải tra chính sách vừa phải soạn email cho khách, hãy tách thành hai bước, mỗi bước mang context riêng. Bước soạn email chỉ cần quyết định cuối cùng và giọng văn của thương hiệu, không cần cả mười trang chính sách.

Ở khách hàng, bắt đầu từ log chứ không từ prompt

Trước khi sửa bất cứ thứ gì, hãy ghi lại nguyên văn context mà model nhận ở lần trả lời sai. Đọc log này là cách nhanh nhất để kiểm tra hai khả năng: thông tin cần thiết bị chôn giữa đống dữ liệu, hoặc hoàn toàn không có mặt.

Tiếp theo, với từng bước của agent, viết một dòng mô tả bước đó cần biết gì để làm đúng. Mỗi khối trong context phải trả lời được câu hỏi “khối này phục vụ dòng mô tả nào?”. Khối nào không trả lời được thì là ứng viên đầu tiên để bỏ, hoặc để chuyển thành tham chiếu just-in-time.

Cuối cùng, đo. Mỗi lần thay đổi context, chạy lại cùng một bộ eval và ghi lại hai con số: độ chính xác và số token trung bình mỗi lần gọi. Chính hai con số này giúp bạn thuyết phục khách hàng, và cũng là thứ đáng đưa vào CV.

Một dòng như “thiết kế lại context cho agent hỗ trợ đơn hàng, giảm token mỗi lần gọi trong khi giữ nguyên điểm eval” có sức nặng hơn nhiều so với “có kinh nghiệm prompt engineering”.

Những lỗi gặp đi gặp lại

Lỗi phổ biến nhất là sửa prompt khi vấn đề nằm ở context. Nếu model không thấy điều khoản đúng thì câu chỉ dẫn hay đến đâu cũng không cứu được.

Lỗi kế tiếp là để lịch sử hội thoại phình ra không giới hạn, cho đến khi agent bắt đầu quên những gì khách nói ở đầu cuộc trò chuyện. Đó chính là lúc cần compaction: tóm tắt lịch sử trước khi chạm giới hạn window, thay vì đợi agent quên.

Lỗi thứ ba là để tool trả về nguyên bản ghi. Một API của khách trả về JSON hàng trăm trường, và bạn chuyển thẳng nó vào context vì tiện. Hãy viết một lớp mỏng chỉ giữ các trường mà bước đó cần.

Lỗi thứ tư là trộn dữ liệu với chỉ dẫn mà không có delimiter, khiến model khó tách được đâu là quy tắc của hệ thống, đâu là nội dung khách hàng gửi vào.

Ở site khách hàng, dữ liệu luôn nhiều hơn mức model có thể chú ý. Việc của FDE là quyết định phần nào được đưa vào, và chịu trách nhiệm cho quyết định đó như với bất kỳ đoạn code nào khác.