Domain 5: Context Management & Reliability — Ôn thi CCA-F

#Task 5.1: Quản lý conversation context để bảo toàn thông tin quan trọng qua các cuộc hội thoại dài

#Knowledge of (Kiến thức về)

• Rủi ro tóm tắt lũy tiến (Progressive summarization): Làm trôi mất các thông số giao dịch cứng (ngày, số tiền, mã đơn, kỳ vọng khách hàng) thành các câu tóm tắt chung chung mơ hồ.
• Hiệu ứng Lost in the middle: LLM xử lý tốt thông tin ở đầu và cuối ngữ cảnh đầu vào, dễ bỏ sót hoặc hiểu sai thông tin nằm ở giữa.
• Tích lũy token của Tool: Cách tool result tích lũy trong context gây lãng phí token (VD: tool tra cứu đơn trả về 40 trường dữ liệu trong khi chỉ có 5 trường liên quan đến đổi trả).
• Tính nhất quán của lịch sử: Bắt buộc truyền đầy đủ lịch sử hội thoại trong API request kế tiếp để giữ tính mạch lạc.

#Skills in (Kỹ năng về)

• Trích xuất Case Facts: Tách các thông số giao dịch cứng vào một block [CASE FACTS] tĩnh, được đính kèm cố định trong mỗi prompt gửi đi để không bị ảnh hưởng bởi quá trình tóm tắt lịch sử chat.
• Cắt gọn Tool Output: Chỉ lọc giữ các trường dữ liệu thực sự cần thiết của tool response trước khi đẩy vào context.
• Sắp xếp vị trí thông tin: Đặt phần tóm tắt kết luận ở đầu ngữ cảnh, và tổ chức nội dung chi tiết phía sau có chia heading rõ ràng để giảm tác động của hiệu ứng Lost in the middle.
• Trích dẫn đầu ra: Bắt buộc các subagent con trả về siêu dữ liệu (metadata, nguồn, trang, ngày xuất bản) để coordinator thực hiện tổng hợp chính xác.
• Trích xuất dữ liệu ra lớp context riêng biệt: Thực hiện lưu trữ dữ liệu giao dịch có cấu trúc (order ID, số tiền, trạng thái) vào một tầng ngữ cảnh riêng biệt (separate context layer) đối với các phiên làm việc xử lý nhiều vấn đề cùng lúc (multi-issue sessions).
• Điều chỉnh Agent Upstream để tối ưu hóa context: Sửa đổi các agent upstream (VD: search/analysis agent) để chỉ trả về dữ liệu có cấu trúc tinh gọn (key facts, citations, relevance scores) thay vì các đoạn văn xuôi dài dòng kèm chuỗi lập luận (reasoning chains), nhằm bảo toàn context budget cho các agent downstream.

// Ví dụ cấu trúc Case Facts Block đặt ở đầu System Prompt mỗi lượt gọi:
[CASE FACTS]
- Customer ID: C-99120 (Verified)
- Order ID: #A-20412
- Refund Claimed: $120.00 (Standard policy limit: $500.00)
- Issue Type: Damaged product on delivery

#🧠 Phân tích & Thực tế từ Delivery Manager:

Trong các dự án chatbot hỗ trợ kỹ thuật lớn, khi lịch sử chat đạt đến 20 lượt, việc tóm tắt lũy tiến (progressive summarization) rất dễ vô tình xóa bỏ mã lỗi thô ban đầu và chỉ ghi "hệ thống báo lỗi kết nối". Để tránh việc này, tôi bắt buộc dev phải duy trì một Context Layer riêng (như một bảng trạng thái bằng JSON) được gửi đi kèm. Đồng thời, các search agent con phải được cấu hình để trả về dữ liệu dạng bảng/lists thay vì chép nguyên văn trang tài liệu vào context.

#Task 5.2: Thiết kế mẫu escalation và giải quyết ambiguity hiệu quả

#Knowledge of (Kiến thức về)

• Điều kiện escalate đúng đắn:
  • Khách hàng chủ động yêu cầu gặp người thực.
  • Yêu cầu vượt ngoài chính sách quy định (policy gaps/exceptions).
  • Agent bị kẹt vòng lặp (loop) và không thể tiến triển thêm.
• Chỉ số không đáng tin: Sentiment (sự giận dữ) của khách và điểm tự tin tự báo cáo (self-reported confidence) của LLM không phản ánh đúng độ phức tạp nghiệp vụ của case.
• Giải quyết trùng lặp (Ambiguity): Khi tool trả về nhiều kết quả trùng tên khách hàng, bắt buộc agent phải hỏi xin thêm thông tin định danh (email/SĐT), cấm dùng mẹo phỏng đoán để chọn bừa.

#Skills in (Kỹ năng về)

• Quy định ranh giới escalate: Đưa tiêu chí cụ thể kèm few-shot examples vào system prompt để agent phân định rõ lúc nào cần escalate.
• Tôn trọng ý kiến khách hàng: Chuyển ngay cho người thực nếu khách yêu cầu, không cố tình giữ lại điều tra thêm gây phiền hà.
• Xử lý khách hàng nóng tính: Xoa dịu cảm xúc, offer hướng giải quyết nếu nằm trong quyền hạn; chỉ escalate nếu khách tiếp tục nhấn mạnh muốn gặp người.
• Escalate khi chính sách không đề cập (Policy Gaps): Cưỡng chế agent thực hiện escalate ngay lập tức khi gặp các yêu cầu nằm ngoài phạm vi bao phủ của tài liệu chính sách (VD: khách yêu cầu đối chiếu giá với đối thủ cạnh tranh - competitor price matching - trong khi chính sách công ty chỉ quy định về giảm giá nội bộ).
• Xác minh thông tin khi trùng kết quả: Chỉ dẫn agent chủ động đặt câu hỏi yêu cầu khách hàng cung cấp thêm các trường định danh duy nhất (VD: email, SĐT) khi kết quả gọi tool trả về nhiều bản ghi trùng khớp, cấm dùng thuật toán phỏng đoán (heuristics) để tự ý chọn một bản ghi.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Nhiều dev thích cấu hình phân tích cảm xúc (sentiment analysis) để escalate khi khách chửi thề. Tuy nhiên, thực tế vận hành cho thấy nhiều khách hàng cực kỳ lịch sự nhưng yêu cầu của họ lại hoàn toàn không có trong quy chế xử lý tự động. Escalate dựa trên sự mơ hồ của chính sách (Policy Gap) quan trọng hơn nhiều so với việc chỉ dựa trên cảm xúc nhất thời của khách.

#Task 5.3: Triển khai chiến lược lan truyền lỗi (Error Propagation) trong multi-agent

#Knowledge of (Kiến thức về)

• Ngữ cảnh lỗi cấu trúc: Trả về mã lỗi chi tiết (loại lỗi, query đã thử, kết quả một phần và hướng xử lý) giúp coordinator quyết định hướng phục hồi thông minh.
• Tránh nuốt lỗi: Nuốt lỗi (trả về kết quả rỗng marked là thành công) hoặc hủy bỏ toàn bộ workflow khi 1 subagent lỗi đều là anti-patterns.
• Phân biệt Access Failure vs Empty Result: Lỗi kết nối (timeout, API sập) cần được phân biệt rõ với truy vấn thành công nhưng không có kết quả khớp (empty result) để có quyết định xử lý khác nhau.
• Tác hại của Generic Error: Trả về mã lỗi chung chung (VD: "search unavailable") sẽ giấu đi ngữ cảnh quý giá của subagent, khiến coordinator không thể đưa ra hướng sửa đổi phù hợp.

#Skills in (Kỹ năng về)

• Ghi nhận lỗ hổng thông tin (Gap annotations): Nếu subagent thất bại vì nguồn dữ liệu lỗi kết nối, coordinator cần ghi nhận cụ thể lỗ hổng này vào báo cáo cuối để người đọc nắm được.
• Phục hồi lỗi cục bộ: Subagent tự retry lỗi transient, chỉ báo cáo lên coordinator khi đã cạn lượt thử.
• Trả error context đầy đủ: Thiết kế subagent trả về cấu trúc lỗi chi tiết chứa: loại lỗi, hành động đã thử, kết quả một phần (partial results) và các phương án thay thế để coordinator ra quyết định.
• Phân định lỗi truy cập trong báo cáo: Phân định rõ ràng lỗi access failures và kết quả rỗng hợp lệ trong error reporting để coordinator không cố gắng thực hiện retry vô ích khi truy vấn thực chất đã thành công.

// Ví dụ cấu trúc trả lỗi chuẩn của subagent về cho coordinator:
{
  "status": "failed",
  "errorCategory": "access_failure",
  "whatAttempted": "Query API endpoint /v1/orders/123",
  "partialResults": { "orderId": "123", "status": "retrieved_partially" },
  "message": "Backend database connection timeout after 3 attempts.",
  "isRetryable": true
}

#🧠 Phân tích & Thực tế từ Delivery Manager:

Khi một subagent tìm kiếm tài liệu nội bộ bị sập do lỗi phân quyền (permission error), nếu nó chỉ trả về một chuỗi rỗng "" (nuốt lỗi), coordinator sẽ nghĩ rằng "tài liệu này không tồn tại" và trả lời khách hàng sai lệch. Tôi luôn yêu cầu viết code bắt lỗi hiển thị chi tiết nguyên nhân: do hệ thống sập hay do không tìm thấy, để coordinator có thể xin lỗi khách hoặc báo cáo admin sửa quyền truy cập.

#Task 5.4: Quản lý context hiệu quả khi khảo sát codebase lớn

#Knowledge of (Kiến thức về)

• Context degradation: Trong session quá dài, Claude sẽ bắt đầu trả lời chung chung dựa trên "pattern điển hình" thay vì code thực tế đã đọc.
• Scratchpad file: Sử dụng file nháp để lưu trữ các thông tin kiến trúc quan trọng làm "neo bộ nhớ" chéo qua các lượt chat.
• Lưu trữ trạng thái có cấu trúc để phục hồi (Crash Recovery): Cơ chế giúp hệ thống tự phục hồi sau khi sập bằng cách bắt mỗi agent định kỳ xuất trạng thái (state exports) ra một thư mục chỉ định, và coordinator sẽ tải file manifest này khi resume session.

#Skills in (Kỹ năng về)

• Ủy thác cho Subagent khảo sát: coordinator spawn subagent đi đọc code chi tiết rồi gửi tóm tắt về, giữ cho context coordinator luôn sạch.
• Dọn dẹp bộ nhớ: Chủ động chạy lệnh /compact để dọn dẹp các log terminal và tool call thô dư thừa khỏi context.
• Tóm tắt chéo giữa các phase khám phá: Thực hiện tóm tắt các phát hiện quan trọng từ một pha khảo sát trước khi spawn subagent cho pha tiếp theo, inject bản tóm tắt này trực tiếp vào context ban đầu của subagent mới.
• Thiết kế crash recovery bằng manifests: Lập trình cơ chế phục hồi sập bằng cách xuất state của agent ra file JSON và cấu hình coordinator tự động load manifest này khi khôi phục session, tự động inject các tham số cần thiết vào prompt.
• Sử dụng scratchpad file ngăn thoái hóa ngữ cảnh: Yêu cầu các agent duy trì một file scratchpad.md ghi nhận các hàm đã trace và sơ đồ dependency, liên tục đọc/ghi file này thay vì dựa vào bộ nhớ hội thoại để tránh context degradation.

// Ví dụ cấu trúc Manifest file phục vụ crash recovery:
{
  "sessionName": "refactor-db-layer",
  "lastCompletedPhase": "phase_2_analysis",
  "activeAgents": ["GrepAgent", "ReadAgent"],
  "manifestState": {
    "filesAnalyzed": ["src/db/connection.ts", "src/db/pool.ts"],
    "detectedDependencies": ["pg", "slonik"]
  }
}

#🧠 Phân tích & Thực tế từ Delivery Manager:

Khi chạy các task refactor codebase lớn tự động qua đêm, khả năng sập giữa chừng do mất mạng hoặc mất điện là hoàn toàn có thể xảy ra. Nếu không thiết kế cơ chế lưu trữ manifest và crash recovery, sáng hôm sau dev sẽ phải chạy lại từ đầu và tốn gấp đôi tiền API. Tôi luôn yêu cầu hệ thống phải export state sau mỗi phase thành công.

#Task 5.5: Thiết kế workflow kiểm duyệt thủ công (Human Review) và hiệu chuẩn confidence

#Knowledge of (Kiến thức về)

• Rủi ro từ chỉ số trung bình: Chỉ số gộp (overall accuracy) cao có thể che giấu việc hệ thống chạy cực kỳ lỗi trên một loại tài liệu đặc thù.
• Stratified random sampling: Lấy mẫu ngẫu nhiên phân tầng đối với các ca trích xuất có điểm tự tin (confidence) cao để đo lường tỷ lệ lỗi thực tế và phát hiện các lỗi mới phát sinh.
• Confidence calibration: Sử dụng một tập dữ liệu validation có nhãn sẵn để hiệu chuẩn (calibrate) ngưỡng điểm confidence của mô hình trước khi cho phép tự động hóa hoàn toàn.
• Field-level confidence: Đo lường điểm tự tin cho từng trường dữ liệu cụ thể (VD: số tiền hóa đơn vs tên nhà cung cấp) thay vì chỉ đo điểm tự tin chung cho toàn bộ tài liệu.

#Skills in (Kỹ năng về)

• Phân khúc kiểm thử: Phân tích độ chính xác theo từng loại tài liệu và trường thông tin cụ thể trước khi giảm tỷ lệ kiểm duyệt của con người.
• Định tuyến thông minh: Route các ca trích xuất có điểm confidence thấp hoặc nguồn dữ liệu mâu thuẫn/mơ hồ sang cho con người kiểm duyệt.
• Trích xuất và Calibrate điểm confidence cấp trường: Thiết lập yêu cầu mô hình xuất ra điểm tự tin ở cấp độ từng trường thông tin (field-level confidence scores), sau đó sử dụng một tập validation có nhãn (labeled validation set) để hiệu chuẩn ngưỡng định tuyến kiểm duyệt phù hợp.
• Áp dụng Stratified random sampling thực tế: Triển khai lấy mẫu ngẫu nhiên phân tầng định kỳ trên nhóm dữ liệu tự động ghi có confidence cao để theo dõi tỷ lệ lỗi thực tế và phát hiện các pattern lỗi mới phát sinh.

// Ví dụ output trích xuất kèm điểm confidence cấp trường (field-level):
{
  "invoiceNumber": { "value": "INV-2026-001", "confidence": 0.99 },
  "totalAmount": { "value": 450.00, "confidence": 0.98 },
  "dueDate": { "value": null, "confidence": 0.65 } // Hệ thống sẽ tự động route trường này sang human review vì confidence < 0.85
}

#🧠 Phân tích & Thực tế từ Delivery Manager:

Rất nhiều đội ngũ kỹ thuật kiêu ngạo tuyên bố "Agent của chúng tôi đạt 98% độ chính xác". Khi tôi kiểm tra, hóa ra nó trích xuất đúng 100% tên công ty nhưng sai tới 25% số tiền hóa đơn trên các tài liệu viết tay. Phải luôn yêu cầu đo độ chính xác cấp trường (field-level) và định tuyến thông minh dựa trên ngưỡng đã được hiệu chuẩn (calibrated threshold).

#Task 5.6: Bảo toàn provenance thông tin và xử lý bất định trong multi-source synthesis

#Knowledge of (Kiến thức về)

• Mất nguồn gốc (Provenance loss): Việc tóm tắt và gộp dữ liệu qua nhiều bước làm mất đi ánh xạ nguồn gốc (claim-source mapping).
• Temporal data: Bắt buộc subagent trích xuất kèm ngày thu thập/ngày xuất bản để tránh việc hai số liệu đo tại hai mốc thời gian khác nhau bị coi là mâu thuẫn logic.
• Xử lý mâu thuẫn dữ liệu từ các nguồn uy tín: Cách thức chú thích chi tiết nguồn gốc cho các dữ liệu mâu thuẫn thay vì tự ý chọn hoặc tính trung bình cộng.

#Skills in (Kỹ năng về)

• Bảo toàn provenance: Đảm bảo subagent trả dữ liệu cấu trúc dạng { claim, excerpt, source_url } và synthesis agent giữ nguyên ánh xạ này khi tổng hợp báo cáo.
• Xử lý mâu thuẫn dữ liệu: Khi hai nguồn uy tín đưa ra số liệu khác nhau, bắt buộc phải đưa cả hai số liệu vào báo cáo cuối kèm nguồn và ngày cụ thể, không được tự ý lựa chọn một con số hoặc tính trung bình cộng.
• Phân chia cấu trúc báo cáo (Well-established vs Contested): Thiết kế cấu trúc báo cáo cuối cùng phân chia rõ ràng thành các mục: Thông tin đã được kiểm chứng đồng thuận (well-established findings) và Thông tin còn gây tranh cãi/mâu thuẫn (contested findings), bảo toàn nguyên vẹn phương pháp luận và bối cảnh của tài liệu nguồn.
• Render định dạng nội dung phù hợp: Lập trình để synthesis agent xuất dữ liệu đúng định dạng hiển thị phù hợp nhất với loại dữ liệu đó (VD: hiển thị dữ liệu tài chính/số liệu dưới dạng bảng - tables, tin tức dạng prose, và các phát hiện kỹ thuật dưới dạng structured lists) thay vì gộp chung tất cả thành văn bản thô đồng nhất.

// Ví dụ cấu trúc trích xuất giữ provenance và thông tin thời gian:
{
  "claim": "Doanh số xe điện đạt 1.2 triệu chiếc năm 2025",
  "provenance": {
    "sourceName": "EV Reports 2025",
    "sourceUrl": "https://evreports.org/2025",
    "pageNumber": 14,
    "retrievedDate": "2026-07-10T10:00:00Z"
  }
}

#🧠 Phân tích & Thực tế từ Delivery Manager:

Khi làm việc với các hệ thống AI tổng hợp thông tin thị trường cho ban giám đốc, việc mất nguồn gốc (provenance loss) là điều tối kỵ. Ban giám đốc sẽ không tin tưởng báo cáo nếu không có link nguồn cụ thể cho từng con số. Tôi luôn thiết lập quy chuẩn thiết kế: mọi bảng số liệu trong báo cáo tổng hợp phải có một cột đi kèm chỉ rõ URL nguồn và ngày thu thập dữ liệu.

Quay lại Trang Hub ôn thi CCA-F.