Context Engineering cho Chatbot sản phẩm

Định nghĩa

Context Engineering cho chatbot là nghệ thuật tổng hợp thông tin — từ kiến thức sản phẩm (RAG), lịch sử trò chuyện (Memory), đến dữ liệu thời gian thực (Tool Use) — để đưa vào Context Window đúng lúc, biến AI từ "người trả lời chung chung" thành "chuyên gia hỗ trợ khách hàng thực thụ".

Giải thích chi tiết

Bốn trụ cột của Context Pipeline

Chatbot sản phẩm không thể sống bằng System Prompt và kiến thức huấn luyện sẵn. Bạn cần một pipeline đưa dữ liệu động vào mỗi lượt gọi API:

1. Context Window — Góc nhìn tức thời Không phải "trí nhớ dài hạn" mà là "tầm nhìn hiện tại". Chatbot chỉ "thấy" những gì bạn đưa vào tin nhắn lần này: câu hỏi hiện tại + lịch sử ngắn vừa đủ. Thiết kế đúng nghĩa là quản lý sliding window — giữ 5-10 turn gần nhất, summarize cũ hơn, chứ không gửi toàn bộ cuộc trò chuyện 3 tháng làm phung phí token.

2. RAG — Kiến thức bên ngoài Sản phẩm thay đổi mỗi tuần: giá mới, chính sách đổi trả cập nhật, tính năng vừa ra mắt. RAG (Retrieval-Augmented Generation) truy xuất đoạn tài liệu liên quan từ vector store, đưa vào prompt như "tài liệu tham khảo". Khác với fine-tune, RAG cho phép cập nhật kiến thức trong vòng dưới 1 phút mà không cần train lại model.

3. Memory — Trạng thái phiên làm việc Thông tin người dùng vừa cung cấp trong cuộc trò chuyện này: tên, ID đơn hàng, vấn đề đang gặp. Khác với RAG (tĩnh), Memory là động — bạn lưu vào Redis hoặc database phiên (session_id), rồi inject vào context mỗi turn.

4. Tool Use — Dữ liệu thời gian thực Chatbot cần "làm việc" chứ không chỉ "nói chuyện". Tra cứu tồn kho, tạo ticket hỗ trợ, gửi email xác nhận — tất cả cần gọi API bên ngoài. Kết quả tool call (ví dụ: "Đơn hàng #123 đang ở kho Hà Nội") phải được đưa vào context ngay turn tiếp theo để AI trả lời dựa trên facts thực.

Lỗi thường gặp khi thiếu Context Engineering

Triệu chứng "Amnesia ngắn hạn": Người dùng hỏi "Cái đó giá bao nhiêu?" sau 3 turn thảo luận về sản phẩm X. Chatbot hỏi lại "Bạn đang nói sản phẩm nào?" — thất bại vì không maintain entity trong memory.

Triệu chứng "Knowledge tĩnh": Chatbot trả lời chính sách đổi trả 30 ngày, trong khi công ty đã đổi thành 15 ngày từ tuần trước. AI dựa vào training cutoff, không query RAG.

Triệu chứng "Hallucination hành động": Chatbot tự tin nói "Tôi đã hủy đơn hàng cho bạn" trong khi thực tế chưa gọi API nào — vì tool result không được confirm vào context.

Token Budget và Trade-off

Context Window là tài nguyên hạn chế (thường 4k-128k token). Chiến lược phân bổ cho chatbot sản phẩm:

• 30% System Prompt + Persona
• 40% RAG results (top-k chunks, k=3-5)
• 20% Conversation History (compressed)
• 10% Tool results + Scratchpad

Nếu vượt ngưỡng, bạn phải cắt bớt — đây là lúc summary memory và reranking RAG trở nên quan trọng.

Ví dụ thực tế

Chatbot hỗ trợ khách hàng thương mại điện tử

Tình huống: Khách hàng vào chat hỏi "Đơn #12345 sao chưa tới?"

Context Pipeline thiết kế:

# 1. Memory: Lấy thông tin phiên trước
user_context = get_memory(session_id)  
# Kết quả: {"user_id": "U789", "last_order": "12345"}

# 2. Tool: Query trạng thái đơn hàng
order_status = query_api(order_id="12345")  
# Kết quả: {"status": "đang giao", "location": "kho Hà Nội"}

# 3. RAG: Retrieve chính sách giao hàng
policy_chunks = retrieve("chính sách giao hàng Hà Nội delay")

# 4. Assemble Context
messages = [
    {"role": "system", "content": "Bạn là nhân viên hỗ trợ. Thông tin: {policy_chunks}"},
    {"role": "user", "content": f"Khách hàng {user_context} hỏi: Đơn #12345 sao chưa tới?"},
    {"role": "assistant", "content": f"Thông tin tra được: {order_status}"}
]

Kết quả: AI trả lời: "Chị ơi, đơn #12345 đang ở kho Hà Nội, dự kiến giao trong 2 giờ tới ạ. Nếu cần đổi địa chỉ, em hỗ trợ ngay." — Không hỏi lại ID, không bịa thông tin, không đề xuất chính sách cũ.

Chatbot tư vấn tài chính với xử lý chuyển chủ đề

Thách thức: Người dùng đang hỏi "lãi suất tiết kiệm 6 tháng" thì bất ngờ chuyển sang "cho vay mua nhà". Nếu giữ nguyên RAG context cũ, AI sẽ trả lời nhầm lẫn hai loại sản phẩm.

Giải pháp Context Engineering:

Sử dụng Intent Router để phát hiện chuyển chủ đề (topic shift), sau đó flush RAG context và memory slot liên quan:

if detect_intent_shift(current_query, previous_intent):
    # Xóa context cũ, chỉ giữ entity người dùng (tên, ID)
    truncate_rag_context()
    retrieve_new_documents(intent="vay mua nhà")

Kết quả: Chatbot phản hồi như người tư vấn thực — nhận ra khách đã chuyển mục tiêu, không gộp lãi suất tiết kiệm vào gói vay.

Debug RAG cho chatbot nội bộ

Vấn đề: Chatbot trả lời sai quy trình nội bộ dù đã có tài liệu.

Chẩn đoán Context: Khi inspect context window, phát hiện RAG retrieve được tài liệu từ năm 2022 (version cũ) thay vì 2024.

Fix: Thêm metadata filtering vào retrieval: filter={"date": {"$gt": "2024-01-01"}} và re-ranking dựa trên recency.

Insight: Lỗi không phải ở model (GPT-4 vẫn trả lời sai nếu đọc tài liệu lỗi), mà ở Context Engineering — pipeline đưa thông tin sai vào "tầm nhìn" của AI.

Ứng dụng

Cho Developer xây dựng hệ thống

Thiết kế kiến trúc Context Assembler — một service đứng giữa user message và LLM API, nhiệm vụ: (1) fetch memory từ Redis, (2) query vector DB, (3) gọi tool nếu cần, (4) cắt gọn để vừa token limit. Đừng để frontend gửi trực tiếp lên LLM — đó là cách để lộ business logic và tốn token vô ích.

Cho Product Manager tối ưu chi phí

Token = tiền. Mỗi turn chat tốn 2k-4k token với context đầy đủ. Giải pháp: implement summarization — mỗi 10 turn, summarize thành 1 turn "memory compressed", giảm 70% token cho phần history.

Cho Doanh nghiệp vừa và nhỏ (SME)

Không cần fine-tune model đắt tiền. Dùng GPT-3.5 hoặc Claude Instant + RAG tài liệu sản phẩm + Memory đơn giản (lưu vào file JSON theo session_id) — hiệu quả vượt trội chatbot generic dùng GPT-4 nhưng thiếu context.

So sánh

Kết luận: Chatbot sản phẩm không cần model mạnh nhất, cần context đúng nhất. Sự khác biệt giữa trải nghiệm "như người thật" và "như robot nguội lạnh" nằm ở việc bạn có đưa đúng thông tin vào tầm nhìn của AI hay không.

Bài viết liên quan

Cùng cụm

Đọc tiếp