ปัญหาของ OpenAI Deep Research

> "Deep Research ของ OpenAI เหมือนถูกสร้างมาเพื่อฉัน แต่ฉันกลับใช้มันไม่ได้ มันดูเหมือนเดโมที่น่าทึ่ง แต่สุดท้ายก็มีปัญหาเกิดขึ้นจนได้เสมอ และวิธีที่ปัญหานั้นปรากฏออกมาก็ค่อนข้างน่าสนใจ" - Benedict Evans

• งานหลักที่ฉันทำคือการรีเสิร์ชและวิเคราะห์
  • ค้นหาข้อมูลที่ต้องการ จัดระเบียบ จากนั้นทำกราฟ แล้วสกัดอินไซต์ออกมาเพื่อนำเสนอเป็นข้อความและกราฟ
  • และนำผลลัพธ์ที่ทำขึ้นมาไปใช้พูดคุยกับผู้คน
• Deep Research ของ OpenAI ดูเหมือนเป็นโซลูชันที่ช่วยทำงาน “งานรีเสิร์ช” เหล่านี้โดยอัตโนมัติ
  • ฉันจึงสงสัยว่าเครื่องมือนี้เหมาะกับการใช้งานจริงหรือไม่ และพยายามทดสอบมัน
  • พอดีกับที่หัวข้อของรายงานตัวอย่างจาก Deep Research คือ ‘ตลาดสมาร์ตโฟน’ ซึ่งเป็นสาขาที่ฉันคุ้นเคยดี
• ตารางที่เสนอมาในรายงานตัวอย่างนั้น ดูเผินๆ แล้วเหมือนยอดเยี่ยมมาก
  • แต่คำถามพื้นฐานที่ต้องถามก่อนคือ “ข้อมูลนี้มาจากที่ไหน”
  • Deep Research อ้างถึง ‘Statista’ และ ‘Statcounter’ เป็นแหล่งที่มา แต่ ทั้งสองแหล่งต่างก็มีปัญหา
    • Statcounter เป็นสถิติที่อิงจากทราฟฟิก จึงมีแนวโน้มที่จะสะท้อนบางแพลตฟอร์มมากหรือน้อยเกินจริงจากความเอนเอียงของปริมาณการใช้งานอุปกรณ์
    • Statista ใช้การทำ SEO เพื่อรีแพ็กข้อมูลจากแหล่งอื่น และแหล่งข้อมูลจริงก็อยู่ที่อื่นอีกทอดหนึ่ง
      • สิ่งนี้แทบไม่ต่างจากการบอกว่า “แหล่งที่มาคือผลการค้นหาของ Google”
• ตัวอย่างเช่น เมื่อดูตัวเลขส่วนแบ่ง iOS/Android ในตลาดญี่ปุ่น Deep Research ระบุว่า “iOS 69%, Android 31%”
  • แต่ตัว Statcounter เองก็ ไม่เคย ให้ตัวเลข 69% นี้ภายในช่วง 1 ปีที่ผ่านมา
  • แหล่งข้อมูลจริงที่อยู่เบื้องหลัง Statista คือ Kantar Worldpanel แต่ตัวเลขที่ Kantar ให้มานั้น แทบตรงกันข้าม (ประมาณ Android 63%, iOS 36%)
  • ขณะเดียวกัน ข้อมูลจากหน่วยงานรัฐบาลญี่ปุ่น(ลิงก์, หน้า 25) ระบุว่า “Android ประมาณ 53%, iOS 47%”
  • ยิ่งไปกว่านั้น ตัวเลขของ Kantar ยังแกว่งได้ถึง 20 จุดเปอร์เซ็นต์ในแต่ละเดือน จึงยากจะมองว่าเป็นข้อมูลที่แสดง “สัดส่วนการติดตั้งฮาร์ดแวร์จริง”
• หากจะตรวจสอบ ความแตกต่างเหล่านี้ทั้งหมด ก็ต้องย้อนกลับไปตรวจทานตัวเลขทุกตัวในตารางนั้นใหม่อยู่ดี
  • ในกรณีนี้ เหตุผลตั้งต้นที่ใช้เครื่องมือซึ่งคือ “การประหยัดเวลา” ก็หายไปเกือบหมด
  • สุดท้ายจึงยากที่จะเชื่อข้อมูลที่ Deep Research ใส่ไว้ในตารางได้เต็มที่
• ปัญหาสำคัญตรงนี้คือ “LLM ไม่ใช่ฐานข้อมูล”
  • LLM มีจุดแข็งในการตีความเจตนาของคำถามด้วยวิธีเชิงความน่าจะเป็น แต่กลับอ่อนในงานแบบ “กำหนดผลได้แน่นอน” ที่ต้องดึงตัวเลขให้ถูกต้องจากแหล่งข้อมูลเฉพาะ
  • Deep Research จำเป็นต้องเข้าใจให้ถูกว่า “ผู้ใช้ต้องการส่วนแบ่งตลาดในความหมายแบบไหน” และต้องดึงตัวเลขที่ถูกต้องจากแหล่งที่เชื่อถือได้ แต่กลับทำไม่ได้
• นี่จึงแสดงให้เห็นปรากฏการณ์ที่ว่า “LLM ทำสิ่งที่คอมพิวเตอร์ไม่ถนัดได้ดี (การเข้าใจบริบท) แต่กลับทำสิ่งที่คอมพิวเตอร์ถนัดได้ไม่ดี (การดึงข้อมูลที่แม่นยำ)”
  • OpenAI พยายามให้มันทำทั้งหน้าที่คาดเดาความตั้งใจของผู้ใช้และหน้าที่รวบรวมข้อมูลอย่างแม่นยำพร้อมกัน แต่ในสภาพปัจจุบันยังเกิดความคลาดเคลื่อนอยู่
  • ยิ่งไปกว่านั้น แม้แต่ตัวอย่างนี้ก็เป็นข้อมูลที่ OpenAI ยกมาใช้เพื่อการโปรโมตเอง แต่ก็ยังมีข้อผิดพลาดปรากฏ
• บางคนอาจพูดว่า “โมเดลจะค่อยๆ ดีขึ้นเอง จึงน่าจะดีขึ้นได้”
  • แต่ ต่อให้ตารางถูกต้อง 85% หากอีก 15% ผิด ความน่าเชื่อถือโดยรวมก็ยังต่ำอยู่ดี
  • การรีเสิร์ชแบบอัตโนมัติเต็มรูปแบบจะเกิดขึ้นได้ก็ต่อเมื่อเข้าใกล้ 100% มากพอ แต่ก็ยังน่าสงสัยว่าจุดนั้นจะไปถึงได้จริงหรือไม่
• ถึงอย่างนั้น ก็ไม่ได้หมายความว่าเทคโนโลยีนี้ ไม่มีประโยชน์เลย
  • ถ้าเป็นหัวข้อที่ตัวเองรู้ดีอยู่แล้ว ก็อาจให้มันสร้างรายงาน 20 หน้าอย่างรวดเร็ว แล้วเราแก้เฉพาะจุดผิดเองเพื่อประหยัดเวลาได้
  • ฉันเรียก LLM ว่า “เด็กฝึกงานไร้ขีดจำกัด” ซึ่งคล้ายกับการที่ ร่างงานที่เด็กฝึกงานนำมาก็ยังต้องมีการตรวจแก้
  • โดยอ้างคำพูดของ Steve Jobs ที่ว่าคอมพิวเตอร์คือจักรยานสำหรับจิตใจ มันจึงน่าจะเหมาะกับการใช้เป็นเครื่องมือเสริมความสามารถของมนุษย์
• แต่ในระดับพื้นฐานยังมีปัญหาอยู่สองข้อ
  • ยังไม่ชัดเจนว่าควรสร้างผลิตภัณฑ์โดยตั้งต้นจากสมมติฐานว่าโมเดลอาจผิดได้ หรือควรตั้งต้นจากสมมติฐานว่าในที่สุดเราจะเชื่อถือโมเดลได้
  • บริษัทอย่าง OpenAI เองก็ยังไม่มีทั้งปราการทางการแข่งขันหรือความสามารถด้านผลิตภัณฑ์ที่โดดเด่นเป็นพิเศษนอกเหนือจากเงินทุนมหาศาล (ยกเว้นในสายโค้ดดิ้งและการตลาด)
    • หากความพยายามอย่าง Deep Research จะกลายเป็น ‘ผลิตภัณฑ์’ ที่มากกว่าแค่ textbox + API ก็ต้องแก้ปัญหา การจัดการข้อผิดพลาดและบริบทการใช้งาน ให้ได้
    • เมื่อมีคู่แข่งอย่าง Perplexity เข้ามาด้วย ในท้ายที่สุด สถานการณ์ที่เป็นไปได้มากกว่าคือ ซอฟต์แวร์อื่นสร้างอยู่บน API ที่ abstraction LLM ไว้อีกชั้น แล้วเป็นฝ่ายจัดการอัตราความผิดพลาดเอง
• โดยสรุป Deep Research เป็นความพยายามที่น่าสนใจ แต่ ในตอนนี้ยังยากจะรับประกันความน่าเชื่อถือ และทิศทางที่อุตสาหกรรมจะพัฒนาต่อไปก็ยังไม่แน่ชัด