ทำไม AI ตรวจจับรูปภาพถึงพลาด (และควรใช้อะไรแทน)

อัปโหลดรูปภาพไปยัง “เครื่องตรวจจับภาพ AI” ส่วนใหญ่ในวันนี้ แล้วคุณมักจะได้คำตอบที่มั่นใจ เช่น “มนุษย์ 94%” หรือ “AI 88%” ตัวเลขเหล่านี้ดูเหมือนการวัดผล แต่ในทางปฏิบัติมักเป็นการคาดเดาเชิงสถิติที่เปราะบาง การตรวจจับภายหลัง (post-hoc detection) คือการฝึกตัวจัดหมวดหมู่ให้เดาว่าภาพถูกสร้างด้วย AI หลังจากภาพนั้นถูกสร้างแล้ว ปัญหาคือสิ่งที่ระบบพยายามตรวจจับเปลี่ยนอยู่ตลอดเวลา และผู้สร้างภาพมีแรงจูงใจสูงที่จะหลบเลี่ยงเครื่องตรวจจับ

ลองใช้ Apidog วันนี้

เรื่องนี้สำคัญกับนักพัฒนาโดยตรง เพราะหลายทีมเริ่มนำ “ความสมบูรณ์ของเนื้อหา” เข้าไปอยู่ในผลิตภัณฑ์จริง: endpoint อัปโหลดที่ปฏิเสธภาพที่ถูกแก้ไข, ระบบ moderation ที่ติดธงสื่อสังเคราะห์, หรือ workflow ด้าน compliance ที่ต้องการ audit trail ที่อธิบายได้

💡 ถ้าคุณกำลังจะเพิ่มขั้นตอนตรวจจับ AI เข้าไปใน API pipeline ให้ถือว่ามันเป็นสัญญาณหนึ่ง ไม่ใช่คำตัดสินสุดท้าย Apidog ช่วยให้ทีมออกแบบ ดีบัก และทดสอบ API เหล่านี้ก่อนนำไปใช้จริง

สรุป TL;DR

การตรวจจับภาพ AI ภายหลังไม่น่าเชื่อถือพอที่จะเป็นแนวป้องกันเดียว เพราะ:

• แพ้การแข่งขันทางอาวุธระหว่าง detector กับ image generator
• สรุปผลได้แย่กับโมเดลใหม่ที่ไม่เคยอยู่ในชุดฝึก
• สร้าง false positive ที่อาจกล่าวหาผู้ใช้จริงผิดพลาด
• ล้มเหลวได้จากการครอบตัด บีบอัดใหม่ หรือ screenshot
• สัญญาณทางสายตาที่เคยใช้จับผิด เช่น มือผิดรูป หรือข้อความเพี้ยน กำลังหายไปเรื่อย ๆ

แนวทางที่แข็งแรงกว่า คือใช้ provenance-first architecture:

1. ตรวจสอบ C2PA Content Credentials เมื่อมี
2. ตรวจสอบ watermark เช่น SynthID เมื่อรองรับ
3. ใช้ classifier เป็นสัญญาณอ่อนเท่านั้น
4. รวม context ของบัญชีและ workflow
5. ให้มนุษย์ตรวจสอบกรณีที่มีผลกระทบสูง

เหตุใดการตรวจจับภายหลังจึงล้มเหลว

Detector ไม่ได้ไร้ประโยชน์ทั้งหมด มันช่วยจัดลำดับคิว moderation หรือติดธงภาพปลอมที่ชัดเจนได้ แต่ไม่ควรถูกใช้เป็น verdict อัตโนมัติ

1. การแข่งขันทางอาวุธไม่มีเส้นชัย

เครื่องตรวจจับเรียนรู้ “รอยนิ้วมือทางสถิติ” จากภาพที่สร้างโดยโมเดลบางชุด เช่น pattern ความถี่, noise, หรือ distribution ของสี

ปัญหาคือ detector มักเรียนรู้จากอดีต ขณะที่ generator รุ่นใหม่ถูกปรับให้สร้างภาพสมจริงขึ้นและทิ้งร่องรอยน้อยลงเรื่อย ๆ เมื่อ detector ถูก deploy มันอาจตรวจจับโมเดลรุ่นก่อนหน้าได้ดี แต่พลาดโมเดลรุ่นใหม่ที่ยังไม่อยู่ในข้อมูลฝึก

2. ตัวจัดหมวดหมู่สรุปผลกับโมเดลใหม่ได้ไม่ดี

Detector ที่ฝึกกับภาพจาก generator ชุดหนึ่งมักทำงานแย่กับ generator ที่ไม่เคยเห็น เช่น:

• โมเดลที่ฝึกกับ GAN รุ่นเก่าอาจพลาดภาพจาก diffusion model
• โมเดลที่ฝึกกับ checkpoint ปีที่แล้วอาจพลาด checkpoint รุ่นใหม่
• ภาพที่ถูก fine-tune หรือ post-process อาจหลุดจาก pattern ที่ detector เคยเรียนรู้

ดังนั้น accuracy ที่ vendor โฆษณาอาจวัดจากชุดทดสอบที่ควบคุมไว้ดี แต่ไม่สะท้อนภาพที่ผู้ใช้จะอัปโหลดจริงในวันพรุ่งนี้

3. False positive ทำร้ายผู้ใช้จริง

Detector ผิดได้สองแบบ:

• False negative: ภาพ AI หลุดผ่าน
• False positive: ภาพมนุษย์แท้ถูกกล่าวหาว่าเป็น AI

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

สำหรับนักพัฒนา บทเรียนคือชัดเจน: คะแนน detector ไม่ใช่ fact ที่ควรนำไปใช้ปฏิเสธ แบน หรือกล่าวหาผู้ใช้โดยอัตโนมัติ

หากต้องการเข้าใจขีดจำกัดของเครื่องมือเหล่านี้เพิ่มเติม อ่านคู่มือเกี่ยวกับ วิธีตรวจสอบว่ารูปภาพถูกสร้างโดย AI หรือไม่

4. การครอบตัดและการบีบอัดใหม่ทำให้ detector พังได้

เครื่องตรวจจับจำนวนมากพึ่งพาสัญญาณละเอียดระดับพิกเซล แต่สัญญาณเหล่านี้เปราะบางมาก การทำสิ่งธรรมดาต่อไปนี้อาจเปลี่ยนผลลัพธ์ได้:

• Save ใหม่เป็น JPEG
• ครอบตัดขอบภาพ
• Resize
• Screenshot
• เพิ่ม noise เล็กน้อย
• ผ่าน pipeline ของ social platform หรือ CDN

นี่ไม่ใช่ attack แปลก ๆ แต่เป็นสิ่งที่เกิดขึ้นตามปกติเมื่อภาพถูกแชร์บนอินเทอร์เน็ต ภาพที่ detector ต้องรับมือจริงมักไม่ใช่ไฟล์ต้นฉบับสะอาดจาก generator แต่เป็นภาพที่ถูกบีบอัด เปลี่ยนขนาด และอัปโหลดซ้ำหลายครั้ง

5. จุดสังเกตทางสายตากำลังหายไป

ช่วงแรก ๆ เราอาจจับภาพ AI ได้จากมือหกนิ้ว ข้อความเพี้ยน หรือ background ละลาย แต่โมเดลรุ่นใหม่แก้ข้อบกพร่องเหล่านี้เร็วมาก

ดังนั้นทั้งมนุษย์และ classifier ที่อาศัย artifact เหล่านี้กำลังไล่ตามเป้าหมายที่เล็กลงเรื่อย ๆ การออกแบบระบบตรวจสอบโดยหวังว่าโมเดล AI จะมีข้อผิดพลาดเดิมตลอดไปเป็นกลยุทธ์ที่ไม่ยั่งยืน

ต้นทุนจริงเมื่อ detector ผิดพลาด

ในระบบจริง ความไม่แม่นยำไม่ใช่แค่ปัญหา quality แต่เป็น product risk

ตัวอย่าง:

• Marketplace ภาพ stock ปฏิเสธภาพแท้ของ contributor เพราะ detector ให้คะแนนว่าเป็น AI
• Workflow ข่าวหรือประกันภัยรับรองภาพสังเคราะห์ว่าเป็นภาพจริง เพราะ detector พลาด
• แพลตฟอร์มจ้างงานหรือการศึกษา flag portfolio ของผู้สมัครว่าใช้ AI โดยอิงจากคะแนนที่เปลี่ยนได้หลังบีบอัดใหม่

ผลลัพธ์คือ support ticket, appeal, ความเสียหายต่อผู้ใช้ และความเชื่อมั่นผิด ๆ จาก “เครื่องหมายถูกสีเขียว” ที่ระบบของคุณสร้างขึ้นเอง

หลักการที่ควรใช้:

classifier_score != proof

คะแนนจาก detector ควรเป็น evidence ระดับอ่อน ไม่ใช่ decision engine เดี่ยว

สิ่งที่ควรใช้แทน: Provenance-first

แทนที่จะถามว่า:

“ภาพนี้ดูเหมือน AI หรือไม่?”

ให้ถามว่า:

“ภาพนี้มีประวัติที่ลงนามและตรวจสอบได้หรือไม่?”

นี่คือแนวคิดของ provenance: บันทึกข้อมูลต้นทางและการแก้ไขตั้งแต่ตอนสร้างหรือแก้ไขไฟล์ แล้วให้ระบบปลายน้ำตรวจสอบได้ด้วยการเข้ารหัส

C2PA Content Credentials: metadata ต้นกำเนิดที่ลงนาม

Coalition for Content Provenance and Authenticity หรือ C2PA เป็นมาตรฐานเปิดสำหรับแนบข้อมูล provenance ไปกับสื่อ เช่น:

• ใครหรือเครื่องมือใดสร้างไฟล์
• มีการแก้ไขอะไรบ้าง
• ใช้ workflow หรือ software ใด
• manifest ถูกลงนามด้วย cryptographic signature หรือไม่

ผู้ใช้ปลายทางอาจเห็นข้อมูลเหล่านี้ผ่าน Content Credentials

ข้อดีของ C2PA คือคุณไม่ต้องเดาจาก pixel แต่ตรวจสอบ statement ที่ลงนามตั้งแต่ตอนสร้างไฟล์ หากมีการแก้ไขภาพโดยไม่อัปเดต manifest ลายเซ็นจะตรวจสอบไม่ผ่าน

อย่างไรก็ตาม C2PA ไม่ใช่เวทมนตร์:

• เป็นระบบ opt-in
• ต้องให้เครื่องมือสร้างหรือแก้ไขเขียน manifest
• metadata อาจถูกลบโดย social platform หรือ CDN
• แอปจำนวนมากลบ metadata ด้วยเหตุผลด้าน privacy เช่นเดียวกับ EXIF GPS

ดังนั้นการไม่มี C2PA ไม่ได้แปลว่าภาพปลอม แปลว่า “ไม่ทราบ”

SynthID: watermark ตั้งแต่เวลาสร้าง

SynthID ของ Google DeepMind ฝังสัญญาณที่มนุษย์มองไม่เห็น แต่เครื่องตรวจจับได้ ลงในภาพตั้งแต่ตอนสร้าง

จุดแข็งของ watermark คืออยู่ใน pixel ไม่ใช่ metadata จึงทนต่อบางการแก้ไขที่มักลบ metadata เช่น:

• Screenshot
• Crop
• Compression
• Color adjustment

C2PA และ SynthID จึงไม่ใช่คู่แข่ง แต่เป็นชั้นที่เสริมกัน:

• C2PA ให้บริบทและประวัติละเอียด
• SynthID ให้สัญญาณที่ทนทานกว่าเมื่อ metadata หายไป

ข้อจำกัดยังเหมือนเดิม: watermark ใช้ได้เฉพาะกับ generator ที่รองรับเท่านั้น

การลงนามใน pipeline ของคุณเอง

Provenance ไม่ได้จำกัดเฉพาะผู้ผลิตโมเดล AI หากระบบของคุณสร้าง แก้ไข หรือนำเข้าภาพ คุณสามารถออกแบบ pipeline ให้ตรวจสอบได้เอง

ตัวอย่างข้อมูลที่ควรบันทึก:

{
  "asset_id": "img_123",
  "uploaded_by": "user_456",
  "uploaded_at": "2026-05-21T10:00:00Z",
  "source_endpoint": "/v1/uploads/images",
  "account_verification": "verified",
  "content_credentials": {
    "present": true,
    "signature_valid": true,
    "issuer": "example-camera-app"
  },
  "watermark": {
    "provider": "synthid",
    "detected": true,
    "confidence": "high"
  },
  "classifier": {
    "model": "detector-v3",
    "ai_probability": 0.72
  },
  "decision": "needs_review"
}

สิ่งสำคัญคืออย่าปล่อยให้ field ใด field หนึ่งตัดสินทุกอย่าง โดยเฉพาะ classifier.ai_probability

ถ้าคุณใช้ key สำหรับลงนามหรือ verify provenance ให้ดูแลเหมือน production secret อื่น ๆ แนวทางเดียวกับการ เก็บ API Keys ให้พ้นจากโค้ดไคลเอ็นต์และส่วนขยาย ควรถูกใช้กับ signing key ด้วย เพราะ key ที่รั่วทำให้ “verified” กลายเป็น “ดูเหมือน verified”

อุตสาหกรรมกำลังไปทาง provenance

ในเดือนพฤษภาคม 2026 OpenAI ประกาศว่าจะ นำ C2PA และ SynthID มาใช้เพื่อตรวจสอบแหล่งที่มาของเนื้อหา โดยภาพจาก ChatGPT, Codex และ OpenAI API จะมี metadata C2PA พร้อม SynthID watermark และมีเครื่องมือ Verify สำหรับตรวจสอบสัญญาณเหล่านี้

ประเด็นสำคัญคือสถาปัตยกรรม: การตอบสนองต่อปัญหา detection ไม่ใช่แค่สร้าง classifier ที่ “แม่นกว่า” แต่เป็นการรวม metadata ที่ลงนามกับ watermark ที่ทนทาน แล้วใช้การตรวจสอบหลายชั้น

ออกแบบ API สำหรับการตรวจสอบหลายชั้น

ระบบที่ดีควรคืนสถานะมากกว่า true หรือ false

ตัวอย่าง response ที่ปลอดภัยกว่า:

{
  "asset_id": "img_123",
  "status": "unknown",
  "signals": {
    "c2pa": {
      "status": "not_found",
      "reason": "no_manifest"
    },
    "watermark": {
      "status": "not_detected",
      "provider": "synthid"
    },
    "classifier": {
      "status": "completed",
      "ai_probability": 0.68,
      "weight": "low"
    },
    "account_context": {
      "uploader_reputation": "medium",
      "upload_history_consistent": true
    }
  },
  "recommended_action": "manual_review"
}

หลีกเลี่ยง response แบบนี้:

{
  "is_ai": true
}

เพราะมันซ่อนความไม่แน่นอนทั้งหมด และทำให้ downstream service เข้าใจผิดว่าเป็นข้อพิสูจน์

Defense in depth: รวมสัญญาณที่อ่อนแอ แต่ไม่เชื่อสัญญาณเดียว

Pipeline ที่เหมาะสมควรมีหลายชั้น:

1. ตรวจสอบ C2PA

   • ถ้ามี manifest และ signature valid ให้ถือเป็นหลักฐานคุณภาพสูง
   • ถ้าไม่มี ให้คืน unknown ไม่ใช่ fake

2. ตรวจสอบ watermark

   • เช่น SynthID หรือระบบเทียบเคียง
   • ถ้าพบ ให้ใช้เป็นสัญญาณแข็งแรง
   • ถ้าไม่พบ อย่าสรุปว่าภาพไม่ใช่ AI

3. เรียก classifier เป็นสัญญาณอ่อน

   • ใช้จัดลำดับคิว review
   • อย่าใช้เป็นตัวตัดสินอัตโนมัติสำหรับการลงโทษผู้ใช้

4. รวม context

   • อายุบัญชี
   • ประวัติการอัปโหลด
   • metadata อุปกรณ์
   • ความสอดคล้องของเวลาและสถานที่
   • การปรากฏของภาพเดียวกันในแหล่งอื่น

5. ใช้ human review สำหรับการตัดสินใจที่มีผลกระทบสูง

   • การปฏิเสธงาน
   • การระงับบัญชี
   • การกล่าวหาทุจริต
   • การจ่ายเงินหรือไม่จ่ายเงิน

เปรียบเทียบแนวทาง

มิติ	การตรวจจับภายหลัง	Provenance และ watermark
คำถามหลัก	ภาพนี้ดูเหมือน AI หรือไม่?	ภาพนี้มีประวัติที่ลงนามและตรวจสอบได้หรือไม่?
ความน่าเชื่อถือเมื่อเวลาผ่านไป	ลดลงเมื่อ generator ใหม่ออกมา	เสถียรกว่า เพราะอิง signature และข้อมูลต้นทาง
โมเดลใหม่ที่ไม่เคยเห็น	มักพลาด	ไม่ต้องรู้จักโมเดล หาก provenance ถูกเขียนไว้
ต้องมีฝ่ายใดร่วมมือ	ไม่ต้อง ซึ่งเป็นข้อดีหลัก	เครื่องมือสร้าง/แก้ไขต้องเขียน credential หรือ watermark
สิ่งที่ทำให้ล้มเหลว	crop, recompress, screenshot, noise, adversarial edit	metadata ถูกลบ; watermark ถูกโจมตีหรือต้นทางไม่รองรับ
false positive	สูงกว่า และอาจกล่าวหางานมนุษย์ผิด	ต่ำกว่า เพราะ absence ควรแปลว่า unknown
failure mode	มั่นใจแต่ผิด	ไม่สรุปผลเมื่อหลักฐานไม่พอ
บทบาทที่เหมาะสม	สัญญาณอ่อนสำหรับ triage	ชั้นหลักเมื่อมีข้อมูล

นโยบายที่ควรออกแบบในผลิตภัณฑ์

1. ทำให้ unknown เป็นสถานะหลัก

อย่าบังคับทุกภาพให้เป็น real หรือ fake

สถานะที่เหมาะสมกว่า:

verified
conflicting
unknown
needs_review

ภาพจำนวนมากบนอินเทอร์เน็ตจะอยู่ในสถานะ unknown และนั่นควรเป็นผลลัพธ์ปกติ ไม่ใช่ error

2. จับคู่การตอบสนองกับความเสี่ยง

งานความเสี่ยงต่ำอาจใช้ automation ได้ เช่น:

• จัดลำดับคิว moderation
• เพิ่ม friction เล็กน้อย
• ขอข้อมูลเพิ่ม

แต่งานความเสี่ยงสูงควรมี human review เช่น:

• แบนบัญชี
• ปฏิเสธรายได้
• กล่าวหาการโกง
• ลบเนื้อหาสำคัญ

3. อธิบายผลลัพธ์ให้ชัด

ข้อความเหล่านี้ไม่เหมือนกัน:

Content Credentials ได้รับการยืนยัน

กับ

Classifier ประเมินว่ามีโอกาสเป็น AI 70%

UI และ API response ควรสื่อให้ชัดว่าผลลัพธ์มาจากหลักฐานแบบใด

4. เขียน provenance ให้ output ของคุณเอง

ถ้าแพลตฟอร์มของคุณสร้างหรือแก้ไขภาพ ให้แนบ Content Credentials หรือ watermark เมื่อทำได้ การทำแบบนี้ช่วย downstream system ลดการเดาจาก pixel และเพิ่ม auditability ให้ระบบนิเวศทั้งหมด

5. ทำระบบให้ modular

มาตรฐานอย่าง C2PA, SynthID และเครื่องมือตรวจสอบต่าง ๆ จะเปลี่ยนแปลงต่อไป ออกแบบ verification layer ให้เปลี่ยน provider ได้ง่าย เช่น:

/verifications/c2pa
/verifications/watermark
/verifications/classifier
/verifications/context

แล้วรวมผลใน policy engine แยกต่างหาก

บทสรุป

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

แนวทางสำหรับนักพัฒนา:

• เริ่มจาก provenance ก่อน
• ตรวจสอบ C2PA Content Credentials เมื่อมี
• ตรวจสอบ watermark เช่น SynthID เมื่อรองรับ
• ใช้ classifier เป็นสัญญาณอ่อนสำหรับ triage
• คืนสถานะ unknown อย่างตรงไปตรงมาเมื่อหลักฐานไม่พอ
• ใช้ human review สำหรับการตัดสินใจที่กระทบผู้ใช้จริง
• ออกแบบ endpoint และ response schema ให้ versioned, testable และอธิบายได้

💡 Apidog ช่วยให้คุณออกแบบ mock และทดสอบ endpoint สำหรับ verification workflow เหล่านี้ก่อน deploy จริง เพื่อสร้างชั้นความสมบูรณ์ของเนื้อหาบนหลักฐานที่ตรวจสอบได้ ไม่ใช่การเดาที่หวังว่าจะถูกต้อง