การแก้ไข AI Observability ใน Mastra

OpenTelemetry คือมาตรฐานสำหรับการตรวจสอบ (monitoring) ระบบสมัยใหม่ Trace แบบดั้งเดิมอาจใช้ได้กับซอฟต์แวร์ส่วนใหญ่ แต่กลับใช้ไม่ได้ผลกับแอปพลิเคชัน AI

เมื่อคุณสร้าง AI คุณต้องการคำตอบที่เฉพาะเจาะจง: • โมเดลไหนเป็นตัวสร้างผลลัพธ์ (output)? • คุณใช้ผู้ให้บริการ (provider) รายใด? • คุณใช้ token ไปเท่าไหร่? • โมเดล embedding ตัวไหนที่ประมวลผลเอกสารของคุณ? • ค่าใช้จ่ายในการดำเนินการครั้งนี้คือเท่าไหร่?

คำถามเหล่านี้มีความสำคัญอย่างยิ่งในระบบ Retrieval-Augmented Generation (RAG)

ในขณะที่ผมกำลังมีส่วนร่วม (contributing) ใน Mastra ผมพบช่องว่างในการทำ RAG embedding observability แม้ว่า Mastra จะมีการส่งออก (export) metadata สำหรับงาน AI หลายอย่าง แต่ RAG embedding spans กลับขาด attributes ที่เป็นมาตรฐาน

เครื่องมือ observability มองเห็นการทำงานของ embedding แต่ไม่เข้าใจบริบท พวกมันพลาดรายละเอียดของโมเดล ข้อมูลผู้ให้บริการ และการใช้งาน token

RAG pipeline มีขั้นตอนดังนี้: • Documents (เอกสาร) • Chunking (การแบ่งส่วนข้อมูล) • Embedding Model (โมเดล Embedding) • Vector Database (ฐานข้อมูลเวกเตอร์) • Similarity Search (การค้นหาความคล้ายคลึง) • LLM Generation (การสร้างโดย LLM)

ขั้นตอนการ embedding นั้นสำคัญอย่างยิ่ง หากคุณขาดข้อมูลในส่วนนี้ การแก้ปัญหา (debugging) ประสิทธิภาพจะทำได้ยาก

OpenTelemetry ใช้ semantic conventions เพื่อสร้างภาษาที่เป็นสากล แทนที่ทุกเครื่องมือจะใช้ชื่อที่กำหนดขึ้นเอง ทุกคนจะปฏิบัติตามมาตรฐานเดียวกัน สิ่งนี้ช่วยให้เครื่องมือสามารถอ่าน attributes ต่างๆ ได้ เช่น: • gen_ai.system • gen_ai.request.model • gen_ai.usage.input_tokens

ผมได้ส่ง pull request เพื่อแมป (map) ข้อมูล RAG embedding ของ Mastra ให้เข้ากับมาตรฐาน OpenTelemetry เหล่านี้

งานนี้ประกอบด้วย: • การส่งออก metadata ของโมเดล embedding • การส่งออกข้อมูลผู้ให้บริการ • การแมปตัวชี้วัด (metrics) การใช้งาน token • การปรับ attributes ให้สอดคล้องกับมาตรฐานสากล

สิ่งนี้ช่วยให้ระบบ observability เข้าใจ embeddings ได้โดยไม่ต้องเขียนโค้ดเพิ่มเติม (custom code)

ระบบ AI ในระดับโปรดักชัน (production) ต้องการความสามารถในการมองเห็น (visibility) คุณจำเป็นต้องรู้ว่าโมเดลไหนทำให้เกิดความหน่วง (latency) หรือผู้ให้บริการรายใดมีค่าใช้จ่ายสูงที่สุด Telemetry ที่เป็นมาตรฐานจะให้คำตอบเหล่านี้โดยอัตโนมัติ

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

หากคุณสร้างโครงสร้างพื้นฐาน AI อย่าละเลยเรื่อง observability ระบบ AI ที่ดีที่สุดคือระบบที่สามารถสังเกตการณ์ได้ (observable)

Source: https://dev.to/akash_santra_3c96613546c6/fixing-ai-observability-how-i-added-genai-semantic-support-for-rag-embedding-spans-in-mastra-4db9

Optional learning community: https://t.me/GyaanSetuAi