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

ชาหาร์ อาซูลาย ผู้บริหารสูงสุดและผู้ร่วมก่อตั้ง groundcover เป็นผู้นำด้านการวิจัยและพัฒนา (R&D) ที่มีประสบการณ์ยาวนานในด้านความมั่นคงทางไซเบอร์และการเรียนรู้ของเครื่องจักร (Machine Learning) โดยเคยทำงานในบริษัทชั้นนำ เช่น Apple (AAPL ), 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 ที่ตั้งของข้อมูล และความไว้วางใจของลูกค้า
• ข้อมูลเทเลเมทรีกลายเป็นสำเนาที่สองของข้อมูลละเอียดอ่อน – หากระบบ observability ส่งเพย์โหลดทั้งหมดไปยังผู้ให้บริการ SaaS ก็เท่ากับมีสำเนาข้อมูลละเอียดอ่อนอีกชุดหนึ่งอยู่นอกสภาพแวดล้อมของคุณ

สถาปัตยกรรมของ groundcover ได้รับการออกแบบมาเพื่อจัดการข้อกังวลเหล่านี้โดยตรง:

• เราใช้รูปแบบ Bring Your Own Cloud โดยแบ็กเอนด์ observability ทั้งหมดทำงานอยู่ภายในบัญชีคลาวด์ของคุณในบัญชีย่อย ในฐานะ data plane ที่ได้รับการจัดการอย่างเต็มรูปแบบ ส่วน control plane ที่ใช้ปรับขนาดและบริหารระบบดำเนินการโดยเรา แต่เราไม่เข้าถึง จัดเก็บ หรือประมวลผลข้อมูลเทเลเมทรีของคุณ
• เพราะสามารถบันทึกเพย์โหลดได้อย่างปลอดภัยภายในสภาพแวดล้อมของคุณ คุณจึงสังเกตพรอมต์ คำตอบ และเวิร์กโฟลว์ได้โดยข้อมูลไม่เคยออกจากคลาวด์ ไม่มีบุคคลที่สามจัดเก็บร่องรอย LLM และไม่มีการส่งข้อมูลออกเพิ่มเติมที่ต้องกังวล
• ด้วยการมองเห็นนี้ คุณตรวจสอบได้ว่าใครกำลังอัปโหลดอะไรและข้อมูลไหลไปที่ใด ตรวจจับการใช้ข้อมูลละเอียดอ่อนที่ไม่คาดคิด และบังคับใช้นโยบายว่าอนุญาตให้ใช้โมเดลและภูมิภาคใดบ้าง

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

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

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

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

groundcover จัดการปัญหาเหล่านี้ด้วยการค้นหาทราฟฟิก AI โดยอัตโนมัติ แล้วมอบความสามารถดังต่อไปนี้:

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

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

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

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

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

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

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