- ผู้เขียนเข้าร่วมงานในเดือนพฤษภาคม 2024 ทำงานที่ OpenAI อยู่ราว 1 ปีก่อนลาออก และเล่าถึง วัฒนธรรมภายในและบรรยากาศการทำงานจริง อย่างตรงไปตรงมา
- ท่ามกลาง การเติบโตแบบก้าวกระโดดมาก (1,000 คน→3,000 คน) กระบวนการภายใน องค์กร วัฒนธรรม และวิธีการทำงาน กำลังเปลี่ยนแปลงอย่างรวดเร็ว
- วัฒนธรรมแบบ bottom-up/ยึดความสามารถเป็นหลัก, การทำงานร่วมกันผ่าน Slack ที่มีเอกลักษณ์, พลังในการลงมือทำสูง, การมองเห็นได้ชัดของผู้นำและการเปลี่ยนทิศอย่างรวดเร็ว รวมถึงทัศนคติแบบ 'โค้ดคือคำตอบ' ได้ซึมอยู่ทั่วทั้งองค์กร
- วัฒนธรรมของแต่ละทีม ความเร็วในการทำงาน และความยืดหยุ่นขององค์กร คือจุดแข็ง โดยนักวิจัยแต่ละคนมีอิสระแบบ 'ผู้บริหารย่อส่วน' และมีทั้งโปรเจกต์ซ้ำซ้อนกับการทดลองไอเดียภายในเกิดขึ้นบ่อยครั้ง
- OpenAI ถูกอธิบายว่าเป็น องค์กรที่ทะเยอทะยานและจริงจัง ซึ่งอยู่ท่ามกลางทั้ง การจับตาอย่างเข้มข้นจากสายตาภายนอกและสื่อ, มาตรการความปลอดภัย/ความลับที่เข้มงวดจริงจัง และความรู้สึกทั้งภารกิจและความตึงเครียดจากการทำ AGI/บริการสำหรับผู้บริโภค
บทนำและภูมิหลังส่วนตัว
- เข้าร่วมงานในเดือนพฤษภาคม 2024 และเพิ่งลาออกจาก OpenAI ไม่นานนี้
- บทความนี้ต้องการแบ่งปัน วัฒนธรรมที่สัมผัสได้จริงใน OpenAI และมุมมองส่วนตัวของผู้เขียน
- ไม่มีความลับภายในองค์กรอยู่ในบทความนี้ แต่เป็นภาพปัจจุบันขององค์กรที่น่าสนใจในเชิงประวัติศาสตร์ พร้อม ประสบการณ์ในฐานะหน้าต่างเล็ก ๆ จากพนักงานคนหนึ่ง
- การตัดสินใจลาออกมีความขัดแย้งส่วนตัวอยู่บ้าง แต่ก็มีความโหยหาความสดใหม่จากการเปลี่ยนผ่านจากผู้ก่อตั้งสตาร์ตอัปมาเป็นพนักงานในองค์กรขนาดใหญ่
- ประสบการณ์การมีส่วนร่วมในการสร้าง AGI และการได้มีส่วนโดยตรงกับการเปิดตัว Codex เป็นสิ่งที่มีความหมายอย่างยิ่ง
วัฒนธรรมองค์กร
- ตอนเข้าทำงานมีคนราว 1,000 คน และ 1 ปีต่อมาก็ทะลุ 3,000 คน สะท้อน การเติบโตที่รวดเร็วผิดปกติ
- การขยายตัวอย่างรวดเร็วทำให้เกิดปัญหาหลากหลายด้าน เช่น การสื่อสาร ระบบการรายงาน การเปิดตัวผลิตภัณฑ์ และการบริหารองค์กร
- การสื่อสารและงานทั้งหมด มี Slack เป็นศูนย์กลาง แทบไม่ใช้อีเมล
- แต่ละทีมมีวัฒนธรรม/จังหวะการทำงานต่างกันมาก ไม่ว่าจะเป็นฝั่งวิจัย การนำไปใช้ หรือ GTM (Go-To-Market) ซึ่งมีกรอบเวลาต่างกัน
- มีวัฒนธรรมแบบ bottom-up และยึดความสามารถจริงเป็นหลัก สูงมาก โดยนักวิจัยและนักพัฒนาต่างขับเคลื่อนการทดลองและการตัดสินใจด้วยตัวเอง
- เป็นวัฒนธรรมองค์กรที่ ให้ความสำคัญกับผลงานและความสามารถ มากกว่าทักษะการเมืองในองค์กร โดยพลังในการลงมือทำและไอเดียสำคัญกว่า
- ไม่มี roadmap แบบทางการชัดเจน แต่มีแนวโน้มที่ ทีมจะรวมตัวกันเองรอบไอเดียที่ดี และเปลี่ยนทิศได้อย่างรวดเร็ว
- ฝ่ายผู้นำให้ความสำคัญกับ การลงมือทำ (doing the right thing) และความคล่องตัวต่อการเปลี่ยนแปลง
- ภายในมี การพัฒนาซ้ำซ้อน/การทดลองแบบขนาน จำนวนมาก มี prototype หลายตัวเกิดขึ้นเองตามธรรมชาติ และเป็นองค์กรที่ 'โค้ดขับเคลื่อน' จริง ๆ
- ผู้นำให้ความสำคัญกับ ความสามารถในการทำให้ไอเดียเกิดขึ้นจริง มากกว่าความสามารถทางการเมือง
- นักวิจัยทำงานเหมือนเป็น "ผู้บริหารย่อส่วน" ที่ต่างคนต่างลงมือแก้ปัญหาด้วยตัวเอง
- อิทธิพลของผู้จัดการงานวิจัยและ PM ที่เก่ง มีสูงมาก
- EM ของ ChatGPT นั้นน่าเชื่อถือมาก และมักจ้างคนเก่งพร้อมให้อิสระในการทำงาน
- ความเร็วในการเปลี่ยนทิศทาง สูงมาก และเมื่อตัดสินใจแล้วก็ลงมือทันที
วิธีทำงานและบรรยากาศ
- โครงสร้างช่องและสิทธิ์ใน Slack ซับซ้อน และการสื่อสารทั้งหมดเกิดขึ้นบน Slack
- ไม่ว่าจะเป็น ทีมวิจัย/PM/EM (Engineering Manager) ต่างก็มีวิธีทำงานของตัวเอง และการย้ายทีมกับการร่วมงานข้ามทีมมีความยืดหยุ่นสูงมาก
- อ่อนไหวอย่างมากต่อความปลอดภัยภายนอกและการเปิดเผยผ่านสื่อ ข้อมูลภายในอย่างผลประกอบการ/รายได้จึงถูกควบคุมอย่างเข้มงวด
- คนในองค์กรมีแรงจูงใจสูงที่จะทำสิ่งที่ถูกต้อง และไม่ได้มองโลกแบบประชดประชันเท่าที่คนนอกบางคนอาจคิด
- OpenAI ถูกเปรียบว่าเป็นองค์กรลูกผสมระหว่าง 'Los Alamos (ห้องปฏิบัติการวิจัยนิวเคลียร์) + บริการผู้บริโภคขนาดมหึมา' ที่มีวัฒนธรรมย่อยหลายแบบปะปนกัน
- ให้ความสำคัญกับ การกระจายประโยชน์ของ AI ให้กว้างที่สุด แม้แต่โมเดลล้ำสมัยก็ไม่ได้จำกัดไว้แค่ฝั่ง enterprise แต่เปิดให้ทุกคนใช้ได้ผ่าน API/ChatGPT
ความปลอดภัยและนโยบายภายใน
- ประเด็น ความปลอดภัยของ AI มีการทุ่มทั้งบุคลากรและทรัพยากรจำนวนมากจริงภายในองค์กร
- ในทางปฏิบัติจะโฟกัสกับ ความเสี่ยงจริง มากกว่า เช่น hate speech, การใช้งานในทางที่ผิด, อคติทางการเมือง, prompt injection, การทำร้ายตนเอง เป็นต้น
- ความเสี่ยงเชิงทฤษฎี (เช่น การพุ่งทะยานของสติปัญญา, power-seeking) มีคนบางส่วนรับผิดชอบโดยตรง แต่ไม่ใช่กระแสหลัก
- งานวิจัยและระบบด้านความปลอดภัยจำนวนไม่น้อย ยังไม่ได้เปิดเผยต่อสาธารณะ
สภาพแวดล้อมการพัฒนาและเทคโนโลยี
- ใช้ mono-repo ขนาดใหญ่ และเน้น Python เป็นหลัก โดยมี Rust/Golang บางส่วน และแทบไม่มีการบังคับ style guide อย่างเข้มงวด
- มีทั้งระบบขนาดใหญ่ที่ออกแบบโดยรุ่นเก๋าจาก Google และ Jupyter notebook ที่เขียนโดยนักวิจัยปริญญาเอกใหม่ ๆ ปะปนอยู่ด้วยกัน
- ฝั่ง API ใช้ FastAPI เป็นหลัก และมีการใช้ Pydantic สำหรับตรวจสอบข้อมูลอย่างเด่นชัด
- โครงสร้างพื้นฐานทั้งหมดรันอยู่บน Azure
- บริการที่เชื่อถือได้มีค่อนข้างจำกัด เช่น Azure Kubernetes Service, CosmosDB และ BlobStore
- ระดับ IAM และบางบริการยังด้อยกว่า AWS และจึงมีแนวโน้มพัฒนาเครื่องมือภายในเอง
- มี วิศวกรจาก Meta (อดีต Facebook) ไหลเข้ามาจำนวนมาก
- บุคลิกของงาน infra และ codebase คล้าย Meta/Instagram ในยุคแรก
- เช่น การ reimplement TAO หรือการรวมระบบยืนยันตัวตน เป็นเรื่องปกติที่จะสร้างระบบขึ้นใช้เอง
- สัมผัสได้ถึง ปัญหาเรื้อรังขององค์กรที่เติบโตเร็ว เช่น โค้ดซ้ำ เครื่องมือ/ไลบรารีจัดการคิวซ้ำซ้อน การดูแล backend ขนาดใหญ่แบบ monolith รวมถึงปัญหาความเร็ว/เสถียรภาพของ CI
- โครงสร้างข้อความแชตและบทสนทนาแทรกอยู่ลึกในหลายส่วนของโค้ด และถูกนำกลับมาใช้ซ้ำในหลายผลิตภัณฑ์
- 'Code wins': ไม่มีคณะกรรมการวางแผนส่วนกลาง แต่โค้ดของทีมที่ทำงานจริงจะกลายเป็นมาตรฐาน
- อำนาจการตัดสินใจอยู่กับทีมที่ลงมือทำงานนั้นโดยตรง เป็นระบบที่ความสามารถและการลงมือทำผ่านโค้ดมีความได้เปรียบ
มุมมองด้านแบรนด์ผู้บริโภคและธุรกิจ
- แบรนด์ Consumer มีขนาดใหญ่มาก: ตัวชี้วัดหลักถูกบริหารบนฐานสมาชิกแบบรายบุคคล ไม่ใช่ระดับทีม
- การเติบโตของผลิตภัณฑ์และทราฟฟิกถูกวัดในหน่วยผู้บริโภค เช่น 'จำนวนสมาชิก Pro' ซึ่งเป็นความรู้สึกใหม่มากสำหรับผู้เขียนที่มาจากองค์กร B2B
- การฝึกโมเดลและการทดลองเริ่มจากขนาดเล็ก แล้วขยายไปเป็นวิศวกรรมระบบกระจายขนาดใหญ่เมื่อประสบความสำเร็จ
- ต้นทุน GPU กินสัดส่วนอย่างท่วมท้น แม้แต่ฟีเจอร์เล็กน้อยก็ยังต้องใช้ทรัพยากร GPU จำนวนมาก
- การประเมินการใช้ GPU และการ benchmark ทำแบบไล่ย้อนกลับจากเกณฑ์ประสบการณ์ผู้ใช้ เช่น latency ที่ต้องการ/จำนวนโทเค็น
- แนวปฏิบัติในการดูแล codebase Python ขนาดใหญ่: เมื่อจำนวนนักพัฒนาเพิ่มขึ้น ก็จำเป็นต้องมี guardrail หลากหลายด้าน เช่น การทำให้ระบบพื้นฐานใช้งานได้ การทดสอบ และการป้องกันการใช้งานผิดพลาด
การบริหารทีมและภาวะผู้นำ
- ฝ่ายผู้นำมองเห็นได้ชัดและลงมือมีส่วนร่วมโดยตรงมาก โดยผู้บริหารทุกคนเข้าร่วมพูดคุยบน Slack อยู่เสมอ
- การย้ายทีมและความร่วมมือเกิดขึ้นเร็วมาก แม้เป็นคำขอจากทีมอื่นก็พร้อมส่งกำลังสนับสนุนทันที แทบไม่มีการรอคิวหรือขั้นตอน
- ของสมนาคุณองค์กร (swag) ก็มีไม่บ่อย และมักแจกในลักษณะจำหน่ายแบบจำกัดเฉพาะภายในเท่านั้น
ประสบการณ์การเปิดตัว Codex
- ในช่วง 3 เดือนล่าสุด การเปิดตัว Codex คือไฮไลต์สำคัญของอาชีพ
- ในเดือนพฤศจิกายน 2024 มีการตั้งเป้าเปิดตัว coding agent ภายในปี 2025 และราวเดือนกุมภาพันธ์ 2025 เครื่องมือภายในก็เสร็จ จนเริ่มรู้สึกถึงแรงกดดันจากความเร็วของการแข่งขันในตลาด
- เพื่อเปิดตัว Codex ทีมต่าง ๆ รวมตัวกันและ สร้างพร้อมเปิดตัวผลิตภัณฑ์สมบูรณ์ (coding agent) ภายใน 7 สัปดาห์ เป็นการสร้างผลิตภัณฑ์ที่ทรงอิทธิพลได้อย่างรวดเร็วในช่วงเวลาพัฒนาสั้นมาก
- ในความเป็นจริงต้องทำงานดึก ขึ้นงานสุดสัปดาห์ และเลี้ยงลูกแรกเกิดไปพร้อมกัน ให้ความรู้สึกเหมือนช่วงอยู่ที่ YC อีกครั้ง
- มีการทำฟีเจอร์ต่าง ๆ อย่างรวดเร็ว เช่น container runtime, การ optimize repo, custom model fine-tuning, การเชื่อมต่อ git และการเข้าถึงอินเทอร์เน็ต
- ทีมประกอบด้วยวิศวกรอาวุโส 8 คน นักวิจัย 4 คน ดีไซเนอร์ 2 คน GTM 2 คน และ PM 1 คน เป็น ทีมขนาดเล็กแต่คัดคนประสบการณ์สูงเป็นหลัก
- วันก่อนเปิดตัว ทุ่มเวลาไปกับงานปิดท้ายรวมถึงการ deploy ด้วยตัวเอง
- ในวันเปิดตัว ทราฟฟิกพุ่งทะลัก และเพียงแค่ไปปรากฏในแถบด้านข้างของ ChatGPT ก็ทำให้มีผู้ใช้จำนวนมากไหลเข้ามาทันที
- Codex ใช้แนวทาง agent แบบ asynchronous (ข้อความผู้ใช้-เอเจนต์→ทำงาน→ส่งผลลัพธ์ PR กลับ)
- ทำงานในสภาพแวดล้อมแยกอิสระเพื่อประมวลผลคำขอของผู้ใช้ แล้วส่งผลลัพธ์ PR กลับมาเหมือนผู้ร่วมงานคนหนึ่ง
- ตอนนี้ยังมีทั้งความเชื่อมั่นและข้อจำกัดของประสิทธิภาพโมเดลปะปนกันอยู่
- จุดต่างของ Codex อยู่ที่ความสามารถอย่างการทำหลายงานพร้อมกัน และความเข้าใจ codebase ขนาดใหญ่
- ภายใน 53 วันหลังเปิดตัว มีการ สร้าง PR ไปแล้ว 630,000 รายการ คิดเป็นมากกว่า 78,000 PR ต่อวิศวกร 1 คน สร้างอิมแพกต์อย่างมหาศาล
บทสรุปและบทเรียน
- เดิมทีมีความกลัวต่อการทำงานในองค์กรใหญ่ แต่เมื่อมองย้อนกลับไป นี่เป็นหนึ่งในการตัดสินใจที่ดีที่สุด และเป็นโอกาสในการเรียนรู้และเติบโต
- บรรลุทุกเป้าหมายที่ตั้งไว้ ไม่ว่าจะเป็น สัญชาตญาณต่อการฝึกโมเดล การร่วมงานกับเพื่อนร่วมงานระดับยอดเยี่ยม และการเปิดตัวผลิตภัณฑ์ที่มีอิมแพกต์
- ได้เรียนรู้ แนวทางดูแล codebase Python ขนาดใหญ่ และได้สัมผัสประสบการณ์จริงเรื่องการ benchmark GPU/การประเมินความจุ
- หากเป็นผู้ก่อตั้งสตาร์ตอัปหรือกำลังคิดเรื่องเส้นทางอาชีพ ตอนนี้อาจเป็นช่วงเวลาที่ ควรท้าทายตัวเองให้มากขึ้น หรือพิจารณาเข้าร่วมแล็บวิจัยขนาดใหญ่
- การแข่งขันสู่ AGI มีม้าหลักอยู่ 3 ตัว คือ OpenAI, Anthropic, Google ซึ่งต่างก็เดินคนละแนวทาง และประสบการณ์การทำงานในหนึ่งในนั้นจะช่วยเปิดโลกทัศน์อย่างมาก
- ผู้เขียนประเมินว่าประสบการณ์ที่ OpenAI เป็นหนึ่งในตัวเลือกที่ดีที่สุดทั้งในฐานะผู้ประกอบการและวิศวกร
2 ความคิดเห็น
https://th.news.hada.io/topic?id=21081 บทความนี้ยังติดอยู่ในความทรงจำเลยครับ
ความเห็นจาก Hacker News
ไม่ค่อยเห็นคนที่ลาออกมาแล้วบรรยายประสบการณ์การทำงานของตัวเองในแง่บวกบ่อยนัก ซึ่งไม่ได้แปลว่า OpenAI พิเศษอะไรเป็นพิเศษ แต่สะท้อนว่าโพสต์แนว “ทำไมถึงลาออกจากบริษัท” ส่วนใหญ่มักเป็นการโทษองค์กร ทั้งที่จริงอาจเป็นเพราะตัวบุคคลไม่เข้ากับองค์กรเอง ในบทความนี้ วลีอย่าง “เป็นระบบ bottom-up แบบเหลือเชื่อ” ก็อาจมีอีกด้านคือไม่มีโรดแมปที่ชัดเจน และไม่มีโปรเจ็กต์ที่ใครเป็นเจ้าของจริง ๆ จนบางคนหลงทิศทางได้ อีกทั้ง “การเน้นลงมือทำ” และ “การเปลี่ยนทิศทันที” ก็อาจหมายถึงสภาพแวดล้อมที่วุ่นวายและภาวะผู้นำระดับผู้บริหารที่ไม่สม่ำเสมอด้วย และคำว่า “ที่ OpenAI มีคนที่มีเจตนาดีจริง ๆ เยอะมาก” ก็ใช้ได้กับแทบทุกบริษัทที่ต้องตัดสินใจเรื่องซับซ้อนทางศีลธรรม ทุกคนล้วนมองว่าตัวเองเป็นคนดี และหาเหตุผลรองรับด้วยเป้าหมายใหญ่และความชอบธรรม
สิ่งที่น่าประทับใจในบทความนี้มีดังนี้
ส่วนที่สะดุดตามากคือการบอกว่ามาราธอนพัฒนา Codex เป็นงานที่หนักที่สุดในรอบ 10 ปีที่ผ่านมา ส่วนใหญ่ต้องทำงานถึง 5 ทุ่มถึงเที่ยงคืน ตีห้าครึ่งก็ดูแลทารกแรกเกิด แล้ว 7 โมงก็ออกไปออฟฟิศแล้ว ในบรรยากาศอุตสาหกรรมที่โปรเจ็กต์ขนาดใหญ่ถูกเร่งสร้างเสร็จภายในไม่กี่สัปดาห์ถึงไม่กี่เดือน ก็อดสงสัยไม่ได้ว่าวิธีทำงานแบบนี้จะยั่งยืนสำหรับพนักงานในระยะยาวจริงหรือไม่
สิ่งที่ฉันอยากรู้จริง ๆ คือ OpenAI หรือแล็บ AI อื่น ๆ ใช้ LLM เป็นเสาหลักในการดำเนินงานภายในอย่างจริงจังหรือไม่ เช่น ใช้กับการพัฒนาโค้ด การคัสตอมโมเดลภายใน หรือการสรุปข้อมูลล่าสุดสำหรับงานจริงหรือเปล่า อยากรู้ว่าพวกเขาลงทั้งเงินและศักยภาพกับเรื่องนี้แค่ไหน แต่ก็น่าเสียดายที่บทความไม่ได้พูดถึง
การทำให้วิศวกรรู้สึกว่าตัวเองกำลังสร้าง “พระเจ้า” คือกลยุทธ์การตลาดระดับสุดยอด จริงอยู่ฉันไม่ได้เชื่อว่ามันเป็นความจริง แต่ไอเดียนี้มีโครงสร้างที่แทบกันคำวิจารณ์ได้หมด เพราะสามารถโต้กลับได้ทุกเมื่อด้วยคำถามว่า “แล้วถ้ามันจริงล่ะ?” และเมื่อผลตอบแทนที่เป็นไปได้ไม่มีที่สิ้นสุด ต่อให้ความน่าจะเป็นเล็กแค่ไหนก็ไม่อาจมองข้ามได้ ต่อให้มีโอกาสแค่ 0.00001% แต่เมื่อคูณกับรางวัลที่เป็นอนันต์ ค่าคาดหวังก็กลายเป็นอนันต์ นี่คือการตลาดชั้นยอด
สิ่งที่ฉันอยากรู้ที่สุดคือ ภายใน OpenAI ใช้ LLM กับการสร้างโปรดักต์จริงมากน้อยแค่ไหน และใช้อย่างไร
แม้จะเป็นบริษัทที่เติบโตเร็วขนาดนี้ แต่การขาดแคลน technical writer ของ OpenAI ก็ยังน่าประหลาดใจอยู่เสมอ บทความใช้คำแค่ว่าเอกสารยังปรับปรุงได้ แต่ถ้าเทียบกับระดับการทำเอกสารของ Anthropic แล้ว แทบไม่เห็นเพื่อนร่วมอาชีพสายเทคนิคอลไรเตอร์ใน OpenAI เลย การจะสร้างเครื่องมือสำหรับนักพัฒนาที่ดีได้ เอกสารที่ยอดเยี่ยมเป็นสิ่งจำเป็น และต้องมีทีมที่รับผิดชอบและพัฒนามันโดยเฉพาะ
บทความนี้มีข้อมูลน่าสนใจที่ฉันไม่เคยได้ยินมาก่อนเยอะมากจริง ๆ คุ้มค่าที่จะใช้เวลาอ่าน
ต่อความเห็นของผู้เขียนที่ว่า “ความปลอดภัยถูกให้ความสำคัญมากกว่าที่คิด” เมื่อพิจารณาว่าหัวหน้าทีมความปลอดภัยหลายคนของ OpenAI ลาออกหรือถูกปลด, โปรเจ็กต์ Superalignment ล้มเหลว, และพนักงานคนอื่น ๆ ก็เคยพูดถึงการขาดการสนับสนุนด้านประเด็นความปลอดภัย คำกล่าวนี้จึงให้ความรู้สึกว่าห่างไกลจากความเป็นจริง หรือจงใจชวนให้เข้าใจผิด
ประโยคที่ว่า “งานวิจัยส่วนใหญ่เริ่มต้นจากการที่นักวิจัยหมกมุ่นกับปัญหาบางอย่าง” น่าสนใจมาก ถ้าวินิจฉัยนี้ถูกต้อง มันอาจเป็นจุดอ่อนแบบ Achilles' heel ของบริษัทได้