Cách các sản phẩm AI được xây dựng

Xây dựng một sản phẩm AI đáng tin cậy ít phụ thuộc vào sự thông minh của bất kỳ prompt đơn lẻ nào mà phụ thuộc nhiều hơn vào việc tuân theo một quy trình có kỷ luật. Những đội ngũ cho ra mắt các tính năng AI đáng tin cậy thường đi qua cùng những giai đoạn — nghiên cứu, lập kế hoạch, xây dựng, đánh giá và triển khai — và họ ưa chuộng thiết kế đơn giản nhất giải quyết được vấn đề hơn là thiết kế tinh vi nhất. Bài viết này đi qua vòng đời đó và các mẫu workflow giúp mỗi giai đoạn vận hành hiệu quả.

Bắt đầu đơn giản

Nguyên tắc hữu ích nhất trong phát triển AI là bắt đầu với cách tiếp cận ít phức tạp nhất và chỉ thêm độ phức tạp khi có bằng chứng đòi hỏi điều đó. Một số lượng đáng ngạc nhiên các bài toán trông như cần đến một agent tự chủ lại được giải quyết tốt hơn bằng một chuỗi các bước cố định. Trước khi dùng đến một agent tự quyết định hành động của mình, hãy tự hỏi liệu một workflow có thể dự đoán được có làm tốt công việc đó một cách rẻ hơn và đáng tin cậy hơn không. Các agent chỉ xứng đáng với chi phí tăng thêm và tính khó lường của chúng khi con đường đến giải pháp thực sự không thể biết trước.

Nghiên cứu

Mọi sản phẩm AI đều bắt đầu bằng việc hiểu vấn đề và chất liệu mà nó sẽ làm việc cùng. Điều này có nghĩa là nghiên cứu nhu cầu thực của người dùng, xem xét các ví dụ tiêu biểu về những đầu vào mà hệ thống sẽ đối mặt, và khảo sát các giải pháp và thư viện hiện có trước khi viết bất cứ thứ gì mới. Tái sử dụng một cách tiếp cận đã được kiểm chứng gần như luôn tốt hơn xây dựng từ đầu. Giai đoạn nghiên cứu nên tạo ra một phát biểu rõ ràng về thế nào là thành công, bởi định nghĩa đó sẽ dẫn dắt mọi thứ ở các bước sau — đặc biệt là việc đánh giá.

Lập kế hoạch

Khi đã hiểu vấn đề, bước tiếp theo là thiết kế hình dạng của hệ thống. Quyết định cốt lõi là chọn đúng mẫu workflow. Một số mẫu đã được thiết lập tốt bao quát hầu hết các nhu cầu.

Prompt chaining chia một nhiệm vụ thành một chuỗi các bước trong đó mỗi bước dựa trên bước trước — ví dụ, trích xuất dữ liệu có cấu trúc rồi định dạng nó. Đây là lựa chọn đúng khi một nhiệm vụ phân rã gọn gàng thành các nhiệm vụ con theo thứ tự.

Routing phân loại một yêu cầu đến và gửi nó xuống một đường chuyên biệt. Một hệ thống hỗ trợ khách hàng có thể định tuyến các câu hỏi về thanh toán, các vấn đề kỹ thuật, và các thắc mắc chung tới những bộ xử lý khác nhau, mỗi bộ được tinh chỉnh cho nhóm của nó.

Parallelization chạy các nhiệm vụ con độc lập cùng lúc và kết hợp kết quả, hữu ích khi cần nhiều góc nhìn về cùng một đầu vào và chúng không phụ thuộc lẫn nhau.

Orchestrator-workers là người anh em thích ứng của parallelization: một mô hình trung tâm phân tích nhiệm vụ ngay lúc chạy, quyết định những nhiệm vụ con nào đáng làm đối với đầu vào cụ thể này, và ủy thác chúng cho các worker. Nó phù hợp với những bài toán mà bạn không thể dự đoán trước cách phân chia đúng, đổi lại là thêm các lần gọi mô hình và độ trễ.

Evaluator-optimizer ghép một mô hình sinh ra phản hồi với một mô hình thứ hai phê bình nó, lặp đi lặp lại cho đến khi đầu ra đáp ứng các tiêu chí. Nó hoạt động tốt khi có các tiêu chuẩn đánh giá rõ ràng và đầu ra thực sự cải thiện qua phản hồi — các nhiệm vụ lập trình và viết lách lặp đi lặp lại là những ví dụ hay.

Lập kế hoạch là nơi bạn khớp mẫu với vấn đề một cách trung thực. Chọn một mẫu nặng ký cho một nhiệm vụ đơn giản sẽ thêm chi phí và các kiểu thất bại mà không có lợi ích; chọn một mẫu quá đơn giản cho một nhiệm vụ thực sự phức tạp sẽ tạo ra các kết quả mong manh.

Xây dựng

Việc hiện thực hóa nên giữ cho hệ thống có thể quan sát và kiểm soát được. Hãy ưu tiên đầu vào và đầu ra có kiểu xác định để các thất bại lộ ra rõ ràng, cấu trúc giao tiếp giữa các thành phần theo một định dạng đáng tin cậy, và kiểm tra rằng mỗi bước đã tạo ra một kết quả dùng được trước khi đi tiếp. Hãy xây dựng việc xử lý lỗi ngay từ đầu: các worker có thể trả về phản hồi rỗng hoặc sai định dạng, đầu ra của mô hình có thể không phân tích cú pháp được, và các tool bên ngoài có thể hết thời gian chờ. Một hệ thống lường trước những thất bại này và phục hồi từ chúng đáng giá hơn nhiều so với một hệ thống chỉ hoạt động trên con đường suôn sẻ.

Trong suốt quá trình xây dựng, hãy cưỡng lại việc mạ vàng (gold-plating). Hãy hiện thực hóa đúng những gì các tiêu chí thành công đã định nghĩa đòi hỏi, xác minh nó hoạt động, rồi dừng lại. Sự linh hoạt suy đoán mà không yêu cầu nào đòi hỏi là một nguồn phổ biến của độ phức tạp và lỗi.

Đánh giá

Đánh giá là thứ phân biệt một bản demo với một sản phẩm. Vì các tiêu chí thành công đã được định nghĩa trong giai đoạn nghiên cứu, giai đoạn này kiểm tra hệ thống đã xây dựng dựa trên chúng. Đánh giá tốt sử dụng một tập tiêu biểu các ví dụ thực, đo lường chất lượng bằng các tiêu chí phù hợp với nhiệm vụ, và theo dõi các chiều thực tiễn quan trọng khi vận hành: tỷ lệ thành công, độ trễ và chi phí. Đối với các nhiệm vụ có tiêu chuẩn rõ ràng, một bộ đánh giá tự động — thậm chí là một mô hình khác chấm điểm các đầu ra dựa trên một rubric — có thể chấm điểm hệ thống một cách liên tục.

Quan trọng là, đánh giá nên bao gồm kiểm thử hồi quy trên những trường hợp khó đã biết. Khi các prompt, mô hình và bộ nhớ tiến hóa, hành vi sẽ trôi dạt, và một bộ các trường hợp khó được chạy thường xuyên chính là hệ thống cảnh báo sớm bắt được sự suy giảm chất lượng trước khi người dùng nhận ra. Một thay đổi cải thiện trường hợp trung bình nhưng âm thầm phá vỡ một trường hợp biên quan trọng chính là kiểu thất bại mà các bài kiểm thử hồi quy tồn tại để bắt được.

Triển khai

Triển khai đưa vào những thực tế của việc vận hành một hệ thống AI liên tục. Các kiểm soát chi phí và độ tin cậy trở nên thiết yếu: ngân sách giới hạn mức chi tiêu, giới hạn về thời lượng một tiến trình có thể chạy, và các phương án dự phòng lui về các mô hình rẻ hơn khi thích hợp. Việc giám sát nên theo dõi không chỉ các sự cố sập mà cả chất lượng đầu ra bị suy giảm và hành vi bất ngờ, bởi một hệ thống AI có thể thất bại một cách âm thầm bằng việc tạo ra các kết quả hợp lý-nhưng-sai thay vì báo lỗi.

Đối với các ứng dụng có rủi ro cao hơn, hãy giữ một con người trong vòng lặp tại các điểm quyết định then chốt, và làm cho các hành động của hệ thống có thể kiểm toán được để khi có sự cố nó có thể được hiểu và sửa chữa. Triển khai không phải là điểm kết thúc của vòng đời mà là khởi đầu của một vòng lặp liên tục: dữ liệu vận hành làm lộ ra các trường hợp thất bại mới, những trường hợp đó được đưa trở lại vào việc đánh giá, và đánh giá dẫn dắt vòng cải tiến tiếp theo.

Một vòng lặp, không phải một đường thẳng

Mặc dù các giai đoạn này được mô tả theo thứ tự, phát triển AI trưởng thành là một vòng lặp chứ không phải một đường thẳng. Việc sử dụng thực tế làm lộ ra những vấn đề mà giai đoạn nghiên cứu không thể lường trước, điều này đưa các đội ngũ trở lại với việc lập kế hoạch và xây dựng. Những đội ngũ thành công coi việc ra mắt là khởi đầu của việc học hỏi, định nghĩa thành công đủ chính xác để đo lường được nó, chọn mẫu đơn giản nhất hoạt động được, và liên tục cải thiện dựa trên việc đánh giá trung thực. Kỷ luật đó, hơn nhiều so với bất kỳ kỹ thuật riêng lẻ nào, mới là thứ biến một bản prototype AI đầy hứa hẹn thành một sản phẩm mà mọi người có thể tin cậy.