AutoThink: เพิ่มประสิทธิภาพ LLM แบบโลคัลด้วยการให้เหตุผลแบบปรับตัว

 (news.ycombinator.com)
2 คะแนน โดย GN⁺ 2025-05-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นเทคนิคที่ช่วยให้ LLM แบบโลคัลปรับจำนวน โทเค็นสำหรับการให้เหตุผล ตามความยากของคำถาม เพื่อสร้างคำตอบที่มีประสิทธิภาพมากขึ้นด้วยทรัพยากรเท่าเดิม
  • แทนที่จะให้ “เวลาคิด” เท่ากันกับทุกคำถาม จะแบ่งเป็นความซับซ้อนระดับ HIGH/LOW แล้วจัดสรรโทเค็น 70~90% ให้กับการให้เหตุผลที่ซับซ้อน และ 20~40% ให้กับคำถามง่าย ๆ
  • ใช้ steering vector ที่อิงจาก Pivotal Token Search ในเปเปอร์ Microsoft Phi-4 เพื่อชี้นำรูปแบบการให้เหตุผล เช่น ความแม่นยำเชิงตัวเลข การแก้ไขตนเอง และการสำรวจอย่างละเอียดถี่ถ้วน
  • บน DeepSeek-R1-Distill-Qwen-1.5B คะแนน GPQA-Diamond เพิ่มจาก baseline 21.72% เป็น 31.06% คิดเป็นการปรับปรุงสัมพัทธ์ 43% และ MMLU-Pro เพิ่มจาก 25.58% เป็น 26.38%
  • ทำงานได้กับโมเดลให้เหตุผลแบบโลคัล เช่น DeepSeek, Qwen และโมเดลที่ fine-tune เอง โดยใช้โทเค็นน้อยกว่าแนวทางมาตรฐานและ ไม่พึ่งพา API

การปรับทรัพยากรการให้เหตุผลตามแต่ละคำถาม

  • AutoThink เป็นเทคนิค adaptive resource allocation ที่จัดสรรทรัพยากรการให้เหตุผลของ LLM แบบโลคัลแตกต่างกันไปในแต่ละคำถาม
  • ขั้นแรกจะแยกคำถามเป็นความซับซ้อนระดับ HIGH หรือ LOW จากนั้นปรับสัดส่วนโทเค็นสำหรับการให้เหตุผลตามระดับความซับซ้อน
    • การให้เหตุผลที่ซับซ้อน: 70~90% ของโทเค็นทั้งหมด
    • คำถามง่าย ๆ: 20~40% ของโทเค็นทั้งหมด
  • steering vector มาจาก Pivotal Token Search และช่วยนำทิศทางการให้เหตุผลของโมเดลระหว่างการสร้างข้อความ
    • พฤติกรรมที่ชี้นำรวมถึง ความแม่นยำเชิงตัวเลข, การแก้ไขตนเอง และการสำรวจอย่างละเอียดถี่ถ้วน
  • การใช้งานประกอบด้วยสองแกนหลัก
    • เฟรมเวิร์กจำแนกแบบปรับตัว ที่เรียนรู้หมวดหมู่ความซับซ้อนใหม่ได้โดยไม่ต้องฝึกใหม่
    • การใช้งานแบบโอเพนซอร์สของ Pivotal Token Search

ผล benchmark และขอบเขตการใช้งาน

  • แสดงผลลัพธ์ต่อไปนี้บน DeepSeek-R1-Distill-Qwen-1.5B
    • GPQA-Diamond: 31.06%, ปรับปรุงสัมพัทธ์ 43% เมื่อเทียบกับ baseline 21.72%
    • MMLU-Pro: 26.38%, เพิ่มขึ้นจาก baseline 25.58%
    • ใช้โทเค็นน้อยกว่าแนวทางมาตรฐาน
  • AutoThink ใช้ได้กับโมเดลให้เหตุผลแบบโลคัลโดยทั่วไป
    • ตัวอย่างโมเดล: DeepSeek, Qwen, โมเดลที่ fine-tune เอง
    • ไม่มี dependency กับ API
  • เอกสารที่เกี่ยวข้อง

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

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

 
GN⁺ 2025-05-29
ความคิดเห็นใน Hacker News

  • ผมขอเปิดเผยว่าแรงจูงใจของ AutoThink เริ่มจากประสบการณ์ที่เห็นโมเดลสาย reasoning เดิมๆ ใช้ทรัพยากรคำนวณสิ้นเปลือง—แม้แต่คำถามง่ายมากอย่าง ‘2+2 เท่าไหร่?’ ก็ยังใช้ ‘เวลาในการคิด’ มากพอๆ กับการพิสูจน์คณิตศาสตร์ซับซ้อน ทำให้เห็นความไม่มีประสิทธิภาพได้ชัดเจน สิ่งที่น่าประหลาดใจคือ เมื่อเอาสองอย่างที่ทดลองแยกกันอยู่ ได้แก่ adaptive classification (เรียนรู้หมวดหมู่ใหม่ได้โดยไม่ต้องฝึกซ้ำ) และ Pivotal Token Search ที่ Microsoft เปิดซอร์สในงานวิจัย Phi-4 มารวมกัน พร้อมใส่การจัดสรรงบประมาณโทเคนแบบไดนามิก ก็ได้การเพิ่มประสิทธิภาพที่มากกว่าคาดมาก ในทางปฏิบัติ จำนวนโทเคนที่ใช้โดยเฉลี่ยกลับลดลง เพราะคิวรีง่ายๆ จบได้เร็วกว่ามากจริงๆ และจะเพิ่มการคำนวณให้เฉพาะคิวรีที่ซับซ้อนเท่านั้น จุดเทคนิคที่น่าสนใจมีอยู่ไม่กี่ข้อ เช่น steering vector มีขนาดเล็กกว่า 1MB ต่อหนึ่งแพตเทิร์น จึงแทบไม่มีภาระด้านหน่วยความจำ กระบวนการจัดประเภทเพิ่มความหน่วงเพียงราว 10ms (น้อยมากจนแทบมองข้ามได้) และการเลือก target layer มีความสำคัญมาก (ในโมเดลส่วนใหญ่ เลเยอร์ช่วงกลางประมาณ 15~20 ให้ผลดีที่สุด) สิ่งที่อยากได้ฟีดแบ็กคือ—ประสบการณ์กับแนวทาง adaptive ที่คล้ายกัน, แพตเทิร์น reasoning ที่น่าจะ steer ได้มีประโยชน์กว่าเดิม, และไอเดียเรื่องการตรวจหา target layer ที่เหมาะสมที่สุดโดยอัตโนมัติ ถ้ามีข้อสงสัยเรื่องการติดตั้งใช้งานหรือผลลัพธ์ ถามมาได้ทุกอย่าง

    • ตอนนี้ก็ไม่แน่เสมอไปแล้วนะ เคยลองใช้ Gemini 2.5 Pro หรือยัง—กับคำถามง่ายๆ มันแทบไม่ ‘คิด’ เลย แต่ถ้าเป็นคำถามเขียนโค้ดจะตอบยาวเหมือนบทความตรรกะเต็มรูปแบบ o3 ก็ดูเหมือนจะเป็นแบบเดียวกัน

    • ขอยินดีด้วย! ทุกความพยายามในการทำให้ LLM มีประสิทธิภาพขึ้นเป็นเรื่องที่น่ายินดีมาก จนถึงตอนนี้ผมทำ optimization แบบขี้เกียจๆ โดยให้ Mac Mini M4 รันคิวรีง่ายๆ ด้วยโมเดล MLX และส่งคิวรีซับซ้อนไปให้ Nvidia 4090—ประสิทธิภาพของ M4 เทียบกับ Nvidia น่าทึ่งจริงๆ ผมคิดว่า Apple เดินมาถูกทางกับ MLX จะไปอ่าน AutoThink เพิ่มและมีแผนจะเอาไปรวมใน workflow ส่วนตัวด้วย

    • ผมคิดว่าน่าลองวิธีแทรก ‘คำตอบจาก non-reasoning model’ ไว้หลังพรอมป์ต์ของผู้ใช้—เช่น “ต่อไปนี้คือสิ่งที่ non-reasoning model คิดไว้: ... นี่คือผลลัพธ์ที่ผู้ใช้ต้องการหรือไม่?” ถ้ากรณีที่เวอร์ชัน non-reasoning เพียงพอ โมเดล reasoning ก็อาจตัดสินใจตอบได้เร็วขึ้นด้วย

    • แม้แต่ Claude Sonnet 3.5 (ยังไม่ใช่เวอร์ชันล่าสุดอย่าง 3.7 หรือ 4 ด้วยซ้ำ) ก็ใช้เวลาประมวลผลต่างกันอย่างชัดเจนตามความซับซ้อนของคิวรี—เห็นได้ว่ามีการปรับเวลาในการประมวลผลแบบไดนามิก

  • สงสัยว่าจะจัดประเภทคำถามอย่างไรว่าเป็น ‘คำถามซับซ้อน’ หรือ ‘คำถามง่าย’ คำถามที่ดูง่ายภายนอกอาจยากมากจริงๆ ก็ได้ ตัวอย่างเช่น คำตอบจำนวนเต็มของ x³+y³+z³=42 เป็นปัญหาที่ใช้ทรัพยากรคำนวณนานกว่า 100 ปี หรือสมการอย่าง x/(y+z)+y/(z+x)+z/(x+y)=4 ก็ดูเรียบง่ายภายนอก แต่มีคำตอบขนาดมหาศาลระดับหลายพันล้านที่ต้องใช้ทฤษฎีเส้นโค้งวงรี ดูลิงก์คำตอบ

    • การจัดประเภทความยากของปัญหาก็เป็นทักษะอีกแบบหนึ่งในตัวมันเอง—เป็นความสามารถที่เรียนรู้ได้โดยแยกจากการลงมือแก้จริง เช่น เมื่อเห็นสมการด้านบน คุณควรสังเกตความยากสามอย่างได้ทันที (ขอบเขตจำนวนเต็ม, 3 ตัวแปร, สมการกำลังสาม) เมื่อองค์ประกอบทั้งสามอย่างนี้มารวมกัน ความยากจะพุ่งขึ้นมาก ถ้าเป็นจำนวนจริงหรือจำนวนเชิงซ้อน มีตัวแปรน้อยกว่า หรือมีดีกรีต่ำกว่า ก็จะแก้ง่ายกว่ามาก แน่นอนว่าก็ไม่ได้แปลว่าต้องยากเสมอไป แต่อาจเป็นปัญหาที่ยังแก้ไม่ได้ ผมเองไม่ได้มีความสามารถพอจะลงมือแก้ แต่ฝึกมาพอที่จะรู้ว่าควรไปหาข้อมูลจากไหน เลยจับสัญญาณได้ทันทีว่า ‘นี่มันยากมาก’ ผมคิดว่า LLM ก็น่าจะเรียนรู้ hint แบบนี้ เพื่อพัฒนาความสามารถในการจัดประเภทความยากของปัญหาได้โดยไม่ต้องแก้จริง (หรือไม่ก็อาจเรียนรู้ไปแล้ว)

    • ในกรณีนี้ ความยากของคิวรีนิยามจากจำนวนโทเคนที่โมเดลใช้เพื่อสร้างคำตอบที่ถูกต้องบนชุดข้อมูลคำตอบจริง (เช่น GSM8k) ตัว adaptive classifier จะฝึกจากชุดข้อมูลนี้ แล้วนำไปใช้จัดประเภทในขั้นตอนอนุมาน

  • ตอนที่ Claude 3.7 ออกสวิตช์ extended thinking ผมก็ทำ POC แบบ autothink คล้ายๆ กันเหมือนกัน—แถมชื่อว่า autothink ด้วย
    github.com/NiloCK/autothink
    บล็อก think-toggles-are-dumb
    เวอร์ชันของผมมี first pass ให้ LLM ให้คะแนนความยากของคิวรีเป็น 0~100 แล้วจัดสรรงบประมาณการคิดแบบเชิงเส้นตามคะแนนนั้น แน่นอนว่าเรียบง่ายกว่าเมื่อเทียบกับงานของ OP แต่ดีใจมากที่ได้เห็นผลเชิงปริมาณ—เป็นผลงานที่ทำออกมาได้ดีมาก!

  • รู้สึกว่าเป็น optimization ที่ควรเกิดขึ้นอยู่แล้ว เลยแปลกใจที่การเปลี่ยนแปลงนี้ยังไม่เกิดเร็วกว่านี้ อธิบายได้ดีและลงมือทำเองด้วย น่าประทับใจ

  • กับโมเดล reasoning อย่าง QwQ หรือ Qwen 3 พูดตรงๆ ว่าผมไม่ได้ใช้เวลามากกับการปรับปรุงผลลัพธ์ แต่ลองหลายพรอมป์ต์เพื่อจำกัดการปล่อย reasoning token ออกมาเท่านั้น Gemma 3 27B QAT แม้จะไม่ใช่โมเดล reasoning แต่ก็ทำตามคำสั่งได้ดีมากเมื่อใช้ใน LLM chain หรือ route จึงเอาไปใช้กับการจัดประเภทล่วงหน้า/ปรับภาษาให้เหมาะก่อน แล้วค่อยใช้ reasoning จริงในขั้นถัดไปก็ได้ นอกจากนี้ยังสามารถสลับแสดงคำตอบระหว่าง thinking tag หลายๆ อันได้ด้วย ในการทดลองโมเดลแบบนี้ ผมให้นิยาม ‘โทเคนที่กำลังคิด’ ว่าเป็นทุกโทเคนที่ทำหน้าที่เป็นหลักก้าวกลางในการแก้ปัญหา ไม่ใช่แค่โทเคนสรุปผลแยกต่างหาก ประสบการณ์ของผมคือ ถ้าสั่งให้ใช้บางโทเคนหรือบางรูปแบบถ้อยคำก่อน มักจะช่วยให้ผลดีขึ้น และวิธีที่ AutoThink ใช้โทเคนที่ทำผลงานดีที่สุดจากชุดข้อมูลโดยอัตโนมัติก็ดูน่าจะนำไปใช้เป็น optimization ที่ทั่วไปและมีประสิทธิภาพมากกว่าได้ อย่างไรก็ตาม ถ้าใช้ pivot token มากเกินไป ก็มีความเสี่ยงจะ overfit กับคำถาม benchmark เท่านั้น จึงอยากรอดูต่อว่าวิธีนี้จะ generalize ได้ดีแค่ไหน โดยส่วนตัวผมมองว่าการเลือกคำ/โทเคนอย่างระมัดระวังเป็น optimization ต้นทุนต่ำแต่ประสิทธิภาพสูงที่ช่วยยกระดับคุณภาพผลลัพธ์ได้มาก และคาดหวังกับความสามารถในการ generalize ของ AutoThink

  • สิ่งที่ยอดเยี่ยมมากคือ โมเดลขนาดเล็กทำให้ทีมเล็กๆ และนักวิจัยรายบุคคลสามารถพิสูจน์แนวทางหรืองานทดลองที่สร้างสรรค์ได้ง่ายขึ้น โดยไม่ต้องอิจฉา AI lab ขนาดใหญ่อีกต่อไป ยิ่ง SML (Small Language Model) แข่งขันได้มากขึ้น สิ่งที่ทำได้บนอุปกรณ์ก็จะขยายไกลเกินคาดยิ่งกว่าเดิม

    • ผมว่าคำที่ถูกควรเป็น SLM มากกว่า “small language models (SML)”

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

  • เป็นประเด็นชวนคิดที่ดีมาก! พวกเราก็กำลังจะคุยกันภายในเรื่องการออกแบบ AI crawler ว่าควรรับรู้แบบยืดหยุ่นไหมว่าแต่ละเว็บไซต์ที่เข้าไปเยี่ยมควรยิงคิวรีมากหรือน้อยต่างกัน อนึ่ง พวกเราคือ samaritanscout.org เป็นโปรเจกต์เสิร์ชเอนจินที่รวบรวมโอกาสอาสาสมัครในชุมชนทั้งหมดจากเว็บไซต์ไม่แสวงกำไรหลากหลายแห่งมาไว้ในที่เดียว

  • ผมเพิ่งเริ่มเข้ามาในโลก LLM และ AI ได้ไม่นาน แต่รู้สึกสนใจโปรเจกต์นี้มาก แนวคิดที่ AutoThink ปรับความพยายามในการคำนวณเพื่อให้ AI ‘คิดได้ฉลาดขึ้น’ ตามความยากของปัญหานั้นน่าประทับใจและเข้าใจได้ง่ายมาก—เปรียบได้กับคนที่ตอบ 2+2 ได้ทันที แต่จะใช้เวลาคิดจริงจังเฉพาะตอนเจอโจทย์ยาก แม้ผมจะยังไม่เข้าใจรายละเอียดเทคนิคอย่างงบประมาณโทเคนหรือ steering vector มากนัก แต่ก็หลงใหลในแนวทางที่ทั้งเร็วขึ้นและฉลาดขึ้นพร้อมกันแบบนี้ จะติดตามต่อไป

  • ผมคิดว่าใน LLM ควรหลีกเลี่ยงการใช้คำว่า ‘คิด’ หรือ ‘อนุมาน’—ทั้งสองคำมีความหมายเฉพาะและพื้นฐานทางปรัชญาอยู่ แต่ความจริงแล้ว LLM ไม่ได้คิดหรือให้เหตุผลแบบนั้น มันใกล้เคียงกับวิธีคอมพิวติ้งที่ใช้การคำนวณเพิ่มขึ้น (เวลาโปรเซสเซอร์มากขึ้น) เพื่อสร้างผลลัพธ์มากกว่า

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

    • เปรียบเทียบกับ “ping”—เวลาพูดว่า ping ไปยัง IP address เราไม่ได้ส่งคลื่นเสียงไปกระทบตัวถังโลหะจริงๆ แต่ก็ใช้ในเชิงเปรียบเปรยให้สอดคล้องกับการทำงานจริง ถ้าเป็นอุปมาอุปไมยที่มีประโยชน์ ก็ไม่จำเป็นต้องตรงกับความจริงแบบ 1:1 จึงจะใช้กันได้ในชีวิตประจำวัน

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