จาก data lakehouse สู่โครงสร้างที่เข้าใจ AI agents
AI agents ระบบข้อมูลหมายถึงสถาปัตยกรรมระบบข้อมูลและเครื่องมือที่ออกแบบมาให้ตัว agent ซึ่งมักเป็นโมเดลภาษาขนาดใหญ่สามารถวางแผน ใช้เครื่องมือ วิเคราะห์ข้อมูล และเขียนผลลัพธ์กลับเข้าสู่ระบบได้แบบกึ่งอัตโนมัติหรืออัตโนมัติเต็มรูปโดยไม่ต้องพึ่งการตัดสินใจของมนุษย์ในทุกขั้น แต่ยังคงระเบียบ กฎเกณฑ์ และความสามารถในการตรวจสอบย้อนกลับของการตัดสินใจและการเปลี่ยนแปลงข้อมูล ปัญหาคือ data lakehouse แบบเหรียญ Bronze Silver Gold ที่เราเคยภูมิใจว่าสร้างเพื่อให้ทีม BI ใช้งานได้สบาย ถูกออกแบบเพื่อคำถามยุคมนุษย์เป็นคนเปิดรายงาน ไม่ใช่ยุคที่ agent วางแผนเองและลงมือเปลี่ยนข้อมูลในระบบ เมื่อให้ agent ต่อ SQL ไปยังชั้น Gold แล้วปล่อยให้มันถามเอง หลายองค์กรเริ่มพบภาพหลอนของตัวเลขและเมตริกที่ไม่มีอยู่จริง นี่ไม่ใช่ความผิดของโมเดลอย่างเดียว แต่สะท้อนว่าโครงสร้างระบบข้อมูลเดิมไม่เคยเตรียมไว้สำหรับผู้บริโภคแบบใหม่อย่าง AI agents
lakehouse เดิมเกิดมาเพื่อคน ไม่ใช่เพื่อ agent
หัวใจของ data lakehouse ยุคเดิมคือสมมติฐานว่าปลายทางของทุกคำขอคือคน มีคนเปิดเครื่องมือ BI มีคนตั้งเวลา job แปลงข้อมูล มีคนเลือกว่ารายงานไหนต้องอัปเดตเช้านี้ และแม้ระบบ streaming ผ่าน Kafka ลงตาราง Delta ก็ยังเชื่อว่ามนุษย์จะเป็นผู้ตีความผลลัพธ์ในท้ายที่สุด สถาปัตยกรรมแบบนี้จึงไหลเชิงเส้นจากแหล่งข้อมูลดิบไปสู่ข้อมูลที่สะอาดขึ้นเรื่อยๆ เพื่อให้คนดูได้สะดวก การกำกับดูแลอยู่ข้างท่อในรูปแบบแคตตาล็อกและนโยบายสิทธิ์ ไม่ใช่เป็นส่วนหนึ่งของการตัดสินใจกลางทาง และสำคัญที่สุด ระบบไม่ได้ตัดสินใจอะไรเลย มันแค่ขนข้อมูล การตัดสินใจอยู่ในหัวคนตั้งแต่ก่อน pipeline จะรัน เมื่อผู้บริโภคกลายเป็น agent ที่ต้องตัดสินใจเองว่าตัวเลขไหนน่าเชื่อถือพอจะเอาไปใช้ ระบบแบบนี้จึงเริ่มสั่นคลอน เพราะมันไม่มีบริบท กฎ และจุดตรวจสอบที่ agent ต้องใช้ในการตัดสินใจอัตโนมัติแบบปลอดภัย
ทำไม AI agents ต้องการ semantic layer และบริบทมากกว่าที่เคย
การให้ AI agents วิ่งคำสั่ง SQL ตรงไปยังชั้น Gold อาจเวิร์กตอนเดโม แต่จะแตกทันทีที่มีสองตารางนิยามคำว่า ลูกค้าที่ใช้งานอยู่ ต่างกัน ซึ่งแทบทุกคลังข้อมูลองค์กรเป็นแบบนั้น เมื่อไม่มี semantic layer architecture ที่บังคับใช้จริง agent จะเอานิยามที่ต่างกันมาเฉลี่ยรวมกันอย่างมั่นใจและรายงานผลราวกับเป็นความจริง นี่อันตรายยิ่งกว่าคนตีความผิด เพราะมันดูถูกต้องและทำซ้ำได้โดยไม่มีใครสังเกต ดังนั้นแพลตฟอร์มยุค data lakehouse AI ต้องมีอย่างน้อยสามสิ่งที่ lakehouse เดิมมองเป็นของแถม หนึ่ง semantic layer ที่ไม่ได้อยู่แค่ใน wiki ที่ไม่มีใครอ่าน แต่ผูกกับการเข้าถึงและการคิวรีให้ agent ใช้คำจำกัดความเดียวกันเสมอ สอง context store เช่นเวกเตอร์ที่เก็บเอกสาร ความเป็นมาของข้อมูล และการตัดสินใจก่อนหน้า เพื่อให้ agent ดึงบริบทเหล่านี้มาใช้แทนการเดาจากชื่อคอลัมน์ล้วนๆ หากองค์กรปวดหัวแค่แดชบอร์ดค้าง การลงทุนใน semantic layer ดีๆ ยังสำคัญกว่าการสร้าง agent mesh ซับซ้อน
ควบคุมเครื่องมือ agentic data analysis ด้วยกราฟการทำงานและ dependency ที่ชัดเจน
โลกของ agentic data analysis กำลังเติบโต เพราะคนหลากหลายวัยที่รู้เรื่อง LLM เล็กน้อยอยากวิเคราะห์ข้อมูลโดยไม่เขียนโค้ดจึงหันมาใช้เครื่องมือแบบ agentic ที่ให้โมเดลตรวจสอบข้อมูล ติดตั้งไลบรารี เขียนสคริปต์ แก้ปัญหา และสร้างผลวิเคราะห์จากคำสั่งผู้ใช้ แต่ทุกคำขอคือการสุ่มสร้างข้อความและโค้ดชุดใหม่ แม้จะเป็นงานเดิม ทำให้ความสามารถในการทำซ้ำและซ้ำใช้ workflow เดิมพังลงพร้อมกับค่าใช้จ่ายที่พุ่งขึ้น แนวทางแบบ skill ลดการคิดซ้ำโดยแพ็กคำแนะนำและสคริปต์ไว้ แต่ยังไม่พอ เพราะมันอธิบายเจตนาของ workflow มากกว่าระบุกราฟการทำงานที่แน่นอน เช่น โหลดข้อมูล ตรวจสอบ แปลง วิเคราะห์ และสร้างผลลัพธ์ ยังไม่เท่ากับการประกาศลำดับขั้น อินพุต เอาต์พุต และเงื่อนไขการแตกแขนงอย่างเป็นทางการ ข้อเสนอ recipe.md จึงเน้นให้มีกราฟการทำงานแบบกำหนดแน่ชัด พร้อมประกาศ dependency ที่เป็นข้อบังคับไม่ใช่ทางเลือก เพื่อให้ทุกครั้งที่ agent รันงานเดียวกันได้ผลลัพธ์ที่เข้าใจได้ ตรวจสอบได้ และใกล้เคียงกันทุกครั้ง
การกำกับดูแลเครื่องมือและวงจร feedback คือหัวใจของ data lakehouse AI
เมื่อปล่อยให้ AI agents ทำงานในระบบข้อมูลองค์กร เราไม่สามารถปล่อยให้มันยิงคิวรีใส่ storage ดิบแบบไร้ขอบเขตได้ แพลตฟอร์มต้องมีชั้นเครื่องมือที่คั่นกลาง ให้ agent เรียกใช้ action ที่นิยามไว้ ไม่ใช่สั่งอะไรก็ได้ลงฐานข้อมูล นี่เป็นทั้งเรื่องการกำกับดูแลและความปลอดภัย เราไม่ควรมี process อัตโนมัติที่มีสิทธิ์เขียนข้อมูลลงตาราง production โดยไม่มีการควบคุม อีกส่วนที่หลายองค์กรมองข้ามคือ feedback loop เมื่อ agent ตรวจพบความผิดปกติหรือแก้ค่าที่ผิด การแก้นั้นต้องไหลกลับเข้าสู่แพลตฟอร์ม ไม่ใช่หายไปในประวัติแชต แนวทางที่ใช้อยู่คือจุดตรวจ human in the loop ซึ่งทำหน้าที่เป็นด่านตรวจสอบงานที่กลับไม่ได้หรือมีต้นทุนสูง ก่อนอนุมัติให้ agent ดำเนินการต่อจริง น่าสังเกตว่าโครงสร้าง Bronze Silver Gold ยังมีประโยชน์อยู่ใต้สถาปัตยกรรมทั้งหมดนี้ แต่หากยังคิดถึง lakehouse แค่เป็นท่อข้อมูลสำหรับคนดูรายงาน เราจะไม่มีวันสร้างระบบที่รองรับ AI agents ได้อย่างปลอดภัยและมีความหมายในเชิงธุรกิจ
