AI ออบเซอร์แวนบิลิตี้ (AI Observability)

AI Observability คือแนวทางปฏิบัติในการดำเนินงานเพื่อเฝ้าระวังและแสดงผลข้อมูล (Visualization) ของอินพุต/เอาต์พุต, Latency, ต้นทุน และคุณภาพของระบบ AI ที่กำลังทำงานอยู่ในสภาพแวดล้อมจริงอย่างต่อเนื่อง ซึ่งถือเป็นรากฐานสำคัญในการทำให้ระบบ AI ทำงานได้อย่างปลอดภัยและมีเสถียรภาพ โดยช่วยให้สามารถตรวจพบ [hallucination] ได้ตั้งแต่เนิ่นๆ และรับมือกับ model drift ได้อย่างทันท่วงที

ทำไม Observability ถึงจำเป็นในตอนนี้

การตรวจสอบซอฟต์แวร์แบบดั้งเดิมมุ่งเน้นไปที่ตัวชี้วัดที่ค่อนข้างชัดเจน เช่น บันทึกข้อผิดพลาด (Error logs) หรือเวลาในการตอบสนอง (Response time) อย่างไรก็ตาม ในระบบที่รวม [generative-ai] และ [llm] เข้าไว้ด้วยกัน ผลลัพธ์ที่ได้จากอินพุตเดียวกันอาจแตกต่างกันไปในแต่ละครั้ง และนิยามของ "คำตอบที่ถูกต้อง" ก็มีความคลุมเครือ ซึ่งนี่คือความแตกต่างพื้นฐานจากวิธีการตรวจสอบแบบเดิม

นอกจากนี้ ใน [compound-ai-system] ที่มีส่วนประกอบหลายอย่างเชื่อมโยงกัน เช่น [rag] หรือ [multi-agent-system] การระบุว่าคุณภาพลดลงในขั้นตอนใดนั้นทำได้ยาก Observability จึงทวีความสำคัญขึ้นอย่างรวดเร็วในฐานะวิธีการที่เข้ามาจัดการกับ "ความไม่โปร่งใสที่เป็นลักษณะเฉพาะของระบบ AI" โดยตรง

4 มิติที่ควรเฝ้าระวัง

ขอบเขตที่ AI Observability ครอบคลุมสามารถแบ่งออกเป็น 4 ด้านหลัก ดังนี้:

• คุณภาพของอินพุตและเอาต์พุต: บันทึกคู่ของ Prompt และการตอบกลับ เพื่อตรวจหา hallucination, เนื้อหาที่เป็นอันตราย และการละเมิดนโยบาย
• Latency และ Throughput: วัดความเร็วในการสร้าง [token] และเวลาในการตอบสนอง เพื่อตรวจจับสัญญาณเตือนก่อนที่จะเกิดการละเมิด SLA
• ต้นทุน: ติดตามปริมาณการใช้ token ในแต่ละการเรียกใช้ API เพื่อนำไปใช้คำนวณ [ai-roi] และป้องกันการใช้งบประมาณเกินกำหนด
• การตรวจจับ Drift: ตรวจจับการเปลี่ยนแปลงของการกระจายข้อมูลอินพุตหรือพฤติกรรมของโมเดลอย่างต่อเนื่อง

ตัวชี้วัดเหล่านี้ไม่ได้ทำงานแยกจากกัน แต่มีความเกี่ยวข้องกัน ตัวอย่างเช่น เมื่อ Latency เพิ่มขึ้นอย่างรวดเร็ว การจะแยกแยะว่าสาเหตุมาจาก [context-window] ที่ใหญ่เกินไป หรือมาจากภาระงานของแบ็กเอนด์ จำเป็นต้องมีการวิเคราะห์โดยใช้ตัวชี้วัดหลายตัวประกอบกัน

ความสัมพันธ์กับ MLOps และการนำไปใช้ในการดำเนินงาน

AI Observability ตั้งอยู่บนแนวทางต่อยอดจาก [mlops] แต่เป็นแนวคิดที่เน้นไปที่การใช้งานจริง (Production) มากกว่า ในขณะที่ MLOps จัดการกับไปป์ไลน์ทั้งหมดตั้งแต่การฝึกฝนโมเดลไปจนถึงการ Deploy แต่ Observability จะมุ่งเน้นไปที่การเฝ้าระวังอย่างต่อเนื่องหลังจาก Deploy แล้ว

หากประยุกต์ใช้แนวคิด [shift-left] การสร้างกลไกประเมินคุณภาพตั้งแต่ขั้นตอนการพัฒนาย่อมเป็นสิ่งที่เหมาะสมที่สุด แทนที่จะรอจัดการปัญหาเมื่อเกิดขึ้นในสภาพแวดล้อมจริง การใช้ร่วมกับ [ai-guardrails] จะช่วยยับยั้งการเกิดปัญหาได้ตั้งแต่ต้น

นอกจากนี้ การบูรณาการเข้ากับ [hitl] (Human-in-the-Loop) ยังเป็นการตัดสินใจเชิงออกแบบที่สำคัญ การมีกลไกที่ส่งงานไปยังคิวการตรวจสอบของมนุษย์โดยอัตโนมัติเมื่อ Observability ตรวจพบความผิดปกติ จะช่วยเพิ่มประสิทธิภาพในการทำ [ai-governance] ให้เป็นรูปธรรมมากขึ้น

ข้อควรระวังในการนำไปใช้

สิ่งที่มักถูกมองข้ามในการติดตั้งระบบ Observability คือ การแลกเปลี่ยนกับความเป็นส่วนตัว (Privacy Trade-off) ยิ่งบันทึก Log ของอินพุตและเอาต์พุตละเอียดเท่าใด ความแม่นยำในการตรวจสอบก็จะยิ่งสูงขึ้น แต่การจัดเก็บข้อมูลที่มีข้อมูลส่วนบุคคลหรือข้อมูลที่เป็นความลับโดยไม่มีขีดจำกัดจะกลายเป็นความเสี่ยงด้านการปฏิบัติตามกฎระเบียบ (Compliance) เช่นเดียวกับที่ถูกชี้ให้เห็นในบริบทของ [shadow-ai] ขอบเขตของการเก็บ Log และระยะเวลาในการจัดเก็บจำเป็นต้องถูกกำหนดภายใต้นโยบายที่ชัดเจน

ยิ่งไปกว่านั้น ใน [agentic-ai] ที่มีการปรับปรุงตัวเองอย่างอิสระ เช่น [agentic-flywheel] พื้นที่การทำงานของสิ่งที่ต้องเฝ้าระวังจะขยายตัวอย่างต่อเนื่อง ทำให้ในบางสถานการณ์ การตรวจสอบด้วยกฎแบบคงที่ (Static rule-based) อาจตามไม่ทัน จึงเป็นเรื่องสำคัญที่จะต้องเข้าใจว่า AI Observability ไม่ใช่สิ่งที่ติดตั้งครั้งเดียวแล้วจบ แต่เป็นสิ่งที่ต้องทบทวนและปรับปรุงอย่างต่อเนื่องตามวิวัฒนาการของระบบ