ความหมายของบทบาท FDE ที่ OpenAI

เมื่อ Codex เปิดตัว มีคนในทีมถามผมว่า “เราจะทำอย่างไร ถ้า Codex ทำสิ่งที่เราใช้เวลาสร้างมาหลายเดือนให้เสร็จได้ในครั้งเดียว”

คำถามนั้นเข้าถึงหัวใจของบทบาทของ FDE ที่ OpenAI เราทำงานเคียงข้างลูกค้าเพื่อเข้าใจปัญหาที่ยากที่สุดของพวกเขา และสร้างโซลูชันที่พึ่งพาได้ สิ่งที่เราเรียนรู้ช่วยกำหนดทิศทางผลิตภัณฑ์ และมอบโจทย์ที่เป็นรูปธรรมให้ทีมวิจัยได้แก้ไข

นั่นคือความก้าวหน้า หากเราทำให้ตัวเองหมดความจำเป็นได้ทุกๆ สองสามเดือน ก็แสดงว่าทีม FDE ของเรากำลังทำหน้าที่ได้ดี

ผมก่อตั้งทีมขึ้นเมื่อต้นปี 2568 เพื่อปิดสิ่งที่เราเรียกว่า “ช่องว่างในการนำไปใช้งานจริง”: ซึ่งหมายถึงช่องว่างระหว่างสิ่งที่ดูเหมือนว่าโมเดลจะทำได้กับสิ่งที่ผู้คนสามารถนำไปใช้ทำงานจริงได้อย่างน่าเชื่อถือ

ความสามารถของโมเดลพัฒนาเร็วกว่าระบบและกระบวนการที่จำเป็นต่อการนำไปใช้ บางครั้งสิ่งที่ยังขาดคือผลิตภัณฑ์ บางครั้งโมเดลทำได้ดีในการทดสอบมาตรฐาน แต่กลับทำงานจริงไม่ได้เมื่อต้องเจอกับตัวแปรและข้อจำกัดในชีวิตจริง

เรามุ่งเน้นแก้ปัญหาที่ยากที่สุดของลูกค้า หากโมเดลของเราสามารถทำงานนั้นได้แล้วในปัจจุบัน เราจะทำงานร่วมกับทีมผลิตภัณฑ์และลูกค้าเพื่อพัฒนาโซลูชันที่สามารถนำไปใช้ซ้ำได้ แต่หากโมเดลยังทำได้ไม่ดีพอ เราจะทำงานร่วมกับลูกค้าและทีมวิจัยเพื่อระบุช่องว่างและพัฒนาความสามารถให้ดีขึ้น เป้าหมายของเราคือทำให้ลูกค้ารายถัดไปเริ่มต้นได้ง่ายขึ้นจากสิ่งที่เราทำไว้ หากเราสามารถยกระดับความสามารถพื้นฐานจนลูกค้าไม่จำเป็นต้องพึ่งพา FDE เพื่อแก้ปัญหาประเภทเดิมอีกในครั้งต่อไป ก็ถือว่าเราทำหน้าที่ได้ดีแล้ว

แต่ปัญหามักเปิดกว้าง อาจไม่มีคำตอบที่ยืนยันได้ให้ยึดเป็นเกณฑ์ และไม่มีแนวทางสำเร็จรูป ทุกคนอยากสร้างสิ่งที่ไม่เคยมีมาก่อน แต่มีน้อยคนที่อยากลงมือทำทุกอย่างที่จำเป็นเพื่อไปให้ถึงจุดนั้น

การหาคนเก่งมาเป็น FDE พร้อมยกระดับมาตรฐานคำว่า “ดีพอ” ทำให้เราต้องทดลองและนำสิ่งต่างๆ ไปใช้งานจริงอย่างต่อเนื่อง

ทุกครั้งที่เริ่มประชุมทีม FDE ผมจะแสดงสไลด์ที่มีค่านิยมหลักข้อหนึ่งว่า “เริ่มจากผลลัพธ์ที่ต้องการ ทำทุกอย่างที่จำเป็นเพื่อให้สำเร็จ แล้วจึงขยายผล”

เดโมที่น่าประทับใจอาจสร้างความเชื่อมั่นได้มาก ก่อนที่ใครจะถามว่ามันใช้งานได้จริงในโลกการทำงานหรือไม่

หน้าที่ของเราคือแก้ปัญหาของลูกค้าให้ได้มาตรฐานที่เรามั่นใจและรับรองได้เมื่อนำไปใช้งานจริง

FDE ของเราไม่จำเป็นต้องรู้จักอุตสาหกรรมนั้นตั้งแต่วันแรก แต่มีหน้าที่ต้องเรียนรู้ให้เข้าใจ

เมื่อผู้ช่วยเขียนโค้ดทำให้สร้างซอฟต์แวร์ได้เร็วขึ้น การเข้าใจธุรกิจของลูกค้าก็ยิ่งสำคัญ เราสร้างทีมที่ผสมผสานคนที่มีความรู้รอบด้านกับผู้เชี่ยวชาญเฉพาะทางไว้ด้วยกัน

คุณต้องมีความรู้มากพอที่จะตัดสินใจได้อย่างมีเหตุผล และมีความใฝ่รู้มากพอที่จะตั้งคำถามกับสมมติฐานที่เกี่ยวกับวิธีทำงานที่เป็นอยู่

ตัวอย่างเช่น ในสาขาวิทยาศาสตร์ชีวภาพ พื้นฐานความรู้ด้านวิทยาศาสตร์ของ FDE ช่วยให้พวกเขาสร้างความไว้วางใจกับนักวิจัยที่ทำงานค้นคว้ายาก่อนการทดลองทางคลินิก เช่น การตรวจสอบความถูกต้องและจัดลำดับความสำคัญของเป้าหมายยา การวิเคราะห์การแสดงออกของยีน และการสร้างเส้นทางการสังเคราะห์สารเคมีขึ้นใหม่ ความเชี่ยวชาญนี้ช่วยให้พวกเขาสามารถใช้ความรู้และวิจารณญาณในการเสนอแนวทางปรับปรุงเวิร์กโฟลว์เหล่านั้นได้อย่างเหมาะสม

เราได้แสดงให้เห็นแล้วว่าเวิร์กโฟลว์เหล่านี้สร้างประโยชน์ได้จริง แต่แต่ละเวิร์กโฟลว์ยังต้องปรับแต่งและเชื่อมต่อระบบเป็นพิเศษมากเกินไปกว่าจะนำไปใช้กับทีมอื่นได้ ความท้าทายต่อไปคือการรักษาผลลัพธ์เหล่านั้นไว้ พร้อมทำให้ซอฟต์แวร์ติดตั้งใช้งานและดูแลรักษาได้ง่ายขึ้น

ถึงตอนนั้น Codex ก็มีความสามารถมากขึ้นแล้ว FDE คนหนึ่งทดลองสร้างแอปพลิเคชันขึ้นใหม่โดยใช้ Codex เป็นแกนหลัก จากนั้นจึงทำงานร่วมกับทีมเพื่อนำกรณีการใช้งานต่างๆ มาไว้บนชุดเครื่องมือทดสอบมาตรฐานเดียวกันโดยมี Codex เป็นศูนย์กลาง

แอปพลิเคชันที่พัฒนาขึ้นเฉพาะกลายมาเป็นปลั๊กอินและสกิลที่สร้างขึ้นจากองค์ประกอบพื้นฐานร่วมกันของ Codex นอกจากนี้ Codex ยังกลายเป็นช่องทางหลักในการใช้งาน ทำให้เราเลิกใช้หน้าจอเทอร์มินัลและ CLI แยกต่างหากที่เคยพัฒนาขึ้นสำหรับแต่ละกรณีการใช้งานได้

เราสามารถลดโค้ดที่พัฒนาขึ้นเฉพาะสำหรับแต่ละโปรเจกต์ได้ประมาณ 90% ซึ่งเปลี่ยนวิธีที่เราใช้ในการสร้าง ดูแลรักษา และขยายเวิร์กโฟลว์เหล่านี้:

• เราได้ประโยชน์จากการปรับปรุง Codex ที่ส่วนกลาง จึงลดปริมาณโค้ดเชื่อมต่อที่ต้องเขียนสำหรับแต่ละกรณีใช้งานลงได้

• ฟังก์ชันหลักถูกรวมไว้เป็นสกิลและปลั๊กอิน ทำให้ทีมต่างๆ แบ่งปันและนำไปใช้ร่วมกันได้ง่ายขึ้น อีกทั้งยังช่วยให้ AI CoE สามารถควบคุมจากส่วนกลางได้ การขยายการใช้งานจากทีมหนึ่งไปยังอีกทีมจึงทำได้ง่ายเพียงเปลี่ยนตัวเชื่อมต่อหรือ เซิร์ฟเวอร์ MCP ให้เหมาะสม สร้างชุดการประเมินใหม่ ซึ่งเราก็มีสกิลสำหรับงานนี้เช่นกัน แล้วเริ่มใช้งานได้ทันที

• ตัวอย่างหนึ่งในเดือนสิงหาคม 2569 การนำระบบไปใช้งานครั้งแรกใช้เวลาสองเดือน แต่การขยายโซลูชันไปยังทีมที่สองใช้เวลาเพียงหนึ่งวัน เมื่อเราขยายการใช้งาน ทีมถัดๆ ไปก็เริ่มใช้งานได้เร็วขึ้น แนวโน้มนี้ยังคงดำเนินต่อไป โดยกรณีการใช้งานหนึ่งในเดือนสิงหาคม 2569 ใช้เวลาเพียงหนึ่งวันในการขยายไปยังทีมที่สอง หลังจากการนำระบบไปใช้งานครั้งแรกใช้เวลาสองเดือน

นี่คือวิธีหนึ่งในการทำให้บทบาทของเราไม่จำเป็นอีกต่อไป งานที่เราทำเพื่อนำระบบไปใช้งานจริงช่วยให้เราเห็นว่าอะไรคือสิ่งสำคัญ เมื่อผลิตภัณฑ์พื้นฐานพัฒนาขึ้น เราก็สามารถแทนที่การพัฒนาระบบเฉพาะของเราได้เป็นส่วนใหญ่ โดยยังคงรักษาประโยชน์ที่ระบบมอบให้ไว้ได้

นี่คือเหตุผลที่ลำดับขั้นตอนมีความสำคัญ LLM ช่วยให้เราพัฒนาได้อย่างรวดเร็ว เราควรใช้ความเร็วนี้ส่งมอบสิ่งที่มีประโยชน์ให้ผู้ใช้ได้ลองใช้งานจริง เรียนรู้ว่าอะไรใช้ได้ผลในทางปฏิบัติ แล้วจึงขยายสิ่งที่ได้ผลให้กว้างขึ้น

หลักการเดียวกันนี้ใช้ได้กับการทำงานร่วมกับลูกค้าทุกราย

บางครั้งผลิตภัณฑ์ที่ดีขึ้นช่วยให้เราลดความซับซ้อนของสิ่งที่สร้างไว้ได้ แต่บางครั้งตัวโมเดลเองก็ยังทำงานนั้นไม่ได้

หากเราสร้างเฉพาะสิ่งที่โมเดลปัจจุบันทำได้อยู่แล้ว เราก็จะไม่พบช่องว่างด้านความสามารถที่ทีมวิจัยต้องพัฒนาต่อ ด้วยเหตุนี้ โครงการสำคัญหลายโครงการของเราจึงเริ่มต้นตรงขีดจำกัดเหล่านั้น โดยลูกค้า ทีม FDE และทีมวิจัยต่างมุ่งมั่นที่จะก้าวข้ามไปด้วยกัน

ทุกส่วนล้วนสำคัญ ลูกค้ามุ่งมั่นที่จะร่วมแก้ปัญหาที่โมเดลยังแก้ไม่ได้ ทีม FDE ทำงานใกล้ชิดกับลูกค้ามากพอที่จะกำหนดโจทย์ สร้างแพลตฟอร์ม และขับเคลื่อนโครงการตั้งแต่ต้นจนจบ ส่วนทีมวิจัยก็ช่วยพัฒนาความสามารถพื้นฐานของโมเดลให้ดีขึ้น

นี่คืออีกวิธีหนึ่งในการทำให้บทบาทของเราไม่จำเป็นอีกต่อไป นั่นคือการช่วยเปลี่ยนปัญหาที่โมเดลในปัจจุบันยังแก้ไม่ได้ ให้กลายเป็นความสามารถที่โมเดลในอนาคตทำได้ ผลตอบแทนจากงานของเราไม่ได้จำกัดอยู่แค่จำนวนชั่วโมงที่เราใช้ทำงานร่วมกับลูกค้าแต่ละรายเท่านั้น

ผมเข้าร่วม OpenAI เพื่อช่วยทำให้ AI มีประโยชน์ต่อการทำงานในชีวิตประจำวันของผู้คน ซึ่งยังคงเป็นแนวทางที่ทีมยึดถือ ผมมักบอกทีมว่าในการพัฒนา LLM ส่วนใหญ่แล้ว หลักการ Occam’s Razor ใช้ได้เสมอ นั่นคือวิธีแก้ปัญหาที่เรียบง่ายที่สุดคือวิธีที่ดีที่สุดในบริษัทที่โดดเด่นด้วยงานวิจัยล้ำสมัยและอุตสาหกรรมที่เต็มไปด้วยคำกล่าวอ้างเกินจริง เราต้องการสร้างสิ่งที่ทำงานได้อย่างน่าเชื่อถือและเป็นสิ่งที่คนทำงานในสายงานจริงไว้วางใจและพึ่งพาได้

เป้าหมายคือให้ทุกโครงการช่วยยกระดับสิ่งที่จะตามมา ไม่ว่าจะเป็นผลิตภัณฑ์ที่นำไปใช้ได้ง่ายขึ้น โมเดลที่รับมือกับงานที่ยากขึ้นได้ หรือการลดงานที่ต้องทำขึ้นเฉพาะสำหรับลูกค้ารายถัดไป

หากคุณมีปัญหายากที่อยากแก้ เรายินดีที่จะร่วมงานกับคุณ หากคุณอยากช่วยแก้ปัญหาเหล่านั้น เราก็ยินดีต้อนรับคุณมาร่วมทีม

แล้วเราจะทำอย่างไร เมื่อ Codex จัดการงานที่เราใช้เวลาสร้างมาหลายเดือนได้แล้ว

เราจะออกไปหาโจทย์ที่ยากกว่าเดิม