LLM กับแนวโน้มการเขียนโปรแกรมช่วงต้นปี 2024
(antirez.com)- ChatGPT และ LLM แบบรันในเครื่องกลายเป็นเครื่องมือที่ช่วยโปรแกรมเมอร์มีประสบการณ์ลด งานสิ้นเปลืองแรง เช่น การค้นเอกสาร การเรียนรู้ API ที่ซับซ้อน และการเขียนโปรแกรมที่จะทิ้งในภายหลัง มากกว่าช่วยแค่การเขียนโค้ดเอง
- LLM ไม่ใช่ปัญญาเหนือธรรมชาติ แต่เป็นการ interpolate อย่างจำกัดภายในพื้นที่ของข้อมูลฝึก อย่างไรก็ตาม ในสาขาที่มีข้อมูลคุณภาพสูงจำนวนมากอย่างการเขียนโปรแกรม ก็มีประโยชน์มากเหมือน “คนโง่ที่รู้เยอะ”
- ในปัญหาที่ ตรวจสอบผลลัพธ์ได้ เช่น การแปลง tensor ของ PyTorch, ไคลเอนต์ BLE ด้วย Objective-C บน macOS, การตีความอินพุต/เอาต์พุตของโมเดล ONNX, และสคริปต์วิเคราะห์ CSV นั้น GPT-4 ช่วยลดเวลาทำงานได้มาก
- ในงานที่ต้องใช้การให้เหตุผลซับซ้อน เช่น การเขียนโปรแกรมระบบด้วย C และการ implement อัลกอริทึม ข้อจำกัดเริ่มเห็นชัดในกรณีการออกแบบ hash สำหรับ Bloom filter และการตีความฟอร์แมต quantization Q6_K ของ llama.cpp
- หากงานเขียนโปรแกรมจำนวนมากคือการนำ pattern เดิมมาปรับเล็กน้อยแล้วทำซ้ำ ความสามารถในการใช้ LLM ให้ดีและความสามารถในการอธิบายปัญหาให้ชัดเจนจะยิ่งสำคัญขึ้น
เหตุผลที่โปรแกรมเมอร์มีประสบการณ์ใช้ LLM
- เป้าหมายของการใช้ LLM ไม่ได้หยุดอยู่แค่การเขียนโค้ดให้เร็วขึ้น
- การค้นหาเอกสารเฉพาะทาง
- การเรียนรู้ API ที่ซับซ้อนเกินจำเป็น
- การเขียนโปรแกรมที่จะทิ้งในอีกไม่กี่ชั่วโมง
- การจัดการรายละเอียดที่ไม่น่าสนใจในเชิงปัญญา
- เมื่อ Google กลายเป็นพื้นที่ค้นหาที่มีสแปมจำนวนมาก LLM จึงกลายเป็น เส้นทางทดแทน สำหรับเข้าถึงข้อมูลที่ต้องการอย่างรวดเร็ว
- ในโค้ดระดับสูงอย่าง Python มีการใช้ LLM เพิ่มขึ้น แต่ในโค้ด C ใช้น้อยกว่ามาก
- ความแตกต่างสำคัญอยู่ที่การแยกให้ออกว่าเมื่อใดใช้ LLM แล้วเร็วขึ้น และเมื่อใดใช้แล้วกลับช้าลง
- LLM มีประโยชน์มากสำหรับคนที่มีความตั้งใจ ความสามารถ และวินัย เช่นเดียวกับ Wikipedia หรือคลาสเรียนบน YouTube แต่อาจมีข้อจำกัดสำหรับคนที่ตามไม่ทัน
LLM ไม่ได้รอบรู้ทุกอย่าง และก็ไม่ใช่แค่นกแก้วนกขุนทอง
- การทำงานภายในของ neural network และ LLM ยังคง ไม่โปร่งใส อยู่มาก
- ผู้เชี่ยวชาญ AI บางส่วนเคยประเมิน LLM ต่ำเกินไปว่าเป็น Markov chain ขั้นสูง หรือเป็นระบบที่ทวนการดัดแปลงข้อมูลฝึกกลับมา แต่เมื่อเผชิญหลักฐาน มุมมองแบบ “นกแก้วนกขุนทอง” เช่นนั้นก็ถูกถอนกลับไปเป็นส่วนใหญ่
- ในทางกลับกัน ท่าทีที่ยกให้ LLM มีความสามารถเหนือธรรมชาติที่ไม่มีอยู่จริงก็ไม่ถูกต้องเช่นกัน
- LLM สามารถ interpolate ได้อย่างจำกัดภายในพื้นที่ที่ประกอบขึ้นจากข้อมูลที่เห็นระหว่างฝึก
- สามารถเขียนโปรแกรมที่ไม่เคยเห็นตรง ๆ มาก่อนได้
- สามารถผสมแนวคิดหลายอย่างที่ปรากฏบ่อยในข้อมูลฝึกได้
- หากต้องใช้การให้เหตุผลละเอียดอ่อน ก็อาจล้มเหลวอย่างมาก
- แม้มีข้อจำกัดเหล่านี้ LLM ก็ถือได้ว่าเป็นความสำเร็จครั้งใหญ่ที่สุดครั้งหนึ่งในประวัติศาสตร์ AI
ผู้ช่วยเขียนโปรแกรมในฐานะ “คนโง่ที่รู้เยอะ”
- LLM อาจให้เหตุผลพื้นฐานที่ผิดพลาดบ่อย เกิด hallucination และสร้างข้อเท็จจริงที่ไม่มีอยู่จริงได้
- ขณะเดียวกัน ในสาขาที่มีข้อมูลคุณภาพดีจำนวนมากอย่างการเขียนโปรแกรม มันทำงานเหมือน savant ที่มีความรู้มหาศาล
- อาจยังไม่ดีพอที่จะเป็นเพื่อนร่วม pair programming แต่มีประโยชน์ในโครงสร้างที่ผู้ใช้ตั้งคำถามและตรวจสอบคำตอบ
- ในอดีต หากรู้ภาษาไม่กี่ภาษา อัลกอริทึมคลาสสิก และไลบรารีหลัก ๆ ก็ทำงานได้หลายอย่าง
- ปัจจุบันความซับซ้อนเพิ่มขึ้นมากจากการระเบิดของ framework, ภาษา และไลบรารี ในสภาพแวดล้อมแบบนี้ “คนโง่ที่รู้ทุกอย่าง” จึงเป็นเพื่อนร่วมงานที่มีประโยชน์
ตัวอย่างความสำเร็จในโค้ดระดับสูงและการตีความข้อมูล
- เมื่อต้องย้ายจาก Keras ไป PyTorch LLM ช่วยเขียนโค้ดที่จำเป็นต่อการประกอบโมเดลโดยไม่ต้องศึกษาคู่มือ PyTorch ตั้งแต่ต้น
- ผู้ใช้รู้แนวคิดอย่าง embedding หรือ residual network อยู่แล้ว
- วิธีที่ได้ผลคือการเสนอ structure ของโมเดลที่ต้องการและคำถามให้ชัดเจน
- GPT-4 ดูโมเดล PyTorch และรูปแบบ batch แล้วเขียนโค้ด reshape tensor ให้เข้ากับอินพุตของ neural network
- ผู้ใช้ตรวจสอบใน Python CLI ว่ามิติของ tensor และ batch ของข้อมูลตรงกันหรือไม่
- เมื่อต้องสร้างไคลเอนต์ BLE สำหรับอุปกรณ์ที่ใช้ ESP32 ก็เขียนโค้ด Objective-C ได้รวดเร็วเพื่อใช้ API native ของ macOS
- มองว่า binding Bluetooth แบบหลายแพลตฟอร์มโดยทั่วไปใช้งานไม่ได้
- ต้องกลับมาจัดการ API BLE ของ Objective-C และรายละเอียดของ Objective-C ที่เคยใช้เมื่อนานมาแล้ว
- โค้ดสุดท้ายอยู่ที่ SerialBTE.m
- แม้ LLM ไม่ได้เขียนโค้ดส่วนใหญ่เองโดยตรง แต่ช่วยอธิบายสาเหตุของปัญหาและวิธีแก้ ทำให้ความเร็วในการเขียนเพิ่มขึ้นมาก
- โปรแกรมช่วยเหลือนี้ให้ผลตอบแทนต่อความพยายามต่ำ จึงมีความเป็นไปได้สูงว่าจะไม่ลองทำเลยหากไม่มี ChatGPT
การตีความโมเดล ONNX และการเขียนโปรแกรมที่จะทิ้ง
- เมื่อต้องใช้ convnet ฟอร์แมต ONNX ที่มีเอกสารไม่เพียงพอ LLM ช่วยตีความวิธีทำงานจาก metadata ของอินพุต/เอาต์พุตและค่า raw output ของภาพทดสอบ
- ตอนแรกไม่รู้ฟอร์แมตและขนาดของภาพอินพุต
- เอาต์พุตไม่ใช่ binary classification ง่าย ๆ แต่ประกอบด้วยค่าหลายร้อยค่า
- ChatGPT ตั้งสมมติฐานว่าเอาต์พุตอาจเป็น normalized box ที่แสดงบริเวณข้อบกพร่องที่เป็นไปได้ในภาพ และความน่าจะเป็นของข้อบกพร่อง
- หลังสนทนากันหลายรอบ ก็ได้สคริปต์ inference ด้วย Python และโค้ดแปลง input tensor
- สำหรับ “โปรแกรมที่จะทิ้ง” มีบางกรณีที่ปล่อยให้ LLM เขียนโค้ดทั้งหมด
- ระหว่างฝึก neural network ขนาดเล็ก GPT-4 ดูฟอร์แมต CSV แล้วสร้าง plot.py เพื่อ visualize loss curve
- ขอให้เมื่อส่งไฟล์ CSV หลายไฟล์ผ่าน command line ให้เปรียบเทียบ validation loss curve ของแต่ละการทดลอง
- งานทั้งหมดใช้เวลา 30 วินาที
- โปรแกรม pandas ที่อ่านรายงาน CSV ของ AirBnB แล้วจัดกลุ่มตามอพาร์ตเมนต์ รายเดือนและรายปี พร้อมคำนวณค่าเช่าเฉลี่ยรายเดือนโดยคำนึงถึงค่าทำความสะอาดและจำนวนคืนที่เข้าพัก ก็ทำงานได้ตั้งแต่ครั้งแรก
- โปรแกรมลักษณะนี้น่าเบื่อและไม่น่าสนใจนักในขั้นตอนเขียนเอง ดังนั้นเมื่อ LLM จัดการให้ ผู้ใช้จึงโฟกัสกับงานสำคัญได้
ข้อจำกัดที่เห็นชัดใน C และการเขียนโปรแกรมระบบ
- เมื่อเขียนโปรแกรม C แทบทุกครั้ง LLM ถูกใช้ในรูปแบบเอกสารที่สะดวกกว่าเท่านั้น
- ในการเขียนโปรแกรมระบบ จำเป็นต้องใช้การให้เหตุผลซับซ้อน และ LLM ปัจจุบันมักล้มเหลวตรงจุดนี้
- เมื่อขอให้ implement Bloom filter GPT-4 ได้เงื่อนไขว่ามีองค์ประกอบ 100,000 รายการและ false positive probability สูงสุด 5% แต่ไม่สามารถให้ implementation ที่ดีได้
- ใช้ hash function ที่คล้ายกันเพียงสองตัว
- ขาด abstraction สำหรับสร้าง hash จำนวน K ตัวที่ decorrelated เพียงพอจากสตริงเดียวกัน
- หากขออย่างชัดเจนให้สร้าง decorrelated output จำนวน N ตัว ก็เสนอ hash function ที่ดีขึ้น
- GPT-4 สามารถเขียน hash function ที่เหมาะสมกว่าได้เมื่อแยกเป็นปัญหาย่อยเล็ก ๆ แต่ไม่สามารถนำแนวคิดนั้นไปใช้เองในการออกแบบ Bloom filter ทั้งหมด
- ผลลัพธ์เช่นนี้อาจมองได้ว่าเป็นผลรวมของความสามารถในการให้เหตุผลที่อ่อนแอ การขาดข้อมูลเฉพาะหัวข้อ และข้อมูลคุณภาพต่ำที่ปะปนอยู่
ความแตกต่างระหว่างโมเดลแบบ local กับโมเดลขนาดใหญ่
- ในปัญหา programming ระบบ ความแตกต่างระหว่างโมเดลเล็กและโมเดลใหญ่เห็นได้ชัด
- Mixtral เสนอวิธีในปัญหา hash_id เดียวกันว่าให้เติม
hash_idต่อท้ายผลลัพธ์ hash ซึ่งถูกประเมินว่าเป็นวิธีแก้ที่แย่มาก - ผลลัพธ์ของ deepseek-coder 34B ที่ quantize เป็น 4-bit แล้วรันบน MacBook M1 Max ดีกว่า
- ผู้ใช้ให้เบาะแสว่าการเติม hash_id ที่ท้ายทำให้ distribution แย่ลง
- โมเดลระบุได้ว่าการบวกแบบง่ายอาจเป็นสาเหตุของปัญหา
- เสนอทางเลือกในการผสม
hash_idด้วย bitwise operation เช่น XOR
- กรณีนี้ใกล้เคียงกับการระบุสาเหตุของปัญหาและเสนอทางแก้ในรูปแบบที่ยากจะได้จากเอกสารหรือการค้น Google เพียงอย่างเดียว
- อย่างไรก็ตาม สำหรับโปรแกรมเมอร์ระบบที่มีประสบการณ์ LLM โดยทั่วไปยังแทบไม่สามารถให้ solution ที่น่าพอใจได้
กรณีตีความฟอร์แมต Q6_K ของ llama.cpp
- โปรเจกต์ ggufflib คือไลบรารีสำหรับอ่านและเขียนไฟล์ฟอร์แมต GGUF ที่ llama.cpp ใช้เมื่อโหลดโมเดล quantized
- encoding ของ quantization เก็บ bit ของแต่ละ quant ไว้ด้วยวิธีที่ซับซ้อนเพื่อความเร็ว
- ตอนแรกพยายามทำความเข้าใจ encoding ด้วย ChatGPT แต่การ reverse engineering โค้ด llama.cpp โดยตรงเร็วกว่ามาก
- แม้ฟังก์ชันจะเล็กพอให้เข้าไปอยู่ใน context ของ GPT-4 ได้ แต่ผลลัพธ์จากการดูประกาศ struct และ decoding function เพื่อสร้างเอกสารฟอร์แมตข้อมูลขึ้นมาใหม่กลับใช้ไม่ได้
- แม้ขอคำอธิบายฟอร์แมต Q6_K ก็ยังอธิบายไม่ชัดว่า lower/upper bit ถูกเก็บใน
qlและqhตามตำแหน่งของ weight อย่างไร- เมื่อต้องการฟังก์ชันอธิบายวิธีเก็บที่ง่ายกว่า index ก็ยังผิด
- การจัดการ sign extension จาก 6-bit เป็น 8-bit ก็ผิดเช่นกัน
- สุดท้ายงานนี้แก้ได้ด้วยกระดาษกับปากกา การอ่านโค้ด และการไล่ติดตาม bit ที่ decoder ดึงออกมา
- งานประเภทนี้คาดว่าอาจเป็นไปได้ภายในไม่กี่เดือนด้วย scaling อีกเล็กน้อยโดยไม่ต้องมี breakthrough
ลักษณะของงานเขียนโปรแกรมและความสามารถในการใช้ LLM
- งานเขียนโปรแกรมจำนวนมากในปัจจุบันคือการทำสิ่งเดิมซ้ำในรูปแบบที่ต่างไปเล็กน้อย และหลายครั้งไม่ต้องใช้การให้เหตุผลระดับสูง
- LLM ค่อนข้างเก่งกับงานเขียนโปรแกรมซ้ำ ๆ แบบนี้ แต่ข้อจำกัดด้านขนาด context ยังคงเป็นข้อจำกัดใหญ่
- ควรลองคิดดูว่า ในอีก 5 หรือ 10 ปีข้างหน้า การเขียนเฉพาะโปรแกรมชนิดที่ LLM ทำบางส่วนได้จะยังเป็นตำแหน่งที่ดีหรือไม่
- ความสามารถในการให้เหตุผลของ LLM ยังอ่อนและไม่สมบูรณ์ แต่ผลลัพธ์ที่สังเกตได้ก็อธิบายได้ยากหากมองว่าเป็นเพียงการทวนคำแบบง่าย ๆ
- เป้าหมายการเรียนรู้แบบทำนาย token ถัดไปบังคับให้สร้าง โมเดลนามธรรม บางรูปแบบขึ้นมา และโมเดลนั้นก็อ่อนแอ มีช่องโหว่จำนวนมาก และไม่สมบูรณ์
ทำไมจึงใช้ LLM ในตอนนี้
- เหตุผลที่จะไม่ใช้ LLM ในการเขียนโปรแกรมนั้นมีน้ำหนักน้อย
- ความสามารถในการตั้งคำถามที่ถูกต้องกับ LLM กลายเป็นทักษะสำคัญ
- ความสามารถในการอธิบายปัญหาให้ชัดเจนมีประโยชน์ไม่เฉพาะกับ LLM แต่รวมถึงการสื่อสารกับคนด้วย
- โปรแกรมเมอร์จำนวนมากอาจเก่งในบางสาขา แต่ขาดการสื่อสารที่ดี
- ในสถานการณ์ที่ Google ใช้งานยากขึ้น LLM ก็เหมาะจะใช้เหมือนเอกสารที่ถูกบีบอัด
- คุณค่าเชิงปฏิบัติของ LLM คือช่วยให้ไม่ต้องเรียนรู้ “junk knowledge” โดยตรงมากนัก เช่น โปรโตคอลสื่อสารกำกวม หรือรายละเอียดไลบรารีซับซ้อน
1 ความคิดเห็น
ความเห็นจาก Hacker News
ประเด็นสำคัญอยู่ตรงนี้: “จะทำได้ไหมถ้าไม่มี ChatGPT? แน่นอนว่าคงทำได้ แต่สิ่งที่น่าสนใจที่สุดไม่ใช่ว่ามันจะใช้เวลานานขึ้น ความจริงคือมันอาจไม่คุ้มพอจนไม่คิดจะลองทำตั้งแต่แรกด้วยซ้ำ”
ศักยภาพที่แท้จริงของ LLM ในการช่วยเขียนโค้ดคือการลดกำแพงในการเริ่มงานใหม่ ทำให้เราได้หยิบงานที่เดิมคงค้างอยู่ในกองโปรเจกต์อนาคตไปเรื่อย ๆ แบบไม่มีกำหนด มาลงมือทำจริงและทำจนเสร็จ
อินเทอร์เน็ตกับโอเพนซอร์สก็เคยให้ผลคล้ายกัน และโปรเจกต์ที่เราสนใจแต่ไม่ได้ลงมือทำเอง เมื่อเวลาผ่านไปก็จะมีคนอื่นแก้ปัญหาใกล้เคียงกันได้ดีพอจนเรานำกลับมาใช้หรือดัดแปลงได้ ส่งผลให้แอปและไลบรารีที่ใช้งานได้จริงเพิ่มขึ้นแบบระเบิด
LLM เพียงลำพังอาจไม่ได้เก่งมากนัก แต่ก็เห็นด้วยกับผู้เขียนที่บอกว่าสำหรับคนที่มีพื้นฐานและแรงจูงใจอยู่แล้ว มันคือ ตัวขยายพลัง
แต่พอทำไปก็พบว่ามันใช้แรงน้อยกว่าที่คิดมาก
การมีคนที่เหมาะสมมาคุยแลกเปลี่ยนไอเดียด้วยก็ให้ผลคล้ายกันได้ แต่คงไม่มีคนที่แม้จะไม่รู้โดเมนปัญหาทั้งหมดก็ยังให้ข้อมูลที่มีความหมายได้ รออยู่ ตลอด 24 ชั่วโมง แค่คลิกครั้งเดียว
มันช่วยได้บ้างในบางเรื่อง แต่พอถึงจุดที่ปกติผมเองก็ไม่รู้ว่ากำลังทำอะไรอยู่ โมเดลก็มักไม่ได้รู้ดีกว่าผม
นอกเหนือจากนั้น การแต่งพรอมป์ตให้เร็วพอมักยากกว่าการเขียนโค้ดเองเสียอีก
เลยสงสัยว่าหรือผมแค่ใช้เครื่องมือพวกนี้ไม่เป็น
ผมพอรู้จักไลบรารี ow2 asm อยู่แล้ว แต่มันช่วยประหยัดเวลาที่ต้องไปคุ้ยหารูปแบบ descriptor ที่แม่นยำ
และยังช่วยให้เข้าใจด้วยว่าทำไมไลบรารีวิเคราะห์แบบ static ตัวอื่น ๆ ถึงยังไม่พอสำหรับผม เพราะวิธีที่มันจัดการกับ state
สำหรับผม ChatGPT ทำอยู่สองอย่าง: ลดการค้นหา StackOverflow เรื่องจุกจิกกับการไล่อ่านโค้ดในไลบรารีเพื่อหาคำตอบของคำถามเฉพาะ และช่วยให้ประเมินได้ในช่วงศึกษาก่อนเริ่มโปรเจกต์ว่าวิธีที่ผมจะใช้มีความเป็นไปได้แค่ไหน
ถ้ามี ADHD รุนแรง เรื่องง่าย ๆ กลับเป็นเรื่องยากที่สุด แม้แต่การเอาขยะไปทิ้งหรือเปิดจดหมายก็แทบเป็นไปไม่ได้
บทสนทนาในหัวจะตะโกนอยู่หลายชั่วโมงให้ไปทำสิ่งนั้น แต่ร่างกายไม่ยอมทำตาม
เขาเรียกสิ่งนี้ว่า executive dysfunction และมันเป็นตัวปัญหาใหญ่ในชีวิตผม
แค่ LLM ช่วย ทำให้เริ่มลงมือได้ ก็เป็นเรื่องใหญ่มากแล้ว
ถ้าเป็นเรื่องการเขียนโปรแกรม ผมเห็นด้วยเต็มที่
จุดที่ใช้ LLM ได้ดีที่สุดคือเมื่อเรารู้หัวข้อนั้นดีพออยู่แล้วจนตรวจสอบผลลัพธ์ได้ และรู้มากพอที่จะอธิบายสิ่งที่ต้องการได้อย่างละเอียด หรืออย่างน้อยก็บอกแก่นสำคัญได้
มันช่วยให้ทำงานได้เร็วขึ้น ทำให้ได้ทำสิ่งที่ปกติคงไม่ทำ และช่วยมากกับการสร้างโปรแกรมเล็ก ๆ แต่มีคุณค่าที่พร้อมจะทิ้งได้
อีกด้านหนึ่งที่มีประโยชน์มากคือการ สำรวจหัวข้อใหม่เอี่ยม ไม่ว่าจะเกี่ยวกับการเขียนโปรแกรมหรือไม่ก็ตาม
แค่บอกไปว่าผมยังไม่ค่อยรู้เรื่องนี้ ไม่จำเป็นต้องลงรายละเอียดเฉพาะเจาะจง แต่อยากคุยเรื่องนี้และช่วยจัดระเบียบความคิดให้หน่อย
มันยิ่งมีประโยชน์มากสำหรับคนที่พร้อมจะไปค้นต่อหรือถามต่อจากสิ่งที่ได้ยิน
ด่านแรกของหลายสาขาคือการเข้าใจคำศัพท์พื้นฐาน ฟังว่าคนในวงการแบ่งแยกเรื่องต่าง ๆ กันอย่างไรและเพราะอะไร และรู้ว่าใครคือผู้เชี่ยวชาญสำคัญในหัวข้อนั้น
คือคอยจิ้มไปเรื่อย ๆ จนได้สัตว์ประหลาดที่ตัวเองไม่เข้าใจ แต่ build ผ่าน
คนที่กำลังเรียนรู้ต้องการความช่วยเหลือ แต่ความช่วยเหลือแบบที่ LLM สไตล์ Copilot ให้มาไม่ใช่รูปแบบที่ถูกต้อง
แทนที่จะพยายามสร้างโค้ดจากคำถามที่กำกวมหรือระบุผิดของจูเนียร์ ไม่แน่ว่าคงน่าสนใจถ้าฝึกโมเดล Copilot ที่ออกแบบมาเป็นคู่คิด คอยถามคำถามเพื่อทำให้ชัด แล้วช่วยตกลงแนวทางแก้ปัญหาไปด้วยกัน
ทุกครั้งมันจะผิดแบบละเอียดอ่อนหรือไม่ก็เสนอ สมมติฐานหลอน ขึ้นมาเลย และทำให้เสียเวลาไปจนกว่าจะรู้ว่าสิ่งนั้นผิด
ถ้ามันไม่มีท่าทีมั่นใจในคำตอบผิด ๆ อย่างไม่สมเหตุสมผล ก็คงยังพอพูดได้ว่ามันไม่ได้แย่ไปกว่าการเอาความรู้ที่ผมมีมาต่อ ๆ กัน แต่ตอนนี้มันโอเคแค่ในฐานะตัวแทน rubber duck หรือ autocomplete เท่านั้น
อยากได้ LLM ที่เราเข้าไปในเว็บไซต์ของภาษาใหม่สักภาษา แล้วคุยกับมันเกี่ยวกับเอกสารพวกนั้น ถามคำถาม และให้มันช่วยทำความเข้าใจ
ถ้ามันฝึกมาจากตัวอย่างโค้ดจริงของภาษา หรือเฟรมเวิร์กนั้น และช่วยเขียนโปรแกรมหรือฟังก์ชันใหม่ตรงนั้นได้เลยก็ยิ่งดี
ถ้าเชื่อมกับ REPL ออนไลน์แล้วช่วยแบบ inline ได้ด้วยก็จะยิ่งมีข้อได้เปรียบมาก
แง่มุมของ LLM ที่ถูกประเมินค่าต่ำที่สุดในมุมมองของผม คือบทบาทคล้าย นักพัฒนาที่รู้ทุกอย่าง ซึ่งบทความแตะไว้แต่ไม่ได้พูดตรงๆ
ต่อให้เป็นโปรแกรมเมอร์ระดับซีเนียร์ สุดท้ายก็ต้องเจอเทคโนโลยีที่แทบไม่รู้จักอยู่ดี
ทุกคนล้วนเป็นจูเนียร์ในบางด้าน
ต่อให้เป็นเทพแห่ง Win32, C++ และ COM ก็ยังอาจไปติดอยู่กับสคริปต์ NSIS สุดพิสดารตอนแพ็กเกจซอฟต์แวร์ได้
ต่อให้สร้างเว็บแอปมา 25 ปีและเคยนั่งในคณะกรรมการภาษา PHP แต่ถ้าได้รับงานให้ไปทำตามมาตรฐาน ISO สุดซับซ้อนที่ใช้สื่อสารกับเครือข่ายบัตรเครดิต ก็อาจไม่เคยสื่อสารกับเครือข่ายบัตรเครดิตในระดับนั้นมาก่อน
ต่อให้พัฒนาแอป iOS มาตั้งแต่ iPhone รุ่นแรก ก่อนหน้านั้นก็ทำแอป Mac เคยทำงานที่ Apple อยู่หลายปี จำ API ของ iOS ได้เกือบหมด แถมยังเคยออกแบบมันเองด้วย แต่ถ้าได้รับงานให้เพิ่มการรองรับ CalDAV ในแอป ก็อาจไม่รู้ด้วยซ้ำว่า CalDAV คืออะไร
ในสถานการณ์แบบนี้ LLM ช่วยได้ และถึงจะเขียนโค้ดทั้งหมดให้ไม่ได้ อย่างน้อยก็พาไปใน ทิศทางที่ถูกต้อง ได้
พอหัวถูกอัดแน่นด้วยเทคโนโลยีอื่น ก็จะมีช่วงที่ต้องดึงความรู้เก่าที่เคยเรียนแต่ถูกเบียดออกไปเพราะเทคโนโลยีใหม่กลับมาทบทวนอีกครั้ง
มันเป็นความรู้สึกแปลกๆ
คุณค่อยๆ ไหลไปตามค่ากลางของงานที่บริษัททำตามธรรมชาติ จนวันหนึ่งก็พบว่าไม่ได้แตะ CSS มา “พักใหญ่แล้ว”
คุณอาจต้องใช้เวลาสุดสัปดาห์เพื่อเรียกความคุ้นเคยกับ Python dataclass กลับมา
ถ้าเป็นสิ่งที่หาได้ด้วย Google ก็มีโอกาสสูงที่ LLM จะหาได้เร็วกว่าและสรุปให้ได้ดีกว่า
โชคดีที่ตอนนั้นผมน่าจะเกษียณไปแล้ว
กระแสที่บอกว่า “โค้ดส่วนใหญ่เขียนด้วยการคัดลอกจาก ChatGPT” ทำให้ผมแปลกใจ
ผมยังตกใจอยู่เสมอว่ามีคนจำนวนมากทนกับ workflow ที่ทรมานแบบนี้ได้
ผู้เขียนต้นฉบับไม่ใช่มือใหม่ที่ใช้ GPT เขียนเกินความรู้ของตัวเอง แต่เป็น วิศวกรที่ช่ำชอง อย่างชัดเจน
ปกติคนแบบนี้น่าจะใส่ใจกับ workflow การเขียนโค้ด รวมถึง usability และประสิทธิภาพของเครื่องมือ แต่หลายคนกลับยอมทนคัดลอกแล้ววางโค้ดไปมาระหว่าง GPT กับไฟล์ในเครื่อง
workflow อันน่าอึดอัดนี้เองที่เป็นแรงบันดาลใจแรกให้สร้าง aider
aider แชร์ local git repository กับ GPT เพื่อให้โค้ดใหม่และการแก้ไขถูกนำไปใช้กับไฟล์โดยตรง
มันยังแชร์บริบทของโค้ดที่เกี่ยวข้องให้ GPT ด้วย จึงเขียนโค้ดที่เชื่อมเข้ากับโปรเจ็กต์ได้
เลยทำได้มากกว่าแค่โค้ดโดดๆ ที่คัดลอกวางง่าย แต่ยังช่วยมีส่วนร่วมที่ซับซ้อนขึ้นได้
สุดท้ายมันจึงกลายเป็น workflow แบบ pair programming ที่ลื่นไหล ซึ่งผมกับ GPT คุยกันไปพร้อมกับแก้ไฟล์ร่วมกัน
https://github.com/paul-gauthier/aider
แต่มีวิธีใช้มันเพื่อคุยเรื่องโค้ดเฉยๆ ไหม?
ผมใช้ LLM เพื่อคุยข้อดีข้อเสียของหลายแนวทาง หรือช่วยคลี่โจทย์แบบ rubber duck
ถ้าจะทำแบบนั้นผมต้องคัดลอกโค้ด แต่ aider เน้นการนำการแก้ไขไปใช้ เลยไม่ค่อยเหมาะกับงานลักษณะนี้
ปกติผมต้องคุยโต้ตอบกันหลายรอบเรื่องวิธีที่ถูกต้องก่อน ถึงจะตัดสินใจว่าจะลงมือแก้จริงหรือไม่
เขาคือ ผู้สร้าง Redis
ถ้าคุณจ่ายค่าสมาชิกอยู่แล้ว การคัดลอกวางย่อมสมเหตุสมผลกว่าการไปจ่ายค่า API เพิ่ม
อีกอย่าง แต่ละคนก็มีเกณฑ์ไม่เหมือนกันว่าการเพิ่มประสิทธิภาพนั้นคุ้มพอจะไปพึ่งพาโปรเจ็กต์ของคนอื่นหรือไม่ โดยเฉพาะเมื่อโปรเจ็กต์แบบนี้มีความเสี่ยงจะถูกทำเป็นบริการเสียเงินหรือถูกปล่อยทิ้งได้
ครั้งแรกที่ลองกับไฟล์จริงมันใหญ่เกินไปจนพัง ครั้งที่สองกับไฟล์จริงอีกไฟล์ก็ยังใหญ่เกินไปอยู่ดี
ผมแปลกใจที่ดูเหมือน aider จะยังแบ่งไฟล์ใหญ่ให้พอดีกับข้อจำกัดโทเค็นไม่ได้
ข้อจำกัดโทเค็นของ GPT ไม่ได้รองรับไฟล์ซอร์สที่ใหญ่ขนาดนั้น
ถ้าผมต้องเป็นคนเลือกไฟล์ที่จะทำงาน และยังต้องผ่าตัดมันไม่ให้ GPT อาเจียนออกมา ผมก็ไม่แน่ใจว่ามันประหยัดเวลากว่าการใช้ Copilot ใน IDE หรือเปล่า
ตอนแรกผมคิดว่าการจัดการปัญหา “ขนาดโค้ด ≫ ขีดจำกัดโทเค็น” คือคุณูปการหลักของ aider แต่ดูเหมือนจะไม่ใช่
ผมอยากลองอีกครั้งนะ แต่ aider ยังอยู่ในหมวดเสียเปรียบแบบ “ต้องหาโจทย์และ codebase ที่ง่ายพอให้ aider รับมือไหว”
ในทางกลับกัน Copilot และ ChatGPT กลับมาช่วยผมได้ทุกวันในงานจริง บน codebase จริง พร้อมทั้งตำหนิข้อบกพร่องต่างๆ ของมัน
ผมคิดว่าฟีเจอร์ปัจจุบันรองรับ use case แบบแชตและการตรวจสอบได้ยอดเยี่ยม
คอมเมนต์ที่นี่อาจไม่ได้สะท้อนความพึงพอใจสูงของผู้ใช้ซอฟต์แวร์ส่วนใหญ่
Aider ช่วยให้ use case ที่ antirez พูดถึงในบทความเกิดขึ้นได้จริง
โดยเฉพาะเมื่อคนใช้เก่งขึ้นเรื่อยๆ ในการ ตั้งคำถามกับ LLM ให้ถูกต้อง อย่างที่ antirez บอก
ช่วงไม่กี่วันที่ผ่านมา ผมพยายามแก้บั๊กในแอป Mac แบบปิดซอร์สตัวหนึ่ง
ผมชอบแอปนั้น แต่บั๊กนี้ทำผมหงุดหงิดแทบตายมาหลายปี
ผมค่อนข้างมั่นใจว่าเมธอด Objective-C ตัวหนึ่งเป็นต้นเหตุของบั๊กนั้นคร่าวๆ แต่ไม่รู้ว่าเมธอดนั้นทำอะไร และเวอร์ชันที่ decompile ออกมาก็ดูเป็นขยะเละเทะอ่านไม่รู้เรื่อง
มันให้ความรู้สึกเหมือนชนกำแพง
แล้วผมก็ลองเอาเสียงรบกวนที่ decompiler พ่นออกมาใส่ GPT-4 แล้วขอให้มันแปลงเป็นเวอร์ชันที่สะอาดขึ้น
ผลลัพธ์ไม่สมบูรณ์แบบ แต่ผมจัดการเกลามันต่อได้ และเมื่อเอาผลลัพธ์นั้นไป swizzling ใส่ในแอป บั๊กก็ดูเหมือนจะหายไป
ผมไม่เคยหา step สำหรับ reproduce ได้ แต่โดยปกติแล้วตอนนี้ควรจะเป็นช่วงที่ปัญหาเกิดขึ้นแล้ว
นี่เป็นสิ่งที่ผมไม่มีทางทำได้เลยหากไม่มี GPT-4
แน่นอนว่าถ้าคุณเขียนชิ้นโค้ดนั้นใหม่ทั้งหมด โอกาสที่มันจะยังมีบั๊กแบบเดียวกับของเดิมก็ย่อมน้อยลง แม้จะใช้ LLM โดยไม่เข้าใจว่ามันทำอะไรก็ตาม
แต่ก็อาจทำให้เกิดบั๊กอื่นแทนได้ และผมหวังว่าจะไม่มีใครทำแบบนี้กับโค้ดที่ผลลัพธ์ของบั๊กสำคัญมาก เช่น ระบบล่มหรือทำให้ลูกค้าเสียค่าใช้จ่าย
บทความนี้ทำให้ฉันช็อกจริงๆ
Salvatore เป็นหนึ่งในวิศวกรซอฟต์แวร์ที่เก่งที่สุดคนหนึ่งที่ยังทำงานอยู่ในปัจจุบัน
เขามองเห็นได้อย่างชัดเจนว่าเครื่องมือที่เรียกกันเช่นนี้ไร้ประโยชน์โดยสิ้นเชิงในสายงานความเชี่ยวชาญของเขา
แต่ถึงอย่างนั้น แทนที่จะโยนมันทิ้งเหมือนไขควงที่ใช้ไม่เข้ากับงานและงอไปแล้ว เขากลับยอมรับสมมติฐานของพวกที่พยายามปกป้องมันว่าอย่างไรก็ต้องหาประโยชน์จากมันให้ได้
อย่างที่เรียนกันในวิชาเศรษฐศาสตร์มหภาคเบื้องต้น ถ้าเกาะหนึ่งได้เปรียบกว่าในการผลิตวิดเจ็ต A ก็ย่อมเกิดการแบ่งงานเฉพาะทางที่เกาะ A ใช้ประโยชน์จากเกาะ B แม้ว่าความสามารถของอีกเกาะในการผลิต B จะย่ำแย่แค่ไหนก็ตาม
ดังนั้นจึงเป็นเรื่องธรรมดาที่ความสามารถเชิงเปรียบเทียบของ antirez ในการเขียนโปรแกรมระบบจะผลัก LLM ไปทำงานเขียนโปรแกรมประเภทอื่นแทน
แต่เราไม่ได้อยู่กันอย่างโดดเดี่ยว
รอบตัวเรามีมนุษย์จำนวนมากที่ต้องการทั้งความท้าทายทางเทคนิคและอาหารกิน
หลายคนในนั้นมีหรือสามารถพัฒนาทักษะที่เสริมกับของเราได้
เมื่อทำงานร่วมกัน ผลลัพธ์จากความร่วมมืออาจมากกว่าผลรวมของแต่ละส่วน
บางที LLM อาจเขียนโค้ด PyTorch ได้ดีกว่า antirez ก็ได้
แต่การที่มีไขควงเก่าๆ งอๆ อยู่ในโรงรถ ไม่ได้แปลว่าเราจำเป็นต้องใช้มัน
วันนี้การไปที่ร้านฮาร์ดแวร์อาจเป็นทางเลือกที่ดีกว่า
เพราะไวยากรณ์ที่เป๊ะหรือการปรับรูปทรงเทนเซอร์ไม่ใช่เรื่องสำคัญมากสำหรับฉัน
ถ้าเป็นการใช้งานส่วนตัวเพื่อสร้างและเทรน convnet กับภาพของฉันเอง ก็ไม่จำเป็นต้องไปรบกวนผู้เชี่ยวชาญ Torch
ถ้าฉันเข้าใจตัว convnet เองดีพอ และแค่ยังไม่รู้ไวยากรณ์หรือเมธอดของ Torch มากพอ ก็ทำเองได้
ทางเลือกก็คือไปนั่งศึกษารายละเอียดในคู่มือ Torch ซึ่งผลลัพธ์ก็คงเหมือนกัน
สิ่งสำคัญในงานนี้ไม่ใช่รายละเอียดของ MLX, Keras, PyTorch แต่คือการควบคุม แนวคิดด้านแมชชีนเลิร์นนิง ให้ได้
ตอนนี้มันก็มีประโยชน์อยู่บ้าง แต่ก็ไม่ถึงกับใช่จริงๆ และถ้าไม่ใช้ก็ไม่ได้แปลว่าเราจะ “ตามไม่ทัน”
ทุกคนที่เกี่ยวข้องกำลังพยายามสุดความสามารถเพื่อทำให้มันเก่งขึ้นอยู่แล้ว ดังนั้นเมื่อถึงวันนั้นก็แค่สั่งสิ่งที่ต้องการผ่านพรอมป์ต์
ไม่จำเป็นต้องรีบเค้นอะไรออกจากเจเนอเรชันปัจจุบัน เพราะตอนนี้หลายครั้งมันลด productivity มากกว่าจะเพิ่ม
ถึงขั้นสงสัยเลยว่าเราอ่านบทความเดียวกันจริงหรือเปล่า
เขาเห็นเครื่องมือใหม่ที่คนอื่นมองว่าน่าสนใจ แล้วก็หาวิธีใช้ที่เป็นประโยชน์กับตัวเอง พร้อมทั้งยอมรับจุดที่มันไร้ประโยชน์ด้วย
และก็ยกตัวอย่างที่มันไม่ได้ไร้ประโยชน์มาสนับสนุนไว้มากพอ
มันไม่ใช่ข้อค้นพบปฏิวัติวงการอะไรเป็นพิเศษสำหรับนักพัฒนา
เราใช้เครื่องมือหลากหลายอย่าง เช่น ภาษาโปรแกรม อยู่ตลอด และเครื่องมือแต่ละอย่างก็มีจุดแข็งกับจุดอ่อน
ไม่เข้าใจว่าทำไม LLM ต้องถูกมองว่าแตกต่างขนาดนั้น
การอ้างว่ามันไม่มีจุดแข็งเลยก็ดูเป็นความคิดที่ไร้เหตุผล
แล้วจะทำแบบนั้นได้ในราคา ต่ำกว่า 20 ดอลลาร์ต่อเดือน ไหม?
เวลาเริ่มโปรเจกต์ใหม่มันจะมี ปัญหาอิมพีแดนซ์ อยู่
ตอนเริ่ม งานยังเสร็จไป 0% และไม่ว่าจะเป็น hello world, ไฟล์ CMakeLists หรือสคริปต์ Python ก็ต้องเริ่มจากตรงไหนสักแห่ง ซึ่งมันยาก
ก่อนยุค ChatGPT/LLM ฉันต้องดึงแรงนั้นออกมาจากตัวเองจนถึงปลายนิ้ว
ตอนนี้โยนให้ ChatGPT ทำได้
ในทางปฏิบัติมันมีประสิทธิภาพน้อยกว่าและพลังน้อยกว่าการ “นั่งลงแล้วทำเอง” แต่ช่วยตัดต้นทุนของการ “ตัดสินใจนั่งลงแล้วทำเอง” ออกไปได้
ถึงอย่างนั้นมันก็ยังเป็นการคัดลอกชิ้นส่วนจาก GitHub code search, StackOverflow, บล็อกสุ่มๆ, เอกสาร, Discord ฯลฯ แล้วเอามาปะติดปะต่อเหมือนเดิม
หลังจากลองและลองใหม่ไม่กี่ครั้ง ก็จะได้ จุดเริ่มต้น 5% ของโปรเจกต์ และพอเริ่มเป็นรูปเป็นร่าง ในที่สุดก็เริ่มทำงานจริงได้
สุดท้ายจึงกลายเป็นการสร้าง proof of concept ตื้นๆ ที่ ChatGPT พ่นออกมาอย่างรวดเร็วด้วยการคัดลอกและวาง แล้วพอมีแรงส่งมากพอก็ค่อยเปลี่ยนไปลงมือขุดลึกเอง
เพราะอย่างนั้นมันจึงช้ากว่า ไร้ประสิทธิภาพกว่า และไม่ใช่ว่า ChatGPT จะเก่งกว่าฉัน แต่ทำได้ง่ายกว่าและไม่ต้องขุดลึกตั้งแต่แรก
ท้ายที่สุดฉันจึงทนไหวกว่ามากในช่วงกลางและท้ายซึ่งเป็นส่วนสำคัญจริงๆ ของโปรเจกต์ และไม่หมดไฟตั้งแต่ต้น
ฉันตั้งคำถามที่ถูกต้องตั้งแต่แรกไหม หรือถ้าไม่ใช่ ยังจะกู้สถานการณ์ของงานนั้นกลับมาอย่างมีประสิทธิภาพได้ไหม?
ต้นทุนจมถูกดูดหายเข้าไปใน ค่าสมาชิกรายเดือน 20 ดอลลาร์
ฉันคิดว่าประเด็นสำคัญอยู่ตรงที่ว่า “มีปัญหาอยู่ และถ้า LLM เพ้อเจ้อ ฉันต้องรู้ให้เร็วว่าเรื่องไหนที่ฉันตรวจสอบได้ ในกรณีนั้นฉันใช้ LLM เพื่อเร่งความเร็วในการได้มาซึ่งความรู้ที่ต้องใช้”
เหตุผลหนึ่งที่การเขียนโปรแกรมเข้ากับ LLM ได้ดีเป็นพิเศษ คือการตรวจสอบว่าคำตอบถูกต้องหรือไม่มักเป็นเรื่องเล็กน้อย
ฉันกำลังทดลองแนวคิดในการประเมินว่า LLM เป็นเครื่องมือที่เหมาะกับงานนั้นหรือไม่
ประมาณว่าเอา “ความสำคัญที่ผลลัพธ์ต้องถูกต้อง” กับ “ความง่ายในการตรวจสอบว่าผลลัพธ์ถูกต้องหรือไม่” มาพล็อตเป็นกราฟ
การใช้ ChatGPT ทำรายชื่อเพลงที่มีศิลปินหญิงเจ้าของรางวัล Emmy เข้าร่วมด้วยนั้นใช้เวลาตรวจความถูกต้อง แต่ความสำคัญก็ต่ำ และมีข้อผิดพลาดบ้างก็ยังพอรับได้
ถ้างั้นซอฟต์แวร์ก็คงไม่มีบั๊กเลยสินะ?
มันคือปัญหาประเภทที่คิดวิธีแก้ยาก แต่ตรวจสอบวิธีแก้ที่เป็นไปได้กลับง่าย
และทุกคนก็รู้ว่าปัญหาประเภทนั้นเรียกว่าอะไร
โลกนี้เต็มไปด้วยข้อความจุกจิกที่ไม่เกี่ยวข้องและไม่แม่นยำอยู่แล้ว และเราควรลดการผลิตสิ่งเหล่านั้นมากกว่าจะเร่งให้เร็วขึ้น
ไม่ได้พูดถึงตัวอย่างใดตัวอย่างหนึ่ง แต่พูดถึงแนวคิดโดยรวมทั้งหมด
ใช้ ChatGPT เป็น คู่คิด ในการเขียนโค้ด
คุยด้วยทุกวันตลอดทั้งวันจนงานเสร็จ
บริษัทอนุมัติให้ใช้ Copilot แต่ระบบเติมโค้ดอัตโนมัติของ Copilot ให้ประสบการณ์ที่แย่มาก
บริษัทไม่ได้อนุมัติ Copilot Chat ที่ฉันต้องการ
ถึงอย่างนั้นก็อยากได้เครื่องมือคล้ายกันที่ช่วยสร้าง unit test หรือคอมเมนต์โค้ดจากโค้ดของฉันบนโน้ตบุ๊กได้
แน่นอนว่าต้องอาศัยอินพุตและการชี้นำจากฉัน
เพื่อนร่วมงานหลายคนชมกันมากจนฉันนึกว่าตัวเองแปลกหรือเปล่า แต่สำหรับฉันมันรบกวนสมาธิมาก และก็ปิดมันไปหลังจากใช้ได้ไม่กี่วัน
มันเหมือนมีใครสักคนพยายามพูดต่อประโยคทั้งที่ฉันยังพูดไม่จบ
ต่อให้เดาถูกก็ยังน่ารำคาญ ทำให้หลุดโฟลว์ และก็ผิดบ่อยมาก
[0] https://continue.dev/
[1] https://ollama.ai/
เมื่อไม่กี่วันก่อนฉันลองใช้ Codeninja
เท่าที่จำได้ มันยังเทียบกับรุ่น 4 ที่รันอยู่หลังบ้านของ Copilot ไม่ได้เลย แต่สำหรับข้อมูลอ่อนไหวที่ห้ามออกไปภายนอก นี่แทบจะเป็นตัวเลือกเดียว
หรือไม่ก็อาจขอ dedicated instance จาก OpenAI
นี่อาจเป็นช่วงที่สำคัญที่สุดในบทความนี้ และเมื่อคิดถึงสิ่งที่จะถาโถมเข้ามาในปี 2024 ก็เป็นประเด็นที่ย้ำเท่าไรก็ไม่เกินไป
“แล้ว LLM มีความสามารถในการให้เหตุผลอยู่มากน้อยแค่ไหน หรือทั้งหมดเป็นแค่ภาพลวง? อย่างที่นักสัญศาสตร์กล่าวไว้ ‘ตัวหมาย’ อาจสร้างความรู้สึกว่ามีความหมายบางอย่างอยู่ ทั้งที่จริงแล้วไม่มี จึงทำให้บางครั้งมันดูเหมือนกำลังใช้เหตุผลก็ได้ แต่คนที่ใช้งาน LLM มามากพอจะรู้ว่า แม้จะยอมรับข้อจำกัดของมัน ก็ไม่อาจอธิบายทุกอย่างได้ด้วยเหตุผลนั้นเพียงอย่างเดียว ความสามารถในการนำสิ่งที่เคยเห็นมาก่อนมาผสมกันนั้นไปไกลกว่าการพ่นคำแบบสุ่มอย่างมาก แม้ว่าการฝึกส่วนใหญ่จะเกิดขึ้นในช่วง pretraining ด้วยวิธีทำนายโทเคนถัดไป เป้าหมายนี้ก็ยังบังคับให้โมเดลต้องสร้าง แบบจำลองเชิงนามธรรม บางรูปแบบขึ้นมา แบบจำลองนี้อ่อนแอ มีช่องโหว่มาก และไม่สมบูรณ์ แต่ถ้าสิ่งที่เราสังเกตนั้นมีอยู่จริง มันก็ต้องมีอยู่แน่นอน เมื่อความมั่นใจทางคณิตศาสตร์ยังน่าสงสัย และแม้แต่ผู้เชี่ยวชาญระดับแนวหน้าก็มักยืนกันคนละฝั่ง การเชื่อสิ่งที่เห็นด้วยตาตัวเองก็ดูจะเป็นทางเลือกที่ฉลาด”