อย่าสร้างผลิตภัณฑ์ AI แบบเดียวกับที่คนอื่น ๆ ทำกัน
(builder.io)- ผลิตภัณฑ์ AI จำนวนมากยังคงเป็นเพียง wrapper ที่เรียกโมเดลภายนอกอย่าง ChatGPT ผ่าน API และดึงความเสี่ยงด้านความแตกต่าง ต้นทุน ความเร็ว และการปรับแต่งเข้ามาไว้ในผลิตภัณฑ์
- วิธีเรียก LLM แบบง่าย ๆ สร้างได้รวดเร็ว แต่ใคร ๆ ก็ลอกเลียนแบบได้ และหาก OpenAI ใส่ฟังก์ชันเดียวกันลงใน ChatGPT ก็ยากที่จะรักษา คุณค่าเฉพาะตัว ไว้
- LLM อเนกประสงค์มีต้นทุนการรันสูง จนอาจเกิดโครงสร้างแบบ GitHub Copilot ที่เก็บเงินเดือนละ $10 แต่มีต้นทุนเฉลี่ย $20 และผู้ใช้บางรายทำให้เกิดต้นทุนสูงสุดถึง เดือนละ $80
- Visual Copilot ของ Builder เคยลองใช้เฉพาะ LLM ในกระบวนการแปลงดีไซน์ Figma เป็นโค้ด แต่เพราะการตอบสนองล่าช้าและข้อจำกัดด้านคุณภาพ จึงเปลี่ยนไปใช้ toolchain ของตนเอง
- ในทางปฏิบัติ ควรแก้ปัญหาด้วยโค้ดทั่วไปก่อน แล้วค่อยนำโมเดล AI เฉพาะทางมาต่อเฉพาะในขอบเขตแคบ ๆ ที่โค้ดมาตรฐานจัดการได้ยาก วิธีนี้เร็วกว่า ถูกกว่า และควบคุมได้มากกว่า
ข้อจำกัดของแนวทาง LLM wrapper แบบง่าย ๆ
- ผลิตภัณฑ์ AI จำนวนมากที่กำลังถูกสร้างอยู่ในตอนนี้ใกล้เคียงกับ wrapper บนโมเดลอื่น โดยทำงานด้วยการส่งอินพุตภาษาธรรมชาติไปยัง ChatGPT API แล้วรับเอาต์พุตภาษาธรรมชาติกลับมา
- ทำได้ง่ายและสร้างฟีเจอร์ที่น่าสนใจได้รวดเร็ว แต่หากคุณค่าเฉพาะของผลิตภัณฑ์อยู่ที่เทคโนโลยี AI ขั้นสูง ความเสี่ยงที่จะถูกลอกเลียนแบบก็จะสูงขึ้น
- กระแสแบบแอปแชตกับ PDF ที่เมื่อคนหนึ่งทำแล้วหลายคนก็ทำแอปคล้าย ๆ กัน และต่อมา OpenAI ใส่เข้าไปใน ChatGPT โดยตรง เกิดขึ้นเมื่อขาดเทคโนโลยีที่แตกต่างอย่างชัดเจน
- หากผลิตภัณฑ์อยู่ในระดับที่กดปุ่มเดียวเพื่อส่งคำขอไปยัง ChatGPT แล้วแสดงคำตอบให้ผู้ใช้เห็น ก็เป็นระดับที่มีความสามารถในการป้องกันตัวเองอ่อนแอที่สุด
- หากมีเทคโนโลยีของตนเองมากพอ และ LLM ช่วยเสริมเพียงส่วนเล็ก ๆ แต่สำคัญ ก็อยู่ในตำแหน่งที่ดีกว่า แต่ปัญหาต้นทุนและความเร็วยังคงมีอยู่
ต้นทุนและความเร็วคือข้อจำกัดจริงของการทำเป็นผลิตภัณฑ์
- LLM มีขนาดใหญ่และซับซ้อนขึ้นเพื่อให้ได้ความเป็นอเนกประสงค์ในวงกว้าง และต้นทุนการรันก็สูงขึ้นตามไปด้วย
- ตามรายงานของ Wall Street Journal, GitHub Copilot เก็บเงินผู้ใช้เดือนละ $10 แต่มีต้นทุนเฉลี่ย $20 และผู้ใช้บางรายสร้างต้นทุนให้ GitHub สูงสุดถึง เดือนละ $80
- ผลิตภัณฑ์จำนวนมากไม่จำเป็นต้องใช้โมเดลขนาดยักษ์ที่เรียนรู้จากทั้งอินเทอร์เน็ต และ 99.9% ของขอบเขตการเรียนรู้อาจไม่เกี่ยวข้องกับกรณีใช้งานเฉพาะนั้นเลย
- อาจเกิดสถานการณ์ที่ต้นทุนการให้บริการบน LLM สูงกว่าจำนวนเงินที่ผู้ใช้ยินดีจ่าย
- ความเร็วก็ส่งผลอย่างมากต่อประสบการณ์ผลิตภัณฑ์
- ในประสบการณ์แบบ ChatGPT ที่อ่านคำทีละคำ เอาต์พุตที่ช้าบ้างยังพอรับได้
- แต่ในแอปที่ต้องได้คำตอบครบถ้วนก่อนจะไปยังขั้นตอนถัดไปของเวิร์กโฟลว์ ความหน่วงจะกลายเป็นการลดทอนความสามารถในการใช้งานทันที
- Visual Copilot ของ Builder พยายามใช้การแปลงด้วย LLM เพื่อเปลี่ยนดีไซน์เป็นโค้ดคุณภาพสูง แต่กระบวนการใส่สเปกดีไซน์ทั้งหมดและรับการนำเสนอใหม่แบบทีละ token ใช้เวลา หลายนาที จึงไม่เหมาะกับการใช้งานจริง
- การนำเสนอที่ LLM ส่งกลับมาไม่ได้อยู่ในรูปแบบที่มนุษย์อ่านได้ ดังนั้นสถานะการโหลดจึงใกล้เคียงกับ spinner ธรรมดา และประสบการณ์ผู้ใช้ก็ไม่ดี
การ fine-tuning เพียงอย่างเดียวไม่เพียงพอต่อการปรับแต่งให้เหมาะกับงาน
- LLM รองรับการ fine-tuning จึงสามารถปรับบางส่วนให้เข้าใกล้ทิศทางที่ต้องการได้มากขึ้น
- Builder นำ fine-tuning มาใช้กับวิธีที่ใส่ดีไซน์ Figma เป็นอินพุตแล้วให้โค้ดเป็นเอาต์พุต แต่แม้จะให้ตัวอย่างจำนวนมาก คุณภาพก็ไม่ดีขึ้น
- ผลลัพธ์คือแนวทางที่ช้า แพง และคุณภาพต่ำ จึงต้องหาวิธีอื่น
- ทางเลือกที่เลือกคือการสร้าง toolchain ของตนเอง
- LLM ที่ fine-tuned แล้ว
- คอมไพเลอร์แบบกำหนดเอง ที่เขียนเอง
- โมเดลที่ฝึกเอง
- ทุกวันนี้ การฝึกโมเดลของตนเองไม่ใช่เรื่องที่ทำได้เฉพาะ data scientist หรือ Ph.D. ด้าน machine learning เท่านั้น นักพัฒนาที่มีประสบการณ์พอเหมาะก็สามารถทำได้
- แนวทางนี้ช่วยให้สร้างผลิตภัณฑ์ที่เร็วกว่า เชื่อถือได้กว่า ถูกกว่า และแตกต่างได้มากกว่า
ผลิตภัณฑ์ AI ที่ซับซ้อนประกอบด้วย toolchain ไม่ใช่โมเดลยักษ์เพียงตัวเดียว
- ความเข้าใจผิดที่พบบ่อยเกี่ยวกับผลิตภัณฑ์ AI คือคิดว่าเทคโนโลยีหลักทั้งหมดถูกจัดการโดยโมเดลอัจฉริยะเพียงตัวเดียว
- รถยนต์ไร้คนขับก็ไม่ได้มีโครงสร้างที่ส่งอินพุตจากกล้อง เซนเซอร์ และ GPS เข้า AI ขนาดยักษ์เพียงตัวเดียว แล้วส่งออกเป็นการกระทำอย่างเลี้ยวขวาทันที
- ในความเป็นจริง โมเดลเฉพาะทาง หลายตัวและโค้ดทั่วไปถูกเชื่อมเข้าด้วยกัน
- โมเดล computer vision ค้นหาและระบุวัตถุ
- โมเดลตัดสินใจเชิงคาดการณ์คาดเดาการกระทำของผู้อื่น
- โมเดล natural language processing เข้าใจคำสั่งเสียง
- โค้ดและลอจิกทั่วไปจำนวนมากสร้างผลลัพธ์สุดท้าย
- รถยนต์ไร้คนขับเป็นกรณีที่ซับซ้อนกว่ามาก และเมื่อเริ่มผลิตภัณฑ์ AI ทั่วไปก็ไม่จำเป็นต้องมีความซับซ้อนระดับนั้น
- ฟังก์ชันของรถยนต์ไม่ได้เสร็จสมบูรณ์ในครั้งเดียวเช่นกัน แต่เริ่มจากฟังก์ชันอย่างจอดรถอัตโนมัติหรือหยุดอัตโนมัติเมื่อเข้าใกล้วัตถุ แล้วค่อยเพิ่มเลเยอร์อย่างการแก้การออกนอกเลนและการตัดสินใจขับขี่ทั้งหมด
- เช่นเดียวกับซอฟต์แวร์ ฟังก์ชัน AI ถูกสร้างด้วยการวางเลเยอร์ถัดไปบนเลเยอร์ก่อนหน้า
แก้ด้วยโค้ดทั่วไปก่อน แล้วค่อยต่อ AI เฉพาะทางเฉพาะจุดที่จำเป็น
- จุดเริ่มต้นสำคัญของแนวทาง Visual Copilot คือการไม่ใช้ AI ตั้งแต่แรก
- ต้องสำรวจพื้นที่ปัญหาด้วยวิธีเขียนโปรแกรมทั่วไปก่อน แล้วหาก่อนว่าพื้นที่ใดกันแน่ที่ต้องใช้ โมเดลเฉพาะทาง
- แนวทาง “ซูเปอร์โมเดล” ที่ใส่ข้อมูล Figma จำนวนมากเข้าโมเดลแล้วรับโค้ดสำเร็จรูปกลับมาทันทีนั้นซับซ้อนเกินไป
- มีเฟรมเวิร์กหลากหลายที่ต้องรองรับ
- มีตัวเลือก styling และการปรับแต่งจำนวนมาก
- การฝึกซ้ำอย่างต่อเนื่องเพื่อสะท้อนข้อมูลใหม่ทำได้ยาก
- อาจซับซ้อน ช้า และแพงจนทำให้การเปิดตัวผลิตภัณฑ์เองเป็นเรื่องยาก
- Builder สำรวจก่อนว่าไปได้ไกลแค่ไหนโดยไม่ใช้ AI
- ต้องแปลงแต่ละ design node ให้เป็นสิ่งที่แสดงด้วยโค้ดได้
- ต้องเข้าใจองค์ประกอบอย่างละเอียด เช่น รูปภาพ พื้นหลัง และ foreground
- ต้องจัดการอย่างประณีตกับวิธีทำให้อินพุตใด ๆ ก็ตามเป็นแบบ responsive
- สร้างอัลกอริทึมที่ประณีตหลายอย่างด้วยลอจิกที่เขียนด้วยมือ เช่น รายการที่ซ้อนกันในแนวตั้งให้กลายเป็น flex column และรายการที่วางข้างกันให้กลายเป็น flex row
- เพิ่ม AI ในจุดที่ถึงขีดจำกัดของโค้ดมาตรฐาน
- ปัญหาการตรวจจับอัตโนมัติว่าควรรวมเลเยอร์ใดบ้างเป็นรูปภาพเดียว เป็นเรื่องง่ายสำหรับการรับรู้ของมนุษย์ แต่ไม่ง่ายสำหรับโค้ด JavaScript แบบ imperative
- ประเภทโมเดลที่มีรากฐานชัดเจนอย่าง object detection สามารถฝึกได้ในผลิตภัณฑ์อย่าง Google Vertex AI โดยเลือกผ่าน GUI เตรียมข้อมูล และอัปโหลด
- สามารถใช้อินเทอร์เน็ตในการสร้างข้อมูลได้
- ใช้ puppeteer เปิดเว็บไซต์ในเบราว์เซอร์แล้วถ่าย screenshot
- ไล่ดู HTML เพื่อหาแท็ก
img - ใช้ตำแหน่งของรูปภาพเป็นข้อมูลเอาต์พุต และใช้ screenshot ของหน้าเว็บเป็นข้อมูลอินพุต
- วิธีนี้ช่วยให้ได้พิกัดของรูปภาพย่อยและรูปภาพต้นฉบับ เพื่อนำไปใช้เป็นข้อมูลฝึกโมเดล object detection
- เมื่อผสานโค้ดกับโมเดล AI เฉพาะทาง ก็สามารถเลือกดีไซน์ คลิก Generate code แล้วรอประมาณ 1 วินาทีก่อนย้ายไปยัง Builder.io
- ใน Builder ผู้ใช้จะได้เว็บไซต์ที่ responsive อย่างสมบูรณ์และโค้ดคุณภาพสูงที่ปรับแต่งได้ พร้อมรองรับเฟรมเวิร์กและตัวเลือกที่หลากหลาย
ข้อได้เปรียบด้านผลิตภัณฑ์เมื่อควบคุมโมเดลของตนเอง
- เมื่อมีโมเดลของตนเอง ก็ไม่จบเพียงการห่อโมเดลภายนอกไว้เฉย ๆ แต่สามารถปรับปรุงโมเดลต่อเนื่องได้
- หากพึ่งพาเฉพาะโมเดลภายนอกอย่าง OpenAI ก็ไม่สามารถรับประกันได้ว่าเมื่อใดมันจะฉลาดขึ้น เร็วขึ้น หรือถูกลงสำหรับกรณีใช้งานเฉพาะ
- ขอบเขตที่ควบคุมได้ด้วย prompt engineering และ fine-tuning เพียงอย่างเดียวก็มีจำกัด
- Visual Copilot ยังอยู่ในสถานะ beta จึงยังมีดีไซน์บางแบบที่นำเข้าได้ไม่ดี และมีการปล่อยการปรับปรุงทุกวันตาม feedback ของผู้ใช้
- เมื่อควบคุมเทคโนโลยีของตนเอง ก็สามารถตอบโจทย์ด้าน privacy ได้ดีกว่า
- บริษัทขนาดใหญ่ที่เน้น privacy มักให้ feedback ว่าไม่สามารถใช้ OpenAI หรือผลิตภัณฑ์ที่ใช้ OpenAI ได้
- มีข้อกำหนดว่าข้อมูลต้องไม่เข้าไปในระบบที่ไม่ได้รับอนุญาต
- Builder ควบคุมเทคโนโลยีทั้งหมด จึงสามารถใช้มาตรฐาน privacy ระดับสูงได้
- ขั้นตอน LLM ไม่ใช่สิ่งจำเป็น แต่ใกล้เคียงกับตัวเลือก จึงสามารถปิดได้
- องค์กรสามารถเชื่อมต่อ LLM ของตนเองได้เช่นกัน
- โมเดลภายในองค์กรเต็มรูปแบบ
- fork ของ
llama2 - อินสแตนซ์ OpenAI ระดับ enterprise ของตนเอง
- โมเดลอื่น ๆ
- ควรใช้ AI ให้น้อยที่สุดเท่าที่เป็นไปได้ และให้โค้ดทั่วไปยังคงเป็นฐานที่เร็ว เชื่อถือได้ กำหนดผลลัพธ์ได้แน่นอน และง่ายต่อการดีบัก แก้ไข จัดการ และทดสอบ
- เวทมนตร์ของผลิตภัณฑ์ไม่ได้เกิดจากการแทนที่ทุกอย่างด้วย AI แต่เกิดจากการใช้โมเดล AI ในพื้นที่เล็ก ๆ แต่ชี้ขาด
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
แม้จะเห็นด้วยกับเจตนาโดยรวมของบทความ แต่ผมคงไม่เลือกแนวทางการนำไปใช้ที่ผู้เขียนเสนอ
ข้อสรุปที่ผมได้คืออย่าพึ่งพา LLM มากเกินไป ทั้งในแง่ขอบเขตงานที่มอบหมายให้ทำ และควรหลีกเลี่ยงการผูกติดกับ LLM ตัวใดตัวหนึ่ง
ตัวอย่างเช่น แม้จะใช้ OpenAI ภายใน แต่ผลิตภัณฑ์ที่ แข่งขันตรงกับ ChatGPT อาจเสียเปรียบในระยะยาว หากสร้างแอปสำหรับจองโรงแรมและตั๋วเครื่องบินด้วยแชตบอต สักวันหนึ่ง ChatGPT หรือ Microsoft, Google อาจให้ฟีเจอร์คล้ายกันได้ดีกว่า จนทำให้ธุรกิจเล็ก ๆ หมดพลังในการแข่งขันได้
ผมมองว่าการพึ่งพาสิ่งอย่าง OpenAI SDK มากเกินไปก็เป็นการเสียเวลา และการเรียก REST API โดยตรงยืดหยุ่นกว่า
อย่างไรก็ตาม การเพิ่มคอมไพเลอร์เข้าไปใน toolchain เป็นอีกประเด็นหนึ่ง ทุกครั้งที่ใส่คอมไพเลอร์เข้าไป ความซับซ้อนที่ไม่จำเป็นและการพึ่งพาเครื่องมือเฉพาะก็เพิ่มขึ้น การใช้คอมไพเลอร์ข้ามคอมโพเนนต์ ทั้งที่ React หรือ Svelte ก็เพียงพอแล้ว ดูเหมือนเป็นการเพิ่มอีกสิ่งหนึ่งที่ต้องเรียนรู้เพื่อสร้างเว็บแอป
ผมคิดว่าข้อความสุดท้ายของบทความควรเป็น “จงสร้าง toolchain ที่มีประสิทธิภาพที่สุดในการบรรลุเป้าหมาย” การใส่เครื่องมือเยอะ ๆ ไม่ได้สร้างคุณค่า และการทำตามวิธีที่คนอื่นทำก็ไม่ได้สร้างคุณค่าเช่นกัน เรื่องนี้ไม่ได้ใช้ได้แค่กับการผสาน LLM เข้ากับแอป แต่รวมถึงวิศวกรรมซอฟต์แวร์โดยรวมด้วย
ผมไม่ค่อยแน่ใจว่า AI จะทำให้สิ่งนี้ต่างออกไปอย่างไร หรือสุดท้ายจะไม่ชนข้อจำกัดเดิม ๆ หรือไม่
มันคงมีเอกลักษณ์และไม่ถูกลอกเลียนแบบได้ง่าย แต่ถ้าคิดถึงภาษาที่ต้องรองรับ ค่าใช้จ่ายในการบำรุงรักษาน่าจะมหาศาล
ชั้น abstraction ที่เพิ่มเข้ามานี้ให้ความรู้สึกแบบ factory-factory-factory อยู่บ้าง
ในทางกลับกัน AI ยังมีพื้นที่ให้เฉพาะทางได้มากกว่าการค้นหาตั๋วเครื่องบินเสียอีก
สำหรับแชตบอตงานเฉพาะทาง เมื่อการตีความภาษาพื้นฐานดีพอแล้ว คุณภาพของโมเดลภาษาทั่วไปก็ไม่ใช่ปัจจัยสำคัญที่สุด แชตบอตจองทริปที่ปรับให้เข้ากับรสนิยมของผมและเชื่อมกับ API เฉพาะทางที่เกี่ยวข้อง จะไม่ถูกเครื่องมือทั่วไปที่แยกวิเคราะห์คำถามได้ดีกว่านิดหน่อยแต่พยายามจองทุกอย่างผ่าน Expedia เอาชนะได้ง่าย ๆ
ในตลาดแบบนี้ แค่ได้รับคำแนะนำที่ดีหรือแย่ครั้งเดียวก็ทำให้เกิด ความภักดีต่อแบรนด์ หรือความรู้สึกต่อต้านได้ จึงยากจะมองว่าใกล้เคียงกับตลาดแบบผู้ชนะกินรวบ
แก่นของบล็อกโพสต์จริง ๆ แล้วไม่ใช่เรื่องนั้น
ผลิตภัณฑ์ของพวกเขาคือเครื่องมือที่แปลงไฟล์ออกแบบ Figma เป็นโค้ด React โดยอัตโนมัติ วิธีแก้ปัญหานี้ด้วยโค้ดธรรมดาก็คือ คอมไพเลอร์ นั่นเอง
ไม่ได้บอกให้ทุกคนใช้คอมไพเลอร์
ในบริบทนี้ การวิจารณ์คอมไพเลอร์โดยทั่วไปจึงไม่ค่อยตรงประเด็น ทางเลือกคือใช้ ChatGPT เหมือนเป็นคอมไพเลอร์ ซึ่งบทความอธิบายไว้ค่อนข้างน่าเชื่อว่านั่นแย่กว่า หรือไม่ก็สงสัยว่าหมายถึงตัวผลิตภัณฑ์ที่สร้างโค้ด React เองนั้นแย่หรือเปล่า
เป็นบทความที่ให้ประเด็นชวนคิด และผมเห็นด้วยกับใจความที่ว่า “อย่าใช้ AI ให้นานที่สุดเท่าที่จะทำได้”
AI เหมาะที่สุดสำหรับใช้กับ งานที่ทำได้ด้วย AI เท่านั้น ถ้ามีวิธีสร้างฟีเจอร์หรือแก้ปัญหาได้โดยไม่ใช้ AI ก็ควรทำแบบนั้น
ตอนนี้ทุกคนเข้าถึงโมเดลระดับท็อปได้แทบจะใกล้เคียงกันแล้ว ผลิตภัณฑ์ที่ดีจึงหนีไม่พ้นต้องถูกนิยามด้วยสิ่งที่ไม่ใช่ AI นั่นคือองค์ประกอบแบบดั้งเดิมอย่าง workflow, UI, ประสบการณ์ผู้ใช้ และประสิทธิภาพ
แต่ผมยังไม่มั่นใจกับคำแนะนำที่ว่า “จงฝึกโมเดลของตัวเอง” นั่นอาจเป็นทางที่ทำให้ผลิตภัณฑ์ล้าสมัยอย่างรวดเร็วได้ แม้อาจสร้างความแตกต่างได้ชั่วคราว แต่ถ้าภายใน 6–12 เดือน OpenAI หรือคู่แข่งที่มีเงินทุนมหาศาลออกโมเดลที่ดีกว่ามากมา โมเดลที่แตกต่าง นั้นก็จะกลายเป็นหนี้ทางเทคนิคทันที
การที่สตาร์ทอัพเล็ก ๆ พยายามแข่งด้วยโมเดลดูเหมือนเป็นสิ่งเบี่ยงเบนความสนใจครั้งใหญ่ คล้ายกับการสร้างฐานข้อมูลเองแทนที่จะใช้ Postgres หรือ MySQL แน่นอนว่าจำเป็นต้องมี moat และผลิตภัณฑ์ที่ลอกเลียนแบบได้ยาก แต่ควรเป็นพื้นที่ที่ทรัพยากรที่มีอยู่ทำให้คุณมีโอกาสเป็นที่สุดได้จริง
จากนั้นเมื่อ ChatGPT ออกมา งานของคู่แข่งก็ล้าสมัยในพริบตา และเขาสามารถไล่ตามฟีเจอร์ AI ได้ภายในไม่กี่สัปดาห์
เขาเดาถูกว่าควรสร้างอะไร แต่เหตุผลผิด และสุดท้ายมันกลายเป็นประโยชน์มหาศาลต่อธุรกิจ
ความแตกต่างเป็นปัจจัยที่ค่อนข้างสำคัญจริง ๆ
เป็นบทความที่ดี และน่าจะโดนใจสตาร์ทอัป AI ใหม่ ๆ ส่วนใหญ่ คำแนะนำของผมคืออย่าสร้าง ผลิตภัณฑ์ AI ไปเลย
กรอบความคิดแบบ “ผลิตภัณฑ์ X” แทบไม่ค่อยนำไปสู่การเพิ่มคุณค่าให้ลูกค้า เช่น ผลิตภัณฑ์ web3, ผลิตภัณฑ์ observability, ผลิตภัณฑ์ machine vision, ผลิตภัณฑ์ AI อะไรทำนองนี้
เช่นเดียวกับไอเดียสตาร์ทอัปที่ดีทั้งหลาย แก่นสำคัญคือการเริ่มจาก ความต้องการจริงของผู้ใช้ ไม่ใช่การอยากใช้เทคโนโลยีเกิดใหม่แล้วเอาปัญหามายัดให้เข้ากัน การเอา UI ไปครอบเทคโนโลยีที่ถูกคาดหวังเกินจริงไม่ได้ทำให้ความต้องการของผู้ใช้ได้รับการตอบสนอง
ไม่ได้พูดเพราะเกลียด LLM แต่คนส่วนใหญ่ที่ผมรู้จักออฟไลน์ไม่ชอบโต้ตอบกับแชตบอตในฐานะผลิตภัณฑ์ ช่วงที่ย้ายบ้านเมื่อไม่นานนี้ ผมต้องคุยกับบอตบริการลูกค้าของผู้ให้บริการพลังงาน น้ำประปา และอินเทอร์เน็ต ซึ่งทั้งหมดแย่มาก
ผมคิดว่าการเริ่มจาก “GPT เจ๋งดี” แล้วไปสร้างแชตบอตแบบปรับแต่งเองนั้นยากที่จะช่วยแก้ความต้องการจริงของผู้ใช้หรือกลายเป็นธุรกิจที่ยั่งยืน
แค่การค้นพบปัญหาที่เป็นจริงพอจะคุ้มต้นทุนทางเทคโนโลยี ก็อยู่นอก comfort zone ของนักเทคโนโลยีจำนวนมากแล้ว เรามักสมมติว่าปัญหานั้นมีอยู่จริง หรือแย่กว่านั้นคือหวังให้มันเป็นจริง แล้วกระโดดเข้าไปแก้ทันที เพราะการสร้างคือพื้นที่ที่เราคุ้นเคย
ท่าทีหรือกระบวนการแบบนี้ไม่ได้ผิดโดยตัวมันเอง ในหลายกรณีที่นักเทคโนโลยีแก้ปัญหาจริงได้ ปัญหาจริงนั้นมักเผยตัวขึ้นโดยบังเอิญระหว่างการสร้าง ทำซ้ำ และหยุดทำ
ดังนั้นสำหรับนักเทคโนโลยี วิธีที่ดีที่สุดในการหาปัญหาจริงอาจไม่ใช่การจมอยู่กับการค้นหาปัญหานาน ๆ แต่คือการมี วงจรเปิดตัว-ทำซ้ำ-หยุดทำ ที่ดีกว่า เป็นวงจรที่ดูการใช้งานปัจจุบันแล้วประเมินอนาคต และตัดสินใจอย่างรวดเร็วว่าอะไรควรหรือไม่ควรสร้าง
หลังจากอ่านชีวประวัติของผู้นำเทคโนโลยีหลายคน ผมเริ่มมองว่าความสามารถหลักที่แยกพวกเขาออกจากกันคือความสามารถในการเริ่มจาก MVP ที่พื้นฐานมาก ๆ แล้วขัดเกลาสัญชาตญาณต่ออุปสงค์ในอนาคตได้อย่างก้าวกระโดดภายในเวลาอันสั้น
เมื่อไม่กี่ปีก่อนก็มีแชตบอตอยู่แล้ว และแทบทุกองค์กรขนาดใหญ่ก็เคยมีกลยุทธ์เกี่ยวกับมัน แนวคิดคือจะลดจำนวนพนักงานคอลเซ็นเตอร์ได้มากและปรับปรุงประสบการณ์ลูกค้า
ปัญหาไม่ได้อยู่ที่คุณภาพของบทสนทนาเท่านั้น สำหรับผู้ใช้จำนวนมาก สิ่งสำคัญไม่ใช่แค่การได้คำตอบของปัญหา แต่ยังเป็น ความรู้สึกเชื่อมโยงแบบมนุษย์ ว่ามีคนกำลังรับฟังอยู่
สิ่งที่ต้องการคือให้งานถูกจัดการให้เร็วที่สุด ไม่ได้สำคัญว่าจะได้คุยกับคนจริงหรือไม่
เหตุผลที่แชตบอตที่ผ่านมาไม่ช่วย ก็เพราะมันเพิ่มเวลาและความหงุดหงิดเข้าไปในกระบวนการ ขั้นแรกกลายเป็นการทำให้แชตบอตคายเบอร์โทรออกมา หรือพยายามให้มันต่อสายไปยังเจ้าหน้าที่ให้ได้
แน่นอนว่าแชตบอตก่อนยุค OpenAI นั้นห่วยแตก แต่ถ้าแชตบอตหลังยุค OpenAI ดีจริง ๆ ผมก็ไม่เห็นเหตุผลว่าทำไมผู้คนจะไม่ใช้
เมื่อไม่กี่ปีก่อนก็เป็นบล็อกเชน ส่วนต่อไปจะเป็นอะไรผมไม่รู้ แต่เห็นแล้วว่าเครือข่าย “คนสายเทค” บน LinkedIn ได้ย้ายจากสตาร์ทอัปคริปโตไปยังสตาร์ทอัป AI แล้ว
ดูเหมือนเป็นการแลกกับความเร็วในการเปิดตัวอย่างมาก
เมื่อใช้เวลา 6–12 เดือนกว่าจะเปิดตัว ทีมอื่นอาจใช้โมเดลแบบโฮสต์โดยตรง ทำซ้ำไปแล้วสองรอบ และสร้างฐานลูกค้าจริงได้แล้ว ถึงตอนนั้นคุณเพิ่งเอา v0.1 ไปให้ลูกค้ารายแรกดู แล้วลูกค้าอาจบอกว่าจริง ๆ แล้วเขาต้องการอย่างอื่น
จากนั้นก็ไม่ใช่แค่ปรับพรอมป์เล็กน้อย แต่ต้องเขียน คอมไพเลอร์และ toolchain รวมถึงโค้ดทั้งบนและล่างของสแต็กใหม่
ถ้าคุณรู้จักลูกค้าและข้อกำหนดดีจริง ๆ ก็อาจสมเหตุสมผล แต่ในสถานการณ์ที่ทำได้ง่ายแบบนี้ ผมกลับยิ่งสงสัยว่าทำไมไม่ตรวจสอบแนวคิดตั้งแต่เนิ่น ๆ ด้วยโมเดลแบบโฮสต์ ถึงจะเป็นแบบทั่วไปและแพงก็ตาม เป็นปัญหาประมาณว่า การปรับแต่งก่อนเวลาอันควร คือรากเหง้าของความชั่วร้ายทั้งปวง
มีการพูดเรื่องเทคโนโลยีและ pipeline มากมาย แต่ถ้าไม่มีผลิตภัณฑ์ที่จะสร้างและปัญหาที่จะแก้ มันก็ไม่มีความหมาย
คล้ายกับการเถียงกับผู้ใช้ว่า SOAP ดีกว่าหรือ REST ดีกว่า ผู้ใช้ไม่สนใจว่าคุณสร้างมันอย่างไร
คิดมากเกินไปในมุมการแข่งขัน แค่สร้างสิ่งที่ ไม่ถูกลอกเลียนแบบได้ง่าย ก็พอ
วิธีมีหลายแบบ แต่จากมุมการแข่งขัน กฎที่จำเป็นมีแค่นั้นข้อเดียว
ในเกือบทุกตลาดแนวตั้ง ส่วนที่ใกล้เคียง 100% ของตลาดทั้งหมดยังเปิดอยู่
ความแตกต่างทางเทคนิคเป็นเพียงชิ้นส่วนเล็ก ๆ และผมมองว่าสิ่งที่สำคัญก่อนคือ การเข้าถึง
นี่คือการแข่งขันไปสู่ผู้ใช้ 1 พันล้านคน และถ้าเป็น B2B แบบพวกเรา ก็คงเป็นการแข่งขันไปสู่ผู้ใช้ 1 ล้านคน ขณะเดียวกันก็เป็นการแข่งขันเรื่องคุณค่าสูงสุด คือปัญหาที่ถูกแก้และประสบการณ์ผู้ใช้ ไม่ใช่การแข่งขันสเปกทางเทคนิคที่ดีที่สุด
ถ้าจุดต่างของคุณคือสิ่งที่คนอื่นไม่สามารถใช้ OAI มาลอกได้ การใช้ OAI ก็ปลอดภัย
ถ้าจุดต่างเพียงอย่างเดียวคือการใช้ OAI ยังไงก็จบอยู่ดี
โดยสรุป ผมเห็นด้วยโดยรวมกับสถานะที่นำเสนอ ผลิตภัณฑ์ของเราก็ใช้ LLM ภายใน control flow แบบ state machine และทำงานได้ดี
แต่ผมไม่เห็นด้วยกับอารมณ์ความรู้สึกของผู้เขียน ถ้าคุณเป็นนักพัฒนาที่เคยใช้แค่เว็บ UI ของ ChatGPT ก็ควรลองจับและสร้างเทคโนโลยี “AI wrapper” ให้เต็มที่ 100%
เพราะก่อนจะค้นพบขีดจำกัดของโมเดลระดับท็อปด้วยตัวเอง ก็ยากที่จะมองเห็นว่าควรใช้ LLM ตรงไหนและอย่างไรภายในสแต็กซอฟต์แวร์แบบดั้งเดิม
บริษัทของผู้เขียนเองก็ดูเหมือนจะเดินเส้นทางนี้ในท้ายที่สุด ช่วงแรกสร้างต้นแบบที่ใช้ LLM แปลงจาก Figma เป็นโค้ด และหลังจากมันทำงานได้ “ในระดับหนึ่ง” ก็พบช่องโหว่ในกระบวนการ
ดังนั้นผมคิดว่าลองสร้างอะไรก็ได้ที่อยากทำด้วยของอย่าง GPT-4-Vision เช่น “ระบบให้เกรดการ์ดสะสมด้วย AI” แล้วจากนั้นค่อยหาวิธีทำให้มันกลายเป็นผลิตภัณฑ์จริงที่ใช้งานได้แบบ builder.io จะดีกว่า
ดูเหมือนว่าอีกไม่นาน AI จะถูกฝังอยู่ในซอฟต์แวร์หลาย ๆ ตัว ตอนนั้นมันคงทั้งเจ๋งมากและน่ากลัวมาก
ตัวอย่างง่าย ๆ คือ ไคลเอนต์อีเมล เมื่อมีใครขอให้ตัดสินใจหรือยืนยันอะไรบางอย่าง AI ก็อาจดึงคำถามออกมาแล้วแสดงเป็นปุ่มตัวเลือกให้ได้
ตัวอย่าง: ยอมรับเวลานัดหมายที่เสนอ: [ศุกร์ 10:00] [จันทร์ 11:30] [เสนอเวลาอื่น]
George กำลังถามว่าสามารถนำเสนอร่างฉบับแรกได้ไหม: [ได้] [ไม่ได้]
ดูเหมือนว่าซอฟต์แวร์ทิกเก็ตซัพพอร์ตลูกค้าอย่าง Zendesk จะมี AI อยู่แล้ว เป็นไปได้สูงว่าคำขอซัพพอร์ตจำนวนมากแทบจะถูกตอบโดยอัตโนมัติไปแล้ว
ฝ่าย HR ก็อาจใช้ AI คัดกรองใบสมัครงาน ให้ไปค้นข้อมูลเพิ่มเติมเกี่ยวกับผู้สมัครบนอินเทอร์เน็ต แล้วสร้างรายการฐานข้อมูลแบบมาตรฐานได้ แน่นอนว่ามันอาจมีข้อบกพร่องมากมาย
สิ่งที่น่าสนใจคือแอปพลิเคชันประเภทนี้ ไม่ใช่ส่วนขยายหรือปลั๊กอิน ChatGPT อีกตัวหนึ่ง
ตั้งใจว่าจะให้รัน pipeline กับอีเมลใหม่ทุกฉบับ เพื่อเสนอการกระทำบางอย่าง
ยังหมุนหลายแนวทางอยู่ในหัว แต่ดูเหมือนว่ามันเป็นไปได้มากพอแล้ว
บทนำดูใช้สำนวนหรูหราและโอ้อวดเกินไปหน่อย เช่น LLM ก็ไม่ได้แพงขนาดนั้น ข้ออ้างของ WSJ ที่ว่า Copilot ขาดทุนต่อผู้ใช้ก็ไม่ค่อยน่าเชื่อ และจะมองว่า LLM “ช้าจนทรมาน” เสมอก็คงยาก
ถึงอย่างนั้น คำแนะนำจริง ๆ ในบทความก็ค่อนข้างสมเหตุสมผล
คือให้จัดการส่วนต่าง ๆ ให้มากที่สุดเท่าที่ทำได้ด้วยโค้ด และใช้ AI เฉพาะทาง กับส่วนที่ทำด้วยโค้ดไม่ได้
สมเหตุสมผล แต่ก็ไม่ใช่เรื่องใหม่เป็นพิเศษ
ผมคาดหวังว่าจะลงลึกกว่านี้ว่าเราจะสร้างผลิตภัณฑ์ AI ที่มีประโยชน์และดีจริง ๆ ได้อย่างไร ช่วงหลังมีความพยายามแบบการเปิดตัว Humane อยู่มาก แต่ยังไม่ค่อยเห็นความสำเร็จมากนัก
บทความนี้ค่อนข้างโฟกัสที่ว่าจะสร้างผลิตภัณฑ์ AI อย่างไร แต่ส่วนตัวผมมองว่าความสำเร็จหรือความล้มเหลวของ “ผลิตภัณฑ์ AI” ขึ้นอยู่กับว่า มันมีประโยชน์จริงไหม มากกว่าความแตกต่าง ต้นทุน ความเร็ว หรือการปรับโมเดลให้เหมาะกับงาน
น่าเสียดายที่ผลิตภัณฑ์ส่วนใหญ่ที่เห็นจนถึงตอนนี้ให้ความรู้สึกเหมือนเป็นคำตอบที่กำลังมองหาปัญหา
ผมคิดว่าทางที่บริษัทต่าง ๆ ควรไปตอนนี้คือหาส่วนที่น่าเบื่อและซ้ำซากที่สุดเวลาผู้ใช้ใช้ผลิตภัณฑ์ แล้วหาวิธีใช้ AI ทำให้มันง่ายลงอย่างเสถียร
เช่นเดียวกับทุกวงจรความร้อนแรง ถ้ามีแค่ค้อน ทุกอย่างก็ดูเหมือนตะปู
ค้อนเมื่อไม่นานมานี้คือ บล็อกเชน และตอนนี้คือ AI
ถ้าคุณไร้เดียงสาพอที่จะหลงเชื่อคำสัญญาของบล็อกเชน ก็เป็นเรื่องธรรมดาที่จะผิดหวังเมื่อ AI ไม่ใช่พีระมิดรวยเร็วที่จะทำเงินให้คุณหลายล้านดอลลาร์โดยไม่ต้องใช้เวลา พลังงาน หรือความคิดริเริ่ม
ถ้าคุณมองหาแต่สิ่งแบบนั้น คุณก็จะผิดหวังต่อไป และก็สมควรแล้ว
AI มีอะไรมากกว่าบล็อกเชนมาก การเอาสองอย่างนี้มาเทียบชั้นกันหมายความว่าคุณไม่ได้เข้าใจอย่างถูกต้องเลยสักอย่าง