ยุคของ Rule-based AI: เมื่อมนุษย์สอนเครื่องจักรให้คิดด้วยกฎ

Rule-based AI คืออะไร

Rule-based AI คือระบบปัญญาประดิษฐ์ที่ใช้ความรู้ซึ่งมนุษย์เขียนไว้ในรูปของกฎ ข้อเท็จจริง และความสัมพันธ์ เมื่อได้รับข้อมูลใหม่ ระบบจะเทียบข้อมูลนั้นกับเงื่อนไข แล้วอนุมานข้อสรุปหรือเลือกการกระทำตามกฎที่เข้าเงื่อนไข

หากเปรียบระบบนี้กับห้องทำงาน ฐานความรู้คือชั้นหนังสือที่เก็บสิ่งซึ่งผู้เชี่ยวชาญรู้ ข้อมูลของกรณีปัจจุบันคือเอกสารบนโต๊ะ ส่วนกลไกอนุมานคือผู้ช่วยที่เปิดหนังสือ เทียบเงื่อนไข และเดินตามเหตุผลทีละขั้น กฎพื้นฐานมักอ่านได้ในรูป IF–THEN หรือ “ถ้า–แล้ว” เช่น

แน่นอนว่าโปรแกรมทั่วไปก็มีคำสั่ง “ถ้า–แล้ว” จุดที่ทำให้ Rule-based AI มีความหมายมากกว่านั้นในทางประวัติศาสตร์ คือการแยกความรู้ของสาขาหนึ่งออกมาเป็นฐานความรู้ แล้วปล่อยให้กลไกอนุมานเชื่อมกฎหลายข้อเพื่อวินิจฉัย วางแผน อธิบายเหตุผล หรือค้นหาข้อสรุป

คำว่า Expert System จึงเกี่ยวข้องอย่างใกล้ชิด แต่ไม่ใช่คำเดียวกันทุกกรณี Rule-based AI บอกว่าเราจะแทนความรู้และให้เหตุผลอย่างไร ส่วน Expert System บอกเป้าหมายของระบบว่า ต้องการทำงานบางอย่างได้ใกล้เคียงผู้เชี่ยวชาญในสาขาเฉพาะ

ระบบผู้เชี่ยวชาญจำนวนมากในยุคแรกใช้กฎเป็นแกนหลัก จนสองคำนี้มักปรากฏคู่กัน แต่ก่อนที่แนวคิดนี้จะกลายเป็นกระแสใหญ่ วงการ AI ต้องยอมรับความจริงข้อหนึ่งเสียก่อนว่า ตรรกะที่ดูฉลาดในห้องทดลองอาจยังไม่รู้มากพอสำหรับโลกจริง

เมื่อความฝันเรื่อง AI อเนกประสงค์สะดุดกับโลกจริง

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

ความจริงในห้องทดลองค่อย ๆ บอกอีกแบบหนึ่ง วิธีแก้ปัญหาทั่วไปทำงานได้ดีกับปริศนา เกม หรือโจทย์ที่สะอาดและมีขอบเขต แต่เมื่อเจอวิชาเคมี การแพทย์ หรือการประกอบคอมพิวเตอร์ รายละเอียดเฉพาะสาขากลับเป็นตัวตัดสินคำตอบ

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

บทเรียนของยุคนั้นคือ ความสามารถในการให้เหตุผลมีค่าเพียงครึ่งเดียว อีกครึ่งหนึ่งคือความรู้ที่ถูกต้องเกี่ยวกับบริบทของงาน

แนวคิดนี้นำไปสู่ Knowledge Engineering หรือวิศวกรรมความรู้ งานของนักพัฒนาไม่ใช่แค่เขียนโปรแกรม เขาต้องนั่งคุยกับผู้เชี่ยวชาญ แกะหลักตัดสินใจที่ซ่อนอยู่ในประสบการณ์ แล้วจัดความรู้นั้นให้อยู่ในรูปแบบที่คอมพิวเตอร์นำไปใช้ได้

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

เมื่อความรู้ของผู้เชี่ยวชาญถูกแยกเป็นสามส่วน

แม้ระบบผู้เชี่ยวชาญแต่ละตัวจะมีรายละเอียดต่างกัน แต่โครงสร้างพื้นฐานมักประกอบด้วยสามส่วนที่ทำงานร่วมกัน

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

โครงสร้างนี้ดูเป็นระเบียบและตรวจสอบได้ แต่การ “มองเห็นกฎ” ไม่ได้แปลว่าเรา “เข้าใจระบบทั้งหมด” เสมอไป เมื่อกฎนับพันข้ออ้างถึงกันไปมา การอ่านเหตุผลของกรณีหนึ่งอาจง่าย ขณะที่การคาดการณ์ว่าการแก้กฎเพียงข้อเดียวจะกระทบกรณีอื่นอย่างไรยังเป็นงานยาก

ก่อนจะไปถึงปัญหานั้น เราต้องเห็นระบบขณะทำงานเสียก่อน เพราะความรู้ที่วางนิ่งอยู่ในฐานข้อมูลยังไม่ใช่เหตุผล จนกว่าจะมีกลไกหยิบกฎมาเรียงต่อกัน

เครื่องจักรเดินตามกฎไปหาคำตอบอย่างไร

กลไกอนุมานต้องเลือกว่าจะเริ่มจากข้อมูลที่มีอยู่ หรือเริ่มจากคำตอบที่ต้องการพิสูจน์ สองวิธีที่พบได้บ่อยคือ Forward Chaining และ Backward Chaining

Forward Chaining: เดินจากข้อเท็จจริงไปหาข้อสรุป

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

วิธีนี้เหมาะกับงานที่ข้อมูลไหลเข้ามาเรื่อย ๆ และระบบต้องตรวจว่าข้อมูลเหล่านั้นกระตุ้นกฎใดบ้าง เช่น การเฝ้าระวังสถานะอุปกรณ์หรือการตรวจนโยบายธุรกิจ

Backward Chaining: เริ่มจากสมมติฐานแล้วค้นหาหลักฐาน

ระบบเริ่มจากเป้าหมาย เช่น “ผู้ป่วยอาจติดเชื้อชนิดใด” แล้วมองย้อนกลับว่าต้องพิสูจน์เงื่อนไขอะไรจึงจะสนับสนุนคำตอบนั้น หากยังขาดข้อมูล ระบบอาจถามผู้ใช้หรือค้นผลตรวจเพิ่มเติม

วิธีนี้ช่วยหลีกเลี่ยงการตรวจทุกกฎโดยไม่จำเป็น เพราะระบบมุ่งไปยังข้อมูลที่เกี่ยวข้องกับสมมติฐาน แต่หากมีสมมติฐานมากหรือกฎเชื่อมโยงซับซ้อน พื้นที่ค้นหาก็ยังขยายใหญ่ได้

ถ้าหลายกฎพร้อมทำงาน ระบบจะเลือกข้อใด

นี่คือปัญหา Conflict Resolution หรือการตัดสินเมื่อมีกฎหลายข้อเข้าเงื่อนไขพร้อมกัน กลไกอาจพิจารณาลำดับความสำคัญ ความเฉพาะเจาะจง ความใหม่ของข้อมูล หรือลำดับที่ผู้ออกแบบกำหนด

รายละเอียดนี้สำคัญมาก เพราะชุดกฎเดียวกันอาจให้พฤติกรรมต่างกันได้ หากวิธีเลือกกฎต่างกัน ระบบจึงต้องบันทึกไม่เพียงว่า “มีกฎอะไร” แต่รวมถึง “กฎถูกเรียกใช้เมื่อไรและตามลำดับใด”

กลไกเหล่านี้อาจฟังเหมือนแนวคิดที่ออกแบบบนกระดาษ คำถามสำคัญจึงอยู่ที่ว่า เมื่อเผชิญปัญหาจริงซึ่งผู้เชี่ยวชาญต้องใช้เวลาหลายปีเรียนรู้ กฎจะพาเครื่องจักรไปได้ไกลเพียงใด คำตอบแรกเริ่มชัดขึ้นในห้องปฏิบัติการเคมีของ Stanford

DENDRAL: เมื่อความรู้เฉพาะด้านชนะความฉลาดแบบกว้าง

กลางทศวรรษ 1960 ทีมนักวิจัยที่ Stanford เริ่มพัฒนา DENDRAL เพื่อช่วยวิเคราะห์โครงสร้างโมเลกุลของสารอินทรีย์จากข้อมูลทางเคมี ระบบสร้างโครงสร้างที่เป็นไปได้ แล้วใช้ข้อจำกัดและความรู้เชิงประสบการณ์ของนักเคมีช่วยตัดตัวเลือกที่ไม่สมเหตุผลออก

DENDRAL ไม่ได้พยายามเป็นนักวิทยาศาสตร์ที่รู้ทุกเรื่อง มันทำงานกับปัญหาที่กำหนดขอบเขตไว้ชัด และได้รับความรู้จากผู้เชี่ยวชาญในสาขาโดยตรง

ความสำเร็จของโครงการจึงช่วยเปลี่ยนจุดสนใจของวงการจาก “สร้างกลไกแก้ปัญหาทั่วไป” ไปสู่ “ใส่ความรู้คุณภาพสูงลงในงานเฉพาะด้าน” [University of Michigan Deep Blue]

อีกแนวคิดที่ตามมาคือการแยกความรู้ของสาขาออกจากกระบวนการอนุมาน เมื่อส่วนควบคุมไม่ผูกติดกับเนื้อหา นักพัฒนาก็สามารถนำโครงระบบไปใช้กับฐานความรู้อื่นได้ แนวคิดของ Expert System Shell หรือโครงระบบผู้เชี่ยวชาญสำเร็จรูปจึงเริ่มมีน้ำหนักมากขึ้น

DENDRAL แสดงให้เห็นว่าความรู้เฉพาะด้านช่วยให้เครื่องจักรคัดตัวเลือกจำนวนมากได้ แต่โลกการแพทย์ยากกว่าอีกขั้น เพราะหลักฐานมักไม่ครบ คำตอบไม่แน่นอน และผู้ใช้จำเป็นต้องรู้ว่าเหตุใดระบบจึงเสนอคำแนะนำนั้น

MYCIN: แพทย์ถามกลับได้ว่า “ทำไม”

ช่วงต้นทศวรรษ 1970 Edward Shortliffe และทีมที่ Stanford พัฒนา MYCIN เพื่อให้คำแนะนำเกี่ยวกับการติดเชื้อแบคทีเรียและการเลือกยาต้านจุลชีพ ระบบใช้กฎจากผู้เชี่ยวชาญร่วมกับข้อมูลที่แพทย์ป้อนระหว่างการปรึกษา

MYCIN น่าสนใจเพราะไม่ได้มีเพียงส่วนให้คำแนะนำ เอกสารของโครงการอธิบายทั้งส่วนให้คำปรึกษา ส่วนอธิบายเหตุผล และเครื่องมือรับกฎใหม่จากผู้เชี่ยวชาญ ผู้ใช้จึงถามได้ว่าทำไมระบบจึงต้องการข้อมูลนั้น หรือเหตุใดจึงเสนอคำตอบนั้น [Rule-Based Expert Systems — Chapter 4]

โลกการแพทย์เต็มไปด้วยความไม่แน่นอน กฎจึงไม่ได้จบด้วยคำตอบจริงหรือเท็จเสมอไป MYCIN ใช้ค่า Certainty Factor เพื่อแทนน้ำหนักความเชื่อที่หลักฐานมีต่อสมมติฐานหนึ่ง

วิธีนี้ช่วยให้ระบบรวมเบาะแสที่ไม่เด็ดขาดได้ แต่ Certainty Factor เป็นแบบจำลองเฉพาะของโครงการ ไม่ควรตีความตรง ๆ ว่าเป็นความน่าจะเป็นทางสถิติ

MYCIN จึงทำให้คำว่า “ระบบผู้เชี่ยวชาญ” มีมิติมากกว่าการตอบถูก ระบบต้องสนทนา ขอข้อมูลเพิ่ม ชั่งน้ำหนักหลักฐาน และเปิดเส้นทางให้ผู้ใช้ถามกลับได้ว่า “ทำไม”

ถึงอย่างนั้น ผลจาก MYCIN มีอิทธิพลต่อการวิจัยอย่างมาก แต่ระบบไม่ได้กลายเป็นเครื่องมือที่แพทย์เรียกใช้เป็นกิจวัตร

บทสรุปของโครงการชี้ถึงต้นทุนคอมพิวเตอร์ ข้อจำกัดของฐานความรู้ และปัญหาที่การปรึกษาแบบแยกต่างหากไม่เข้ากับขั้นตอนทำงานประจำของแพทย์ [Rule-Based Expert Systems — Chapter 36]

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

สิ่งที่ MYCIN ยังไปไม่ถึงคือการกลายเป็นส่วนหนึ่งของงานประจำทุกวัน จุดเปลี่ยนนั้นเกิดขึ้นเมื่อ Expert System เดินออกจากมหาวิทยาลัยและเข้าไปอยู่ในสายการผลิตจริง

XCON: วันที่ Expert System เดินเข้าโรงงาน

หาก DENDRAL แสดงศักยภาพในงานวิทยาศาสตร์ และ MYCIN แสดงการให้คำแนะนำทางการแพทย์ XCON ก็ทำให้ภาคธุรกิจเห็นว่าระบบผู้เชี่ยวชาญสามารถเข้าไปอยู่ในกระบวนการผลิตประจำวันได้

R1/XCON รับรายการสั่งซื้อระบบ VAX-11/780 แล้วตรวจว่าต้องแก้ไขหรือเพิ่มองค์ประกอบใด เพื่อให้ชิ้นส่วนทั้งหมดทำงานร่วมกันได้ พร้อมสร้างรายละเอียดสำหรับการประกอบ

John McDermott รายงานในปี 1982 ว่าระบบถูกใช้งานเป็นประจำในฝ่ายการผลิตของ Digital Equipment Corporation [Artificial Intelligence, 1982]

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

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

จากความสำเร็จสามเรื่องสู่ความหวังของโลกธุรกิจ

ช่วงทศวรรษ 1980 องค์กรจำนวนมากเริ่มสนใจ Expert System เพราะข้อเสนอของมันตรงกับปัญหาที่ธุรกิจคุ้นเคยดี ความรู้สำคัญมักกระจุกอยู่กับผู้เชี่ยวชาญเพียงไม่กี่คน หากคนเหล่านั้นลาออก เกษียณ หรือไม่ว่าง กระบวนการทั้งสายอาจช้าลง

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

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

ตลาดจึงเกิดทั้งเครื่องมือสร้าง Expert System บริษัทที่ปรึกษาด้านวิศวกรรมความรู้ และคอมพิวเตอร์เฉพาะทางสำหรับภาษาอย่าง Lisp กระแสเติบโตเร็ว เพราะแทบทุกองค์กรดูเหมือนจะมี “ความรู้ที่ควรเก็บไว้ในกฎ”

แต่ความฝันว่าจะคัดลอกผู้เชี่ยวชาญลงคอมพิวเตอร์ได้ง่าย ๆ กำลังซ่อนต้นทุนก้อนใหญ่เอาไว้

เมื่อความสำเร็จเริ่มสร้างภาระของตัวเอง

ผู้เชี่ยวชาญรู้มากกว่าที่อธิบายออกมาได้

ความรู้จำนวนมากไม่ได้อยู่ในคู่มือ ผู้เชี่ยวชาญอาจตัดสินจากสัญญาณเล็ก ๆ ที่สั่งสมมานานจนไม่ทันสังเกตว่าตนเองใช้มันอยู่ เมื่อวิศวกรความรู้ถามว่า “คุณรู้ได้อย่างไร” คำตอบจึงอาจเป็นเพียง “เห็นแล้วก็รู้”

การดึงความรู้ที่กระจัดกระจายและบางครั้งขัดกันออกมาเป็นกฎจึงกลายเป็น Knowledge Acquisition Bottleneck หรือคอขวดในการรวบรวมความรู้ นักพัฒนาอาจสร้างกลไกอนุมานได้แล้ว แต่ยังต้องใช้เวลามหาศาลเพื่อให้ผู้เชี่ยวชาญอธิบายสิ่งที่ตนทำโดยแทบไม่รู้ตัว ยิ่งสาขาเปลี่ยนเร็ว กฎที่เพิ่งเขียนเสร็จก็ยิ่งมีโอกาสล้าสมัยเร็วตามไปด้วย

ระบบเก่งเฉพาะโลกที่กฎครอบคลุม

Rule-based AI ตอบได้ดีเมื่อกรณีใหม่อยู่ในขอบเขตเดิม แต่ไม่มีสามัญสำนึกมาช่วยเติมช่องว่าง หากนักพัฒนาไม่เคยสร้างกฎรองรับเหตุการณ์หนึ่ง ระบบอาจหยุดโดยไม่พบข้อสรุป หรือใช้กฎที่ดูตรงเงื่อนไขแต่ผิดบริบท

John McCarthy อธิบายข้อจำกัดของ MYCIN ไว้อย่างเห็นภาพ ฐานความรู้ของระบบรู้เรื่องแบคทีเรีย อาการ ผลตรวจ และยา แต่ไม่ได้มีแบบจำลองโลกกว้างแบบมนุษย์ จึงทำงานได้ดีเมื่อผู้ใช้เข้าใจขอบเขตและไม่ถามสิ่งที่อยู่นอกโลกของมัน [Stanford Formal Reasoning Group]

กฎยิ่งมาก ผลกระทบจากการแก้ยิ่งคาดเดายาก

XCON เริ่มจากกฎประมาณ 700 ข้อ แต่ในปี 1987 ฐานกฎเติบโตเกิน 6,200 ข้อ และประมาณครึ่งหนึ่งมีการเปลี่ยนแปลงในแต่ละปี นักวิจัยรายงานว่าประสิทธิภาพของระบบยังน่าพอใจ ทว่าการแก้ไขเริ่มยากขึ้นเรื่อย ๆ เพราะกฎเชื่อมโยงและพึ่งพากัน [AAAI-87]

ปัญหานี้คล้ายการแก้หนังสือกฎหมายที่ทุกมาตราอ้างถึงมาตราอื่น การเพิ่มข้อยกเว้นหนึ่งข้ออาจแก้กรณีปัจจุบันได้ แต่ไปทำให้กรณีเก่าตัดสินผิด นักพัฒนาจึงต้องมีชุดทดสอบ การควบคุมเวอร์ชัน เจ้าของกฎ และกระบวนการตรวจผลกระทบ ไม่ต่างจากระบบซอฟต์แวร์ขนาดใหญ่

ระบบไม่เรียนรู้จากประสบการณ์โดยอัตโนมัติ

Rule-based AI แบบดั้งเดิมใช้กฎที่มนุษย์กำหนดให้ หากพบข้อผิดพลาด ระบบไม่ย้อนกลับไปแก้ความรู้ของตัวเอง นักพัฒนาและผู้เชี่ยวชาญต้องวิเคราะห์สาเหตุ แล้วเขียนหรือปรับกฎด้วยมือ

จุดนี้กลายเป็นคำถามสำคัญของวงการ: แทนที่จะให้มนุษย์อธิบายทุกกฎ เราจะให้คอมพิวเตอร์ค้นหารูปแบบจากตัวอย่างจำนวนมากได้หรือไม่ ก่อนคำถามนั้นจะกลายเป็นเส้นทางหลักของ AI อุตสาหกรรม Expert System ต้องผ่านช่วงที่ความคาดหวังเริ่มแพงกว่าความสำเร็จเสียก่อน

เมื่อคำสัญญาแพงกว่าคุณค่าที่องค์กรได้รับ

ปลายทศวรรษ 1980 ความคาดหวังที่สูงเริ่มชนกับค่าใช้จ่ายจริง ระบบต้นแบบอาจดูดี แต่การนำไปใช้ทั้งองค์กรต้องจ่ายทั้งค่าฮาร์ดแวร์ ซอฟต์แวร์ ผู้เชี่ยวชาญ วิศวกรความรู้ การเชื่อมต่อข้อมูล และการดูแลกฎต่อเนื่อง

ขณะเดียวกัน คอมพิวเตอร์ใช้งานทั่วไปมีประสิทธิภาพดีขึ้น ความได้เปรียบของคอมพิวเตอร์ Lisp ราคาแพงจึงลดลง

หลายโครงการขยายออกจากขอบเขตที่ควบคุมได้แล้วให้ผลไม่คุ้มกับคำสัญญา เงินลงทุนในตลาด Expert System จึงหดตัว และกลายเป็นองค์ประกอบหนึ่งของ AI Winter ครั้งที่สอง หรือช่วงที่เงินทุนและความสนใจต่อ AI ลดลงอย่างหนัก

ประโยชน์ของ Rule-based AI ยังปรากฏชัดใน XCON และระบบเฉพาะด้านอื่น ปัญหาเกิดขึ้นเมื่อคนขยายข้อสรุปจาก “ระบบนี้เก่งในงานนี้” ไปเป็น “เราสามารถบรรจุความฉลาดของมนุษย์ลงในกฎได้ทุกเรื่อง”

กฎทำให้ระบบแน่นอนในสิ่งที่เราเขียนไว้ แต่ไม่ได้เตรียมคำตอบสำหรับสิ่งที่เราไม่เคยนึกถึง

เมื่อวงการเห็นขอบเขตของกฎชัดขึ้น คำถามจึงเปลี่ยนจาก “เราจะเขียนความรู้ให้ครบได้อย่างไร” เป็น “เราจะให้เครื่องจักรค้นหารูปแบบจากประสบการณ์ได้หรือไม่” ตรงนี้คือสะพานจากยุค Rule-based AI ไปสู่ Machine Learning

จุดเปลี่ยนจากการเขียนกฎสู่การเรียนรู้จากข้อมูล

ความต่างที่จำง่ายที่สุดระหว่าง Rule-based AI กับ Machine Learning อยู่ที่ต้นทางของความรู้ แบบแรกเริ่มจากมนุษย์เขียนกฎให้เครื่อง ส่วนแบบหลังเริ่มจากตัวอย่างข้อมูล แล้วใช้กระบวนการฝึกเพื่อให้เครื่องสร้างโมเดลของรูปแบบขึ้นมา

ไม่มีแนวทางใดชนะทุกสถานการณ์ หากกฎหมายกำหนดอายุขั้นต่ำไว้ชัด การเขียนกฎตรงไปตรงมาย่อมเหมาะกว่าฝึกโมเดลให้เดาว่าใครผ่านเกณฑ์ แต่ถ้าต้องแยกภาพแมวออกจากภาพอื่นท่ามกลางสภาพแสง ฉากหลัง และมุมกล้องนับไม่ถ้วน การเขียนกฎให้ครอบคลุมย่อมแทบเป็นไปไม่ได้

Machine Learning ไม่ได้ลบข้อจำกัดทิ้งทั้งหมด มันแลกปัญหา “เขียนกฎไม่ครบ” กับปัญหาใหม่ เช่น ข้อมูลไม่เป็นตัวแทน โมเดลทำนายผิดเมื่อโลกเปลี่ยน และคำตอบบางชนิดอธิบายได้ยากกว่าเดิม ด้วยเหตุนี้ กฎจึงไม่ได้หายไปเมื่อยุคการเรียนรู้จากข้อมูลมาถึง

กฎไม่ได้ตาย เพียงถอยจากบทพระเอก

แม้กระแส Expert System จะลดความร้อนแรงลง การใช้กฎก็ไม่ได้หายไป ทุกวันนี้องค์กรยังใช้ Rule Engine หรือกลไกประมวลผลกฎกับนโยบายธุรกิจ การกำหนดสิทธิ์ การตรวจความครบถ้วน การคำนวณเงื่อนไข และการเฝ้าระวังเหตุการณ์

ตัวอย่างเช่น Drools ซึ่งเป็นโครงการโอเพนซอร์สด้านระบบอัตโนมัติทางธุรกิจ ยังคงใช้แนวคิดหลักที่คุ้นเคยจากยุคก่อน ได้แก่ กฎ ข้อเท็จจริง หน่วยความจำทำงาน การจับคู่เงื่อนไข และลำดับกฎที่พร้อมทำงาน [Apache KIE / Drools Documentation]

ระบบสมัยใหม่ยังมักผสมกฎกับ Machine Learning ตัวอย่างเช่น โมเดลอาจคำนวณคะแนนความเสี่ยงจากข้อมูลจำนวนมาก แล้วกฎจึงกำหนดว่าคะแนนระดับใดควรอนุมัติ ปฏิเสธ หรือส่งให้มนุษย์ตรวจ

หากมีข้อห้ามที่ต้องปฏิบัติตามทุกครั้ง กฎสามารถเป็นด่านบังคับเงื่อนไขก่อนหรือหลังการทำนาย เพื่อไม่ให้ผลจากโมเดลฝ่าฝืนนโยบาย

รูปแบบผสมช่วยให้แต่ละเทคโนโลยีทำงานในสิ่งที่ถนัด โมเดลค้นหารูปแบบซึ่งยากจะเขียนออกมาเป็นกฎ ส่วนกฎบังคับใช้นโยบายที่ต้องชัดเจน แต่ระบบผสมไม่ได้ปลอดภัยเองโดยอัตโนมัติ ทั้งกฎและโมเดลยังต้องผ่านการทดสอบ เฝ้าระวัง และมีผู้รับผิดชอบเมื่อเกิดผลกระทบ

บทเรียนจากประวัติศาสตร์จึงไม่ใช่ “เลิกใช้กฎ” แต่คืออย่าบังคับให้กฎทำงานเกินขอบเขตของมัน การเลือกเทคโนโลยีควรเริ่มจากธรรมชาติของปัญหา ไม่ใช่จากชื่อที่กำลังเป็นกระแส

เมื่อใดควรเลือกใช้กฎ

ก่อนตัดสินใจสร้างโมเดล ลองตรวจธรรมชาติของปัญหาก่อน งานมีแนวโน้มเหมาะกับ Rule-based System เมื่อพบเงื่อนไขต่อไปนี้หลายข้อ

• นโยบายหรือข้อจำกัดเขียนออกมาได้ชัด และมีคำตอบที่ถูกต้องแน่นอน
• จำนวนกรณีและข้อยกเว้นอยู่ในขนาดที่ทีมดูแลไหว
• ต้องอธิบายย้อนหลังว่าการตัดสินใจเกิดจากกฎใด
• ยังไม่มีข้อมูลฝึกที่เพียงพอ แต่มีผู้เชี่ยวชาญที่อธิบายหลักตัดสินใจได้
• ความผิดพลาดบางชนิดต้องถูกห้ามอย่างเด็ดขาด ไม่ควรปล่อยให้โมเดลคาดเดา

หากกฎเพิ่มขึ้นไม่หยุด ผู้เชี่ยวชาญอธิบายรูปแบบไม่ได้ ข้อมูลมีความผันแปรสูง หรือโจทย์เกี่ยวกับภาพ เสียง และภาษาธรรมชาติ Machine Learning อาจเหมาะกว่า ส่วนงานที่มีทั้งรูปแบบซับซ้อนและข้อบังคับชัด มักเหมาะกับการออกแบบระบบผสม

หลักเกณฑ์เหล่านี้จะชัดขึ้นเมื่อเราลองสวมบทเป็นกลไกอนุมาน และเดินตามกฎด้วยตัวเองทีละขั้น

ทดลองทำ: ไล่เส้นทางการตัดสินใจด้วยตนเอง

สิ่งที่ยุค Rule-based AI ฝากไว้ให้ AI ทุกยุค

แบบฝึกหัดห้องเซิร์ฟเวอร์ใช้กฎเพียงสี่ข้อก็ยังเผยช่องว่างได้ เมื่อย้อนมอง DENDRAL, MYCIN และ XCON ภาพเดียวกันจะขยายใหญ่ขึ้นเป็นบทเรียนที่ยังใช้ได้กับ AI ทุกยุค

1. ความรู้เฉพาะด้านสร้างคุณค่ามากกว่าคำว่า “ฉลาด” แบบกว้าง ๆ

ระบบที่รู้ขอบเขตของตนและแก้ปัญหาหนึ่งได้ดี อาจมีประโยชน์กว่าระบบที่ดูทำได้ทุกอย่างแต่รับประกันอะไรไม่ได้ การออกแบบ AI จึงควรเริ่มจากงาน ผู้ใช้ และเกณฑ์ความสำเร็จที่ชัดเจน

2. คำอธิบายต้องออกแบบตั้งแต่ต้น

MYCIN ไม่ได้อธิบายได้เพราะกฎอ่านง่ายเท่านั้น ทีมวิจัยสร้างระบบอธิบายและเก็บร่องรอยการอนุมานไว้โดยตรง หากองค์กรต้องการตรวจสอบคำตอบ การบันทึกเหตุผลต้องเป็นส่วนหนึ่งของสถาปัตยกรรม ไม่ใช่ข้อความที่แต่งเพิ่มภายหลัง

3. การดูแลหลังเปิดใช้คือส่วนหนึ่งของ AI

XCON แสดงให้เห็นว่าความสำเร็จนำมาซึ่งกฎใหม่ ผลิตภัณฑ์ใหม่ และข้อยกเว้นใหม่เสมอ ระบบที่ไม่มีเจ้าของความรู้ ไม่มีการทดสอบผลกระทบ และไม่มีแผนเลิกใช้กฎเก่า จะเสื่อมสภาพแม้วันแรกจะทำงานดีเพียงใด

4. ความโปร่งใสไม่เท่ากับความถูกต้อง

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

5. AI ที่ดีอาจใช้หลายแนวทางร่วมกัน

บทเรียนจาก Rule-based AI ไม่ได้บอกให้เลือกข้างระหว่างกฎกับการเรียนรู้จากข้อมูล มันเตือนให้เราเลือกเครื่องมือให้ตรงกับธรรมชาติของความรู้ สิ่งใดเป็นข้อกำหนดชัดเจนให้เขียนเป็นกฎ สิ่งใดเป็นรูปแบบซับซ้อนให้โมเดลเรียนรู้ และจุดใดมีผลกระทบสูงให้มนุษย์เป็นผู้ตัดสิน

ก่อนสรุปเรื่องราวทั้งหมด ยังมีคำถามบางข้อที่มักเกิดขึ้นเมื่อเราเอาแนวคิดยุค Expert System มาเทียบกับ AI ในปัจจุบัน

คำถามที่พบบ่อยเกี่ยวกับ Rule-based AI

Rule-based AI กับ Expert System เหมือนกันหรือไม่

ไม่เหมือนกันเสียทีเดียว Rule-based AI คือแนวทางที่แทนความรู้ด้วยกฎและใช้กลไกอนุมาน ส่วน Expert System คือระบบที่มุ่งทำงานเลียนแบบผู้เชี่ยวชาญในสาขาเฉพาะ ระบบผู้เชี่ยวชาญยุคแรกจำนวนมากใช้กฎ จึงทำให้สองคำนี้มักถูกใช้ใกล้เคียงกัน

Rule-based AI เรียนรู้เองได้หรือไม่

ระบบแบบดั้งเดิมไม่เรียนรู้กฎใหม่เอง ความรู้เปลี่ยนเมื่อมนุษย์เพิ่มหรือแก้กฎ แม้ภายหลังจะมีงานวิจัยเรื่องการสร้างหรือเรียนกฎจากข้อมูล แต่ระบบนั้นมีองค์ประกอบของ Machine Learning เพิ่มเข้ามาแล้ว

ทำไมคำสั่ง IF–THEN จึงถูกเรียกว่า AI

คำสั่งเงื่อนไขเพียงข้อเดียวไม่ทำให้โปรแกรมเป็น AI โดยอัตโนมัติ ในบริบทของ Rule-based AI กฎจำนวนมากทำหน้าที่แทนความรู้ และกลไกอนุมานเลือกใช้กฎเพื่อวินิจฉัย วางแผน หรืออธิบายข้อสรุป งานเหล่านี้เคยถูกมองว่าเป็นงานที่ต้องอาศัยสติปัญญาของมนุษย์

Rule-based AI อธิบายได้ดีกว่า Machine Learning เสมอหรือไม่

เส้นทางของกฎมักตรวจย้อนกลับได้โดยตรงกว่า แต่ฐานกฎขนาดใหญ่อาจซับซ้อนจนคนมองไม่เห็นผลกระทบทั้งหมด ขณะเดียวกัน Machine Learning บางชนิด เช่น ต้นไม้ตัดสินใจขนาดเล็ก ก็อธิบายได้ง่าย จึงควรประเมินความโปร่งใสจากระบบจริง ไม่ใช่จากชื่อเทคโนโลยี

ปัจจุบันยังมีการใช้ระบบที่มีกฎอยู่หรือไม่

ยังมีใช้อยู่ โดยเฉพาะงานด้านนโยบายธุรกิจ การตรวจเงื่อนไข การกำหนดสิทธิ์ การเฝ้าระวัง และระบบผสมที่ใช้กฎควบคู่กับคะแนนจากโมเดล Machine Learning

เพียงแต่หลายองค์กรเรียกเทคโนโลยีนี้ว่า Rule Engine, Decision Engine หรือ Business Rules Management มากกว่า Expert System

Generative AI สามารถเขียนกฎแทนผู้เชี่ยวชาญได้หรือไม่

โมเดลสร้างเนื้อหาอาจช่วยร่าง แปลงเอกสาร หรือค้นหาความขัดแย้งเบื้องต้นได้ แต่กฎที่มีผลต่อความปลอดภัย สิทธิ หรือเงินของผู้คนต้องผ่านการยืนยันจากเจ้าของนโยบายและผู้เชี่ยวชาญ

การสร้างประโยคที่ดูสมเหตุผลไม่เท่ากับการรับรองว่ากฎถูกต้อง ครบถ้วน และสอดคล้องกับกฎหมายล่าสุด

สรุป: มนุษย์เขียนกฎได้มากมาย แต่เขียนโลกทั้งใบไม่ไหว

ย้อนกลับไปที่โรงงานคอมพิวเตอร์ของ Digital Equipment Corporation ความสำเร็จของ XCON เริ่มจากแนวคิดที่เรียบง่ายและเป็นรูปธรรม หากผู้เชี่ยวชาญอธิบายความรู้เป็นกฎได้ เครื่องจักรก็สามารถใช้กฎเหล่านั้นอย่างรวดเร็ว สม่ำเสมอ และตรวจย้อนกลับได้

DENDRAL แสดงให้เห็นพลังของความรู้เฉพาะด้าน MYCIN ทำให้การอธิบายเหตุผลกลายเป็นส่วนสำคัญของระบบ และ XCON พา Expert System จากห้องทดลองเข้าสู่การผลิตจริง

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

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

จากห้องโรงงานของ XCON คำถามใหม่จึงค่อย ๆ ชัดขึ้น:

ถ้ามนุษย์เขียนกฎให้ครบทุกกรณีไม่ได้ เราจะให้เครื่องจักรเรียนรู้กฎหรือรูปแบบจากข้อมูลด้วยตัวเองได้หรือไม่

คำถามนี้จะพาเราเข้าสู่บทถัดไป — ยุคของ Machine Learning