Knowledge Graph กับ Digital Twin: เมื่อกราฟความรู้ทำให้ดิจิทัลทวินเข้าใจโรงงานของคุณจริงๆ

ทำไมโรงงานจึง “มีข้อมูลมหาศาล แต่ตอบคำถามง่ายๆ ไม่ได้”

คำถามที่ดูเหมือนง่ายอย่าง “เครื่องอัดกระแทกเนื้อ (hydraulic press) หมายเลข 7 ที่สาย 2 ใช้ VFD รุ่นไหน ติดตั้งเมื่อไร และเชื่อมกับ HMI ตัวไหน” มักต้องข้ามไปถาม 3 แผนก รอคำตอบ 2 วัน เพราะข้อมูลชิ้นนี้กระจายอยู่ใน Excel ของฝ่ายวิศวกรรม, ไฟล์ PDF แผนภาพ P&ID, ฐานข้อมูล SCADA และใบสั่งซื้อในระบบ ERP — ทุกระบบเก็บ “ข้อเท็จจริง” ไว้คนละที่ แต่ไม่มีระบบใดเก็บ “ความสัมพันธ์” ระหว่างข้อเท็จจริงเหล่านั้นเลย

Digital Twin ยุคแรกแก้ปัญหาการ “เห็น” เครื่องจักรผ่านโมเดลสามมิติและข้อมูลเรียลไทม์ได้แล้ว แต่ความท้าทายระยะถัดไปคือการทำให้ดิจิทัลทวิน เข้าใจบริบท (context) ว่าอุปกรณ์แต่ละตัวเป็นใคร อยู่ที่ไหน ติดต่อกับใคร และมีความหมายอย่างไรต่อกระบวนการผลิต — นี่คือจุดที่ Knowledge Graph (กราฟความรู้) เข้ามาเป็นชั้นความหมายที่ขาดหายไป

Knowledge Graph คืออะไร และต่างจากฐานข้อมูลเดิมอย่างไร

ฐานข้อมูลแบบตาราง (relational) ออกแบบมาเพื่อเก็บ “ข้อเท็จจริง” ที่โครงสร้างคงที่ เช่น รายการเครื่องจักร รายการใบสั่งซื้อ ส่วน Knowledge Graph ออกแบบมาเพื่อเก็บ “ความสัมพันธ์” เป็นชุดของ triple สามส่วน: หัวเรื่อง → ความสัมพันธ์ → วัตถุ เช่น Motor-M-201 → isPartOf → Line-2, Motor-M-201 → hasSensor → VIB-014, VIB-014 → measures → VibrationVelocity

เมื่อทุกข้อเท็จจริงเชื่อมกันเป็นสายโซ่ของความสัมพันธ์ คำถามที่ต้องเดาเองข้ามแผนกกลายเป็น query ที่ตอบได้ในไม่กี่วินาที ทีมงาน Honey Corporation มีประสบการณ์ติดตั้งระบบ IoT ที่ต้องรวมข้อมูลจาก PLC, SCADA และระบบแจ้งเตือนเข้าด้วยกันในโครงการระดับอุตสาหกรรม จึงเข้าใจดีว่าการทำให้ข้อมูลจากหลายแหล่ง “พูดภาษาเดียวกัน” คือความท้าทายที่แท้จริงของทุกโรงงาน ไม่ใช่แค่การติดเซ็นเซอร์เพิ่ม

Ontology: สัญญาณร่วมภาษาของโรงงาน

หัวใจของ Knowledge Graph คือ ontology — คำนิยามชุดคำศัพท์และกติกาที่ทุกฝ่ายตกลงร่วมกันว่าจะเรียกสิ่งของว่าอะไร มีคุณสมบัติอะไรได้บ้าง และเชื่อมกับอะไรได้บ้าง ในบริบทอุตสาหกรรมมีมาตรฐานสำคัญที่ควรรู้จัก:

ประเด็นสำคัญที่มักถูกมองข้าม: AAS ตามมาตรฐาน IEC 63278 มีรูปแบบการแสดงผลหลายแบบ ทั้ง XML, JSON และ RDF (Turtle / JSON-LD) ซึ่ง RDF ไม่ใช่แค่ “อีก format หนึ่ง” แต่ทำให้ AAS กลายเป็นกราฟตัวจริง — โครงสร้าง BOM ที่ซับซ้อนซึ่งเก็บในตารางต้องเขียน JOIN หลายชั้น กลายเป็นการเดินจากโหนดหนึ่งไปอีกโหนดหนึ่งด้วย SPARQL ที่สั้นกว่าและทนต่อการเปลี่ยนแปลงโครงสร้างได้ดีกว่า

เมื่อกราฟความรู้เข้าไปอยู่ในดิจิทัลทวิน: ทำอะไรได้จริง

1. ตอบคำถามข้ามระบบด้วย query เดียว

เมื่อสายการผลิตหยุดและระบบแจ้งเตือนชี้ว่า “อุณหภูมิมอเตอร์สูงผิดปกติ” วิศวกรมักต้องไล่สาย: มอเตอร์ตัวนี้อยู่สายไหน → ใครเป็นผู้ดูแล → ชิ้นส่วนสำรองอยู่คลังไหน → เคยมีประวัติเสียแบบนี้ไหม ถ้าทุกความสัมพันธ์ถูกเก็บในกราฟ คำถามทั้งหมดนี้คือ SPARQL query เดียวที่วิ่งจากโหนด “มอเตอร์ตัวนี้” ออกไปหาทุกสิ่งที่เกี่ยวข้อง รวมถึงอ้างอิงเอกสารคู่มือและใบสั่งซื้อล่าสุดได้ในผลลัพธ์ชุดเดียว

2. เตรียมพร้อมสำหรับ Digital Product Passport

สหภาพยุโรปกำลังผลักดัน Digital Product Passport (DPP) ภายใต้กฎระเบียบ ESPR โดยกำหนดให้ผลิตภัณฑ์บางประเภท เช่น แบตเตอรี่ ต้องมี DPP บังคับใช้ตั้งแต่ 18 กุมภาพันธ์ 2027 สำหรับโรงงานไทยที่ส่งออกไปยุโรป การเริ่มจัดระเบียบข้อมูลผลิตภัณฑ์ด้วยโครงสร้าง AAS + Knowledge Graph ตั้งแต่วันนี้ คือการลงทุนที่จะทำให้การทำ DPP ในอนาคตเป็นการ “เติมข้อมูลลงแม่แบบ” แทนการเริ่มรวบรวมข้อมูลจากศูนย์

3. ทำให้ AI ตอบคำถามโรงงานได้ถูกต้องขึ้น (Grounding)

โมเดลภาษาขนาดใหญ่ (LLM) เข้าใจภาษาคนเก่งขึ้นเรื่อยๆ แต่ไม่รู้จักโรงงานของคุณ แนวทาง GraphRAG ที่นำ Knowledge Graph มาเป็นแหล่งความรู้ที่ “ตอกย้ำ” คำตอบของ AI ช่วยลดการหลอน (hallucination) และทำให้ผู้ใช้กล้าเชื่อและตรวจสอบคำตอบได้ เพราะทุกคำตอบชี้ไปยังโหนดในกราฟที่ตรวจสอบย้อนกลับได้

แนวทางลงมือทำ: จากคำนิยามคำศัพท์สู่กราฟที่ใช้งานจริง

สำหรับทีมที่อยากเริ่มต้น เราแนะนำลำดับ 5 ขั้นที่พิสูจน์แล้วว่าลดควamามเสี่ยงของโครงการกราฟความรู้ได้จริง:

1. เลือก Use Case แคบแต่เจ็บที่สุด — เช่น “ค้นหาอุปกรณ์ + ประวัติซ่อม + ชิ้นส่วนสำรอง” ใน 1 สายการผลิต ไม่ใช่ทั้งโรงงานในครั้งเดียว
2. ทำ Data Inventory — สำรวจว่าข้อมูลสินทรัพย์อยู่ที่ไหนบ้าง: Excel, ERP, SCADA, ใบแจ้งซ่อม, PDF แผนเดินเครื่อง
3. ตั้ง Vocabulary ร่วม — ตัดสินใจว่าจะอิง IEC CDD / ECLASS หรือคำศัพท์ภายใน แล้วบันทึก mapping ให้ชัด เช่น ชื่อฟิลด์ “Maker” ใน ERP เทียบกับ “name of manufacturer” ในพจนานุกรมกลาง
4. เลือก Stack เทคโนโลยี — triple store + SPARQL endpoint สำหรับทีมที่ต้องการมาตรฐานเปิด หรือ property graph + query ภาษา graph หากทีมคุ้นเคยมากกว่า โดยเชื่อมกับข้อมูลเรียลไทม์ผ่าน integration layer
5. วัดผลและขยาย — ตัวชี้วัดที่ดีคือเวลาที่วิศวกรใช้หาข้อมูลก่อน/หลัง, จำนวน query ที่ตอบได้เองโดยไม่ต้องถามข้ามแผนก และความครอบคลุมของกราฟ (จำนวนสินทรัษย์ที่เชื่อมแล้ว)

มุมมองของวิศวกร Honey: Knowledge Graph ไม่ใช่โครงการ “เปลี่ยนฐานข้อมูลเดิมทั้งหมด” แต่เป็นการเพิ่มชั้นความหมายที่ทำให้ข้อมูลเดิมมีชีวิต โรงงานที่เริ่มจากการจัดระเบียบข้อมูลเครื่องจักรแค่ 50 เครื่องให้เชื่อมกันครบ มักค้นพบว่าคุณค่าที่ได้กลับมามากกว่าการลงทุน dashboard ที่สวยแต่ไม่ตอบคำถามข้ามแผนก

Key Takeaways

• ปัญหาที่แท้จริงคือความสัมพันธ์ ไม่ใช่ปริมาณข้อมูล — ฐานข้อมูลเดิมเก็บข้อเท็จจริงแยกกัน กราฟความรู้เก็บการเชื่อมโยงที่ทำให้ตอบคำถามข้ามแผนกได้ใน query เดียว
• เริ่มจากมาตรฐานที่มีอยู่ — IEC 63278 (AAS), IEC CDD / ECLASS, RDF/SPARQL และ ISO 23247 ลดเวลาออกแบบ ontology ลงอย่างมาก และเปิดทางให้เชื่อมกับ partners ในอนาคต
• RDF ของ AAS คือจุดเชื่อมสู่กราฟ — การแสดงผลด้วย RDF (Turtle/JSON-LD) เปลี่ยน AAS จากไฟล์แลกเปลี่ยนเป็นกราฟที่ query ซ้อนความสัมพันธ์ได้ (BOM หลายชั้น, ผู้ดูแล, ประวัติซ่อม)
• Digital Product Passport มีกำหนดบังคับใกล้แล้ว — แบตเตอรี่บางประเภทต้องมี DPP ตั้งแต่ 18 ก.พ. 2027 โรงงานส่งออกยุโรปควรเริ่มจัดระเบียบข้อมูลด้วย AAS ตั้งแต่วันนี้
• GraphRAG ทำให้ AI ตอบคำถามโรงงานได้น่าเชื่อถือขึ้น — กราฟความรู้เป็นฐานยึด (grounding) ที่ลดการหลอนของ AI และตรวจสอบย้อนกลับได้
• เริ่มเล็ก วัดผล แล้วขยาย — 1 สายการผลิต, 50 เครื่องจักร, คำถาม 3 ข้อที่เจ็บที่สุด คือขอบเขตที่เหมาะสมของโครงการแรก