Dhivya Nagasubramanian, Phó Chủ tịch Chuyển đổi và Đổi mới Trí tuệ Nhân tạo – Loạt Phỏng vấn

Dhivya Nagasubramanian là Phó Chủ tịch Chuyển đổi và Đổi mới Trí tuệ Nhân tạo tại một tổ chức tài chính lớn của Mỹ, nơi cô lãnh đạo thiết kế, triển khai và quản lý các hệ thống trí tuệ nhân tạo agentic sản xuất. Cô là tác giả của Agentic AI cho Kỹ sư (Apress/Springer Nature), một hướng dẫn thực tế để xây dựng các hệ thống tự trị trí tuệ nhân tạo có thể được tin cậy trong sản xuất. Kể từ khi phát hành, cuốn sách đã ghi nhận hơn 6.000 lần truy cập tổ chức trên SpringerLink, lưu trữ trong hơn 260 thư viện trên toàn thế giới và được áp dụng trên các trường đại học. Cô là người được cấp bằng sáng chế của Văn phòng Sáng chế và Nhãn hiệu Hoa Kỳ trong lĩnh vực học máy ứng dụng. Nghiên cứu của cô bao gồm xây dựng các ứng dụng có khả năng chống lại các cuộc tấn công jailbreak đối thủ và đóng góp vào các nỗ lực ngành công nghiệp rộng lớn hơn để phát triển các mô hình an toàn và bảo mật đa văn hóa tốt hơn. Cô là một chuyên gia được săn đón và là thành viên hội đồng trên nhiều hội nghị ngành công nghiệp và học thuật.

Sự nghiệp của bạn đã tiến bộ từ tư vấn doanh nghiệp và khoa học dữ liệu đến lãnh đạo chuyển đổi trí tuệ nhân tạo trong lĩnh vực tài chính. Những kinh nghiệm đó đã định hình Agentic AI cho Kỹ sư như thế nào, và khoảng trống nào giữa nghiên cứu trí tuệ nhân tạo và triển khai doanh nghiệp đã thuyết phục bạn rằng cuốn sách này cần được viết?

Tôi bắt đầu vào năm 2008 bằng việc xây dựng các hệ thống kế toán và đo lường hiệu suất cho các nền tảng ngân hàng. Một trong những dự án đó là một động cơ tuân thủ GIPS để tính toán lợi nhuận có trọng số thời gian, mà các tổ chức tài chính ở hơn 80 quốc gia sau đó đã sử dụng. Công việc đó đã dạy tôi một bài học đã định hình toàn bộ sự nghiệp của tôi. Trong tài chính được quản lý, sự thất bại nguy hiểm nhất là một con số sai mà trông có vẻ đúng. Một tính toán không chính xác được tin cậy, báo cáo và thực hiện trong nhiều năm, vì không có gì có vẻ bị hỏng.

Tôi đã thấy lại mẫu đó sau này. Tôi đã tìm thấy một khoảng trống cấu trúc trong mô hình Markov của một mô hình thuộc tính tiếp thị được sử dụng rộng rãi. Khung này được sử dụng bởi hàng trăm nghìn người dùng, và lỗi đã tồn tại trong nhiều năm vì một lý do: đầu ra trông có vẻ hợp lý. Khi tôi chuyển sang chuyển đổi trí tuệ nhân tạo trong lĩnh vực tài chính, tôi đã xem các hệ thống agentic lặp lại mẫu này với các ставка cao hơn. Một tác nhân không chỉ sản xuất một kết quả sai. Nó thực hiện hành động dựa trên kết quả đó.

Khoảng trống đã thuyết phục tôi viết cuốn sách là nghiên cứu và triển khai doanh nghiệp quan tâm đến những điều khác nhau. Nghiên cứu đo lường khả năng trên các tiêu chuẩn. Doanh nghiệp phụ thuộc vào cách một hệ thống hoạt động dưới sự không rõ ràng, dữ liệu thay đổi và áp lực đối thủ. Hầu hết các tác phẩm về các tác nhân dừng lại ở giai đoạn trình diễn. Tôi đã viết Agentic AI cho Kỹ sư cho kỹ sư phải đặt tên của họ vào một hệ thống sẽ chạy với sự giám sát hạn chế trong một tổ chức được quản lý.

Cuốn sách mô tả sự chuyển đổi từ tự động hóa sang tự chủ như một tư duy kỹ thuật mới. Điều gì thực sự phân biệt một tác nhân trí tuệ nhân tạo tự chủ với một quy trình tự động hóa tinh vi, và các tổ chức có thể nhầm lẫn hai điều này ở đâu?

Tôi đưa cho các nhóm một bài kiểm tra đơn giản. Bạn có thể liệt kê mọi đường dẫn mà hệ thống có thể thực hiện trước khi bạn chạy nó không? Nếu có, bạn có tự động hóa. Nó có thể là tự động hóa rất tinh vi với một mô hình ngôn ngữ bên trong nó, nhưng nó vẫn là tự động hóa. Nếu hệ thống chia nhỏ các mục tiêu, chọn công cụ và quyết định thứ tự hành động tại thời gian chạy dựa trên ngữ cảnh bạn không viết kịch bản, bạn có tự chủ. Sự khác biệt không liên quan gì đến mô hình bạn sử dụng. Nó chỉ liên quan đến nơi quyết định được thực hiện.

Các tổ chức nhầm lẫn hai điều này theo cả hai hướng, nhưng chỉ một hướng là tốn kém. Gọi một quy trình công việc LLM được kịch bản là agentic chủ yếu là một vấn đề tiếp thị. Lỗi đắt tiền là ngược lại. Các nhóm triển khai quyết định tự chủ thực sự dưới sự quản lý được thiết kế cho tự động hóa xác định. Kiểm tra của họ giả định tính lặp lại. Giám sát của họ giả định các mẫu thất bại đã biết. Hồ sơ kiểm toán của họ giả định có một quy tắc có thể theo dõi đằng sau mọi hành động. Không một trong những giả định đó giữ cho một tác nhân.

Đó là sự thay đổi tư duy mà tôi lập luận trong cuốn sách. Với tự động hóa, câu hỏi chính là liệu hệ thống đã thực hiện đúng hay không. Với tự chủ, câu hỏi trở thành liệu hệ thống đã quyết định đúng hay không. Để trả lời câu hỏi đó, cần có các công cụ và phương pháp đánh giá khác nhau, và một mức độ thận trọng khác.

Nhiều hệ thống trí tuệ nhân tạo agentic hoạt động ấn tượng trong các bản demo nhưng gặp khó khăn khi đối mặt với người dùng thực, dữ liệu thay đổi và công cụ không thể đoán trước. Những thành phần nào nên được coi là bắt buộc trong một kiến trúc tác nhân sản xuất?

Câu trả lời trung thực là sản xuất cần mọi thứ mà một bản demo cho phép bạn bỏ qua. Một bản demo hoạt động vì ai đó đã kiểm soát môi trường. Sản xuất lấy đi sự kiểm soát đó.

Trong cuốn sách, tôi mô tả một kiến trúc tham chiếu bảy lớp, nhưng những thành phần này tôi coi là bắt buộc. Hợp đồng công cụ với đầu vào được nhập và quyền rõ ràng, để tầm với của tác nhân bị giới hạn bởi thiết kế chứ không phải bởi hy vọng. Quản lý trạng thái tồn tại sau các gián đoạn và thất bại. Xử lý thất bại có cấu trúc với các đường dẫn leo thang được xác định. Một bộ khung đánh giá chạy liên tục, không chỉ một lần trước khi ra mắt. Và một hồ sơ kiểm toán ghi lại các quyết định và lý do đằng sau chúng, không chỉ các hành động được thực hiện.

Thành phần mà các nhóm thường bỏ qua nhất là xác minh tại thời gian chạy. Đây là một lớp kiểm tra mọi hành động chống lại mục tiêu được nêu của tác nhân và các chính sách áp dụng cho nó. Cơ sở hạ tầng tiêu chuẩn cho bạn biết liệu một cuộc gọi đã thành công hay không. Xác minh hỏi liệu cuộc gọi có nên được thực hiện hay không. Nó không bao giờ chứng minh giá trị của nó trong một bản demo, vì không có gì cần được bắt. Trong sản xuất, nó là điều đầu tiên bạn sẽ ước mình có.

Cuốn sách của bạn bao gồm an toàn, căn chỉnh, vòng lặp phản hồi, kiểm tra, gỡ lỗi, đánh giá và triển khai. Làm thế nào các nhóm kỹ sư nên kết hợp các yếu tố này vào một quá trình đảm bảo liên tục thay vì coi an toàn như một cuộc xem xét cuối cùng trước khi ra mắt?

Một cuộc xem xét cuối cùng dựa trên giả định rằng hệ thống bạn xem xét là hệ thống sẽ chạy. Đối với trí tuệ nhân tạo agentic, giả định đó thất bại theo ba cách. Các mô hình cơ bản được cập nhật. Các công cụ và API mà tác nhân phụ thuộc vào thay đổi. Và dữ liệu và môi trường mà tác nhân hoạt động tiếp tục thay đổi. Một cuộc xem xét an toàn một lần mô tả một hệ thống không còn tồn tại vài tháng sau đó.

Đảm bảo liên tục có nghĩa là đóng vòng lặp. Các đánh giá hành vi chạy trong CI (tích hợp liên tục) giống như các kiểm tra đơn vị, và chúng cổng mọi thay đổi đối với các lời nhắc, công cụ và mô hình. Giám sát thời gian chạy cho phép các bản ghi sản xuất quay lại các tập hợp đánh giá. Tôi mô tả bốn mẫu giám sát trong cuốn sách, vì không có mẫu nào bao gồm toàn bộ bề mặt thất bại. Mỗi sự cố sản xuất một kiểm tra mới, giống như mỗi lỗi nên sản xuất một kiểm tra hồi quy. Và kiểm tra đối thủ chạy trên một lịch trình thường xuyên thay vì chỉ một lần trước khi ra mắt.

Phía tổ chức quan trọng như phía kỹ thuật. An toàn không thể là một nhóm riêng biệt xuất hiện vào cuối với một danh sách kiểm tra. Các kỹ sư xây dựng tác nhân nên sở hữu các bộ kiểm tra đánh giá, các bất biến và thiết kế leo thang của họ, vì họ biết hơn bất kỳ ai nơi phán quyết của hệ thống yếu nhất.

Bạn đã nhấn mạnh việc giám sát ngữ nghĩa của các cuộc gọi công cụ của tác nhân. Giám sát ngữ nghĩa tiết lộ những gì mà các nhật ký và công cụ quan sát thông thường không thể, và nó có thể phát hiện khi nào một tác nhân hoạt động về mặt kỹ thuật nhưng theo đuổi mục tiêu sai không?

Các công cụ quan sát thông thường trả lời một câu hỏi: liệu cuộc gọi đã thành công hay không? Nó bao gồm mã trạng thái, lược đồ, độ trễ và tỷ lệ lỗi. Nó không thể trả lời câu hỏi quan trọng nhất đối với các tác nhân, đó là liệu cuộc gọi nên xảy ra hay không. Một cuộc gọi công cụ có thể hoàn hảo về mặt kỹ thuật và vẫn là hành động sai. Định dạng đúng, thông tin xác thực hợp lệ, phản hồi thành công, điều sai lầm để làm.

Giám sát ngữ nghĩa đánh giá mọi hành động chống lại mục tiêu được nêu của tác nhân và các chính sách áp dụng cho nó. Trong cuốn sách, tôi mô tả điều này như định nghĩa các bất biến ngữ nghĩa trên các cuộc gọi công cụ của tác nhân. Đây là những thuộc tính phải được giữ cho dù tác nhân thực hiện con đường nào. Một tác nhân nghiên cứu một trường hợp của khách hàng không bao giờ nên truy cập hồ sơ ngoài trường hợp đó. Một tác nhân nên đánh dấu một sự không nhất quán trên một ngưỡng nhất định, không bao giờ giải quyết nó một mình. Khi một bất biến bị vi phạm, bạn bắt được vấn đề tại thời điểm hành động thay vì trong một cuộc kiểm toán hàng quý.

Đây cũng là cách bạn phát hiện sự trôi dạt mục tiêu, mà tôi coi là sự thất bại định nghĩa của các hệ thống agentic. Sự trôi dạt mục tiêu trông giống như một tác nhân hoàn thành mọi bước một cách chính xác theo nhật ký trong khi im lặng làm việc hướng tới mục tiêu sai. Nó không bao giờ xuất hiện trong một nhật ký, vì không có gì thất bại. Giám sát ngữ nghĩa đối xử với ý định như một thứ bạn đo lường trực tiếp, và ý định là nơi các tác nhân sai lầm.

Khi một tác nhân gặp phải các hướng dẫn không rõ ràng, các chính sách mâu thuẫn, các công cụ không có sẵn hoặc sự tự tin không đủ, xử lý thất bại có cấu trúc nên trông như thế nào? Làm thế nào các nhà phát triển có thể đảm bảo rằng hệ thống sẽ tạm dừng, leo thang hoặc phục hồi thay vì tự phát?

Vấn đề để thiết kế chống lại là hầu hết các tác nhân chỉ có một cách để kết thúc một nhiệm vụ, đó là sản xuất một câu trả lời. Khi hướng dẫn không rõ ràng hoặc các chính sách mâu thuẫn, tác nhân tự phát. Không phải vì mô hình là bất cẩn, mà vì tự phát là hành vi duy nhất mà kiến trúc cho phép. Xử lý thất bại có cấu trúc có nghĩa là cung cấp cho hệ thống các lựa chọn tốt hơn và làm cho chúng dễ tiếp cận hơn một câu trả lời được làm lên.

Trong thực tế, điều đó có nghĩa là từ chối và leo thang được thiết kế và thử nghiệm với cùng mức độ chăm sóc như thành công. Tôi khuyên bạn nên định nghĩa các trạng thái thất bại được nhập: hướng dẫn không rõ ràng, chính sách mâu thuẫn, công cụ không có sẵn, tự tin không đủ. Mỗi trạng thái này ánh xạ đến một hành vi cụ thể. Hỏi một câu hỏi làm rõ. Chuyển giao cho một con người với toàn bộ ngữ cảnh được đính kèm. Giảm xuống hoạt động chỉ đọc. Thử lại trong giới hạn chặt chẽ hơn. Hoặc dừng lại. Ngưỡng tự tin nên phù hợp với rủi ro của hành động cụ thể. Ngưỡng cho việc soạn thảo một bản tóm tắt nội bộ và ngưỡng cho việc chạm vào tài khoản khách hàng không bao giờ nên là cùng một số.

Hai thực tiễn làm cho điều này trở thành hiện thực. Đầu tiên, thiết kế đường dẫn leo thang trước đường dẫn hạnh phúc. Nếu một con người sẽ nhận được việc chuyển giao, quyết định ngữ cảnh họ nhận được và quyền hạn họ có trước khi bạn viết lời nhắc đầu tiên. Thứ hai, thử nghiệm thất bại theo cách bạn thử nghiệm các tính năng. Tiêm hướng dẫn không rõ ràng. Vô hiệu hóa công cụ trong môi trường thử nghiệm. Cho tác nhân các chính sách mâu thuẫn. Một hệ thống chưa bao giờ thực hành thất bại sẽ hành động mà không có hướng dẫn khi nó xảy ra trong sản xuất.

Các tổ chức tài chính phải cân bằng giữa thử nghiệm và các yêu cầu nghiêm ngặt xung quanh quyền riêng tư, khả năng kiểm toán, rủi ro mô hình và tuân thủ quy định. Ở đâu nên duy trì sự phê duyệt của con người là bắt buộc, và ở đâu các tác nhân có thể được trao quyền tự chủ hoạt động lớn hơn?

Quy tắc của tôi là phê duyệt của con người nên vẫn bắt buộc cho mọi hành động không thể đảo ngược, di chuyển tiền hoặc ảnh hưởng đến kết quả của bệnh nhân, liên quan đến các cuộc truyền thông của khách hàng mang trọng lượng quy định, cho ăn báo cáo quy định hoặc thay đổi các công cụ, chính sách hoặc quyền của tác nhân. Các tác nhân có thể an toàn thực hiện nhiều tự chủ hơn trong công việc đọc và lý luận: nghiên cứu, thu hồi, phân tích tài liệu, phân loại, soạn thảo và hòa giải cờ bạc cho xem xét của con người thay vì giải quyết chúng.

Lỗi phổ biến là yêu cầu phê duyệt của con người tại mọi bước. Điều đó không làm cho hệ thống an toàn hơn. Nó tái tạo quá trình thủ công với các bước bổ sung và đào tạo người xem để phê duyệt. Phê duyệt thuộc về các điểm quyết định thực sự. Nên có ít điểm như vậy, và mỗi điểm nên được nhân viên có thẩm quyền thực sự để nói không.

Nguyên tắc khác là tự chủ nên được kiếm được chứ không phải được cấp. Bắt đầu hẹp. Mở rộng khi hệ thống chứng minh mình dưới sự giám sát. Giữ bằng chứng. Trong các điều khoản rủi ro mô hình, môi trường kiểm soát của bạn nên cho phép bạn chỉ ra cho một cơ quan quản lý không chỉ những gì tác nhân đã làm, mà tại sao bạn được chứng minh là có lý do để cấp cho nó mức độ độc lập đó. Hồ sơ đó là giấy phép thực sự để hoạt động.

Thông qua công việc của bạn về các biện pháp an toàn trí tuệ nhân tạo và tiêu chuẩn, bạn đang giúp định nghĩa các quy tắc cho các hệ thống có khả năng tiếp tục thay đổi. Những biện pháp an toàn nào có thể được tiêu chuẩn hóa một cách thực tế ngày nay, và những lĩnh vực nào vẫn phụ thuộc quá nhiều vào ngữ cảnh, ngành công nghiệp hoặc trường hợp sử dụng?

Các biện pháp an toàn mà chúng ta có thể tiêu chuẩn hóa ngày nay là cấu trúc. Chúng yêu cầu rằng các kiểm soát nhất định tồn tại, được ghi lại và có thể được kiểm tra. Khả năng và ranh giới quyền được ghi lại cho các hệ thống tự chủ. Cơ chế giám sát con người được xác định và các cơ chế leo thang. Nghĩa vụ phát hiện và báo cáo sự cố. Phương pháp đánh giá và yêu cầu bằng chứng. Trách nhiệm rõ ràng trên toàn bộ vòng đời của hệ thống, để khi có điều gì đó sai, câu trả lời cho ai là người chịu trách nhiệm không bao giờ chỉ là trí tuệ nhân tạo. Những điều này có thể được tiêu chuẩn hóa vì chúng liên quan đến việc kiểm soát có tồn tại và kiểm soát có tốt như thế nào, không phải giá trị cụ thể mà chúng thực hiện.

Điều mà chúng ta vẫn chưa thể tiêu chuẩn hóa là chính các cài đặt. Ngưỡng tự tin cụ thể, phân loại thiệt hại và mức độ tự chủ phù hợp phụ thuộc rất nhiều vào ngữ cảnh. Tolerance thất bại chấp nhận được cho một tác nhân nội dung tiếp thị và cho một hệ thống chạm vào quyết định lâm sàng hoặc tài chính là không phải hai điểm trên cùng một thang. Chúng thuộc về các chế độ khác nhau, được định hình bởi lĩnh vực, khu vực pháp lý và ai gánh chịu thiệt hại khi có điều gì đó sai.

Điều khiển tài chính là một mô hình hữu ích ở đây. Yêu cầu kiểm toán được tiêu chuẩn hóa trên toàn cầu, nhưng tính vật chất luôn được đánh giá trong ngữ cảnh. Các tiêu chuẩn tôn trọng sự phân chia đó có xu hướng được áp dụng. Các tiêu chuẩn cố gắng định nghĩa các giá trị phụ thuộc vào ngữ cảnh có xu hướng bị bỏ qua, và một tiêu chuẩn an toàn mà không ai tuân theo không bảo vệ ai.

Nghiên cứu gần đây của bạn đã khám phá sự mạnh mẽ và an toàn của đa văn hóa trong đánh giá an toàn trí tuệ nhân tạo. Những loại thất bại mô hình nào có thể bị bỏ lỡ bởi các tiêu chuẩn Western-centric hoặc toàn cầu trung bình, và làm thế nào các doanh nghiệp nên đánh giá các hệ thống dự định cho việc triển khai đa văn hóa?

Nhìn chỉ vào các tiêu chuẩn trung bình có thể bỏ lỡ những thất bại quan trọng nhất. Một mô hình có thể đăng một điểm an toàn tổng thể mạnh mẽ trong khi thất bại nghiêm trọng đối với một ngôn ngữ, phương ngữ hoặc ngữ cảnh văn hóa cụ thể, vì những thất bại đó biến mất vào trung bình. Đánh giá Western-centric thêm một điểm mù khác. Nó bỏ lỡ những tổn hại cụ thể về văn hóa, chẳng hạn như thành ngữ, cử chỉ và ngữ cảnh tôn giáo hoặc khu vực mà cùng một đầu ra vô hại trong một văn hóa và có hại trong một văn hóa khác. Nó cũng kiểm tra dưới mã hóa, chuyển tự và tên và thực thể không phải của phương Tây. Có một góc độ đối thủ. Những kẻ tấn công không nhắm vào hiệu suất trung bình của bạn. Họ tìm điểm yếu nhất của bạn, và đối với hầu hết các mô hình, điểm yếu đó là một ngôn ngữ hoặc ngữ cảnh văn hóa ít tài nguyên hơn.

Điều này đã thu hút tôi vào việc đóng góp vào nghiên cứu về tiêu chuẩn an toàn trí tuệ nhân tạo đa văn hóa. Phát hiện cốt lõi là thẳng thắn. Đánh giá an toàn trên các nền văn hóa đòi hỏi dữ liệu đánh giá và phán quyết của con người được rút ra từ những nền văn hóa đó. Bạn không thể đánh giá tổn hại từ bên ngoài ngữ cảnh mà nó xảy ra.

Đối với các doanh nghiệp, tôi đề xuất ba quy tắc. Đánh giá mọi phân khúc bạn phục vụ, và không bao giờ chấp nhận một trung bình làm bằng chứng. Xây dựng các tập hợp đánh giá từ dân số khách hàng thực tế của bạn. Chạy kiểm tra đối thủ trong các ngôn ngữ mà khách hàng của bạn sử dụng. Nếu bạn phục vụ khách hàng ở 40 quốc gia và chỉ đánh giá trong tiếng Anh, bạn đã đo lường hệ thống của mình cho một triển khai khác.

Bạn cũng nắm giữ một bằng sáng chế được cấp bởi Văn phòng Sáng chế và Nhãn hiệu Hoa Kỳ trong lĩnh vực học máy ứng dụng. Vấn đề bạn đang cố gắng giải quyết là gì, quá trình đó đã dạy bạn gì về việc chuyển đổi nghiên cứu trí tuệ nhân tạo thành đổi mới thực tế, và thách thức agentic AI nào chưa được giải quyết bạn quan tâm nhất để giải quyết tiếp theo?

Bằng sáng chế gần đây được phê duyệt giải quyết một vấn đề về quy mô và nhất quán trong xem xét chất lượng dịch vụ tài chính – xem xét cuộc gọi thông thường là thủ công, vì vậy các reviewer con người chỉ có thể lấy mẫu một phần nhỏ các cuộc gọi, và đánh giá của họ khác nhau từ người này sang người khác. Cách tiếp cận của tôi định tuyến mỗi câu hỏi về chất lượng và tuân thủ đến phương pháp phù hợp nhất để trả lời nó, với mỗi quyết định được ghi lại và có thể theo dõi được để kiểm toán.

Bạn có thể thấy cùng những chủ đề mà tôi đã mô tả trong suốt cuộc phỏng vấn này. Định tuyến mỗi nhiệm vụ đến công cụ ít mạnh mẽ nhất có thể thực hiện nó tốt. Giữ con người trong vòng lặp nơi phán quyết quan trọng. Và làm cho mọi quyết định tự động trở nên có thể theo dõi được, vì trong một tổ chức được quản lý, một câu trả lời mà không có bằng chứng không phải là một câu trả lời.

Quá trình cấp bằng sáng chế đã dạy tôi rằng sự kỷ luật nằm trong các chi tiết. Bạn không thể cấp bằng sáng chế cho một ý tưởng mơ hồ. Bạn phải chỉ ra chính xác phương pháp của bạn làm khác biệt như thế nào, và chính xác nơi nó áp dụng. Sự chính xác đó đã buộc công việc cơ bản trở nên tốt hơn.

Thách thức chưa được giải quyết mà tôi quan tâm nhất hiện nay là xác minh tại thời gian chạy cho các hệ thống đa tác nhân. Định nghĩa các bất biến ngữ nghĩa cho một tác nhân đơn lẻ là có thể quản lý. Tôi biết, vì chúng tôi làm điều đó trong sản xuất. Khi các tác nhân ủy quyền công việc cho các tác nhân khác, hành vi trở nên nổi bật, và các thất bại di chuyển vào các cuộc gọi. Một hướng dẫn được hiểu hơi khác tại mỗi bước. Một chính sách áp dụng cho một tác nhân nhưng không phải cho tác nhân mà nó tuyển dụng. Xác minh tương tác giữa các tác nhân, không chỉ các hành động của từng tác nhân, là nơi tôi dự đoán thế hệ thất bại im lặng tiếp theo sẽ xuất hiện. Đó là vấn đề tôi muốn làm việc tiếp theo.

Cảm ơn vì cuộc phỏng vấn tuyệt vời, độc giả cũng có thể đặt hàng cuốn sách của cô Agentic AI cho Kỹ sư.