Randall Newman, CPTO và Đồng sáng lập Satisfi Labs – Loạt phỏng vấn

Randall Newman, CPTO và Đồng sáng lập Satisfi Labs, là một nhà lãnh đạo công nghệ và sản phẩm với kinh nghiệm dày dặn trong việc xây dựng nền tảng AI, công nghệ tài chính và các hệ thống hiệu năng cao. Kể từ khi đồng sáng lập Satisfi Labs, Newman đã đóng vai trò trung tâm trong việc hình dung, thiết kế và mở rộng công nghệ AI hội thoại của công ty, đồng thời giám sát phát triển sản phẩm, kiến trúc, các đội kỹ thuật và các tích hợp chiến lược. Trước khi gia nhập Satisfi Labs, ông từng là Trưởng bộ phận Sản phẩm tại Satisfi Inc. và đồng sáng lập công ty tiếp thị di động Right On Mobile. Ở giai đoạn đầu sự nghiệp, Newman đã làm việc hơn 17 năm tại CIBC World Markets, nơi ông nắm giữ các vị trí lãnh đạo cao cấp trong các lĩnh vực rủi ro chiến lược, giao dịch tần suất cao và arbitrage cổ phiếu, kết hợp chuyên môn giao dịch định lượng với phát triển công nghệ thực tiễn.

Satisfi Labs là một công ty AI tập trung vào việc triển khai các tác nhân AI chuyên biệt cho lĩnh vực thể thao, giải trí, du lịch, các điểm tham quan và các doanh nghiệp trải nghiệm trực tiếp khác. Được thành lập vào năm 2016, công ty đã phát triển từ AI hội thoại và Answer Engine thành một nền tảng tác nhân nhằm giúp các tổ chức tự động hoá hỗ trợ khách hàng, tăng chuyển đổi vé và thương mại, và khai thác thông tin từ các cuộc trò chuyện với khách hàng. Các tác nhân AI của nó có thể hoạt động trên hơn 50 ngôn ngữ và kết nối với hệ thống bán vé, CRM, quản lý nội dung và các hệ thống kinh doanh khác để thực hiện các hành động như bán vé, chuyển cuộc trò chuyện lên nhân viên con người, thu thập thông tin khách hàng và cung cấp phản hồi cá nhân hoá. Satisfi Labs cho biết công nghệ của họ hiện đã được hơn 775 thương hiệu tin dùng, với các tích hợp và quan hệ đối tác bao gồm Ticketmaster, Simpleview, MappedIn, Ventrata và Vozzi.

Bạn đã dành gần hai thập kỷ trong thị trường tài chính, bao gồm việc xây dựng các hệ thống giao dịch độ trễ thấp và dẫn dắt các chiến lược giao dịch tần suất cao tại CIBC, trước khi chuyển sang khởi nghiệp công nghệ và cuối cùng đồng sáng lập Satisfi Labs. Những bài học nào từ các hệ thống vận hành, nơi tốc độ, độ tin cậy và quản lý rủi ro là yếu tố then chốt, đã ảnh hưởng nhiều nhất đến cách bạn xây dựng các tác nhân AI sản xuất hiện nay?

Thương mại đã dạy tôi rằng một ý tưởng tốt và một doanh nghiệp tốt là hai điều khác nhau. Bạn có thể nhận diện đúng cơ hội nhưng vẫn mất tiền vì việc thực thi chậm, chi phí quá cao, hoặc giả định rủi ro sai. AI cũng tương tự. Khả năng của mô hình chỉ là một yếu tố đầu vào. Doanh nghiệp phụ thuộc vào việc bạn có thể biến khả năng đó thành kết quả lặp lại với chi phí và rủi ro chấp nhận được hay không.

Việc điều hành một danh mục arbitrage chỉ số cũng dạy bạn nhìn xa hơn các quyết định riêng lẻ. Một lỗi nhỏ lặp lại trên toàn danh mục sẽ trở thành một rủi ro rất lớn. Với AI, bạn có thể có hàng ngàn tác nhân đưa ra các quyết định hợp lý riêng biệt nhưng cùng nhau tạo ra vấn đề. Tất cả chúng dựa trên cùng một dữ liệu kém, hoặc tất cả đều thử lại cùng một dịch vụ thất bại. Bạn phải quản lý toàn hệ thống, không chỉ riêng từng phản hồi.

Tốc độ chỉ có ý nghĩa khi nó cải thiện kết quả. Trong giao dịch, đã có những khoảnh khắc mà microgiây là quan trọng. Trong AI, tôi thà dành thêm một giây để xác nhận giao dịch hơn là ngay lập tức đưa ra kết quả sai. Kỷ luật ở đây là biết nơi tốc độ tạo giá trị và nơi nó chỉ làm tăng tốc một sai lầm.

Bài học cuối cùng là điều đã khởi nguồn cho toàn bộ doanh nghiệp. Lợi thế đến từ việc phát hiện sự định giá sai trước mọi người khác. Tôi cho rằng hiện nay sự định giá sai là hầu hết các doanh nghiệp nhìn các tác nhân AI như một cách để cắt giảm chi phí hỗ trợ. Tại Satisfi Labs, chúng tôi xem chúng như một kênh doanh thu. Ở các sân thể thao của chúng tôi, khoảng 40 % các cuộc trò chuyện của tác nhân liên quan đến vé. Những người hâm mộ này không đến để phàn nàn. Họ đến với tiền trong tay, hỏi chỗ ngồi. Hãy tìm ra những gì thị trường định giá sai và nắm bắt nó. Đây là bản năng giống như trong kinh doanh arbitrage.

Satisfi Labs được thành lập vào năm 2017, khá sớm so với bùng nổ AI sinh tạo hiện nay, và đã phát triển từ xử lý ngôn ngữ tự nhiên ngữ cảnh và AI hội thoại thành một nền tảng tác nhân. Những thay đổi kiến trúc lớn nhất nào cần thiết để chuyển từ các hệ thống chủ yếu trả lời câu hỏi sang các tác nhân có khả năng thực hiện hành động thay mặt người dùng?

Chúng tôi đã dành một thập kỷ để xây dựng hàng ngàn tác nhân AI cho hơn 800 khách hàng doanh nghiệp, bao gồm các đội MLB/NFL, các địa điểm giải trí và các tổ chức du lịch. Thay đổi lớn nhất là bạn đang trao quyền cho hệ thống, không chỉ cung cấp thông tin.

Nếu một trợ lý cho bạn biết vé nào còn khả dụng, đó là cung cấp câu trả lời. Nếu nó đổi vé cho bạn, nó đang thay đổi tồn kho, hồ sơ khách hàng và có thể cả tiền bạc. Bây giờ bạn cần biết ai đã ủy quyền hành động, thực tế đã xảy ra gì, và cách khôi phục nếu quá trình dừng lại giữa chừng.

Vì vậy chúng tôi tách quyết định của mô hình ra khỏi quyền thực thi. Mô hình có thể giải thích yêu cầu và đề xuất bước tiếp theo. Các hệ thống bên dưới nó thực thi quyền hạn, quy tắc kinh doanh và giới hạn giao dịch. Một lời giải thích thuyết phục từ mô hình không thể vượt qua các kiểm soát đó.

Bạn cũng cần một sự phân biệt rõ ràng giữa “tác nhân nói rằng đã hoàn thành nhiệm vụ” và “hệ thống doanh nghiệp xác nhận việc hoàn thành”. Hai điều đó không giống nhau. Nếu một yêu cầu mua hàng bị hết thời gian, bạn nên xác định xem giao dịch đã xảy ra hay chưa trước khi thử lại.

Và về mặt chiến lược, các mô hình tốt hơn không nên buộc bạn phải xây dựng lại các kiểm soát kinh doanh. Tôi muốn tận dụng mọi cải tiến trong khả năng suy luận mà không phải thương lượng lại những gì hệ thống được phép làm mỗi khi một mô hình mới được ra mắt.

Thuật ngữ “agentic AI” hiện đang được áp dụng cho một loạt các sản phẩm. Từ góc độ kỹ thuật, bạn vẽ ranh giới ở đâu giữa một chatbot tiên tiến, một AI đồng hành, và một AI tự động thực sự?

Tôi sẽ hỏi một câu: trách nhiệm nào mà người đó thực sự đã giao phó?

Chatbot cung cấp thông tin. AI đồng hành giúp bạn hoàn thành công việc, nhưng bạn vẫn điều hướng và phê duyệt các bước quan trọng. Một AI tự động có quyền tự đưa ra một số quyết định đó trong khi theo đuổi mục tiêu.

Giao diện không cho bạn biết bạn đang nhìn vào loại nào. Một sản phẩm giao tiếp có thể có tính tự chủ thực sự phía sau. Một thứ được quảng cáo là agent vẫn có thể cần một người phê duyệt mọi hành động hữu ích.

Đối với doanh nghiệp, tính tự chủ nên là một thỏa thuận cụ thể: hệ thống này có thể thực hiện các hành động này, cho những người dùng này, trong những giới hạn này, và phải dừng lại khi gặp các điều kiện này. Đó là điều bạn có thể thực sự kiểm tra và quản lý.

Tôi cũng sẽ không đặt mục tiêu đạt mức tự chủ tối đa. Đôi khi sản phẩm tốt nhất chỉ đặt một câu hỏi đúng thời điểm và xử lý phần còn lại. Việc bỏ câu hỏi đó làm bản demo trở nên ấn tượng hơn nhưng doanh nghiệp lại kém an toàn. Mục tiêu là loại bỏ công việc con người không cần thiết, không phải loại bỏ phán đoán cần thiết của con người.

Satisfi Labs gần đây đã ra mắt Satisfi Forward, một thực tiễn kỹ thuật triển khai sớm. Khoảng trống nào bạn đã thấy giữa việc xây dựng một nền tảng AI mạnh mẽ và thực sự khiến các agent hoạt động đáng tin cậy trong môi trường thực tế của khách hàng đã dẫn đến việc bạn tạo ra mô hình này?

Giai đoạn cuối cùng đang trở thành nút thắt. Một nền tảng có thể chuẩn hoá rất nhiều, nhưng không thể giả định mọi doanh nghiệp của khách hàng đều hoạt động theo cùng một cách. Hệ thống vé của họ có một số hạn chế. Quy trình phê duyệt của họ đi qua ba phòng ban. Định nghĩa về một khách hàng tiềm năng đủ tiêu chuẩn của họ khác với của khách hàng tiếp theo. Những chi tiết đó quyết định việc triển khai có thực sự hữu ích hay không.

Bạn có thể mua một nền tảng có sẵn và lắp ráp một bản demo gây ấn tượng với mọi người. Tuy nhiên, thương mại hoá nó thành một trải nghiệm vững chắc cho người dùng thực tế là một chuyện khác. Đó là nơi các kỹ sư triển khai sớm đóng vai trò. Công việc của đội ngũ chúng tôi tại Satisfi Forward là hiểu kết quả mong muốn, xác định những rào cản, và xây dựng các quy trình làm việc cùng các tích hợp trên nền tảng để hiện thực hoá chúng.

Nhưng chúng tôi đặt ra các ranh giới rõ ràng cho mọi dự án. Trước khi xây dựng, chúng tôi thống nhất về ý nghĩa của thành công, người sở hữu quy trình kinh doanh, những yếu tố phụ thuộc vào khách hàng, và người chịu trách nhiệm duy trì sau khi ra mắt. Nếu không, dự án giai đoạn cuối sẽ trở thành một nghĩa vụ không giới hạn. Và dự án không kết thúc khi mã nguồn được giao. Nó kết thúc khi quy trình làm việc hoạt động trong hoạt động của khách hàng và có người chịu trách nhiệm duy trì chúng.

Chi phí viết mã cũng đã giảm đáng kể, khiến mô hình này thực tế hơn rất nhiều so với trước đây. Tuy nhiên, tôi không xem Satisfi Forward như một nhánh dịch vụ gắn vào sản phẩm SaaS. Mỗi dự án đều dạy chúng tôi sản phẩm tiếp theo nên là gì. Khi ba khách hàng yêu cầu cùng một quy trình làm việc, đó không phải là gánh nặng hỗ trợ. Đó là việc tự viết lộ trình, kèm theo các khách hàng trả phí. Mô hình SaaS cũ chỉ đoán các tính năng và chờ đợi bằng chứng. Cách này chúng tôi nhận được bằng chứng trước, và doanh thu trong khi thu thập chúng. Tôi nghĩ đó là cách các công ty sản phẩm được xây dựng trong thời đại AI.

Các agent của bạn có thể kết nối với hệ thống vé, nền tảng quản lý quan hệ khách hàng, hệ thống quản lý nội dung và các nguồn thông tin thời gian thực khác. Khi các agent có khả năng thực hiện giao dịch và kích hoạt hành động, làm thế nào bạn cân bằng việc truy cập dữ liệu thời gian thực và độ trễ thấp với việc định vị, bảo mật và các biện pháp bảo vệ chống lại các hành động sai lệch?

Trước hết, tôi không bao giờ để tốc độ bù đắp cho một lỗi bảo mật. Một số yêu cầu là các ràng buộc. Bạn phải tối ưu trong phạm vi đó.

Sau đó bạn phân biệt các loại công việc. Trả lời câu hỏi về chỗ đỗ xe và hoàn thành việc mua vé không cần cùng mức độ tươi mới dữ liệu hay cùng các kiểm soát. Bạn có thể lưu trữ tạm thời thông tin ổn định. Khi tiền được chuyển, bạn cần hệ thống giao dịch có thẩm quyền để xác nhận giá, tính khả dụng và hoàn thành.

Những trường hợp nguy hiểm là khi hệ thống không biết điều gì đã xảy ra. Một backend chấp nhận mua hàng, nhưng phản hồi không bao giờ tới. Nếu agent cho rằng giao dịch thất bại và thử lại, bạn sẽ có hai lần mua. Đó không phải là vấn đề ngôn ngữ. Đó là vấn đề phục hồi giao dịch.

Và bạn đo lường trải nghiệm dưới những điều kiện thực sự quan trọng. Độ trễ trung bình vào một ngày thứ Ba yên tĩnh hầu như không cho bạn thông tin gì. Nếu một sự kiện bị mưa bão, bạn đột nhiên có hàng ngàn người hỏi về vé của họ, cùng một lúc. Nếu bạn chỉ lên kế hoạch dựa trên lưu lượng trung bình mỗi phút, bạn sẽ thiếu khả năng đáp ứng trong đợt bùng phát đó. Tôi đã học điều này trực tiếp từ các hệ thống giao dịch.

Ở đây cũng có một quyết định về chi phí. Không phải mọi yêu cầu đều cần mô hình đắt nhất hoặc một chuỗi các tác nhân. Hãy sử dụng con đường đơn giản nhất đáp ứng yêu cầu, và dành thời gian hoặc tính toán bổ sung ở những nơi thực sự cải thiện quyết định. Người dùng nên nhận được kết quả trung thực, bao gồm cả lời khẳng định trung thực rằng một số điều không thể được xác nhận.

Satisfi Labs mô tả một mô hình trong đó các tác nhân chuyên môn có thể hoạt động cùng nhau như một lực lượng lao động AI. Những vấn đề kỹ thuật khó khăn nhất liên quan đến việc điều phối nhiều tác nhân chuyên môn, đặc biệt là về định tuyến, ngữ cảnh chia sẻ, quyết định mâu thuẫn và xác định tác nhân nào nên hành động là gì?

Phần khó nhất là duy trì trách nhiệm khi bạn phân phối công việc.

Bắt đầu bằng cách hỏi liệu bạn có thực sự cần một tác nhân khác hay không. Đôi khi bạn cần một chuyên gia. Đôi khi bạn chỉ cần một lời gọi công cụ hoặc một quy trình đơn giản. Mỗi tác nhân bạn thêm vào là một cách diễn giải khác của yêu cầu, một phụ thuộc khác, một nơi có thể phát sinh lỗi. Và số lượng các tác nhân chạy phía sau nên được ẩn khỏi người dùng.

Khi có nhiều tác nhân được biện minh, tôi muốn một tác nhân chịu trách nhiệm duy nhất cho tương tác. Các chuyên gia có thể cung cấp thông tin hoặc thực hiện công việc có giới hạn. Một tác nhân bán vé quản lý tồn kho và giao dịch, một tác nhân dịch vụ khách hàng quản lý các chính sách. Nhưng phải có người tổng hợp kết quả và quyết định liệu người dùng thực sự nhận được những gì họ mong muốn hay không.

Định tuyến khó khăn vì con người không đặt câu hỏi theo các danh mục rõ ràng. Một yêu cầu có thể liên quan đến ba tác nhân. Hệ thống phải quyết định: một tác nhân có thể xử lý được không, có cần nhiều tác nhân chạy tuần tự không, hay nên hỏi người dùng thêm một câu hỏi trước khi thực hiện bất kỳ hành động nào?

Cũng tương tự với ngữ cảnh. Bạn không gửi mọi thứ cho mọi tác nhân. Điều đó làm tăng độ trễ, tạo ra tiếng ồn và có thể lộ thông tin mà một tác nhân không cần. Và giả định của một tác nhân không nên trở thành sự thật chỉ vì nó đã được chuyển cho tác nhân tiếp theo.

Nếu hai tác nhân không đồng ý, tôi không muốn chúng tranh cãi cho đến khi một bên nghe thuyết phục hơn. Phải có một mô hình quyền hạn rõ ràng. Hệ thống bán vé xác định tính khả dụng. Doanh nghiệp xác định chính sách giao dịch. Dữ liệu thời gian thực vượt trội hơn dữ liệu đã lưu, quy tắc kinh doanh vượt qua phán đoán của mô hình, và nếu vẫn không giải quyết được, bạn sẽ hỏi người dùng hoặc đưa một con người vào. Phần khó không phải là làm cho các tác nhân nói chuyện với nhau, mà là có khả năng tái tạo chính xác tác nhân nào đã làm gì và trách nhiệm nằm ở đâu.

Satisfi Labs ngày càng tập trung vào việc đo lường các tác nhân dựa trên mục tiêu và kết quả kinh doanh thay vì các chỉ số như khối lượng hội thoại. Doanh nghiệp thực sự nên đo lường gì để xác định liệu một tác nhân AI có hoạt động tốt hay không, và làm thế nào để đánh giá độ tin cậy trước khi cho phép một tác nhân có mức độ tự chủ cao hơn?

Bắt đầu với kết quả kinh doanh, sau đó hỏi tác nhân thực sự gây ra bao nhiêu phần của kết quả đó.

Nếu ai đó mua vé sau khi nói chuyện với một tác nhân, điều đó không đồng nghĩa tự động rằng tác nhân đã tạo ra giao dịch. Họ có thể đã mua dù sao. Khi có thể, bạn muốn các so sánh có kiểm soát hoặc một chuẩn đáng tin cậy, không chỉ ghi công cho tương tác cuối cùng. Đối với khách hàng bán vé, điều này có nghĩa là đo lường liệu người hâm mộ có cuối cùng có được chỗ ngồi hay không, chứ không phải liệu tác nhân có trả lời lịch sự hay không. Đối với một địa điểm muốn giảm hàng đợi tại quầy bán vé, điều này có nghĩa là đo lường những gì tác nhân đã giải quyết trước khi bất kỳ ai phải xếp hàng.

Sau đó xem xét kinh tế học của một kết quả thành công: chi phí mô hình, hạ tầng, kiểm tra của con người, các lần leo thang, và chi phí sửa lỗi. Một tác nhân có vẻ rẻ đến khi bạn tính cả những người sửa chữa công việc của nó thì không thực sự rẻ.

Độ tin cậy cần một bảng điểm riêng. Hoàn thành, độ chính xác, hành động không được phép, khả năng phục hồi sau thất bại, chất lượng leo thang. Bạn không thể trung bình một sự cố bảo mật nghiêm trọng vào tỷ lệ chuyển đổi tốt.

Để có mức độ tự chủ cao hơn, tôi sẽ yêu cầu bằng chứng về lớp hành động cụ thể được giao. Hãy thử nghiệm, giám sát khi nó hoạt động, mở rộng trong phạm vi cho phép và luôn duy trì cách dừng lại nó. Một điểm chính xác tổng thể tốt không chứng minh hệ thống đã sẵn sàng cho mọi giao dịch. Và hãy cẩn thận với các động cơ khuyến khích. Đôi khi việc đưa một con người vào lại là kết quả đúng. Nếu bạn chỉ thưởng cho tác nhân vì tránh chuyển giao, đừng ngạc nhiên khi nó giữ lại những vấn đề mà lẽ ra phải được chuyển lên.

Bạn gần đây đã lập luận rằng AI giọng nói cần được thiết kế dựa trên các kết quả có thể đo lường thay vì được xem như một giao diện khác cho chatbot hiện có. Những đột phá kỹ thuật nào còn cần thiết trước khi các tác nhân giọng nói có thể trở thành giao diện chính cho các tương tác phức tạp, thời gian thực, đặc biệt trong các môi trường như sân vận động, điểm tham quan và sự kiện trực tiếp?

Nhiều khách hàng hỏi, liệu bạn có thể chỉ lấy ứng dụng chat và gắn giọng nói vào không? Chúng tôi có thể. Nhưng điều đó không có nghĩa là sẽ mang lại trải nghiệm tốt. Cải tiến thực sự tiếp theo không phải là một giọng nói nghe giống người hơn. Đó là một tương tác có thể tồn tại trong những điều kiện mà người dùng thực sự sử dụng.

Trong một sân vận động, ai đó đang nói qua tiếng ồn của đám đông, sử dụng tên cầu thủ không quen thuộc, đổi ý giữa chừng câu nói, và cố gắng hoàn tất mua vé trước khi cổng mở. Hệ thống phải xử lý gián đoạn, sự không chắc chắn và độ trễ phía sau mà không làm mất nhiệm vụ.

Hãy chú ý đặc biệt đến các chi tiết quan trọng. Nghe sai một câu nói thông thường là chuyện này. Nghe sai số lượng vé hoặc ngày diễn ra sự kiện là chuyện khác. Đại lý cần xác nhận những chi tiết có thể thay đổi hậu quả của hành động mà không làm cho toàn bộ cuộc trò chuyện trở nên nhàm chán.

Và giọng nói không nên bị ép buộc phải làm mọi thứ. So sánh hai mươi tùy chọn chỗ ngồi sẽ tốt hơn trên màn hình. Một người có thể bắt đầu bằng cách gõ, lên xe, và muốn tiếp tục cuộc trò chuyện bằng cách nói. Hệ thống nên giữ lại ngữ cảnh đó và sử dụng giọng nói, văn bản và hình ảnh sao cho phù hợp nhất với thời điểm.

Một phần của điều này cần các mô hình tốt hơn. Phần lớn cần có sự tích hợp và thiết kế tương tác tốt hơn. Chờ đợi một đột phá sẽ không giải quyết được quy trình làm việc được thiết kế quanh văn bản và sau đó được đọc to. Tôi sẽ đánh giá tiến bộ theo cách này: liệu mọi người có hoàn thành nhiệm vụ một cách chính xác, với ít nỗ lực hơn, trong điều kiện thực tế không?

Khi các đại lý chuyển từ việc cung cấp thông tin sang bán vé, thu thập dữ liệu khách hàng, cá nhân hoá trải nghiệm và tương tác với các hệ thống vận hành, các công ty nên xác định như thế nào các quyết định mà một đại lý có thể thực hiện một cách tự động và những quyết định nào luôn cần sự giám sát của con người?

Đó là quản lý rủi ro. Nếu việc này đi sai hướng, nó có thể gây ra thiệt hại gì? Liệu đại lý có mở một cánh cửa mà không thể đóng lại không?

Khả năng đảo ngược là một bài kiểm tra hữu ích đầu tiên, nhưng cũng cần xem xét tổng mức độ phơi bày. Một khoản hoàn trả có thể nhỏ và có thể đảo ngược. Mười nghìn khoản hoàn trả sai trước khi ai đó nhận ra là một vấn đề khác. Bạn cần đặt giới hạn cho các hành động cá nhân và cho hoạt động tích lũy của hệ thống.

Nếu hành động có rủi ro thấp và có thể đảo ngược, hãy cho nó nhiều quyền tự chủ hơn: cập nhật sở thích, kiểm tra đơn hàng, giữ một mục. Khi hậu quả tăng lên, hãy thêm xác nhận hoặc phê duyệt. Một giao dịch mua có thể cần khách hàng xác nhận giá. Một khoản hoàn trả lớn có thể cần sự chấp thuận của nhân viên. Một mối đe dọa an toàn sẽ được nâng cấp ngay lập tức. Và một số quyết định nên luôn do con người thực hiện, chấm dứt.

Sự đồng ý của khách hàng và sự phê duyệt của công ty là hai điều khác nhau, nhân tiện. Khách hàng xác nhận một giao dịch mua không cho phép đại lý bỏ qua chính sách công ty. Nhân viên phê duyệt một ngoại lệ không đồng nghĩa với việc khách hàng đã đồng ý với khoản phí.

Các giới hạn phải được thực thi bởi các hệ thống thực hiện hành động, không chỉ được mô tả trong một lời nhắc. Bạn không thể cấp cho đại lý quyền truy cập rộng rãi rồi dựa vào một lời nhắc bảo nó cẩn thận. Khi cần có con người, hãy cung cấp cho họ đủ ngữ cảnh để đưa ra quyết định thực sự. Giao cho ai đó hàng trăm phê duyệt mà không có thông tin, bạn đã tạo ra một con dấu cao su, không phải sự giám sát. Đặt sự chú ý của con người vào những nơi giảm thiểu rủi ro có ý nghĩa. Đừng lan tỏa nó quá mỏng trong mọi tương tác.

Nhìn về phía trước, bạn có kỳ vọng các công nghệ như Giao thức Ngữ cảnh Mô hình và giao tiếp giữa các đại lý sẽ thay đổi căn bản cách các hệ thống AI doanh nghiệp được xây dựng, chuyển chúng ta từ các đại lý cô lập sang các hệ sinh thái mà trong đó các đại lý có thể khám phá công cụ, trao đổi ngữ cảnh và phối hợp hành động giữa các công ty và nền tảng không?

Tôi nghĩ các giao thức là một phương tiện để đạt mục tiêu. MCP cung cấp cho các ứng dụng AI một cách chung để truy cập công cụ và ngữ cảnh. Các giao thức giữa các đại lý xử lý sự hợp tác giữa các đại lý. Điều đó có giá trị. Bạn không nên phải xây dựng một tích hợp tùy chỉnh mỗi khi một đại lý cần một công cụ. Điều này tương tự như những gì API đã làm cho các tích hợp phần mềm.

Nhưng một định dạng chung không có nghĩa là hai doanh nghiệp đồng ý về ý nghĩa của một hành động, người nào có thể ủy quyền, hoặc điều gì sẽ xảy ra khi nó thất bại. Chỉ vì một đại lý có thể khám phá một công cụ không có nghĩa là nó được phép sử dụng nó. Bạn vẫn phải xác định danh tính, quyền hạn, độ tin cậy, trách nhiệm. Nếu một đại lý yêu cầu đại lý khác thực hiện một việc gì đó và nó sai, ai sẽ chịu trách nhiệm quyết định đó?

Đây là những gì tôi nghĩ thực sự thay đổi. Hiện nay, một địa điểm có một trang web và một ứng dụng. Trong vài năm tới, nó sẽ có một đại lý mà các đại lý khác sẽ đàm phán cùng. Trợ lý cá nhân của một người hâm mộ yêu cầu đại lý của địa điểm cung cấp hai ghế với mức giá nhất định, cộng với một vé đỗ xe, và toàn bộ giao dịch diễn ra giữa hai đại lý. Tìm kiếm các khả năng phù hợp là bước dễ dàng. Biết quyền chi tiêu của khách hàng, xác nhận giá tổng hợp, và xử lý trường hợp vé thành công nhưng đỗ xe thất bại, đó là những vấn đề thực sự.

Và tôi không tin rằng việc vận hành một đại lý tự động mang lại cho bạn mối quan hệ khách hàng. Điều đó phải được kiếm được. Nhưng tôi cũng không tin rằng các địa điểm sẽ giao những giao dịch này cho một công ty tìm kiếm hoặc một chợ vé. Mục tiêu của chúng tôi tại Satisfi Labs là trở thành đại lý đại diện cho địa điểm trong nền kinh tế đó, một đại lý đủ tin cậy để một doanh nghiệp đặt tên lên nó. Tất cả những gì chúng tôi xây dựng quanh độ tin cậy, quyền hạn và trách nhiệm là những gì mang lại vị trí đó.

Cảm ơn bạn đã tham gia phỏng vấn tuyệt vời, những độc giả muốn tìm hiểu thêm nên truy cập Satisfi Labs.