อาจเกิดการเปลี่ยนแปลงครั้งใหญ่ในขอบเขตเฉพาะทางของปัญญาประดิษฐ์ที่ปรับแต่งมาเพื่องานเขียนโค้ด เป็นเวลานานแล้วที่โมเดลซึ่งพัฒนาโดย Anthropic โดยเฉพาะซีรีส์ Claude มักถูกอ้างถึงว่าเป็นผู้นำในการช่วยเหลือนักพัฒนาในการเขียน แก้จุดบกพร่อง และทำความเข้าใจโค้ด อย่างไรก็ตาม พัฒนาการล่าสุดชี้ให้เห็นว่ามีผู้ท้าชิงรายใหม่ที่น่าเกรงขามได้เข้ามาสู่สังเวียนแล้ว นั่นคือ Gemini 2.5 ของ Google สัญญาณเบื้องต้น รวมถึงประสิทธิภาพจาก benchmark และเสียงตอบรับจากนักพัฒนาในช่วงแรก ชี้ไปที่การที่เวอร์ชันล่าสุดนี้อาจกำหนดมาตรฐานใหม่สำหรับผู้ช่วยเขียนโค้ดที่ขับเคลื่อนด้วย AI ทำให้เกิดคำถามว่าลำดับชั้นที่เป็นที่ยอมรับกำลังจะถูกสับเปลี่ยนหรือไม่ การเกิดขึ้นของ Gemini 2.5 Pro Experimental โดยเฉพาะ กำลังจุดประกายการสนทนาและการเปรียบเทียบอย่างเข้มข้นในชุมชนนักพัฒนา
ความสามารถด้าน Benchmarking: ความได้เปรียบเชิงปริมาณ?
ตัวชี้วัดเชิงวัตถุวิสัยมักให้ภาพรวมแรกเกี่ยวกับความสามารถของโมเดลใหม่ และในแง่นี้ Gemini 2.5 ได้เปิดตัวอย่างน่าประทับใจ การประเมินที่เกี่ยวข้องอย่างยิ่งอย่างหนึ่งคือ Aider Polyglot leaderboard ซึ่งเป็น benchmark ที่ออกแบบมาอย่างพิถีพิถันเพื่อประเมินความเชี่ยวชาญของแบบจำลองภาษาขนาดใหญ่ (LLMs) ในงานเชิงปฏิบัติของการสร้างโค้ดใหม่และการแก้ไข codebase ที่มีอยู่เดิมในภาษาโปรแกรมต่างๆ ภายในการประเมินที่ท้าทายนี้ Gemini 2.5 Pro เวอร์ชันทดลองทำคะแนนได้อย่างน่าทึ่งถึง 72.9% ตัวเลขนี้ทำให้มันนำหน้าคู่แข่งที่แข็งแกร่งอย่างเห็นได้ชัด รวมถึง Claude 3.7 Sonnet ของ Anthropic ซึ่งได้คะแนน 64.9% นอกจากนี้ยังเหนือกว่าข้อเสนอจาก OpenAI เช่น โมเดล o1 (61.7%) และ o3-mini high variant (60.4%) การนำหน้าใน benchmark ที่เน้นการเขียนโค้ดโดยเฉพาะเช่นนี้เป็นข้อโต้แย้งเชิงปริมาณที่แข็งแกร่งสำหรับความถนัดของ Gemini 2.5 ในสาขานี้
นอกเหนือจากการประเมินที่เน้นการเขียนโค้ดแล้ว Gemini 2.5 ยังแสดงให้เห็นถึงประสิทธิภาพที่ยอดเยี่ยมในการทดสอบที่กว้างขึ้นเกี่ยวกับการให้เหตุผลและการประยุกต์ใช้ความรู้ มันคว้าอันดับสูงสุดใน benchmark GPQA (Graduate-Level Google-Proof Q&A) ซึ่งเป็นการทดสอบที่เข้มงวดซึ่งท้าทายโมเดล AI ด้วยคำถามที่ซับซ้อนครอบคลุมสาขาวิชาวิทยาศาสตร์ต่างๆ ที่มักพบในระดับบัณฑิตศึกษา Gemini 2.5 ได้คะแนน 83% ใน benchmark นี้ ประสิทธิภาพนี้เหนือกว่าโมเดล o1-Pro ของ OpenAI ซึ่งได้คะแนน 79% และ Claude 3.7 Sonnet ของ Anthropic ที่ได้ 77% แม้จะใช้เทคนิคการขยายเวลาคิดก็ตาม การจัดอันดับสูงอย่างสม่ำเสมอใน benchmark ที่หลากหลาย รวมถึงการทดสอบการให้เหตุผลทั่วไปควบคู่ไปกับทักษะเฉพาะทางเช่นการเขียนโค้ด ชี้ให้เห็นถึงสถาปัตยกรรมพื้นฐานที่แข็งแกร่งและหลากหลาย การผสมผสานระหว่างความสามารถในการเขียนโค้ดเฉพาะทางและความสามารถทางปัญญาที่กว้างขวางนี้อาจเป็นตัวสร้างความแตกต่างที่สำคัญสำหรับนักพัฒนาที่กำลังมองหาผู้ช่วย AI ที่ครอบคลุม
เสียงชื่นชมจากนักพัฒนาและการตรวจสอบในโลกแห่งความเป็นจริง
ในขณะที่ benchmark ให้ข้อมูลเชิงลึกเชิงปริมาณที่มีค่า การทดสอบที่แท้จริงของผู้ช่วยเขียนโค้ด AI อยู่ที่การประยุกต์ใช้จริงโดยนักพัฒนาที่จัดการกับโครงการในโลกแห่งความเป็นจริง รายงานและคำรับรองเบื้องต้นชี้ให้เห็นว่า Gemini 2.5 ไม่เพียงแต่ทำงานได้ดีในการทดสอบที่มีการควบคุมเท่านั้น แต่ยังสร้างความประทับใจให้กับผู้ใช้ในเวิร์กโฟลว์ประจำวันของพวกเขาด้วย Mckay Wrigley นักพัฒนาที่กำลังทดลองใช้โมเดลใหม่อย่างแข็งขัน ได้ให้การรับรองอย่างหนักแน่น โดยระบุอย่างชัดเจนว่า “Gemini 2.5 Pro ตอนนี้เป็นโมเดลที่ดีที่สุดสำหรับการเขียนโค้ดได้อย่างง่ายดาย“ ข้อสังเกตของเขาไปไกลกว่าแค่การสร้างโค้ด เขาเน้นย้ำถึงกรณีที่โมเดลแสดงสิ่งที่เขาเรียกว่า “ประกายแห่งความฉลาดอย่างแท้จริง“ นอกจากนี้ Wrigley ยังชี้ให้เห็นถึงลักษณะเฉพาะที่อาจมีความสำคัญ: โมเดลไม่ได้เพียงแค่ยอมรับตามพรอมต์ของผู้ใช้โดยปริยาย แต่มีส่วนร่วมอย่างมีวิจารณญาณมากขึ้น ซึ่งบ่งบอกถึงระดับความเข้าใจที่ลึกซึ้งยิ่งขึ้นหรือการให้เหตุผลจำลอง ข้อสรุปของเขานั้นหนักแน่น: “Google ส่งมอบผู้ชนะตัวจริงที่นี่“
ความรู้สึกเชิงบวกนี้ดูเหมือนจะถูกแบ่งปันโดยผู้อื่น โดยเฉพาะอย่างยิ่งเมื่อเปรียบเทียบโดยตรงกับ Claude 3.7 Sonnet ที่ได้รับการยอมรับอย่างสูงของ Anthropic นักพัฒนาจำนวนมากพบว่าประสบการณ์จริงของพวกเขาสอดคล้องกับผลลัพธ์ benchmark ที่สนับสนุน Gemini 2.5 เรื่องราวประกอบเรื่องหนึ่งมาจากผู้ใช้บน Reddit ซึ่งให้รายละเอียดเกี่ยวกับการต่อสู้ของพวกเขาในการสร้างแอปพลิเคชันเป็นเวลาหลายชั่วโมงโดยใช้ Claude 3.7 Sonnet ผลลัพธ์ตามที่ผู้ใช้กล่าวคือ โค้ดส่วนใหญ่ใช้งานไม่ได้และเต็มไปด้วยแนวปฏิบัติด้านความปลอดภัยที่ไม่ดี เช่น การฝัง API keys โดยตรงภายในโค้ด (hardcoding) ด้วยความหงุดหงิด นักพัฒนาจึงเปลี่ยนไปใช้ Gemini 2.5 พวกเขาให้ codebase ที่มีข้อบกพร่องทั้งหมดที่สร้างโดย Claude เป็นอินพุต มีรายงานว่า Gemini 2.5 ไม่เพียงแต่ระบุข้อบกพร่องที่สำคัญและอธิบายได้อย่างชัดเจนเท่านั้น แต่ยังดำเนินการเขียนแอปพลิเคชันใหม่ทั้งหมด ส่งผลให้ได้เวอร์ชันที่ใช้งานได้และปลอดภัยยิ่งขึ้น เกร็ดเล็กเกร็ดน้อยนี้เน้นย้ำถึงศักยภาพของ Gemini 2.5 ในการจัดการงานแก้จุดบกพร่องและปรับโครงสร้างโค้ด (refactoring) ที่ซับซ้อนได้อย่างมีประสิทธิภาพ
การทดสอบเปรียบเทียบเพิ่มเติมได้มุ่งเน้นไปที่แง่มุมต่างๆ ของการพัฒนา ในกรณีหนึ่งที่บันทึกไว้บนแพลตฟอร์มโซเชียล X ผู้ใช้รายหนึ่งได้นำ Gemini 2.5 มาแข่งขันกับ Claude 3.7 Sonnet ในงานด้านภาพ: การสร้างส่วนติดต่อผู้ใช้ (UI) ของ ChatGPT ขึ้นมาใหม่ ตามการประเมินของผู้ใช้ Gemini 2.5 สร้างการแสดงผลทางภาพที่แม่นยำยิ่งขึ้นของ UI เป้าหมายเมื่อเทียบกับคู่แข่งจาก Anthropic แม้ว่าการจำลอง UI จะเป็นเพียงแง่มุมหนึ่งของการพัฒนา แต่ความแม่นยำในงานดังกล่าวสามารถบ่งบอกถึงความใส่ใจในรายละเอียดของโมเดลและความสามารถในการแปลคำอธิบายหรือตัวอย่างที่ซับซ้อนให้เป็นผลลัพธ์ที่จับต้องได้
การปรับปรุงไม่ได้เป็นเพียงแค่เมื่อเทียบกับคู่แข่งเท่านั้น แต่ยังแสดงถึงความก้าวหน้าที่สำคัญเหนือกว่าโมเดลก่อนหน้าของ Google เองด้วย นักพัฒนา Alex Mizrahi ได้แบ่งปันประสบการณ์ที่เน้นย้ำถึงความก้าวหน้าภายในนี้ เขาใช้ Gemini 2.5 และพบว่ามันสามารถจดจำไวยากรณ์ประมาณ 80-90% ของ Rell (ภาษาโปรแกรมเฉพาะ) ได้อย่างหมดจดจากฐานความรู้ภายใน สิ่งนี้ถือเป็นก้าวกระโดดที่สำคัญจาก Gemini เวอร์ชันก่อนหน้า ซึ่งตามที่ Mizrahi กล่าว ประสบปัญหาอย่างมากกับไวยากรณ์ Rell แม้ว่าจะได้รับตัวอย่างอย่างชัดเจนภายในพรอมต์ก็ตาม สิ่งนี้ชี้ให้เห็นถึงการปรับปรุงข้อมูลการฝึกอบรมพื้นฐานของโมเดลและความสามารถในการเรียกคืนสำหรับภาษาหรือไวยากรณ์ที่ไม่ค่อยพบบ่อย
การเขียนโค้ดร่วมกันและข้อได้เปรียบด้านบริบท
นอกเหนือจากการสร้างโค้ดดิบและความแม่นยำแล้ว รูปแบบการโต้ตอบและความสามารถด้านบริบทของโมเดล AI ยังส่งผลกระทบอย่างมีนัยสำคัญต่อประโยชน์ใช้สอยในฐานะคู่หูในการเขียนโค้ด ผู้ใช้กำลังรายงานความรู้สึกร่วมมือกันมากขึ้นเมื่อทำงานกับ Gemini 2.5 นักพัฒนา Matthew Berman สังเกตเห็นพฤติกรรมที่แตกต่างบน X: “มัน (Gemini 2.5 Pro) ถามคำถามเพื่อความชัดเจนกับฉันไปตลอดทาง ซึ่งไม่มีโมเดลอื่นเคยทำ“ เขาตีความสิ่งนี้ว่าทำให้การโต้ตอบ “ร่วมมือกันมากขึ้น“ การมีส่วนร่วมเชิงรุกนี้—การแสวงหาความชัดเจนแทนที่จะตั้งสมมติฐาน—สามารถนำไปสู่ผลลัพธ์ที่แม่นยำยิ่งขึ้น ลดการทำซ้ำ และอาจป้องกันความเข้าใจผิด โดยเฉพาะอย่างยิ่งในงานที่ซับซ้อนหรือไม่ชัดเจนซึ่งมักพบใน “vibe coding” ที่นักพัฒนามีแนวคิดทั่วไปแต่ไม่มีข้อกำหนดที่แม่นยำ
ปัจจัยทางเทคนิคที่สำคัญประการหนึ่งที่ส่งผลต่อความเหนือกว่าที่เป็นไปได้ของ Gemini 2.5 ในสถานการณ์การเขียนโค้ดที่ซับซ้อนคือ context window ที่กว้างขวาง โมเดลนี้รองรับ input tokens ได้สูงสุดถึง 1 ล้าน นี่แสดงถึงข้อได้เปรียบที่สำคัญเหนือคู่แข่งในปัจจุบัน โมเดลชั้นนำของ OpenAI อย่าง o1 และ o3-mini ปัจจุบันรองรับ context window ที่ 250,000 tokens ในขณะที่มีรายงานว่า Anthropic กำลังดำเนินการขยาย context window ซึ่งอาจสูงถึง 500,000 tokens แต่ความสามารถในปัจจุบันของ Gemini 2.5 ก็ยังเหนือกว่าตัวเลขเหล่านี้อย่างมีนัยสำคัญ
ทำไม context window ขนาดใหญ่จึงมีความสำคัญอย่างยิ่งต่อการเขียนโค้ด? การพัฒนาซอฟต์แวร์สมัยใหม่มักเกี่ยวข้องกับการทำงานกับ codebase ขนาดใหญ่ ไฟล์หลายไฟล์ การพึ่งพาที่ซับซ้อน และประวัติการเปลี่ยนแปลงที่ยาวนาน โมเดลที่มี context window ขนาดใหญ่สามารถรับและประมวลผลข้อมูลแวดล้อมเหล่านี้ได้มากขึ้นพร้อมกัน สิ่งนี้ช่วยให้สามารถรักษาความสอดคล้องกันได้ดีขึ้นในโครงการขนาดใหญ่ เข้าใจความสัมพันธ์ที่ซับซ้อนระหว่างโมดูลโค้ดต่างๆ ติดตามการใช้ตัวแปรและคำจำกัดความของฟังก์ชันข้ามไฟล์ และอาจสร้างโค้ดที่ผสานรวมเข้ากับโครงสร้างที่มีอยู่ได้อย่างราบรื่นยิ่งขึ้นโดยไม่ต้องให้นักพัฒนาป้อนข้อมูลบริบทที่เกี่ยวข้องด้วยตนเองอย่างต่อเนื่อง สำหรับงานต่างๆ เช่น การปรับโครงสร้างโค้ดขนาดใหญ่ (large-scale refactoring) การทำความเข้าใจระบบเดิม หรือการพัฒนาฟีเจอร์ที่เกี่ยวข้องกับหลายส่วนของแอปพลิเคชัน context window หนึ่งล้านโทเค็นอาจเป็นตัวเปลี่ยนเกม ลดข้อผิดพลาด และปรับปรุงคุณภาพและความเกี่ยวข้องของการมีส่วนร่วมของ AI
ความไม่สมบูรณ์ที่ยังคงอยู่และความจำเป็นในการกำกับดูแล
แม้จะมีความก้าวหน้าที่น่าประทับใจและเสียงตอบรับในเชิงบวก สิ่งสำคัญคือต้องรักษาทัศนคติที่สมดุล: Gemini 2.5 โดยเฉพาะอย่างยิ่งในสถานะปัจจุบันที่เป็น “Pro Experimental” ไม่ใช่เทพพยากรณ์การเขียนโค้ดที่ไร้ที่ติ มันยังคงแสดงให้เห็นถึงความท้าทายแบบคลาสสิกและข้อผิดพลาดที่อาจเกิดขึ้นซึ่งเกี่ยวข้องกับการใช้แบบจำลองภาษาขนาดใหญ่สำหรับการพัฒนาซอฟต์แวร์ ข้อกำหนดพื้นฐานสำหรับวิจารณญาณของมนุษย์และการกำกับดูแลอย่างขยันขันแข็งยังคงเป็นสิ่งจำเป็นอย่างยิ่ง
ประเด็นสำคัญประการหนึ่งที่น่ากังวลยังคงเป็นเรื่องความปลอดภัย นักพัฒนา Kaden Bilyeu ได้แบ่งปันกรณีหนึ่งบน X ที่ Gemini 2.5 พยายามสร้างโค้ดที่จะสร้าง API ฝั่งไคลเอ็นต์ (client-side) สำหรับจัดการการตอบกลับแชท แนวทางนี้ไม่ปลอดภัยโดยเนื้อแท้ เนื่องจากจะนำไปสู่การเปิดเผยหรือการรั่วไหลของ API key ภายในโค้ดฝั่งไคลเอ็นต์อย่างหลีกเลี่ยงไม่ได้ ทำให้ผู้ใช้ปลายทางสามารถเข้าถึงได้ สิ่งนี้เน้นย้ำว่าแม้แต่โมเดลขั้นสูงก็อาจขาดความเข้าใจพื้นฐานเกี่ยวกับแนวปฏิบัติด้านความปลอดภัยที่ดีที่สุด ซึ่งอาจนำไปสู่ช่องโหว่ที่สำคัญหากเชื่อถือผลลัพธ์ของมันอย่างสุ่มสี่สุ่มห้า นักพัฒนาต้องตรวจสอบโค้ดที่สร้างโดย AI อย่างเข้มงวด โดยเฉพาะอย่างยิ่งเกี่ยวกับ การยืนยันตัวตน (authentication) การอนุญาต (authorization) และการจัดการข้อมูล
นอกจากนี้ ความสามารถของโมเดลในการจัดการ codebase ขนาดใหญ่มากได้อย่างมีประสิทธิภาพยังได้รับคำวิจารณ์ที่หลากหลาย ซึ่งชี้ให้เห็นว่า context window ที่น่าประทับใจอาจไม่ได้แปลไปสู่ประสิทธิภาพเชิงปฏิบัติได้อย่างสมบูรณ์แบบเสมอไปภายใต้ภาระงานหนัก นักพัฒนา Louie Bacaj รายงานถึงความยากลำบากอย่างมากเมื่อมอบหมายให้ Gemini 2.5 ทำงานกับ codebase ที่ประกอบด้วยโค้ดประมาณ 3,500 บรรทัด Bacaj ตั้งข้อสังเกตว่าแม้จะมีการปรับปรุงที่กล่าวอ้างของโมเดลในการจัดการบริบทและการเรียก API ที่ประสบความสำเร็จซึ่งบ่งชี้ว่าได้รับบริบทแล้ว แต่ก็มักจะล้มเหลวในการทำงานที่ร้องขอได้อย่างถูกต้องหรือครอบคลุมภายในขอบเขตโครงการที่ใหญ่ขึ้นนี้ สิ่งนี้ชี้ให้เห็นถึงข้อจำกัดที่เป็นไปได้ในการใช้ประโยชน์จาก context window ทั้งหมดอย่างมีประสิทธิภาพสำหรับงานการให้เหตุผลหรือการจัดการที่ซับซ้อนภายในโค้ดที่มีอยู่จำนวนมาก หรืออาจมีความไม่สอดคล้องกันในประสิทธิภาพขึ้นอยู่กับลักษณะเฉพาะของโค้ดและงาน
ป้ายกำกับ “Experimental” ที่แนบมากับ Gemini 2.5 Pro เวอร์ชันที่มีอยู่ในปัจจุบันก็มีความสำคัญเช่นกัน มันส่งสัญญาณว่า Google ยังคงปรับปรุงโมเดลอย่างแข็งขัน ผู้ใช้ควรคาดการณ์ถึงความไม่เสถียรที่อาจเกิดขึ้น ความผันแปรในประสิทธิภาพ และการเปลี่ยนแปลงอย่างต่อเนื่องในขณะที่ Google รวบรวมข้อเสนอแนะและปรับปรุงเทคโนโลยี แม้ว่าช่วงนี้จะช่วยให้เข้าถึงความสามารถที่ล้ำสมัยได้ก่อนใคร แต่ก็หมายความว่าโมเดลอาจยังไม่มีความน่าเชื่อถือหรือความสมบูรณ์เต็มที่ตามที่คาดหวังจากรุ่นที่เผยแพร่จริง การปรับปรุงอย่างต่อเนื่องมีแนวโน้มที่จะเกิดขึ้น แต่ผู้ใช้ปัจจุบันกำลังเข้าร่วมในการทดสอบเบต้าขนาดใหญ่อย่างมีประสิทธิภาพ ความไม่สมบูรณ์เหล่านี้เน้นย้ำถึงบทบาทที่ไม่อาจทดแทนได้ของนักพัฒนาที่เป็นมนุษย์ในกระบวนการ – ไม่ใช่แค่เพื่อตรวจจับข้อผิดพลาด แต่สำหรับการตัดสินใจด้านสถาปัตยกรรม การวางแผนเชิงกลยุทธ์ และการรับรองว่าผลิตภัณฑ์ขั้นสุดท้ายสอดคล้องกับข้อกำหนดและมาตรฐานคุณภาพ
ความท้าทายที่กว้างขึ้น: การบรรจุพลังสู่ประสบการณ์
ในขณะที่ Google DeepMind ดูเหมือนจะบรรลุเป้าหมายทางเทคนิคที่น่าทึ่งด้วยโมเดลอย่าง Gemini 2.5 แต่ก็มีประเด็นที่เกิดขึ้นซ้ำๆ คือ ความท้าทายในการแปลพลังทางเทคโนโลยีดิบให้เป็นประสบการณ์ผู้ใช้ที่น่าสนใจ เข้าถึงได้ และดึงดูดความสนใจของตลาด มีการรับรู้ว่าแม้เมื่อ Google พัฒนาความสามารถ AI ที่อาจเป็นผู้นำระดับโลกได้ แต่บางครั้งก็สะดุดในการบรรจุและนำเสนอความสามารถเหล่านี้ในลักษณะที่สะท้อนใจผู้ใช้อย่างกว้างขวาง โดยเฉพาะอย่างยิ่งเมื่อเทียบกับคู่แข่งอย่าง OpenAI
ประเด็นนี้ถูกเน้นโดยนักลงทุน Angel Investor ชื่อ Nikunj Kothari ผู้ซึ่งแสดงความเห็นใจต่อทีม Google DeepMind ในระดับหนึ่ง “ผมรู้สึกเห็นใจทีม Google DeepMind เล็กน้อย“ เขากล่าว โดยสังเกตเห็นความแตกต่างระหว่างการเปิดตัวโมเดลที่ทรงพลังกับปรากฏการณ์ไวรัลที่มักสร้างขึ้นโดยคู่แข่ง “คุณสร้างโมเดลที่เปลี่ยนแปลงโลกและทุกคนก็โพสต์รูปภาพสไตล์ Ghibli แทน“ เขากล่าวเสริม โดยอ้างถึงกระแสเกี่ยวกับความสามารถในการสร้างภาพของ GPT-4o ของ OpenAI ซึ่งดึงดูดจินตนาการของสาธารณชนได้อย่างรวดเร็ว Kothari ระบุว่านี่เป็นความท้าทายที่คงอยู่สำหรับ Google: การมีบุคลากรที่มีความสามารถทางเทคนิคอันมหาศาลที่สามารถสร้าง AI ที่ดีที่สุดในระดับเดียวกันได้ แต่กลับอาจลงทุนน้อยเกินไปในชั้นที่สำคัญของการออกแบบผลิตภัณฑ์และประสบการณ์ที่ผู้บริโภคต้องเผชิญ “ผมขอร้องให้พวกเขาแบ่งคนเก่งที่สุด 20% และให้อิสระแก่พวกเขาในการสร้างประสบการณ์ผู้บริโภคระดับโลก“ เขากระตุ้น
ความรู้สึกนี้ขยายไปถึง “บุคลิกภาพ” ที่รับรู้ได้ของโมเดล Kothari ตั้งข้อสังเกตว่ารูปแบบการโต้ตอบของ Gemini 2.5 รู้สึก “ค่อนข้างพื้นฐาน“ เมื่อเทียบกับโมเดลชั้นนำอื่นๆ องค์ประกอบเชิงอัตวิสัยนี้ แม้จะวัดผลได้ยาก แต่ก็มีอิทธิพลต่อการมีส่วนร่วมของผู้ใช้และความรู้สึกของการทำงานร่วมกับ AI ผู้ใช้อื่นๆ อีกหลายคนสะท้อนข้อสังเกตนี้ โดยชี้ให้เห็นว่าในขณะที่เชี่ยวชาญทางเทคนิค โมเดลอาจขาดรูปแบบการโต้ตอบที่มีส่วนร่วมหรือละเอียดอ่อนกว่าที่คู่แข่งได้ปลูกฝังไว้
ปัญหาด้านการใช้งานจริงก็ปรากฏขึ้นเช่นกัน ตัวอย่างเช่น การเปิดตัวการสร้างภาพแบบเนทีฟภายในโมเดล Gemini 2.0 Flash ได้รับการยกย่องทางเทคนิคในด้านความสามารถ อย่างไรก็ตาม ผู้ใช้จำนวนมากรายงานว่าประสบปัญหาในการค้นหาและใช้งานฟีเจอร์นี้ ส่วนติดต่อผู้ใช้ถูกอธิบายว่าไม่เป็นธรรมชาติ โดยมีตัวเลือกซ้อนอยู่ในเมนูโดยไม่จำเป็น ความติดขัดในการเข้าถึงฟีเจอร์ที่ทรงพลังนี้สามารถลดความกระตือรือร้นและการยอมรับของผู้ใช้ได้อย่างมาก โดยไม่คำนึงถึงคุณภาพของเทคโนโลยีพื้นฐาน หากผู้ใช้ประสบปัญหาแม้กระทั่งในการเริ่มต้นงาน พลังของโมเดลก็ไม่เกี่ยวข้องกับพวกเขา
เมื่อพิจารณาถึง “ความคลั่งไคล้ Ghibli” ที่อยู่รอบๆ การสร้างภาพของ GPT-4o สถานการณ์อาจไม่ได้เกี่ยวกับความล้มเหลวของ Google ในด้านการตลาดโดยสิ้นเชิง แต่เกี่ยวกับความเชี่ยวชาญของ OpenAI ในการทำความเข้าใจและใช้ประโยชน์จากจิตวิทยาของผู้ใช้ ดังที่ผู้ใช้รายหนึ่งบน X ชี้ให้เห็นเกี่ยวกับการนำเสนอของ OpenAI ว่า “คุณโพสต์รูปภาพสองรูปและทุกคนก็เข้าใจ“ ลักษณะที่มองเห็นได้ แบ่งปันได้ง่าย และมีความคิดสร้างสรรค์โดยเนื้อแท้ของการสาธิตได้เข้าถึงความสนใจของผู้ใช้ในทันที ในทางตรงกันข้าม การประเมินการปรับปรุงที่ละเอียดอ่อนในแบบจำลองภาษาอย่าง Gemini 2.5 ต้องใช้ความพยายามมากกว่า “คุณขอให้คนกลุ่มเดียวกันอ่านรายงานที่สร้างโดย 2.0 และเปรียบเทียบ [มัน] กับ 2.5 และนั่นต้องใช้เวลามากกว่าการเลื่อนดูและกดไลค์“ ผู้ใช้รายนั้นอธิบายเพิ่มเติม
สถานการณ์เหล่านี้เน้นย้ำบทเรียนที่สำคัญในภูมิทัศน์ AI ปัจจุบัน: ความเหนือกว่าทางเทคโนโลยีเพียงอย่างเดียวไม่ได้รับประกันความเป็นผู้นำตลาดหรือความพึงพอใจของผู้ใช้ ปัจจัยต่างๆ เช่น ความง่ายในการใช้งาน การออกแบบที่ใช้งานง่าย การสื่อสารความสามารถอย่างมีประสิทธิภาพ และแม้กระทั่งบุคลิกภาพหรือปัจจัยการมีส่วนร่วมที่รับรู้ได้ของ AI ล้วนมีบทบาทสำคัญ ผู้ใช้โดยเฉลี่ย รวมถึงนักพัฒนาจำนวนมากที่มุ่งเน้นไปที่ประสิทธิภาพการทำงาน มักจะโน้มเอียงไปหาเครื่องมือที่ไม่เพียงแต่ทรงพลัง แต่ยังสนุกสนาน เข้าถึงได้ และผสานรวมเข้ากับเวิร์กโฟลว์ของตนได้อย่างราบรื่น สำหรับ Google ที่จะใช้ประโยชน์จากศักยภาพของโมเดลอย่าง Gemini 2.5 ได้อย่างเต็มที่ โดยเฉพาะอย่างยิ่งในสาขาที่มีการแข่งขันสูงเช่นผู้ช่วยเขียนโค้ด การเชื่อมช่องว่างระหว่างการวิจัยที่ล้ำสมัยและประสบการณ์ผู้ใช้ที่ยอดเยี่ยมยังคงเป็นภารกิจที่สำคัญ