LLM หลงทางในการสนทนาแบบหลายเทิร์น

 (arxiv.org)
4 คะแนน โดย GN⁺ 2025-05-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โมเดลภาษาขนาดใหญ่ (LLM) แสดงให้เห็นถึง ประสิทธิภาพที่ลดลง และความน่าเชื่อถือที่ถดถอยในการสนทนาแบบหลายเทิร์น
  • เมื่อเทียบกับแบบเทิร์นเดียว มีการยืนยันจากการทดลองว่าในสถานการณ์ หลายเทิร์น ประสิทธิภาพลดลงเฉลี่ย 39%
  • ปัจจัยหลักคือ ความสามารถที่ลดลงเล็กน้อย และ ความน่าเชื่อถือที่ลดลงอย่างมาก หรือก็คือความสม่ำเสมอของผลลัพธ์ที่แย่ลง
  • LLM มีแนวโน้มจะตั้ง สมมติฐานที่ผิด ตั้งแต่ช่วงต้น หรือพยายามหาคำตอบสุดท้าย เร็วเกินไป
  • ผลคือเมื่อ LLM ทำพลาดในช่วงต้นของบทสนทนา จะเกิดอาการ กู้กลับไม่ได้และหลงทิศทางของการสนทนา

ABSTRACT

  • โมเดลภาษาขนาดใหญ่ (LLM) ในฐานะอินเทอร์เฟซแบบสนทนา มีศักยภาพที่จะช่วยให้ผู้ใช้ค่อย ๆ นิยาม สำรวจ และปรับแก้ความต้องการผ่าน การสนทนาแบบหลายเทิร์น ได้ แม้ผู้ใช้จะยังไม่สามารถระบุความต้องการได้ครบถ้วนตั้งแต่ต้น
  • อย่างไรก็ตาม แม้ว่าการประเมิน LLM ส่วนใหญ่จะมุ่งที่สภาพแวดล้อมแบบ คำสั่งสมบูรณ์ในเทิร์นเดียว แต่การวิเคราะห์บันทึกบทสนทนาจริงกลับพบปรากฏการณ์ คำสั่งที่ยังระบุไม่ครบถ้วน (underspecification) อยู่บ่อยครั้ง
  • งานวิจัยนี้เปรียบเทียบประสิทธิภาพของ LLM ในสภาพแวดล้อมแบบ เทิร์นเดียว และ หลายเทิร์น (underspecified) ผ่านการจำลองในวงกว้าง
  • ผลลัพธ์พบว่าใน LLM ชั้นนำ 15 รุ่น ทุกตัว ประสิทธิภาพในการสนทนาแบบหลายเทิร์นลดลงเฉลี่ย 39% ซึ่งวิเคราะห์ได้ว่าเกิดจาก ความสามารถที่ลดลงเล็กน้อย และ ความน่าเชื่อถือที่ลดลงอย่างรุนแรง
  • เมื่อต้นทางของบทสนทนา LLM เลือกเส้นทางผิด ก็พบปรากฏการณ์ว่า ไม่สามารถกู้กลับและหลงทางอยู่ในบทสนทนา ในเวลาต่อมา

Introduction

  • LLM รุ่นใหม่ ๆ (เช่น ChatGPT, Gemini, Claude เป็นต้น) เป็นอินเทอร์เฟซที่รองรับ การสนทนาแบบหลายเทิร์น
  • แม้ผู้ใช้จะไม่ได้อธิบายทุกความต้องการอย่างชัดเจนตั้งแต่แรก ก็สามารถค่อย ๆ ทำให้ข้อกำหนดชัดเจนขึ้นได้ผ่านการถามตอบซ้ำ ๆ (underspecified → refined)
  • ในความเป็นจริง ผู้ใช้จำนวนมากมักเริ่มบทสนทนาด้วยความต้องการที่ไม่ชัดเจน แต่ การประเมินส่วนใหญ่ยังดำเนินในสภาพแวดล้อมแบบคำสั่งสมบูรณ์เทิร์นเดียว เท่านั้น
  • งานก่อนหน้าบางส่วนพยายามประเมินแบบหลายเทิร์น แต่ก็มักปฏิบัติต่อแต่ละเทิร์นของบทสนทนาเป็นตอนแยกกัน จึงประเมินผลกระทบของ ความไม่ชัดเจน ที่พบได้ทั่วไปในบทสนทนาจริงของมนุษย์ต่ำเกินไป
  • เพื่อลดช่องว่างนี้ งานวิจัยจึงเสนอแนวทาง sharded simulation (แบ่งข้อมูลออกเป็นหลายชิ้นและเปิดเผยทีละชิ้นในแต่ละเทิร์น) เพื่อจำลองสถานการณ์คำสั่งไม่ชัดเจนแบบหลายเทิร์นอย่างละเอียด

สรุปผลการวิจัยสำคัญ

  • ในแบบเทิร์นเดียว LLM ทำได้ 90% เมื่อได้รับคำสั่งครบทั้งหมดในครั้งเดียว แต่ในสถานการณ์ คำสั่งไม่ชัดเจนแบบหลายเทิร์น ลดลงเหลือ 65% (ลดลงเฉลี่ย 25 จุด)
  • ปรากฏการณ์นี้เกิดขึ้นแม้ผ่านบทสนทนาเพียง สองเทิร์น และพบร่วมกันใน LLM ทุกประเภท ทั้งแบบเปิด แบบปิด ขนาดใหญ่ และขนาดเล็ก
  • การวิเคราะห์สาเหตุของ ประสิทธิภาพที่ลดลง พบสองปัจจัยคือ (1) ความสามารถที่ลดลง (aptitude loss) และ (2) ความไม่น่าเชื่อถือ (unreliability) ที่เพิ่มขึ้นอย่างมาก
    • ในแบบเทิร์นเดียว โมเดลที่มีความสามารถสูงมักมีความน่าเชื่อถือสูงด้วย แต่ในแบบหลายเทิร์น ความน่าเชื่อถือต่ำโดยแทบไม่ขึ้นกับระดับความสามารถ
    • กล่าวคือ เมื่อ LLM เข้าสู่ทิศทางที่ผิดระหว่างการสนทนาแบบหลายเทิร์น ก็จะ ไม่สามารถกู้กลับได้ — งานนี้เรียกปรากฏการณ์นี้ว่า “lost in conversation”
  • สาเหตุหลัก
    • การตอบยืดยาว และ การรีบพยายามให้คำตอบสุดท้าย
    • การตั้งสมมติฐานผิดจากข้อมูลที่ยังไม่ชัดเจน
    • การยึดติดกับความพยายามที่ผิดก่อนหน้าเกินไป
  • มี ช่องว่างขนาดใหญ่ ระหว่างการใช้งาน LLM จริงกับวิธีการประเมินโมเดล
    • ยิ่งเป็นผู้ใช้มือใหม่ ก็ยิ่งมีแนวโน้มให้คำสั่งที่ไม่สมบูรณ์ในช่วงต้น ซึ่งทำให้ปรากฏการณ์นี้เป็นหนึ่งในสาเหตุสำคัญที่ขัดขวางการนำไปใช้จริง
  • โครงสร้างของงานวิจัย: สรุปงานก่อนหน้า อธิบายสภาพแวดล้อมการจำลอง งานสร้าง 6 ประเภทและตัวชี้วัดการประเมิน การทดลองขนาดใหญ่กับ LLM 15 รุ่นและผลลัพธ์ ตลอดจนข้อคิดเชิงปฏิบัติ การประยุกต์ใช้กับผลิตภัณฑ์ และคำแนะนำที่เป็นรูปธรรม

Background and Related Work

  • โมเดลภาษาในยุคก่อนหน้า (เช่น BART, GPT-2, T5) ไม่สามารถรองรับการสนทนาแบบหลายเทิร์นได้จริง จึงถูกประเมินโดยเน้น เทิร์นเดียว
  • หลังการมาถึงของ ChatGPT ความสนใจต่อการประเมินแบบหลายเทิร์นเพิ่มสูงขึ้น และมีการประเมินแบบ crowdsourcing เช่น MT-bench
  • แต่ระบบประเมินส่วนใหญ่ยังคงเป็น บทสนทนาแบบเป็นตอน (ประเมินแต่ละเทิร์นแยกกัน) ทำให้ไม่คำนึงถึงความต่อเนื่องของบทสนทนาที่ไม่ชัดเจนในโลกจริง
  • ในความเป็นจริง มนุษย์มักสั่งงานอย่างไม่ชัดเจนตาม “หลักความพยายามต่ำสุด” (a.k.a. underspecification) และ LLM ก็มีประสิทธิภาพลดลงจากการ สรุปเร็วเกินไปเมื่อข้อมูลไม่พอ และ ปรับตัวได้ไม่ดี
  • งานวิจัยนี้จึงออกแบบมาเพื่อมุ่งสู่การประเมินที่ใกล้เคียงกับสภาพแวดล้อมจริง ซึ่งความไม่ชัดเจนเป็นหัวใจสำคัญ

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

  • แบ่ง คำสั่งที่ระบุครบถ้วนเดิม ออกเป็นหลาย shard (ชิ้นส่วนข้อมูล)
    • ตัวอย่าง: แทนที่จะใส่ทุกเงื่อนไขไว้ในประโยคเดียว ก็เปิดเผยข้อมูลทีละอย่างในแต่ละเทิร์น (ฉากบริบท ค่าตัวเลข เงื่อนไข ฯลฯ)
  • shard แรกจะอธิบาย เป้าหมายระดับสูงของคำสั่ง เสมอ จากนั้น shard ถัดไปจะค่อย ๆ ให้ข้อมูลเพิ่มเติม (บริบท เงื่อนไข ฯลฯ) ในแต่ละเทิร์น
  • กระบวนการ sharding นี้สร้างชุดข้อมูลคำสั่งแบบหลายเทิร์นคุณภาพสูงด้วยการให้ LLM (GPT-4o) เสนอ+ตรวจสอบ และมีการปรับแก้ด้วยมือเพิ่มเติม
  • สำหรับแต่ละงาน มีการสร้าง sharded instruction 90–120 ชุด (พร้อมการตรวจทานด้วยมือหลายชั่วโมง)

3.2 Simulating Sharded Conversations

  • การจำลองบทสนทนา ใช้บทบาท 3 ฝ่าย: LLM ที่เป็นเป้าประเมิน (assistant), user simulator ที่รู้ shard ทั้งหมด, และระบบจัดประเภท/ให้คะแนนคำตอบ
  • เทิร์นแรก: user simulator ส่งเฉพาะ shard แรกให้ assistant → assistant ตอบ → มีการจัดประเภทกลยุทธ์ของคำตอบนั้น (ขอความชัดเจน ตั้งคำถาม พยายามตอบเลย ฯลฯ) และดึงคำตอบออกมา → ประเมินความถูกต้องของคำตอบ
  • เทิร์นถัดไป: เปิดเผย shard ที่เหลือเพิ่มอีกเพียงหนึ่งชิ้นและทำซ้ำ / ในแต่ละเทิร์น assistant สามารถตอบได้อย่างอิสระ
  • จบบทสนทนา เมื่อ (1) ผู้ประเมินตัดสินได้ว่าคำตอบถูกต้องแล้ว หรือ (2) ไม่มี shard ให้เปิดเผยเพิ่มเติม
  • user simulator ถูกสร้างด้วย LLM (GPT-4o-mini) ทำให้สามารถให้ shard อย่างเป็นธรรมชาติและ rephrase อัตโนมัติได้
  • ตลอดการทดลองทั้งหมด ความผิดพลาดจาก LLM ผู้ช่วยประเมิน เช่น การจัดประเภทผิดหรือการดึงคำตอบผิด มีน้อยกว่า 5% และกรณีที่เสียเปรียบต่อ assistant มีน้อยกว่า 2%
  • assistant ถูกประเมินใน สถานะค่าเริ่มต้น โดยไม่ให้ข้อมูลพิเศษเกี่ยวกับสภาพแวดล้อมนี้ล่วงหน้า (ให้ใกล้เคียงการใช้งานจริง)

3.3 Simulation Types

  • FULLY-SPECIFIED (FULL): ให้คำสั่งทั้งหมดในเทิร์นเดียว ใช้เป็น baseline สำหรับประเมินประสิทธิภาพ
  • SHARDED: เปิดเผยข้อมูลเพียงหนึ่งชิ้นต่อเทิร์น เป็นการทดลองหลักของงานวิจัยเกี่ยวกับบทสนทนาแบบหลายเทิร์นที่คำสั่งไม่ชัดเจน
  • CONCAT: ให้ sharded instruction ทั้งหมดพร้อมกันในรูปแบบ bullet-point เพื่อวัดผลเฉพาะการสูญเสียจากรูปแบบข้อมูลคำสั่ง
  • RECAP: หลังบทสนทนาแบบ sharded จะสรุป/ให้ shard ทั้งหมดอีกครั้งในตอนท้าย เป็นรูปแบบหนึ่งของการแทรกแซงแบบ agent อย่างง่าย
  • SNOWBALL: ในแต่ละเทิร์นจะเพิ่ม shard ใหม่พร้อมทวน shard ที่เปิดเผยไปก่อนหน้าทั้งหมด เพื่อไม่ให้ assistant พลาดข้อมูล เป็นการทดลองเสริมความจำ

Task and Metric Selection

4.1 Task Selection

  • งานทั้งหมด 6 ประเภท: การเขียนโปรแกรม (Code), ฐานข้อมูล (สร้าง SQL), การเรียกใช้ฟังก์ชัน API (Actions), คณิตศาสตร์ (Math), ตาราง→ข้อความ (Data-to-Text), การสรุปแบบถามตอบ (Summary)
    • ตัวอย่าง: เขียนฟังก์ชัน Python, แปลงภาษาธรรมชาติเป็นคำสั่ง SQL เป็นต้น
  • สำหรับแต่ละงาน มีการคัดเลือกคำสั่ง 90–120 รายการจาก benchmark คุณภาพสูง แล้วทำ sharding และตรวจสอบด้วยมือ
  • ทั้ง 6 งานเป็นตัวแทนที่ครอบคลุมทั้งงานเขียนโปรแกรมและไม่ใช่การเขียนโปรแกรม รวมถึงสถานการณ์ที่หลากหลาย เช่น Summary ที่ต้องใช้ long context

4.2 Metric Selection

  • ตัวชี้วัดการประเมิน
    • ประสิทธิภาพเฉลี่ย (P): คะแนนเฉลี่ย (0~100) ที่ได้จากหลายการจำลอง
    • ความสามารถ (A90): ค่าผลลัพธ์ของการจำลองในกลุ่มบนสุด 10% (90th percentile, กรณีดีที่สุด)
    • ความน่าเชื่อถือ (U90_10): ส่วนต่างระหว่างคะแนนบนสุด 90% กับล่างสุด 10% (ใช้วัดความสม่ำเสมอ/ความผันผวนของผลลัพธ์)
  • ตัวอย่าง: ด้านบนสุดของ box-plot คือความสามารถ ส่วนช่วงบน-ล่างสะท้อนความน่าเชื่อถือ
  • ทั้ง 6 งานถูกรวมคะแนนด้วยมาตรวัดที่สอดคล้องกัน (ความถูกต้อง/ความคล้ายคลึง/BLEU ฯลฯ)
  • รายละเอียดวิธีการ โค้ด ตัวอย่าง และพารามิเตอร์การทดลองทั้งหมด รวมถึงการสุ่มตัวอย่าง ถูกใส่ไว้ในภาคผนวก/Appendix

Simulation Scale and Parameters

  • สร้าง instruction ทั้งหมด 600 รายการ ครอบคลุม 6 งาน และทดลองในสถานการณ์ FULL/CONCAT/SHARDED
  • สำหรับ LLM 15 รุ่น (GPT-4, Claude, Gemini เป็นต้น) ทำการจำลองแต่ละชุดผสม 10 ครั้ง สร้างข้อมูลการทดลอง มากกว่า 200,000 ครั้ง
  • การทดลองทั้งหมดดำเนินด้วย temperature 1 (sampling) และในการทดลองเพิ่มเติม (7.2) ยังวิเคราะห์ผลของ temperature ด้วย
  • ชุดข้อมูลการจำลองขนาดใหญ่นี้ช่วยให้สามารถระบุสาเหตุหลักและรูปแบบของ พฤติกรรมและประสิทธิภาพที่ลดลงของ LLM ในบทสนทนา underspecified แบบหลายเทิร์น ได้

Lost in Conversation Experiment

  • จากนั้นในเนื้อหาหลักของบทความจะอธิบายอย่างละเอียดตามลำดับ ได้แก่ การตั้งค่าการทดลอง ผลลัพธ์ของแต่ละโมเดล การวิเคราะห์สาเหตุของประสิทธิภาพที่ลดลง การทดลองเทคนิคเสริม (RECAP/SNOWBALL) ตลอดจนข้อคิดเชิงปฏิบัติและคำแนะนำอย่างเป็นรูปธรรม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-16
ความเห็นจาก Hacker News

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

    • ประสบการณ์ของผมก็คล้ายกับข้อสังเกตนี้ แต่ก็มีส่วนที่ต่างออกไปเล็กน้อย ผมใช้ Gemini ดีบักปัญหา IPSEC อยู่ 2 สัปดาห์ ตอนแรกให้มันอ่านเอกสาร IPSEC ของ OPNsense และ pfSense แล้วให้คอนเท็กซ์ภาพรวม จากนั้นก็แชร์ข้อมูลการตั้งค่าและคุยถามตอบต่อเนื่องกันไป ช่วงท้าย ๆ LLM เริ่มวอกแวกน้อยลง และบางครั้งผมก็โยนโพสต์จากฟอรัมหรือ SO เข้าไป แต่ LLM ก็ยังบอกได้ว่า “อันนี้ต่างจากอาการที่เรากำลังดูอยู่ตอนนี้” เราตัดทางตันทั้งหมดออกอย่างมีเหตุผล และแม้ LLM จะช่วยสะท้อนความคิดได้ แต่การตัดสินใจยังต้องเป็นของมนุษย์ สุดท้ายก็หาสาเหตุของปัญหาเจอ และอย่างที่ผู้ใช้อื่นพูดไว้ LLM เก่งเรื่องทำข้อมูลซับซ้อนให้เรียบง่าย แต่ไม่เก่งเรื่องขยายแนวคิดง่าย ๆ ให้ซับซ้อน ผมจะพอใจกับผลลัพธ์มากกว่าเมื่ออินพุตซับซ้อนหรือยาวกว่าผลลัพธ์ ทำได้โดยไม่ใช้ LLM ก็จริง แต่สิ่งที่มีประโยชน์คือมันช่วยเก็บสิ่งที่จำคอนเท็กซ์ไว้ไม่ได้หรือเอากลับมาใหม่ได้ไม่เร็วพอ นอกจากนี้ยังช่วยหาลักษณะเวลาในล็อกปริมาณมากได้ด้วย และยังช่วยปรับการตั้งค่าหลายอย่าง ไม่ได้มีประโยชน์แค่แก้ปัญหา แต่ยังได้เรียนรู้อีกมาก บางครั้งการประเมินสถานะก็ผิด แต่แก้ให้ตรงได้ไม่ยาก สรุปคือ ถ้ารู้เป้าหมายและใช้มันเป็นเครื่องมือก็มีประโยชน์ แต่ถ้ายกการตัดสินใจให้มันหรือปล่อยให้พาออกนอกทางก็ไม่ช่วยอะไร ใช้ไป 350,000 โทเค็น (ราว 300,000 คำ) มีบล็อกโพสต์ที่เกี่ยวข้องอยู่ ไม่ต้องแนะนำ wireguard
    • ตรงกับประสบการณ์ผมทุกอย่างเลย คำว่า “ปนเปื้อน” นี่ใช่มาก พอมีอะไรผิดพลาด คำตอบทั้งหมดหลังจากนั้นก็เริ่มแย่ลงเรื่อย ๆ นี่แหละเหตุผลที่ผมไม่ชอบฟีเจอร์ memory ของ ChatGPT ไม่ใช่ว่ามีปัญหาใหญ่โต แต่ผมกังวลเพราะไม่เข้าใจทั้งหมดว่าการปนเปื้อนของคอนเท็กซ์เกิดขึ้นอย่างไร
    • เคล็ดลับที่ดีที่สุดที่ผมบอกได้คือ ใช้ปุ่ม “แก้ไข” เล็ก ๆ ที่ซ่อนอยู่ของ ChatGPT และ Claude ให้เต็มที่ ถ้าได้คำตอบแย่ ๆ อย่าปล่อยผ่าน ให้หยุดแล้วแก้ไข เพื่อให้ได้คำตอบที่ดีกว่า ไม่อย่างนั้นความเละเทะจะเพิ่มพูนต่อไป
    • ผมอยาก fork บทสนทนาเพื่อทดลองหลายทิศทางอยู่เสมอ อยากป้องกันไม่ให้เส้นทางที่ดูมีอนาคตต้องเจอกับการปนเปื้อนแบบย้อนกลับไม่ได้ ตอนนี้ผมยังทำแบบนี้ใน ChatGPT ไม่ได้ เลยสงสัยว่ามีบริการไหนที่ให้ฟีเจอร์นี้บ้าง
    • ตัวอย่างที่น่าสนใจของปัญหานี้ก็คือพรอมป์ต์เริ่มต้น มันแทบจะเป็นคอนเท็กซ์ถาวรที่ถูกซ่อนไว้ บอท Grok บน Twitter ช่วงนี้ชอบพูดถึง “White Genocide” บ่อย ๆ ซึ่งเป็นเพราะมีคนไปเปลี่ยนพรอมป์ต์ให้สอดคล้องกับหัวข้อนั้น ถ้าเป็นแชตบอตที่สมบูรณ์แบบ มันไม่ควรถูกกระทบในหัวข้ออื่น แต่ในความจริงมันถูกกระทบ สุดท้ายคอนเท็กซ์ก็เปลี่ยน และมันก็หมกมุ่นกับหัวข้อนั้นไม่เลิก
    • นั่นแหละคือเหตุผลที่ผมสร้าง FileKitty ขึ้นมา เป็นเครื่องมือรวมไฟล์ซอร์สโค้ดหลายไฟล์เป็นรูปแบบ Markdown อย่างรวดเร็ว เวลาใช้ LLM ช่วยงานพัฒนาซอฟต์แวร์ ถ้าพึ่ง LLM ในการค้นหาโค้ดเบสมากเกินไป โอกาสผิดพลาดจะสูงขึ้น และผลลัพธ์ก็อาจเจือจางจากความสูญเสียในการบีบอัดคอนเท็กซ์ วิธีที่ได้ผลดีที่สุดคือทำให้คอนเท็กซ์เฉพาะชัดเจนตั้งแต่แรก แล้วคอยอัปเดตระหว่างบทสนทนา ถึงอย่างนั้นก็ยังต้องใส่ใจกับความยาวของบทสนทนาอยู่ดี ผมยังมีพรอมป์ต์ไว้จับคอนเท็กซ์ให้ดีแล้วส่งต่อไปยังเซสชันใหม่ด้วย บางครั้งก็เลือกไฟล์ที่จะรวมเข้าไปแล้วใส่ในพรอมป์ต์ใหม่ด้วย ดูการคุยที่เกี่ยวข้องได้ในเธรดอื่นของ HN
    • ตอนนี้รูปแบบนี้กลายเป็นส่วนหนึ่งของเวิร์กโฟลว์ผมไปแล้ว บางครั้งผมถาม LLM ว่า “กำลังไปได้ดี อยากไปขั้นต่อไปแล้ว แต่ควรทำต่อในบทสนทนานี้หรือควรเริ่มใหม่?” ถ้ามันบอกว่าควรเริ่มใหม่ มันก็จะช่วยเตรียมพรอมป์ต์สรุปที่ดีให้ แต่บางครั้งก็บอกว่าทำต่อได้ ผมมีโน้ตหลายอันชื่อประมาณว่า “ชุดค่าเริ่มต้นสำหรับสำรวจต่อ” ด้วย กระบวนการ post-training แบบอิง RL ฯลฯ ทำให้แชตบอตมีแนวโน้มจะพยายามคุยต่อไปเรื่อย ๆ ใน RL นั้น post-training ต่างจาก RL จริงตรงที่ใช้แค่กลไกอิง preference แบบครั้งเดียว ส่วน preference ระยะยาวหรือการสนทนานั้นความซับซ้อนเชิงคำนวณเพิ่มแบบทวีคูณ เลยยังมีงานวิจัยไม่มาก
    • ผมสงสัยว่ามีใครทำอินเทอร์เฟซสำหรับ “จัดระเบียบ” ประวัติการสนทนาหรือยัง ฟังก์ชันที่คอยเก็บกวาดทางตันหรือเนื้อหาที่ไม่เกี่ยวข้องออกจากบทสนทนา เก็บประวัติทั้งหมดไว้ แต่ตัดแต่ง/จัดระเบียบเฉพาะส่วนที่ไม่จำเป็นตามเส้นทางของหัวข้อ ไม่ใช่การสรุป แต่เป็นการจัดระเบียบแบบอินทรีย์มากกว่า
    • ผมใช้ LLM แค่ในบทบาท autocomplete แต่คิดว่าปัญหานี้แก้ได้ถ้าเพิ่มปุ่มหรือออปชัน “ลบข้อความ” ใน UI แชตของ LLM ถ้าลบข้อความล่าสุดของ LLM ก็สามารถขอคำตอบใหม่ได้ ซึ่งมีประโยชน์มากโดยเฉพาะกับ LLM ที่มีความสุ่มสูง (temperature) และถ้าลบข้อความอื่น ก็ควรอัปเดตคอนเท็กซ์เพื่อให้สะท้อนในคำตอบถัดไปด้วย วิธีนี้ยังช่วยแก้ความเข้าใจผิดของผู้ใช้ที่คิดว่า LLM ฉลาดกว่าความเป็นจริงด้วย ไม่แน่ใจว่านี่เป็นมาตรฐานอยู่แล้วหรือเปล่า ถ้ายัง ผมขอปล่อยไอเดียนี้เป็น public domain อีกทางหนึ่ง การมี “subcontext LLM” มาคอยจัดการคอนเท็กซ์หลักก็ดูใช้ได้จริง เช่น เมื่อคำตอบยาวหรือมหาศาลเกินไป ก็ให้ LLM ย่อยคอยสรุป/จัดระเบียบเพื่อเกลาคอนเท็กซ์ของบทสนทนาทั้งหมด หรือจะง่ายกว่านั้นคือมีปุ่ม “แก้ไขข้อความ” เพื่อให้คนจัดระเบียบเองก็ได้
    • พอคอนเท็กซ์ปนเปื้อนแล้ว การกู้คืนทำได้ยาก ถ้ามีวิธีรีเซ็ตหรือชำระล้างบางส่วนของ LLM เป็นระยะ ๆ ก็อาจช่วยได้ แต่โจทย์คือจะจัดการส่วนไหนโดยไม่ทำข้อมูลสำคัญหายไป การจัดการคอนเท็กซ์ที่ฉลาดขึ้นอาจช่วยรักษาความสอดคล้องของบทสนทนายาว ๆ ได้ แต่การหาสมดุลนั้นยาก บางทีเอเจนต์ตัวอื่นอาจช่วยทำให้เป็นอัตโนมัติได้
    • พรอมป์ต์แบบ chain-of-thought ใน AI chatbot ก็เริ่มแสดงข้อจำกัดด้วยเหตุผลเดียวกัน
    • เรื่องที่ว่า “การสนทนา” เป็นเพียงผลผลิตของอินเทอร์เฟซผลิตภัณฑ์เท่านั้น ผมมีความเห็นว่ากระแสนี้เปลี่ยนไปแล้วเพราะการฝึกด้วยชุดข้อมูลประเมินผลแบบ multi-turn ของ RL แม้หน้าต่างคอนเท็กซ์จะเป็นของใหม่ทุกครั้ง แต่มันมีแนวโน้มตีความแต่ละพรอมป์ต์ว่าเป็นส่วนหนึ่งของบทสนทนาที่ยาวขึ้นมากขึ้น แม้ตอนนี้ multi-turn post-training แบบสาธารณะยังไม่ขยายตัวมาก แต่ระยะยาวก็น่าจะถูกนำมาใช้เพื่อให้บรรลุเป้าหมายได้มากขึ้น
    • ตอนเขียนโค้ด ผมเองก็เริ่มแชตใหม่บ่อย ๆ โดยเอาโค้ดปัจจุบันมาอธิบายใหม่ แทนที่จะตะบี้ตะบันอยู่ในบทสนทนาเดียว ซึ่งหลายครั้งให้ผลดีกว่า ถ้าใช้คำสั่งแบบ manual เพื่อบอกให้โมเดลสรุปและลืมบางอย่างอย่างชัดเจน ก็น่าจะแก้ปัญหาได้บ้าง เรื่องนี้ก็สอดคล้องกับกลไกการทำงานของมนุษย์บางส่วนด้วย (working memory vs narrative/episodic memory)
    • หนึ่งในฟีเจอร์ของ ChatGPT ที่น่าหงุดหงิดที่สุดคือ “memory” เพราะการปนเปื้อนของบทสนทนาสามารถตามข้ามแชตไปได้
    • “ปนเปื้อน” เป็นคำที่ตรงมากจริง ๆ อยากให้มี “version control” ในบทสนทนา/API เพื่อจะได้ rollback กลับไปสถานะก่อนหน้า หรือ clone ไปเป็นบทสนทนาใหม่ ยิ่งสำคัญเข้าไปอีกเมื่อพิจารณาว่าแม้แต่การพิมพ์ผิดหรือการแก้ข้อความก็ยังสร้างอคติเล็ก ๆ ต่อคำตอบในภายหลังได้
    • ผมชอบ UX แชตของ zed มาก เพราะแก้ไขประวัติการสนทนาทั้งหมดได้เหมือนไฟล์ข้อความ ทำให้จัดระเบียบ ลบ หรือแก้ไขเติมเต็มส่วนที่ไม่ต้องการ แล้วคุยต่อด้วยคอนเท็กซ์ที่สะอาดและตรงประเด็นกว่ามาก นี่จึงเป็นเหตุผลที่ผมใช้ zed เป็นหนึ่งในอินเทอร์เฟซหลักสำหรับคุยกับ LLM แม้ในงานที่ไม่เกี่ยวกับการเขียนโปรแกรมด้วย
    • การปนเปื้อนยังเกิดจากคำถามหรือคำตอบที่หลุดประเด็น รวมถึงการ “เจือจาง” ซ้ำ ๆ ได้ด้วย แม้ตอนสร้างคอนเทนต์เองก็มักเจอว่าคำสั่งที่ตอนแรกชัดเจนค่อย ๆ พร่าเลือนไป
    • ผมพยายามเตือนตัวเองเสมอว่า “การสนทนาเป็นเพียงผลผลิตของอินเทอร์เฟซผลิตภัณฑ์” แต่เอาเข้าจริงก็ยาก เพราะมีเบาะแสเชิง “ภาษาพูดแบบสนทนา” มากมาย
    • ผมเสียใจที่เปิด memory ไว้ เพราะบทสนทนาถูกปนเปื้อนด้วยข้อมูลไร้สาระ
    • สิ่งที่น่าทึ่งคือโมเดลมักยึดติดกับสมมติฐานที่ผิดตั้งแต่เนิ่น ๆ มากแค่ไหน
    • พอคิดดูแล้ว คนเราก็เป็นแบบนี้กันบ่อยเหมือนกัน
    • ตอนนี้ ChatGPT เข้าถึงบทสนทนาเก่าได้ผ่าน “memory” แล้ว การปนเปื้อนจึงอาจกลายเป็นเรื่องถาวร พอมันจับไอเดียผิดอันหนึ่งได้ จากมุมมองผู้ใช้ ต่อให้ย้ำหลายครั้งว่าอย่าพูดถึงมันอีก มันก็ยังชอบยัดเรื่องนั้นกลับเข้ามาในคำตอบเรื่อย ๆ เคยมีกรณีที่มันเผลอพ่นพรอมป์ต์ภายในออกมาด้วย (“ผู้ใช้ไม่พอใจมาก ต้องเอา xyz ออก”) จนกลายเป็นสถานการณ์ตลกที่ยิ่งไปโฟกัสที่ xyz หนักกว่าเดิม

  • นี่เป็นผลจากแนวโน้มที่รู้กันดีของ LLM คือความมั่นใจเกินเหตุ การขาดความสามารถในการสะท้อนตนเอง และการไม่รู้ตัวว่าเมื่อใดควรขอข้อมูลเพิ่ม พอดูผลลัพธ์ของ reasoning model ก็จะเห็นว่าเวลาเจอความกำกวม LLM มักไม่ขอคำอธิบายเพิ่มเติม แต่จะเดาว่าผู้ใช้ต้องการสื่ออะไรซ้ำ ๆ สิ่งนี้ชี้ให้เห็นข้อจำกัดเชิงปฏิบัติของแนวคิดที่จะเอามาแทนโปรแกรมเมอร์มนุษย์ เพราะส่วนที่ยากจริง ๆ คือ “การโต้ตอบกับผู้มีส่วนได้ส่วนเสีย” เพื่อค่อย ๆ เปลี่ยนความต้องการที่กำกวมให้ชัดเจน

    • เรื่องความไม่สามารถสะท้อนตนเองนั้น LLM ไม่มีตัวตนที่แท้จริงอยู่แล้ว และผู้ใช้ก็เหมือนตกอยู่ใน “เรื่องเล่าเพื่อคงความเชื่อ” แบบหนึ่ง โดยหลักแล้วถ้าคุณป้อนข้อความในบทบาทผู้ใช้ของบทหนัง LLM ก็แค่ autocomplete เนื้อเรื่องที่ไม่สมบูรณ์ในบทบาทแชตบอตเท่านั้น ตัวอย่างเช่นการสัมภาษณ์กับ Draculabot ก็แค่เลียนแบบการสะท้อนตนเองแบบผิวเผินด้วยประโยคอย่าง “โหยหาเลือด” หรือ “กลายเป็นฝูงค้างคาว”
    • ผมผิดหวังเหมือนกันที่ LLM ขอคำชี้แจงเพิ่มเติมอย่างชัดเจนไม่ได้เมื่อเจอโจทย์ปลายเปิดที่ข้อมูลคลุมเครือ (โดยเฉพาะพวก paradox) ผมทดสอบกับ DeepSeek-R1 และ Claude-3.7-Sonnet และมีบล็อกทดลองเกี่ยวกับเรื่องนี้ด้วย
    • Gemini 2.5 Pro และ ChatGPT-o3 มักขอข้อมูลเพิ่มเติมก่อนลงมือทำงานอยู่บ่อย ๆ Gemini ยังชอบเสนอหลายตัวเลือกแล้วให้ผมเลือกด้วย
    • โปรแกรมเมอร์ตัวจริงใช้เวลาส่วนใหญ่ไปกับการทำความต้องการให้ชัดเจน LLM ยังมอง “การเดา” เป็นฟีเจอร์อย่างหนึ่งอยู่เลย
    • น่าแปลกที่เวลาทำงานกับนักพัฒนามือใหม่ก็คล้ายกัน พอมอบงานให้ หลายคนจะพุ่งตรงไปอย่างเดียว ตั้งสมมติฐานเอง ไม่ถามอะไรเลย แล้วสุดท้ายก็หลงเข้าไปในป่าลึกจนต้องส่งทีมกู้ภัยไปตามออกมา
    • ผมคิดว่าเรื่องนี้เปลี่ยนได้ค่อนข้างง่าย เหมือนกับที่พรอมป์ต์ chain of thought เปลี่ยนโทเค็นสุดท้ายเป็น “อืม” ได้ ถ้า LLM กำลังจะพูดทำนองว่า “น่าจะเป็น ~” ก็แค่เปลี่ยนโทเค็นให้เป็น “ผมจะขอคำอธิบายเพิ่มเติมก่อน”
    • การขอข้อมูลเพิ่มหรือการสะท้อนตนเอง ถ้าสั่งให้ทำ มันก็ทำได้ดีพอสมควรอยู่แล้ว

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

    • Cursor เคยพยายามทำสิ่งนี้อัตโนมัติ แต่ถ้าไม่ได้ใช้โมเดลคอนเท็กซ์ขนาดใหญ่ เนื้อหาที่สรุปออกมาจะตกหล่นรายละเอียดมากเกินไป เลยไม่ค่อยเวิร์กในทางปฏิบัติ
    • Claude Code มีคำสั่ง /compact สำหรับสรุปบทสนทนาเพื่อลดการใช้โทเค็น

  • ผมคิดค้น TSCE (Two-Step Contextual Enrichment) ขึ้นมาเอง พอใช้กับงาน 300 ชุดบน GPT-35-turbo ประสิทธิภาพดีขึ้น +30pp และเปิดเป็นเฟรมเวิร์กให้ใช้ได้อย่างอิสระ ผมยังทดลองเพิ่มอีก 300 รอบกับ gpt-4.1 ด้วย baseline ล้มเหลวในการลบ em-dash 149/300 ครั้ง ส่วน TSCE ล้มเหลว 18/300 ครั้ง และผมก็เปิดข้อมูลทั้งหมดกับสคริปต์ไว้ด้วย

    • เสียพลังงานระดับกิโลวัตต์ชั่วโมงไปกับงาน find and replace ง่าย ๆ แบบนี้ แค่ใช้ text.replace("—", "-") ไม่ได้เหรอ
    • แค่เปลี่ยน baseline prompt นิดหน่อยก็ทำให้ GPT-4.1 สำเร็จ 100% ได้แล้ว โดยไม่ต้องเรียกเพิ่ม ไม่ต้องใช้โทเค็นเพิ่ม และไม่ต้องใช้เทคนิคซับซ้อนอะไรเลย

  • ผมเคยแก้ปัญหาด้วยสองระบบ (LMM + curator อัตโนมัติ) ระบบหนึ่งคือ LLM เอง อีกระบบเป็น “ภัณฑารักษ์ของความคิด” ที่คอยสลับจัดการบางส่วนของคอนเท็กซ์อย่างยืดหยุ่น อาศัยความสามารถของ LLM ในการเติมช่องว่างมากกว่าจะพึ่งกฎที่ชัดเจน มันช่วยให้จัดการปัญหาโดยแบ่งเป็นชิ้นเล็ก ๆ แล้วค่อยรวมผลเพื่อไปสู่เป้าหมายสุดท้าย

    • เป็นไอเดียที่เจ๋งมาก สิ่งที่คุณทำตอนนี้ดูคล้าย conversational RAG ผมคิดว่าอนาคตการแยกชั้นของ memory (ข้อมูลฝึก / คอนเท็กซ์ปัจจุบัน / RAG) จะชัดเจนขึ้น
    • คิดว่าเป็นแนวคิดที่น่าสนใจ ถ้าแบ่งปันให้โลกเห็นแม้แบบเรียบง่าย หลายคนก็คงช่วยกันปรับปรุงจนชุมชนต่อยอดได้เอง
    • ฟังดูคล้ายระบบวิจารณ์ภายในที่พูดถึงใน Emotion Machine
    • อยากรู้ข้อมูลเพิ่มเติมเกี่ยวกับโปรเจกต์ที่คุณกำลังสร้าง ดูน่าสนใจมาก
    • สรุปแล้วก็เหมือน Map-Reduce-of-Thought

  • ผมแปลกใจที่การแตกกิ่ง/ฟอร์กยังไม่ใช่เรื่องพื้นฐานในเครื่องมือแชตหลัก ๆ แม้จะแก้ไขคำตอบได้ แต่ก็ทำให้คอนเท็กซ์อื่น ๆ หายไปเยอะ เวิร์กโฟลว์ของผมคือ 1. วางแผน 2. สร้าง 3. แตกกิ่ง 4. ทำซ้ำ ผมคิดว่าการตัดแต่ง/แตกกิ่งพรอมป์ต์ควรเป็นเครื่องมือหลักของการใช้ LLM

    • อย่างน้อย Google AI Studio ก็มีฟีเจอร์นี้ แต่การทำออกมายังค่อนข้างชวนสับสน ซึ่งอาจเป็นเหตุผลว่าทำไมมันยังไม่แพร่หลายกว่านี้
    • ผมอยากสร้างอะไรแบบนี้เองมานานแล้ว BetterChatGPT อย่างน้อยก็มี UI ลบประวัติที่ดี แต่ผมก็เห็นด้วยว่าการแตกกิ่งคือก้าวต่อไป

  • ปัญหาเกิดขึ้นเมื่ออินเทอร์เฟซของ LLM ถูกออกแบบโดยยึดการสนทนาแบบเทิร์นเดียวเป็นศูนย์กลาง ผู้ใช้ส่วนใหญ่คาดหวังบทสนทนาเชิงเส้น ผมเลยสร้าง Telegram bot ชื่อ experai_bot ให้เป็น universal UI สำหรับ LLM และใช้แนวคิด “ถ้าไม่ใช่ reply ก็เป็นบทสนทนาใหม่” ถ้าจะเก็บคอนเท็กซ์ไว้ จำเป็นต้องต่อกันเป็นโครงสร้างต้นไม้ของ reply ผู้ใช้ที่ไม่เชี่ยวชาญมักเข้าใจวิธีนี้ได้ยาก อีกอย่าง โมเดลของ OpenAI (อย่างน้อย 3.5 และ 4o) ยิ่งถามคำถามเดิมซ้ำหลายครั้ง ช่องว่างหรือทางเลือกที่ได้จะยิ่งสั้นลง และผลลัพธ์จะยิ่งไม่แม่นยำ ต้องทำ system message ให้น้อยที่สุดถึงจะคงคุณภาพได้พอสมควร ถ้าจำเป็นก็มีตัวเลือกให้เพิ่ม system message ได้

  • เหตุผลหลักที่ผมสร้าง promptdown ก็เพื่อให้แก้ไขประวัติแชตทั้งหมดได้เต็มรูปแบบในแต่ละเทิร์น โครงสร้างแบบ append-only ของอินเทอร์เฟซมาตรฐานทำให้เรื่องนี้ยากมาก

  • ตอนนี้วงการ LLM ให้ความรู้สึกเหมือนทุกคนกำลังแก้ปัญหาเดิมซ้ำไปซ้ำมา

    • เหมือน LLM ในบทสนทนาแบบ multi-turn ที่ทุกคนกำลังวนแก้ปัญหาเดิมอยู่
    • มันไม่ใช่ “การเรียนรู้” แต่เป็นการ “ต้อนแมว” ซึ่งก็เหมาะกับบางเวิร์กโฟลว์
    • ทุกคนอยากอวดฝีมือ prompt engineering ของตัวเอง

  • LLM เหมือนยักษ์ในตะเกียงจริง ๆ มันจะตอบคำถามให้คุณได้สามครั้ง แต่หลังจากนั้นจะเริ่มพูดอะไรหลุดโลกไปหมด