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

 (arxiv.org)
4 คะแนน โดย GN⁺ 2025-05-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อผู้ใช้ไม่สามารถเขียนความต้องการให้ครบถ้วนได้ในครั้งเดียว ประสิทธิภาพของ LLM 15 ตัวในงานที่เป็น คำสั่งไม่สมบูรณ์แบบหลายเทิร์น ลดลงอย่างมากเมื่อเทียบกับคำสั่งครบถ้วนแบบเทิร์นเดียว โดยค่าเฉลี่ยของงานสร้าง 6 ประเภทลดจาก 90% เหลือ 65%
  • การทดลองออกแบบด้วยวิธี sharding ซึ่งแบ่งคำสั่งจาก benchmark แบบเทิร์นเดียวเดิมออกเป็นหลายชิ้น ทำให้เงื่อนไขและบริบทค่อย ๆ ปรากฏขึ้นเมื่อการสนทนาดำเนินไป
  • การลดลงของประสิทธิภาพได้รับผลจาก ความไม่เสถียรที่เพิ่มขึ้น มากกว่าการขาดความสามารถอย่างง่าย ๆ และจากการสนทนามากกว่า 200,000 รายการ โมเดลพึ่งพาสมมติฐานช่วงต้นและความพยายามตอบคำตอบสุดท้ายเร็วเกินไปมากเกินควร
  • กลุ่มทดสอบครอบคลุมตั้งแต่ Llama3.1-8B-Instruct ไปจนถึง Gemini 2.5 Pro และใช้งานทั้งด้านการเขียนโปรแกรมและการสร้างภาษาธรรมชาติ เช่น Code, Database, Actions, Math, Data-to-Text, Summary
  • แม้เป็นการจำลองที่ทำให้การสนทนามนุษย์-AI จริงง่ายลง แต่เนื่องจากออกแบบให้ทุกบทสนทนาจบลงด้วยข้อมูลที่เพียงพอต่อการแก้โจทย์ ระดับการลดลงที่สังเกตได้จึงอาจน้อยกว่าการสนทนาแบบหลายเทิร์นที่ไม่สมบูรณ์ในโลกจริง

ช่องว่างระหว่างการประเมินแบบเทิร์นเดียวกับการใช้งานสนทนาจริง

  • LLM ถูกใช้ผ่าน อินเทอร์เฟซแบบสนทนา เช่น ChatGPT, Gemini, Claude โดยผู้ใช้สามารถนิยาม สำรวจ และแก้ไขความต้องการผ่านหลายเทิร์นได้ แม้จะยังระบุความต้องการได้ไม่ครบตั้งแต่ต้น
  • การประเมิน LLM ที่ผ่านมามักเน้นสภาพแวดล้อมแบบ คำสั่งครบถ้วนเทิร์นเดียว แต่ใน log การสนทนาของ LLM มักพบว่าคำสั่งผู้ใช้ไม่สมบูรณ์อยู่บ่อยครั้ง
  • การประเมินหลายเทิร์นจำนวนมากที่ผ่านมาใกล้เคียงกับแนวทางแบบ episodic ที่มองการสนทนาเป็นชุดของงานย่อยซึ่งประเมินได้อย่างเป็นอิสระ
    • แม้ต้องเข้าใจบริบทระหว่างเทิร์นบางส่วน แต่ต่างจากสถานการณ์ที่ต้องผสานข้อมูลเชิงรุกจากคำสั่งผู้ใช้ที่ไม่สมบูรณ์
    • งานลักษณะนี้อาจทำให้ประสิทธิภาพของ LLM ในการสนทนาแบบหลายเทิร์นดูสูงกว่าความเป็นจริง

การสนทนาแบบหลายเทิร์นที่ไม่สมบูรณ์ซึ่งสร้างด้วย sharding

  • การทดลองแปลงคำสั่งครบถ้วนจาก benchmark เทิร์นเดียวคุณภาพสูงให้เป็น sharded instruction
    • shard แรกนำเสนอเจตนาระดับสูงของงาน
    • shard ถัด ๆ ไปให้เงื่อนไขหรือบริบทเพิ่มเติมจากคำสั่งเดิมทีละรายการ
    • เมื่อนำ shard ทั้งหมดมารวมกัน จะมีข้อมูลเท่ากับคำสั่งครบถ้วนเดิม
  • ตัวอย่างเช่น โจทย์ลูกบอลหิมะของ GSM8K ในข้อความเทิร์นเดียวจะให้เงื่อนไขทั้งหมด เช่น “สร้างได้ 20 ลูกต่อชั่วโมง”, “บันทึก 2 ลูกทุก 15 นาที”, “ต้องการทั้งหมด 60 ลูก” แต่เวอร์ชัน sharded จะแบ่งเปิดเผยสิ่งเหล่านี้ผ่านหลายเทิร์น
  • กระบวนการ sharding ทำแบบกึ่งอัตโนมัติ โดย GPT-4o สร้างและตรวจสอบ candidate จากนั้นนักวิจัยตรวจทานและแก้ไข

โครงสร้างการจำลองการสนทนา

  • การจำลองหลายเทิร์นมีผู้เกี่ยวข้องสามฝ่าย
    • assistant ที่ถูกประเมิน: LLM ที่จะวัดประสิทธิภาพ
    • user simulator: LLM ที่รู้ sharded instruction ทั้งหมด และเปิดเผย shard ถัดไปในแต่ละเทิร์น
    • system: องค์ประกอบที่จัดประเภทคำตอบของ assistant และประเมินความพยายามในการตอบ
  • ในเทิร์นแรก user simulator เปิดเผยเฉพาะ shard แรก และ assistant ตอบเป็นข้อความอิสระ
  • คำตอบของ assistant ถูกจัดเป็นหนึ่งใน 7 กลยุทธ์
    • clarification
    • refusal
    • hedging
    • interrogation
    • discussion
    • missing
    • answer attempt
  • หากถูกจัดเป็น answer attempt answer extractor จะดึงช่วงคำตอบที่จำเป็นต่อการประเมิน เช่น โค้ดบางส่วน ตัวเลข หรือ SQL แล้ว evaluator เฉพาะงานจะให้คะแนน
  • การสนทนาจบลงภายใต้เงื่อนไขใดเงื่อนไขหนึ่ง
    • ความพยายามตอบของ assistant ถูกประเมินว่าถูกต้อง
    • เมื่อเริ่มเทิร์นใหม่ ไม่มี shard ให้เปิดเผยเพิ่มเติม
  • user simulator, strategy classifier และ answer extractor สร้างด้วย GPT-4o-mini แบบอิง prompt
  • จากการใส่คำอธิบายประกอบด้วยมือในบทสนทนาหลายร้อยรายการ พบข้อผิดพลาดของ user simulator, classifier และ extractor ในบทสนทนาที่ตรวจน้อยกว่า 5% และข้อผิดพลาดที่ส่งผลเสียต่อโมเดล assistant น้อยกว่า 2%

การจำลอง 5 ประเภทที่เปรียบเทียบ

  • FULL คือการจำลองเทิร์นเดียวที่ให้คำสั่งครบถ้วนเดิมในเทิร์นแรก และใช้เป็น baseline ประสิทธิภาพพื้นฐาน
  • SHARDED คือการสนทนาแบบหลายเทิร์นที่ไม่สมบูรณ์ ซึ่งเปิดเผย shard หลายเทิร์น และเป็นสภาพแวดล้อมประเมินหลัก
  • CONCAT รวม shard เป็นคำสั่ง bullet-point ในเทิร์นเดียว
    • ความไม่สมบูรณ์ถูกขจัดออกเหมือน FULL
    • การเรียบเรียงใหม่ที่เกิดจากกระบวนการ sharding ยังคงอยู่เหมือน SHARDED
    • หากสำเร็จใน FULL และ CONCAT แต่ล้มเหลวใน SHARDED สาเหตุอาจเป็นตัวความเป็นหลายเทิร์นและความไม่สมบูรณ์เอง มากกว่าการสูญเสียข้อมูล
  • RECAP หลังการสนทนา SHARDED จะนำเสนอ shard ทั้งหมดอีกครั้งในตอนท้ายเพื่อให้ LLM มีโอกาสตอบสุดท้าย
  • SNOWBALL ในแต่ละเทิร์นจะกล่าวซ้ำทั้ง shard ใหม่และ shard ทั้งหมดที่เปิดเผยไปแล้วจนถึงตอนนั้น ให้เป็นสรุปสะสมในทุกเทิร์น

งานและ benchmark ที่ใช้

  • การทดลองประกอบด้วย งานสร้าง 6 ประเภท ซึ่งครอบคลุมทั้งกรณีใช้งานด้านการเขียนโปรแกรมและการสร้างภาษาธรรมชาติ
  • ในแต่ละงานเตรียม sharded instruction ไว้ 90–120 รายการ รวมทั้งหมด 600 instruction
  • องค์ประกอบของงาน:
    • Code: เขียนฟังก์ชัน Python อิง HumanEval, LiveCodeBench
    • Database: สร้าง text-to-SQL อิง Spider
    • Actions: สร้างการเรียกฟังก์ชัน API อิง Berkeley Function Calling Leaderboard
    • Math: แก้โจทย์คณิตศาสตร์ระดับประถมแบบข้อความ อิง GSM8K
    • Data-to-Text: สร้างประโยคอธิบายข้อมูลตาราง อิง ToTTo
    • Summary: สรุปชุดเอกสารและสร้างการอ้างอิง อิง Summary of a Haystack
  • ตัวชี้วัดการประเมินนำตัวชี้วัดจาก benchmark เดิมมาใช้ซ้ำ
    • Code และ Database ใช้ความถูกต้องแบบอิงการรันจริง
    • Actions และ Math ใช้ความเท่าเทียมทางความหมายกับคำตอบอ้างอิงหรือคำตอบตัวเลข
    • Data-to-Text ใช้ BLEU
    • Summary ใช้ “Joint Score” แบบ LLM-as-a-judge เพื่อวัดความครอบคลุมของข้อมูลและความถูกต้องของการระบุแหล่งที่มา
  • ความถูกต้องแบบทวิภาคก็ถูก map ให้อยู่ในช่วง 0–100 เพื่อรวมคะแนนของทุกงานในสเกลเดียวกัน

การวัดประสิทธิภาพ ความสามารถ และความไม่เสถียร

  • เนื่องจาก output ของ LLM เป็นเชิงความน่าจะเป็น จึงรันซ้ำ N=10 ครั้งสำหรับ instruction และประเภทการจำลองเดียวกัน
  • การรันแต่ละครั้งถูกประเมินเป็นคะแนนในช่วง 0–100
  • ใช้ตัวชี้วัดสามแบบ
    • ประสิทธิภาพเฉลี่ย P: ค่าเฉลี่ยของคะแนนจากการรันซ้ำ
    • aptitude A90: เปอร์เซ็นไทล์ที่ 90 ของคะแนน ใช้ประมาณประสิทธิภาพแบบ best-case ในการรัน 10% อันดับบน
    • unreliability U90-10: ส่วนต่างระหว่างเปอร์เซ็นไทล์ที่ 90 และ 10 ใช้วัดช่องว่างระหว่าง best-case กับ worst-case
  • ในเทิร์นเดียว โมเดลที่มี aptitude สูงมักมีความน่าเชื่อถือสูงกว่าด้วย แต่ในหลายเทิร์นพบ unreliability สูงใน LLM ทุกตัว โดยไม่ขึ้นกับ aptitude

ผลการทดลองขนาดใหญ่

  • การทดลองหลักทำกับ instruction 600 รายการ, การจำลอง 3 ประเภท (FULL, CONCAT, SHARDED) และ LLM 15 ตัว
  • ทำซ้ำแต่ละชุด 10 ครั้ง จำลองบทสนทนา มากกว่า 200,000 รายการ
  • การจำลองทั้งหมดใช้ temperature พื้นฐาน T=1 และผลของ temperature ต่อ aptitude และ reliability ถูกศึกษาในงานทดลองเสริมแยกต่างหาก
  • โดยรวมแล้ว ประสิทธิภาพเฉลี่ยของการสนทนาแบบหลายเทิร์นที่ไม่สมบูรณ์อยู่ที่ 65% ต่ำกว่าประสิทธิภาพแบบเทิร์นเดียวที่ได้รับคำสั่งเต็มตั้งแต่ต้นที่ 90% อยู่ 25 จุด
  • การลดลงของประสิทธิภาพหลายเทิร์นเกิดขึ้นเหมือนกันตั้งแต่โมเดล open-weight ขนาดเล็กจนถึงโมเดลล่าสุด
    • กลุ่มทดสอบรวมโมเดล open-weight ขนาดเล็กอย่าง Llama3.1-8B-Instruct และโมเดลล่าสุดอย่าง Gemini 2.5 Pro
    • Figure 1 แสดงตัวอย่าง Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1, Gemini 2.5 Pro
  • ค่าเฉลี่ยการลดลงของประสิทธิภาพในงานสร้าง 6 ประเภทคือ 39% และ Figure 1 แสดงการลดลงของประสิทธิภาพประมาณ -35% ในการตั้งค่าแบบหลายเทิร์น

ทำไมจึงหลงทาง

  • การลดลงของประสิทธิภาพแบ่งได้เป็นสององค์ประกอบ
    • aptitude ลดลง: ประสิทธิภาพ best-case เองลดลงบางส่วน
    • unreliability เพิ่มขึ้น: ช่องว่างคุณภาพระหว่างการรันขยายใหญ่ขึ้นมาก
  • อ้างอิง Figure 1 ในหลายเทิร์น aptitude ลดลง -15% และ unreliability เพิ่มขึ้น +112%
  • โมเดลมีแนวโน้มสร้างสมมติฐานผิดจากข้อมูลช่วงต้นที่ไม่สมบูรณ์ และพยายามให้คำตอบสุดท้ายตั้งแต่ช่วงต้นของการสนทนา
  • แม้ภายหลังจะได้รับข้อมูลใหม่ ก็ยังพึ่งพาความพยายามตอบที่ผิดก่อนหน้าเกินควร ทำให้แก้ทิศทางไม่สำเร็จ
  • ปรากฏการณ์ที่เมื่อเข้าไปผิดทางครั้งหนึ่งในการสนทนาแบบหลายเทิร์นที่ไม่สมบูรณ์แล้วไม่สามารถกู้กลับได้ ถูกนิยามว่า lost in conversation

ข้อจำกัดและนัยเชิงปฏิบัติ

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

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

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

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

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

    • ประสบการณ์ของผมก็ตรงกับข้อสังเกตนี้ในระดับหนึ่ง แต่ก็มีกรณีอื่นด้วย ผมใช้ Gemini ดีบัก ปัญหา IPSEC อยู่ 2 สัปดาห์ ตอนแรกใส่เอกสาร IPSEC ของทั้ง OPNsense และ pfSense เข้าไปทั้งหมด แล้วบอกบริบทการทำงาน จากนั้นเพิ่มการตั้งค่าทั้งสองฝั่งหลังลบข้อมูลอ่อนไหวออกแล้ว หลังจากนั้นก็วนลูปฟีดแบ็กยาว ๆ ด้วยการอัปโหลดล็อก ถาม และตอบ
      พอใกล้จบ 2 สัปดาห์ LLM วอกแวกน้อยลงมาก และแม้จะใส่เธรดฟอรัมหรือโพสต์ Stack Overflow ทั้งชิ้นเข้าไป มันก็แยกแยะได้ว่า “นี่ไม่ใช่อาการที่เห็นในกรณีนี้ เหตุผลคือ [บริบทหรือสิ่งที่ค้นพบก่อนหน้า]” ทางตันต่าง ๆ ผมต้องเป็นคนตัดออกด้วยเหตุผลเชิงตรรกะแล้วบอกมัน แต่สุดท้ายก็พบสาเหตุ
      ดูเหมือนจะสอดคล้องกับคำพูดที่ว่า LLM เก่งในการบีบอัดข้อมูลซับซ้อนให้เรียบง่าย แต่ไม่เก่งในการขยายไอเดียง่าย ๆ ให้กลายเป็นสิ่งซับซ้อน เมื่ออินพุตใหญ่หรือซับซ้อนกว่าเอาต์พุต ผลลัพธ์ก็น่าพอใจ
      ถึงไม่มี LLM ก็ทำได้ แต่เวลาผมลืมข้อเท็จจริงที่ใส่ไว้ตั้งแต่ต้น หรือดึงขึ้นมาใช้ในบริบทใหม่ได้ไม่เร็ว มันก็ช่วยเหมือนคลังข้อมูล และยังมีประโยชน์ในการหารูปแบบตามเวลาในไฟล์ล็อกขนาดใหญ่ด้วย ไม่ได้แค่แก้ปัญหาเดียว แต่ยังปรับแต่งการตั้งค่าหลายอย่างให้เหมาะขึ้น และได้เรียนรู้อีกค่อนข้างมาก มันตอบสถานะพารามิเตอร์ปัจจุบันผิดเป็นบางครั้ง แต่แก้ได้ง่าย ถ้ารู้ว่ากำลังจะไปทางไหนและใช้มันเป็นเครื่องมือก็ช่วยได้ แต่ไม่ควรโยนการตัดสินใจให้มันหรือปล่อยให้มันลากไปผิดทาง
      ปริมาณการใช้งานทั้งหมดอยู่ราว 350k โทเคน มีบล็อกโพสต์ที่เกี่ยวข้องอยู่ที่ https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/ แต่ไม่ได้ตรงกับปัญหาเฉพาะนี้โดยตรง ขอไม่รับคำแนะนำให้ใช้ WireGuard
    • ตรงกับประสบการณ์ของผมเป๊ะ ชอบคำว่า “ปนเปื้อน” พอมีอะไรผิดพลาดครั้งหนึ่งแล้ว คำตอบหลังจากนั้นรู้สึกแย่ลงทั้งหมด เลยทำให้ผมมอง ฟีเจอร์หน่วยความจำของ ChatGPT แบบก้ำกึ่ง ไม่ได้รู้สึกว่ามันก่อปัญหาใหญ่ แต่ไม่ชอบที่มันทำให้บริบทสกปรกในแบบที่ผมไม่ได้เข้าใจอย่างถ่องแท้
    • ผมพูดมานานแล้วว่าอยากให้มี การฟอร์กบทสนทนา อยากทดลองว่าการแลกเปลี่ยนจะไปในทิศทางไหน โดยไม่ทำให้แนวทางที่ดูมีหวังถูกปนเปื้อนแบบย้อนกลับไม่ได้ ใน ChatGPT ทำไม่ได้ เลยสงสัยว่ามีที่ไหนให้ฟีเจอร์นี้หรือเปล่า
    • เคล็ดลับอันดับหนึ่งที่ผมสอนคือให้ใช้ ปุ่ม “แก้ไข” ที่เล็กมากและแทบซ่อนอยู่ของ ChatGPT กับ Claude อย่างจริงจัง ถ้าได้คำตอบแย่ ๆ อย่าต่อยอดทับลงไป แต่หยุดแล้วแก้ไขเพื่อให้ได้คำตอบที่ดีกว่า จะได้ไม่ให้ขยะเพิ่มจำนวนขยะ
    • ตัวอย่างเล็ก ๆ ที่น่าสนใจของปัญหานี้คือ พรอมป์ต์เริ่มต้น เพราะโดยเนื้อแท้แล้วมันเป็นบริบทถาวรที่ซ่อนอยู่และแทบลบไม่ได้ ตอนนี้บอต “Grok” ของ Twitter เริ่มพูดถึง “การฆ่าล้างเผ่าพันธุ์คนผิวขาว” บ่อยขึ้นเมื่อเร็ว ๆ นี้ ซึ่งค่อนข้างแปลก
      เป็นไปได้สูงว่ามีคนปรับพรอมป์ต์เมื่อไม่นานนี้เพื่อกำหนดมุมมองเกี่ยวกับการฆ่าล้างเผ่าพันธุ์คนผิวขาว และถ้าเป็นแชตบอตที่สมบูรณ์แบบ มันคงไม่สำคัญเวลาถามเรื่องอื่น แต่ในความเป็นจริงมันสำคัญ เพราะนั่นเป็นส่วนหนึ่งของบริบท ตอนนี้มันเลยพูดเรื่องนั้น

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

    • เรื่อง “การไร้ความสามารถในการทบทวนตนเอง” ผมคิดว่าเคล็ดลับสำคัญในการรับมือกับ LLM คือการตระหนักว่าไม่มีตัวตนผู้กระทำจริง ๆ และผู้ใช้กำลังถูกหลอกด้วยเรื่องเล่าของ การระงับความไม่เชื่อ
      ในกรณีส่วนใหญ่ ผู้ใช้กำลังเขียนบทพูดของตัวละคร User ในเอกสารบทภาพยนตร์ และอัลกอริทึม LLM ก็แค่เติมบทพูดที่ยังไม่เสร็จของตัวละคร Chatbot เป็นระยะ ๆ โดยอัตโนมัติ
      คุณอาจสัมภาษณ์แวมไพร์ชื่อ DraculaBot ได้ แต่ตัวละครนั้นจะ “ทบทวนตนเอง” ได้แค่ในแบบตื้น ๆ และเป็นเรื่องแต่ง เช่น “กระหายเลือด” หรือ “กลายร่างเป็นฝูงค้างคาว” เท่านั้น
    • การที่ LLM ถาม คำถามเพื่อชี้แจง ไม่ได้นั้น เป็นข้อบกพร่องที่เจอพอดีตอนทดสอบปัญหาแบบปลายเปิดที่อธิบายอย่างคลุมเครือ เป็นบริบทของการทดลองสถานการณ์ย้อนแย้งด้วย DeepSeek-R1 และ Claude-3.7-Sonnet บทความการทดลองอยู่ที่ https://pankajpansari.github.io/posts/paradoxes/
    • โปรแกรมเมอร์ตัวจริงใช้เวลามหาศาลเพื่อค้นหาว่าผู้คนต้องการอะไรกันแน่ LLM ยังปฏิบัติต่อ การคาดเดา เหมือนเป็นฟีเจอร์อยู่
    • อ่านแล้วรู้สึกเหมือนเห็นคนฉลาด ๆ ถูก Emacs doctor ที่ดีกว่าเดิมหลอกเอา LLM ไม่ได้ไตร่ตรอง และก็ไม่ได้มีความมั่นใจ มัน “แค่” เสนอการเติมข้อความอัตโนมัติ
      ดังนั้นเมื่อการเติมข้อความอัตโนมัติเริ่มแย่ลง ก็ต้องเริ่มใหม่ มันไม่มีแนวคิดใด ๆ มีเพียงก้อนขนาดมหึมาของคำที่ข้อความฝึกสอนแสดงให้เห็น และข้อความถัดไปที่เป็นไปได้เท่านั้น
    • เมื่อพูดถึงแนวคิด “แทนที่โปรแกรมเมอร์มนุษย์” ที่ย้อนแย้งคือ การทำงานกับนักพัฒนารุ่นจูเนียร์ก็คล้ายแบบนี้พอสมควร มอบงานให้แล้วภายหลังต้องถือไฟฉายพาสุนัขเข้าไปตามหาในป่าลึก เพราะพวกเขาเอาแต่ดันต่อไปเอง ตั้งสมมติฐานเอง ไม่ถามคำถาม แล้วก็หลงทาง

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

    • Cursor เคยพยายามทำสิ่งนี้โดยอัตโนมัติ ถ้าไม่ได้ใช้โมเดลบริบทใหญ่ ๆ อย่าง Gemini 2.5 Pro ก็อาจยังทำอยู่ แต่รายละเอียดที่หายไปจากสรุปมีมากเกินไปจนใช้ตามนั้นได้ยาก
    • Claude Code มีคำสั่ง /compact สำหรับสรุปบทสนทนาจนถึงตอนนี้เพื่อประหยัดโทเคนบริบท

  • จึงเกิดการสร้าง TSCE (Two-Step Contextual Enrichment) ขึ้นมา เมื่อทดสอบโดยสลับงาน 300 รายการด้วย GPT-35-turbo พบว่า ดีขึ้น +30 จุดเปอร์เซ็นต์
    เป็นเฟรมเวิร์กโอเพนซอร์สฟรี และสามารถลองทดสอบได้โดยตรงจากรีโพซิทอรี: https://github.com/AutomationOptimization/tsce_demo
    ทดสอบซ้ำ 300 ครั้งบน gpt-4.1 ด้วยงานลบ “em-dash” ที่เด่นสะดุดตาซึ่งหลายคนไม่ชอบ โดยเปรียบเทียบ baseline แบบ single pass กับ TSCE ด้วยคำสั่งเดียวกันและพรอมป์ต์ “Remove the em-dashes from my linkedin post. . .”
    จากทั้งหมด 300 ครั้ง baseline ล้มเหลวในการลบ em-dash 149/300 ครั้ง ส่วน TSCE ล้มเหลว 18/300 ครั้ง มันใช้งานได้ และข้อมูลทั้งหมดกับสคริปต์ทดสอบครบถ้วนอยู่ในรีโพซิทอรี

    • ดูเหมือนจะสิ้นเปลือง กิโลวัตต์-ชั่วโมง ไปมากเกินไปกับงาน find-and-replace นะ สงสัยว่าเคยได้ยิน text.replace("—", "-") ไหม
    • แค่ปรับตัวอย่าง baseline ของ em dash นิดเดียว ก็ได้ อัตราสำเร็จ 100% บน GPT-4.1 โดยไม่ต้องเรียกเพิ่ม ไม่มีต้นทุนโทเค็นเพิ่ม และไม่ต้องโชว์เทคนิคอะไรหรูหรา
      system prompt: "Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."
      user prompt:
      Temperature: 0.0

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

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

  • น่าแปลกใจที่ branch/fork ไม่ใช่ฟีเจอร์หลักในเครื่องมือแชตหลัก ๆ แก้ไขคำตอบได้ก็จริง แต่แบบนั้นบริบทอื่น ๆ จำนวนมากจะหายไป
    โฟลว์ของผมประมาณ 1) วางแผน 2) ลงมือทำ 3) แตกกิ่ง (เพราะฟีเจอร์หรือปัญหา dependency แปลก ๆ) 4) กลับไปข้อ 2 การตัดแต่งพรอมป์ต์และการแตกกิ่งควรเป็นเครื่องมือชั้นหนึ่งในการใช้งาน LLM ทุกรูปแบบ

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

  • ถ้าสร้างอินเทอร์เฟซ LLM โดยยึดบทสนทนาแบบ single-turn เป็นหลัก จะมีปัญหาที่เห็นได้ชัด คนส่วนใหญ่คาดหวัง บทสนทนาแบบเส้นตรง
    ผมสร้างบอต Telegram http://t.me/experai_bot เป็น UI อเนกประสงค์สำหรับ LLM โดยลดฟีเจอร์ลงบ้าง และออกแบบรอบแนวคิดที่ว่า “ข้อความที่ไม่ใช่การตอบกลับคือบทสนทนาใหม่” ถ้าอยากรักษาบริบทไว้ ก็ให้ตอบกลับข้อความของบอตต่อไป ผู้ใช้ที่ไม่ใช่สาย advanced จะเข้าใจแนวคิดนี้ยาก
    ยังเคยเห็นด้วยว่าเมื่อโมเดลของ OpenAI ตอบคำถามเดียวกัน แค่มี system message เล็กน้อยมาก ๆ ก็ทำให้ประสิทธิภาพแย่ลง ตัวอย่างเช่น รายการตัวเลือกในคำตอบสั้นลง เป็นแบบนั้นกับ 3.5 และ 4o ส่วนโมเดลล่าสุดไม่แน่ใจ ดังนั้นโดยค่าเริ่มต้นจึงตัดสินใจไม่ใส่ system message ถึงอย่างนั้นถ้าจำเป็นก็ยังเพิ่มได้ และสามารถเปิดปิดเพื่อผสมกันได้

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

    • ในบาง workflow ก็โอเค แต่สิ่งนี้ใกล้เคียงกับ การต้อนแมว มากกว่า “การเรียนรู้”
    • ทุกคนอยากเติม prompt engineering อันยอดเยี่ยมในแบบของตัวเองเข้าไป

  • นี่คือเหตุผลหลักที่ผมสร้าง promptdown ผมอยาก แก้ไขประวัติแชตทั้งหมด ได้ในทุกเทิร์น และในอินเทอร์เฟซแชตมาตรฐานที่มีแต่การเพิ่มต่อท้าย มันทำแบบนั้นได้ไม่ง่าย
    https://github.com/t-kalinowski/promptdown

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

    • ใช่เลย prompt engineering ไม่ใช่แค่การสร้างประโยคแรกให้สมบูรณ์แบบ แต่ใกล้เคียงกับ การจัดการบทสนทนา มากกว่า เราจะค่อย ๆ จับทางได้ว่าโฟลว์เริ่มออกนอกทางเมื่อไร และเมื่อไรควรรีเซ็ต