Đồng hành qua các giai đoạn của vòng đời giải pháp

Một giải pháp dùng Claude không kết thúc ở ngày lên production. Sau đó còn giám sát, cải tiến, đổi model, và có khi phải thiết kế lại. Kiến trúc sư giỏi là người làm cho mỗi giai đoạn để lại thứ giai đoạn sau dùng được.

Bài này giúp bạn trả lời: một giải pháp đi qua những giai đoạn nào, mỗi giai đoạn giao gì cho giai đoạn sau, và khi nào thì quay lại từ đầu?

Ví dụ xuyên suốt: công ty phân bón và trợ lý cho nông dân

Một công ty phân bón và giống cây trồng muốn có trợ lý nhắn tin cho nông dân và đại lý: hỏi liều bón theo giai đoạn cây, lịch bón cho từng vụ, mô tả triệu chứng sâu bệnh. Câu khó thì chuyển cho kỹ sư nông học của công ty. Dự án đi từ khảo sát tới vận hành trong một năm, qua hai vụ lúa.

Mỗi giai đoạn giao một thứ cho giai đoạn sau

Năm giai đoạn đề thi nhắc tới là khảo sát (discovery), thiết kế (design), bàn giao (handoff), giám sát (monitoring) và cải tiến (iteration). Điều quan trọng không phải tên giai đoạn mà là thứ mỗi giai đoạn giao đi:

Khoá AI Fluency for Builders của Anthropic Academy nhắc rằng người xây phải chịu trách nhiệm cho kết quả chứ không chỉ cho đầu ra, và gợi ý tự hỏi trước khi đưa vào dùng: mình hiểu hệ thống làm gì chưa, đã kiểm chưa, nó được quyền chạm vào gì, ai chịu trách nhiệm khi nó sai, và có vòng phản hồi để biết khi nó sai chưa. Năm câu đó trải qua cả vòng đời, không dừng ở ngày bàn giao.

Thiết kế chọn đường xây, bàn giao trao cả bài kiểm

Ở giai đoạn thiết kế, ràng buộc từ khảo sát quyết định đường xây. Docs của Anthropic nêu ba đường: tự viết vòng lặp trên Messages API, dùng Agent SDK để chạy vòng lặp trong tiến trình của mình, hoặc để Anthropic chạy vòng lặp và môi trường với Managed Agents. Đường nào cũng có giới hạn riêng. Ví dụ docs ghi Managed Agents hiện không đủ điều kiện cho chế độ không lưu dữ liệu (ZDR) và không nằm trong thoả thuận HIPAA. Nếu khảo sát ghi ra một ràng buộc như vậy, thiết kế phải loại đường đó ngay.

Ở giai đoạn bàn giao, giao bản thiết kế thôi là chưa đủ. Đội nhận phải có bài kiểm để biết mình xây đúng. Bài viết của Anthropic về agent chạy dài cho một ví dụ: trước khi viết code, một agent lập danh sách tính năng dạng JSON, mọi mục đều đánh dấu chưa đạt; agent viết code chỉ được đổi trạng thái khi đã kiểm như người dùng thật, và không được xoá hay sửa bài kiểm. Cách đó chặn việc tuyên bố xong quá sớm, và áp được cho cả đội người: bài kiểm nghiệm thu viết từ lúc khảo sát đi cùng bản thiết kế sang đội triển khai.

Trong ví dụ, đội IT nhận bộ 400 câu hỏi có đáp án của kỹ sư, danh sách thuốc được phép, và lệnh chạy lại cả bộ. Họ biết đã xong khi bộ đó đạt ngưỡng, không phải khi trợ lý "trông có vẻ ổn".

Giám sát: biến hành vi thật thành dữ liệu để quyết định

Bộ đánh giá trước khi lên production không bắt được mọi thứ. Bài viết về đánh giá agent của Anthropic so cách kết hợp nhiều lớp kiểm với các lát pho mát Thuỵ Sĩ: mỗi lát có lỗ, chồng nhiều lát thì ít lỗ lọt qua. Các lớp gồm đánh giá tự động, giám sát production, thử A/B, phản hồi người dùng, đọc lại hội thoại, và nghiên cứu có người tham gia.

Bài viết cũng phân biệt hai loại bộ đánh giá. Bộ đo năng lực (capability eval) bắt đầu với tỉ lệ đạt thấp, dùng để đẩy chất lượng lên. Bộ chống thụt lùi (regression eval) phải đạt gần 100%, dùng để chắc thay đổi mới không làm hỏng cái đã chạy. Khi một bộ năng lực đã đạt gần hết, nó chuyển thành bộ chống thụt lùi.

Trong ví dụ, giai đoạn giám sát có ba nguồn:

• Số đo vận hành: số tin mỗi ngày, độ trễ, tỉ lệ chuyển cho kỹ sư, chi phí.
• Mẫu đầu ra được chấm: mỗi tuần kỹ sư nông học chấm lại 50 cuộc hội thoại chọn ngẫu nhiên.
• Phản hồi: đại lý báo những câu trợ lý trả lời sai hay khó hiểu.

Cải tiến: làm tiếp, sửa tại chỗ, hay quay lại thiết kế

Vòng cải tiến dựa trên bằng chứng: xem số đo vận hành, kết quả chấm mẫu và phản hồi của các bên, chọn thay đổi có tác động lớn nhất cho vòng tới, rồi lên kế hoạch đo thay đổi đó bằng chính bộ đánh giá đang có.

Phần lớn thay đổi nằm gọn trong vòng cải tiến. Nhưng có lúc phải quay lại thiết kế, và ranh giới khá rõ: kiến trúc hiện tại không đáp ứng được yêu cầu mới nếu không đổi trách nhiệm của các thành phần hoặc hợp đồng cốt lõi giữa chúng. Trong ví dụ, sang vụ thứ hai, nông dân muốn gửi ảnh lá lúa bị bệnh. Hệ thống cần một thành phần mới đọc ảnh, hợp đồng đầu vào đổi từ chỉ có chữ sang có ảnh, và quy trình chuyển cho kỹ sư phải kèm ảnh. Đó là việc của một vòng thiết kế mới.

1. Yêu cầu mới buộc đổi trách nhiệm thành phần hay hợp đồng cốt lõi?Quay lại thiết kế
2. Hệ thống không còn mang lại giá trị đáng với chi phí?Lên kế hoạch dừng
3. Có thay đổi trong một thành phần hay một cấu hình đáng làm?Sửa trong vòng cải tiến, đo bằng bộ đánh giá
4. Còn lạiGiữ nguyên, tiếp tục giám sát

Khi model bên dưới thay đổi

Ngay cả khi hệ thống của bạn không đổi gì, model nó dùng vẫn có vòng đời riêng. Docs về ngừng model khuyên kiểm ứng dụng với model mới từ sớm, trước ngày ngừng của model đang dùng, và đổi sang model thay thế được khuyến nghị càng sớm càng tốt. Để biết ứng dụng nào còn gọi model cũ, vào trang Usage trong Claude Console, xuất file CSV: số liệu được chia theo API key và theo model.

Với kiến trúc sư, việc model sắp bị ngừng là một vòng cải tiến có hạn chót:

1. Tìm mọi chỗ còn gọi model cũ qua file xuất từ trang Usage.
2. Chạy bộ đánh giá đã mang theo từ đầu dự án với model thay thế.
3. Sửa prompt hoặc cấu hình nếu kết quả lệch, đo lại.
4. Báo các bên theo kênh đã thống nhất, rồi chuyển trước ngày ngừng.

Trong ví dụ, nhờ bộ 400 câu hỏi được giữ từ lúc khảo sát, việc đổi model chỉ tốn một buổi chạy và đọc kết quả. Không có bộ đó, nhóm sẽ phải đoán.