การสร้างบริษัทแบบ AI-Native

• ในช่วงต้นทศวรรษ 2020 ความสนใจจำนวนมากมุ่งไปที่ generative AI
  • การพูดคุยส่วนใหญ่เน้นว่าเครื่องมือ generative AI จะหล่อหลอมเราอย่างไร และจะส่งผลต่อการเขียน การเขียนโค้ด แอนิเมชัน และวิธีการบริโภคข้อมูลอย่างไร
  • อย่างไรก็ตาม แทบไม่มีการพูดถึงรูปร่างหน้าตาของเครื่องมือของเราเท่าไรนัก
• ในช่วงปลายทศวรรษ 1960 ระบบสารสนเทศต้องเผชิญกับปัญหาที่ต้นทุนในการค้นหาข้อมูลที่เกี่ยวข้องเพิ่มสูงขึ้นเรื่อย ๆ เนื่องจากมีข้อมูลจำนวนมหาศาล
• ในช่วงทศวรรษ 1980 และ 90 relational database กลายเป็นโซลูชันหลัก
  • มอบการทำดัชนีที่เข้าใจได้ง่ายและรับประกันประสิทธิภาพของการ query
  • relational database ทำให้สามารถแสดงข้อมูลเป็นชุดของตารางที่มีความสัมพันธ์เชิงโครงสร้างได้
  • ทำให้ค้นคืนข้อมูลได้รวดเร็วยิ่งขึ้นผ่านภาษา query เช่น SQL
• ระหว่างที่สถาปัตยกรรมฐานข้อมูลพัฒนาไป บริษัทบางแห่ง เช่น IBM, Oracle, Sun Microsystems และ MongoDB ก็ได้สร้างตำแหน่งที่มั่นในตลาดเกิดใหม่แต่ละแห่ง
• แม้ Oracle จะเป็นผู้นำในโลกของ relational database แต่วิธีที่ผู้คนจัดเก็บและเข้าถึงข้อมูลก็ยังคงเปลี่ยนแปลงอย่างต่อเนื่อง
  • ทุกครั้งที่มีงานรูปแบบใหม่ ผู้คนก็คิดค้นสถาปัตยกรรมใหม่ขึ้นมาเพื่อจัดการกับมัน
• วิวัฒนาการล่าสุดของฐานข้อมูลเกิดจากความจำเป็นในการจัดการข้อมูลที่ไม่มีโครงสร้าง
  • ตลอดกว่า 50 ปีที่ผ่านมา schema ถูกออกแบบโดยมีความสัมพันธ์ของข้อมูลแบบมีโครงสร้างเป็นศูนย์กลางเป็นหลัก
  • แต่ผู้คนจำนวนมากขึ้นเรื่อย ๆ ต้องการเครื่องมือที่จัดการกับความกำกวมของข้อมูลได้ดีกว่ามาก
  • นั่นจึงเป็นที่มาของ vector database
• large language model (LLM) แบบ transformer เช่น GPT สามารถจับความสัมพันธ์ระยะยาวในข้อความได้
  • แต่การคงความสามารถในการเข้าใจข้อความยาว ๆ ไว้นั้นอาจมีต้นทุนด้านการคำนวณสูง
  • vector database สามารถขยาย context window ของโมเดลเหล่านี้ได้
• แม้ vector database จะทรงพลังสำหรับ use case ด้าน AI แต่ก็ยังเป็นโครงสร้างพื้นฐานที่ทื่อซึ่งทำงานตาม input และ output
  • มันขาดความสามารถในการเข้าใจหรือตีความข้อมูล
  • มันเพียงทำหน้าที่เป็นที่เก็บข้อมูลที่จัดเก็บและค้นคืนข้อมูลตามคำสั่งเท่านั้น โดยไม่มีสติปัญญาในตัวหรือการรับรู้บริบท
• การเปิดตัว GPT-3 ในปี 2020 ทำให้ AI ถูกนำมาใช้เป็นแกนหลักมากขึ้นเรื่อย ๆ แทนที่จะเป็นเพียงส่วนเสริมของผลิตภัณฑ์องค์กร
  • สถาปัตยกรรม transformer ปริมาณข้อมูลที่เพิ่มขึ้น และประสิทธิภาพที่ดีขึ้น ได้ปูพื้นฐานสำหรับการพัฒนาผลิตภัณฑ์ที่ขับเคลื่อนด้วย AI
• เมื่อบริษัท AI-Native (ขับเคลื่อนด้วย AI) เพิ่มจำนวนขึ้นและขยายขนาด ความต้องการเครื่องมือที่รองรับ use case แบบ AI-driven ก็เพิ่มขึ้นเช่นกัน
  • คลื่นแรกของบริษัทที่มี AI เป็นแกนหลักส่วนใหญ่เน้นที่การทำ inference ด้วยโมเดลที่มีอยู่แล้ว
• แต่ด้วยโมเดลที่มีประสิทธิภาพสูงขึ้น โดยเฉพาะโมเดลโอเพนซอร์สที่เข้าถึงได้ง่าย บริษัทต่าง ๆ จึงสามารถสร้างขีดความสามารถในฐานะธุรกิจที่ขับเคลื่อนด้วย AI ได้ลึกยิ่งขึ้น
  • ความสามารถในการขยายนี้กำลังเปิดโลกของโอกาสว่าด้วย tech stack แบบ AI-driven อาจมีหน้าตาเป็นอย่างไร

เครื่องมือที่หล่อหลอมเรา (The Tools that Shape Us)

• ในปี 1967 John M. Culkin เพื่อนของ Marshall McLuhan กล่าวว่า "เราสร้างเครื่องมือ และหลังจากนั้นเครื่องมือก็สร้างเรา"
  • การสร้างเทคโนโลยีก็ไม่ต่างกัน
  • โครงสร้างพื้นฐานที่เราใช้สร้างซอฟต์แวร์ได้พัฒนาอย่างต่อเนื่องให้สอดรับกับความต้องการในการสร้างของเรา และจากนั้นสิ่งที่เราสร้างก็ถูกหล่อหลอมโดยโครงสร้างพื้นฐานที่เราได้วางไว้
• ในช่วงต้นทศวรรษ 2020 ความสนใจจำนวนมากมุ่งไปที่ generative AI
  • โดยเฉพาะอย่างยิ่งความสนใจพุ่งไปที่ผลลัพธ์ เช่น ข้อความหรือโค้ดที่ถูกสร้างขึ้น ภาพที่ถูกเรนเดอร์ deepfake ที่ถูกผลิตขึ้น และดนตรีที่ถูกสังเคราะห์
  • การพูดคุยส่วนใหญ่เน้นว่าเครื่องมือเหล่านี้จะหล่อหลอมเราอย่างไร และจะส่งผลต่อการเขียน การเขียนโค้ด แอนิเมชัน และวิธีการบริโภคข้อมูลอย่างไร
  • ผู้คนถกเถียงกันถึงประสิทธิภาพเปรียบเทียบของ large language model แบบเปิดและแบบปิด ความเสี่ยงของอาการหลอนของโมเดล ข้อถกเถียงระหว่าง platform กับ function และข้อถกเถียงระหว่างบริษัทเดิมกับสตาร์ตอัป
• อย่างไรก็ตาม แทบไม่มีการพูดถึงรูปร่างหน้าตาของเครื่องมือของเราเท่าไรนัก
  • โดยพื้นฐานแล้ว วิธีที่เราสร้างเทคโนโลยีนั้นถูกหล่อหลอมโดยโครงสร้างพื้นฐานที่เราจัดเตรียมไว้เพื่อการสร้างนั้น
  • การแพร่หลายของ SaaS ถูกเร่งโดยอินเทอร์เน็ต การพัฒนา mobile เกิดขึ้นได้จากการที่สมาร์ตโฟนกลายเป็นสิ่งแพร่หลาย และความสามารถในการขยายของแอปพลิเคชันหลายยุคก็ได้รับแรงส่งจาก cloud computing
• ความแพร่หลายของ AI ในแอปพลิเคชันขึ้นอยู่กับการประมวลผล ความสามารถของโมเดล และการ orchestration ของโมเดลเหล่านั้นภายใน use case ทางธุรกิจ
  • บทความนี้จะมุ่งเน้นไปที่องค์ประกอบด้าน orchestration
  • หนึ่งในองค์ประกอบสำคัญในการ orchestration use case ด้าน AI ทั้งหมดคือฐานข้อมูลขององค์กร
  • ตำแหน่งที่ข้อมูลถูกจัดเก็บ ถูกจัดการ และถูกเรียกใช้งานนั้นเป็นชิ้นส่วนสำคัญของปริศนา
  • แต่ดังที่จะแสดงให้เห็น ประวัติศาสตร์ของฐานข้อมูลโดยมากแล้วคือประวัติศาสตร์ของโครงสร้างพื้นฐานที่ทื่อ
  • หากต้องการดึงประโยชน์ของ AI ออกมาให้สูงสุด เราจำเป็นต้องสร้างฐานข้อมูลให้เป็นส่วนหนึ่งของสมการการสร้าง

ฐานรากสำหรับข้อมูล (A Base For Data)

• ในเดือนพฤษภาคม 1959 CODASYL (Conference on Data Systems Languages) ถูกจัดประชุมขึ้นเป็นครั้งแรก โดยมีเป้าหมายเพื่อสร้าง “ภาษาทั่วไปสำหรับการสร้างแอปพลิเคชันทางธุรกิจ”
  • ช่วงปลายทศวรรษ 1960 ระบบสารสนเทศต้องเผชิญปัญหาที่ต้นทุนในการค้นหาข้อมูลที่เกี่ยวข้องสูงขึ้นเรื่อย ๆ เนื่องจากมีข้อมูลจำนวนมหาศาล
• การใช้งานคอมพิวเตอร์เมนเฟรมโดยทั่วไปนำไปสู่ต้นทุน MIPS (ล้านคำสั่งต่อวินาที) ที่เพิ่มขึ้น เมื่อการใช้งานเมนเฟรมสูงขึ้นจากค่าใช้จ่ายในการอัปเกรดที่จำเป็นต่อการบำรุงรักษาแอปพลิเคชัน การแพตช์ และการคงประสิทธิภาพไว้
  • ด้วยความซับซ้อนของการจัดการฐานข้อมูล โครงสร้างลำดับชั้นที่แข็งตัว และการแมปโครงสร้างการนำทางที่ซับซ้อน องค์กรมักต้องพึ่งพาความเชี่ยวชาญทางเทคนิคเพื่อเข้าถึงข้อมูลที่ต้องการ และนักพัฒนาบางคนถึงกับต้องเขียนโปรแกรมทั้งชุดเพื่อเข้าถึงข้อมูลที่เกี่ยวข้อง
• ในปี 1970 E.F Codd ได้เผยแพร่บทความ “A Relational Model for Large Shared Data Banks” โดยเสนอโมเดลที่ตารางสามารถเชื่อมโยงกันได้ผ่านคุณลักษณะที่ใช้ร่วมกัน (เช่น primary key ที่ระบุเรคอร์ดเฉพาะ และ foreign key ที่สร้างความสัมพันธ์ระหว่างตาราง)
  • สิ่งนี้ทำให้สามารถดึงข้อมูลจากตารางที่ต่างกันได้ด้วยคิวรีเดียว
  • ฐานข้อมูลเชิงสัมพันธ์ของ Codd อาศัยความสัมพันธ์ระหว่างรายการข้อมูล ทำให้สามารถจัดการและใช้งานข้อมูลได้อย่างยืดหยุ่น
• ในปี 1973 กลุ่มโปรแกรมเมอร์จาก IBM San Jose Research Laboratory ได้เริ่มโครงการ System R เพื่อพิสูจน์ว่าระบบฐานข้อมูลเชิงสัมพันธ์สามารถรวมความสามารถครบถ้วนที่จำเป็นต่อการใช้งานระดับ production ได้ พร้อมกับยังคงมีประสิทธิภาพสูง
  • ทีมนี้ได้พัฒนาโปรแกรมเพิ่มประสิทธิภาพแบบอิงต้นทุนเพื่อประสิทธิภาพของฐานข้อมูล และงานพัฒนาที่ต่อยอดจาก System R ได้นำไปสู่การเปิดตัว SQL/DS ซึ่งเป็นผลิตภัณฑ์ฐานข้อมูลเชิงสัมพันธ์ตัวแรกของ IBM ในภายหลัง
• ในช่วงทศวรรษ 1980 และ 1990 ฐานข้อมูลเชิงสัมพันธ์ได้กลายเป็นโซลูชันฐานข้อมูลหลัก
  • มอบการทำดัชนีที่เข้าใจง่ายและรับประกันประสิทธิภาพของคิวรี
  • ฐานข้อมูลเชิงสัมพันธ์ทำให้สามารถแสดงข้อมูลเป็นชุดของตารางที่มีความสัมพันธ์เชิงโครงสร้างได้
  • ทำให้ค้นคืนข้อมูลได้เร็วขึ้นผ่านภาษาคิวรีอย่าง SQL
• ฐานข้อมูลเชิงสัมพันธ์ถูกสร้างขึ้นบนสมมติฐานว่าจะทำงานบนเครื่องเดียว
  • แต่การยอมรับอินเทอร์เน็ตอย่างแพร่หลายในช่วงทศวรรษ 1990 และ 2000 ทำให้มีข้อมูลไหลเข้ามามหาศาล จนเกิดเวิร์กโหลดที่หนักเกินกว่าคอมพิวเตอร์เครื่องเดียวจะรับไหว
  • ฐานข้อมูล SQL แบบดั้งเดิมถูกออกแบบมาให้ทำงานบนเซิร์ฟเวอร์เครื่องเดียว และผู้ใช้ต้องเพิ่มฮาร์ดแวร์จริงให้เพียงพอกับความจุจัดเก็บ ซึ่งพิสูจน์แล้วว่ามีค่าใช้จ่ายสูงมากสำหรับองค์กรที่ต้องรองรับเวิร์กโหลดขนาดใหญ่
• ในช่วงทศวรรษ 2010 ทั้งข้อมูลและผู้ใช้สำหรับ OLTP (online transaction processing) เติบโตแบบทวีคูณ จนนำไปสู่การเพิ่มขึ้นอย่างกว้างขวางของ distributed database, data warehouse และ OLAP (online analytical processing)
• ฐานข้อมูลเชิงสัมพันธ์และ SQL ไม่เหมาะกับขนาดและความซับซ้อนของแอปพลิเคชันที่ต้องการอีกต่อไป และฐานข้อมูล NoSQL ก็เกิดขึ้นมาเพื่อเป็นแนวทางเพิ่มประสิทธิภาพ (โดยแลกกับความสามารถ ACID)
  • แม้ว่าฐานข้อมูลเชิงสัมพันธ์จะสามารถจัดเก็บและจัดการข้อมูลแบบมีโครงสร้างได้ แต่การรักษาความสัมพันธ์ระหว่างข้อมูลเป็นเรื่องยากเมื่อคำนึงถึง overhead ของการ join และต้นทุนของงาน CRUD
  • ฐานข้อมูลเชิงสัมพันธ์เหมาะกับการจัดการข้อมูลเชิงสัมพันธ์ที่มีข้อกำหนดเชิงตรรกะหรือแยกส่วนชัดเจน แต่โดยทั่วไปมักผูกอยู่กับระบบ legacy ที่สร้างขึ้นมาโดยเฉพาะสำหรับโครงสร้างเชิงสัมพันธ์
  • NoSQL เกิดขึ้นเพื่อเป็นวิธีจัดการ big data แบบไม่มีโครงสร้าง โดยมอบ data persistence ให้แก่นักพัฒนาผ่านแนวทางแบบ non-relational
  • แทนที่จะใช้ SQL เป็นภาษาคิวรีหลัก NoSQL ให้การเข้าถึงผ่าน API ทำให้ได้ทั้งความสามารถในการขยายระบบที่สูงขึ้น distributed computing ต้นทุนที่ลดลง และความยืดหยุ่นของ schema
  • ฐานข้อมูล NoSQL ทำงานบนสถาปัตยกรรมที่มีประสิทธิภาพและสามารถขยายแบบแนวนอนได้ ดังนั้นหากต้องการเพิ่มความจุในการจัดเก็บหรือการประมวลผล ก็เพียงเพิ่มเซิร์ฟเวอร์หรือ cloud instance เข้าไป
  • สำหรับองค์กรที่มีเวิร์กโหลดข้อมูลซึ่งต้องการการประมวลผลหรือการวิเคราะห์ข้อมูลไม่มีโครงสร้างที่รวดเร็วยิ่งขึ้น ฐานข้อมูล NoSQL จึงเป็นตัวเลือกที่ได้รับความนิยม

สงครามฐานข้อมูลยุค OG

• ระหว่างที่สถาปัตยกรรมฐานข้อมูลพัฒนาไป บริษัทบางแห่งก็สามารถสร้างฐานที่มั่นในแต่ละตลาดเกิดใหม่ได้
  • ไม่นานหลังจากที่ IBM เปิดตัว System R, Larry Ellison วัย 33 ปีก็ได้อ่านบทความฉบับเดียวกันของ Codd เกี่ยวกับฐานข้อมูลเชิงสัมพันธ์
  • Ellison และผู้ร่วมก่อตั้งอีกสองคนพยายามสร้างบริษัทที่เข้ากันได้กับ System R แต่ IBM ทำให้เรื่องนั้นเป็นไปได้ยากมาก
  • ผลก็คือ ทั้งสามได้สร้างธุรกิจขึ้นมารอบผลิตภัณฑ์ฐานข้อมูลเรือธงตัวใหม่ของตน นั่นคือ Oracle Databases
  • นับแต่นั้นมา ฐานข้อมูลของ Oracle ก็กลายเป็นผลิตภัณฑ์ผู้นำ และ ณ เดือนพฤษภาคม 2024 มีส่วนแบ่งตลาดราว 28.7%
• ในช่วงไม่กี่ปีก่อน IPO ของ Oracle ในปี 1986 มีอีกบริษัทหนึ่งเข้าสู่ตลาดฐานข้อมูล
  • Sun Microsystems เริ่มต้นในปี 1982 ด้วยการจำหน่ายชิ้นส่วนคอมพิวเตอร์หลากหลายประเภท แต่ต่อมาเป็นที่รู้จักจากการมีส่วนร่วมอย่าง Java programming language, Network File System และอื่น ๆ
  • ประเด็นสำคัญคือ ในปี 2008 Sun Microsystems ได้เข้าซื้อ MySQL ซึ่งเป็นระบบจัดการฐานข้อมูลแบบโอเพนซอร์ส
  • เพียง 2 ปีต่อมา Oracle ก็เข้าซื้อ Sun Microsystems (รวมถึง MySQL)
  • เกือบ 15 ปีต่อมา ณ เดือนพฤษภาคม 2024 ฐานข้อมูลชั้นนำคือ Oracle (ส่วนแบ่งตลาด 28.7%) และ MySQL (ราว 17.3%)
• แม้ Oracle จะครองโลกของฐานข้อมูลเชิงสัมพันธ์ แต่วิธีที่ผู้คนจัดเก็บและเข้าถึงข้อมูลก็ยังเปลี่ยนแปลงต่อไป
  • ทุกครั้งที่มีภาระงานรูปแบบใหม่ ผู้คนก็คิดค้นสถาปัตยกรรมใหม่เพื่อจัดการกับมัน
  • ตั้งแต่ document store อย่าง MongoDB (2007), Databricks (2013) ไปจนถึงฐานข้อมูล time-series อย่าง InfluxDB (2013), Prometheus (2012) และฐานข้อมูลกราฟอย่าง Neo4j (2007), Cosmos (2017) รายชื่อฐานข้อมูลเฉพาะทางก็เพิ่มขึ้นอย่างต่อเนื่อง
  • เมื่อความนิยมของฐานข้อมูลเชิงสัมพันธ์ลดลงอย่างต่อเนื่อง โซลูชันที่หลากหลายก็เกิดขึ้นเพื่อตอบโจทย์ความต้องการเฉพาะกลุ่มใหม่ ๆ เหล่านี้
• วิวัฒนาการล่าสุดของฐานข้อมูลเกิดจากความจำเป็นในการจัดการข้อมูลที่ไม่มีโครงสร้าง
  • ตลอดเวลากว่า 50 ปีที่ผ่านมา schema ถูกออกแบบโดยมีความสัมพันธ์ของข้อมูลแบบมีโครงสร้างเป็นศูนย์กลางเป็นหลัก
  • แต่ผู้คนจำนวนมากขึ้นเรื่อย ๆ ต้องการเครื่องมือที่จัดการกับความกำกวมของข้อมูลได้ดีกว่ามาก
  • และนั่นคือจุดที่ vector database ถือกำเนิดขึ้น

การเติบโตของ vector database

• การแพร่หลายอย่างกว้างขวางของโมเดลภาษาขนาดใหญ่ (LLM) และ generative AI ทำให้ฐานข้อมูลเวกเตอร์กลายเป็นเครื่องมือสำคัญสำหรับการจัดการข้อมูลมัลติโหมดแบบไม่มีโครงสร้าง
  • ขณะที่ฐานข้อมูลเชิงสัมพันธ์แบบเดิม (Postgres, MySQL) เหมาะที่สุดกับสคีมาที่มีโครงสร้าง ฐานข้อมูลเวกเตอร์เหมาะสำหรับการจัดเก็บและคิวรีเวกเตอร์เอ็มเบดดิง (การแทนข้อมูลเชิงตัวเลขที่รวมความหมายสัมพัทธ์ต่อค่าน้ำหนักของโมเดลภาษา)
  • แทนที่จะใช้แถวและคอลัมน์แบบที่ใช้กันทั่วไปในฐานข้อมูลเชิงสัมพันธ์ ฐานข้อมูลเวกเตอร์จะแทนข้อมูลเป็นจุดในปริภูมิหลายมิติ และจับคู่ข้อมูลตามความคล้ายคลึงกันแทนค่าที่ตรงกันแบบเป๊ะ
• ข้อมูลสามารถถูกแทนในปริภูมิเวกเตอร์ที่แตกต่างกันและมีหลายมิติได้ ขึ้นอยู่กับโมเดลเอ็มเบดดิง
  • เวกเตอร์เอ็มเบดดิงช่วยจับความหมายของจุดข้อมูล ทำให้สามารถค้นหาอ็อบเจ็กต์ที่ใกล้ที่สุดในฐานข้อมูลเวกเตอร์เพื่อหาอ็อบเจ็กต์ที่คล้ายกันได้
• ตัวอย่างเช่น Word2Vec ทำการแมปคำเป็นเวกเตอร์ ซึ่งช่วยจับความหมาย ความคล้ายคลึงเชิงความหมาย และความสัมพันธ์เชิงบริบทกับข้อความอื่น
  • อัลกอริทึมนี้ใช้โครงข่ายประสาทเทียมแบบตื้นเพื่ออนุมานความหมายของคำเฉพาะจากคลังข้อความที่กว้างขึ้น และใช้ logistic regression เพื่อระบุคำพ้องความหมาย
  • ยังมีวิธีที่ช่วยดึงเอ็มเบดดิงออกมาได้โดยไม่ต้องพึ่งโครงข่ายประสาทเทียมเชิงลึก เช่น singular value decomposition (SVD) และ principal component analysis (PCA)
• distance metric ช่วยกำหนด “ระยะห่าง” สัมพัทธ์ระหว่างจุดต่าง ๆ ในปริภูมิเวกเตอร์ โดยวิธีที่ใช้ทั่วไปได้แก่ Euclidean distance, Manhattan distance, cosine distance และ Jaccard similarity
  • K-nearest neighbors (KNN) และ approximate nearest neighbors (ANN) ช่วยให้การค้นหาความคล้ายคลึงสำหรับภาพ วิดีโอ หรืออินพุตมัลติโหมดอื่น ๆ ง่ายขึ้นและช่วยปรับปรุงเวลาในการประมวลผล
• ฐานข้อมูลเฉพาะทางด้านเวกเตอร์อย่าง Weaviate, Chroma, Qdrant และ Pinecone ช่วยให้นักพัฒนาจัดการข้อมูลขนาดใหญ่ โดยเฉพาะอินพุตแบบไม่มีโครงสร้าง ได้ง่ายขึ้นในด้านการค้นหา
  • ต่างจากฐานข้อมูลเชิงสัมพันธ์หรือฐานข้อมูล NoSQL แบบดั้งเดิม ฐานข้อมูลเวกเตอร์ถูกออกแบบมาโดยเฉพาะเพื่อจัดการเวกเตอร์เอ็มเบดดิง
  • ฐานข้อมูลแบบเดิมจัดเก็บข้อมูลเป็นสเกลาร์ ขณะที่ฐานข้อมูลเวกเตอร์จัดเก็บเฉพาะเวกเตอร์ และใช้เทคนิคการทำดัชนี เช่น quantization และ clustering เพื่อเพิ่มประสิทธิภาพงานค้นหา
• LLM แบบทรานส์ฟอร์เมอร์ เช่น GPT สามารถจับการพึ่งพาระยะยาวของข้อความได้
  • อย่างไรก็ตาม การคงความสามารถในการเข้าใจข้อความยาวอาจมีต้นทุนการคำนวณสูง
  • แม้ LLM รุ่นใหม่จะสามารถจับการพึ่งพาแบบทั่วทั้งคู่โทเค็นในอินพุตได้ แต่ความซับซ้อนด้านเวลาและพื้นที่ทำให้เกิดข้อจำกัดด้านทรัพยากรการคำนวณ ส่งผลให้ความยาวข้อความอินพุตระหว่างการฝึก และ effective context window ระหว่างการอนุมาน ถูกจำกัด
• สำหรับกรณีหลายมิติ การทำ relative positional encoding นำไปใช้งานได้ยาก และแนวทางส่วนใหญ่ในการเข้ารหัสตำแหน่งสัมพัทธ์ต้องอาศัยกลไก positional embedding ที่ซับซ้อน ซึ่งมีส่วนทำให้ประสิทธิภาพระหว่างการอนุมานลดลง
  • แม้เมื่อความยาวข้อความเพิ่มขึ้น ฐานข้อมูลเวกเตอร์ก็ยังมีความสำคัญในฐานะหน่วยความจำระยะยาวของโมเดล
  • การใช้ฐานข้อมูลเวกเตอร์ช่วยทำให้งานอย่าง text completion หรือ summarization ง่ายขึ้น ซึ่งบริบทของทั้งประโยคอาจจำเป็นต่อการสร้างผลลัพธ์ที่แม่นยำ
• ฐานข้อมูลเวกเตอร์สามารถรองรับ retrieval-augmented generation (RAG) ได้ โดยฐานข้อมูลเวกเตอร์สามารถใช้เพื่อเสริมพรอมป์ต์ที่ส่งให้ LLM ด้วยบริบทเพิ่มเติมควบคู่ไปกับคิวรีดั้งเดิม
  • LLM มักพึ่งพาโมเดลการเรียนรู้แบบ self-supervised จึงมักประสบปัญหากับงานเฉพาะโดเมนที่ต้องใช้ความรู้เฉพาะทางหรือเกณฑ์ความแม่นยำที่สูงกว่า
  • RAG สามารถช่วยยืนยัน ติดตาม หรืออธิบายได้ว่าคำตอบถูกได้มาอย่างไร พร้อมทั้งลดอาการหลอนของโมเดลที่อาจเกิดจากการขาดบริบทสำหรับคิวรีของปัญหา
• นักพัฒนาสามารถผสาน knowledge graph กับการค้นหาแบบเวกเตอร์เพื่อขยายความสามารถของ LLM ให้ก้าวเลยข้อมูลที่ใช้ฝึกมา
  • เครื่องมืออย่าง GraphRAG ของ Microsoft Research ช่วยให้การเสริมพรอมป์ต์ทำได้สะดวกขึ้นเมื่อทำ retrieval กับชุดข้อมูลส่วนตัว
  • RAG แบบพื้นฐานมักมีปัญหาในการทำความเข้าใจแนวคิดเชิงความหมายแบบสรุปภาพรวมของคอลเลกชันข้อมูลขนาดใหญ่ ดังนั้นเครื่องมืออย่าง LlamaIndex และ GraphRAG จึงสร้าง knowledge graph จากชุดข้อมูลส่วนตัว
• นักพัฒนาอาจพบว่าการใช้ knowledge graph เหมาะสมกว่า RAG ขึ้นอยู่กับความต้องการหรือกรณีใช้งานเฉพาะ
  • ฐานข้อมูลเวกเตอร์เหมาะกับการค้นหาความคล้ายคลึง และเหมาะที่สุดสำหรับการค้นหาเอกสารหรือภาพ รวมถึงการสร้างคำแนะนำ ขณะที่ knowledge graph เหมาะกับการให้เหตุผล (โดยเฉพาะเมื่อมีประโยชน์ต่อการรวบรวมข้อมูล การดึงเอนทิตีพร้อมความสัมพันธ์ที่เชื่อมโยงกัน และการไล่ตามความสัมพันธ์เหล่านั้น)
• สำหรับแอปพลิเคชันที่ต้องการการประมวลผลข้อมูลแบบเรียลไทม์หรือเกือบเรียลไทม์ ฐานข้อมูลเวกเตอร์อาจเป็นตัวเลือกที่เหมาะกว่าเพราะคิวรีมี latency ต่ำกว่า
• ด้วยการรวบรวมและจัดเก็บเอ็มเบดดิง ฐานข้อมูลเวกเตอร์ช่วยให้การค้นหาแบบ similarity search ทำได้รวดเร็วยิ่งขึ้น โดยจับคู่พรอมป์ต์ที่ป้อนเข้ากับเอ็มเบดดิงที่คล้ายกัน
• การจัดอันดับตามความคล้ายคลึงช่วยรองรับงานแมชชีนเลิร์นนิงหลากหลายประเภท ตั้งแต่ระบบแนะนำ การค้นหาเชิงความหมาย การรู้จำภาพ ไปจนถึงแอปพลิเคชันประมวลผลภาษาธรรมชาติอื่น ๆ
• ฐานข้อมูลเวกเตอร์มีบทบาทสำคัญในการเพิ่มประสิทธิภาพของ LLM ด้วยการทำให้การจัดเก็บและค้นคืนเวกเตอร์เอ็มเบดดิงมีประสิทธิภาพ
  • สิ่งนี้ช่วยให้สามารถทำความเข้าใจภาษาธรรมชาติแบบอัตโนมัติได้ในระดับขนาดใหญ่
• อย่างไรก็ตาม เวกเตอร์เอ็มเบดดิงเป็นนวัตกรรมแบบ N+1
  • เป็นรูปแบบข้อมูลที่ต่อยอดมาจากรูปแบบก่อนหน้า เช่น ข้อมูลเชิงสัมพันธ์หรือข้อมูลอนุกรมเวลา
• ผู้ให้บริการฐานข้อมูลแบบดั้งเดิมเริ่มเปิดตัวความสามารถด้านเวกเตอร์แล้ว เช่น Atlas Vector Search ของ MongoDB, ฐานข้อมูลเวกเตอร์ของ SingleStore และ vector search index ของ Neo4J
• แม้ว่าฐานข้อมูลเวกเตอร์จะทรงพลังสำหรับกรณีใช้งานด้าน AI แต่ท้ายที่สุดมันก็ยังเป็นโครงสร้างพื้นฐานที่ทื่อ ๆ ซึ่งทำงานตามอินพุตและเอาต์พุต
  • มันขาดความสามารถในการเข้าใจหรือตีความข้อมูล
  • มันเป็นเพียงที่เก็บข้อมูลที่ทำหน้าที่จัดเก็บและค้นคืนข้อมูลตามที่ได้รับคำสั่ง โดยไม่มีสติปัญญาโดยเนื้อแท้หรือการรับรู้บริบท
• สำหรับแอปพลิเคชันยุคใหม่ที่ขับเคลื่อนด้วย AI เพียงเท่านี้อาจไม่เพียงพอ
  • องค์กรต่าง ๆ กำลังสร้างระบบโดยมีโมเดล AI เป็นแกนกลางมากขึ้นเรื่อย ๆ
  • ดังนั้น หากแอปพลิเคชันต้องแสดงความสามารถอันชาญฉลาดมากขึ้นเรื่อย ๆ โครงสร้างพื้นฐานก็จะต้องมีความสามารถอันชาญฉลาดแบบเดียวกันด้วย

บริษัท AI-Native ยุคแรก

• นับตั้งแต่วงการวิชาการเริ่มศึกษาปัญญาประดิษฐ์เป็นครั้งแรกที่มหาวิทยาลัยดาร์ตมัธในปี 1956 กรณีการใช้งานเชิงปฏิบัติก็เป็นแรงขับเคลื่อนให้สาขานี้พัฒนามาโดยตลอด
  • ตัวอย่างเช่น ในช่วงปลายทศวรรษ 1960 Joseph Weizenbaum ได้สร้างโปรแกรมคอมพิวเตอร์ชื่อ ELIZA ซึ่งใช้แนวทางแบบง่ายในการจำลองบทสนทนาด้วยการจับคู่รูปแบบ และถูกนำไปใช้กับบทสนทนาที่คล้ายการบำบัดขั้นพื้นฐาน (แชตบอตตัวแรก)
• ตลอดประวัติศาสตร์ส่วนใหญ่ของการใช้ AI ในกรณีการใช้งานทางธุรกิจ การพัฒนา AI เป็นไปอย่างค่อยเป็นค่อยไป
• ก่อนที่คำว่า AI จะกลายเป็นคำฮิต คำว่า machine learning ถูกใช้บ่อยกว่าในการอ้างถึงเทคโนโลยีแบบเดียวกัน
  • กล่าวคือ เป็น "อัลกอริทึมเชิงสถิติที่เรียนรู้จากข้อมูลและทำให้ทั่วไปกับข้อมูลที่ไม่เคยเห็นมาก่อนได้ จึงสามารถทำงานได้โดยไม่ต้องมีคำสั่งอย่างชัดเจน"
• ในแง่ของการรับรู้ของสาธารณะ AI มาถึงจุดเปลี่ยนเมื่อ OpenAI เปิดตัว ChatGPT ในวันที่ 30 พฤศจิกายน 2022 แต่ในมุมมองทางเทคนิค จุดเปลี่ยนเกิดขึ้นก่อนหน้านั้นมาก
• ในเดือนพฤศจิกายน 2017 คณะกรรมการเสถียรภาพทางการเงินระหว่างประเทศ (FSB) ได้จัดทำภาพรวมเกี่ยวกับผลกระทบของ machine learning ต่อบริการทางการเงิน
  • บริษัทบริการทางการเงินสามารถใช้ machine learning มากขึ้นเรื่อยๆ เพื่อทำงานอย่างเช่น "การประเมินคุณภาพเครดิต" และ "ช่วยให้เกิดระบบการเงินที่มีประสิทธิภาพมากขึ้น"
  • กล่าวคือ มันช่วยเพิ่มประสิทธิภาพได้ แต่ยังไม่ใช่สิ่งจำเป็นระดับการดำรงอยู่
• ขณะเดียวกัน machine learning ก็พัฒนาดีขึ้นเรื่อยๆ และในเดือนพฤษภาคม 2018 OpenAI ได้เผยแพร่งานวิจัยเกี่ยวกับประวัติของคอมพิวต์ที่จำเป็นต่อการฝึกโมเดลขนาดใหญ่ ซึ่งแสดงให้เห็นว่าหลังปี 2012 คอมพิวต์เพิ่มขึ้นเป็นสองเท่าทุก 3.4 เดือน หรือเพิ่มขึ้นรวม 300,000 เท่า
• เดือนถัดมาในเดือนมิถุนายน 2018 OpenAI ได้เผยแพร่การแนะนำ GPT รุ่นแรก
• กำลังก่อตัวเป็นการถกเถียงระหว่างสองฝ่าย
  • ฝ่ายหนึ่งมีคนจำนวนมากที่เชื่อว่าการเติบโตอย่างต่อเนื่องของโมเดลที่ใหญ่ขึ้นเรื่อยๆ จะชนกับกฎผลตอบแทนลดลง
  • อีกฝ่ายซึ่ง OpenAI อยู่ในนั้น เชื่อว่าเมื่อสเกลใหญ่ขึ้น ประสิทธิภาพจะยังคงดีขึ้นต่อไป
• ในเดือนมกราคม 2020 Jared Kaplan นักวิจัยของ OpenAI และศาสตราจารย์แห่งมหาวิทยาลัย Johns Hopkins ร่วมกับผู้อื่นได้เผยแพร่ "Scaling Laws for Neural Language Models" ซึ่งระบุไว้ดังนี้:
  • "ประสิทธิภาพของ language modeling จะดีขึ้นอย่างราบรื่นและคาดการณ์ได้ เมื่อมีการขยายขนาดโมเดล ข้อมูล และคอมพิวต์อย่างเหมาะสม เราคาดว่าโมเดลภาษาที่ใหญ่กว่าจะมีประสิทธิภาพดีกว่าและมี sample efficiency สูงกว่าโมเดลปัจจุบัน"
• ในเดือนพฤษภาคม 2020 OpenAI ได้เผยแพร่บทความ "Language Models are Few-Shot Learners" เกี่ยวกับ GPT-3 ซึ่งแสดงให้เห็นการขยายประสิทธิภาพอย่างราบรื่นตามการเพิ่มขึ้นของคอมพิวต์
• นอกจากนี้ OpenAI ยังพบว่าการเพิ่มสเกลยังช่วยเพิ่มความสามารถในการ generalize และระบุว่า "การขยายสเกลของโมเดลภาษาขนาดใหญ่ช่วยเพิ่มประสิทธิภาพ few-shot แบบไม่ยึดติดกับงานอย่างมีนัยสำคัญ จนบางครั้งสามารถแข่งขันกับแนวทาง fine-tuning ที่ล้ำหน้าที่สุดก่อนหน้านี้ได้"
• Gwern Branwen นักวิจัยอิสระ ได้เสนอสมมติฐานเรื่อง scaling hypothesis ในบล็อกโพสต์ และกล่าวว่า:
  • "GPT-3 ที่ OpenAI เผยแพร่ในเดือนพฤษภาคม 2020 เป็นโครงข่ายประสาทเทียมที่ใหญ่ที่สุดเท่าที่เคยฝึกมา ใหญ่กว่าด้วยหลักมากกว่าหนึ่งหลัก... ตรงกันข้ามกับที่หลายคนคาดไว้ (รวมถึงตัวผมเอง) การเพิ่มสเกลมหาศาลนี้ยังคงแสดงให้เห็นข้อดีของสเกลตามที่ OpenAI คาดการณ์ไว้ และไม่ได้ชนกับผลตอบแทนลดลงหรือผลตอบแทนติดลบอย่างที่หลายคนคาด"
• ความประหลาดใจที่ Branwen รู้สึกนั้นสะท้อนถึงการเปลี่ยนแปลงของภูมิทัศน์
• AI ไม่ได้เป็นเพียงส่วนเสริมของผลิตภัณฑ์บริษัทอีกต่อไป แต่สามารถถูกใช้เป็นแกนกลางได้มากขึ้นเรื่อยๆ
• สถาปัตยกรรม transformer, ปริมาณข้อมูลที่เพิ่มขึ้น, และระดับประสิทธิภาพที่ดีขึ้น ล้วนปูพื้นฐานให้กับการพัฒนาผลิตภัณฑ์ที่ขับเคลื่อนด้วย AI
• ไม่นานหลังจาก GPT-3 เปิดตัวในเดือนพฤษภาคม 2020 บริษัทอย่าง Writer และ Jasper ก็สร้างผลิตภัณฑ์ด้านการเขียนคำโฆษณาที่วางโมเดล AI ไว้เป็นศูนย์กลางของธุรกิจ
• บริษัทอย่าง Harvey และ EvenUp ก็สร้าง legal tech โดยมี AI เป็นแกนกลาง
• บริษัทอย่าง DeepScribe และ Freed ก็สร้างระบบถอดความทางการแพทย์โดยมี AI เป็นแกนกลาง
• แต่เช่นเดียวกับที่กรณีใช้งานใหม่ๆ ในอดีตเคยนำไปสู่การวิวัฒนาการของฐานข้อมูล การกำเนิดของผลิตภัณฑ์ที่ขับเคลื่อนด้วย AI ก็หมายความว่าโครงสร้างพื้นฐานเบื้องหลังเทคสแต็กของแต่ละบริษัทจำเป็นต้องเปลี่ยนแปลงและปรับตัว

AI-Native Database

• เมื่อบริษัทที่ขับเคลื่อนด้วย AI เพิ่มจำนวนขึ้นและขยายขนาดมากขึ้น ความต้องการเครื่องมือที่รองรับกรณีการใช้งานที่ขับเคลื่อนด้วย AI ก็เพิ่มขึ้นตามไปด้วย
• บริษัทคลื่นแรกที่มี AI เป็นแกนกลาง มุ่งเน้นไปที่การทำ inference ด้วยโมเดลที่มีอยู่เป็นหลัก
  • มีเครื่องมือเวิร์กโฟลว์เฉพาะจุดประสงค์สำหรับแอปพลิเคชัน การเขียนคำโฆษณา การถอดความทางการแพทย์ และอื่นๆ
  • แก่นของผลิตภัณฑ์คือผลลัพธ์ เช่น ข้อความที่สร้างจากโมเดลหรือภาพที่สร้างขึ้น
• หลัง DevDay ของ OpenAI ในเดือนพฤศจิกายน 2023 มีม "OpenAI ทำลายสตาร์ทอัปของฉัน" เริ่มแพร่กระจาย
  • GPT เฉพาะทางหรือ AI agent บางประเภทดูเหมือนจะเข้ามารับบทบาทของสตาร์ทอัป AI ยุคแรกเหล่านี้ เพราะพวกมันมุ่งเน้นการทำ inference จากโมเดลที่มีอยู่
  • OpenAI กลายเป็นผู้ให้บริการทั้งโมเดลและแอปพลิเคชันโดยบังเอิญ
• นวัตกรรมที่มีศูนย์กลางอยู่ที่ความสามารถของโมเดลดำเนินไปอย่างรวดเร็วมาก จนเริ่มให้ความรู้สึกว่าเป็นภัยคุกคามต่อสตาร์ทอัป
• แต่ในทางกลับกัน โมเดลที่มีประสิทธิภาพดีขึ้น (โดยเฉพาะโมเดลโอเพนซอร์สที่เข้าถึงได้ง่าย) ทำให้บริษัทสามารถสร้างขีดความสามารถในฐานะธุรกิจที่ขับเคลื่อนด้วย AI ได้ลึกยิ่งขึ้น
• การสร้างเทคสแต็กที่ขับเคลื่อนด้วย AI ไม่ได้หมายถึงแค่การเพิ่มองค์ประกอบรอบๆ โมเดลเท่านั้น
  • ตัวอย่างเช่น ฐานข้อมูลที่สร้างขึ้นมาเพื่อ AI โดยเฉพาะควรมีหน้าตาอย่างไร?
  • หาก inference คือผลลัพธ์สำคัญ ฐานข้อมูลแบบ AI-native ก็ไม่ควรเพียงแค่จัดเก็บและเรียกค้นข้อมูลเท่านั้น แต่ควรสามารถรับคำสั่งเชิงบริบทเกี่ยวกับสิ่งที่ต้องทำกับข้อมูลที่จัดเก็บอยู่ได้ด้วย
• ตัวอย่างหนึ่งอาจเป็นการปรับแต่งคำอธิบายสินค้าให้เป็นส่วนบุคคลสำหรับอีคอมเมิร์ซ
  • vector database ไม่เพียงเก็บ vector embedding ของ SKU สินค้าและคำอธิบายเท่านั้น แต่ยังเก็บ embedding ของ persona ผู้ใช้ได้ด้วย
  • โดยใช้ข้อมูลเชิงบริบททั้งหมดนี้ในฐานข้อมูล โครงสร้างพื้นฐานสามารถใช้ลูปป้อนกลับเชิงสร้างสรรค์ที่ทำให้การ query คำอธิบายสินค้ากระตุ้นการ query ไปยัง persona ผู้ใช้ที่เกี่ยวข้องด้วย จากนั้นจึงเขียนคำอธิบายสินค้าตาม persona ที่เกี่ยวข้องนั้น
• ในทำนองเดียวกัน ภาษาเองก็สามารถถูกใช้เป็นลูปป้อนกลับเชิงสร้างสรรค์ได้
  • ตัวอย่างเช่น ผู้ใช้อาจต้องการสร้างคำอธิบายสินค้าในหลายภาษา
  • จึงสามารถสร้างคำอธิบายสินค้าที่ไม่เพียงปรับให้เข้ากับผู้ใช้ แต่ยังแปลเป็นภาษาที่ผู้ใช้เลือกไว้ด้วย
  • คำสั่งประเภทนี้สามารถฝังอยู่ในฐานข้อมูลได้โดยตรง เพราะกรณีใช้งานอย่าง generative AI กำลังกลายเป็นฟังก์ชันหลักของแอปพลิเคชันมากขึ้นเรื่อยๆ
• การพัฒนาโครงสร้างพื้นฐานให้สอดคล้องกับกรณีใช้งานไม่ใช่เรื่องใหม่
  • เดิมทีนักพัฒนาใช้ JavaScript เพื่อสร้างแอปพลิเคชันในเบราว์เซอร์ ทำให้เว็บไซต์มีความโต้ตอบและมีความไดนามิก
  • แต่เมื่อพวกเขาตระหนักว่าสามารถนำสิ่งนี้ไปใช้กับแบ็กเอนด์ได้ด้วย node.js จึงถือกำเนิดขึ้น
  • ต่อมาเมื่อนักพัฒนาเริ่มสร้างแอปพลิเคชันมือถือมากขึ้น JSON (JavaScript Object Notation) ก็ปรากฏขึ้นเพื่อรองรับแอปพลิเคชันที่มีความไดนามิก ตอบสนองได้ดี และขับเคลื่อนด้วยข้อมูลมากกว่าเดิม
  • MongoDB เป็นบริษัทที่เกิดขึ้นมาเพื่อตอบโจทย์ความต้องการด้านโครงสร้างพื้นฐานที่เปลี่ยนแปลงไป และเข้ากับคลื่นนี้ได้อย่างลงตัว
• ประวัติศาสตร์กำลังซ้ำรอยกับ AI
  • เมื่อความต้องการเปลี่ยนไป โครงสร้างพื้นฐานก็ต้องพัฒนาเพื่อตอบสนองความต้องการเหล่านั้น
  • คำถามใหญ่ที่สุดจะเป็นเรื่องที่ว่าผู้คนต้องการสร้างบริษัทแบบใด และโครงสร้างพื้นฐานแบบใดที่เหมาะสมที่สุดกับบริษัทเหล่านั้น
  • ตามที่ Bob กล่าวไว้ในการสัมภาษณ์กับ Matthew Lynley:
    • "ผมเชื่ออย่างแรงกล้าว่าแอปพลิเคชันทุกตัวในอนาคตจะมี AI อยู่ในนั้น บางแอปพลิเคชันจะถูกโรย AI ลงไป และบางแอปพลิเคชันจะมี AI เป็นศูนย์กลางของตัวแอป หากเอา AI ออก มันก็จะไม่สามารถมีอยู่ได้อีกต่อไป ถ้าคุณต้องการสร้างเว็บแอปแล้วโรย AI ลงไป ก็ใช้ MongoDB ได้เลย โดยเฉพาะถ้าคุณใช้อยู่แล้ว... แต่ถ้าคุณต้องการสร้างแอปพลิเคชันที่ขับเคลื่อนด้วย AI ซึ่ง AI เป็นแกนกลางของแอปพลิเคชัน ถึงเวลาที่คุณควรพิจารณา Weaviate"
• จากนี้ไป บริษัทต่างๆ จะต้องตัดสินใจว่าจะสร้างผลิตภัณฑ์โดยมี AI เป็นเพียงส่วนเสริม หรืออย่างที่ Bob พูดคือเป็นการ "sprinkle" หรือจะให้มันเป็นแกนหลักของผลิตภัณฑ์

AI-Native เทคสแต็ก

• สำหรับบริษัทที่ต้องการสร้าง AI ให้เป็นองค์ประกอบหลักของผลิตภัณฑ์ อินฟราสตรักเจอร์แบบเดิมมีแนวโน้มจะไม่เหมาะสม
  • เมื่อใช้เครื่องมือแบบเลกาซี การจัดเก็บ การจัดระเบียบ และการรันข้อมูลจะถูกสร้างไว้ในไซโลหนึ่ง ขณะที่ระบบอัตโนมัติจะถูกสร้างไว้อีกไซโลหนึ่ง
  • ข้อเสียของแนวทางนี้คือบริบทจะสูญหายไปจากสิ่งต่าง ๆ เช่น วงจรป้อนกลับเชิงสร้างสรรค์ ซึ่งสามารถช่วยให้เข้าใจและปรับปรุงผลิตภัณฑ์ได้ดีขึ้น
• สำหรับบริษัทที่มาจากสแต็กแบบ "AI-adjacent" การอนุมานของโมเดลเฉพาะมักถูกจำกัดด้วย context window
  • บางคนเชื่อว่าเมื่อความจุของ context window เพิ่มขึ้น ก็อาจแทนที่ vector database ได้
  • อย่างไรก็ตาม มีความเป็นไปได้สูงกว่าว่าสถานการณ์ตรงกันข้ามจะเป็นจริง คือ vector database อาจวิวัฒน์จนเข้ามาแทนที่ context window ได้
  • vector embedding มีความสำคัญอย่างมากต่อโมเดลเชิงกำเนิด และอินฟราสตรักเจอร์สำหรับผลลัพธ์เชิงกำเนิดควรปฏิบัติต่อ vector embedding เสมือนเป็นพลเมืองชั้นหนึ่ง
• แทนที่จะเพิ่มขนาดของ context window เพียงอย่างเดียว สามารถฝัง vector database เข้าไปในโมเดล เพื่อให้ได้ทั้งความเข้าใจเชิงบริบทของ context window และความน่าเชื่อถือกับความสามารถในการขยายขนาดของฐานข้อมูล
  • โดยเฉพาะอย่างยิ่ง ยิ่งโมเดลมีความเป็นอเนกประสงค์มากเท่าไร ก็ยิ่งมีโอกาสน้อยลงที่จะถูกสร้างมาให้เหมาะกับงานเฉพาะด้าน
  • vector database ที่ขับเคลื่อนด้วย AI จะทำให้เกิดความสามารถที่เฉพาะเจาะจงมากขึ้น
• โมเดลอเนกประสงค์อย่าง GPT-4 ถูกสร้างขึ้นมาให้ทำการสรุปรวมความรู้ให้เป็นลักษณะทั่วไปโดยตั้งใจ
  • หากผลิตภัณฑ์พึ่งพาเพียงการ fine-tuning แบบง่ายเล็กน้อย โมเดลพื้นฐานก็จะไม่ใช่ส่วนที่มีคุณค่าเฉพาะตัวของธุรกิจนั้น
  • การสร้างผลิตภัณฑ์ที่ขับเคลื่อนด้วย AI นอกจากจะเกี่ยวข้องกับการใช้ประโยชน์จากโมเดลแล้ว ยังหมายถึงการสร้างผลิตภัณฑ์โดยมีสแต็กที่เชื่อมโยงกันอย่างใกล้ชิดมากขึ้นเป็นศูนย์กลาง
  • สแต็กนี้จะมอบทั้งขนาดในระดับฐานข้อมูลและความสามารถของโมเดล เพื่อสร้างผลิตภัณฑ์ที่มีศักยภาพสูงกว่าเดิม

[savvykang]

อยากให้มีกรณีการใช้งานการสร้างเวกเตอร์เอ็มเบดดิงและการใช้ vector DB ออกมาให้มากกว่านี้ เพื่อให้มีเวิร์กโฟลว์มาตรฐานเกิดขึ้นมา สักประมาณ 1 ปีคงต้องรอดูใช่ไหม