Moshe Sambol, Phó Chủ tịch Giải pháp Khách hàng tại Lightrun – Loạt Phỏng vấn

Moshe Sambol, Phó Chủ tịch Giải pháp Khách hàng tại Lightrun – mang hơn hai thập kỷ kinh nghiệm trong lĩnh vực kỹ thuật phần mềm, kiến trúc, cơ sở hạ tầng đám mây và lãnh đạo kỹ thuật hướng đến khách hàng. Trước khi gia nhập Lightrun vào năm 2022, ông đã dành gần một thập kỷ tại Google, nơi ông đã nắm giữ nhiều vị trí lãnh đạo, bao gồm Quản lý Kỹ thuật Khách hàng Cloud, giúp các tổ chức áp dụng và mở rộng công nghệ Google Cloud. Sớm trong sự nghiệp của mình, Sambol đã giữ các vị trí lãnh đạo kỹ thuật và phát triển tại Oracle, Sun Microsystems, BMC Software và JPMorgan Chase. Tại Lightrun, ông ban đầu lãnh đạo Kỹ thuật Giải pháp Toàn cầu trước khi trở thành Phó Chủ tịch Giải pháp Khách hàng, nơi ông tập trung vào việc giúp khách hàng áp dụng công nghệ Runtime Insights của công ty và chuyển đổi khả năng của nó thành lợi ích kinh doanh và năng suất phát triển có thể đo lường được.

Lightrun là một nền tảng kỹ thuật độ tin cậy bản địa AI được thiết kế để cung cấp cho các nhà phát triển và tác nhân AI cái nhìn trực tiếp vào cách phần mềm hoạt động khi nó đang chạy. Công nghệ của nó có thể động态 thu thập nhật ký, ảnh chụp, số liệu, dấu vết, giá trị biến và ngữ cảnh thực hiện từ các ứng dụng trực tiếp mà không cần thay đổi mã hoặc triển khai lại. Công ty đang ngày càng mở rộng trí tuệ runtime này sang phát triển phần mềm hỗ trợ AI thông qua Lightrun MCP, sử dụng Giao thức Context Mô hình để cung cấp cho các trợ lý mã và công cụ đại lý ngữ cảnh ứng dụng trực tiếp thay vì chỉ dựa vào mã nguồn tĩnh. Điều này cho phép các hệ thống AI điều tra các vấn đề sản xuất, xác thực các giả thuyết chống lại hành vi thực hiện thực tế và hỗ trợ phân tích nguyên nhân gốc rễ trong khi kết hợp các kiểm soát doanh nghiệp như truy cập dựa trên vai trò và xóa dữ liệu nhạy cảm.

Sự nghiệp của bạn đã trải qua phát triển phần mềm thực tế và kiến trúc, kỹ thuật khách hàng đám mây tại Google, kỹ thuật giải pháp toàn cầu và hiện tại là giải pháp khách hàng tại Lightrun. Làm thế nào mà sự kết hợp này giữa xây dựng phần mềm và làm việc trực tiếp với khách hàng doanh nghiệp đã định hình sự hiểu biết của bạn về những gì phân biệt một bản demo tác nhân AI ấn tượng với một hệ thống có thể được tin cậy trong sản xuất?

Có một sự khác biệt lớn giữa việc展示 những gì một tác nhân AI có thể làm và chứng minh nó có thể được tin cậy trong một môi trường doanh nghiệp. Điều này là vì các tác nhân chỉ là một phần của hệ thống sẵn sàng sản xuất. Khung xung quanh nó cũng quan trọng không kém. Nó phải thực thi truy cập với đặc quyền tối thiểu, giám sát hoạt động, bảo tồn một đường dẫn kiểm toán, ngăn chặn các hành động rủi ro không thể chấp nhận được và đưa một con người vào khi cần thiết.

Các hệ thống tác nhân khác biệt với phần mềm truyền thống vì các nhà phát triển không quy định chính xác cách hệ thống sẽ hoạt động. Chúng ta thiết lập một mục tiêu, cung cấp công cụ và hướng dẫn, và mô hình quyết định cách tiếp tục. Sự linh hoạt đó rất mạnh mẽ, nhưng nó cũng làm cho hành vi của hệ thống khó dự đoán hơn.

Đối với các doanh nghiệp, đặc biệt là những doanh nghiệp trong các ngành được quy định, các quy trình sản xuất thường hoạt động hoặc mất một lượng thời gian không thể đoán trước để hoàn thành là không thể chấp nhận được. Môi trường sản xuất chứa dữ liệu nhạy cảm, mã nguồn và tài sản trí tuệ, vì vậy các tổ chức cần phải có thể ngăn chặn các tác nhân phơi bày thông tin đó hoặc thực hiện các tuyến đường sáng tạo nhưng không thể chấp nhận được để đạt được mục tiêu của chúng. Điều này đang trở nên quan trọng hơn, vì mỗi tuần lại mang đến một ví dụ mới về một hệ thống AI, trong nỗ lực đạt được mục tiêu, đã kết thúc dễ bị tổn thương hoặc gây ra một lỗ hổng bảo mật.

Hầu hết các nhà lãnh đạo tôi nói chuyện vẫn đánh giá các tác nhân theo cách họ đánh giá một nhân viên mới: dựa trên khả năng, phán đoán và đầu ra. Câu hỏi thực sự không phải là liệu tác nhân có thông minh đủ hay không. Đó là liệu hệ thống xung quanh nó có thể bắt và chứa đựng những khoảnh khắc nó không phải là như vậy.

Nhiều doanh nghiệp ban đầu tin rằng xây dựng một tác nhân AI chủ yếu là vấn đề viết một lời nhắc hiệu quả. Điều gì mà các tổ chức hiểu lầm về các yêu cầu kỹ thuật, kiến trúc và vận hành đằng sau các tác nhân sẵn sàng sản xuất?

Tôi nghĩ sự hiểu lầm lớn nhất là một niềm tin gần như ngây thơ vào sức mạnh của AI để giải quyết bất kỳ thách thức nào, một khi đã đưa ra một lời nhắc hiệu quả, ngữ cảnh liên quan và công cụ phù hợp. Các đội kết nối LLM của họ với mã, tài liệu, vé và dữ liệu lịch sử, và sau đó mong đợi nó suy luận một cách chính xác đến quyết định đúng.

Điều họ không xây dựng là một mô hình xác thực cho từng bước suy luận của AI. Một trong những điểm mạnh tuyệt vời của AI là nó sử dụng suy luận xác suất, tìm và thực hiện một trong nhiều tuyến đường có thể để đạt đến đích. Trong các môi trường sản xuất phức tạp, liên kết, điểm mạnh đó lại giới thiệu rủi ro nghiêm trọng: một quyết định duy nhất có thể kích hoạt các hồi quy hạ lưu, thất bại im lặng hoặc hành vi không mong muốn khác đe dọa đến sự ổn định hoạt động của hệ thống đang chạy.

Đây là nơi định hướng xác định trở nên thiết yếu. Suy luận của tác nhân có thể vẫn là xác suất, nhưng các điểm kiểm tra xung quanh hành động của nó không thể là như vậy. Đối với một tác nhân tham gia vào một quy trình kỹ thuật, điều này yêu cầu một bước xác thực kiểm tra giả thuyết hành động tiếp theo của nó chống lại thực tế sản xuất, một cổng xác định chứ không phải một ước tính xác suất khác. Nó cần phải thấy được kết quả của quyết định đó sẽ là gì và chỉ phê duyệt nó một khi nó đã xác định rằng hành động là an toàn.

Nhìn qua làn sóng đầu tiên của các tác nhân doanh nghiệp được phát triển nội bộ, những sai lầm kiến trúc nào bạn đang thấy phổ biến nhất và những vấn đề nào có thể được sửa chữa dần dần chứ không cần phải xây dựng lại hoàn toàn?

Lo ngại cốt lõi mà tôi luôn quay lại là xác thực. Các tác nhân có thể trở thành một hộp đen: chúng thu thập thông tin từ nhiều nguồn và sau đó đưa ra quyết định trông có vẻ hợp lý trên nguyên tắc nhưng có thể không phù hợp với thực tế của một môi trường sản xuất phức tạp và lộn xộn.

Điều đó chỉ ra một sự thay đổi cơ bản hơn và đó là điều chúng tôi thường xuyên thảo luận tại Lightrun khi chúng tôi giúp khách hàng xây dựng tự động hóa tác nhân cho các tổ chức kỹ thuật của họ. Các đội cần phải xây dựng lại dòng chảy tác nhân và đặt cổng trên hành động của tác nhân, để đảm bảo rằng việc sử dụng công cụ của nó được giám sát, kiểm toán và xem xét. Cung cấp cho chính tác nhân một vòng phản hồi mạnh mẽ – bao gồm khả năng quan sát thời gian chạy trực tiếp – tập trung ngữ cảnh của nó vào những gì thực sự đang xảy ra ngay bây giờ. Đó là điều cho phép tác nhân xác thực các quyết định thiết kế của chính nó, phân tích nguyên nhân gốc rễ và đề xuất giảm thiểu lỗi chống lại thực tế sản xuất thay vì chống lại các giả định dựa trên phân tích mã tĩnh hoặc dữ liệu cũ.

Một sự xây dựng lại kịch bản không phải là lựa chọn duy nhất. Điều gì có thể được thực hiện dần dần và điều này không phải là đột phá nhưng rất quan trọng, là đầu tư vào các kỹ năng hướng dẫn hành vi của tác nhân. Các kỹ năng được thiết kế và đánh giá cẩn thận sẽ đẩy tác nhân theo hướng của một quy trình công việc xác định. Các đội không cần phải tái kiến trúc toàn bộ hệ thống để có được lợi ích đó. Họ cần phải đối xử với thiết kế kỹ năng với cùng một sự nghiêm ngặt mà họ dành cho bất kỳ logic sản xuất nào.

Tại sao một số tác nhân hoạt động tốt trong quá trình kiểm tra được kiểm soát nhưng bắt đầu tạo ra kết quả không nhất quán, không đầy đủ hoặc gây hiểu lầm khi tiếp xúc với người dùng thực, dữ liệu thay đổi, công cụ bên ngoài và môi trường sản xuất phức tạp?

Các kiểm tra được kiểm soát loại bỏ hầu hết sự biến đổi sẽ định nghĩa thực tế sản xuất mà AI phải đối mặt. Dữ liệu được thu thập, hành vi công cụ có thể dự đoán được, quyền được biết, và chúng bao gồm một con đường chúng ta đã dự đoán. Khi bạn phát hành một tác nhân để tương tác với người dùng thực và các hiệu ứng của họ trong các hệ thống trực tiếp, bạn không đang so sánh như với như.

Người dùng giới thiệu các yêu cầu mơ hồ và chạy các hành động đồng thời, trạng thái hệ thống luôn thay đổi, tác nhân thường phải làm việc từ dữ liệu không đầy đủ, và các công cụ bên ngoài mang lại độ trễ và chế độ thất bại của riêng chúng trên đó. Bởi vì mô hình là xác suất, mỗi biến mới tạo ra một nơi khác mà quy trình công việc có thể phân kỳ hoặc hợp chất một lỗi trước đó.

Phần nguy hiểm là tác nhân có thể tiếp tục xuất hiện như thể nó đang hoạt động đúng mặc dù tạo ra các phản hồi không chính xác nhưng có thể xảy ra, được xây dựng trên dữ liệu không đầy đủ hoặc dựa trên các giả định có nguồn gốc từ thông tin cũ. Đó là lý do tại sao các tác nhân sản xuất cần có đánh giá liên tục tiếp tục chạy sau khi ra mắt, xử lý rõ ràng dữ liệu bị thiếu và thất bại công cụ, và xác thực trực tiếp một quyết định trước khi nó hoàn thành một hành động có tác động cao.

Lightrun đặt sự nhấn mạnh đáng kể vào việc cung cấp cho các hệ thống AI quyền truy cập vào ngữ cảnh thời gian chạy. Thông tin gì mà ngữ cảnh thời gian chạy cung cấp có thể bị bỏ qua bởi các nhật ký, số liệu và dấu vết thông thường và tại sao thông tin này đặc biệt quan trọng cho việc chẩn đoán sự cố tác nhân?

Quan sát thông thường cho thấy các triệu chứng bên ngoài của hành vi hệ thống, thường được tổng hợp, lấy mẫu hoặc lọc thông qua các bảng điều khiển và cảnh báo kích hoạt trên ngưỡng. Chúng thường phụ thuộc vào các quyết định được thực hiện bởi các nhà phát triển tại thời điểm mã được viết: những thông tin nào sẽ quan tâm trong tương lai? Điều gì đáng được ghi lại hoặc đo lường? Ngữ cảnh thời gian chạy ngắt kết nối khả năng hiển thị khỏi nhu cầu biết trước những gì có thể quan tâm và cung cấp dữ liệu hạt nhân cho thấy những gì đang diễn ra dưới mui và làm thế nào chúng ta đến được đó.

Khoảng trống thực sự là dữ liệu tĩnh so với dữ liệu động. Các nhật ký, số liệu và dấu vết thông thường là tĩnh và tạo ra một tài khoản lịch sử về những gì đã xảy ra. Ngữ cảnh thời gian chạy của Lightrun là động. Nó cung cấp cho tác nhân khả năng đặt công cụ mới vào mã đang chạy, theo yêu cầu, và quan sát chính xác các giá trị biến, đối số hàm, trạng thái đối tượng, ngăn xếp cuộc gọi hoặc điều kiện nhánh khi chúng xảy ra.

Sự khác biệt này đặc biệt quan trọng để chẩn đoán các lỗi trong mã được tạo bởi tác nhân, vì những lỗi này thường im lặng. Một tác nhân có thể chọn công cụ sai, truyền đối số sai hoặc hành động dựa trên một giả định cũ và vẫn hoàn thành nhiệm vụ của nó mà không kích hoạt bất kỳ lỗi nào. Một lỗi như vậy sẽ không hiển thị trong dữ liệu tĩnh, vì không ai biết trước để công cụ cho nó. Hành vi không mong muốn đòi hỏi một cuộc điều tra động trực tiếp trên hệ thống đang chạy, đặt công cụ mới chính xác nơi mô hình thế giới của tác nhân phân kỳ khỏi thực tế, thay vì dựa vào bất cứ điều gì đã được ghi lại.

Đó là điều làm cho ngữ cảnh thời gian chạy động trở thành lớp xác thực tự nhiên cho các quyết định được tạo bởi AI trong kỹ thuật.

Làm thế nào Giao thức Context Mô hình (MCP) và các lớp tích hợp tương tự có thể cho phép các tác nhân mã học hỏi từ hành vi thực hiện thực tế mà không cung cấp cho chúng quyền truy cập quá mức hoặc không an toàn vào các hệ thống sản xuất?

MCP và các quyền truy cập được kiểm soát vào các công cụ bên ngoài (ví dụ: vỏ bọc CLI) cho phép một tác nhân gọi một khả năng cụ thể, được phạm vi hóa thay vì được cấp quyền truy cập rộng rãi vào một hệ thống và được tin cậy để hành động. Một tác nhân được kết nối thông qua máy chủ MCP để có ngữ cảnh thời gian chạy có thể yêu cầu bằng chứng chỉ đọc, giá trị của một biến, một đường dẫn cuộc gọi, liệu một ngưỡng đã được vượt qua hay không, mà không chạm vào quyền truy cập ghi, mà không cần phải triển khai lại bất cứ thứ gì và mà không cần phải có thông tin đăng nhập vĩnh viễn cho môi trường cơ bản.

Khi tái thiết kế một tác nhân thế hệ đầu, các doanh nghiệp nên tiếp cận các quyền công cụ, bộ nhớ, thu thập dữ liệu, đánh giá, giám sát con người và các thủ tục dự phòng như những phần của một kiến trúc gắn kết chứ không phải là các tính năng riêng biệt?

Bạn không thể gắn các mảnh này một cách độc lập vì mỗi mảnh thay đổi các mảnh khác. Những nơi tốt nhất để bắt đầu là khuôn khổ, bộ phận điều khiển vòng lặp tác nhân và quy trình công việc toàn diện điều phối các tác nhân và diễn viên khác. Đối với một quy trình phân tích nguyên nhân gốc rễ, ví dụ, các đội nên quyết định bằng chứng gì là cần thiết, những hệ thống nào tác nhân có thể kiểm tra, liệu nó có thể xuất bản một kết luận hay chỉ dự thảo một, khi nào một con người phải phê duyệt bước tiếp theo và những gì xảy ra nếu bằng chứng thời gian chạy không có sẵn.

Khi hợp đồng đó rõ ràng, bộ phận điều khiển và khuôn khổ cung cấp các cơ chế để thực thi các hướng dẫn đó. Cổng MCP có thể được tận dụng để hạn chế quyền truy cập của tác nhân vào các khả năng cụ thể liên quan đến mục đích của nó. Các công cụ có thể được cấp với đặc quyền tối thiểu. Bộ nhớ có thể được giám sát, với dữ liệu nhạy cảm bị xóa một cách xác định. Thu thập có thể được thiết kế xung quanh bằng chứng mà quy trình công việc cần.

Đánh giá, giám sát và dự phòng sau đó đóng vòng lặp. Hệ thống nên đo lường xem các kết luận có chính xác và được hỗ trợ hay không, đưa một con người vào khi rủi ro hoặc sự không chắc chắn vượt quá một ngưỡng xác định và dừng hoặc rơi trở lại một khuyến nghị chỉ đọc khi nó không thể thu thập đủ bằng chứng. Một bản ghi kiểm toán chung nên kết nối kích hoạt, quyền, bằng chứng, cuộc gọi công cụ, phê duyệt, hành động và kết quả. Đó là điều làm cho các thành phần này trở thành một kiến trúc sản xuất chứ không phải sáu tính năng riêng biệt.

Những biện pháp phòng ngừa nào nên bao quanh các tác nhân có thể kiểm tra các ứng dụng trực tiếp hoặc tham gia vào các quy trình kỹ thuật tin cậy trang web, đặc biệt là trong các môi trường được quy định nơi các kiểm soát truy cập, quyền riêng tư, khả năng kiểm toán và sự ổn định hoạt động là quan trọng?

Đây là một trong những câu hỏi thiết kế trung tâm khi chúng tôi xây dựng Lightrun AI SRE. Một AI SRE hoạt động gần với một số hệ thống nhạy cảm nhất trong một tổ chức, vì vậy chúng tôi đã thiết kế nó như một diễn viên hoạt động được đặc quyền, không phải là một trợ lý trò chuyện. Một quyết định quan trọng là tách mặt phẳng kiểm tra khỏi mặt phẳng hành động. AI SRE thu thập bằng chứng thông qua các tích hợp chỉ đọc và công cụ thời gian chạy được cách ly của Lightrun, với quyền truy cập bị hạn chế bởi danh tính, người thuê nhà, dịch vụ và môi trường. Nó có thể kiểm tra thực hiện trực tiếp và tạo bằng chứng bị thiếu, nhưng lớp kiểm tra thời gian chạy không thể thay đổi trạng thái ứng dụng.

Trong một môi trường được quy định, ranh giới đó phải được hỗ trợ bởi RBAC, SSO, cách ly người thuê nhà, xóa PII, kiểm soát lưu giữ và một bản ghi kiểm toán cho thấy những công cụ và bằng chứng nào hỗ trợ mỗi kết luận. Chúng tôi cũng cần các giới hạn hoạt động xung quanh việc thu thập bao nhiêu dữ liệu, tần suất thời gian chạy có thể được truy vấn và những hành động nào yêu cầu phê duyệt. Nếu bằng chứng bị thiếu hoặc một kết luận không thể được xác thực, AI SRE nên nói như vậy và chuyển quyết định cho một con người thay vì hành động như thể nó biết nhiều hơn những gì nó thực sự biết. Mục tiêu là tự chủ được kiểm soát: hữu ích đủ để tăng tốc một cuộc điều tra, nhưng bị giới hạn đủ để vẫn an toàn cho hệ thống trực tiếp.

Khi các doanh nghiệp chuyển sang các tác nhân vượt ra ngoài thử nghiệm, những phép đo nào nên xác định liệu một tác nhân có thực sự sẵn sàng sản xuất hay không và bạn dự đoán mối quan hệ giữa các tác nhân AI và các kỹ sư con người sẽ phát triển như thế nào trong vài năm tới?

Tôi sẽ đánh giá sự sẵn sàng sản xuất bằng cách thường xuyên các hành động của một tác nhân AI tạo ra kết quả mong muốn, kết luận của nó giữ vững trước những gì thực sự đúng trong sản xuất, những kết luận không được hỗ trợ bị bắt trước khi hành động và liệu nó có thất bại một cách rõ ràng và an toàn khi bằng chứng không có. Đối với các tác nhân kỹ thuật, độ chính xác của kết quả được xác thực, phạm vi bằng chứng, thời gian để xác nhận nguyên nhân gốc rễ, tỷ lệ thành công của quy trình dự phòng và kết quả sau hành động là các chỉ số cốt lõi chúng ta nên tập trung vào.

Trong vài năm tới, tôi dự đoán các tác nhân sẽ thực hiện nhiều hơn việc thu thập bằng chứng và điều tra sơ bộ, cũng như giám sát các quy trình công việc tác nhân và học hỏi liên tục từ kinh nghiệm và phản hồi, trong khi các kỹ sư thiết lập chính sách, giải quyết sự mơ hồ, phê duyệt các hành động rủi ro cao và điều khiển các hệ thống tác nhân tự cải thiện. Sự tin cậy sẽ mở rộng quy trình công việc theo quy trình công việc. Các tác nhân có thể truy tìm kết luận của chúng trở lại bằng chứng trực tiếp và rõ ràng tiết lộ những gì chúng không thể xác thực sẽ kiếm được sự tự chủ lớn hơn. Những tác nhân không thể làm được điều đó sẽ vẫn bị giới hạn trong các nhiệm vụ hẹp, thấp, bất kể chúng có âm thanh trôi chảy như thế nào.

Cảm ơn vì cuộc phỏng vấn tuyệt vời, những người đọc muốn tìm hiểu thêm nên truy cập Lightrun.