Claude nằm ở đâu trong hệ thống (Claude / systems / humans)

Ai làm việc gì? Mỗi solution đều có 3 bên đảm nhiệm: Việc phân bổ sớm là chìa khóa thành công

Mọi solution bạn thiết kế với Claude đều rơi vào một trong ba nhóm đảm nhiệm:

Các Architects đôi khi gộp cả 3 nhóm công việc này thành "những gì Claude làm", nhưng việc giao quá nhiều nhiệm vụ cho Claude hầu như luôn khiến quy trình trở nên đắt đỏ hơn, chậm hơn và khó quản lý hơn. Mấu chốt là phải biết Claude làm tốt nhất điều gì và nó nên chịu trách nhiệm cho phần nào trong solution của bạn.

Ủy quyền (Delegation): Quyết định phần việc tin tưởng giao cho Claude

Quá trình decomposition sẽ tạo ra một delegation map (bản đồ ủy quyền). Với mỗi phần của yêu cầu, bạn không chỉ quyết định xem liệu Claude có thể làm được hay không, mà là liệu Claude có nên own (đảm nhiệm) nó hay không:

• Công việc phù hợp với AI (AI-appropriate work)

• Công việc giữ lại cho con người (human-retained work)

• Công việc phối hợp (collaborative work) nơi Claude soạn thảo bản nháp và con người đưa ra quyết định.

Hãy biện minh cho từng sự phân bổ dựa trên 3 tiêu chí:

• Tính khả đảo (Reversibility): Một quyết định sai có thể đảo ngược/sửa chữa được không?

• Mức độ rủi ro (Stakes): Một quyết định sai sẽ trả giá bằng điều gì?

• Trách nhiệm giải trình (Accountability): Ai sẽ là người phải chịu trách nhiệm cho kết quả đó?

Phần này sẽ dạy bạn tính kỷ luật trong ủy quyền – năng lực đầu tiên trong 4 năng lực AI Fluency. 4 đặc tính hành vi giúp bạn biết Claude có thể tin tưởng được ở đâu đã được giảng dạy ở phần nền tảng; tại đây bạn sẽ áp dụng chúng.

Kịch bản thực tế: Phân rã yêu cầu của đối tác và phân bổ từng bước cho đúng bên

Một đối tác yêu cầu xây dựng một "trợ lý phân loại hồ sơ bồi thường (claims triage assistant) có khả năng đọc hồ sơ bồi thường, quyết định mức độ ưu tiên, tra cứu phạm vi bảo hiểm, và gửi email cho người thẩm định (adjuster'])".

Bản năng đầu tiên của một Architect có thể là đưa cả 4 bước này vào nhóm "Những gì Claude làm", nhưng lăng kính 4 đặc tính sẽ ngăn sai lầm đó xảy ra:

1. "Đọc hồ sơ bồi thường" (Read the claim): Hoàn toàn nằm trong vùng năng lực của Claude. Đọc và phiên giải một hồ sơ bồi thường là công việc ngôn ngữ giàu patterns, và nếu output schema được ràng buộc chặt chẽ, cả next-token prediction lẫn steerability đều hỗ trợ tốt cho bạn. Đây là công việc do Claude đảm nhiệm.

2. "Quyết định mức độ ưu tiên" (Decide priority): Bước này có vẻ giống một tác vụ ngôn ngữ, nhưng thực tế không phải. Mức độ ưu tiên là một quy tắc định tính (deterministic rule) mà đối tác của bạn vốn đã định nghĩa và duy trì. Yếu tố được tính là ưu tiên trong tổ chức của đối tác nằm trong một rules engine, chứ không nằm trong training data của Claude. Định tuyến phần này cho Claude sẽ đưa vào một ranh giới tri thức (knowledge limitation) không cần thiết. Thay vào đó, Claude gọi rules engine và hệ thống hiện tại (existing system) sẽ đảm nhiệm việc quyết định mức độ ưu tiên.

3. "Tra cứu phạm vi bảo hiểm" (Look up policy coverage): Vấn đề tương tự như quyết định ưu tiên, nhưng với stakes (mức độ rủi ro) cao hơn. Các hợp đồng bảo hiểm thay đổi và bảng phạm vi bảo hiểm được cập nhật thường xuyên, trong khi model không có cách nào đảm bảo biết được khi nào phiên bản nó học trong quá trình huấn luyện dừng cập nhật. Câu trả lời phải đến từ hệ thống đang nắm giữ dữ liệu bảo hiểm thực tế (live coverage data), được truy xuất thông qua tool use hoặc một MCP server.

4. "Gửi email cho người thẩm định" (Email the adjuster): Bước này cần được chia nhỏ. Việc soạn thảo nội dung email (drafting) là công việc ngôn ngữ và do Claude đảm nhiệm. Việc gửi email thuộc về hệ thống email hiện tại. Con người cần xem xét và phê duyệt (review and approve) bất kỳ quyết định nào vượt quá ngưỡng giá trị quy định, bởi nếu Claude tự mình quyết định hoàn toàn, cả giới hạn về working-memory lẫn steerability của nó đều trở thành rủi ro lớn.

Quá trình decomposition nên được dẫn dắt bằng cách trả lời câu hỏi: "Tại sao 4 đặc tính lại ủng hộ việc dùng Claude thay vì hệ thống vốn đã làm đúng việc này?" thay vì câu hỏi "Claude có thể hỗ trợ ở đâu?". Hãy chú ý kỹ sự thay đổi trong cách đặt vấn đề này, đây là khái niệm then chốt mà module này đang hướng tới.

Chi phí · Độ phức tạp · Rủi ro

• Chi phí (Cost): Mọi thao tác tra cứu lẽ ra một hệ thống deterministic đơn giản có thể xử lý được lại được gửi cho Claude. Bạn rốt cuộc phải trả tiền cho model để làm công việc mà một truy vấn CSDL (database query) hoặc một rules table có thể làm với chi phí chỉ bằng một phần nhỏ, và trên hàng nghìn requests, chi phí đó sẽ tích tụ rất nhanh.

• Độ phức tạp (Complexity): Khi bạn chuyển logic ra khỏi một hệ thống dựa trên bảng (table-driven system) và đưa vào model, các lỗi sẽ không còn vết để truy vết (traceable). Một quy tắc deterministic thất bại theo cách có thể dự đoán và debug được. Một model xử lý cùng công việc đó lại tạo ra các đầu ra biến thiên (variable outputs), vốn khó theo dõi và chẩn đoán hơn rất nhiều.

• Rủi ro (Risk): Model không có cách nào đáng tin cậy để biết khi nào thông tin của nó đã lỗi thời, và nó sẽ không cảnh báo khoảng trống đó. Khi model trở thành source of truth thay vì hệ thống thực tế của đối tác, các câu trả lời mang tính thẩm quyền có thể lặng lẽ chệch hướng mà không hề có lỗi nào được bắn ra hay lời cảnh báo nào được đưa ra.