อย่าปล่อยให้ LLM เป็นผู้ตัดสินใจหรือรันบิสิเนสลอจิก

ข้อโต้แย้งหลัก: ควรออกจาก LLM ให้เร็วที่สุดและไม่ควรอยู่ในนั้นนาน

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

ทำไมถึงเป็นเช่นนั้น?

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

• ประสิทธิภาพ: แม้ LLM จะเล่นหมากรุกได้น่าทึ่ง แต่ก็ยังช้ากว่าและแม่นยำน้อยกว่าเอนจินหมากรุกเฉพาะทางอย่าง Stockfish

• ดีบักและปรับแต่งได้ยาก: ยากที่จะรู้ว่าทำไมมันถึงตัดสินใจแบบนั้น จึงแก้ไขให้ทำงานตามที่ต้องการได้ลำบาก

• ปัญหาอื่น ๆ:

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

การแบ่งบทบาทที่ถูกต้องจากตัวอย่างหลากหลาย

• ในเกม ถ้าพูดว่า "ฉันจะโจมตีผู้เล่น X ด้วยดาบโวร์พัล" → LLM ควรทำหน้าที่เพียงแปลงสิ่งนี้เป็น attack(player=X, weapon="vorpal_sword") แล้วส่งต่อให้ลอจิกของเกม
• เอเจนต์การเจรจา → LLM ไม่ควรเป็นผู้ตัดสินใจในการเจรจา แต่ควรห่อหุ้มอินพุตของผู้ใช้ ส่งต่อให้เอนจินการเจรจา แล้วสื่อสารผลลัพธ์กลับมา
• การสร้างคำตอบแบบสุ่ม → ไม่ควรให้ LLM เป็นผู้เลือก แต่ควรให้ฟังก์ชันสุ่มจากภายนอกจัดการ

สิ่งที่ LLM ทำได้ดี

• LLM เชี่ยวชาญเรื่อง การแปลง การตีความ และการสื่อสาร
• ตัวอย่าง:
  • "ตีออร์คด้วยดาบ" → แปลงเป็น attack(target="orc", weapon="sword")
  • { "error": "insufficient_funds" } → อธิบายอย่างเป็นธรรมชาติว่า "ทองไม่พอ"
  • สามารถจำแนกได้ว่าอินพุตของผู้ใช้เป็นคำสั่งต่อสู้ การตรวจสอบไอเท็ม หรือการขอความช่วยเหลือ
  • เข้าใจแนวคิดแบบมนุษย์ได้ดี (เช่น blade = sword, smash = attack)
• แก่นสำคัญคือ ไม่ใช่การตัดสินใจซับซ้อนหรือการจัดการสถานะ → แต่เป็นการทำหน้าที่เป็นสะพานเชื่อมเจตนาของผู้ใช้กับระบบ

มุมมองในอนาคตและหลักการที่ยังคงใช้ได้

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

[GN⁺]

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

• ตรรกะมีอยู่สองประเภท

  • 1. ตรรกะที่โดยเนื้อแท้แล้วต้องถูกต้องและเคร่งครัด
  • 2. ตรรกะที่เป็นมาเช่นนั้นเพราะลักษณะของคอมพิวเตอร์

• ประเภทที่ 1 ครอบคลุมสาขาอย่างความปลอดภัย การเงิน คณิตศาสตร์ เป็นต้น

• ประเภทที่ 2 มีโอกาสสูงที่จะถูก AI เข้ามาแทนที่

• ส่วนต่าง ๆ ของแอปพลิเคชันเดียวกันอาจเหมาะกับประเภทที่ 1 หรือ 2 ต่างกันไป

• ไม่นานมานี้ได้สร้างเกมเพื่อการศึกษาขึ้นในงานแฮกกาธอน

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

• LLM ไม่ควรถูกใช้เพื่ออิมพลีเมนต์ตรรกะ

  • ตรรกะ การทำ optimization และ constraint programming เป็นเทคนิคที่แยกจากกัน
  • ผู้ก่อตั้งตรรกศาสตร์สมัยใหม่คือ George Boole และเขาเป็นปู่ของ Geoffrey Everest Hinton

• การทำความเข้าใจความสามารถของ LLM เป็นเรื่องยาก

  • ผู้อ่านต้องการคำตอบที่เรียบง่าย
  • LLM อาจมีปัญหาในการเขียน state machine แบบง่าย
  • งานวิจัยกำลังได้รับความนิยม และแม้ถึงปี 2025 ก็คงยังไม่มีใครเข้าใจ LLM ได้อย่างสมบูรณ์

• หากต้องการให้การตอบสนองของ LLM เร็วและมีต้นทุนต่ำ ควรใช้พรอมป์ต์สั้นและโมเดลขนาดเล็ก

  • ข้อมูลจำนวนมากตั้งอยู่บนสมมติฐานว่าต้องใช้โมเดลขนาดใหญ่
  • UI แบบดั้งเดิมอาจเป็นทางเลือกที่ดีกว่า

• การทดสอบด้วย LLM เพียงอย่างเดียวทำได้ยาก

  • สไตล์ส่วนบุคคลส่งผลต่อปฏิสัมพันธ์
  • ค่าใช้จ่ายในการบำรุงรักษาอาจสูง
  • การแปลงเป็นการเรียกใช้ API อาจสมเหตุสมผลกว่า

• การใช้ LLM ใน business logic มีความเสี่ยง

  • เหมาะกับการประมวลผลภาษา

• สามารถใช้ภาพที่สร้างโดย AI เพื่อสรุปบทความได้