Claude Certification Guide
0% chương trình học đã hoàn thành

Thuật ngữ: Quản lý Context & Độ tin cậy

Context Window

Số lượng token tối đa (đầu vào cộng đầu ra) mà Claude có thể xử lý trong một lệnh gọi API. Các model Claude khác nhau có kích thước context window khác nhau (ví dụ 200K token cho Claude 3.5 Sonnet). Mọi thứ trong cuộc hội thoại — system prompt, lịch sử tin nhắn, định nghĩa tool, và phản hồi — đều phải nằm trong giới hạn này.

Bối cảnh thi: Nắm rõ kích thước context window của các model Claude hiện tại và cách tính tổng lượng token sử dụng. Đề thi kiểm tra các chiến lược để giữ trong giới hạn: tóm tắt, cắt bớt tin nhắn, và ưu tiên hóa nội dung.

Xem thêm: 5.1 Context Window Management


Prompt Caching

Một tính năng của API cho phép cache nội dung prompt được tái sử dụng thường xuyên, giúp giảm độ trễ và chi phí cho các yêu cầu tiếp theo. Nội dung được cache (như system prompt, định nghĩa tool, hoặc tài liệu lớn) được đánh dấu bằng cache_control và được lưu trữ trong một khoảng thời gian tồn tại (TTL). Cache hit được tính phí ở mức thấp hơn.

Bối cảnh thi: Nắm rõ cách bật caching (cache_control: { type: "ephemeral" }), những gì có thể được cache (system prompt, tool, tin nhắn), và yêu cầu về thứ tự — nội dung được cache phải đứng trước nội dung không được cache. Hiểu rõ hành vi TTL của cache.

Xem thêm: 5.2 Prompt Caching


Rate Limiting

Các giới hạn do API áp đặt nhằm hạn chế số lượng request, token đầu vào, hoặc token đầu ra mà một người dùng có thể tiêu thụ trong một khoảng thời gian. Rate limit được áp dụng theo từng tổ chức và từng model. Khi vượt giới hạn, API trả về mã trạng thái 429. Xử lý đúng cách bao gồm exponential backoff và xếp hàng request.

Bối cảnh thi: Nắm rõ sự khác biệt giữa giới hạn requests-per-minute (RPM) và tokens-per-minute (TPM). Đề thi kiểm tra các chiến lược xử lý rate limit: retry với backoff, xếp hàng request, và phân phối tải theo thời gian.

Xem thêm: 5.4 Rate Limiting & Quotas


Quotas

Giới hạn sử dụng giới hạn tổng mức tiêu thụ API trong một chu kỳ thanh toán. Khác với rate limit (hạn chế thông lượng), quota giới hạn tổng mức sử dụng (ví dụ mức chi tiêu tối đa mỗi tháng). Quota được cấu hình trong Anthropic Console và có thể được thiết lập ở cấp tổ chức hoặc workspace.

Bối cảnh thi: Hiểu rõ sự khác biệt giữa rate limit (thông lượng) và quota (tổng mức sử dụng). Nắm rõ cách theo dõi mức tiêu thụ quota và thiết lập cảnh báo trước khi chạm giới hạn.

Xem thêm: 5.4 Rate Limiting & Quotas


Monitoring

Việc theo dõi mức sử dụng API, các chỉ số hiệu năng, và tỷ lệ lỗi trong các ứng dụng Claude ở môi trường production. Các chỉ số quan trọng bao gồm độ trễ phản hồi, mức tiêu thụ token, tỷ lệ lỗi, tỷ lệ thành công của tool call, và chi phí mỗi request. Monitoring giúp phát hiện sớm sự cố và tối ưu hóa dựa trên dữ liệu.

Bối cảnh thi: Nắm rõ những chỉ số cần theo dõi cho một triển khai Claude ở môi trường production. Đề thi kiểm tra khả năng thiết kế một chiến lược monitoring bao quát hiệu năng, chi phí, và độ tin cậy.

Xem thêm: 5.5 Monitoring & Observability


Observability

Khả năng hiểu được trạng thái nội bộ của một hệ thống dùng Claude thông qua việc xem xét đầu ra của nó. Observability vượt xa monitoring bằng cách cung cấp trace chi tiết cho từng request riêng lẻ, bao gồm nội dung prompt, lệnh gọi tool, phản hồi của model, và phân tích độ trễ. Framework tracing và structured logging là các công cụ observability cốt lõi.

Bối cảnh thi: Hiểu rõ sự khác biệt giữa monitoring (chỉ số tổng hợp) và observability (trace từng request riêng lẻ). Đề thi có thể hỏi về việc triển khai tracing cho agentic loop khi có nhiều lệnh gọi API xảy ra trong một request người dùng.

Xem thêm: 5.5 Monitoring & Observability


Token Counting

Quá trình đo lường số token mà một prompt hoặc phản hồi tiêu thụ. Token là các đơn vị nhỏ hơn từ — khoảng 3-4 ký tự mỗi token trong tiếng Anh. Phản hồi API bao gồm input_tokensoutput_tokens trong trường usage. Đếm token chính xác là điều thiết yếu cho việc quản lý context window và ước tính chi phí.

Bối cảnh thi: Nắm rõ cách đọc trường usage trong phản hồi API. Đề thi kiểm tra nhận thức rằng số lượng token bao gồm toàn bộ nội dung (system prompt, tin nhắn, định nghĩa tool) và các loại nội dung khác nhau có tỷ lệ token-trên-ký-tự khác nhau.

Xem thêm: 5.1 Context Window Management


Cache Breakpoints

Các điểm đánh dấu trong mảng tin nhắn xác định nơi nội dung được cache kết thúc và nội dung mới bắt đầu. Trường cache_control với type: "ephemeral" được đặt trên tin nhắn hoặc content block được cache cuối cùng. Nội dung trước breakpoint có thể được phục vụ từ cache; nội dung sau breakpoint được xử lý mới cho mỗi request.

Bối cảnh thi: Nắm rõ quy tắc đặt cache breakpoint. Đề thi kiểm tra hiểu biết rằng breakpoint phải được đặt một cách có chiến lược — quá nhiều breakpoint lãng phí dung lượng cache, trong khi quá ít làm giảm tỷ lệ cache hit.

Xem thêm: 5.2 Prompt Caching


Extended Thinking

Một tính năng của Claude phân bổ một ngân sách "suy nghĩ" riêng trước khi model tạo ra phản hồi hiển thị. Khi được bật, Claude dùng các token suy luận nội bộ (không hiển thị trong đầu ra cuối cùng theo mặc định) để giải quyết các vấn đề phức tạp. Điều này cải thiện độ chính xác cho các tác vụ đòi hỏi suy luận, phân tích, hoặc lập kế hoạch nhiều bước.

Bối cảnh thi: Nắm rõ cách bật extended thinking qua API (tham số thinking với giá trị budget_tokens). Hiểu rõ token suy nghĩ được tính vào giới hạn token đầu ra và được tính phí tương ứng. Nắm rõ khi nào extended thinking hữu ích và khi nào là chi phí phát sinh không cần thiết.

Xem thêm: 5.1 Context Window Management


Batches API

Một endpoint API để gửi khối lượng lớn request được xử lý bất đồng bộ với chi phí thấp hơn. Request theo lô được xếp hàng và xử lý trong một cửa sổ 24 giờ. Kết quả được lấy về bằng cách polling trạng thái lô. Cách này lý tưởng cho các tác vụ xử lý ngoại tuyến như sinh nội dung hàng loạt, đánh giá, hoặc trích xuất dữ liệu.

Bối cảnh thi: Nắm rõ lợi thế chi phí của Batches API (thường rẻ hơn 50% so với request thời gian thực) và sự đánh đổi của nó (không đảm bảo thời gian hoàn thành trong cửa sổ 24 giờ). Hiểu rõ khi nào xử lý theo lô phù hợp so với khi nào cần xử lý thời gian thực.

Xem thêm: 5.4 Rate Limiting & Quotas