Claude Certification Guide

Quản lý context window trong Claude: Tránh bẫy tóm tắt lũy tiến

18 tháng 3, 2026 · 9 phút đọc

Mỗi tin nhắn bạn gửi cho Claude đều bao gồm toàn bộ lịch sử hội thoại. Cuộc trò chuyện càng kéo dài, payload đó càng phình to, và cuối cùng bạn chạm giới hạn context. Vì vậy bạn tóm tắt các lượt cũ hơn để giải phóng chỗ trống. Nghe có vẻ hợp lý. Vấn đề là việc tóm tắt âm thầm phá hủy chính xác dữ liệu mà hệ thống của bạn cần để hoàn thành công việc.

Những mẫu hình dưới đây là cách bạn quản lý context mà không mất thông tin quan trọng. Chúng xuất hiện lặp đi lặp lại trong bài thi Claude Certified Architect vì chúng phân biệt các bản thử nghiệm chạy được với các hệ thống sản xuất thực sự đứng vững.

Bẫy tóm tắt lũy tiến

Hãy tưởng tượng thế này. Một agent hỗ trợ khách hàng xử lý một phiên làm việc với hai vấn đề đang mở. Cuộc hội thoại phình to, hệ thống tóm tắt các lượt cũ hơn để giữ trong giới hạn context, và sau khi tóm tắt:

Trước: "Khách hàng muốn hoàn tiền $247.83 cho đơn hàng #8891 đặt ngày 3 tháng 3"

Sau: "Khách hàng muốn hoàn tiền cho một đơn hàng gần đây"

Số tiền, mã đơn hàng, ngày tháng. Biến mất. Agent bắt đầu gọi đó là "yêu cầu hoàn tiền gần đây của bạn" thay vì giao dịch cụ thể. Khách hàng nhận ra. Sự tin tưởng bốc hơi.

Đó chính là bẫy tóm tắt lũy tiến. Khi bạn nén lịch sử hội thoại, các giá trị số, ngày tháng, tỷ lệ phần trăm, và kỳ vọng khách hàng đã nêu ra đều bị nén thành các bản tóm tắt mơ hồ. Các mô hình tóm tắt tối ưu cho việc nén ngữ nghĩa, không phải bảo toàn dữ kiện. Chúng sẽ luôn giữ lại ý chính và bỏ đi các chi tiết cụ thể.

Cách khắc phục: khối dữ kiện vụ việc bền vững

Kéo các dữ kiện giao dịch vào một khối có cấu trúc nằm ngoài lịch sử được tóm tắt và được đưa vào mọi prompt:

pythonCopy

case_facts = {
    "customer_id": "CUST-44891",
    "issues": [
        {
            "order_id": "#8891",
            "amount": "$247.83",
            "date": "2026-03-03",
            "status": "refund_requested",
            "product": "Wireless headphones"
        },
        {
            "order_id": "#9102",
            "amount": "$89.99",
            "date": "2026-03-10",
            "status": "delivery_delayed",
            "expected_delivery": "2026-03-15"
        }
    ]
}

Khối này được chèn vào đầu system prompt ở mỗi lượt. Bạn có thể tóm tắt lịch sử hội thoại mạnh tay tới đâu tùy ý vì các dữ kiện cứng đã nằm riêng biệt:

pythonCopy

system_prompt = f"""You are a customer support agent.
 
CASE FACTS (always reference these exact values):
{json.dumps(case_facts, indent=2)}
 
CONVERSATION SUMMARY:
{summarised_history}
"""

Giờ đây mô hình luôn có sẵn số tiền, ngày tháng, và mã đơn hàng chính xác, bất kể bạn nén lịch sử hội thoại đến mức nào. Mẫu hình này là cốt lõi của Task 5.1 — Quản lý Context Window.

Cắt gọn kết quả tool

API tra cứu đơn hàng của bạn trả về hơn 40 trường. Địa chỉ giao hàng, địa chỉ thanh toán, mã kho hàng, mã theo dõi nội bộ, phân tích thuế, timestamp kiểm toán. Agent của bạn chỉ cần năm trong số đó: mã đơn hàng, trạng thái, số tiền, tên sản phẩm, và ngày giao hàng dự kiến.

Nếu bạn nối toàn bộ phản hồi API vào lịch sử hội thoại, bạn đang đốt token vào dữ liệu không liên quan và chèn ép thông tin thực sự quan trọng.

pythonCopy

def trim_order_result(raw_result: dict) -> dict:
    """Extract only the fields the agent needs."""
    return {
        "order_id": raw_result["order_id"],
        "status": raw_result["status"],
        "total_amount": raw_result["total_amount"],
        "product_name": raw_result["items"][0]["name"],
        "expected_delivery": raw_result.get("expected_delivery"),
    }

Thực hiện cắt gọn này trước khi bạn nối kết quả tool vào lịch sử hội thoại. Mô hình nhận được dữ liệu gọn gàng, tập trung thay vì một bức tường các trường mà nó không cần.

Khi nào nên cắt gọn mạnh tay

Cắt gọn khi:

  • Tool trả về dữ liệu có cấu trúc với hàng chục trường
  • Bạn chỉ quan tâm đến một số ít trường trong số đó cho tác vụ hiện tại
  • Cùng một tool được gọi nhiều lần trong một hội thoại (mỗi lần gọi ngốn thêm context)

Giữ nguyên toàn bộ output khi:

  • Người dùng có thể hỏi tiếp về bất kỳ trường nào
  • Tool trả về văn bản phi cấu trúc mà bạn không thể tóm tắt một cách đáng tin cậy
  • Bạn đang debug hoặc kiểm toán và tính đầy đủ mới là điều quan trọng

Hiệu ứng "lạc giữa dòng"

Các mô hình ngôn ngữ xử lý tốt thông tin nằm gần đầu và cuối của các input dài. Nội dung bị chôn vùi ở giữa? Nó nhận được ít sự chú ý hơn. Điều này đã được ghi nhận kỹ trong tài liệu nghiên cứu, và nó quan trọng rất nhiều khi bạn tổng hợp output từ nhiều tool hoặc agent.

Điều không nên làm: Đổ toàn bộ kết quả tool tuần tự vào một khối context dài.

Điều hiệu quả: Đặt bản tóm tắt các phát hiện chính lên đầu, sau đó mới đưa kết quả chi tiết bên dưới:

pythonCopy

aggregated_input = f"""KEY FINDINGS SUMMARY:
- Order #8891: Refund approved, processing in 3-5 business days
- Order #9102: Delivery delayed, new ETA 2026-03-20
 
DETAILED RESULTS:
{detailed_tool_output_1}
 
{detailed_tool_output_2}
 
{detailed_tool_output_3}
"""

Bản tóm tắt ở đầu có nghĩa là mô hình gặp phần quan trọng nhất trước tiên. Ngay cả khi nó chú ý ít hơn đến các phần chi tiết ở giữa, các dữ kiện then chốt đã được xử lý rồi.

Các tiêu đề mục rõ ràng cũng giúp ích. Chúng đóng vai trò như các tín hiệu truy xuất giúp mô hình nhảy thẳng đến thông tin cụ thể thay vì quét qua cả bức tường văn bản.

Tối ưu hóa agent thượng nguồn

Trong các hệ thống multi-agent, các agent thượng nguồn thường có xu hướng trả về mọi thứ: toàn bộ chuỗi suy luận, tính toán trung gian, dữ liệu thô đổ ra hàng loạt. Nếu agent hạ nguồn có ngân sách context giới hạn, tất cả sự dài dòng đó là token bị lãng phí.

Cách khắc phục khá đơn giản. Yêu cầu các agent thượng nguồn trả về structured output chỉ với những trường mà agent hạ nguồn cần:

pythonCopy

# Instead of: verbose reasoning + raw data
upstream_output_bad = """
I searched through the database and found several matching records.
After comparing the dates and cross-referencing with the shipping
logs, I determined that order #8891 was shipped on March 4th from
warehouse W-12 via carrier DHL with tracking number 1234567890...
(500 more words of reasoning)
"""
 
# Return structured data with metadata
upstream_output_good = {
    "order_id": "#8891",
    "ship_date": "2026-03-04",
    "carrier": "DHL",
    "tracking": "1234567890",
    "status": "in_transit",
    "confidence": "verified",
    "source": "shipping_database"
}

Phiên bản có cấu trúc chỉ dùng một phần nhỏ số token và vẫn bảo toàn mọi dữ kiện. Agent hạ nguồn nhận đúng những gì nó cần mà không phải thừa hưởng 500 từ suy luận mà nó sẽ không bao giờ dùng đến.

Nội dung này được đề cập trong Task 5.3 — Hội thoại dài.

Prompt caching

System prompt, định nghĩa tool, và dữ liệu tham chiếu của bạn không thay đổi giữa các request. Vậy tại sao phải xử lý lại chúng mỗi lần? Prompt caching của Claude cho phép bạn đánh dấu nội dung là có thể cache để nó chỉ được xử lý một lần và tái sử dụng:

pythonCopy

message = client.messages.create(
    model="claude-sonnet-4-6-20250514",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": long_system_prompt,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": user_query}]
)

Cache system prompt, mô tả tool, và bất kỳ dữ liệu tham chiếu nào không đổi. Lịch sử hội thoại thay đổi ở mỗi lượt, vì vậy đừng cache nó.

Kết quả là độ trễ thấp hơn và chi phí thấp hơn cho các workload sản xuất. Xem Task 5.2 — Prompt Caching để biết phân tích đầy đủ.

Các mẫu hình trong bài thi

Bài thi kiểm tra khả năng quản lý context qua các tình huống ứng dụng. Đây là những gì cần chú ý:

  1. "Agent nói 'đơn hàng gần đây của bạn' thay vì mã đơn hàng cụ thể." Đó là bẫy tóm tắt lũy tiến. Khắc phục bằng một khối dữ kiện vụ việc bền vững.

  2. "Context đầy sau 8 lần gọi tool." Kết quả tool dài dòng đang ngốn token. Cắt gọn về các trường liên quan trước khi nối vào.

  3. "Các phát hiện từ nguồn dữ liệu thứ ba bị thiếu trong báo cáo cuối cùng." Hiệu ứng lạc giữa dòng. Đặt bản tóm tắt phát hiện chính lên đầu.

  4. "Tăng kích thước context window" như một phương án gây nhiễu. Điều này chỉ trì hoãn vấn đề. Bài thi muốn các cách khắc phục về mặt cấu trúc (dữ kiện vụ việc, cắt gọn, vị trí đặt), không phải tăng dung lượng.

  5. "Chỉ thị mô hình bảo toàn số liệu trong khi tóm tắt." Đừng mắc bẫy này. Chỉ thị tóm tắt dựa trên prompt không đảm bảo bảo toàn dữ kiện. Hãy trích xuất dữ kiện theo cấu trúc thay vì vậy.

Làm việc qua toàn bộ lĩnh vực Quản lý Context cho cả sáu nội dung nhiệm vụ, hoặc tự kiểm tra bản thân với câu hỏi luyện tập.