- เมื่อ Generative AI ไม่ได้ทำงานบนข้อมูลที่เชื่อถือได้ ผลการวิเคราะห์ก็ยากจะเชื่อถือได้เช่นกัน ทำให้การจัดการข้อมูลยกระดับจากงานสนับสนุนด้านเทคนิคไปเป็น ความสามารถเชิงกลยุทธ์หลัก
- จากช่วงแรกที่นักพัฒนาแอปพลิเคชันรับผิดชอบถึงโครงสร้างข้อมูล บทบาทได้แยกออกเป็นผู้ออกแบบ/ผู้ดูแลฐานข้อมูล, CIO และ CDO โดยมีความถูกต้องสมบูรณ์ของข้อมูลและความเข้าใจที่สอดคล้องกันทั้งองค์กรเป็นโจทย์สำคัญ
- ในข้อมูลแบบมีโครงสร้างจะมีการแก้ไข data model และฐานข้อมูลโดยตรง แต่ในสภาพแวดล้อมของ Generative AI จะใช้ การควบคุมทางอ้อม โดยคัดเลือกและทำความสะอาดข้อความที่จะป้อนเข้า LLM
- สำหรับข้อความแบบไม่มีโครงสร้าง จำเป็นต้องใช้ ontology/taxonomy แทน data model แบบดั้งเดิม และต้องผสานเข้ากับ Enterprise Logical Data Model (ELDM) ขององค์กรพร้อมอัปเดตอย่างต่อเนื่อง
- เมื่อข้อมูลกระจายอยู่ในหลายระบบ, PC และอินเทอร์เน็ต การรวมศูนย์ทางกายภาพจึงเป็นไปไม่ได้อีกต่อไป และ การรวมศูนย์เชิงความหมาย ที่บูรณาการความหมายระดับองค์กรด้วย ELDM จึงยิ่งสำคัญ
การจัดการข้อมูลที่เริ่มต้นจากงานพัฒนาแอปพลิเคชัน
- ในระบบคอมพิวเตอร์ยุคแรก นักพัฒนาแอปพลิเคชันกำหนดทั้งข้อมูลที่ระบบจะใช้และโครงสร้างของมัน ควบคู่ไปกับการเก็บความต้องการ, การปฏิบัติตาม methodology, การเขียนโปรแกรม และการทดสอบ
- การออกแบบข้อมูลไม่ใช่หน้าที่อิสระในระดับองค์กร แต่เป็นหนึ่งในหลายงานที่รวมอยู่ในกระบวนการพัฒนา
การประมวลผลธุรกรรมและการเกิดขึ้นของบทบาทเฉพาะทางด้านฐานข้อมูล
- เมื่อระบบประมวลผลธุรกรรมแพร่หลายขึ้น การออกแบบฐานข้อมูลต้องสะท้อนเวลาในการตอบสนอง ความพร้อมใช้งานของระบบ และความถูกต้องสมบูรณ์ของการประมวลผลธุรกรรม
- เมื่อมี ผู้ออกแบบฐานข้อมูล ที่รับมือกับความต้องการเหล่านี้โดยเฉพาะ การจัดการข้อมูลจึงเริ่มถูกมองว่าเป็นงานอิสระ
- เมื่อฐานข้อมูลสำหรับระบบธุรกรรมเพิ่มขึ้นอย่างรวดเร็ว ก็จำเป็นต้องมี ผู้ดูแลฐานข้อมูล เพื่อควบคุมและประสานฐานข้อมูลจำนวนมาก
ปัญหาความถูกต้องสมบูรณ์ของข้อมูลและ data warehouse
- เมื่อองค์ประกอบข้อมูลเดียวกันถูกเก็บซ้ำในแอปพลิเคชันจำนวนมากที่เชื่อมโยงกัน ก็เกิดปัญหาที่แต่ละตำแหน่งมีค่าต่างกัน
- ปัญหาขององค์กรจึงเปลี่ยนจากการมีข้อมูล ไปเป็นการตัดสินใจว่าควรเชื่อข้อมูลใด
- การเพิ่มแอปพลิเคชันและเทคโนโลยีไม่ได้แก้ปัญหาความถูกต้องสมบูรณ์ กลับยิ่งขยายและเร่งปัญหา
- จึงจำเป็นต้องมี ทางออกเชิงสถาปัตยกรรม ที่แยกข้อมูลปฏิบัติการออกจากข้อมูลวิเคราะห์ ไม่ใช่เพียงการแก้ทางเทคนิค และนั่นนำไปสู่การเกิดขึ้นของ data warehouse
Data model และสภาพแวดล้อมข้อมูลแบบมีโครงสร้าง
- การแปลงข้อมูลปฏิบัติการไปเป็นข้อมูลวิเคราะห์และ data warehouse จำเป็นต้องมี data model ที่นามธรรมประเภทข้อมูลที่มีอยู่ในปัจจุบันหรือจะต้องใช้ในอนาคต
- ระบบปฏิบัติการและ data warehouse ประกอบด้วยสภาพแวดล้อมข้อมูลแบบมีโครงสร้าง ซึ่งรูปแบบของแต่ละเรกคอร์ดเหมือนกันและแตกต่างกันเฉพาะเนื้อหา
- ข้อมูลแบบมีโครงสร้างของแอปพลิเคชัน, ฐานข้อมูล และฐานข้อมูลสำหรับระบบธุรกรรม ถูกจัดการด้วยระบบจัดการฐานข้อมูล (DBMS)
- เมื่อความขัดข้องของระบบธุรกรรมส่งผลโดยตรงต่อการทำงานจริงและลูกค้า เช่น ATM และระบบจองตั๋วเครื่องบิน คุณค่าของระบบและการจัดการข้อมูลที่แม่นยำและเสถียรจึงสูงขึ้น
งานของผู้จัดการข้อมูลแบบมีโครงสร้าง
- หลังสร้าง data model แล้ว จะต้องบำรุงรักษาและแก้ไขอย่างต่อเนื่องให้สอดคล้องกับภาวะเศรษฐกิจ การแข่งขัน เทคโนโลยี กฎหมาย และการเปลี่ยนแปลงของตลาด
- ในการออกแบบฐานข้อมูล จะยึดตามหลัก normalization แต่ก็ใช้ denormalization ในระดับที่จำเป็นเพื่อประสิทธิภาพของการประมวลผลธุรกรรม
- ผู้จัดการข้อมูลต้องปรับสมดุลระหว่าง normalization และ denormalization ให้ตรงกับเป้าหมายของระบบและข้อกำหนดด้านประสิทธิภาพ
- เขียน DDL เพื่อกำหนดฐานข้อมูลตาม data model
- ทำ capacity planning เพื่อคาดการณ์ว่าอุปกรณ์สำหรับการประมวลผลธุรกรรมจะถึงขีดจำกัดเมื่อใด
- เฝ้าติดตามกิจกรรมของฐานข้อมูลและปริมาณข้อมูลที่เพิ่มขึ้นอย่างต่อเนื่อง
- เมื่อพบปัญหา จะใช้วิธี การควบคุมโดยตรง โดยเข้าถึงและแก้ไข data model หรือฐานข้อมูลนั้นโดยตรง
การขยายตัวของข้อมูลแบบไม่มีโครงสร้าง/ข้อความ
- ในองค์กรไม่ได้มีเพียงข้อมูลแบบมีโครงสร้าง แต่ยังมีข้อมูลแบบไม่มีโครงสร้าง/ข้อความอยู่เป็นวงกว้าง และยังมีการประเมินว่าข้อมูลขององค์กรอาจมากถึง 90% เป็นข้อความ
- เนื่องจากข้อมูลสำคัญขององค์กรจำนวนมากอยู่ในรูปข้อความ องค์กรด้านการจัดการข้อมูลจึงต้องดูแลสิ่งนี้ร่วมด้วย
- ข้อมูลแบบมีโครงสร้างและข้อมูลข้อความมีโครงสร้างและวิธีการจัดการที่แตกต่างกันโดยพื้นฐาน
ontology และ taxonomy ในสภาพแวดล้อมข้อความ
- ในสภาพแวดล้อมข้อความ การนำ structured data model แบบดั้งเดิมมาใช้ตรง ๆ ทำได้ยาก
- บทบาทที่ data model ทำในข้อมูลแบบมีโครงสร้างนั้น ในสภาพแวดล้อมข้อความจะเป็นหน้าที่ของ ontology/taxonomy
- แม้ทั้งสองโมเดลจะทำหน้าที่สอดคล้องกัน แต่โครงสร้างและเทคนิคการจัดการแตกต่างกันมาก
- การนำเทคนิคการทำ modeling และการจัดการข้อมูลแบบมีโครงสร้างมาใช้กับข้อความโดยตรงจึงไม่เหมาะสม และแทบไม่ให้ผลลัพธ์ที่เป็นรูปธรรม
การคัดเลือกและทำความสะอาดข้อความที่ป้อนเข้า LLM
- ในสภาพแวดล้อมของ Generative AI งานจัดการข้อมูลที่สำคัญที่สุดคือการตรวจสอบข้อความต้นฉบับก่อนจะเข้าสู่ LLM
- ต้องกำจัดข้อความที่ไม่จำเป็นและไม่เกี่ยวข้องกับงานขององค์กร เพื่อไม่ให้ไหลเข้าสู่ LLM
- เมื่อกำจัดข้อความที่ไม่จำเป็นออก ปริมาณข้อมูลที่ต้องประมวลผลทุกครั้งที่รันคิวรีจะลดลง ทำให้ ลดต้นทุน ได้
- เมื่อเหลือเฉพาะข้อความที่เกี่ยวข้องกับงาน ขอบเขตที่ LLM จะใช้แสดงและจัดการก็จะชัดเจนขึ้น
ELDM และการเชื่อมข้อมูลแบบมีโครงสร้าง/ไม่มีโครงสร้าง
- ผู้จัดการข้อมูลในสภาพแวดล้อมของ Generative AI ต้องผสาน ontology/taxonomy เข้ากับ ELDM (Enterprise Logical Data Model) ของทั้งองค์กร
- ELDM ใช้เพื่อบูรณาการ data model แบบมีโครงสร้างดั้งเดิมเข้ากับ ontology/taxonomy ของสภาพแวดล้อมข้อความ
- เมื่อความต้องการทางธุรกิจขององค์กรเปลี่ยนไป ontology/taxonomy ก็ต้องอัปเดตตามไปด้วย
การรวบรวมข้อความภายนอกและการบำรุงรักษาอย่างต่อเนื่อง
- ก่อนอื่นต้องคัดเลือกข้อความต้นฉบับจากแหล่งต่าง ๆ อย่างอินเทอร์เน็ตในวงกว้าง
- จากนั้นจึงเข้าสู่กระบวนการคัดกรอง 2 ขั้น โดยคัดเลือกข้อมูลที่เกี่ยวข้องกับงานขององค์กรอีกครั้งจากข้อความที่เลือกมาแล้ว
- เนื่องจากสภาพแวดล้อมการทำงานและสถานการณ์ของโลกเปลี่ยนแปลงอยู่เสมอ จึงต้องเฝ้าติดตามและจัดการ ontology/taxonomy อย่างต่อเนื่อง
- จำเป็นต้องมีการบำรุงรักษาแบบวนซ้ำ เพื่อให้เงื่อนไขที่เปลี่ยนไปและระบบการจัดหมวดหมู่สอดคล้องกัน
การควบคุม LLM แบบอ้อม
- ผู้จัดการข้อมูลแบบมีโครงสร้างสามารถเปลี่ยน data model และฐานข้อมูลได้โดยตรง แต่ในสภาพแวดล้อมของ Generative AI ไม่สามารถควบคุมตัว LLM เองโดยตรงในแบบเดียวกันได้
- วิธีควบคุมผลลัพธ์ของ Generative AI คือ การจัดการว่าจะป้อนข้อความใดเข้า LLM
- ดังนั้น การจัดการข้อมูลสำหรับ Generative AI จึงใกล้เคียงกับการควบคุมทางอ้อมผ่านการคัดเลือกและทำความสะอาดข้อมูลนำเข้า มากกว่าการแก้ไขโดยตรง
การเปลี่ยนแปลงของบทบาทการจัดการข้อมูลในองค์กร
- ในช่วงแรก การจัดการข้อมูลเป็นเพียงหนึ่งในหลายงานที่นักพัฒนาระบบทำ และยังไม่มีหน่วยงานหรือหน้าที่เฉพาะในองค์กร
- เมื่อการประมวลผลธุรกรรมมีความสำคัญมากขึ้น การออกแบบฐานข้อมูลจึงแยกออกเป็นงานอิสระ และเกิดบทบาทผู้ออกแบบฐานข้อมูล
- เมื่อฐานข้อมูลเพิ่มขึ้นอย่างรวดเร็วและจำนวนองค์ประกอบข้อมูลที่ต้องจัดการมากขึ้น บทบาทผู้ดูแลฐานข้อมูลก็ขยายตัว
- เมื่อปัญหาข้อมูลจากหลายระบบไม่สอดคล้องกันรุนแรงขึ้น จึงเกิดบทบาท CIO (Chief Information Officer) ที่รับผิดชอบการบูรณาการข้อมูลในระดับองค์กร
- เมื่อเกิดความจำเป็นในการบูรณาการข้อมูลแบบมีโครงสร้างและข้อมูลข้อความเพื่อทำความเข้าใจข้อมูลทั้งองค์กรในภาพรวม บทบาทจึงพัฒนาไปเป็น CDO (Chief Data Officer)
- ยิ่งรูปแบบของข้อมูลหลากหลายมากขึ้น ความซับซ้อนและความสำคัญของการจัดการ ตลอดจนโอกาสในการใช้งานและความท้าทาย ก็ยิ่งเพิ่มขึ้นตามไปด้วย
จากการรวมศูนย์ทางกายภาพสู่การรวมศูนย์เชิงความหมาย
- หากต้องการเข้าใจข้อมูลและความหมายของมันอย่างสอดคล้องกันทั้งองค์กร ก็จำเป็นต้องมีระบบความเข้าใจข้อมูลแบบรวมศูนย์
- ในการประมวลผลยุคแรก การรวมศูนย์หมายถึง การรวมศูนย์ทางกายภาพ โดยรวบรวมฐานข้อมูลไว้บนเมนเฟรมขนาดใหญ่
- ต่อมาเมื่อข้อมูลกระจายไปยังหลายตำแหน่ง เช่น คอมพิวเตอร์ส่วนบุคคล อินเทอร์เน็ต และระบบขององค์กร การรวมศูนย์ทางกายภาพจึงเป็นไปไม่ได้อีกต่อไป
- ยิ่งข้อมูลกระจายตัวมากขึ้น ความจำเป็นในการทำให้เข้าใจสิ่งเดียวกันด้วยความหมายเดียวกัน ทั้งบนอินเทอร์เน็ตและภายในองค์กรก็ยิ่งมากขึ้น
- เป้าหมายของการรวมศูนย์จึงย้ายจากตำแหน่งที่เก็บข้อมูล ไปสู่ ความหมายและคำจำกัดความ ของข้อมูล
- ELDM ถูกใช้เป็นวิธีรักษาความหมายข้อมูลร่วมกันในระดับองค์กรจากศูนย์กลาง แม้ว่าข้อมูลจะอยู่ในหลายตำแหน่งทางกายภาพก็ตาม
ยังไม่มีความคิดเห็น