Thiết kế kiến trúc đầu cuối

Claude chỉ là một khâu trong hệ thống. Trước nó có dữ liệu cần làm sạch, sau nó có kết quả cần kiểm và lưu, và quanh nó có người dùng góp ý. Kiến trúc tốt đặt từng việc vào đúng khâu.

Bài này giúp bạn trả lời: một hệ thống dùng Claude từ đầu tới cuối gồm những tầng nào, việc nào thuộc tầng nào, và phản hồi đi vào hệ thống bằng đường nào?

Ví dụ xuyên suốt: xử lý hồ sơ bồi thường bảo hiểm sức khoẻ

Một công ty bảo hiểm sức khoẻ nhận hồ sơ bồi thường qua app: ảnh chụp hoá đơn viện phí, giấy ra viện, đơn thuốc. Họ muốn dùng Claude để đọc hồ sơ, xếp loại (ngoại trú, nội trú, nha khoa), lấy ra các trường như số tiền, ngày khám, chẩn đoán, đối chiếu với hợp đồng của khách, rồi đưa cho nhân viên thẩm định duyệt. Cuối tháng lượng hồ sơ tăng gấp ba ngày thường.

Bốn tầng của hệ thống

Một kiến trúc đầu cuối (end-to-end architecture) đi theo chuỗi đầu vào → xử lý → đầu ra → vòng phản hồi (input → processing → output → feedback loops). Trong đề, phần xử lý thường được chia rõ hơn thành ba lớp: tiền xử lý (Pre-Processing), tầng model (Model Stage) và hậu xử lý (Post-Processing).

Mẹo xếp tầng: đi theo đường dữ liệu chảy qua hệ thống. Việc nào xảy ra trước khi gọi model là tiền xử lý, việc nào do model làm là tầng model, việc nào dùng kết quả model là hậu xử lý.

Khi tầng model là một agent

Nếu tầng model chỉ là một lần gọi Claude, mọi thứ đơn giản. Nhưng khi Claude cần tự tra hợp đồng, tra danh mục thuốc rồi mới kết luận, tầng model là một vòng lặp agent (agent loop). Docs của Agent SDK mô tả vòng lặp này: mỗi lượt, Claude trả về chữ và/hoặc các lời gọi tool; nếu có lời gọi tool thì tool được chạy và kết quả đưa lại cho Claude; vòng lặp dừng khi Claude trả lời mà không gọi tool nào nữa. Câu trả lời đó là đầu ra.

Vòng lặp không tự giới hạn. Agent SDK có max_turns và max_budget_usd, mặc định là không giới hạn, và kết quả cuối có loại (subtype) cho biết vòng lặp xong bình thường (success) hay dừng vì chạm giới hạn lượt, giới hạn chi phí hoặc lỗi. Chỉ loại success mới có câu trả lời, nên phải kiểm loại trước khi dùng kết quả.

Tool nào do ai chạy

Docs về tool use nói rõ: model không bao giờ tự chạy gì cả. Nó chỉ gửi yêu cầu gọi tool, còn việc chạy thuộc về một trong hai bên:

Server tool chạy trong một vòng lặp phía Anthropic có giới hạn số lần lặp. Nếu chạm giới hạn khi chưa xong, phản hồi trả về stop_reason là pause_turn: việc chưa xong, bạn gửi lại hội thoại (kèm phản hồi đó) để Claude làm tiếp.

Khi nào thật sự cần tool

Docs gợi ý dùng tool khi việc có tác dụng phụ (ghi, gửi, đổi trạng thái), cần dữ liệu mới hoặc bên ngoài, cần đầu ra đúng một hình dạng, hoặc phải gọi hệ thống có sẵn. Không cần tool cho việc model làm được từ chính nội dung đã có, như tóm tắt hay dịch, vì mỗi lần gọi tool tốn thêm ít nhất một lượt đi về. Docs còn đưa một dấu hiệu dễ nhớ: nếu bạn đang viết regex để móc một quyết định ra khỏi câu trả lời của model, thì quyết định đó lẽ ra phải là một lời gọi tool.

Thứ tự an toàn và chịu tải

Nếu hệ thống có truy xuất tài liệu (RAG), bước xác thực và phân quyền phải chạy trước bước truy xuất. Như vậy truy xuất mới lọc được theo người hỏi: nhân viên chi nhánh Đà Nẵng chỉ thấy hồ sơ của chi nhánh mình. Nếu truy xuất trước rồi mới lọc trong câu trả lời, dữ liệu không được phép đã nằm trong context của model. Cũng vì an toàn, log hội thoại không được chứa nguyên số giấy tờ tuỳ thân, kể cả với lý do "để có thêm dữ liệu tinh chỉnh".

Cuối tháng hồ sơ tăng gấp ba. Nếu app gọi thẳng Claude cho từng hồ sơ, lúc cao điểm sẽ gặp giới hạn tốc độ và lỗi hàng loạt. Cách làm quen thuộc là đặt một hàng đợi bất đồng bộ (asynchronous queue) giữa bước nhận hồ sơ và bước gọi model: hồ sơ vào hàng đợi, các worker lấy ra xử lý với tốc độ hệ thống chịu được.

Hướng dẫn ticket routing của Anthropic cũng nhắc một lựa chọn ở khâu nhận đầu vào: hệ thống nguồn tự đẩy sự kiện sang qua webhook (push), hoặc dịch vụ của bạn định kỳ kéo dữ liệu mới về (pull). Đẩy thì mở rộng tốt hơn nhưng phải mở một endpoint công khai. Kéo thì dễ làm hơn, nhưng kéo quá dày thì tốn lượt gọi thừa, kéo quá thưa thì chậm.

Vòng phản hồi: trong lượt chạy và sau khi chạy

Phản hồi đi vào hệ thống bằng hai đường.

Trong lượt chạy, để sửa ngay kết quả của lượt này:

• Kết quả tool: tra hạn mức thấy hồ sơ vượt mức, Claude nhận kết quả đó và điều chỉnh kết luận.
• Hook: đoạn code chạy ở những điểm cố định của vòng lặp, ví dụ PreToolUse chạy trước mỗi lần gọi tool. Hook chạy trong process ứng dụng, không tốn context, và có thể chặn một lời gọi tool; Claude nhận lý do bị chặn thay cho kết quả. Trong ví dụ, một hook chặn mọi lần ghi kết quả thẩm định có số tiền vượt hạn mức hợp đồng. Một dòng dặn trong system prompt không chắc được tuân thủ mọi lần; hook thì lần nào cũng chạy.
• Bộ chấm riêng: Claude Managed Agents có tính năng outcome (đang beta). Bạn mô tả kết quả mong muốn kèm một rubric, hệ thống tự dựng một grader chấm sản phẩm theo rubric và gửi nhận xét lại cho agent sửa, tối đa max_iterations vòng (mặc định 3, tối đa 20). Grader dùng một context window riêng để không bị ảnh hưởng bởi cách agent chính đã làm. Đây là lý do không nên để agent tự chấm bài của chính nó.

Sau khi chạy, để lần sau tốt hơn: mỗi lần nhân viên thẩm định sửa một trường Claude trích sai, hệ thống ghi lại hồ sơ gốc, kết quả của Claude và bản sửa. Những ca này:

1. Thêm vào bộ test (evaluation set) để lần sửa prompt sau chạy lại và so sánh.
2. Cho biết loại hồ sơ nào hay sai, để ưu tiên cải thiện.
3. Theo dõi theo thời gian: tỉ lệ phải sửa tăng lên là dấu hiệu dữ liệu đầu vào đã đổi.

Docs của Anthropic về đánh giá khuyên làm bộ test sát với việc thật và tự động hoá việc chấm khi có thể. Dữ liệu từ vòng phản hồi chính là nguồn ca test sát thực tế nhất.