Từ yêu cầu nghiệp vụ đến yêu cầu chức năng và hạ tầng

Yêu cầu từ phía kinh doanh thường chỉ có một câu: "giúp lễ tân trả lời khách nhanh hơn". Từ câu đó tới một ứng dụng chạy được còn rất nhiều câu hỏi: nhanh là bao nhiêu giây, dữ liệu đi qua đâu, chạy trên nền tảng nào, mỗi tháng tốn bao nhiêu.

Bài này giúp bạn trả lời: làm sao đọc một mục tiêu nghiệp vụ thành các yêu cầu kỹ thuật, và mỗi yêu cầu dẫn tới lựa chọn nào khi làm với Claude?

Ví dụ xuyên suốt: chuỗi nha khoa và tin nhắn của khách

Một chuỗi nha khoa có 12 chi nhánh nhận khoảng 2.000 tin nhắn mỗi ngày qua trang web và ứng dụng chat: hỏi giá, hỏi giờ mở cửa, xin đặt hoặc đổi lịch hẹn, gửi ảnh chụp răng hỏi có cần đến khám không. Ban giám đốc đưa ra hai mục tiêu:

1. "Lễ tân trả lời khách nhanh hơn."
2. "Mỗi sáng quản lý biết hôm qua khách phàn nàn gì nhiều nhất."

Công ty đã ký hợp đồng dùng AWS cho toàn bộ hệ thống, và bộ phận pháp chế yêu cầu dữ liệu khách không được rời khỏi hạ tầng đã ký hợp đồng.

Bước đầu: diễn giải yêu cầu chức năng và hạ tầng

Trước khi nghĩ tới model hay prompt, hãy diễn giải những gì mục tiêu nghiệp vụ ngầm đòi hỏi. Đề thi gọi đây là yêu cầu chức năng (functional requirements) và yêu cầu hạ tầng (infrastructure requirements):

Mỗi dòng phải đủ cụ thể để kiểm được. "Nhanh hơn" chưa kiểm được; "chữ đầu tiên hiện trong 2 giây ở 95% lượt chat" thì kiểm được.

Đổi từng yêu cầu thành lựa chọn

Khi đã có danh sách yêu cầu, mỗi yêu cầu thường chỉ thẳng vào một lựa chọn:

Trong ví dụ, mục tiêu 1 dẫn tới Messages API có streaming. Mục tiêu 2 thoạt nhìn hợp với Batch API: tóm tắt 2.000 tin nhắn mỗi đêm, sáng mới cần. Nhưng ở đây yêu cầu hạ tầng chen vào. Docs của Claude in Amazon Bedrock liệt kê những thứ chưa hỗ trợ trên nền tảng này, trong đó có endpoint Message Batches, Files API, nguồn ảnh qua URL và các tool chạy phía máy chủ (code execution, web search). Vậy đội phải chọn cách khác cho báo cáo đêm, ví dụ một job gọi tuần tự có giới hạn tốc độ, và ước lại chi phí khi không có giảm giá 50%.

Đó là lý do nên đi từ yêu cầu hạ tầng trước: nó loại bớt lựa chọn trước khi bạn mất công so chất lượng.

Claude in Amazon Bedrock dùng cùng dạng yêu cầu Messages API như API của Anthropic, chỉ khác endpoint, cách xác thực (thông tin đăng nhập AWS) và model ID (anthropic.claude-sonnet-5-5 thay vì claude-sonnet-5-5). Phần logic còn lại của ứng dụng gần như giữ nguyên.

Loại theo giới hạn cứng, rồi mới so chất lượng

Một số yêu cầu là giới hạn cứng: không đạt thì model hay nền tảng đó bị loại, không cần thử. Bảng so sánh model của Anthropic cho các con số cần kiểm:

Với các model còn lại sau khi lọc, trang hướng dẫn chọn model khuyên dựng bộ test riêng cho đúng việc của bạn, chạy với prompt và dữ liệu thật, so độ chính xác, chất lượng và cách xử lý trường hợp khó, rồi cân với chi phí. Trong ví dụ, đội lấy 200 tin nhắn thật đã được lễ tân trả lời làm bộ test, chạy thử Haiku 5.5 và Sonnet 5.5.

Tích hợp thẳng hay qua lớp trung gian

Một yêu cầu hạ tầng hay bị đặt ra mà không ai cần: "phải đổi được sang nhà cung cấp LLM khác". Lớp trừu tượng nhiều nhà cung cấp có chi phí thật: thêm một tầng phải bảo trì, và thường che mất các tính năng riêng của Claude sau một giao diện chung. Nếu không có ai yêu cầu đổi nhà cung cấp, tích hợp thẳng qua SDK của Claude là lựa chọn đơn giản hơn.

1. Hợp đồng hay chính sách bắt dùng nền tảng cụ thể?Gọi qua nền tảng đó, kiểm danh sách tính năng có và không có
2. Có yêu cầu nơi xử lý dữ liệu?Chọn vùng xử lý phù hợp, tính thêm phụ phí nếu có
3. Người dùng đang chờ?Messages API, bật streaming
4. Khối lượng lớn, không ai chờ?Batch API nếu nền tảng có
5. Còn lạiSo các model còn lại bằng bộ test riêng, cân chất lượng với chi phí