อุตสาหกรรมปัญญาประดิษฐ์กำลังเผชิญกับความท้าทายด้านโครงสร้างพื้นฐานที่สำคัญ เมื่อมาตรฐานที่แข่งขันกันสองตัวต่อสู้เพื่อความเป็นใหญ่ในการสังเกตการณ์ LLM ในขณะที่ OpenTelemetry ได้สถาปนาตัวเองเป็นมาตรฐานอุตสาหกรรมสำหรับการตรวจสอบแอปพลิเคชัน การเกิดขึ้นของเครื่องมือเฉพาะ AI ได้สร้างระบบนิเวศที่กระจัดกระจายซึ่งก่อให้เกิดปัญหาจริงสำหรับทีมพัฒนาในการใช้งานจริง
 |
|---|
| แดชบอร์ด Phoenix แสดงช่วงเวลาการตรวจสอบ เน้นย้ำถึงความท้าทายในการสังเกตการณ์ประสิทธิภาพของ AI agents |
การตรวจสอบความเป็นจริงในการใช้งานจริง
บริษัทที่สร้าง AI agents กำลังค้นพบว่าเครื่องมือตรวจสอบแบบดั้งเดิมไม่เพียงพอเมื่อต้องแก้ไขข้อบกพร่องของพฤติกรรม LLM ที่ซับซ้อน ทีมต้องการการมองเห็นกระบวนการดึงเอกสาร การเรียกใช้เครื่องมือ และห่วงโซ่การตัดสินใจที่แพลตฟอร์มการสังเกตการณ์มาตรฐานไม่ได้ถูกออกแบบมาเพื่อจัดการ ปัญหาจะรุนแรงขึ้นเป็นพิเศษเมื่อระบบ AI แสดงพฤติกรรมที่ไม่คาดคิด เช่น การเปลี่ยนภาษาแบบสุ่มหรือให้คำตอบที่ไม่ถูกต้องโดยไม่มีคำอธิบายที่ชัดเจน
ระบบ multi-agent นำเสนอความท้าทายที่ยิ่งใหญ่กว่า นักพัฒนาคนหนึ่งได้แบ่งปันประสบการณ์ของพวกเขาในการสร้าง workflows ที่ซับซ้อนซึ่งผู้ใช้ที่ไม่ใช่ด้านเทคนิคเขียน prompts ที่ยาวกว่า 10 หน้า ความต้องการด้านการสังเกตการณ์ของพวกเขารวมถึงการวัดความซับซ้อนของงาน เมตริกความสำเร็จ ความเร็วของ agent การติดตามข้อผิดพลาด และต้นทุนการใช้ token ความซับซ้อนของระบบเหล่านี้ทำให้การตรวจสอบอย่างครอบคลุมเป็นสิ่งจำเป็นมากกว่าเป็นตัวเลือก
หมายเหตุ: การสังเกตการณ์ LLM หมายถึงความสามารถในการตรวจสอบและเข้าใจว่าโมเดลภาษาขนาดใหญ่ทำงานอย่างไรในการใช้งานจริง รวมถึงข้อมูลนำเข้า ผลลัพธ์ และกระบวนการตัดสินใจของพวกมัน
ข้อกำหนดการติดตามและสังเกตการณ์ของ LLM
- การติดตามการดึงเอกสารสำหรับคำสั่ง RAG
- การตรวจสอบการเรียกใช้เครื่องมือและเส้นทางการดำเนินงาน
- การติดตามข้อมูลเข้าและออกในแต่ละขั้นตอนการประมวลผล
- การมองเห็นกระบวนการตัดสินใจ
- การประเมินความซับซ้อนของงาน
- การวัดตัวชี้วัดความสำเร็จ
- การตรวจสอบประสิทธิภาพ (ความเร็ว, การหมดเวลา)
- การติดตามต้นทุน (จำนวน token ที่ใช้)
- การตรวจจับและจำแนกข้อผิดพลาด
- การประสานงานเวิร์กโฟลว์แบบหลายเอเจนต์
การแบ่งแยกมาตรฐานสร้างปัญหาจริง
ความขัดแย้งระหว่างมาตรฐาน OpenTelemetry และ OpenInference เป็นมากกว่าเชิงทฤษฎี OpenTelemetry เสนอการสนับสนุนภาษาที่กว้างขวางและการยอมรับในอุตสาหกรรม แต่ขาดประเภท span เฉพาะ AI ซึ่งจำกัดการมองเห็นการดำเนินงาน LLM OpenInference ให้ semantics เฉพาะ AI ที่หลากหลายพร้อมประเภท span สำหรับการเรียก LLM การดำเนินการเครื่องมือ และ workflows ของ agent แต่มีการสนับสนุนภาษาที่จำกัดและการรวมระบบนิเวศที่อ่อนแอกว่า
การแบ่งแยกนี้ส่งผลกระทบโดยเฉพาะต่อทีมที่ใช้ภาษาที่ไม่มีการสนับสนุน OpenInference โดยตรง นักพัฒนา Ruby ตัวอย่างเช่น เผชิญกับการเลือกระหว่างการสร้าง SDK แบบกำหนดเอง การสูญเสียข้อมูลเชิงลึกเฉพาะ AI หรือการเปลี่ยน technology stacks ทั้งหมด การอ้างความเข้ากันได้ระหว่างมาตรฐานมักจะพิสูจน์ได้ว่าตื้นเขินในทางปฏิบัติ โดยเครื่องมือแสดงข้อมูล OpenTelemetry เป็น spans ที่ไม่รู้จักเมื่อพวกมันไม่รู้จัก semantics เฉพาะ AI
หมายเหตุ: ประเภท Span เป็นหมวดหมู่ที่ช่วยจำแนกประเภทการดำเนินงานต่างๆ ใน distributed tracing เช่น การเรียกฐานข้อมูล คำขอ HTTP หรือในกรณีนี้ การโต้ตอบ LLM
การเปรียบเทียบ OpenTelemetry กับ OpenInference
| คุณสมบัติ | OpenTelemetry | OpenInference |
|---|---|---|
| การรองรับภาษา | ครอบคลุมทั่วถึง (ภาษาหลักทั้งหมด) | จำกัด (ไม่มี Ruby SDK) |
| การยอมรับในอุตสาหกรรม | ได้รับการยอมรับอย่างแพร่หลาย เป็นมาตรฐานอุตสาหกรรม | ใหม่กว่า การยอมรับกำลังเติบโต |
| คุณสมบัติเฉพาะ AI | มีเฉพาะ span types พื้นฐาน | มี AI span types ที่หลากหลาย (LLM, tool, chain, embedding, agent) |
| การผสานรวม Ecosystem | ยอดเยี่ยม | การอ้างสิทธิ์ความเข้ากันได้ที่จำกัด |
| ความพร้อมสำหรับ Production | เป็นผู้ใหญ่และมีเสถียรภาพ | กำลังพัฒนา |
โซลูชันชุมชนและการแก้ไขปัญหาชั่วคราว
ชุมชนนักพัฒนาได้ตอบสนองด้วยแนวทางต่างๆ เพื่อเชื่อมช่องว่างนี้ ทีมบางทีมกำลังสร้างโซลูชันแบบผสมที่รักษา OpenTelemetry เป็นแกนหลักในขณะที่เพิ่มคุณลักษณะเฉพาะ AI ทีมอื่นๆ เลือกเครื่องมือเฉพาะทางแม้จะมีความท้าทายด้านการรวม โดยยอมรับการสังเกตการณ์ที่กระจัดกระจายเพื่อแลกกับข้อมูลเชิงลึก AI ที่ดีกว่า
สิ่งที่เป็นอยู่คือ ความจริงที่ว่าการสื่อสารกับ LLMs ส่งเสริมการขาดความแม่นยำและการแก้ไขการพิมพ์ผิดในเวลาเดียวกัน มันเปิดเผยเราต่อการเขียนที่มีโครงสร้างของพวกมันเอง หมายความว่าการเขียนแบบสบายๆ ปกติจะเอนเอียงไปสู่การผสมผสานแบบนี้พอดี
แนวทางที่เน้นฐานข้อมูลกำลังได้รับความนิยมเป็นทางเลือก นักพัฒนาบางคนแนะนำให้ใช้ฐานข้อมูลเชิงสัมพันธ์เช่น ClickHouse สำหรับข้อมูลการสังเกตการณ์ LLM ที่หลากหลาย โดยข้ามความขัดแย้งของมาตรฐานไปเลย แนวทางนี้เสนอความยืดหยุ่นแต่ต้องการงานพัฒนาแบบกำหนดเองมากขึ้น
หมายเหตุ: ClickHouse เป็นระบบฐานข้อมูลประสิทธิภาพสูงที่ออกแบบมาสำหรับ analytical workloads และการประมวลผลข้อมูลแบบเรียลไทม์
เส้นทางข้างหน้า
ผู้สังเกตการณ์อุตสาหกรรมแนะนำให้ติดตามความคืบหน้าของ OpenTelemetry GenAI working group ซึ่งกำลังพัฒนาข้อตกลงเฉพาะ AI ภายในมาตรฐานที่จัดตั้งขึ้นอย่างแข็งขัน แนวทางนี้อาจให้ semantics ที่หลากหลายที่จำเป็นสำหรับการสังเกตการณ์ LLM ในที่สุด ในขณะที่รักษาความเข้ากันได้ของระบบนิเวศ
สำหรับทีมที่กำลังเผชิญกับการตัดสินใจเหล่านี้ในปัจจุบัน ฉันทามติเอนเอียงไปสู่การรักษาความสอดคล้องกับโครงสร้างพื้นฐานที่มีอยู่ องค์กรที่ใช้ OpenTelemetry อยู่แล้วได้รับคำแนะนำให้ขยายการตั้งค่าปัจจุบันของพวกเขาด้วยคุณลักษณะเฉพาะ AI มากกว่าการนำเสนอมาตรฐานที่แข่งขันกันซึ่งทำให้ภาพการสังเกตการณ์ของพวกเขากระจัดกระจาย
การแก้ไขขั้นสุดท้ายอาจต้องการให้เครื่องมือการสังเกตการณ์ AI จัดตำแหน่งให้ดีขึ้นกับข้อตกลง OpenTelemetry หรือให้ OpenTelemetry เร่งการพัฒนาฟีเจอร์เฉพาะ AI จนกว่าจะถึงตอนนั้น ทีมต้องนำทางการแลกเปลี่ยนระหว่างความหลากหลายเชิงความหมายและการรวมระบบนิเวศตามความต้องการเฉพาะและข้อจำกัดทางเทคนิคของพวกเขา
อ้างอิง: LLM Observability in the Wild - Why OpenTelemetry should be the Standard