Phỏng vấn
Shahar Azulay, Giám đốc điều hành và Đồng sáng lập của groundcover

Shahar Azulay, Giám đốc điều hành và đồng sáng lập của groundcover là một nhà lãnh đạo nghiên cứu và phát triển (R&D) hàng đầu. Shahar mang lại kinh nghiệm trong lĩnh vực an ninh mạng và học máy có sự tham gia của các công ty như Apple, DayTwo và Cymotive Technologies. Shahar đã dành nhiều năm trong Bộ phận An ninh mạng của Văn phòng Thủ tướng Israel và nắm giữ ba bằng cấp về Vật lý, Kỹ thuật Điện và Khoa học Máy tính từ Viện Công nghệ Israel Technion cũng như Đại học Tel Aviv. Shahar luôn nỗ lực sử dụng kiến thức công nghệ từ nền tảng phong phú này và mang nó đến chiến trường bản địa đám mây hiện đại dưới hình thức sắc nét và sáng tạo nhất để làm cho thế giới phát triển trở nên tốt hơn.
groundcover là một nền tảng quan sát bản địa đám mây được thiết kế để cung cấp cho các đội kỹ sư cái nhìn toàn diện và thời gian thực về hệ thống của họ mà không có sự phức tạp hoặc chi phí của các công cụ giám sát truyền thống. Được xây dựng trên công nghệ eBPF, nó thu thập và liên kết nhật ký, số liệu, dấu vết và sự kiện trên các môi trường bản địa đám mây và Kubernetes mà không cần thay đổi mã, cho phép phân tích nguyên nhân gốc rễ nhanh hơn và cái nhìn hệ thống rõ ràng hơn. Nền tảng này nhấn mạnh vào giá cả dự đoán, triển khai linh hoạt giúp giữ dữ liệu trong đám mây của khách hàng và khả năng quan sát từ đầu đến cuối bao gồm cơ sở hạ tầng, ứng dụng và các công việc hiện đại được thúc đẩy bởi AI.
Nhìn lại hành trình của bạn – từ việc lãnh đạo các đội nghiên cứu và phát triển an ninh mạng trong Văn phòng Thủ tướng Israel đến quản lý các sáng kiến học máy tại Apple – những kinh nghiệm nào cuối cùng đã thúc đẩy bạn thành lập groundcover và khi nào bạn lần đầu tiên nhận ra khoảng trống trong khả năng quan sát của các hệ thống AI hiện đại?
Sự thúc đẩy để thành lập groundcover đến từ thời gian của tôi tại Apple và DayTwo. Ngay cả với ngân sách khổng lồ, chúng tôi vẫn phải chọn giữa việc trả một khoản tiền lớn để ghi lại mọi thứ hoặc lấy mẫu và bay mù. Lúc đó, chúng tôi đang tìm kiếm một công nghệ sẽ giải quyết vấn đề đó. Khi chúng tôi gặp Extended Berkeley Packet Filter (eBPF), rõ ràng rằng nó sẽ thay đổi mọi thứ. eBPF cho phép chúng tôi xem mọi thứ đang xảy ra trong hạt nhân mà không cần dựa vào các thay đổi ứng dụng. Tôi không thể hiểu tại sao các công cụ quan sát lại không tận dụng lợi thế của điều đó. Khoảng trống AI trở nên rõ ràng sau đó. Khi nền tảng Kubernetes của chúng tôi trưởng thành, chúng tôi thấy khách hàng vội vàng triển khai GenAI trong khi đối xử với các mô hình ngôn ngữ lớn (LLM) như các hộp đen. Họ biết mô hình phản hồi, nhưng không biết tại sao nó lại hành xử không thể đoán trước hoặc tại sao chi phí lại tăng vọt. Chúng tôi nhận ra rằng các công việc phức tạp là các dịch vụ vi mô không xác định và cần sự hiển thị không chạm mà chúng tôi đã xây dựng.
Làm thế nào nền tảng của bạn trong lĩnh vực an ninh mạng, hệ thống nhúng và nghiên cứu phát triển học máy ảnh hưởng đến tầm nhìn đằng sau groundcover và những thách thức đầu tiên bạn phải đối mặt khi xây dựng một công ty tập trung vào khả năng quan sát cho các ứng dụng và ứng dụng LLM?
Nền tảng an ninh mạng của tôi đã định hình ADN của công ty. Trong thế giới tình báo, bạn giả định rằng bạn không kiểm soát ứng dụng. Đó là lý do tại sao groundcover không yêu cầu công cụ hóa. Tôi biết từ kinh nghiệm rằng yêu cầu các nhà phát triển sửa đổi mã là cách nhanh nhất để chặn việc áp dụng. Thách thức khó khăn nhất ban đầu với việc giám sát LLM là vấn đề bảo mật. Khả năng quan sát AI thu thập các lời nhắc có thể chứa thông tin cá nhân hoặc sở hữu trí tuệ nhạy cảm. Nền tảng của tôi đã khiến tôi nhận ra rõ ràng rằng các doanh nghiệp sẽ không muốn dữ liệu đó rời khỏi môi trường của họ. Đó là lý do tại sao chúng tôi xây dựng kiến trúc dựa trên đám mây, cho phép chúng tôi cung cấp cái nhìn sâu sắc vào hành vi của tác nhân trong khi giữ tất cả dữ liệu bên trong môi trường của khách hàng.
Bạn định nghĩa khả năng quan sát LLM như thế nào và điều gì làm cho nó khác biệt so với giám sát truyền thống hoặc giám sát học máy?
Khả năng quan sát LLM là việc thực hành công cụ hóa và giám sát các hệ thống sản xuất sử dụng các mô hình ngôn ngữ lớn để bạn có thể thu thập toàn bộ ngữ cảnh của mỗi suy luận: lời nhắc, ngữ cảnh, hoàn thành, sử dụng token, độ trễ, lỗi, siêu dữ liệu mô hình và lý tưởng nhất là tín hiệu phản hồi hoặc chất lượng. Thay vì chỉ hỏi “Dịch vụ có hoạt động và nhanh không?” hoặc “Yêu cầu này có lỗi không?”, khả năng quan sát LLM giúp bạn trả lời các câu hỏi như “Tại sao yêu cầu này cụ thể thành công hoặc thất bại?”, “Thực sự xảy ra gì trong công việc đa bước này?” và “Làm thế nào các thay đổi đối với lời nhắc, ngữ cảnh hoặc phiên bản mô hình ảnh hưởng đến chi phí, độ trễ và chất lượng đầu ra?” Đó là rất khác so với các phương pháp giám sát truyền thống hoặc thậm chí là giám sát học máy cổ điển. Các phương pháp cũ được điều chỉnh cho các hệ thống xác định, số liệu cơ sở hạ tầng, ngưỡng tĩnh. Các ứng dụng LLM là không xác định, mở và phụ thuộc rất nhiều vào ngữ cảnh. Sự thành công thường là ngữ nghĩa và chủ quan, không chỉ là mã trạng thái 200 so với 500. Điều đó có nghĩa bạn phải theo dõi đầu vào và đầu ra, hiểu các cuộc gọi công cụ và bước thu hồi, đánh giá phản hồi về các khía cạnh như ảo giác hoặc vi phạm chính sách và kết nối chi phí và độ trễ token với ứng dụng và cơ sở hạ tầng xung quanh.
Các ứng dụng được hỗ trợ bởi LLM giới thiệu những thách thức nào mà các công cụ quan sát truyền thống không đủ?
Các hệ thống hỗ trợ bởi LLM giới thiệu một số thách thức mà các công cụ truyền thống không thể giải quyết:
- Các công việc đa bước phức tạp – Chúng đã chuyển từ các luồng “gọi mô hình, nhận phản hồi” đơn giản sang các tác nhân đa bước, đường ống đa bước, tạo ra tăng cường và sử dụng công cụ. Một lỗi im lặng trong bất kỳ bước nào trong số đó, chẳng hạn như thu hồi, tăng cường, nhúng, gọi công cụ hoặc gọi mô hình, có thể phá vỡ toàn bộ trải nghiệm. Giám sát truyền thống thường không cung cấp cho bạn cái nhìn đầy đủ, theo dõi từng bước của các chuỗi này với lời nhắc và phản hồi được bao gồm.
- Các ngăn xếp AI đang phát triển nhanh chóng – Các đội đang thêm các mô hình mới, công cụ và nhà cung cấp với tốc độ họ chưa từng thấy trước đây. Ở nhiều công ty, không ai có thể tự tin liệt kê các mô hình đang được sản xuất tại bất kỳ thời điểm nào. Giám sát cổ điển thường giả định bạn có thời gian để công cụ hóa SDK, triển khai lại và chăm sóc cẩn thận những gì bạn đo lường. Điều đó đơn giản là không theo kịp tốc độ mà AI đang được áp dụng.
- Kinh tế và hạn ngạch dựa trên token – Giá cả và hạn ngạch được gắn với token và độ dài ngữ cảnh, thường được kiểm soát bởi nhà phát triển, lời nhắc hoặc hành vi người dùng, không phải bởi hoạt động trung tâm. Các công cụ truyền thống không được thiết kế để hiển thị “ai đã sử dụng bao nhiêu token trên mô hình nào, cho công việc nào, với độ trễ nào”.
- Đúng ngữ nghĩa thay vì thành công nhị phân – Một LLM có thể trả về mã trạng thái 200 và vẫn ảo giác, trôi dạt khỏi lời nhắc của bạn hoặc vi phạm chính sách. Các công cụ truyền thống coi đó là thành công. Bạn cần khả năng quan sát có thể hiển thị lời nhắc và phản hồi và cung cấp đủ ngữ cảnh để kiểm tra hành vi và theo thời gian, cắm các kiểm tra chất lượng tự động.
- Dữ liệu đầu vào nhạy cảm chảy vào các bên thứ ba – LLM mời người dùng chia sẻ thông tin rất nhạy cảm thông qua giao diện tương tự như trò chuyện. Bây giờ bạn chịu trách nhiệm về dữ liệu đó, nơi nó được lưu trữ và các nhà cung cấp phụ nào nhìn thấy nó. Giám sát SaaS truyền thống dựa trên đám mây thường không thể chấp nhận được cho các công việc này.
Tất cả những điều này có nghĩa là các hệ thống LLM yêu cầu khả năng quan sát nhận thức AI, giàu ngữ cảnh và ít phụ thuộc vào công cụ hóa thủ công hơn so với các công cụ mà hầu hết các đội sử dụng ngày nay.
Các tín hiệu hoặc số liệu nào là quan trọng nhất để hiểu hiệu suất và chất lượng của các hệ thống LLM, bao gồm độ trễ, sử dụng token và hành vi lời nhắc / phản hồi?
Có một số loại tín hiệu quan trọng trong thực tế:
Độ trễ và thông lượng
- Độ trễ từ đầu đến cuối cho mỗi yêu cầu, bao gồm thời gian mô hình và thời gian ứng dụng xung quanh.
- Độ trễ đuôi (P90, P95, P99) cho mỗi mô hình và mỗi công việc.
- Thông lượng theo mô hình, tuyến đường và dịch vụ, để bạn biết nơi tải thực sự đang diễn ra.
Sử dụng token và tài nguyên chi phí
- Token đầu vào và đầu ra cho mỗi yêu cầu, được chia nhỏ theo mô hình.
- Sử dụng token tổng hợp theo thời gian cho mỗi mô hình, nhóm, người dùng và công việc.
- Kích thước ngữ cảnh cho các đường ống thu hồi nặng để bạn có thể xem khi lời nhắc nổ.
- Đây là những gì cho phép bạn trả lời “Ai thực sự đang chi tiêu ngân sách AI của chúng tôi và trên cái gì?”
Hành vi lời nhắc và phản hồi
- Payloader lời nhắc và phản hồi thực tế trên các dấu vết đại diện, bao gồm các cuộc gọi công cụ và đường dẫn suy luận.
- Các công cụ mà LLM đã chọn gọi và theo trình tự nào.
- Biến thể trong phản hồi cho các lời nhắc tương tự để bạn có thể nói hành vi ổn định như thế nào.
Độ tin cậy và lỗi
- Tỷ lệ lỗi và loại lỗi cụ thể (lỗi nhà cung cấp, thời gian chờ, vấn đề xác thực, lỗi hạn ngạch).
- Thất bại trong công việc xung quanh, chẳng hạn như thời gian chờ công cụ hoặc lỗi thu hồi, tương quan với cuộc gọi LLM.
Ngữ cảnh cơ sở hạ tầng cổ điển
- Đồng hồ CPU, bộ nhớ và số liệu mạng cho các dịch vụ dàn xếp các cuộc gọi LLM của bạn.
- Đồng bộ nhật ký mô tả những gì ứng dụng đang cố gắng thực hiện.
Khi bạn có thể xem tất cả những điều đó trong một nơi, khả năng quan sát LLM chuyển từ “Tôi biết một cái gì đó chậm hoặc đắt” sang “Tôi biết chính xác mô hình, mẫu lời nhắc và dịch vụ nào chịu trách nhiệm và tại sao”.
Làm thế nào khả năng quan sát có thể giúp các đội phát hiện ra các lỗi im lặng như trôi dạt lời nhắc, ảo giác hoặc suy giảm dần chất lượng đầu ra?
Các lỗi im lặng trong các hệ thống LLM thường xảy ra khi mọi thứ trông “xanh” ở cấp độ cơ sở hạ tầng, nhưng hành vi thực tế đang trôi dạt. Khả năng quan sát giúp đỡ theo một số cách:
- Theo dõi toàn bộ công việc, không chỉ cuộc gọi mô hình – Bằng cách thu thập toàn bộ đường dẫn của một yêu cầu từ khách hàng đến dịch vụ đến thu hồi đến mô hình đến công cụ, bạn có thể xem nơi hành vi đã thay đổi. Ví dụ, có thể thu hồi bắt đầu trả về ít tài liệu hơn, hoặc một cuộc gọi công cụ đang thất bại định kỳ và mô hình đang tự phát.
- Giữ lời nhắc, ngữ cảnh và phản hồi trong tầm nhìn – Khi bạn có thể kiểm tra lời nhắc và phản hồi cùng với dấu vết, nó trở nên dễ dàng hơn nhiều để phát hiện các trường hợp mà một phiên bản lời nhắc mới, một hướng dẫn hệ thống mới hoặc một nguồn ngữ cảnh mới đã thay đổi hành vi, ngay cả khi độ trễ và tỷ lệ lỗi vẫn giống nhau.
- Lọc và cắt trên điều kiện ngữ nghĩa – Một khi bạn có telemetry LLM phong phú, bạn có thể lọc xuống những thứ như “các cuộc gọi cơ bản trên một giây”, “các yêu cầu sử dụng gia đình mô hình này” hoặc “các dấu vết liên quan đến tuyến đường này”, sau đó đọc lời nhắc và phản hồi để xem mô hình có trôi dạt hoặc ảo giác trong một kịch bản cụ thể hay không.
- Cảnh báo trên SLO cấp độ kinh doanh – Bạn có thể định nghĩa SLO như “bất kỳ cuộc gọi LLM nào trên một giây vi phạm SLA hướng tới người dùng của chúng tôi” và kích hoạt cảnh báo khi các điều kiện đó được đáp ứng. Theo thời gian, các SLO tương tự có thể được gắn với điểm số chất lượng hoặc kiểm tra chính sách để bạn nhận được cảnh báo khi chất lượng suy giảm, không chỉ khi cơ sở hạ tầng thất bại.
Bởi vì lớp quan sát có quyền truy cập vào cả tín hiệu AI cụ thể và nhật ký, số liệu và dấu vết cổ điển, nó trở thành một nơi tự nhiên để bắt các vấn đề sẽ suy giảm trải nghiệm người dùng im lặng.
Làm thế nào cách tiếp cận của groundcover hỗ trợ việc chẩn đoán độ trễ không thể đoán trước hoặc hành vi không mong muốn trong các công việc đa bước của tác nhân và cuộc gọi công cụ?
groundcover sử dụng một cách tiếp cận được thiết kế cho các hệ thống AI hiện đại. Chúng tôi sử dụng một cảm biến dựa trên eBPF ở cấp hạt nhân để quan sát lưu lượng truy cập trên các dịch vụ vi mô mà không cần thay đổi mã hoặc triển khai lại. Ngay khi bạn giới thiệu một công việc LLM, chúng tôi có thể tự động khám phá các cuộc gọi đó. Nếu bạn bắt đầu sử dụng một mô hình mới như Anthropic, OpenAI hoặc Bedrock vào ngày mai, groundcover sẽ tự động thu thập lưu lượng truy cập đó. Điều đó cung cấp cho bạn:
- Dấu vết từ đầu đến cuối của các công việc đa bước – Bạn nhìn thấy toàn bộ đường dẫn của một yêu cầu trên các dịch vụ, bao gồm nơi một LLM hoặc công cụ được sử dụng.
- Ngữ cảnh sâu về mỗi cuộc gọi LLM – Mỗi cuộc gọi bao gồm mô hình được sử dụng, độ trễ, sử dụng token, lời nhắc, phản hồi và nhật ký và số liệu cơ sở hạ tầng tương quan.
- Bộ lọc mạnh trên độ trễ và điều kiện – Ví dụ, bạn có thể lọc tất cả các cuộc gọi Claude 3.5 trên một giây và ngay lập tức kiểm tra các dấu vết đã vi phạm SLA của bạn.
- Cảnh báo và bảng điều khiển gắn với hành vi LLM – Một khi dữ liệu có sẵn, bạn có thể tạo cảnh báo cho các vi phạm SLO hoặc xây dựng bảng điều khiển theo dõi độ trễ, thông lượng, sử dụng token và lỗi.
Bởi vì mọi thứ đều được thu thập ở rìa bởi eBPF và được lưu trữ trong đám mây của riêng bạn, bạn có được cái nhìn chi tiết cao mà không cần thêm công cụ hóa vào mỗi tác nhân hoặc cuộc gọi công cụ.
Các rủi ro bảo mật dữ liệu và tuân thủ nào bạn nhìn thấy đang xuất hiện trong các triển khai LLM và khả năng quan sát có thể giúp giảm thiểu những rủi ro đó như thế nào?
Các triển khai LLM mang lại một số rủi ro dữ liệu duy nhất:
- Đầu vào người dùng không giới hạn – Người dùng có thể nhập thông tin rất nhạy cảm vào các giao diện AI và giao diện trò chuyện. Điều đó có thể bao gồm dữ liệu cá nhân, dữ liệu khách hàng hoặc thông tin được quản lý mà bạn không bao giờ muốn thu thập.
- Các nhà cung cấp mô hình bên thứ ba – Một khi bạn gửi dữ liệu đó đến một nhà cung cấp LLM bên ngoài, bạn sẽ chịu trách nhiệm về nơi nó đi, cách nó được lưu trữ và các nhà cung cấp phụ nào tham gia. Điều đó có ý nghĩa quan trọng đối với GDPR, nơi cư trú của dữ liệu và niềm tin của khách hàng.
- Telemetry như một bản sao thứ hai của dữ liệu nhạy cảm – Nếu ngăn xếp quan sát của bạn gửi toàn bộ payload đến một nhà cung cấp SaaS, bạn bây giờ có một bản sao khác của thông tin nhạy cảm đó nằm ngoài môi trường của bạn.
Kiến trúc của groundcover được thiết kế để giải quyết chính xác những mối quan tâm đó:
- Chúng tôi sử dụng mô hình mang đám mây của riêng bạn, nơi toàn bộ ngăn xếp quan sát phía sau chạy trong tài khoản đám mây của bạn, trong một tài khoản con, như một mặt phẳng dữ liệu được quản lý hoàn toàn. Mặt phẳng điều khiển mở rộng và quản lý nó được chạy bởi chúng tôi, nhưng chúng tôi không truy cập, lưu trữ hoặc xử lý dữ liệu telemetry của bạn.
- Bởi vì chúng tôi có thể thu thập an toàn payload trong môi trường của riêng bạn, bạn có thể quan sát lời nhắc, phản hồi và công việc mà không cần dữ liệu đó rời khỏi đám mây của bạn. Không có lưu trữ bên thứ ba của dấu vết LLM của bạn và không có thêm egress dữ liệu để lo lắng.
- Với cái nhìn đó, bạn có thể xem ai đang tải lên cái gì và nơi nó chảy, phát hiện sử dụng không mong muốn của dữ liệu nhạy cảm và thực thi các chính sách xung quanh mô hình và khu vực được phép.
Nói cách khác, khả năng quan sát trở thành không chỉ là một công cụ tin cậy và chi phí, mà còn là một điểm kiểm soát quan trọng cho quyền riêng tư, nơi cư trú của dữ liệu và tuân thủ.
Khi các tổ chức mở rộng từ một tích hợp LLM đến nhiều dịch vụ được hỗ trợ bởi AI, những thách thức hoạt động nào thường xuất hiện xung quanh khả năng hiển thị, độ tin cậy và chi phí?
Tích hợp đầu tiên thường là một mô hình duy nhất trong một công việc duy nhất. Ở giai đoạn đó, mọi thứ có vẻ có thể quản lý được. Khi các đội nhìn thấy giá trị, việc sử dụng nổ tung và một số thách thức xuất hiện:
- Phân tán mô hình và nhà cung cấp – Các đội đang thử nghiệm các mô hình mới liên tục. Nó nhanh chóng trở nên không rõ ràng những mô hình nào đang được sản xuất và chúng được sử dụng như thế nào.
- Đột ngột chi phí từ việc sử dụng token – Tiêu thụ token tăng với độ dài ngữ cảnh và độ phức tạp của công việc. Không có khả năng hiển thị việc sử dụng token theo mô hình và công việc, việc quản lý chi phí trở nên rất khó khăn.
- Sự phụ thuộc độ tin cậy vào các nhà cung cấp bên ngoài – Các API hướng tới người dùng trở nên nhạy cảm với độ trễ mô hình hoặc lỗi, điều này có thể gián đoạn SLA ngay cả khi cơ sở hạ tầng cốt lõi là khỏe mạnh.
- Nợ công cụ hóa ngày càng tăng – Giám sát truyền thống giả định bạn có thể thêm công cụ khi cần. Trong các ngăn xếp AI đang di chuyển nhanh, các nhà phát triển hiếm khi có thời gian cho điều đó.
groundcover giải quyết những điều này bằng cách tự động khám phá lưu lượng truy cập AI và sau đó cung cấp cho bạn:
- Khả năng hiển thị trung tâm về các mô hình và nhà cung cấp được sử dụng.
- Bảng điều khiển hiển thị độ trễ, thông lượng và sử dụng token theo thời gian.
- Sự tương quan giữa hành vi LLM và các dịch vụ phụ thuộc vào nó
- Cảnh báo cho các vi phạm SLO AI.
Điều đó làm cho nó dễ dàng hơn nhiều để mở rộng từ “một tính năng AI cool” sang “AI được dệt vào hàng chục dịch vụ quan trọng” mà không mất kiểm soát.
Nhìn về tương lai, bạn dự đoán khả năng quan sát LLM sẽ phát triển như thế nào trong năm năm tới khi AI tác nhân, đa mô hình và áp lực quy định tăng tốc?
Chúng tôi vẫn còn trong những ngày đầu. Trong năm năm tới, tôi dự đoán một số thay đổi lớn:
- Từ cấp độ yêu cầu đến cấp độ tác nhân – Khả năng quan sát sẽ mở rộng để thu thập các chuỗi công cụ, đường dẫn suy luận và logic retry, không chỉ cuộc gọi mô hình.
- Tín hiệu ngữ nghĩa và chính sách phong phú hơn – Kiểm tra chất lượng tự động cho ảo giác, vấn đề an toàn và sự phù hợp với thương hiệu sẽ trở thành các số liệu chuẩn.
- Liên kết chặt chẽ hơn với quản trị và quyền riêng tư – Khi quy định tăng trưởng, khả năng quan sát cũng sẽ phục vụ như một lớp thực thi và kiểm toán cho nơi cư trú của dữ liệu, lưu giữ và sử dụng mô hình được phê duyệt.
- Tối ưu hóa đa mô hình, đa nhà cung cấp – Các đội sẽ định tuyến lưu lượng truy cập trên các mô hình dựa trên hiệu suất và chi phí, được hướng dẫn bởi dữ liệu quan sát thời gian thực.
- Ít công cụ hóa thủ công hơn – Các kỹ thuật như thu thập dựa trên eBPF và khám phá tự động sẽ trở thành mặc định, vì vậy các đội có thể đổi mới mà không chậm lại.
Tóm lại, khả năng quan sát LLM sẽ phát triển từ “đnice để có bảng điều khiển cho AI” thành hệ thống thần kinh trung ương kết nối độ tin cậy, kiểm soát chi phí, quản trị dữ liệu và chất lượng sản phẩm trên mọi thứ một tổ chức làm với AI.
Cảm ơn 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 groundcover.












