ชาฮาร์ อะซูเลย์ ซีอีโอและผู้ร่วมก่อตั้งบริษัท Groundcover

ชาฮาร์ อะซูเลย์ ซีอีโอและผู้ร่วมก่อตั้ง Groundcover อย่าง Shahar เป็นผู้นำด้านการวิจัยและพัฒนาที่มีประสบการณ์มากมาย เขาเชี่ยวชาญด้านความปลอดภัยทางไซเบอร์และการเรียนรู้ของเครื่องจักร โดยเคยดำรงตำแหน่งผู้นำในบริษัทต่างๆ เช่น Apple, DayTwo และ Cymotive Technologies Shahar ใช้เวลาหลายปีในแผนกไซเบอร์ของสำนักงานนายกรัฐมนตรีอิสราเอล และสำเร็จการศึกษาระดับปริญญาตรี 3 สาขา ได้แก่ ฟิสิกส์ วิศวกรรมไฟฟ้า และวิทยาการคอมพิวเตอร์ จากสถาบันเทคโนโลยี Technion Israel และมหาวิทยาลัย Tel Aviv Shahar มุ่งมั่นที่จะนำความรู้ทางเทคโนโลยีจากประสบการณ์อันยาวนานนี้มาใช้ในสมรภูมิคลาวด์เนทีฟในปัจจุบันอย่างเฉียบคมและสร้างสรรค์ที่สุด เพื่อทำให้โลกแห่งการพัฒนาซอฟต์แวร์ดีขึ้น

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

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

แรงผลักดันในการสร้างระบบตรวจสอบความปลอดภัยมาจากช่วงเวลาที่ผมทำงานที่ Apple และ DayTwo แม้จะมีงบประมาณมหาศาล เราก็ยังติดอยู่กับการเลือกระหว่างการจ่ายเงินก้อนโตเพื่อบันทึกทุกอย่าง หรือการสุ่มตัวอย่างและทำงานโดยไม่รู้ข้อมูลอะไรเลย ในเวลานั้น เรากำลังมองหาเทคโนโลยีที่จะแก้ปัญหานั้น เมื่อเราได้พบกับ Extended Berkeley Packet Filter (eBPF) ก็ชัดเจนว่ามันจะเปลี่ยนทุกอย่าง eBPF ช่วยให้เรามองเห็นทุกสิ่งที่เกิดขึ้นในเคอร์เนลโดยไม่ต้องพึ่งพาการเปลี่ยนแปลงของแอปพลิเคชัน ผมไม่เข้าใจว่าทำไมเครื่องมือตรวจสอบความปลอดภัยจึงไม่ใช้ประโยชน์จากสิ่งนี้ ช่องว่างของ AI ชัดเจนขึ้นในภายหลัง เมื่อแพลตฟอร์ม Kubernetes ของเราเติบโตเต็มที่ เราเห็นลูกค้ารีบเร่งในการใช้งาน GenAI ในขณะที่มอง LLM เหมือนกล่องดำ พวกเขารู้ว่าโมเดลตอบสนอง แต่ไม่รู้ว่าทำไมมันถึงทำงานอย่างคาดเดาไม่ได้ หรือทำไมต้นทุนถึงพุ่งสูงขึ้น เราตระหนักว่าเวิร์กโฟลว์แบบเอเจนต์นั้นเป็นเพียงไมโครเซอร์วิสที่ซับซ้อนและไม่สามารถคาดเดาได้ ซึ่งต้องการการมองเห็นแบบไม่ต้องสัมผัสใดๆ เช่นเดียวกับที่เราได้สร้างไว้แล้ว

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

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

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

การตรวจสอบการทำงานของ LLM (Large Language Model) คือการติดตั้งเครื่องมือและตรวจสอบระบบการผลิตที่ใช้โมเดลภาษาขนาดใหญ่ เพื่อให้คุณสามารถบันทึกบริบททั้งหมดของการอนุมานแต่ละครั้งได้ ไม่ว่าจะเป็นข้อความแจ้ง บริบท การเสร็จสิ้น การใช้งานโทเค็น ความหน่วง ข้อผิดพลาด เมตาเดต้าของโมเดล และโดยอุดมคติแล้วคือสัญญาณตอบรับหรือสัญญาณคุณภาพในขั้นตอนถัดไป แทนที่จะถามเพียงแค่ว่า “บริการทำงานได้เร็วหรือไม่” หรือ “คำขอเกิดข้อผิดพลาดหรือไม่” การตรวจสอบการทำงานของ LLM ช่วยให้คุณตอบคำถามเช่น “เหตุใดคำขอเฉพาะนี้จึงสำเร็จหรือล้มเหลว” “เกิดอะไรขึ้นจริง ๆ ภายในเวิร์กโฟลว์หลายขั้นตอน” และ “การเปลี่ยนแปลงข้อความแจ้ง บริบท หรือเวอร์ชันของโมเดลส่งผลต่อต้นทุน ความหน่วง และคุณภาพของผลลัพธ์อย่างไร” ซึ่งแตกต่างอย่างมากจากการตรวจสอบแบบดั้งเดิม หรือแม้แต่การตรวจสอบ ML แบบคลาสสิก วิธีการแบบเดิมได้รับการปรับแต่งสำหรับระบบที่กำหนดได้ เมตริกโครงสร้างพื้นฐาน และเกณฑ์คงที่ แอปพลิเคชัน LLM นั้นไม่สามารถกำหนดได้ เปิดกว้าง และขึ้นอยู่กับบริบทอย่างมาก ความสำเร็จมักเป็นเรื่องของความหมายและอัตวิสัย ไม่ใช่แค่รหัสสถานะ 200 เทียบกับ 500 เท่านั้น นั่นหมายความว่าคุณต้องติดตามอินพุตและเอาต์พุต เข้าใจการเรียกใช้เครื่องมือและขั้นตอนการดึงข้อมูล ประเมินการตอบสนองสำหรับสิ่งต่างๆ เช่น ภาพหลอนหรือการละเมิดนโยบาย และเชื่อมโยงต้นทุนและความล่าช้าในระดับโทเค็นกลับไปยังแอปพลิเคชันและโครงสร้างพื้นฐานโดยรอบ

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

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

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

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

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

มีสัญญาณอยู่ไม่กี่ประเภทที่มีความสำคัญอย่างมากในทางปฏิบัติ:

ความหน่วงและปริมาณงาน

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

การใช้งานโทเค็นและปัจจัยด้านต้นทุน

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

พฤติกรรมการตอบสนองอย่างรวดเร็ว

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

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

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

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

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

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

การตรวจสอบช่วยให้ทีมตรวจจับความล้มเหลวที่เกิดขึ้นอย่างเงียบๆ ได้อย่างไร เช่น การเปลี่ยนแปลงอย่างฉับพลัน ภาพหลอน หรือคุณภาพผลลัพธ์ที่ลดลงอย่างค่อยเป็นค่อยไป?

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

• ติดตามขั้นตอนการทำงานทั้งหมด ไม่ใช่แค่การเรียกใช้โมเดล – การบันทึกเส้นทางทั้งหมดของการร้องขอจากไคลเอ็นต์ไปยังบริการ การดึงข้อมูล การสร้างแบบจำลอง และการใช้เครื่องมือ จะช่วยให้คุณเห็นว่าพฤติกรรมเปลี่ยนแปลงไปที่ใด ตัวอย่างเช่น การดึงข้อมูลอาจส่งคืนเอกสารน้อยลง หรือการเรียกใช้เครื่องมือล้มเหลวเป็นระยะ และแบบจำลองกำลังปรับปรุงแก้ไขเฉพาะหน้า
• โดยคำนึงถึงคำถาม บริบท และการตอบสนองอยู่เสมอ – เมื่อคุณสามารถตรวจสอบข้อความแจ้งเตือนและการตอบสนองควบคู่ไปกับข้อมูลการติดตามได้ จะทำให้การระบุกรณีที่เวอร์ชันข้อความแจ้งเตือนใหม่ คำสั่งระบบใหม่ หรือแหล่งบริบทใหม่ เปลี่ยนแปลงพฤติกรรมได้ง่ายขึ้นมาก แม้ว่าความหน่วงและอัตราข้อผิดพลาดจะยังคงเท่าเดิมก็ตาม
• การกรองและการแบ่งส่วนตามเงื่อนไขทางความหมาย – เมื่อคุณมีข้อมูลการวัดระยะทางของ LLM ที่ครบถ้วนแล้ว คุณสามารถกรองข้อมูลลงไปถึงรายละเอียดต่างๆ เช่น “การเรียกใช้ฐานระบบที่นานกว่าหนึ่งวินาที”, “คำขอที่ใช้ตระกูลโมเดลนี้” หรือ “ร่องรอยที่เกี่ยวข้องกับเส้นทางเฉพาะนี้” จากนั้นอ่านข้อความแจ้งและคำตอบเพื่อดูว่าโมเดลมีการเบี่ยงเบนหรือเกิดภาพหลอนในสถานการณ์เฉพาะหรือไม่
• การแจ้งเตือนเกี่ยวกับ 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 การจัดเก็บข้อมูลในประเทศ และความไว้วางใจของลูกค้า
• ระบบส่งข้อมูลทางไกล (Telemetry) เป็นสำเนาที่สองของข้อมูลสำคัญ – หากระบบตรวจสอบการทำงานของคุณส่งข้อมูลทั้งหมดไปยังผู้ให้บริการ SaaS คุณก็จะมีสำเนาข้อมูลสำคัญนั้นอีกชุดหนึ่งอยู่นอกสภาพแวดล้อมของคุณ

โครงสร้างทางสถาปัตยกรรมของพืชคลุมดินได้รับการออกแบบมาเพื่อแก้ไขข้อกังวลเหล่านั้นโดยเฉพาะ:

• เราใช้โมเดล Bring Your Own Cloud (BRO) โดยที่ระบบตรวจสอบและเฝ้าระวังทั้งหมดจะทำงานอยู่ภายในบัญชีคลาวด์ของคุณ ในบัญชีย่อย ในรูปแบบของ Data Plane ที่ได้รับการจัดการอย่างเต็มรูปแบบ ส่วน Control Plane ที่ทำหน้าที่ปรับขนาดและจัดการระบบนั้น เราเป็นผู้ดูแล แต่เราจะไม่เข้าถึง จัดเก็บ หรือประมวลผลข้อมูล Telemetry ของคุณ
• เนื่องจากเราสามารถบันทึกข้อมูลได้อย่างปลอดภัยในสภาพแวดล้อมของคุณเอง คุณจึงสามารถสังเกตข้อความแจ้งเตือน การตอบสนอง และขั้นตอนการทำงานได้โดยที่ข้อมูลเหล่านั้นไม่ถูกส่งออกจากระบบคลาวด์ของคุณ ไม่มีการจัดเก็บข้อมูลการติดตาม LLM ของคุณโดยบุคคลที่สาม และไม่ต้องกังวลเรื่องการส่งออกข้อมูลเพิ่มเติม
• ด้วยความสามารถในการมองเห็นภาพรวมนี้ คุณจะสามารถดูได้ว่าใครกำลังอัปโหลดอะไรและข้อมูลไหลไปที่ใด ตรวจจับการใช้งานข้อมูลที่ละเอียดอ่อนโดยไม่คาดคิด และบังคับใช้นโยบายเกี่ยวกับโมเดลและภูมิภาคที่ได้รับอนุญาต

กล่าวอีกนัยหนึ่ง ความสามารถในการตรวจสอบได้กลายเป็นเครื่องมือที่ไม่เพียงแต่ช่วยเพิ่มความน่าเชื่อถือและลดต้นทุนเท่านั้น แต่ยังเป็นจุดควบคุมที่สำคัญสำหรับความเป็นส่วนตัว การจัดเก็บข้อมูลในประเทศ และการปฏิบัติตามกฎระเบียบอีกด้วย

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

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

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

แอปพลิเคชัน groundcover แก้ปัญหาเหล่านี้โดยการตรวจจับปริมาณการจราจรด้วย AI โดยอัตโนมัติ แล้วแสดงผลลัพธ์ดังนี้:

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

นั่นทำให้การขยายขอบเขตจาก “ฟีเจอร์ AI สุดเจ๋งเพียงอย่างเดียว” ไปสู่ ​​“การผสาน AI เข้ากับบริการสำคัญหลายสิบรายการ” ทำได้ง่ายขึ้นมาก โดยไม่สูญเสียการควบคุม

เมื่อมองไปข้างหน้า คุณคาดหวังว่าการตรวจสอบ LLM จะพัฒนาไปอย่างไรในอีกห้าปีข้างหน้า ในขณะที่ AI แบบตัวแทน การจัดการแบบหลายโมเดล และแรงกดดันด้านกฎระเบียบเพิ่มสูงขึ้น?

เราเพิ่งเริ่มต้นเท่านั้น ในอีกห้าปีข้างหน้า ผมคาดว่าจะมีการเปลี่ยนแปลงครั้งใหญ่หลายอย่าง:

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

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

ขอบคุณสำหรับบทสัมภาษณ์ที่ดี ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมควรเยี่ยมชม คลุมดิน.