Các hình thái mà ngành công nghiệp đã phải trả giá để rút ra bài học

Kiến trúc tham chiếu: Thiết kế chuẩn trông như thế nào và dự án thường đi sai hướng ở đâu

Các reference architectures chỉ mang tính tham khảo, không phải là bản thiết kế cố định bắt buộc phải tuân theo tuyệt đối. Mục tiêu không phải là ép bài toán của đối tác vào một thiết kế cố định có sẵn. Mỗi khối lượng công việc (workload) của đối tác đều là duy nhất, vì vậy mục tiêu của bạn ở đây là hiểu đủ sâu các mô hình phổ biến này để có thể khái quát hóa từ chúng, tùy biến cho bài toán trước mắt và nhận biết khi nào một khối lượng công việc đòi hỏi kết hợp nhiều patterns cùng lúc.

Hầu hết các bài toán của đối tác đều ánh xá tới một trong số ít các reference architectures đã được chứng minh hiệu quả trong hệ sinh thái của Claude:

1. Agent

• Thiết kế chuẩn (What good looks like): Model hướng tới một mục tiêu bằng cách tự quyết định gọi tools nào và theo thứ tự nào. Quyền tự quyết (autonomy) được kiểm soát bằng cách giới hạn năng lực của tools và thiết lập turn limit (ngưỡng số lượt trao đổi). Dùng mô hình này khi luồng công việc không thể viết trước: điều tra một codebase, tổng hợp từ nhiều nguồn nghiên cứu, hoặc phân loại/xử lý các ca khách hàng phức tạp.

• Đi sai hướng (Where projects go wrong): Quyền tự quyết không giới hạn (unbounded autonomy): Trao cho model các tools có khả năng thay đổi trạng thái (change state) mà không có con người duyệt, không có turn limit, và không có cách đo lường liệu mục tiêu đã đạt được hay chưa.

2. Retrieval-augmented generation (RAG)

• Thiết kế chuẩn: Một kho tri thức ổn định (stable knowledge corpus) như tài liệu hướng dẫn sản phẩm, tài liệu nội bộ, hoặc văn bản quy định được chia nhỏ (chunked) và đánh chỉ mục (indexed). Khi có câu hỏi, các chunks liên quan nhất sẽ được truy xuất (retrieved) và đưa vào context cho model.

• Đi sai hướng: Dùng RAG để trả lời các câu hỏi về live state (trạng thái thời gian thực): trạng thái đơn hàng, số lượng tồn kho, hàng chờ ticket. Index thực chất là một bức ảnh chụp nhanh (snapshot). Nếu dữ liệu gốc đã thay đổi kể từ lần refresh cuối, câu trả lời chắc chắn sẽ sai.

3. Document processing pipeline → Evaluator-optimizer

• Thiết kế chuẩn: Trích xuất dữ liệu có cấu trúc từ tài liệu bán cấu trúc như hồ sơ bồi thường, hóa đơn, hợp đồng. Pipeline xử lý OCR, trích xuất các trường dữ liệu theo schema, kiểm tra đầu ra và định tuyến các luồng ngoại lệ. Mô hình evaluator-optimizer rất phổ biến ở đây vì việc trích xuất ngay lần đầu tiên (first-pass extraction) đối với các trường hợp biên (edge cases) không đủ tin cậy để tin tưởng nếu thiếu bước kiểm tra.

• Đi sai hướng: Không có luồng xử lý ngoại lệ (exception path). Các dữ liệu trích xuất có độ tin cậy thấp (low-confidence extractions) lại đi chung một pipeline với tài liệu sạch mà không có human gate để chặn những trường hợp model làm sai.

4. Customer-service / ticket triage → Routing

• Thiết kế chuẩn: Phân loại ý định (intent) và yêu cầu của người dùng, sau đó route đến đúng hệ thống phía sau: tầng knowledge retrieval cho câu hỏi tài liệu, transactional API cho các truy vấn live state (trạng thái đơn hàng, thay đổi tài khoản), và human approval layer cho các hành động có rủi ro cao.

• Đi sai hướng: Dùng retrieval cho trạng thái đơn hàng thay vì gọi trực tiếp API. Không có luồng leo thang (escalation path) cho con người. Triển khai biến thể agent trước khi đo lường kỹ lưỡng routed workflow đơn giản hơn.

5. Coding agent (Khám phá dạng agentic kết hợp các bước chỉnh sửa/kiểm thử/review định tính)

• Thiết kế chuẩn: Công việc chia làm 2 giai đoạn. Đầu tiên, agent điều tra codebase để hiểu cần thay đổi điều gì (phần này mang tính agentic vì luồng đi qua một codebase xa lạ không thể lập trình trước). Thứ hai, các bước chỉnh sửa thực tế tuân theo quy trình định tính (deterministic): phân tích (parse), lập kế hoạch (plan), đề xuất (propose), kiểm thử (test), đánh giá (review). Các subagents xử lý các tác vụ cô lập với đủ ngữ cảnh để làm việc nhưng không quá nhiều khiến các bước trở nên mất kiểm soát.

• Đi sai hướng: Cho phép agent tự chỉnh sửa và commit mà không có human review gate. Không theo dõi tỷ lệ lỗi phát sinh (regression rates) so với bộ eval set cho từng ngôn ngữ/framework. Đối xử với toàn bộ hệ thống như một cuộc trò chuyện thay vì một structured pipeline với các điểm bàn giao rõ ràng.

Cách quyết định bài toán cần một hay nhiều patterns

Các bài toán thực tế của đối tác thường nằm ở ranh giới giữa hai kiến trúc. Một routing workflow có thể chuyển một số ý định nhất định sang một vòng lặp điều tra dạng agentic. Một document processing pipeline có thể dùng RAG trên văn bản chính sách khi gặp trường hợp ngoại lệ. Việc vận dụng nhiều hơn một pattern đôi khi là câu trả lời chính xác.

Điều quan trọng là lý do bạn cần đến pattern thứ hai. Đừng nghĩ patterns là các mảnh ghép lego chỉ việc lắp lại. Hãy nhìn vào lý do tại sao mỗi pattern hoạt động tốt và điều chỉnh tư duy cho phù hợp. Chỉ dùng thêm pattern thứ hai khi hai phần của bài toán thất bại theo những cách khác nhau và cần được quản lý riêng biệt. Nếu bạn dùng thêm pattern thứ hai chỉ vì chưa xác định rõ mình đang giải quyết bài toán gì, hãy điều chỉnh một pattern duy nhất. Đó là việc bạn đang hoãn lại một quyết định thiết kế, chứ không phải đang áp dụng một pattern.

Sai lầm phổ biến nhất: Áp dụng retrieval cho live state

Sai lầm phổ biến nhất trong kiến trúc tham chiếu là dùng retrieval ở nơi lẽ ra thuộc về một tool call. Bạn có thể nhận diện nó qua các dấu hiệu: các chunks bị cũ, kết quả thay đổi mỗi lần index refresh, câu trả lời mâu thuẫn với dữ liệu trong database.

Một embedding model tốt hơn hay tần suất refresh ngắn hơn cũng không giải quyết được vấn đề này. Thay vào đó, hãy gọi trực tiếp hệ thống đang nắm giữ live state, chứ đừng truy xuất một bản lưu tạm (cached version) của nó.

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

• Chi phí (Cost): Phối hợp hai reference architectures sẽ tăng gấp đôi phạm vi hệ thống bạn phải duy trì. Khi còn nghi ngờ, hãy chọn một.

• Độ phức tạp (Complexity): Mỗi reference architecture đi kèm một quy chuẩn đánh giá (eval contract) riêng. Bạn cần các bộ eval sets riêng cho từng kiến trúc, chứ không phải một bộ eval chung cho toàn hệ thống phức hợp. Một hệ thống trông có vẻ khỏe mạnh ở tầng trên cùng có thể đang che đậy thất bại ở một trong các thành phần bên dưới.

• Rủi ro (Risk): Áp dụng sai retrieval cho live state sẽ tạo ra những câu trả lời đã cũ nhưng lại vô cùng tự tin. Hệ thống trông vẫn bình thường từ bên ngoài (độ trễ bình thường, không báo lỗi). Chi phí phát hiện rất cao vì không có tín hiệu cảnh báo nào cho đến khi người dùng nhận ra câu trả lời không khớp với thực tế.