นักพัฒนาซอฟต์แวร์ถกเถียงว่า LLMs ให้การแยกชั้นการเขียนโปรแกรมใหม่จริงหรือเป็นเพียงระบบอัตโนมัติที่ซับซ้อน

ทีมชุมชน BigGo
นักพัฒนาซอฟต์แวร์ถกเถียงว่า LLMs ให้การแยกชั้นการเขียนโปรแกรมใหม่จริงหรือเป็นเพียงระบบอัตโนมัติที่ซับซ้อน

การกล่าวอ้างล่าสุดของ Martin Fowler ว่า Large Language Models เป็นตัวแทนของการเปลี่ยนแปลงพื้นฐานในการแยกชั้นการเขียนโปรแกรมได้จุดประกายการถกเถียงอย่างรุนแรงในหมู่นักพัฒนา ในขณะที่ Fowler เปรียบเทียบผลกระทบของ LLMs กับการเปลี่ยนผ่านจากภาษาแอสเซมบลีไปสู่ภาษาโปรแกรมระดับสูง ชุมชนนักพัฒนายังคงแบ่งแยกอย่างลึกซึ้งเกี่ยวกับว่าสิ่งนี้เป็นตัวแทนของการแยกชั้นที่แท้จริงหรือเป็นเพียงระบบอัตโนมัติขั้นสูง

การเปรียบเทียบวิวัฒนาการของภาษาโปรแกรมมิ่ง:

  • จาก Assembly สู่ภาษาระดับสูง: นำเสนอคำสั่ง เงื่อนไข การวนซ้ำ ตัวแปรที่มีชื่อ
  • ข้อจำกัดในยุคแรก: Fortran IV ขาดคำสั่ง ELSE ต้องใช้การตั้งชื่อตัวแปรตามแบบแผนเฉพาะ
  • การปรับปรุงในยุคปัจจุบัน: โครงสร้างแบบบล็อก การเขียนโปรแกรมเชิงฟังก์ชัน แต่ยังคงใช้โมเดลการสื่อสารพื้นฐานเดิม
  • ความแตกต่างของ LLM: นำเสนอการแยกนามธรรมแบบไม่กำหนดร่วมกับอินเทอร์เฟซระดับสูงกว่า

ข้อถกเถียงเรื่องความแน่นอน

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

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

การกำหนดค่า LLM เพื่อความแน่นอนในผลลัพธ์:

  • การตั้งค่า Temperature: 0 เพื่อให้ได้ผลลัพธ์ที่แน่นอน
  • การกำหนด RNG seed แบบคงที่: จำเป็นสำหรับผลลัพธ์ที่สม่ำเสมอ
  • เวอร์ชันของโมเดล: ต้องระบุให้ชัดเจน (เช่น gemma3n:e4b digest: 15cb39fd9394)
  • สามารถได้ผลลัพธ์เดียวกันในอุปกรณ์และการกำหนดค่า GPU ที่แตกต่างกัน

ข้อจำกัดของการเขียนโปรแกรมด้วยภาษาธรรมชาติ

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

สิ่งที่หลายคนพลาดและเน้นย้ำในบทความคือสิ่งต่อไปนี้: ไม่มีทางที่จะ 'แม่นยำ' ด้วยภาษาธรรมชาติ 'คำนิยามเชิงปฏิบัติการ' ของความแม่นยำเกี่ยวข้องกับรูปแบบที่เป็นทางการ

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

การแยกชั้นเทียบกับระบบอัตโนมัติ

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

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

ผลกระทบในอนาคตสำหรับการพัฒนาซอฟต์แวร์

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

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

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

อ้างอิง: LLMs bring new nature of abstraction