Sierra ra mắt Release Governance: Thiết lập rào chắn cho việc triển khai AI Agent quy mô lớn

Một số công ty lớn nhất thế giới đang xây dựng các agent của họ trên Sierra: hàng trăm người cùng làm việc trong một agent duy nhất, xuyên suốt hàng trăm hành trình (journeys), phục vụ hàng triệu khách hàng. Một thay đổi nhỏ đối với agent có thể ngay lập tức định hình lại cách nó tương tác với mọi khách hàng. Ở quy mô đó, việc phát hành một agent một cách an toàn không thể dựa vào các kiểm tra không chính thức hay việc trông chờ ai đó nhớ kiểm tra lại các thay đổi.

Đó là lý do tại sao chúng tôi tích hợp quản trị phát hành (release governance) trực tiếp vào nền tảng Sierra: các bước kiểm tra, phê duyệt và chiến lược triển khai giúp đưa một thay đổi từ Workspace của người xây dựng đến cuộc hội thoại trực tiếp với khách hàng một cách an toàn. Đây chính là kỷ luật đã giúp các đội ngũ phần mềm phát triển từ vài lập trình viên lên đến hàng nghìn người — bao gồm kiểm thử tự động, đánh giá mã nguồn và triển khai theo giai đoạn — nay được áp dụng vào Vòng đời Phát triển Agent (Agent Development Lifecycle). Trên thực tế, điều này có nghĩa là Agent Checks và Simulations sẽ chủ động phát hiện vấn đề, các quy trình phê duyệt hợp nhất (merge approval workflows) đảm bảo có sự tham gia của con người, và việc phân tách lưu lượng truy cập (split traffic) giúp triển khai các thay đổi một cách dần dần.

Phát hiện vấn đề trước khi khách hàng gặp phải

Thời điểm tốt nhất để tìm ra vấn đề là trước khi bạn tạo ra nó. Rất lâu trước khi một thay đổi sẵn sàng để phát hành, Sierra đã kiểm tra công việc của bạn. Agent Checks đóng vai trò như một công cụ linter cho agent của bạn, đưa ra các cảnh báo trong quá trình bạn xây dựng dựa trên các hành trình và những cuộc hội thoại mà chúng tạo ra.

Nó phát hiện những vấn đề dễ bị bỏ sót và gây tốn kém khi phát hành: một công cụ mà prompt của bạn tham chiếu đến nhưng chưa bao giờ được cung cấp, các hướng dẫn mâu thuẫn cho agent, một công cụ tra cứu thực hiện công việc của một công cụ hành động, một phản hồi hoạt động tốt trên màn hình nhưng lại thất bại trong cuộc gọi, hoặc việc tra cứu dữ liệu nhạy cảm mà không có xác thực đầy đủ. Các kiểm tra được ưu tiên theo mức độ nghiêm trọng, giúp các nhóm phân biệt giữa những vấn đề có khả năng ảnh hưởng đến khách hàng với các cải tiến chất lượng ưu tiên thấp hơn, và hầu hết đều đi kèm với đề xuất sửa lỗi từ Ghostwriter có thể áp dụng ngay tại chỗ.

Trong khi Agent Checks phát hiện các vấn đề trong cách xây dựng agent, một số vấn đề chỉ xuất hiện trong các cuộc hội thoại. Đó là lý do tại sao các nhóm cũng có thể yêu cầu Simulations phải vượt qua trước khi tiến tới giai đoạn sản xuất. Cùng với nhau, chúng cung cấp các cổng kiểm soát chất lượng tự động được tích hợp trực tiếp vào nền tảng, giảm thiểu rủi ro khi một thay đổi bị lọt qua mà không được kiểm tra.

Không phải quyết định nào cũng có thể tự động hóa

Các cổng kiểm soát tự động giúp phát hiện những gì bị hỏng, nhưng chúng không thể cho bạn biết liệu một thay đổi có nên được phát hành hay không.

Đó là lý do tại sao chúng tôi giới thiệu quy trình phê duyệt hợp nhất. Các tổ chức hiện có thể yêu cầu đánh giá ngang hàng (peer review) trước khi bất kỳ thay đổi nào được phát hành, giống như cách các đội ngũ phần mềm yêu cầu phê duyệt trước khi một pull request được hợp nhất. Vai trò Reviewer chuyên biệt cho phép bạn quyết định chính xác ai cần ký duyệt: trưởng nhóm CX, bên liên quan về tuân thủ, quản lý kỹ thuật hoặc một chuyên gia lĩnh vực khác.

Người đánh giá có thể kiểm tra các thay đổi (diffs) theo từng dòng, để lại nhận xét theo ngữ cảnh và yêu cầu thay đổi trước khi việc hợp nhất được phê duyệt. Người xây dựng có thể làm việc cùng với Ghostwriter để giải quyết các phản hồi đó và thậm chí yêu cầu đánh giá lại trước khi có sự phê duyệt cuối cùng từ con người.

Phát hành dần dần, không phải tất cả cùng một lúc

Khi một thay đổi đã được phê duyệt, câu hỏi tiếp theo là liệu bạn có nên phát hành nó cho tất cả khách hàng cùng một lúc hay không. Thông thường, câu trả lời là không.

Tính năng phát hành phân tách lưu lượng truy cập (split traffic releases) mới của chúng tôi cho phép các tổ chức triển khai dần dần một bản phát hành cho một phần lưu lượng khách hàng trước khi mở rộng ra tất cả mọi người — đây chính là chiến lược canary mà các đội ngũ phần mềm đã tin dùng trong nhiều năm. Nếu bạn đã nâng cấp mô hình, thiết kế lại xác thực hoặc thực hiện một thay đổi lớn về hành vi, bạn có thể xác minh rằng bản phát hành hoạt động như mong đợi trước khi triển khai rộng rãi hơn. Một hãng hàng không lớn, sàn giao dịch du lịch và công ty fintech hiện đang sử dụng tính năng phân tách lưu lượng truy cập để kiểm soát cách các bản phát hành tiếp cận khách hàng của họ.

Đối với các nhóm đã sử dụng Experiments, các bản phát hành phân tách lưu lượng truy cập phục vụ một mục đích khác: Experiments giúp bạn xác định biến thể nào hoạt động tốt nhất, trong khi các bản phát hành phân tách lưu lượng truy cập giúp bạn triển khai an toàn biến thể chiến thắng đó.

Và vì mỗi bản phát hành là một bản chụp (snapshot) bất biến, việc hoàn tác (roll back) cũng nhanh chóng như vậy nếu có bất kỳ điều gì bất ngờ xảy ra.

Quản trị cho quy mô lớn

Các đội ngũ phần mềm không phát minh ra đánh giá mã nguồn, CI/CD và triển khai canary vì họ thích quy trình. Họ áp dụng chúng vì đó là cách duy nhất để hàng trăm người có thể cùng nhau phát hành phần mềm một cách an toàn.

Các agent doanh nghiệp đã đạt đến điểm tương tự. Khi Vòng đời Phát triển Agent trưởng thành, quản trị phát hành không còn là gánh nặng mà trở thành yếu tố cho phép các nhóm di chuyển nhanh chóng mà không cần phải lo âu. Những biện pháp kiểm soát này chứng minh giá trị ngay cả với một người xây dựng trên một hành trình duy nhất, và trở nên không thể thiếu khi hàng trăm người đang cùng xây dựng song song cho một agent trò chuyện với khách hàng suốt ngày đêm.