ระบบ Feature Store นำเสนอการจัดการฟีเจอร์แบบรวมศูนย์ นำกลับมาใช้ใหม่ได้ และมีการกำหนดเวอร์ชันสำหรับเวิร์กโฟลว์การเรียนรู้ของเครื่อง ในขณะที่การสร้างฟีเจอร์แบบเฉพาะกิจนั้นอาศัยสคริปต์ที่กำหนดเองซึ่งสร้างขึ้นสำหรับแต่ละโครงการ การเลือกใช้ระบบใดระบบหนึ่งจะส่งผลต่อวิธีการที่ทีมขยายขนาด ทำงานร่วมกัน และปรับใช้โมเดลในสภาพแวดล้อมการผลิต
แพลตฟอร์มส่วนกลางที่จัดเก็บ จัดการเวอร์ชัน และให้บริการฟีเจอร์ที่คัดสรรมาแล้วสำหรับโมเดลการเรียนรู้ของเครื่องจักรในทีมและโครงการต่างๆ
การสร้างฟีเจอร์เฉพาะโครงการแบบกำหนดเองนั้น ดำเนินการด้วยตนเองโดยนักวิทยาศาสตร์ข้อมูลโดยใช้สคริปต์ โน้ตบุ๊ก หรือไปป์ไลน์แบบเฉพาะกิจ
| ฟีเจอร์ | ระบบร้านค้าฟีเจอร์ | วิศวกรรมคุณสมบัติเฉพาะกิจ |
|---|---|---|
| ความสามารถในการนำคุณสมบัติกลับมาใช้ใหม่ | ระดับสูง - ใช้ร่วมกันระหว่างทีมและโครงการต่างๆ | ราคาต่ำ - โดยทั่วไปขึ้นอยู่กับโครงการเฉพาะ |
| ความสม่ำเสมอในการฝึกอบรมและการให้บริการ | สร้างขึ้นโดยใช้ไปป์ไลน์แบบรวมศูนย์ | ทำด้วยมือ มักไม่สม่ำเสมอ |
| ความซับซ้อนในการตั้งค่า | ค่าใช้จ่ายในการติดตั้งและโครงสร้างพื้นฐานเริ่มต้นสูงกว่า | เรียบง่าย - มีเพียงโค้ดและข้อมูล |
| ความสามารถในการปรับขนาด | ออกแบบมาเพื่อรองรับการผลิตในระดับอุตสาหกรรม | มีข้อจำกัดด้านทีมงานและกำลังการผลิตของเครื่องมือ |
| การปกครองและสายสืบ | การกำหนดเวอร์ชัน การควบคุมการเข้าถึง บันทึกการตรวจสอบ | โดยทั่วไปมักไม่มีเอกสารหรือเป็นแบบไม่เป็นทางการ |
| ความยืดหยุ่นสำหรับการทดลอง | ระดับปานกลาง - ถูกจำกัดโดยแพลตฟอร์ม | สูงมาก - ไม่มีข้อจำกัดของแพลตฟอร์ม |
| ได้เวลาสร้างโมเดลแรกแล้ว | ทำงานช้าลงเนื่องจากมีค่าใช้จ่ายในการตั้งค่าเพิ่มเติม | รวดเร็วกว่าสำหรับโครงการแบบครั้งเดียวจบ |
| ค่าใช้จ่ายในการบำรุงรักษา | ลดผลกระทบระยะยาวในระดับใหญ่ | ยิ่งจำนวนฟีเจอร์เพิ่มมากขึ้น ก็ยิ่งมีค่าสูงขึ้น |
ระบบ Feature Store ทำงานเป็นโครงสร้างพื้นฐานเฉพาะที่อยู่ระหว่างแหล่งข้อมูลดิบและโมเดลแมชชีนเลิร์นนิง โดยจัดการการนำเข้า การแปลง การจัดเก็บ และการให้บริการผ่านไปป์ไลน์แบบครบวงจร ในทางตรงกันข้าม การสร้าง Feature แบบเฉพาะกิจนั้น จะทำงานอยู่ที่ใดก็ได้ที่นักวิทยาศาสตร์ข้อมูลทำงาน โดยปกติจะอยู่ในโน้ตบุ๊กหรือสคริปต์แบบสแตนด์อโลนที่ดึงข้อมูล ใช้การแปลง และป้อนข้อมูลให้กับโมเดลโดยตรง ความแตกต่างทางสถาปัตยกรรมนี้หมายความว่า Feature Store ต้องการการลงทุนล่วงหน้าในเครื่องมือ ในขณะที่วิธีการแบบเฉพาะกิจสามารถเริ่มต้นได้โดยใช้เพียงไฟล์ CSV และโค้ด pandas บางส่วนเท่านั้น
หนึ่งในปัญหาใหญ่ที่สุดของแมชชีนเลิร์นนิงคือความไม่สมดุลระหว่างการฝึกฝนและการใช้งานจริง ซึ่งโมเดลอาจทำงานได้ดีในระหว่างการพัฒนา แต่กลับทำงานได้แย่ลงเมื่อใช้งานจริง เนื่องจากฟีเจอร์ต่างๆ ถูกคำนวณแตกต่างกัน ฟีเจอร์สโตร์ช่วยแก้ปัญหานี้ได้โดยใช้โค้ดการแปลงข้อมูลเดียวกันสำหรับทั้งข้อมูลการฝึกฝนแบบแบตช์และการอนุมานแบบเรียลไทม์ ด้วยวิธีการเขียนโค้ดแบบเฉพาะกิจ ทีมงานมักจะเขียนชุดตรรกะชุดหนึ่งสำหรับการฝึกฝนและอีกชุดหนึ่งสำหรับการใช้งานจริง ซึ่งทำให้เกิดข้อผิดพลาดเล็กๆ น้อยๆ ที่แก้ไขได้ยากมาก ข้อได้เปรียบด้านความสม่ำเสมอเพียงอย่างเดียวนี้ก็เป็นแรงผลักดันให้หลายองค์กรนำฟีเจอร์สโตร์มาใช้แล้ว
เมื่อฟีเจอร์ต่างๆ ถูกจัดเก็บไว้ในที่เก็บข้อมูลส่วนกลาง นักวิทยาศาสตร์ข้อมูลคนใดก็ได้สามารถค้นหาและนำฟีเจอร์เหล่านั้นกลับมาใช้ใหม่ได้ ซึ่งช่วยป้องกันการทำงานซ้ำซ้อนและส่งเสริมการสร้างมาตรฐาน สมาชิกทีมใหม่สามารถเรียกดูแคตตาล็อกของฟีเจอร์ที่มีอยู่แทนที่จะต้องสร้างใหม่ทั้งหมด การพัฒนาแบบเฉพาะกิจมักจะสร้างกลุ่มงานแยกกัน โดยที่นักวิเคราะห์แต่ละคนสร้างฟีเจอร์ที่คล้ายกันขึ้นมาใหม่โดยลำพัง บางครั้งอาจมีการกำหนดความหมายที่แตกต่างกันเล็กน้อยซึ่งก่อให้เกิดความสับสนในขั้นตอนต่อไป เมื่อเวลาผ่านไป การแตกแยกนี้จะทำให้การรักษากลยุทธ์ฟีเจอร์ที่สอดคล้องกันทั่วทั้งองค์กรทำได้ยากขึ้น
การสร้างฟีเจอร์แบบเฉพาะกิจ (Ad hoc feature engineering) โดดเด่นในช่วงเริ่มต้นของการทดลอง เมื่อนักวิทยาศาสตร์ข้อมูลต้องการพัฒนาการแปลงข้อมูลใหม่ๆ อย่างรวดเร็วโดยไม่ต้องกังวลเกี่ยวกับการใช้งานจริง ฟีเจอร์ใหม่สามารถทดสอบได้ภายในไม่กี่นาที อย่างไรก็ตาม การใช้ฟีเจอร์สโตร์ (feature store) เพิ่มภาระงาน เนื่องจากฟีเจอร์ทุกตัวต้องได้รับการลงทะเบียน ตรวจสอบความถูกต้อง และบูรณาการเข้ากับโครงสร้างพื้นฐานการให้บริการก่อนที่จะสามารถนำไปใช้งานจริงได้ แต่ภาระงานนั้นจะคุ้มค่าเมื่อโมเดลถูกนำไปใช้งานจริง เนื่องจากฟีเจอร์นั้นพร้อมใช้งานแล้ว ไม่จำเป็นต้องใช้ความพยายามทางวิศวกรรมแยกต่างหาก
การบริหารจัดการฟีเจอร์สโตร์นั้นเกี่ยวข้องกับค่าใช้จ่ายด้านโครงสร้างพื้นฐานสำหรับการจัดเก็บ การประมวลผล และการจัดการระบบ รวมถึงความพยายามด้านวิศวกรรมในการบำรุงรักษา สำหรับทีมขนาดเล็กหรือโครงการเดียว อาจดูเหมือนเป็นการลงทุนที่มากเกินไป การพัฒนาแบบเฉพาะกิจนั้นมีค่าใช้จ่ายด้านโครงสร้างพื้นฐานเกือบเป็นศูนย์ แต่จะมีค่าใช้จ่ายแฝงสะสมจากการทำงานซ้ำซ้อน การแก้ไขข้อบกพร่องที่ไม่สอดคล้องกัน และการเขียนฟีเจอร์ใหม่สำหรับการใช้งานจริง จุดคุ้มทุนมักจะมาถึงเมื่อองค์กรมีโมเดลหลายตัวที่ใช้งานอยู่ หรือมีนักวิทยาศาสตร์ข้อมูลหลายคนทำงานในปัญหาที่ซ้ำซ้อนกัน
Feature store ก็คือฐานข้อมูลสำหรับฟีเจอร์ต่างๆ นั่นเอง
Feature Store เป็นมากกว่าแค่ที่เก็บข้อมูล มันรวมถึงกระบวนการแปลงข้อมูล การให้บริการแบบออนไลน์และออฟไลน์ การค้นหาฟีเจอร์ การติดตามที่มาของข้อมูล และการควบคุมการเข้าถึง การมองว่ามันเป็นเพียงฐานข้อมูลธรรมดาทำให้มองข้ามคุณค่าส่วนใหญ่ของมันไป โดยเฉพาะอย่างยิ่งการรับประกันความสอดคล้องระหว่างข้อมูลฝึกฝนและข้อมูลอนุมาน
การสร้างฟีเจอร์แบบเฉพาะกิจนั้นไม่สามารถขยายขนาดได้เลย
บริษัทที่ประสบความสำเร็จหลายแห่งใช้ไปป์ไลน์แบบเฉพาะกิจมานานหลายปีก่อนที่จะนำฟีเจอร์สโตร์มาใช้ วิธีการนี้ใช้ได้ผลดีพอสมควรสำหรับทีมขนาดเล็กและโมเดลไม่กี่ตัว แต่สิ่งที่ล้มเหลวคือการทำงานร่วมกัน การกำกับดูแล และความสม่ำเสมอ เมื่อจำนวนโมเดลและนักวิทยาศาสตร์ข้อมูลเพิ่มขึ้นอย่างมาก
คุณต้องเลือกแนวทางใดแนวทางหนึ่งตลอดไป
องค์กรด้านแมชชีนเลิร์นนิงที่เติบโตเต็มที่ส่วนใหญ่ใช้ทั้งสองวิธี นักวิทยาศาสตร์ข้อมูลสำรวจแนวคิดใหม่ๆ แบบเฉพาะกิจในสมุดบันทึก จากนั้นจึงนำคุณสมบัติที่ผ่านการตรวจสอบแล้วไปเก็บไว้ในคลังคุณสมบัติเพื่อนำไปใช้ในการผลิต การมองว่าทั้งสองวิธีนี้เป็นส่วนเสริมกันมากกว่าที่จะเป็นคู่แข่งกัน มักจะได้ผลดีที่สุดในทางปฏิบัติ
Feature store ช่วยเพิ่มความแม่นยำของโมเดลโดยอัตโนมัติ
Feature store ช่วยปรับปรุงคุณภาพการดำเนินงาน ไม่ได้หมายความว่าจะช่วยเพิ่มประสิทธิภาพของโมเดลเสมอไป มันช่วยลดบั๊ก เร่งความเร็วในการปรับใช้ และป้องกันความไม่สอดคล้องกัน แต่ฟีเจอร์พื้นฐานยังคงต้องการการออกแบบอย่างรอบคอบ ฟีเจอร์ที่ไม่ดีใน store ก็ยังคงเป็นฟีเจอร์ที่ไม่ดีอยู่ดี
ฟีเจอร์สโตร์แบบโอเพนซอร์สพร้อมใช้งานสำหรับการผลิตได้ทันทีโดยไม่ต้องตั้งค่าเพิ่มเติม
เครื่องมืออย่าง Feast และ Hopsworks เป็นรากฐานที่มั่นคง แต่การนำไปใช้งานจริงยังคงต้องอาศัยงานด้านวิศวกรรมอย่างมากในด้านการตรวจสอบ การขยายขนาด ความปลอดภัย และการบูรณาการกับโครงสร้างพื้นฐานข้อมูลที่มีอยู่ ความพร้อมใช้งานแบบสำเร็จรูปนั้นแตกต่างกันไปอย่างมากในแต่ละโครงการ
ระบบ Feature Store เป็นตัวเลือกที่ดีกว่าสำหรับองค์กรที่ใช้งานโมเดลหลายตัวในการผลิต หรือขยายการดำเนินงานด้าน Machine Learning ข้ามทีม ซึ่งความสม่ำเสมอและการนำกลับมาใช้ใหม่มีความสำคัญที่สุด อย่างไรก็ตาม การสร้าง Feature แบบเฉพาะกิจยังคงมีคุณค่าสำหรับนักวิทยาศาสตร์ข้อมูลที่ทำงานคนเดียว โครงการวิจัย และการทดลองในระยะเริ่มต้น ซึ่งความเร็วและความยืดหยุ่นมีความสำคัญมากกว่าข้อดีของโครงสร้างพื้นฐานแบบรวมศูนย์ ทีมที่มีประสบการณ์หลายทีมใช้ทั้งสองแบบ โดยอาศัยการทำงานแบบเฉพาะกิจสำหรับการสำรวจ และใช้ Feature Store สำหรับทุกสิ่งที่เข้าสู่ขั้นตอนการผลิต
AI slop หมายถึงเนื้อหา AI ที่ผลิตออกมาจำนวนมากโดยใช้ความพยายามน้อยและขาดการกำกับดูแล ในขณะที่งาน AI ที่มีมนุษย์ควบคุมนั้นเป็นการผสมผสานปัญญาประดิษฐ์เข้ากับการตัดต่อ การกำกับ และการตัดสินใจเชิงสร้างสรรค์อย่างรอบคอบ ความแตกต่างมักอยู่ที่คุณภาพ ความคิดริเริ่ม ประโยชน์ใช้สอย และว่ามีบุคคลจริงเข้ามามีส่วนร่วมในการกำหนดผลลัพธ์สุดท้ายหรือไม่
AI ที่มีมนุษย์เข้ามาเกี่ยวข้อง (Human-in-the-Loop AI) ผสานประสิทธิภาพของเครื่องจักรเข้ากับการตัดสินใจของมนุษย์ในจุดสำคัญ ในขณะที่ระบบ AI อัตโนมัติเต็มรูปแบบ (Fully Automated AI Systems) ทำงานอย่างอิสระตั้งแต่ต้นจนจบ แต่ละแนวทางมีข้อดีข้อเสียที่แตกต่างกันในด้านความแม่นยำ ความสามารถในการขยายขนาด ต้นทุน และความรับผิดชอบ ซึ่งเป็นตัวกำหนดว่าแนวทางใดเหมาะสมกับกรณีการใช้งานนั้นๆ
การเปรียบเทียบทางสถาปัตยกรรมนี้เน้นให้เห็นถึงความแตกต่างหลักระหว่างระบบ AI ที่รับรู้บริบท ซึ่งวิเคราะห์ข้อมูลสถานการณ์แบบไดนามิก เช่น ความตั้งใจของผู้ใช้ ประวัติ และสภาพแวดล้อม กับระบบที่ไม่รับรู้บริบท ซึ่งประมวลผลข้อมูลนำเข้าเป็นเหตุการณ์แยกต่างหากโดยอาศัยกฎที่กำหนดไว้ล่วงหน้าเท่านั้น
AI ที่เสริมด้วยการค้นหาจะดึงข้อมูลแบบเรียลไทม์จากแหล่งข้อมูลภายนอกในขณะที่ทำการค้นหา ในขณะที่การฝึกฝนโดยใช้ชุดข้อมูลเพียงอย่างเดียวจะอาศัยความรู้ที่ฝังอยู่ในน้ำหนักของโมเดลระหว่างการฝึกฝนเท่านั้น แต่ละแนวทางมีข้อดีข้อเสียที่แตกต่างกันในด้านความแม่นยำ ต้นทุน ความทันสมัย และความสามารถในการจัดการกับคำถามที่อยู่นอกขอบเขตการฝึกฝนดั้งเดิม
ระบบ AI แบบกระจายศูนย์จะกระจายสติปัญญา ข้อมูล และการคำนวณไปยังโหนดอิสระต่างๆ โดยมักให้ความสำคัญกับความเปิดกว้างและการควบคุมของผู้ใช้ ในขณะที่ระบบ AI ขององค์กรนั้นได้รับการจัดการจากส่วนกลางโดยบริษัทต่างๆ โดยมุ่งเน้นที่ประสิทธิภาพ ผลกำไร และการบูรณาการผลิตภัณฑ์ ทั้งสองแนวทางนี้มีส่วนกำหนดวิธีการสร้าง การกำกับดูแล และการเข้าถึง AI แต่มีความแตกต่างกันอย่างมากในด้านความโปร่งใส การเป็นเจ้าของ และการควบคุม
