- แบบจำลองภาษาขนาดใหญ่ (LLM) กำลังเปลี่ยนวิธีการทำงานอย่างพื้นฐาน และ Oxide ได้กำหนดไว้อย่างชัดเจนว่าควรใช้ในองค์กรอย่างไร
- Oxide เป็นสตาร์ทอัปโครงสร้างพื้นฐานคอมพิวติงแบบตามความต้องการที่สร้างฮาร์ดแวร์และซอฟต์แวร์แบบบูรณาการสำหรับศูนย์ข้อมูลแบบ on-premise
- Oxide เสนอหลักการสำคัญของการใช้ LLM ในรูปแบบ ความสมดุลระหว่างความรับผิดชอบ ความรอบคอบ ความเห็นอกเห็นใจ การทำงานเป็นทีม และความเร่งด่วน
- LLM มีประโยชน์ในการสรุปและทำความเข้าใจเอกสาร การรีวิวโค้ด และการดีบัก แต่ในกรณีที่เกี่ยวข้องกับการเขียนข้อความหรือลงมือเขียนโค้ด การตัดสินใจและความรับผิดชอบของมนุษย์คือสิ่งจำเป็น
- ผลลัพธ์ที่ LLM สร้างขึ้นต้องคงอยู่ในโครงสร้างที่ มนุษย์เป็นผู้ตรวจสอบและรับผิดชอบเสมอ
- Oxide สนับสนุนการใช้ LLM แต่ตั้งอยู่บนพื้นฐาน ความรับผิดชอบต่อผลิตภัณฑ์ ลูกค้า และเพื่อนร่วมงาน
เกณฑ์คุณค่าของการใช้ LLM
- Oxide ประเมินการใช้ LLM ตาม คุณค่าหลักขององค์กร
- ความรับผิดชอบ (Responsibility) : LLM เป็นเพียงเครื่องมือ และความรับผิดชอบต่อผลลัพธ์เป็นของมนุษย์อย่างสมบูรณ์
- ความรอบคอบ (Rigor) : หากใช้ด้วยความระมัดระวังสามารถช่วยกลั่นความคิดให้ละเอียดขึ้น แต่ถ้าดูหมิ่นความระมัดระวังอาจทำให้คุณภาพของการคิดลดลง
- ความเห็นอกเห็นใจ (Empathy) : ต้องตระหนักว่าผู้รับสารและผู้ส่งสารล้วนเป็นมนุษย์ และต้องคงการสื่อสารที่ยึดมนุษย์เป็นศูนย์กลาง
- การทำงานเป็นทีม (Teamwork) : ควรระวังไม่ให้การใช้ LLM ทำลายความไว้วางใจระหว่างเพื่อนร่วมงาน และการประกาศการใช้งานไม่ควรดูเหมือนหลีกเลี่ยงความรับผิดชอบ
- ความเร่งด่วน (Urgency) : แม้จะช่วยเพิ่มความเร็วได้ แต่ห้ามแลกกับการลดทอนคุณค่าอื่น
รูปแบบการใช้ LLM ที่หลากหลาย
LLMs in as Readers
- LLM เหมาะอย่างยิ่งสำหรับ การสรุปเอกสารและการตอบคำถาม และช่วยทำความเข้าใจข้อมูลจำนวนมากได้อย่างรวดเร็ว
- อย่างไรก็ตาม ต้อง รับประกันความเป็นส่วนตัวของข้อมูล และตั้งค่าเพื่อป้องกันไม่ให้เอกสารที่อัปโหลดถูกใช้ในการฝึกโมเดล
- เป็นเครื่องมือช่วยในการทำความเข้าใจเอกสารที่ดี แต่ ไม่ควรแทนที่การอ่านด้วยตนเองเมื่อจำเป็น
LLMs as Editors
- การปรับปรุงโครงสร้างและสไตล์ของเอกสารที่เสร็จสมบูรณ์ ให้ผลดีและมีประโยชน์เมื่อใช้ในช่วงปลายของกระบวนการ
- แต่ LLM มักให้การตอบสนองที่ค่อนข้างเป็นบวกเกินไป จนการวิเคราะห์เชิงวิจารณ์อาจไม่เพียงพอ
- หากใช้ในช่วงร่างงานมีความเสี่ยงที่จะ สูญเสียเสียงเฉพาะตัวของผู้เขียน
LLMs as Writers
- งานเขียนที่สร้างโดย LLM มักมีความซ้ำซากหรือมีร่องรอยการสร้างอัตโนมัติที่ชัดเจน
- การเขียนที่สร้างอัตโนมัติอาจทำลายความจริงใจของการคิดและความเชื่อมั่นของผู้อ่าน
- ผู้อ่านคาดหวังว่าผู้เขียนเข้าใจเนื้อหาอยู่แล้ว แต่ผลงานที่เขียนโดย LLM ทำให้สมมติฐานนี้พังทลาย
- Oxide กำหนดให้สมาชิกทุกคนมีความสามารถในการเขียน และจึง ไม่ใช้ LLM เป็นผู้เขียนหลัก
- อย่างไรก็ตาม LLM ยังสามารถใช้ได้ในลักษณะเครื่องมือช่วยคิดหรือเครื่องมือเสริมแบบจำกัด
LLMs as Code Reviewers
- LLM เป็นประโยชน์ในการตรวจจับ ประเภทย่อยของปัญหาโค้ด แต่ ไม่สามารถแทนที่การรีวิวของมนุษย์ได้
- เนื่องจากข้อเสนอแนะอาจไม่เป็นเหตุเป็นผลหรือมองข้ามบริบท ควรใช้เป็น เครื่องมือเสริมเท่านั้น
LLMs as Debuggers
- LLM สามารถใช้ได้ในบทบาท ‘Rubber Duck’ เพื่อกระตุ้นความคิดในการดีบัก
- ความสามารถในการแก้ปัญหาอย่างแท้จริงมีข้อจำกัด แต่เป็นประโยชน์ในฐานะตัวกระตุ้นให้เกิดมุมมองใหม่ๆ
LLMs as Programmers
- LLM มีความสามารถในการ สร้างโค้ด ที่ยอดเยี่ยม และเหมาะกับการเขียนโค้ดเชิงทดลองและเป็นเครื่องมือช่วย
- ยิ่งเข้าใกล้โค้ดของผลิตภัณฑ์มากขึ้นเท่าใด ความสำคัญของ การตรวจสอบและการรับผิดชอบ ก็ยิ่งสูงขึ้น
- โค้ดที่ LLM สร้างควรผ่าน self-review โดยผู้เขียนเอง และจำเป็นต้องตรวจสอบก่อนรีวิวกับเพื่อนร่วมงานเสมอ
- ระหว่างการรีวิวโค้ด ห้ามจัดการด้วยการสร้างใหม่ทั้งหมด เพราะจะทำให้การรีวิวซ้ำได้ยาก
- แม้ในงานเขียนโค้ดด้วย LLM ก็ต้องรักษา ความรับผิดชอบ ความรอบคอบ ความเห็นอกเห็นใจ การทำงานเป็นทีม อย่างเคร่งครัด
การดำเนินงานและแนวทางปฏิบัติ
- รายละเอียดเชิงเทคนิคและแนวทางภายในสำหรับการใช้ LLM ถูกบันทึกไว้ในเอกสารภายในบน GitHub
- Oxide สนับสนุนการใช้ LLM พร้อมยืนยันว่าต้องใช้อย่างมีความรับผิดชอบ
- ให้ความสำคัญสูงสุดกับความรับผิดชอบต่อคุณภาพผลิตภัณฑ์ ความเชื่อมั่นของลูกค้า และความร่วมมือระหว่างเพื่อนร่วมงาน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
บทความของ Bryan แสดงมุมมองที่ สมดุลและอยู่บนความเป็นจริง
คิดว่าเหตุที่ Oxide ไม่ได้จ้างวิศวกรจูเนียร์ ทำให้ไม่มีเนื้อหาส่วนนั้นอยู่ใน RFD
Bryan เป็นวิศวกรที่ทำงานกับซอฟต์แวร์และฮาร์ดแวร์ยาก ๆ มานานกว่า 30 ปี และเคยมีประสบการณ์ทำ “โปรแกรมที่ยากจริง ๆ (OS)” จนเสร็จ
วิธีที่เขารับมือกับ LLM จึงแตกต่างจากวิศวกรจูเนียร์ในปี 2025 มาก
เดาว่าจูเนียร์ทุกวันนี้แทบไม่เคยเขียนโค้ดโดยไม่มีความช่วยเหลือจาก LLM เลย
น่าเบื่อมากจนแทบไม่อยากไปทำงาน แต่ตอนนี้น่าจะใช้ LLM ทำเสร็จได้ในไม่กี่นาที
เวลาที่ทุ่มไปตอนนั้นพอมานึกตอนนี้แล้วแทบจะรู้สึกว่าเสียเวลาแบบบ้าคลั่ง
หลังจากนั้นค่อยแนะนำ Dreamweaver ซึ่งทำให้ productivity เพิ่มขึ้นเป็นสิบเท่า
ในงานอย่าง security research ที่ผลลัพธ์ชัดเจน LLM ทำได้ยอดเยี่ยม แต่กับปัญหาที่ต้องการการตัดสินใจละเอียดอ่อนกลับอ่อนกว่า
ดังนั้นอุดมคติคือน่าจะให้ LLM รับผิดชอบส่วนที่ซ้ำ ๆ และเป็นระบบ ส่วนที่ต้องใช้วิจารณญาณให้มนุษย์ทำ
แต่ตอนนี้ยอมรับแล้วว่านี่คือ “วิธีเขียนโปรแกรมแบบใหม่” และพอตระหนักแบบนั้นกลับรู้สึกเหมือนตัวเองหนุ่มขึ้น
ช่วงนี้พอใช้ em-dash แล้วมักถูกเข้าใจผิดว่าเป็นงานเขียนของ AI ซึ่งค่อนข้างน่าหงุดหงิด
ตอนอ่าน RFD ของ Oxide ก็พยักหน้าเห็นด้วยเกือบทั้งหมด แต่ไม่เห็นด้วยกับส่วนที่ว่า “LLM เขียนโค้ดตั้งแต่ต้นได้ดี”
LLM เก่งเรื่องแก้ “blank page syndrome” แต่คิดว่าโค้ดที่เอาไป deploy ได้จริงยังห่างจากผลลัพธ์ที่มันสร้างออกมามาก
เรื่องนี้อาจเป็น “ภาพลวงตาของความก้าวหน้า” ก็ได้
LLM เรียนรู้ “วิธีแก้ที่ดี” ที่ปรากฏบ่อยในชุดข้อมูล จึงเก่งด้านการแก้ปัญหา
ในทางกลับกัน การแสดงออกของมนุษย์มีความหลากหลายเป็นแก่นแท้ ดังนั้นการแสดงออกแบบเฉลี่ย ๆ จึงไม่น่าสนใจ
สุดท้าย LLM อาจจำกัดความสามารถในการแก้ปัญหาที่ยังไม่เคยถูกแก้มาก่อน
และมองว่าสาเหตุที่คุณภาพโค้ดยังต่ำเป็นเพราะข้อจำกัดของ context window
การให้สร้างในระดับฟังก์ชันยังพอได้ แต่ถ้าให้รับผิดชอบทั้งฟีเจอร์ โครงสร้างกับอินเทอร์เฟซจะเละเทะ
ถ้าเทียบกับการเขียน ก็ควรประมาณให้ประโยคแรกกับประโยคสุดท้ายของย่อหน้า แล้วให้เติมที่เหลือเอง
โปรแกรมเมอร์ยังพอตัดสินคุณภาพโค้ดได้ แต่กับงานเขียนไม่เป็นแบบนั้น
หลายคนอาจมีภาพลบเพราะเคยใช้โมเดลเก่าหรือโมเดลราคาถูก
สงสัยกับคำกล่าวที่ว่า “LLM แยกแยะข้อความที่ LLM เขียนได้ดี”
อยากรู้ว่ามีข้อมูลมายืนยันหรือไม่
เขาบอกว่ากระบวนการรับสมัครของบริษัทเน้น การเขียน เป็นหลัก จึงมีใบสมัครที่เขียนด้วย LLM เพิ่มขึ้นมากในช่วงหลัง
ทั้งใน RFD 0003 และ หน้ารับสมัครงาน ก็เตือนไว้แล้ว แต่ก็ยังเกิดขึ้นต่อเนื่อง
ใน ตอนของพอดแคสต์ ก็พูดถึงกรณีที่เกี่ยวข้องด้วย
เขาบอกว่าแม้ LLM จะจับงานเขียนจาก AI ได้ไม่หมดทุกชิ้น แต่ มีประโยชน์ในฐานะเครื่องมือช่วยตรวจจับกรณีน่าสงสัย
แม้จะยังไม่ได้ลองทดลองจริง แต่ก็เป็นแนวทางที่น่าสนใจ
จึงคิดว่าด้วยเทคโนโลยีปัจจุบันยังแยกแยะได้อย่างสมบูรณ์แบบไม่ได้
เมื่อใช้โค้ดจาก LLM ความรับผิดชอบยังอยู่ที่วิศวกร
โค้ดที่ยังไม่ได้ตรวจทานด้วยตัวเองไม่ควรถูกส่งไปรีวิว
ขั้นตอนของฉันมีดังนี้:
ขั้นตอนสุดท้ายนี่ยากที่สุด และในเชิงอารมณ์ก็มักอยากข้ามมันไป
วิธีนี้ช่วยลดงานซ้ำ ๆ โดยยังรักษา การคิดในระดับสถาปัตยกรรม เอาไว้
แต่ LLM เป็นสิ่งที่ไม่กำหนดแน่นอน จึงต่างจากเครื่องมือที่คาดเดาได้อย่างคอมไพเลอร์
ถ้าโค้ดทำงานไม่ถูกต้องก็ต้องแก้อีกมาก
เลยยังไม่แน่ใจว่า LLM ประหยัดเวลาได้จริงหรือไม่
มันยากที่จะมีอารมณ์ร่วมกับการขัดเกลาโค้ดที่เครื่องสร้างขึ้นมา
แปลกที่ไม่มีการพูดถึง ความเป็นไปได้ของการละเมิดลิขสิทธิ์ ในโค้ดที่ LLM สร้าง
โค้ดจาก GitHub อาจถูกคัดลอกมาตรง ๆ ได้ ซึ่งเป็นประเด็นสำคัญสำหรับบริษัทโอเพนซอร์ส
ต้องมีส่วนร่วมจากมนุษย์มากพอจึงจะเกิดลิขสิทธิ์ได้ แต่เกณฑ์นั้นก็ยังไม่ชัดเจน
เอกสารถูกจัดวางมาดี แต่ส่วนที่ว่า “ใช้ LLM ช่วยอ่านได้ไม่มีปัญหา” ฟังดูเหมือนขัดแย้งในตัว
ถ้ามันสมบูรณ์แบบก็ไม่ต่างจากต้นฉบับ แต่ถ้าไม่สมบูรณ์แบบก็มี ความเสี่ยงของการอ่านผิด
ในความเป็นจริงมักเห็น LLM อ่านเอกสารไม่ครบ แล้วอนุมานจากสารบัญอย่างเดียว
มีความเสี่ยงที่จะเกิด ชั้นการแปลความ คั่นกลางระหว่างเนื้อหากับผู้อ่าน
ควรป้อนข้อความเต็มทั้งหมดเข้าไปใน context window โดยตรง
แต่หนังสือทั้งสามเล่มรวมกันอาจมีปริมาณเกินขีดจำกัดของ LLM อยู่ดี
เห็นด้วยกับคำพูดที่ว่า “ข้อความที่ LLM สร้างขึ้นบั่นทอนแม้กระทั่งความแท้จริงของความคิด”
ข้อความที่มนุษย์เขียนเองมีคุณค่า แต่ข้อความที่ LLM เขียนเหมือน สำเนาที่ถูกเจือจางจนคุณค่าลดลง
คำพูดที่ว่าบางทีอ่าน prompt เสียยังจะดีกว่า เป็นประโยคที่ติดใจมาก
ความคิดที่น่าสนใจและเป็นต้นฉบับอยู่ตรงจุดที่หลุดออกจากค่าเฉลี่ย
ในงานอย่างการแปล ถ้าคนที่ไม่ใช่เจ้าของภาษาจะใช้ LLM เพื่อสื่อความคิดของตัวเองให้ดีขึ้นก็พอเข้าใจได้ แต่
ผู้รับสารก็ย่อมสงสัยว่าถ้อยคำนั้นเป็นความคิดของคนนั้นจริงหรือไม่
คอมเมนต์คือความพยายามอธิบาย บริบทเชิงทฤษฎี ที่ไม่ได้อยู่ในโค้ด
LLM ไม่มี “ทฤษฎี” แบบนี้ จึงสร้างคอมเมนต์ที่มีคุณค่าจริงไม่ได้
เช่น โพสต์ใน /r/SaaS ส่วนใหญ่ดูเหมือนเขียนโดย LLM แต่ก็ใช้การเล่าเรื่องเชิงอารมณ์ดึงปฏิกิริยาจากผู้อ่านได้ดี
ฉันเองก็ใช้ LLM ช่วยเขียนเอกสารหรือ benchmark
มันยังช่วยคนที่ไม่ใช่เจ้าของภาษาเวลาเขียนเอกสารเทคนิคได้ด้วย แต่คุณภาพก็แกว่งมาก
สุดท้ายแล้วใน งานเขียนเพื่อสื่อสารข้อมูล LLM กำลังมีประโยชน์มากขึ้นเรื่อย ๆ
สิ่งที่อยากรู้ไม่ใช่แค่ว่าเขาเขียนอะไร แต่คือ ทำไมถึงเขียนแบบนั้น
เพราะอย่างนั้น ถึงความคิดของฉันอาจไม่ถึงขั้นเป็นต้นฉบับ แต่การที่มันพบได้ยากในเชิงสถิติก็ยังเป็นเรื่องชวนอุ่นใจ
คิดว่างานเขียนที่ใช้ LLM เขียนนั้นไม่มีคุณค่าพอให้อ่าน
ชอบที่ Oxide วาง หลักการชัดเจน ว่าจะไม่ใช้ LLM กับผลลัพธ์ที่ไม่ใช่โค้ด
แม้แต่ใน code review ก็เช่นกัน ผู้เขียนต้องตรวจโค้ดที่สร้างขึ้นก่อน
วัฒนธรรมแบบนี้จะรักษาไว้ได้จริงหรือไม่คงต้องรอดู แต่ทิศทางถือว่าฉลาด
มี การรับรู้กันแรงมากว่า LLM ถูกฝึกจากข้อมูลที่ขโมยมา
จึงคิดว่าควรคำนึงถึงการรับรู้ของสาธารณะในจุดนี้ด้วย
ไม่ว่าจะเป็นประเด็นจริยธรรมหรือความเสี่ยงด้านแบรนด์ ตอนนี้ก็เป็นองค์ประกอบสำคัญชัดเจน
จุดประสงค์คือเสนอ แนวทางเชิงเทคนิค มากกว่าจะประกาศจุดยืนทางจริยธรรม
ข้อความที่ LLM สร้างสูญเสีย ความแท้จริง และผู้อ่านก็อาจรู้สึกว่าแม้แต่ความคิดนั้นก็ถูกทำให้เป็นอัตโนมัติไปแล้ว
สุดท้ายมันอาจทำลาย ความไว้วางใจระหว่างกัน ได้
ประโยคที่ว่า “การเขียนเป็นแรงงานทางปัญญาที่มากกว่าการอ่าน” ฟังดูน่าสนใจ
แต่รู้สึกว่าในโค้ดกลับตรงกันข้าม
เพราะงั้นโค้ดแย่จึงมีอยู่มากกว่ามาก
ในทางกลับกัน โค้ดที่เขียนดีมีคุณค่าในการเรียนรู้สูง และต้องใช้ insight เหมือนงานเขียน
“การดีบักยากกว่าการเขียนโค้ดสองเท่า
ดังนั้นถ้าคุณฉลาดที่สุดเท่าที่จะเป็นได้ตอนเขียน ตอนดีบักก็จะเป็นไปไม่ได้”
ลิงก์ laws-of-software.com