- จากประสบการณ์ในการสร้าง Pandas และ Apache Arrow เขามองว่า แม้ในยุค AI ความเชี่ยวชาญ วิจารณญาณ และรสนิยม ในการออกแบบระบบข้อมูลและซอฟต์แวร์ประสิทธิภาพสูงก็ยังเป็นหัวใจสำคัญ
- Apache Arrow คือ เลเยอร์ in-memory แบบทั่วไป สำหรับข้อมูลเชิงตาราง ที่ช่วยทำให้การส่งผ่านและประมวลผลระหว่างระบบเป็นมาตรฐาน และยิ่งมีระบบนำไปใช้มากเท่าไร คุณค่าด้านการทำงานร่วมกันก็ยิ่งสูงขึ้น
- ระบบที่ซับซ้อนอย่าง DuckDB และ DataFusion เป็นสิ่งที่แทนที่ได้ยากด้วยการสร้างโค้ดแบบเฉลี่ย ๆ จาก LLM เพียงอย่างเดียว และความสามารถในการแข่งขันของโอเพนซอร์สไม่ได้มีแค่โค้ด แต่รวมถึง ความเชื่อถือและประวัติคุณภาพ ที่สั่งสมมายาวนานด้วย
- เครื่องมือ AI ช่วยเพิ่มผลิตภาพให้กับนักพัฒนาที่มีความเป็นผู้นำในการขับเคลื่อนงานสูงได้มาก แต่ถ้ายังไม่ชัดเจนว่าจะสร้างอะไร ก็อาจเกิด หล่มของเอเจนต์ (agentic tarpit) ที่เต็มไปด้วยวิธีแก้และโค้ดแบบกลาง ๆ จนแม้แต่เอเจนต์ก็ยากจะหลุดออกมาได้
- ต่อจากนี้ ความสำคัญจะย้ายจากไวยากรณ์ภาษาและการเขียนโค้ดด้วยมือ ไปสู่สถาปัตยกรรม การนิยามปัญหา การสื่อสาร และความสามารถในการตัดสินผลลัพธ์ ขณะที่องค์กรก็ต้องจัดการทั้ง ภาระการตัดสินใจที่เพิ่มขึ้นและต้นทุนโทเค็น ด้วย
เส้นทางอาชีพจาก Pandas สู่เครื่องมือพัฒนา AI
- Wes McKinney สร้าง Python Pandas ขึ้นเมื่อราว 18 ปีก่อน และเปิดเป็นโอเพนซอร์สในปี 2010
- หนังสือ
Python for Data Analysisของเขาถูกใช้อย่างแพร่หลายในระบบนิเวศ data science ของ Python และต่อมาเขาก็เข้าไปมีส่วนร่วมในการสร้างบริษัทและโมเดลธุรกิจที่ช่วยให้การพัฒนาโอเพนซอร์สดำเนินต่อได้ - เขาเริ่มต้น Apache Arrow ที่ Cloudera ร่วมกับนักพัฒนาโอเพนซอร์สหลายคน และยังมีส่วนเกี่ยวข้องกับระบบนิเวศ Arrow และการพัฒนา Parquet
- Ursa Computing ต่อมากลายเป็น Voltron Data และหลังจาก Voltron Data ถูกปิดไป เขาก็ยังคงมีความสัมพันธ์กับ Posit
- ปัจจุบันเขาก่อตั้งบริษัทใหม่ที่มุ่งเน้น เครื่องมือและโครงสร้างพื้นฐานสำหรับนักพัฒนา AI มากกว่าการสร้างไลบรารี data science เพื่อสำรวจวิธีเพิ่มผลิตภาพวิศวกรรมซอฟต์แวร์ด้วย AI
เส้นทางการแพร่หลายของ Apache Arrow
- Arrow คือ เลเยอร์พื้นฐานข้อมูล in-memory แบบทั่วไปสำหรับข้อมูลเชิงตาราง ที่ช่วยให้การประมวลผลในหน่วยความจำและการส่งข้อมูลระหว่างระบบทำได้รวดเร็วขึ้น พร้อมเพิ่มความสามารถในการทำงานร่วมกัน
- ในช่วงแรกมีผู้ใช้และระบบปลายทางรองรับน้อย จึงมีแรงจูงใจในการนำไปใช้น้อย และยังมีความสงสัยว่าชุมชนโอเพนซอร์สหลายแห่งจะตกลงใช้ฟอร์แมตเดียวกันได้ยาก
- เมื่อสร้างมาตรฐานรวมใหม่ ก็มักเจอปัญหาแบบ XKCD ที่จากเดิมมีมาตรฐาน 13 แบบ กลายเป็น 14 แบบ
- Arrow เติบโตด้วยการนำเสนอ implementation ที่เสถียรในช่วงที่แทบไม่มีทางเลือกที่น่าเชื่อถืออื่นสำหรับแก้ปัญหาเดียวกัน แล้วรอให้เกิดการยอมรับ
- ตัวเทคโนโลยีเองแทบไม่ได้เปลี่ยนไปมากในช่วง 5~6 ปีที่ผ่านมา แต่เมื่อมีระบบนำไปใช้เพิ่มขึ้น มูลค่าก็เพิ่มขึ้นในลักษณะใกล้เคียงกับ network effect
- DataFusion ช่วยให้สามารถขยาย query engine ให้เหมาะกับผลิตภัณฑ์ได้โดยไม่ต้องสร้างใหม่ทั้งหมดตั้งแต่ต้น และคาดว่ามีบริษัทประมาณ 30~40 แห่งใช้เป็นองค์ประกอบภายใน
- Arroyo ซึ่งเคยสร้าง streaming data engine ถูก Cloudflare เข้าซื้อ และหลังจากนั้น Arrow กับ DataFusion ก็ถูกใช้เป็นส่วนหนึ่งของโครงสร้างพื้นฐานข้อมูลสตรีมมิงของ Cloudflare
- DataFusion Comet ถูกนำไปใช้เพื่อเร่งความเร็ว Spark
ซอฟต์แวร์ระบบที่ AI ยังแทนได้ยาก
- DataFusion และ DuckDB เป็นโครงการประเภทที่ยากจะสร้างตัวแทนขึ้นมาอย่างรวดเร็วด้วย vibe coding
- LLM มีแนวโน้มที่จะเฉลี่ยโค้ดและแนวทางที่มีอยู่เดิม จึงยากที่จะสร้างระบบที่ผู้เชี่ยวชาญออกแบบอย่างพิถีพิถัน เช่น query engine ระดับแนวหน้า ได้ในระยะเวลาอันใกล้
- โครงการแบบนี้ใกล้เคียงกับ นาฬิกาสวิสความแม่นยำสูง ที่ช่างฝีมือประกอบขึ้น มากกว่าของเล่นพลาสติกที่ผลิตด้วยการฉีดขึ้นรูป
- ไม่ได้แปลว่า AI จะสร้างไม่ได้ตลอดไป แต่ในตอนนี้โอกาสที่จะทดแทนได้ยังต่ำ
- มูลค่าของโครงการโอเพนซอร์สไม่ได้มาจากตัว implementation เท่านั้น แต่ยังมาจากความไว้วางใจที่ชุมชนสะสมมานาน
- ความเชื่อว่าผู้ดูแลโครงการจะคำนึงถึงประโยชน์ของชุมชน
- ความคาดหวังว่าจะป้องกัน supply-chain attack และแก้บั๊กร้ายแรงได้
- ประวัติการส่งมอบซอฟต์แวร์ที่ออกแบบดีและเชื่อถือได้อย่างสม่ำเสมอ
- McKinney ไม่ได้มีส่วนร่วมอย่างลึกซึ้งกับการพัฒนา Pandas มาตั้งแต่ปี 2013 และปัจจุบันโครงการนี้ดูแลโดยกลุ่มนักพัฒนาขนาดใหญ่
- ดังนั้นเขาจึงเห็นว่าคำขอบคุณและการสนับสนุนควรไปถึงผู้ดูแลตัวจริง
- ต่อให้ AI สร้างโค้ดได้วันละ 10,000 บรรทัด ก็ไม่สามารถเผยแพร่ผลงานที่คุณภาพต่ำกว่ามาตรฐานที่สะสมมาในอดีตได้ ทำให้โจทย์ที่สำคัญกว่าปริมาณการสร้างคือ การรีวิวและการรักษาคุณภาพ
จากเกมและคณิตศาสตร์สู่การเขียนโปรแกรม
- ช่วงปลายทศวรรษ 1990 เขาหลงใหล
GoldenEye 007บน Nintendo 64 และเข้าร่วมชุมชนแข่งทำเวลา หลังจากสร้างแฟนไซต์บน GeoCities ในช่วงปลายปี 1997 หรือต้นปี 1998 - ตอนนั้นเขาดูแลเว็บไซต์ด้วยมือ แต่เมื่อเห็น Kisman ซึ่งเก่งด้าน competitive programming ใช้โปรแกรม C++ อัตโนมัติในการอัปเดตเว็บ เขาก็ได้เห็น พลังของระบบอัตโนมัติ ที่สร้างโดยโปรแกรมเมอร์ฝีมือดี
- ตอนมัธยมเขาสนใจการแข่งขันคณิตศาสตร์และการใช้คอมพิวเตอร์ และเมื่อเข้าเรียนที่ MIT ก็รู้สึกถึงช่องว่างด้านทักษะอย่างมากเมื่อเทียบกับเพื่อนที่เขียนโปรแกรมมาตั้งแต่เด็ก
- เขาจบปริญญาด้านคณิตศาสตร์บริสุทธิ์และได้เรียนวิทยาการคอมพิวเตอร์เชิงทฤษฎีบางส่วน เช่น complexity และ algorithm แต่เพราะประสบการณ์เชิงลบกับ Java จึงยังไม่รู้สึกสนใจการเขียนโปรแกรมมากนัก
- เขาเริ่มทุ่มเทอย่างจริงจังก็ต่อเมื่อมองว่าการเขียนโปรแกรมคือเครื่องมือสำหรับแก้ปัญหาและขยายผลิตภาพส่วนบุคคล
Pandas ที่เริ่มต้นจากงานวิจัยการเงิน
- ในปี 2007 ตอนอายุ 22 เขาเข้าทำงานที่กองทุนเฮดจ์ฟันด์สาย quant และพบว่างานวิเคราะห์จำนวนมากไม่ได้ขับเคลื่อนด้วยสมการอย่างที่คาด แต่พึ่งพา สเปรดชีต Excel และงานทำมือ อย่างมาก
- มีการใช้ MATLAB และ R ด้วย แต่เป็นเพียงเครื่องมือเสริม และหากต้อง deploy โค้ด MATLAB ไปยังเซิร์ฟเวอร์ก็ต้องซื้อไลเซนส์ราคาแพงแยกตามแต่ละเครื่อง
- เขาจึงเห็นว่าจำเป็นต้องมีภาษาโอเพนซอร์สที่เหมาะกับการสร้างระบบสำหรับงานตั้งแต่งานวิจัยไปจนถึง production
- ด้วยคำแนะนำจากเพื่อนร่วมงาน เขาเริ่มใช้ Python และไลบรารี scientific computing ในช่วงต้นปี 2008 และระหว่างสร้างเครื่องมือวิจัยเดิมขึ้นใหม่ด้วย Python ก็เริ่มปรากฏ รูปร่างแรกเริ่มของ Pandas
- เขารู้สึกหลงใหลแบบเดียวกับการแข่งทำเวลาในเกม จากการสร้างเครื่องมือที่ช่วยเพิ่มผลิตภาพและได้เห็นคนอื่นทำงานได้มีประสิทธิภาพขึ้นด้วยเครื่องมือนั้น
ประสบการณ์ใช้งานที่เรียบง่ายกับหนี้เทคนิคภายใน
- McKinney ให้ความสำคัญกับ เครื่องมือที่เรียบง่ายและสม่ำเสมอ ซึ่งคนอื่นสามารถเข้าใจและใช้งานได้ มากกว่าเครื่องมือ AI ที่ซับซ้อนและเหมาะกับคนใดคนหนึ่งเท่านั้น
- ชุดเครื่องมือที่ปรับแต่งเฉพาะตัวมากเกินไปอาจกลายเป็นโครงสร้างซับซ้อนแบบ Winchester Mystery House ที่ไม่มีใครนอกจากผู้สร้างเองสำรวจได้
- implementation แรก ๆ ของ Pandas มุ่งไปที่ API และการใช้งานที่มนุษย์เข้าใจและเขียนได้ง่าย มากกว่าสถาปัตยกรรมภายใน
- แม้ความยุ่งเหยิงภายในจะกลายเป็นภาระการดูแลรักษาในระยะยาว แต่ความสำเร็จของ Pandas ก็แสดงให้เห็นว่าซอฟต์แวร์ไม่จำเป็นต้องมีสถาปัตยกรรมสมบูรณ์แบบเสมอไปจึงจะประสบความสำเร็จอย่างมากได้
บทบาทและข้อจำกัดของ NumPy
- NumPy เกิดจากการที่ Travis Oliphant รวมสายของ Numeric ซึ่งเป็นไลบรารีอาร์เรย์หลายมิติที่ Jim Hugunin เริ่มในช่วงกลางทศวรรษ 1990 เข้ากับสายของ Numarray ที่เพิ่มความสามารถด้านอาร์เรย์ขนาดใหญ่ เช่น memory mapping ในช่วงราวปี 2005~2006
- ในเวลานั้น Matplotlib, SciPy รวมถึงเครื่องมือด้านสถิติและ linear regression ต่างทำงานบนอาร์เรย์ของ NumPy ดังนั้นหากเครื่องมือข้อมูลใหม่จะเข้าร่วมในระบบนิเวศได้ ก็จำเป็นต้อง เข้ากันได้กับ NumPy
- NumPy มุ่งเน้นอาร์เรย์หลายมิติขนาดใหญ่ของค่าตัวเลขและจำนวนเต็ม และไม่ได้ถูกออกแบบให้เป็นฐานสำหรับฐานข้อมูลหรือข้อมูลที่ไม่ใช่ตัวเลข
- Pandas ยุคแรกจึงอาศัย NumPy เป็นฐานและหลบเลี่ยงข้อจำกัดของข้อมูลที่ไม่ใช่ตัวเลข
- ค่าที่ไม่ใช่ตัวเลขหรือบูลีนจะถูกเก็บเป็น Python object ภายในอาร์เรย์ของ NumPy
- ข้อมูลสตริงมี overhead ของ object และการอ้างอิงทางอ้อม ทำให้ไม่มีประสิทธิภาพนัก
- ข้อจำกัดเหล่านี้กลายมาเป็นแรงจูงใจในการสร้าง Arrow ซึ่งเป็นพื้นฐาน in-memory ทางเลือกสำหรับระบบอย่าง Pandas ในเวลาต่อมา
การเติบโตของระบบนิเวศ data science บน Python
- มีเงินลงทุนจำนวนมากไหลเข้าสู่โครงการโอเพนซอร์สบิ๊กดาต้า หลังจากหลายบริษัทที่ได้รับเงิน venture capital โฆษณาว่าทุกองค์กรควรสร้างโครงสร้างพื้นฐานข้อมูลแบบเดียวกับ Google
- แม้ไม่ใช่ทุกบริษัทที่ต้องการโครงสร้างพื้นฐานขนาดนั้น แต่หากไม่มีเงินทุนเหล่านี้ ก็อาจยากกว่ามากที่จะรวบรวมนักพัฒนาที่จำเป็นต่อ Arrow
- ในเวลานั้นอุตสาหกรรมแข่งขันกันทั้งในเรื่องความหมายของ data science และ data scientist รวมถึงการหา人才ที่มีทั้งทักษะธุรกิจ สถิติ และซอฟต์แวร์
- Python ทำให้คนที่ไม่ได้มีประสบการณ์เขียนโปรแกรมมาก แต่มีพื้นฐานสถิติ สามารถเข้าถึง data science ได้
- หากเรียน
Python for Data Analysisและเครื่องมืออย่าง scikit-learn ก็สามารถเริ่มทำงานวิเคราะห์ที่เป็นประโยชน์ต่องานได้ภายใน 2~3 สัปดาห์ - หากต้องเริ่มจากการเรียนภาษาอย่าง Scala ก่อน เขามองว่าอุปสรรคในการเริ่มต้นจะสูงกว่าและใช้เวลาเรียนรู้นานกว่า
- หากเรียน
การเปิดตัว Pandas และการก่อตัวขององค์กร Arrow
- มีการตัดสินใจเปิดตัว Pandas ในคืนก่อนวันขึ้นปีใหม่ 2009 และจุดที่เชื่อมต่อกับชุมชน Python อย่างจริงจังคือการนำเสนอครั้งแรกในงาน PyCon เดือนกุมภาพันธ์ 2010
- McKinney เริ่มเรียนปริญญาเอกด้านสถิติที่ Duke ในปี 2010 แต่ตัดสินใจพักเรียนเมื่อเห็นความสนใจจากบริษัทการเงินต่อเครื่องมือข้อมูลของ Python และเห็นศักยภาพการเติบโตของ Pandas
- ตอนนั้น Pandas 0.1 ยังมีฟีเจอร์จำกัดมาก ถึงขั้นยังรองรับ join ได้ไม่ครบทุกประเภท และเขาก็ออกจากบัณฑิตศึกษาเพื่อโฟกัสกับการเติบโตของโครงการ
- หลังจากพิจารณาธุรกิจด้านการเงินเทค เขาก็เขียน
Python for Data Analysisและร่วมก่อตั้ง BI startup ก่อนจะเข้าร่วม Cloudera ในปี 2013 เมื่อเห็นว่ายากจะแข่งขันกับ Looker ในตลาด BI - ที่ Cloudera เขาได้เชื่อมต่อกับนักพัฒนา Impala และพบกับวิศวกรหลายคนที่ต่อมาไปทำงานกับ Iceberg และ Databricks ซึ่งประสบการณ์นี้กลายเป็นฐานสำคัญของเส้นทางอาชีพถัดมา
- โครงการ Arrow เริ่มขึ้นที่ Cloudera ในช่วงต้นปี 2016 แต่ในตลาด enterprise software ตอนนั้น การขออนุมัติงบทีมเฉพาะสำหรับเทคโนโลยีเชิงทดลองเป็นเรื่องยาก
- ช่วงปี 2016~2018 เขานำ Arrow ไปใช้จริงในบริษัทการเงินเพื่อเร่งความเร็ว workload การประมวลผลข้อมูล และปรับปรุง Parquet
- ในปี 2018 หลายบริษัทต้องการสนับสนุนงบเพื่อพัฒนา Arrow แต่ข้อกำหนดของบริษัทการเงินทำให้จัดการเงินจากภายนอกได้ยาก จึงก่อตั้งองค์กรอิสระที่รับการสนับสนุนจากบริษัทได้ในเดือนเมษายน
- มีผู้สนับสนุนราว 6 ราย รวมถึงบริษัทฮาร์ดแวร์อย่าง Nvidia และบริษัทการเงิน
- มีการจัดตั้งทีมพัฒนาราว 8 คน
- หลังยืนยันโอกาสเชิงพาณิชย์ได้แล้ว เขาจึงเปลี่ยนผ่านสู่ Ursa Computing ในช่วงการระบาดของโควิด-19 ปี 2020
ปัญหาด้าน data engineering ที่ยังคงอยู่
- แม้ในปัจจุบัน วงการข้อมูลก็ยังคงแก้ปัญหาเดิมซ้ำ ๆ คือการย้ายข้อมูลจาก A ไป B การแปลงฟอร์แมต การโหลดเข้าหน่วยความจำ และการรัน query กับ transformation อย่างมีประสิทธิภาพ
- Pandas กลายเป็นฐานรองรับ data flow ขององค์กรจำนวนมากเกินกว่าที่คาดไว้ และตอนนี้ก็อาจมีความเป็นไปได้ว่า LLM สร้างโค้ด Pandas มากกว่าปริมาณที่มนุษย์เคยเขียนไว้ในอดีต
- DuckDB เป็นเครื่องมือที่ทรงพลังถึงระดับที่นักพัฒนาเมื่อ 20 ปีก่อนคงจินตนาการได้ยาก
- ติดตั้งได้ฟรีและรันได้ในสภาพแวดล้อมหลากหลาย
- ทำงานได้ทั้งบนโทรศัพท์และในเว็บเบราว์เซอร์
- ให้การวิเคราะห์ประสิทธิภาพสูงบนเครื่องเดียวโดยไม่ต้องตั้งค่าซับซ้อน
- จากความไม่สะดวกและการลองผิดลองถูกยาวนาน ทำให้ความจำเป็นของเทคโนโลยีอย่าง DuckDB และ Arrow ชัดเจนขึ้น และหลายแนวทางรวมถึง Parquet ก็ได้รับอิทธิพลจากเทคโนโลยีที่บริษัทอินเทอร์เน็ตรายใหญ่อย่าง Google สร้างขึ้นเพื่อลดต้นทุนและเวลา
- Parquet อาจไม่ใช่ฟอร์แมตที่ดีที่สุด แต่ก็ดีกว่าในอดีตมากและแทบทุกระบบรองรับ
- แม้จะมีทางเลือกเฉพาะทางอย่าง Vortex และ Lance แต่ก็ยังถูกใช้อย่างต่อเนื่องเพราะ ความเข้ากันได้ที่ดีพอ
- เมื่อ AI เข้ามายึดความสนใจของอุตสาหกรรม กระแสของ data engineering ก็ลดลง แม้ Databricks จะประกาศ data engine ใหม่ก็ได้รับความสนใจน้อยกว่าเดิม
- ในทางกลับกัน สำหรับนักพัฒนาเครื่องมือข้อมูล นี่เปิดพื้นที่ให้โฟกัสกับความสมบูรณ์ทางเทคนิคโดยไม่ต้องวิ่งตามกระแส และสามารถใช้ AI กับงานซ้ำ ๆ ที่น่าเบื่อ เช่น การเขียนเทสต์
การหวนกลับสู่เทคโนโลยีฐานข้อมูล
- บทเรียนสำคัญของยุคบิ๊กดาต้าคือ เราน่าจะนำงานวิจัยและผลงานประชุมของนักวิจัยฐานข้อมูลมาใช้ให้เร็วกว่านี้
- แนวทางที่สำคัญคือการอ่าน ลงมือ implement และร่วมงานกับงานวิจัยด้านฐานข้อมูลจากสถาบันอย่าง TU Munich, CWI, MIT, CMU และ Berkeley
- ในยุคที่ NoSQL และที่เก็บข้อมูลแบบ non-relational ครองกระแส ระบบที่ขยายตัวได้มักเพิ่ม overhead มาก จนบางครั้งช้ากว่า implementation แบบ single-machine, single-thread ที่ทำมาดี
- งานวิจัย
Scalability! But at what COST?ที่มี Frank McSherry และ Michael Isard ร่วมอยู่ด้วย ตั้งคำถามถึงต้นทุนที่ต้องจ่ายเพื่อให้ได้ scalability - data stack สมัยใหม่กำลังหวนกลับมารวมศูนย์ที่ เทคโนโลยีฐานข้อมูลและการประมวลผลแบบคอลัมน์
- Polars, Daft และ DataFusion ใช้ Arrow
- เอนจินใหม่ของ dbt ใช้ ADBC
- Databricks Photon เลือกโครงสร้างแบบคอลัมน์ ไม่ว่าจะใช้ Arrow หรือไม่ก็ตาม
- เมื่อระบบหลักต่าง ๆ เริ่มลู่เข้าหาสถาปัตยกรรมและแนวทางคล้ายกัน โจทย์สำคัญจึงไม่ใช่วิธีประมวลผลแกนกลางอีกต่อไป แต่เป็นการทำให้ซอฟต์แวร์ใช้งานง่ายจริงแค่ไหน
จาก Hadoop สู่ DuckDB: การปรับปรุงด้านการใช้งาน
- ในยุค Hadoop บางครั้งต้องใช้เวลาเกือบสองวันไปกับการตั้งค่าก่อนเริ่มทำงานจริง เพราะมีทั้ง Java, ไฟล์ตั้งค่า XML และจุดปรับแต่งจำนวนมาก
- Spark ถือเป็นการพัฒนาครั้งใหญ่เพราะสามารถเขียน word count ได้ในบรรทัดเดียว แต่ก็ยังต้องเตรียมโครงสร้างพื้นฐานและไฟล์ตั้งค่าอยู่ดี
- รูปแบบการติดตั้งและการใช้งานของ DuckDB คือ โมเดลด้าน usability ที่แสดงให้เห็นว่าระบบข้อมูลสามารถเรียบง่ายได้มากเพียงใด
- แม้แต่ระบบ distributed ก็ควรมีค่าเริ่มต้นที่สมเหตุสมผลและการตั้งค่าที่ใช้งานได้ทันที เพื่อลดความซับซ้อนในการปฏิบัติการ
- DuckDB กำลังขยายไปยังพื้นที่ client-server ด้วย และทำงานใกล้ชิดกับ MotherDuck
เลเยอร์ข้อมูลมัลติโหมดสำหรับ generative AI
- เลกเฮาส์แบบเดิมเน้นข้อมูลเชิงตารางและ Parquet แต่สำหรับ generative AI รวมถึงการฝึกและ fine-tune โมเดลขนาดใหญ่ จำเป็นต้องใช้ทั้งภาพ วิดีโอ ข้อความ เอกสาร และล็อกไปพร้อมกัน
- multimodal data lakehouse ที่ LanceDB จัดการอยู่นั้นเป็นปัญหาระดับองค์กรที่เกิดขึ้นจริง
- เมื่อสร้าง embedding จากข้อมูลไม่มีโครงสร้างขนาดใหญ่ จะต้องใช้ไฟฟ้าและเวลา GPU ทำให้ embedding ที่ได้เองก็มีมูลค่าทางเศรษฐกิจจากต้นทุนการคำนวณ
- ในสภาพแวดล้อม production จำเป็นต้องมี data store ที่สามารถเก็บ จัดการ และประมวลผลทั้งข้อมูลต้นฉบับและผลลัพธ์ที่สร้างขึ้นได้อย่างเสถียร
- หากทุกบริษัทสร้างที่เก็บข้อมูลมัลติโหมดของตัวเอง ก็มีแนวโน้มจะเจอปัญหาบั๊ก ข้อมูลสูญหาย และประสิทธิภาพต่ำซ้ำ ๆ ดังนั้นการมีผู้ขายซอฟต์แวร์เฉพาะทางมอบโซลูชันร่วมจึงมีประสิทธิภาพกว่า
- แม้จะบริหาร Iceberg table ด้วยตัวเองได้ แต่การมอบหมายการดูแลให้ผู้ให้บริการอย่าง Databricks, Snowflake หรือ AWS ช่วยลดความซับซ้อนในการปฏิบัติการได้ และตรรกะเดียวกันนี้ก็ใช้ได้กับข้อมูลมัลติโหมดสำหรับ generative AI
- ตลาดข้อมูลสำหรับ generative AI ยังมีพื้นที่ให้แก้ปัญหาในหลายเลเยอร์ ตั้งแต่ document vector search และการรองรับ high QPS ไปจนถึงการจัดการวงจรชีวิตข้อมูล
ความสามารถในการแข่งขันของนักพัฒนาในยุค AI
- McKinney เคยกังวลว่าในฐานะวิศวกรซอฟต์แวร์ ตัวเขาเองยังมีอนาคตหรือไม่ แต่ตอนนี้เขามองว่า AI ทำให้ความแตกต่างระหว่างคนชัดเจนขึ้นตาม ระดับความเป็นผู้นำในการขับเคลื่อนงาน
- คนที่มีความเป็นผู้นำสูงจะได้ประโยชน์จาก AI อย่างมากในรูปของการขยายผลิตภาพ เพราะพวกเขาคิดอย่างจริงจังว่าจะสร้างอะไร และมีทั้งรสนิยมกับวิจารณญาณในการตัดสินว่าอะไรคือผลลัพธ์ที่ดี
- LLM ให้ แนวทางระดับ B+ ที่ดูดีและใช้ได้กับปัญหาส่วนใหญ่ แต่ไม่ได้สร้างประสบการณ์ รสนิยม หรือวิจารณญาณแทนผู้ใช้ให้
- หากเติมโค้ดที่สร้างขึ้นไปเรื่อย ๆ โดยไม่มีวิจารณญาณที่ดี ก็จะเกิดหล่มความซับซ้อน และแม้แต่เอเจนต์เองก็ทำงานต่อได้ยากเพราะถูกกดทับด้วยบริบทและโครงสร้าง
- ในอดีตคนเราพัฒนาทั้งทักษะเทคนิคและวิจารณญาณผ่านการลงมือ implement ด้วยตนเอง แต่ต่อจากนี้เมื่อเวลาในการเขียนโค้ดด้วยมือลดลง ก็จำเป็นต้องฝึกความเข้าใจระบบและความสามารถด้านการออกแบบแยกต่างหาก
สิ่งที่ควรเรียนในยุค AI
- นักพัฒนารุ่นใหม่ควรเรียน การออกแบบและสถาปัตยกรรมซอฟต์แวร์ รวมถึงโครงสร้างของระบบข้อมูล มากกว่ามุ่งจำแค่ไวยากรณ์ของ Python หรือ Java
- ในสาย data engineering ควรเข้าใจว่าระบบต่าง ๆ เช่น Lambda architecture และ Kappa architecture ทำงานอย่างไร และเหมาะกับปัญหาแบบไหน
- ต้องสามารถสื่อสารผลลัพธ์ที่ต้องการกับเอเจนต์ได้อย่างแม่นยำ และรู้ตัวเมื่อมันกำลังไปผิดทาง
- หากผู้ใช้เองยังตัดสินไม่ได้ว่า A หรือ B ดีกว่า เอเจนต์ก็ไม่อาจรับประกันการเลือกที่ถูกต้องแทนได้
- ทั้งวิศวกรซอฟต์แวร์ วิศวกรข้อมูล และนักวิทยาศาสตร์ข้อมูล อาจต้องใช้เวลากับ การนิยามปัญหาและการสื่อสาร มากกว่าการเขียนโค้ด
- หากอธิบายสิ่งที่ต้องการไม่ได้ ก็ย่อมไม่ได้ผลลัพธ์ที่ต้องการจาก AI เช่นกัน และการเติม AI เข้าไปในองค์กรไม่ได้ทำให้ผลิตภาพหรือผลลัพธ์ทางเศรษฐกิจเพิ่มขึ้นโดยอัตโนมัติ
- หากมอบ AI ให้กับคนที่ขาดประสบการณ์และวิจารณญาณ มันอาจกลายเป็น slop cannon ที่ผลิตหนี้งานจำนวนมากให้คนอื่นต้องตามมาเก็บกวาด มากกว่าจะสร้างผลงานที่มีประโยชน์
ภาระการตัดสินใจที่เพิ่มขึ้นและการลงทุน AI ขององค์กร
- ในช่วง 2~5 ปีข้างหน้า การจ้างนักพัฒนา การสัมภาษณ์ด้านเทคนิค และการแบ่งบทบาทงานอาจอยู่ในภาวะสับสนและเปลี่ยนแปลงอย่างรวดเร็ว
- ในอดีตทีมมักสร้างความมั่นใจร่วมกันต่อสิ่งที่จะทำผ่านการประชุม การวางแผนสปรินต์ และ planning poker ก่อนจะแบ่งงาน implementation กัน
- ตอนนี้กระบวนการวางแผนแบบ agile เดิมอาจถูกย่อเข้าไปอยู่ใน planning mode ของ Claude และกลายเป็นสถานการณ์ที่นักพัฒนาคนเดียวต้องตัดสินใจจำนวนมากด้วยตัวเอง
- นักพัฒนาที่ต้องตัดสินใจมากกว่าเดิม 10 เท่าต่อวันอาจหยุดชะงักได้เพราะ decision fatigue และความคลุมเครือ
- คนที่ตัดสินใจได้เร็วและเลือกเส้นทางที่มีประสิทธิภาพจะใช้ประโยชน์จากผลิตภาพของ AI ได้ แต่ถ้ายังไม่มั่นใจว่าควรทำอะไร AI ก็ไม่ได้ช่วยแก้ปัญหานั้นให้
- องค์กรอาจจ่ายเงินจำนวนมากให้ Anthropic และ OpenAI แต่ยังยากจะพิสูจน์ผลตอบแทนจากการลงทุนใน AI
- นอกจากผลลัพธ์เชิงบวกบางส่วนแล้ว ยังมีความสูญเปล่า ผลงานคุณภาพต่ำ และต้นทุนในการตามเก็บกวาดสิ่งเหล่านั้น
- ผู้ให้บริการโมเดล AI ทำกำไรได้ตราบใดที่การขายโทเค็นยังดำเนินต่อไป แต่ฝั่งลูกค้าองค์กรมีแนวโน้มจะเริ่มใช้ งบประมาณโทเค็น อย่างเข้มงวดยิ่งขึ้น
โมเดล open-weight และความคุ้มค่าทางเศรษฐศาสตร์ของโทเค็น
- McKinney รันโมเดลจีนแบบ open-weight GLM 5.2 บนโครงสร้างพื้นฐานจริง และประเมินว่าผลลัพธ์ออกมาดี
- GLM 5.2 ไม่ใช่โมเดลขนาดเล็ก และหากจะรันอย่างเหมาะสมต้องใช้ GPU B200 ราว 8 ตัว
- ราคาของ B200 หนึ่งตัวคาดว่าอยู่ที่ประมาณ 30,000~50,000 ดอลลาร์
- ต้นทุนฮาร์ดแวร์รวมอาจอยู่ที่ประมาณ 250,000~400,000 ดอลลาร์
- เขาคาดหวังว่าในระยะยาว หากคุณภาพของโมเดล open-weight ดีขึ้นและฮาร์ดแวร์ราคาถูกลง ก็จะสามารถใช้วิธีที่จ่ายเพียงค่าไฟของเซิร์ฟเวอร์ส่วนตัว แทนการจ่ายค่าบริการให้บริษัท AI ภายนอกอย่างต่อเนื่องได้
- หากคำนวณโทเค็นที่ใช้ในช่วง 30 วันที่ผ่านมาในราคาหน้า API จะอยู่ที่ประมาณ 37,000 ดอลลาร์ แต่จำนวนเงินที่จ่ายให้ผู้ให้บริการโมเดลจริงต่ำกว่านั้นมาก
- มีความเป็นไปได้ว่าราคาโทเค็นในปัจจุบันยังถูกอุดหนุนอย่างมาก และยังไม่ชัดเจนว่าโครงสร้างต้นทุนแบบใดจะยั่งยืนในระยะยาว
- อัตราการนำ AI ไปใช้จริงก็ไม่ได้กระจายสม่ำเสมอตามระดับความสนใจของอุตสาหกรรม บางบริษัทยังอยู่ในช่วงหางยาวที่แม้จะมีการพูดคุยกันในระดับบอร์ดและ CTO แล้ว แต่ยังไม่ได้เริ่มใช้งานจริง
ยังไม่มีความคิดเห็น