ชาหาร์ อาซูลาย ผู้บริหารสูงสุดและผู้ร่วมก่อตั้ง groundcover

ชาหาร์ อาซูลาย ผู้บริหารสูงสุดและผู้ร่วมก่อตั้ง groundcover เป็นผู้นำด้านการวิจัยและพัฒนา (R&D) ที่มีประสบการณ์ยาวนานในด้านความมั่นคงทางไซเบอร์และการเรียนรู้ของเครื่องจักร (Machine Learning) โดย曾ทำงานในบริษัทชั้นนำ เช่น Apple, DayTwo และ Cymotive Technologies ชาหาร์ใช้เวลาหลายปีในแผนกไซเบอร์ของสำนักงานนายกรัฐมนตรีของอิสราเอล และจบการศึกษาสามใบจากสาขาฟิสิกส์ วิศวกรรมไฟฟ้า และวิทยาศาสตร์คอมพิวเตอร์จาก Technion Israel Institute of Technology และ Tel Aviv University ชาหาร์มุ่งมั่นที่จะนำความรู้ด้านเทคโนโลยีจากประสบการณ์อันกว้างขวางมาใช้ในการสร้างสนามรบที่มีประสิทธิภาพและนวัตกรรมที่สุดเพื่อทำให้โลกของนักพัฒนาสามารถทำงานได้ดีขึ้น

groundcover เป็นแพลตฟอร์มการดูแลระบบแบบคลาวด์ (Cloud-Native Observability Platform) ที่ออกแบบมาเพื่อให้ทีมวิศวกรมองเห็นระบบของตนได้อย่างเต็มที่และแบบเรียลไทม์ โดยไม่ต้องมีความซับซ้อนหรือค่าใช้จ่ายสูงเหมือนเครื่องมือติดตามแบบดั้งเดิม groundcover ถูกสร้างขึ้นโดยใช้เทคโนโลยี eBPF (Extended Berkeley Packet Filter) ซึ่งช่วยเก็บและเชื่อมโยงบันทึก (Logs) เมตริกส์ (Metrics) การติดตาม (Traces) และเหตุการณ์ (Events) ทั่วทั้งระบบคลาวด์และ Kubernetes โดยไม่ต้องมีการเปลี่ยนแปลงโค้ด ทำให้สามารถวิเคราะห์สาเหตุของปัญหาได้เร็วขึ้นและเข้าใจระบบได้ดีขึ้น แพลตฟอร์มนี้เน้นย้ำถึงการกำหนดราคาแบบคาดการณ์ได้ การติดตั้งที่ยืดหยุ่นซึ่งเก็บข้อมูลลูกค้าไว้ในคลาวด์ของตนเอง และการดูแลระบบแบบต่อเนื่องที่ครอบคลุมโครงสร้างพื้นฐาน แอปพลิเคชัน และเวิร์กโหลดที่ขับเคลื่อนด้วย AI แบบสมัยใหม่

เมื่อมองย้อนกลับไปที่ประสบการณ์ของคุณ ตั้งแต่การนำทีม R&D ในด้านไซเบอร์ของสำนักงานนายกรัฐมนตรีของอิสราเอล ไปจนถึงการบริหารโครงการ Machine Learning ที่ Apple คุณได้รับประสบการณ์อะไรที่ผลักดันให้คุณก่อตั้ง groundcover และเมื่อไหร่ที่คุณรับรู้ถึงช่องว่างในการดูแลระบบสำหรับระบบ AI แบบสมัยใหม่?

การก่อตั้ง groundcover เกิดขึ้นจากประสบการณ์ของฉันที่ Apple และ DayTwo แม้จะมีงบประมาณขนาดใหญ่ แต่เราก็ยังต้องเลือกว่าจะจ่ายเงินจำนวนมากเพื่อบันทึกทุกอย่างหรือตัวอย่างและบินตามใจคิด เมื่อก่อนเรากำลังมองหเทคโนโลยีที่จะแก้ปัญหานั้น เมื่อเราพบ eBPF ก็ชัดเจนว่ามันจะเปลี่ยนแปลงทุกอย่าง eBPF ช่วยให้เราเห็นทุกอย่างที่เกิดขึ้นในเคอร์เนลโดยไม่ต้องอาศัยการเปลี่ยนแปลงแอปพลิเคชัน ฉันไม่เข้าใจว่าทำไมเครื่องมือการดูแลระบบจึงไม่ได้ใช้ประโยชน์จากสิ่งนั้น ช่องว่างในการดูแลระบบ AI เกิดขึ้นชัดเจนภายหลัง เมื่อแพลตฟอร์ม Kubernetes ของเราสเต็ปขึ้น เราเห็นลูกค้าเร่งรีบในการใช้งาน GenAI ในขณะที่รักษา LLMs ไว้เหมือนกล่องดำ พวกเขารู้ว่าโมเดลตอบสนอง แต่ไม่รู้ว่าทำไมจึงมีพฤติกรรมที่ไม่คาดคิดหรือค่าใช้จ่ายพุ่งสูงขึ้น เราเข้าใจว่าเวิร์กโฟลว์แบบอเจนติกเป็นเพียงไมโครเซอร์วิสที่ซับซ้อนและไม่แน่นอนซึ่งต้องการการมองเห็นที่ไม่ต้องสัมผัสแบบที่เรามีแล้ว

ประสบการณ์ของคุณในด้านความมั่นคงทางไซเบอร์ ระบบฝังตัว และการวิจัย Machine Learning มีอิทธิพลต่อวิสัยทัศน์ของ groundcover อย่างไร และคุณเผชิญกับความท้าทายตั้งแต่แรกเริ่มในการสร้างบริษัทที่มุ่งเน้นการดูแลระบบสำหรับแอปพลิเคชัน LLM และอเจนติกอย่างไร?

ประสบการณ์ด้านไซเบอร์ของฉันส่งผลต่อ DNA ของบริษัท ในโลกข่าวกรอง คุณต้องสมมติว่าคุณไม่ได้ควบคุมแอปพลิเคชัน นั่นคือเหตุผลที่ groundcover ไม่ต้องการการปรับเปลี่ยนเครื่องมือ ฉันรู้จากประสบการณ์ว่าการขอให้นักพัฒนาทำการเปลี่ยนแปลงโค้ดเป็นวิธีที่เร็วที่สุดในการปิดกั้นการนำไปใช้งาน ความท้าทายที่ยากที่สุดในการติดตาม LLM คือเรื่องความเป็นส่วนตัว การดูแลระบบ AI จะบันทึกคำสั่งซึ่งอาจมีข้อมูลส่วนบุคคลหรือทรัพย์สินทางปัญญาที่ละเอียดอ่อน ประสบการณ์ของฉันทำให้ชัดเจนว่าองค์กรจะไม่ต้องการให้ข้อมูลนั้นออกจากสภาพแวดล้อมของตน นั่นคือเหตุผลที่เราสร้างโครงสร้างในคลาวด์ของลูกค้าเพื่อให้สามารถมองเห็นพฤติกรรมของเอเจนต์ได้โดยไม่ต้องส่งข้อมูลออกไป

คุณกำหนด LLM Observability อย่างไร และมันแตกต่างจากการติดตามแบบดั้งเดิมหรือการตรวจสอบ Machine Learning อย่างไร?

การดูแลระบบ LLM คือการปฏิบัติในการติดตามและตรวจสอบระบบการผลิตที่ใช้โมเดลภาษาขนาดใหญ่เพื่อให้สามารถจับภาพบริบททั้งหมดของการอนุมานทุกครั้ง: คำสั่ง บริบท การเติมเต็ม การใช้โทเค็น ความล่าช้า ข้อผิดพลาด เมตาดาต้าของโมเดล และในอุดมคติแล้ว ฟีดแบ็กหรือสัญญาณคุณภาพในทางกลับกัน ไม่ใช่แค่ถามว่า “บริการเปิดใช้งานและเร็วไหม” หรือ “คำขอนี้ผิดพลาดหรือไม่” การดูแลระบบ LLM ช่วยให้คุณตอบคำถามอย่าง “ทำไมคำขอนี้สำเร็จหรือล้มเหลว” “เกิดอะไรขึ้นภายในเวิร์กโฟลว์ที่มีหลายขั้นตอน” และ “การเปลี่ยนแปลงคำสั่ง บริบท หรือเวอร์ชันโมเดลส่งผลต่อค่าใช้จ่าย ความล่าช้า และคุณภาพเอาต์พุตอย่างไร” สิ่งนี้แตกต่างจากการติดตามแบบดั้งเดิมหรือแม้แต่การตรวจสอบ Machine Learning แบบคลาสสิก วิธีการแบบดั้งเดิมถูกตั้งค่าสำหรับระบบที่แน่นอน ข้อมูลโครงสร้างพื้นฐาน และค่าขีดจำกัดแบบคงที่ ระบบ LLM เป็นแบบไม่แน่นอน เปิดกว้าง และขึ้นอยู่กับบริบทอย่างมาก ความสำเร็จมักจะอยู่ในเชิงอธิบายและเป็นเรื่องส่วนตัว ไม่ใช่แค่สถานะ 200 เทียบกับ 500

แอปพลิเคชันที่ใช้ LLM นำเสนอความท้าทายอะไรที่ทำให้เครื่องมือการดูแลระบบแบบดั้งเดิมไม่เพียงพอ?

ระบบที่ใช้ LLM นำเสนอความท้าทายหลายประการที่เปิดเผยข้อจำกัดของเครื่องมือแบบดั้งเดิม:

• เวิร์กโฟลว์ที่ซับซ้อนและหลายขั้นตอน – เราเปลี่ยนจากฟลาว์ที่เรียบง่าย “เรียกโมเดลและรับคำตอบ” ไปเป็นเอเจนต์ที่มีหลายขั้นตอน ปายพ์ไลน์ที่มีหลายขั้นตอน การสร้างแบบเสริมด้วยการค้นหา และการใช้เครื่องมือ การล้มเหลวแบบเงียบในขั้นตอนเหล่านั้น เช่น การค้นหา การเพิ่มคุณค่า การฝังตัว การเรียกเครื่องมือ หรือการเรียกโมเดล สามารถทำลายประสบการณ์ทั้งหมดได้ การติดตามแบบดั้งเดิมมักไม่ได้ให้มุมมองแบบติดตามที่สมบูรณ์ของช่องว่างเหล่านั้นพร้อมคำสั่งและคำตอบ
• สแต็ค AI ที่พัฒนาอย่างรวดเร็ว – ทีมกำลังเพิ่มโมเดลใหม่ เครื่องมือ และผู้ให้บริการด้วยความเร็วที่ไม่เคยเห็นมาก่อน ในหลายบริษัท ไม่มีใครสามารถระบุได้อย่างมั่นใจว่าโมเดลใดอยู่ในระบบการผลิตในขณะใดขณะหนึ่ง การติดตามแบบดั้งเดิมมักจะสมมติว่าคุณมีเวลาในการปรับเครื่องมือ SDK 重新ติดตั้ง และคัดเลือกสิ่งที่คุณวัดอย่างรอบคอบ ซึ่งไม่สามารถตามทันการนำ AI ไปใช้ได้
• เศรษฐศาสตร์แบบโทเค็นและโควต้า – การกำหนดราคาและโควต้าถูกผูกกับโทเค็นและความยาวบริบท ซึ่งมักถูกควบคุมโดยนักพัฒนาสั่งหรือพฤติกรรมผู้ใช้ ไม่ใช่โดยการดำเนินงานกลาง การติดตามแบบดั้งเดิมไม่ได้ถูกสร้างขึ้นเพื่อแสดง “ใครใช้โทเค็นจำนวนเท่าใดในโมเดลใด สำหรับเวิร์กโฟลว์ใด ในความล่าช้าใด”
• ความถูกต้องทางเชิงอธิบายแทนความสำเร็จแบบไบนารี – LLM สามารถส่งกลับ 200 และยังคงหลอกลวง หลงทางจากคำสั่งของคุณ หรือละเมิดนโยบาย การติดตามแบบดั้งเดิมมองว่าสิ่งนี้เป็นความสำเร็จ คุณต้องการการดูแลระบบที่สามารถแสดงคำสั่งและคำตอบและให้ความเข้าใจพฤติกรรมเพียงพอเพื่อตรวจสอบและในระยะยาวเชื่อมต่อการตรวจสอบคุณภาพอัตโนมัติ
• ข้อมูลอินพุตที่ละเอียดอ่อนไหลเข้าไปในบุคคลที่สาม – LLMs เชิญชวนให้ผู้ใช้แบ่งปันข้อมูลที่ละเอียดอ่อนมากผ่านอินเทอร์เฟซที่คล้ายกับการสนทนา ตอนนี้คุณรับผิดชอบต่อข้อมูลนั้น ที่ไหนจัดเก็บ และผู้ให้บริการใดเห็นมัน การติดตามแบบ SaaS ที่ส่งทุกการวัดไปยังบุคคลที่สามมักไม่เหมาะสมสำหรับเวิร์กโหลดเหล่านี้

ทั้งหมดนี้หมายความว่าระบบ LLM ต้องการการดูแลระบบที่ตระหนักถึง AI มีบริบทและต้องมีการปรับเปลี่ยนด้วยตนเองน้อยกว่าเครื่องมือที่ทีมส่วนใหญ่ใช้ในปัจจุบัน

สัญญาณหรือเมตริกใดที่สำคัญที่สุดสำหรับการทำความเข้าใจประสิทธิภาพและคุณภาพของระบบ LLM รวมถึงความล่าช้า การใช้โทเค็น และพฤติกรรมคำสั่ง/คำตอบ?

มีหมวดหมู่ของสัญญาณที่สำคัญมากในทางปฏิบัติ:

ความล่าช้าและปริมาณการทำงาน

• ความล่าช้าที่จบแล้วต่อคำขอ รวมถึงเวลาโมเดลและเวลาแอปพลิเคชันที่อยู่รอบๆ
• ความล่าช้าแบบหาง (P90, P95, P99) ต่อโมเดลและต่อเวิร์กโฟลว์
• ปริมาณการทำงานตามโมเดล เส้นทาง และบริการ เพื่อให้คุณรู้ว่าภาระงานไปที่ไหนจริงๆ

การใช้โทเค็นและต้นทุน

• โทเค็นอินพุตและเอาต์พุตต่อคำขอ แบ่งตามโมเดล
• การใช้โทเค็นรวมตามเวลา ต่อโมเดล ทีม ผู้ใช้ และเวิร์กโฟลว์
• ขนาดบริบทสำหรับไปป์ไลน์ที่หนักไปทางการค้นหา เพื่อให้คุณเห็นว่าเมื่อไหร่ที่คำสั่งจะระเบิด
• สิ่งนี้ช่วยให้คุณตอบว่า “ใครใช้จ่ายงบ AI ของเราและใช้ไปกับอะไร”

พฤติกรรมคำสั่งและคำตอบ

• พayload ของคำสั่งและคำตอบที่แท้จริงในตัวอย่างการวัดที่เป็นตัวแทน รวมถึงการเรียกเครื่องมือและเส้นทางการให้เหตุผล
• เครื่องมือที่ LLM เลือกที่จะเรียกและลำดับ
• ความแปรผันของคำตอบสำหรับคำสั่งที่คล้ายกัน เพื่อให้คุณบอกได้ว่าพฤติกรรมมีความเสถียรแค่ไหน

ความน่าเชื่อถือและข้อผิดพลาด

• อัตราข้อผิดพลาดเฉพาะโมเดลและประเภท (ข้อผิดพลาดของผู้ให้บริการ การหมดเวลา ข้อผิดพลาดการรับรอง และข้อผิดพลาดโควต้า)
• ความล้มเหลวในเวิร์กโฟลว์ที่อยู่รอบๆ เช่น การหมดเวลาของเครื่องมือหรือข้อผิดพลาดการค้นหา ที่เกี่ยวข้องกับการเรียก LLM

บริบทโครงสร้างพื้นฐานแบบคลาสสิก

• เมตริกส์ CPU, หน่วยความจำ และเครือข่ายสำหรับบริการที่กำกับดูแลการเรียก LLM
• บันทึกที่เกี่ยวข้องที่อธิบายว่าแอปพลิเคชันพยายามทำอะไร

เมื่อคุณเห็นทุกอย่างในสถานที่เดียว การดูแลระบบ LLM จะเปลี่ยนจาก “ฉันรู้ว่ามีบางสิ่งที่ช้าหรือแพง” เป็น “ฉันรู้ว่าโมเดลใด คำสั่งรูปแบบใด และบริการใดที่รับผิดชอบและทำไม”

การดูแลระบบสามารถช่วยทีมตรวจจับข้อผิดพลาดแบบเงียบๆ เช่น การเลื่อนของคำสั่ง การหลอกลวง หรือการเสื่อมสภาพของคุณภาพเอาต์พุตอย่างไร?

ข้อผิดพลาดแบบเงียบๆ ในระบบ LLM มักเกิดขึ้นเมื่อทุกอย่างดู “เขียว” ที่ระดับโครงสร้างพื้นฐาน แต่พฤติกรรมที่แท้จริงกำลังเลื่อน การดูแลระบบช่วยในหลายวิธี:

• การวัดเวิร์กโฟลว์ทั้งหมด ไม่ใช่แค่การเรียกโมเดล – โดยการบันทึกเส้นทางเต็มของคำขอจากไคลเอ็นต์ไปยังบริการไปยังการค้นหาไปยังโมเดลไปยังเครื่องมือ คุณสามารถเห็นว่าพฤติกรรมเปลี่ยนแปลงไปที่ไหน เช่น การค้นหาที่เริ่มส่งเอกสารน้อยลงหรือการเรียกเครื่องมือที่ล้มเหลวแบบไม่สม่ำเสมอและโมเดลที่ดัดแปลง
• การรักษาคำสั่ง บริบท และคำตอบให้เห็น – เมื่อคุณสามารถตรวจสอบคำสั่งและคำตอบพร้อมกับการวัด คุณสามารถจับกรณีที่เวอร์ชันคำสั่งใหม่ ระบบคำสั่งใหม่ หรือแหล่งบริบทใหม่เปลี่ยนพฤติกรรมได้ แม้ว่าความล่าช้าและอัตราข้อผิดพลาดจะยังคงเท่าเดิม
• การกรองและการตัดตามเงื่อนไขเชิงอธิบาย – เมื่อคุณมีการวัด LLM ที่มีรายละเอียด คุณสามารถกรองให้แคบลงไปที่สิ่งเช่น “การเรียก Bedrock ที่มากกว่าหนึ่งวินาที” หรือ “การวัดที่เกี่ยวข้องกับเส้นทางนี้” จากนั้น คุณสามารถอ่านคำสั่งและคำตอบเพื่อดูว่าโมเดลหลอกลวงหรือเลื่อนในสถานการณ์เฉพาะหรือไม่
• การเตือนบน SLO ระดับธุรกิจ – คุณสามารถกำหนด SLO เช่น “การเรียก LLM ใดๆ ที่มากกว่าหนึ่งวินาทีจะละเมิด SLA ของเรา” และทริกเกอร์เตือนเมื่อเงื่อนไขเหล่านั้นถูกต้อง ในระยะยาว SLO เหล่านี้สามารถเชื่อมโยงกับผลคะแนนคุณภาพหรือการตรวจสอบนโยบายเพื่อให้คุณได้รับการเตือนเมื่อคุณภาพลดลง ไม่ใช่แค่เมื่อโครงสร้างพื้นฐานล้มเหลว

เนื่องจากชั้นการดูแลระบบมีการเข้าถึงสัญญาณ AI และสัญญาณคลาสสิกทั้งสอง คุณจึงสามารถจับปัญหาได้ที่จะเสื่อมสภาพประสบการณ์ของผู้ใช้โดยไม่เงียบๆ

วิธีการของ groundcover สนับสนุนการวินิจฉัยความล่าช้าที่ไม่คาดคิดหรือพฤติกรรมที่ไม่คาดคิดภายในเวิร์กโฟลว์ของเอเจนต์แบบหลายขั้นตอนและเรียกเครื่องมืออย่างไร?

groundcover ใช้วิธีการที่ออกแบบมาสำหรับระบบ AI สมัยใหม่ เราใช้เซ็นเซอร์ eBPF ระดับเคอร์เนลเพื่อสังเกตการจราจรทั่วไมโครเซอร์วิสโดยไม่ต้องมีการเปลี่ยนแปลงโค้ดหรือการปรับใหม่ เมื่อคุณแนะนำเวิร์กโฟลว์ LLM เราสามารถค้นหาและติดตามการเรียกเหล่านั้นโดยอัตโนมัติ หากคุณเริ่มใช้โมเดลใหม่ เช่น Anthropic, OpenAI หรือ Bedrock วันพรุ่งนี้ groundcover จะจับจราจรนั้นโดยอัตโนมัติ ซึ่งให้:

• การวัดแบบติดตามทั้งเวิร์กโฟลว์แบบหลายขั้นตอน – คุณเห็นเส้นทางเต็มของคำขอข้ามบริการ รวมถึงที่ที่ LLM หรือเครื่องมือถูกใช้
• บริบทลึกสำหรับการเรียก LLM ทุกครั้ง – การเรียกทุกครั้งรวมโมเดลที่ใช้ ความล่าช้า การใช้โทเค็น คำสั่ง คำตอบ และบันทึกและเมตริกส์โครงสร้างพื้นฐานที่เกี่ยวข้อง
• การกรองที่ทรงพลังบนความล่าช้าและเงื่อนไข – ตัวอย่างเช่น คุณสามารถกรองเพื่อการเรียก Claude 3.5 ที่มากกว่าหนึ่งวินาทีและตรวจสอบการวัดที่ละเมิด SLA ของคุณทันที
• การเตือนและแผงควบคุมที่เชื่อมโยงกับพฤติกรรม LLM – เมื่อข้อมูลมีให้ คุณสามารถสร้างการเตือนสำหรับการละเมิด SLA หรือสร้างแผงควบคุมเพื่อติดตามความล่าช้า ปริมาณการทำงาน การใช้โทเค็น และข้อผิดพลาด

เนื่องจากทุกอย่างถูกเก็บที่ขอบด้วย eBPF และเก็บไว้ในคลาวด์ของคุณ คุณจะได้มุมมองละเอียดอ่อนนี้โดยไม่ต้องเพิ่มการปรับเปลี่ยนภายในทุกเอเจนต์หรือการเรียกเครื่องมือ

คุณเห็นความเสี่ยงด้านความปลอดภัยของข้อมูลและความเป็นไปตามกฎระเบียบใดที่เกิดขึ้นในระหว่างการนำ LLM ไปใช้ และการดูแลระบบสามารถช่วยลดความเสี่ยงเหล่านั้นได้อย่างไร?

การนำ LLM ไปใช้นำเสนอความเสี่ยงด้านความปลอดภัยของข้อมูลที่ไม่เหมือนใคร:

• อินพุตผู้ใช้ที่ไม่มีขอบเขต – ผู้ใช้สามารถพิมพ์ข้อมูลที่ละเอียดอ่อนมากเข้าไปในอินเทอร์เฟซ AI ที่คล้ายกับการสนทนา ซึ่งอาจรวมถึงข้อมูลส่วนบุคคล ข้อมูลลูกค้า หรือข้อมูลที่มีการควบคุมที่คุณไม่ได้ตั้งใจจะรวบรวม
• ผู้ให้บริการโมเดลบุคคลที่สาม – เมื่อคุณส่งข้อมูลนั้นไปยังผู้ให้บริการ LLM ภายนอก คุณรับผิดชอบต่อที่ที่มันไป ที่เก็บ และผู้รับเหมาที่เกี่ยวข้อง ซึ่งมีผลกระทบอย่างมากต่อ GDPR การพำนักของข้อมูล และความไว้วางใจของลูกค้า
• การวัดเป็นสำเนาที่สองของข้อมูลที่ละเอียดอ่อน – หากการดูแลระบบของคุณส่งพ