AI Observability: เก็บ Log และตรวจคุณภาพ AI ในระบบจริง
ระบบ AI ที่เปิดใช้แล้วต้องมองเห็นได้ ควรเก็บ Log อะไร วัดคุณภาพยังไง และระวังข้อมูลส่วนบุคคลใน Log อย่างไร พร้อมเครื่องมืออย่าง OpenTelemetry และ Langfuse
Chatbot ตอบคำถามสวัสดิการพนักงานเปิดใช้มาได้สองเดือน ทุกอย่างดูเรียบร้อยจนกระทั่งพนักงานคนหนึ่งส่งภาพหน้าจอมาในกลุ่มไลน์ บอกว่า AI ตอบเรื่องวันลาผิดจากระเบียบบริษัท ทีมที่ดูแลระบบอยากรู้ว่าเกิดขึ้นบ่อยแค่ไหน เริ่มผิดตั้งแต่เมื่อไร และเกิดจากเอกสารอ้างอิงหรือจากตัวโมเดล แต่กลับไม่มีข้อมูลอะไรให้ย้อนดูเลย เพราะไม่ได้เก็บ Log ไว้ตั้งแต่ต้น นี่คือเหตุผลที่ระบบ AI ที่ใช้งานจริงต้องมี Observability ไม่ต่างจากระบบซอฟต์แวร์สำคัญอื่นๆ
AI Observability คืออะไร
AI Observability คือความสามารถในการมองเห็นว่าระบบ AI กำลังทำอะไร ได้รับข้อมูลอะไร ตอบอะไรออกไป ใช้ทรัพยากรเท่าไร และคุณภาพดีแค่ไหน เพื่อให้ตรวจพบปัญหาได้เร็วและแก้ได้ตรงจุด ระบบซอฟต์แวร์ทั่วไปมักผิดพลาดแบบชัดเจน เช่น หน้าเว็บล่ม แต่ AI มักผิดพลาดแบบเงียบ คือยังตอบได้ตามปกติ เพียงแต่คำตอบผิด ซึ่งจะไม่มีใครรู้ถ้าไม่ได้ตั้งใจวัด
ในกรอบ NIST AI RMF 1.0 งานนี้อยู่ในฟังก์ชัน Measure ที่ใช้เครื่องมือเชิงปริมาณและคุณภาพติดตามความเสี่ยง และฟังก์ชัน Manage ที่รวมถึงการวางแผนรับมือและสื่อสารเมื่อเกิดเหตุ
ควรเก็บ Log อะไรบ้าง
ข้อมูลพื้นฐานทุกครั้งที่เรียกโมเดล
- เวลา ผู้ใช้หรือรหัสเซสชัน และฟีเจอร์ที่เรียกใช้
- ชื่อโมเดลและเวอร์ชันของ Prompt ที่ใช้
- จำนวน Token ขาเข้าและขาออก เวลาที่ใช้ตอบ และข้อผิดพลาด
ข้อมูลสำหรับวิเคราะห์คุณภาพ
- คำถามและคำตอบ (เก็บอย่างระวัง ดูหัวข้อข้อควรระวัง)
- เอกสารที่ระบบ RAG ดึงมาอ้างอิง
- เครื่องมือที่ Agent เรียกใช้และผลลัพธ์แต่ละขั้น
- Feedback จากผู้ใช้ เช่น กดถูกใจหรือไม่ถูกใจ
เพื่อไม่ต้องคิดรูปแบบเอง OpenTelemetry ซึ่งเป็นมาตรฐานเปิดด้าน Observability มี Semantic Conventions สำหรับ Generative AI ที่กำหนดวิธีบันทึกข้อมูลอย่างพารามิเตอร์ของโมเดล ข้อมูลการตอบกลับ และจำนวน Token ให้เป็นรูปแบบเดียวกัน และตามบล็อกของ OpenTelemetry การบันทึกเนื้อหาคำถามและคำตอบเป็นแบบต้องเปิดใช้เอง (Opt-in)
ตรวจคุณภาพในระบบจริงยังไง
1. สุ่มตรวจโดยคน
ให้ผู้เชี่ยวชาญเรื่องนั้นสุ่มอ่านบทสนทนาทุกสัปดาห์ และให้คะแนนตามเกณฑ์ที่ตกลงกัน เช่น ถูกต้อง ครบถ้วน น้ำเสียงเหมาะสม
2. ชุดทดสอบถาวร (Regression Set)
เก็บคำถามสำคัญพร้อมคำตอบที่ถูกไว้เป็นชุด แล้วรันซ้ำทุกครั้งที่เปลี่ยนโมเดล Prompt หรือเอกสาร เพื่อดูว่าอะไรแย่ลง
3. ใช้ AI ช่วยให้คะแนน
เทคนิค LLM-as-a-judge คือให้โมเดลอีกตัวประเมินคำตอบตามเกณฑ์ ช่วยให้ตรวจได้ปริมาณมากขึ้น แต่ควรเทียบกับคะแนนจากคนเป็นระยะ
4. ตั้งตัวชี้วัดและการแจ้งเตือน
เช่น อัตราการกดไม่ถูกใจ อัตราที่ส่งต่อให้พนักงาน เวลาตอบเฉลี่ย และค่าใช้จ่ายต่อวัน ถ้าตัวเลขเปลี่ยนผิดปกติให้แจ้งเตือนทันที
เครื่องมือที่ใช้ได้
นอกจากการต่อ OpenTelemetry เข้ากับระบบ Monitoring ที่มีอยู่ ยังมีเครื่องมือเฉพาะทาง เช่น Langfuse ซึ่งเอกสารของ Langfuse ระบุว่าเป็นแพลตฟอร์มโอเพนซอร์สที่ติดตั้งเองได้ มีทั้ง Tracing การจัดการเวอร์ชัน Prompt การประเมินผลแบบ LLM-as-a-judge และแดชบอร์ดคุณภาพ ค่าใช้จ่าย และความเร็ว
AI ที่ไม่มี Log ก็เหมือนพนักงานที่ทำงานโดยไม่มีใครเคยตรวจงาน คุณจะรู้ว่าผิดก็ต่อเมื่อลูกค้าบอก
ข้อควรระวัง
- Log คือข้อมูลอ่อนไหว: คำถามของผู้ใช้อาจมีข้อมูลส่วนบุคคล ควรปิดบังข้อมูล (Masking) ก่อนบันทึก จำกัดสิทธิ์คนเข้าถึง และกำหนดระยะเวลาเก็บ อ่านเพิ่มที่ PDPA กับการใช้ AI
- เก็บมากไม่ได้แปลว่าดี: Log ที่ไม่มีใครอ่านคือต้นทุนเปล่า ตั้งคนรับผิดชอบดูทุกสัปดาห์
- คะแนนจาก AI ไม่ใช่ความจริงทั้งหมด: ใช้เป็นสัญญาณ แต่การตัดสินใจสำคัญต้องมีคนตรวจ
เริ่มต้นยังไง
- เลือกระบบ AI ที่ใช้งานจริงอยู่ 1 ระบบ
- เริ่มเก็บข้อมูลพื้นฐาน: โมเดล เวอร์ชัน Prompt Token เวลา และข้อผิดพลาด
- เพิ่มปุ่ม Feedback ให้ผู้ใช้ และตั้งกติกาปิดบังข้อมูลส่วนบุคคลใน Log
- สร้างชุดทดสอบ 20 ถึง 50 คำถามที่สำคัญที่สุด
- นัดทีมดูแดชบอร์ดและสุ่มอ่านบทสนทนาทุกสัปดาห์
ถ้าคุณยังไม่ได้ประเมินความเสี่ยงก่อนเปิดระบบ เริ่มได้ที่ ประเมินความเสี่ยงก่อนนำ AI มาใช้ และถ้าอยากต่อยอดสายงานด้าน AI และ Data ดูตำแหน่งงานได้ที่ Plants.work Jobs