เวลาพูดว่า data quality ไม่ดี เรามักนึกถึงค่าในตารางที่ผิด เช่น ราคาเป็นศูนย์ ชื่อหาย หรือวันที่พิมพ์สลับเดือนกับวัน ปัญหาของ AI มีเพิ่มอีกชั้นหนึ่ง: ข้อมูลอาจ “ไม่ผิดตาม schema” แต่ผิดในบริบทที่ระบบกำลังใช้

แถวข้อมูลมีครบทุก column, parser ไม่ error และ model ตอบได้ แต่เอกสารที่ถูกค้นมาเป็นฉบับเก่า หรือ timestamp ขาดช่วงจนคำตอบไม่ตรงกับช่วงเวลาที่ถาม นี่คือเหตุผลที่ data quality สำหรับ AI ต้องถามมากกว่าว่า “ข้อมูล valid ไหม?”

ข้อมูลผิดเล็ก ๆ กลายเป็นคำตอบผิดที่ฟังดูมั่นใจ

ปัญหาที่ต้นทางอาจไม่ทำให้ model error แต่ยังเปลี่ยนความหมายของ context และการตัดสินใจปลายทาง

ความผิดพลาดเล็ก ๆ ที่เปลี่ยนความหมาย

ลองดู record สองชุดนี้:

{
  "policy": "travel-v3",
  "effective_from": "2026-09-01",
  "hotel_limit": 1500,
  "currency": "THB"
}
{
  "policy": "travel-v2",
  "effective_from": "2025-01-01",
  "hotel_limit": 1200,
  "currency": "THB"
}

ถ้า retrieval ไม่ filter effective_from หรือไม่มี metadata ให้จัดลำดับ ฉาก generate อาจหยิบทั้งสองฉบับมาอธิบายรวมกัน คำตอบที่ได้ยังเป็นภาษาไทยที่ดี แต่ผู้ใช้ไม่รู้ว่าตัวเลขใดมีผลอยู่จริง

ปัญหาแบบเดียวกันเกิดจาก:

  • freshness: index ยังไม่เห็นข้อมูลใหม่
  • completeness: passage ขาดย่อหน้าที่มีข้อยกเว้น
  • null context: ระบบส่ง context ว่างแต่ไม่ได้เปลี่ยนสถานะเป็น “ไม่พบข้อมูล”
  • timestamp gaps: event หายจากช่วงเวลาที่ใช้วิเคราะห์
  • schema drift: field เปลี่ยนชื่อหรือชนิดโดย downstream ไม่รู้
  • incorrect context: ข้อมูลเกี่ยวข้องกับคำถามแต่เป็นคนละ entity หรือคนละสิทธิ์

Plausible output อันตรายกว่าคำตอบที่ล้มเหลว

ถ้า parser ล้มเหลวและระบบแสดง error คนอาจหยุดตรวจสอบ แต่ถ้าข้อมูลผิดไหลผ่านไปถึง model คำตอบอาจดูน่าเชื่อถือจนไม่มีใครสงสัย ความลื่นไหลของภาษาไม่ได้ช่วยยืนยันความถูกต้องของ source

ดังนั้น data-quality gate ไม่ควรตรวจแค่ row count หรือ null rate แบบรวม ๆ ควรตรวจว่า data ที่กำลังใช้ตอบคำถามมีคุณสมบัติครบตามงานด้วย เช่น:

function canUseContext(context: Context): boolean {
  return (
    context.documents.length > 0 &&
    context.documents.every((document) => document.isCurrent) &&
    context.documents.every((document) => document.permission === 'allowed')
  );
}

ถ้า gate ไม่ผ่าน ระบบควรส่งต่อไปทาง fallback ที่บอกเหตุผลได้ ไม่ใช่ปล่อยให้ model เติมช่องว่างเอง

Data contract ช่วยให้ความผิดพลาดอยู่ใกล้ต้นทาง

Data contract ไม่ได้หมายความว่าต้องสร้างเอกสารใหญ่ทุกครั้ง มันคือข้อตกลงที่ชัดว่า field นี้หมายถึงอะไร อัปเดตเมื่อไร ใช้ได้ในช่วงไหน และใครเป็นเจ้าของการเปลี่ยนแปลง

สำหรับระบบ AI contract ที่มีประโยชน์อาจระบุเพิ่มว่า:

  1. record ต้องมี source_id และ effective_at
  2. เอกสารที่หมดอายุห้ามเข้า default retrieval set
  3. การเปลี่ยนชื่อ field ต้องมี compatibility window
  4. ถ้าความสดเกิน threshold ให้ระบบลดความมั่นใจหรือหยุด
  5. ทุกคำตอบที่อ้าง policy ต้องเก็บ source ที่ตามกลับได้

การตรวจเหล่านี้ลดโอกาสที่ปัญหาจะถูกค้นพบตอนคนอ่านคำตอบแล้ว แต่ยังไม่แทนการตรวจ output และการประเมิน end-to-end

วิธีคิดเรื่องคุณภาพที่ใช้งานได้

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

ตัวอย่างชุดเล็กอาจมีคำถามที่ต้องใช้ข้อมูลล่าสุด คำถามที่มี entity ชื่อคล้ายกัน คำถามที่ไม่มีข้อมูล และคำถามที่ผู้ใช้ไม่มีสิทธิ์เห็นข้อมูลนั้น จากนั้นวัด retrieval กับ generation แยกกัน เพราะคำตอบที่ผิดอาจเกิดจากค้นผิดหรือสรุปเกินหลักฐาน

สรุป

data quality สำหรับ AI คือคุณภาพของข้อมูลเมื่ออยู่ในบริบทของการตัดสินใจ ไม่ใช่เพียงการผ่าน schema

สิ่งที่ควรจำมีสามข้อ:

  1. ข้อมูลที่เก่า ไม่ครบ หรืออยู่ผิด context อาจทำให้คำตอบผิดทั้งที่ภาษายังลื่นไหล
  2. data contract ควรบอกความหมาย ความสด สิทธิ์ และเงื่อนไขการใช้งาน
  3. ถ้า context ไม่พอ ระบบควรมีสถานะที่ยอมรับว่าไม่รู้ แทนการให้ model เติมช่องว่าง

References

  • Google for Developers — Production ML systems: Monitoring pipelines: การตรวจ schema, missing values, distribution และ training-serving skew
  • TensorFlow — TensorFlow Data Validation: ตัวอย่างการตรวจ anomaly, schema, skew และ drift ในข้อมูลที่ใช้กับ ML pipeline
  • Great Expectations — Define Expectations: เปลี่ยนสมมติฐานเรื่องข้อมูลให้เป็น assertion ที่ตรวจซ้ำได้
  • NIST — AI Risk Management Framework (2023): ช่วยเชื่อม data quality เข้ากับความเสี่ยงและผลกระทบของระบบ AI