แม้จะเป็นผู้ใช้ LLM ที่มีประสบการณ์สูง แต่ทำไมในชีวิตจริงถึงไม่ได้ใช้บ่อยนัก

• ผู้เขียนเผยว่าแม้จะศึกษาวิจัย LLM และเทคโนโลยีการสร้างข้อความมานานกว่า 10 ปี แต่กลับไม่ได้ใช้ LLM บ่อยนักในชีวิตประจำวันอย่างที่คาดไว้
• เมื่อต้องใช้ LLM จะให้ความสำคัญกับการควบคุมอย่างละเอียด เช่น prompt engineering, การตั้งค่า system prompt และการปรับอุณหภูมิ โดยชอบเข้าถึงผ่าน API มากกว่าการใช้ฟรอนต์เอนด์ทั่วไป
• ในงานที่ BuzzFeed ผู้เขียนใช้ LLM เพื่อแก้ปัญหาเฉพาะทาง เช่น การติดป้ายกำกับข้อมูล, การสรุปคลัสเตอร์ข่าว และการตรวจสอบ style guide ซึ่งพิสูจน์แล้วว่าช่วยประหยัดเวลาได้มาก
• แม้จะไม่ใช้ LLM ในการเขียนบทความ แต่ใช้มันเพื่อทดสอบมุมมองเชิงวิพากษ์ผ่านคอมเมนต์ Hacker News สมมติ เพื่อตรวจสอบตรรกะของงานเขียน
• LLM มีประโยชน์ในการช่วยเขียนโค้ด แต่สำหรับงานที่ซับซ้อนหรือต้องการความน่าเชื่อถือสูง ผู้เขียนยังคงเลือกลงมือทำเอง และยังคงมีมุมมองเชิงสงสัยต่อ agent และ vibe coding

---

ระยะห่างระหว่างฉันกับ LLM

• ผู้เขียนเป็นนักวิทยาศาสตร์ข้อมูลที่มีประสบการณ์สูงในการใช้เครื่องมือ Generative AI มาอย่างยาวนาน ตั้งแต่การสร้างข้อความด้วย RNN, การปรับแต่ง GPT-2 ไปจนถึงการทดลองกับ GPT-3/ChatGPT
• แต่กรณีที่ใช้งานโดยตรงเป็นประจำกลับมีไม่มาก และการจะใช้หรือไม่ใช้นั้นเป็นแนวทางเชิงเครื่องมือที่ตัดสินตามลักษณะงานและความจำเป็น

วิธีควบคุม LLM

• หัวใจสำคัญของการใช้ LLM คือการชี้นำให้ได้ผลลัพธ์ตามต้องการผ่านprompt engineering
• แทนที่จะใช้ฟรอนต์เอนด์ทั่วไปอย่าง ChatGPT.com ผู้เขียนเลือกเรียก API โดยตรงหรือใช้งานผ่าน UI ฝั่งแบ็กเอนด์ และชอบ Claude Sonnet API เป็นพิเศษ
• ใช้ system prompt และการปรับค่า temperature เพื่อบาลานซ์ระหว่างความสร้างสรรค์กับความเป็น deterministic โดยมักตั้งไว้ที่ 0.0 ~ 0.3 เพื่อให้ผลลัพธ์คาดเดาได้มากขึ้น
• ปัญหาhallucination (การสร้างข้อมูลที่ไม่เป็นความจริง) มักรุนแรงขึ้นเมื่ออุณหภูมิสูง จึงต้องระวังเป็นพิเศษ

ตัวอย่างการใช้งานในงานจริง

• ระบบอัตโนมัติสำหรับจัดหมวดหมู่ข่าวของ BuzzFeed: ใช้ Claude API ร่วมกับโครงสร้างการจัดหมวดหมู่แบบ JSON และตั้ง temperature 0.0 เพื่อกำหนดหมวดหมู่ได้อย่างแม่นยำ
• การสรุปคลัสเตอร์ข่าว: ป้อนข่าวที่คล้ายกัน 5 ชิ้น แล้วให้โมเดลส่งคืนชื่อเรื่องและคำอธิบายร่วมกัน เพื่อทำระบบสรุปคลัสเตอร์ได้อย่างมีประสิทธิภาพ
• การตรวจสอบเครื่องหมายวรรคตอนและ style guide: ใส่ style guide ทั้งหมดไว้ใน system prompt แล้วให้โมเดลตัดสินไวยากรณ์ตามนโยบายที่กำหนด
• แต่ละงานสามารถทำ POC ได้ภายในไม่กี่ชั่วโมง และพิสูจน์แล้วว่าช่วยลดเวลาจากเดิมได้มากกว่าหลายวัน

เขียนเอง แต่ให้ LLM ช่วยวิจารณ์

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

การใช้ LLM กับงานเขียนโค้ด

• ในงานที่ซับซ้อนแต่ทำซ้ำบ่อย เช่น การเขียน regular expression หรือการคอมโพสิตภาพด้วย Pillow นั้น LLM ช่วยเพิ่มผลิตภาพได้มาก
• ในทางกลับกัน เมื่อใช้กับไลบรารีใหม่อย่าง Polars โมเดลอาจสับสนและเผลอใช้ฟังก์ชันของ pandas ซึ่งก่อให้เกิดปัญหาได้
• ผู้เขียนไม่ค่อยชอบคำแนะนำโค้ดแบบเรียลไทม์อย่าง Copilot เพราะมองว่าทำให้ต้องสลับบริบททางความคิดบ่อยจนเสียสมาธิ
• จุดยืนคือ**"ยืมไอเดียมา แล้วแก้เอง" ดีกว่ารับข้อเสนอจาก LLM มาใช้ตรง ๆ**

มุมมองต่อ Agents, MCP และ Vibe Coding

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

ความคิดต่ออุตสาหกรรม LLM และจริยธรรม

• ข้ออ้างว่า "LLM ใช้งานไม่ได้จริง" นั้นไม่สะท้อนความเป็นจริงของการใช้งานจริง และประเด็นสำคัญกว่าคือROI ระยะสั้นและปัญหาเชิงโครงสร้างของอุตสาหกรรม
• โมเดลโอเพนซอร์สและโครงสร้างพื้นฐานทางเลือกอย่าง Cerebras, Groq เป็นต้น สามารถตอบสนองความต้องการ LLM ได้แม้ OpenAI จะหายไป
• ท้ายที่สุดแล้ว LLM คือเครื่องมือที่ควรถูกใช้อย่างเหมาะสมตามวัตถุประสงค์ และทั้งการสรรเสริญแบบไร้เงื่อนไขและการปฏิเสธแบบสุดโต่งล้วนเป็นอันตราย

สรุป

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

[ifmkl]

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

[GN⁺]

ความคิดเห็นบน Hacker News

• มีความเห็นเกี่ยวกับจุดที่ชวนสับสนเมื่อโปรแกรมเมอร์ที่มีประสบการณ์ทำงานกับ LLMs

  • pandas เป็นไลบรารีมาตรฐานสำหรับจัดการข้อมูลแบบตารางใน Python และถูกใช้งานมาตั้งแต่ปี 2008
  • ช่วงหลังเริ่มใช้ไลบรารี polars ตัวใหม่ และ LLMs มักสับสนฟังก์ชันของ polars ว่าเป็นฟังก์ชันของ pandas จึงต้องคอยตรวจเอกสารประกอบ
  • เหตุผลที่ไม่ใช้ coding agent คือมัน "รบกวนสมาธิ" ซึ่งเป็นมุมมองที่คนที่ไม่ชอบ autocomplete น่าจะเข้าใจได้
  • LLMs แบบ "ล้วนๆ" ทำให้เกิดข้อผิดพลาดในโค้ดระหว่างงานเขียนโปรแกรม แต่การตั้งค่า agent LLM ยังมีโค้ดที่ช่วยจัดโครงสร้างการโต้ตอบกับ LLM รวมอยู่ด้วย
  • ถ้า LLM ทำให้เกิดข้อผิดพลาดของฟังก์ชัน โปรแกรมก็จะคอมไพล์ไม่ผ่าน และ agent จะตรวจพบก่อนให้ LLM แก้ซ้ำไปเรื่อยๆ

• ใช้ vibe coding เวลาสร้าง mock UI หรือเว็บไซต์

  • แม้จะไม่มีประสบการณ์ฝั่งฟรอนต์เอนด์ แต่การทำไลฟ์เดโมที่เสร็จไปแล้ว 80% เพื่อเอาไปให้คนอื่นดูนั้นมีคุณค่า
  • ยังไม่พร้อมสำหรับผลิตภัณฑ์จริง แต่มีประโยชน์สำหรับการทำ mock เพื่อใช้คุยกันภายในทีม

• เคยลองใช้หลายวิธีเพื่อให้ได้ผลลัพธ์ที่ดีที่สุดจาก LLMs

  • การคิดสถานการณ์เพื่อ "หลอก" LLMs นั้นไม่มีประสิทธิภาพ และผลลัพธ์อาจต่างกันมากตามเวอร์ชันของโมเดล

• จะระมัดระวังกับเอาต์พุตของ LLM มากขึ้นเมื่อเป็นคำถามโค้ดที่ซับซ้อนเกี่ยวกับไลบรารีที่ไม่ค่อยนิยม

  • ในช่วงไม่กี่เดือนที่ผ่านมา การใช้หน้าต่าง ChatGPT เพื่อแก้คำถามโค้ดเกี่ยวกับไลบรารีใหม่ๆ ได้ผลดี
  • งานอัปเกรดโค้ดไปใช้ไลบรารี JavaScript ใหม่ทำได้สำเร็จ

• ใช้วิธีคัดลอกเอกสารของไลบรารีใหม่หรือทั้งโค้ดเบสไปวางตรงๆ ในโมเดลที่รองรับบริบทยาว

  • ได้ผลดีกับไลบรารีที่มีขนาดต่ำกว่า 50,000 โทเคน และ Gemini 2.5 Pro ก็จัดการได้ดีแม้ระดับหลายแสนโทเคน

• ชอบที่ผู้เขียนแนบบันทึกการสนทนามาด้วย

  • หลายคนแชร์ไม่ได้เพราะอาจเปิดเผยข้อมูล แต่เมื่อจะอ้างถึงประสิทธิภาพของ LLM ก็ควรมีสิ่งนี้ไว้รองรับ

• ไม่ใช้ ChatGPT.com หรือส่วนติดต่อผู้ใช้แบบทั่วไป

  • ใช้ backend UI ของแต่ละบริการ LLM เพื่อให้ได้ผลลัพธ์ที่ดีกว่า
  • OpenAI มีแนวโน้มจะจำกัดโมเดลใน UI ของ ChatGPT

• อินเทอร์เฟซ LLM สมัยใหม่ที่ไม่เปิดให้ตั้ง system prompt แบบชัดเจน จะใช้ system prompt ของตัวเอง

  • ChatGPT มี system prompt แต่ Claude ไม่มี
  • ในโมเดลใหม่ๆ ประโยชน์ของ system prompt กำลังลดลง

• การกำหนดข้อจำกัดเฉพาะสำหรับข้อความที่สร้างขึ้น มักได้ผลดีกว่าเมื่อใส่ไว้ใน system prompt มากกว่า user prompt

  • LLMs เข้าใจแนวคิดเรื่อง 30 คำได้ แต่ก็ไม่ได้ทำงานนี้ได้ดีเสมอไป

• ใช้ backend UI ของแต่ละบริการ LLM

  • สงสัยว่าใช้ wrapper แบบปรับแต่งเองเพื่อเชื่อมกับ API หรือใช้ไคลเอนต์ที่มีอยู่แล้ว

• การตอบกลับแบบ JSON ไม่ได้ทำงานตามคาดเสมอไป

  • หากต้องการให้คืนค่า JSON อย่างสม่ำเสมอ ควรกำหนด JSON schema เพื่อบังคับให้คืนโครงสร้างเดิมเสมอ

• ใช้ LLM เพื่อเรียนรู้สิ่งใหม่หรือเขียนสคริปต์สั้นๆ

  • เทคนิคเอาข้อความจากบล็อกโพสต์ใส่เข้าไปใน LLM แล้วขอให้ LLM แกล้งเป็นคอมเมนเตอร์ Hacker News สายประชดและเขียนคอมเมนต์ 5 แบบนั้นน่าสนใจ