คู่มือการใช้งาน Feature Store: การออกแบบเพื่อเพิ่มความสามารถในการนำกลับมาใช้ใหม่และความสดใหม่ของข้อมูลสำหรับโมเดล AI

หัวข้อของบทความนี้คือ "คู่มือการนำ Feature Store มาใช้งาน" Feature Store คือโครงสร้างพื้นฐานด้านข้อมูลสำหรับการนำฟีเจอร์เดิมกลับมาใช้ซ้ำทั้งในขั้นตอนการเรียนรู้ (Training) และการอนุมาน (Inference) เพื่อให้ข้อมูลมีความสดใหม่อยู่เสมอ การนำมาใช้งานจำเป็นต้องมีการตัดสินใจเชิงออกแบบเป็นขั้นตอน ตั้งแต่การกำหนดความต้องการ การสร้างไปป์ไลน์ การบูรณาการเข้ากับระบบจริง ไปจนถึงการวางระบบติดตามผล Feature Store ถูกจัดวางให้เป็นกลไกที่ช่วยให้การดำเนินงานโมเดล AI มีการออกแบบที่เพิ่มความสามารถในการนำกลับมาใช้ใหม่และความสดใหม่ของข้อมูล ช่วยป้องกันความไม่สอดคล้องกันของฟีเจอร์ระหว่างช่วงการเรียนรู้และช่วงการอนุมาน รวมถึงช่วยให้สามารถนำฟีเจอร์กลับมาใช้ซ้ำระหว่างโมเดลต่างๆ ได้ บทความนี้จัดทำขึ้นสำหรับผู้รับผิดชอบที่กำลังพิจารณาการนำ Feature Store มาใช้งานและต้องการประเมินระบบ MLOps ขององค์กร โดยจะอธิบายขั้นตอนการตรวจสอบเงื่อนไขเบื้องต้นก่อนการติดตั้ง 4 ขั้นตอนการออกแบบ รวมถึงข้อผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง เมื่ออ่านจบแล้ว คุณจะสามารถตัดสินใจได้ว่าสถานะปัจจุบันขององค์กรเหมาะสมกับการนำมาใช้งานหรือไม่ และสามารถระบุงานที่ควรดำเนินการต่อไปได้อย่างเป็นรูปธรรม

ข้อกำหนดเบื้องต้นในการนำไปใช้งานประกอบด้วย 3 ประการ ได้แก่ โครงสร้างพื้นฐานของข้อมูลที่สามารถแยกส่วนออฟไลน์และออนไลน์ออกจากกันได้, การออกแบบสคีมาที่สามารถจัดการกับนิยามของ Entity และ timestamp ได้, และการจัดการข้อมูลเมตาที่สามารถลงทะเบียนและนำนิยามของฟีเจอร์กลับมาใช้ใหม่ได้ หากขาดสิ่งเหล่านี้ไป การนำไปใช้งานจะนำไปสู่การเปลี่ยนแปลงการออกแบบในขั้นตอนถัดไป

ในการตรวจสอบโครงสร้างพื้นฐานข้อมูลที่มีอยู่ ให้ตรวจสอบว่ามีการแยกจุดจัดเก็บข้อมูลฝั่งออฟไลน์และออนไลน์ออกจากกันอย่างชัดเจนหรือไม่ โดยฝั่งออฟไลน์จะสมมติให้เป็นจุดจัดเก็บแบบแบตช์ (Batch) เช่น BigQuery, S3 หรือ Snowflake ส่วนฝั่งออนไลน์จะสมมติให้มีการใช้ Kafka หรือ PubSub เป็นช่องทางสตรีมมิ่งที่รองรับการอ้างอิงข้อมูลที่มีความหน่วงต่ำ เนื่องจาก Feast และ Tecton ถูกออกแบบมาโดยมีเงื่อนไขว่าต้องมีการเชื่อมต่อและจัดระเบียบ (Orchestration) กับที่จัดเก็บข้อมูลภายนอกเหล่านี้ หากโครงสร้างพื้นฐานเดิมไม่รองรับการกำหนดค่าดังกล่าว จำเป็นต้องเตรียมช่องทางการเชื่อมต่อให้พร้อมก่อนที่จะเริ่มใช้งาน Feature Store

ในการตรวจสอบระบบ MLOps ให้ตรวจสอบการมีอยู่ของไปป์ไลน์ CI/CD, ตัวจัดตารางเวลา (Scheduler) และการจัดระเบียบ (Orchestration) รวมถึงความเป็นไปได้ในการเชื่อมต่อกับ Model Registry หากการเรียนรู้ของโมเดลและการสร้างฟีเจอร์ทำงานบนไปป์ไลน์ที่แยกจากกัน โดยไม่มีกลไกในการจัดการคำจำกัดความของฟีเจอร์แบบรวมศูนย์ อาจนำไปสู่สาเหตุที่ทำให้เกิดการใช้ตรรกะที่แตกต่างกันระหว่างช่วงการเรียนรู้และช่วงการอนุมาน (Inference) หากไปป์ไลน์ของบริษัทรองรับเฉพาะการประมวลผลแบบแบตช์และไม่มีกลไกสำหรับการอัปเดตแบบสตรีมมิ่ง จำเป็นต้องกำหนดความต้องการด้านความสดใหม่ของข้อมูลสำหรับการให้บริการแบบออนไลน์ให้ชัดเจนก่อน แล้วจึงค่อยตัดสินใจลำดับขั้นตอนในการปรับปรุงโครงสร้างพื้นฐานต่อไป

ทีมที่จำเป็นต้องมีประกอบด้วย 4 บทบาท ได้แก่ Data Engineer (สร้าง Batch/Stream Pipeline), ML Engineer (เข้าใจการออกแบบ Feature และการทำ Point-in-time Join), SRE/Cloud Operator (จัดการ Latency SLA สำหรับการให้บริการแบบออนไลน์) และ Governance (จัดการสิทธิ์การเข้าถึงและ Metadata) ทั้งนี้ ไม่จำเป็นต้องเป็นพนักงานประจำเต็มเวลาในทั้ง 4 บทบาท แต่หากไม่มีบุคลากรที่เข้าใจแนวคิดเรื่อง Point-in-time Join ในขั้นตอนการออกแบบ ก็จะยังคงมีความเสี่ยงที่ตรรกะที่ใช้ในการเรียนรู้ (Training) และการอนุมาน (Inference) จะไม่ตรงกัน

สำหรับการเลือกเครื่องมือ ให้ใช้เกณฑ์เปรียบเทียบ 4 ประการดังนี้

Feast ให้บริการฟังก์ชันที่เกี่ยวข้องกับ 4 ประการข้างต้นในฐานะโครงการ Open Source ส่วน Tecton และ Databricks Feature Store ให้บริการในฐานะแพลตฟอร์ม Feature Store เชิงพาณิชย์ โปรดตรวจสอบขอบเขตการรับประกัน SLA และการเชื่อมต่อ IAM ของแต่ละเครื่องมือจากเอกสารอย่างเป็นทางการ

จุดเริ่มต้นของการกำหนดความต้องการ (Requirement Definition) คือการระบุคำนิยามของ Entity (Primary Key) รวมถึง Schema ของคุณลักษณะ (Feature) แต่ละรายการ และการจัดการกับค่าที่ขาดหายไป (Missing Value) การกำหนดคอลัมน์ timestamp และ TTL สำหรับคุณลักษณะแต่ละรายการ และการตัดสินใจว่าจะกำหนดนโยบายการออกแบบที่ไม่ทำลายความถูกต้องของข้อมูล ณ จุดเวลาใดเวลาหนึ่ง (Point-in-time correctness) ให้ชัดเจนตั้งแต่ต้นหรือไม่นั้น จะเป็นตัวกำหนดระดับความยากง่ายในการดำเนินการในขั้นตอนถัดไป

ออฟไลน์ฟีเจอร์ (Offline features) และออนไลน์ฟีเจอร์ (Online features) จะถูกจำแนกตามข้อกำหนดด้านช่วงเวลาที่จัดเก็บและความเร็วในการให้บริการ ออฟไลน์ฟีเจอร์คือฟีเจอร์ที่เก็บประวัติย้อนหลังและถูกนำมาใช้เพื่อสร้างข้อมูลสำหรับการเรียนรู้ (Training data) โดยจำเป็นต้องมีการสะสมข้อมูลระยะยาวและสามารถสร้าง "ค่าที่มีอยู่ ณ จุดเวลาหนึ่ง" ขึ้นมาใหม่ได้อย่างแม่นยำผ่านการเชื่อมโยงข้อมูลตามจุดเวลา (Point-in-time join)

ออนไลน์ฟีเจอร์คือฟีเจอร์ในรูปแบบ Key-Value Store ที่ส่งคืนเฉพาะค่าล่าสุดด้วยความหน่วงต่ำ เนื่องจากถูกอ้างอิงในระหว่างการอนุมาน (Inference) ระยะเวลาการจัดเก็บจึงสั้น และความเร็วในการตอบสนองจะเป็นหัวใจสำคัญของข้อกำหนดด้านประสิทธิภาพ

แม้ว่าฟีเจอร์ทั้งสองประเภทนี้จะถูกจัดเก็บไว้ในที่จัดเก็บข้อมูลแยกกัน แต่ตัวนิยามฟีเจอร์ (Feature definition) ควรจะเป็นชุดเดียวกัน ตัวอย่างเช่น ฟีเจอร์ "จำนวนครั้งในการซื้อของผู้ใช้" จะดึงค่าในอดีตจากออฟไลน์สโตร์ในระหว่างการเรียนรู้ และดึงค่าล่าสุดจากออนไลน์สโตร์ในระหว่างการอนุมาน หากตรรกะการคำนวณแตกต่างกันจะทำให้เกิดความคลาดเคลื่อนของค่าระหว่างการเรียนรู้และการอนุมาน การกำหนดการจำแนกประเภทนี้ให้ชัดเจนตั้งแต่เริ่มต้นจะเป็นรากฐานสำคัญในการออกแบบนิยามฟีเจอร์ เช่น Feature View

ความสดใหม่ (Freshness) ถูกนิยามว่าเป็นความล่าช้า (Latency) ตั้งแต่เวลาที่ข้อมูลถูกสร้างขึ้นจนกระทั่งสามารถเรียกใช้งานได้บนร้านค้าออนไลน์ โดยค่าความล่าช้านี้เมื่อระบุเป็นตัวเลขตามความต้องการทางธุรกิจจะเรียกว่า SLA ความสดใหม่ ตัวอย่างเช่น ในกรณีของการตรวจจับการฉ้อโกง (Fraud Detection) ฟีเจอร์ที่จำเป็นต้องสะท้อนข้อมูลธุรกรรมล่าสุดทันทีจะต้องการ SLA ในระดับวินาที แต่หากเป็นฟีเจอร์ที่ใช้แนวโน้มการซื้อรายสัปดาห์ ความล่าช้าในระดับชั่วโมงก็เพียงพอต่อความต้องการทางธุรกิจแล้ว

ขั้นตอนการกำหนด SLA มีดังนี้:

1. ตกลงกับฝ่ายธุรกิจเกี่ยวกับค่าความล่าช้าสูงสุดที่ยอมรับได้สำหรับผลลัพธ์การอนุมาน (Inference) ในแต่ละฟีเจอร์
2. เลือกวิธีการอัปเดตที่ตอบโจทย์ความล่าช้านั้น (ไม่ว่าจะเป็นการทำ Materialize แบบ Batch หรือการเขียนข้อมูลแบบ Streaming)
3. กำหนดค่าความล่าช้าที่วัดได้จริงของแต่ละวิธีการอัปเดตให้เป็นดัชนีชี้วัด (Monitoring Metric)

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

เป็นขั้นตอนการนำ Entity, Schema และ SLA ที่กำหนดไว้ในขั้นตอนการนิยามความต้องการ (Requirement Definition) มาปรับใช้ในการพัฒนาจริง ในส่วนของไปป์ไลน์นั้น ไม่ควรเลือกประมวลผลฟีเจอร์ทั้งหมดด้วยวิธีใดวิธีหนึ่งเพียงอย่างเดียว ไม่ว่าจะเป็นแบบ Batch หรือ Streaming แต่จำเป็นต้องเลือกวิธีการอัปเดตให้เหมาะสมกับฟีเจอร์แต่ละตัว และต้องสร้างโครงสร้างที่สามารถใช้ตรรกะการคำนวณร่วมกันระหว่างขั้นตอนการเรียนรู้ (Training) และการอนุมาน (Inference) ได้

การประมวลผลแบบแบตช์ (Batch processing) คือวิธีการคำนวณข้อมูลย้อนหลังแบบรวมกลุ่มและนำไปอัปเดตยังร้านค้าออนไลน์ (Online store) ตามตารางเวลาที่กำหนด เหมาะสำหรับฟีเจอร์ที่ยอมรับค่าความสดใหม่ (Freshness SLA) ได้ในระดับชั่วโมงขึ้นไป เช่น แนวโน้มการซื้อหรือข้อมูลคุณลักษณะที่อัปเดตเป็นรายวันหรือรายสัปดาห์ ใน Feast จะใช้กระบวนการที่เรียกว่า "materialize" เพื่อดำเนินการนี้ โดยจะเขียนค่าจากออฟไลน์สโตร์ (Offline store) ลงในออนไลน์สโตร์เป็นระยะๆ

การประมวลผลแบบสตรีมมิ่ง (Streaming processing) คือวิธีการคำนวณฟีเจอร์ทันทีที่เกิดเหตุการณ์ขึ้นและเขียนลงในออนไลน์สโตร์โดยตรง เหมาะสำหรับฟีเจอร์ที่ต้องการ SLA ในระดับวินาที เช่น การตรวจจับการฉ้อโกงหรือประวัติการใช้งานล่าสุด แต่จะมีต้นทุนในการสร้างและดูแลรักษาโครงสร้างพื้นฐานการประมวลผลสูงกว่าแบบแบตช์

ขั้นตอนการออกแบบมีดังนี้:

1. ตรวจสอบค่าความสดใหม่ (Freshness SLA) ของฟีเจอร์แต่ละตัว
2. หาก SLA อยู่ในระดับชั่วโมงขึ้นไปให้เลือกแบบแบตช์ หากเป็นระดับนาทีหรือวินาทีให้เลือกแบบสตรีมมิ่ง
3. หากมีการใช้งานทั้งสองวิธีร่วมกัน ให้แยกเส้นทางการเขียนข้อมูลไปยังออนไลน์สโตร์ตามรายฟีเจอร์ เพื่อให้สามารถตรวจสอบความล่าช้าในการอัปเดตแยกกันได้

หากประมวลผลฟีเจอร์ทั้งหมดด้วยวิธีเดียวกัน จะส่งผลให้เกิดภาระการคำนวณที่ไม่จำเป็น หรือข้อมูลมีความสดใหม่ไม่เพียงพออย่างใดอย่างหนึ่ง

จุดประสงค์ของการทำให้ตรรกะการแปลง Feature (Feature Transformation Logic) เป็นมาตรฐานเดียวกัน คือเพื่อรับประกันว่าผลลัพธ์การคำนวณในระหว่างการเทรน (Training) และการอนุมาน (Inference) จะต้องเหมือนกัน หากมีการเขียนโค้ดแยกกันระหว่างการประมวลผลแบบ Batch และแบบ Streaming อาจทำให้ตรรกะการคำนวณของ Feature ที่มีชื่อเดียวกันมีความแตกต่างกันเล็กน้อย ซึ่งเป็นสาเหตุที่ทำให้ข้อมูลที่ใช้เทรนและค่าที่นำเข้าในขณะอนุมานไม่ตรงกัน เพื่อหลีกเลี่ยงปัญหานี้ เราจึงควรกำหนดตรรกะการแปลงไว้เพียงครั้งเดียวในรูปแบบของ Feature Store Definition แล้วจึงเรียกใช้คำจำกัดความนั้นจากทั้งฝั่ง Offline และ Online

ขั้นตอนการดำเนินการมีดังนี้:

1. เขียนตรรกะการแปลงไว้ในที่เดียวในรูปแบบของ Feature Store Definition
2. Pipeline สำหรับการเทรนจะเรียกใช้คำจำกัดความนี้ผ่าน API สำหรับดึงข้อมูลย้อนหลัง (Historical Retrieval API)
3. Pipeline สำหรับการอนุมานจะเรียกใช้คำจำกัดความเดียวกันผ่าน API สำหรับดึงข้อมูลแบบออนไลน์ (Online Retrieval API)

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

จุดตัดสินใจในการทำ Production Integration อยู่ที่ความแตกต่างของ API ที่เรียกใช้ระหว่างฝั่งการเรียนรู้ (Training) และฝั่งการอนุมาน (Inference) โดย API สำหรับดึงข้อมูลประวัติ (History Retrieval API) และ API สำหรับดึงข้อมูลแบบออนไลน์ (Online Retrieval API) นั้นเป็นคนละส่วนกัน การที่ทั้งสองส่วนอ้างอิงถึงนิยามคุณลักษณะ (Feature Definition) เดียวกันหรือไม่นั้น จะเป็นตัวกำหนดความสอดคล้องระหว่างการเรียนรู้และการอนุมาน

สำหรับการเชื่อมต่อกับไปป์ไลน์การเรียนรู้ของโมเดล (Model Training Pipeline) ให้รวม History Retrieval API เข้าที่จุดเริ่มต้นของโค้ดการเรียนรู้ และรวมการดึงข้อมูลฟีเจอร์ (Feature Retrieval) และการสร้างข้อมูลสำหรับการเรียนรู้เข้าไว้ในขั้นตอนการประมวลผลเดียวกัน โดยมีขั้นตอนการเชื่อมต่อดังนี้:

1. เตรียมรายการเอนทิตีที่ต้องการเรียนรู้ และเวลาอ้างอิง (Reference Time) ของแต่ละตัวอย่าง (เวลาที่ระบุฉลากได้แน่ชัด)
2. ส่ง Feature View ที่กำหนดไว้ในฝั่ง Feature Store และเวลาอ้างอิงไปยัง History Retrieval API เพื่อดึงข้อมูลสำหรับการเรียนรู้
3. ส่ง DataFrame ที่ได้ไปยังงานการเรียนรู้ (Training Job) โดยตรง โดยไม่ต้องมีโค้ดคำนวณฟีเจอร์แยกต่างหากไว้ในฝั่งการเรียนรู้

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

สิ่งที่ต้องตรวจสอบในการซิงโครไนซ์กับการให้บริการแบบออนไลน์ (Online Serving) ในขณะอนุมาน (Inference) คือการตรวจสอบว่าการอัปเดตไปยัง Online Store นั้นเกิดขึ้นผ่านช่องทางใดและมีความล่าช้าเท่าใด โดยช่องทางการอัปเดตจะแบ่งออกเป็น 2 ประเภท ได้แก่ การทำ Materialize ที่เลือกไว้ในการออกแบบ Batch Processing และการเขียนข้อมูลแบบทันทีผ่าน Streaming Processing ซึ่งในการบูรณาการเข้าสู่ระบบจริง (Production Integration) จำเป็นต้องมีการดำเนินงานเพื่อตรวจสอบความล่าช้าในการอัปเดตที่เกิดขึ้นจริงในแต่ละช่องทาง สำหรับขั้นตอนการตัดสินด้วยเกณฑ์ค่าขีดจำกัด (Threshold) และการเปรียบเทียบกับ Freshness SLA ให้ปฏิบัติตามเนื้อหาที่ได้กล่าวไว้ในส่วนของการกำหนดความต้องการด้านความสดใหม่ของข้อมูล (Freshness Requirements) และ SLA

ขั้นตอนการตรวจสอบการซิงโครไนซ์มีดังนี้:

1. เก็บเวลาการอัปเดตล่าสุดไว้เป็น Metadata สำหรับ Feature แต่ละรายการภายใน Online Store
2. บันทึกผลต่างระหว่างเวลาการอัปเดตล่าสุดของ Feature ที่ดึงมาได้กับเวลาปัจจุบันในทุกคำขออนุมาน (Inference Request)
3. นำผลต่างที่บันทึกไว้ไปเทียบกับเกณฑ์การตัดสินของ Freshness SLA และจัดการช่องทางที่มีความล่าช้าต่อเนื่องว่าเป็นความล่าช้าในการอัปเดต (Update Latency)

ความผิดพลาดในการตั้งค่าตารางเวลาของ Materialize หรือความล่าช้าในการประมวลผลของ Streaming Infrastructure เป็นปัญหาที่สังเกตได้ยากจนกว่าจะปรากฏออกมาในรูปแบบของความแม่นยำของผลลัพธ์การอนุมานที่ลดลง เช่นเดียวกับการรวม API สำหรับดึงข้อมูลประวัติ (History Retrieval API) เข้าเป็นหนึ่งเดียวในการเชื่อมต่อกับ Pipeline การเรียนรู้ (Training Pipeline) ฝั่งการอนุมานเองก็ต้องจำกัดการดึงข้อมูลผ่าน Online Retrieval API เท่านั้น และไม่ควรเหลือช่องทางการอ้างอิง Feature อื่นๆ ไว้ ซึ่งถือเป็นข้อกำหนดเบื้องต้นสำหรับการซิงโครไนซ์

เมื่อการรวมระบบเข้ากับสภาพแวดล้อมจริง (Production Integration) เสร็จสมบูรณ์แล้ว ยังไม่มีการรับประกันว่าฟีเจอร์ (Features) จะไหลเวียนได้อย่างถูกต้องหรือไม่ จุดตัดสินใจสำคัญในขั้นตอนการดำเนินงานคือการสร้างระบบที่สามารถตรวจวัดอัตราข้อมูลที่ขาดหาย (Missing rate), ความสดใหม่ของข้อมูล (Freshness), การเปลี่ยนแปลงของการกระจายตัว (Distribution shift) และความหน่วงในการตอบสนอง (Response latency) เพื่อให้สามารถตรวจพบความผิดปกติได้ก่อนที่ประสิทธิภาพของโมเดลจะลดลง

Feature Drift คือปรากฏการณ์ที่การกระจายตัวของ Feature ที่ใช้ในขณะฝึกสอน (Training) แตกต่างไปจากการกระจายตัวของ Feature ที่พบจริงในขณะใช้งานจริง (Production) พื้นฐานของการตรวจจับคือการเปรียบเทียบการกระจายตัวของแต่ละ Feature ในช่วงที่ฝึกสอนกับช่วงเวลาล่าสุด แล้วแปลงความแตกต่างนั้นออกมาเป็นค่าทางสถิติ วิธีการที่เป็นตัวแทนได้แก่ Wasserstein distance หรือ KS test โดยสำหรับ Categorical features จะใช้คะแนนความแตกต่างของความถี่ในการกระจายตัว ส่วน Numerical features จะใช้วิธีคำนวณความแตกต่างของรูปร่างการกระจายตัว

ขั้นตอนการตรวจจับมีดังนี้:

1. บันทึกสแนปชอต ณ ช่วงเวลาที่ฝึกสอนไว้เป็นข้อมูลอ้างอิง (Reference distribution)
2. รวบรวมค่าที่ให้บริการแบบออนไลน์ในช่วงเวลาล่าสุด เช่น 1 วัน หรือ 1 สัปดาห์ เพื่อสร้างข้อมูลเปรียบเทียบ (Comparison distribution)
3. ดึงข้อมูล Feature ที่มีค่าทางสถิติเกินเกณฑ์ (Threshold) ที่กำหนดไว้ล่วงหน้าออกมา แล้วแจ้งเตือน

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

ในการออกแบบสิทธิ์การเข้าถึงและธรรมาภิบาล สิ่งที่ต้องตรวจสอบคือมีการออกแบบโดยแยกการควบคุมการเข้าถึงในระดับฟีเจอร์ (Feature) ออกจากการจัดการข้อมูลเมตา (Metadata) หรือไม่ โดยใช้ IAM หรือ RBAC ในการแบ่งแยกโปรเจกต์และพื้นที่ทำงาน (Workspace) พร้อมทั้งกำหนดสิทธิ์ว่าใครสามารถเรียกดูหรืออัปเดตฟีเจอร์ใดได้บ้าง แพลตฟอร์มเชิงพาณิชย์บนระบบคลาวด์มักมีการรวมระบบเข้ากับ IAM อยู่แล้ว แต่หากเป็นโครงสร้างแบบ On-premise จำเป็นต้องตั้งค่าสิทธิ์ในส่วนของ Feature Store ให้สอดคล้องกับการตั้งค่าสิทธิ์บนระบบคลาวด์

ขั้นตอนการออกแบบมีดังนี้:

1. แบ่งฟีเจอร์ออกเป็น Workspace ตามทีมหรือวัตถุประสงค์การใช้งาน
2. ลงทะเบียนเจ้าของ (Owner) และแท็ก (วัตถุประสงค์การใช้งาน/ระดับความลับ) ให้กับฟีเจอร์แต่ละรายการในฐานะข้อมูลเมตา
3. จัดเก็บประวัติการเรียกดู อัปเดต และลบข้อมูลไว้เป็นบันทึกการตรวจสอบ (Audit Log)

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

ความล้มเหลวในการนำ Feature Store มาใช้ไม่ได้เกิดจากการเลือกเทคโนโลยีที่ผิดพลาด แต่เกิดจากการลำดับการตัดสินใจในการออกแบบที่ผิดพลาด ทั้งความไม่สอดคล้องกันระหว่างการเรียนรู้ (Training) และการอนุมาน (Inference) รวมถึงการออกแบบที่เกินความจำเป็น (Over-engineering) ล้วนเป็นผลมาจากการละเลยขั้นตอนการกำหนดความต้องการ (Requirement Definition) ซึ่งจะปรากฏให้เห็นในขั้นตอนการทำงานภายหลัง

Training-Serving Skew คือปรากฏการณ์ที่ค่าของฟีเจอร์ที่ใช้ในระหว่างการเรียนรู้ (Training) กับค่าที่ถูกอ้างอิงจริงในระหว่างการอนุมาน (Inference) เกิดความคลาดเคลื่อนกัน สาเหตุส่วนใหญ่แบ่งออกเป็น 2 ประการ ได้แก่ การรั่วไหลของข้อมูล (Data Leakage) ที่เกิดจากการนำค่าในอนาคตเข้ามาปะปนในขณะสร้างข้อมูลสำหรับเรียนรู้ และความแตกต่างในการคำนวณที่เกิดจากการแยกกันพัฒนาตรรกะการแปลงข้อมูล (Transformation Logic) สำหรับการเรียนรู้และการอนุมาน

แนวทางรับมือหลักคือการทำ Point-in-time Join หากสามารถรวมเส้นทางการดึงข้อมูลให้เป็นหนึ่งเดียวตามที่ระบุไว้ในหัวข้อ 45195 ได้ แม้เส้นทางการอ้างอิงระหว่างฝั่งเรียนรู้และฝั่งอนุมานจะแตกต่างกัน แต่คำนิยามของฟีเจอร์ที่เรียกใช้ก็จะยังคงเป็นชุดเดียวกัน

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

การออกแบบที่เกินความจำเป็น (Over-engineering) มักเกิดขึ้นจากการขยายขอบเขตการออกแบบในขั้นตอนการนำไปใช้งาน โดยรวมไปถึง "ฟีเจอร์ที่อาจได้ใช้ในอนาคต" เข้าไปด้วย เมื่อ Feature View หรือเส้นทางการให้บริการแบบออนไลน์ (Online serving path) ที่ไม่ได้ถูกใช้งานจริงในการผลิตมีจำนวนเพิ่มมากขึ้น จะส่งผลให้รายการที่ต้องเฝ้าระวังและรายการการจัดการสิทธิ์การเข้าถึงเพิ่มพูนขึ้น จนทำให้ต้นทุนการดำเนินงานสูงกว่ามูลค่าการใช้งานจริงของฟังก์ชันนั้นๆ

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

1. รวบรวมรายการฟีเจอร์ที่โมเดลปัจจุบันใช้งานอยู่ เพื่อกำหนดเป็นขอบเขตการใช้งานเริ่มต้น
2. เมื่อมีความต้องการโมเดลใหม่เข้ามา ให้ตรวจสอบก่อนว่าสามารถนำฟีเจอร์ที่มีอยู่เดิมกลับมาใช้ใหม่ได้หรือไม่ ก่อนที่จะตัดสินใจเพิ่มฟีเจอร์ใหม่
3. ทำการตรวจสอบ Feature View ที่ไม่ได้ถูกเรียกใช้งานเป็นระยะเวลาหนึ่งอย่างสม่ำเสมอ เพื่อดำเนินการลบหรือรวมเข้าด้วยกัน

ในเอกสารของผู้จำหน่าย (Vendor) เองก็ได้ระบุถึงแนวทางการดำเนินงานที่ควบคู่ไปกับการเลือกระหว่าง Build หรือ Buy โดยแนะนำว่าไม่ควรติดตั้งฟังก์ชันทั้งหมดตั้งแต่เริ่มต้น แต่ควรใช้วิธีการขยายขอบเขตแบบค่อยเป็นค่อยไปในรูปแบบ MVP การจัดลำดับความสำคัญโดยเพิ่มฟังก์ชันที่เกินขอบเขตที่กำหนดไว้ในขั้นตอนการกำหนดความต้องการ (Requirement Definition) หลังจากที่มีผลการใช้งานจริงปรากฏออกมาแล้ว จะเป็นเกณฑ์การตัดสินใจที่ช่วยควบคุมต้นทุนการดำเนินงานได้

ขอบเขตการประยุกต์ใช้งาน Feature Store นั้นกว้างไกลกว่าการจัดเตรียมข้อมูลสำหรับการอนุมาน (Inference) ของโมเดลเดี่ยว โดยจะขยายไปสู่ระดับที่หลายโมเดลและหลายทีมสามารถใช้โครงสร้างพื้นฐานของ Feature ร่วมกันได้ ซึ่งการใช้งานหลักมี 4 ประการ ดังนี้:

• การจัดเก็บบริบทของผู้ใช้และประวัติเซสชัน รวมถึงการอ้างอิงร่วมกันจากหลายโมเดล
• การจัดเก็บและส่งมอบ Embedding Vector เพื่อใช้เป็น Feature และนำไปประยุกต์ใช้กับการค้นหาความคล้ายคลึง (Similarity Search) โดยทำงานร่วมกับ Vector Database
• การนำ Feature View ที่มีอยู่เดิมกลับมาใช้ใหม่เมื่อมีการเพิ่มโมเดลใหม่ เพื่อหลีกเลี่ยงการทำ Feature Engineering ซ้ำ
• การจัดเตรียม Feature แบบเรียลไทม์ตามเงื่อนไขการทดสอบในการทำ Online A/B Testing

ในกรณีที่จัดการ Embedding Vector ในฐานะ Feature มีข้อกำหนดเบื้องต้นว่าห้ามนำ Vector ที่มาจากโมเดลต้นทางหรือหน่วย Chunk ที่แตกต่างกันมาปะปนกันใน Feature View เดียวกัน หากมีการอัปเดต Embedding ที่เปลี่ยนเงื่อนไขการสร้างโดยไม่มีการแยกแยะ จะส่งผลให้ความหมายของค่าที่ดึงมาในขณะอนุมานเปลี่ยนไปตามแต่ละโมเดล ซึ่งจะเพิ่มภาระในการตรวจสอบ Feature และโมเดลที่ไม่ได้ใช้งาน ทั้งนี้ ใน Feast ได้มีการพัฒนาส่วนขยายเพื่อรองรับการค้นหา Vector มากขึ้น ดังนั้น การกำหนดบทบาทหน้าที่ระหว่าง Feature Store และ Vector Database ให้ชัดเจนตั้งแต่ขั้นตอนการออกแบบ จึงเป็นเกณฑ์ตัดสินใจสำคัญในการขยายขอบเขตการใช้งานให้กว้างขวางยิ่งขึ้น

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

เราไม่ได้ตัดสินจากขนาดขององค์กร แต่ให้พิจารณาจากเงื่อนไข 3 ประการต่อไปนี้:

• มีโมเดลที่ใช้งานจริง (Production model) หลายตัว และมีการเพิ่มหรืออัปเดตอยู่บ่อยครั้ง
• มีหลายทีมที่ต่างคนต่างนำ Feature เดียวกันไปเขียนโค้ดใหม่ (Re-implement)
• มีข้อกำหนดทางธุรกิจที่ต้องการค่า Latency ต่ำในการประมวลผล (Inference)

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

Feature Store คือระบบที่ทำหน้าที่คำนวณและจัดเก็บ Feature พร้อมทั้งให้บริการ Feature เหล่านั้นสำหรับการเรียนรู้ (Training) และการอนุมาน (Inference) ด้วยตรรกะเดียวกัน ในขณะที่ Data Catalog เป็นกลไกสำหรับค้นหาและจัดการ Metadata ของสินทรัพย์ข้อมูล โดยไม่ได้มีหน้าที่ในการคำนวณหรือให้บริการข้อมูล เนื่องจากทั้งสองระบบมีบทบาทที่แตกต่างกัน การกำหนดค่าการทำงานร่วมกันเพื่อให้สามารถค้นหาข้อมูลนิยามของ Feature ได้จากฝั่ง Data Catalog จึงเป็นแนวทางปฏิบัติทั่วไปในการใช้งานจริง