ทำ Autoresearch กับไอเดียวิจัยเก่า

 (ykumar.me)
4 คะแนน โดย GN⁺ 2026-03-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบ Autoresearch เป็นโครงสร้าง constraint optimization loop ที่ให้เอเจนต์ LLM ปรับแก้ train.py ซ้ำ ๆ เพื่อปรับปรุงประสิทธิภาพ โดยทำวงจรอัตโนมัติตั้งแต่การตั้งสมมติฐานไปจนถึงการประเมินผล
  • การทดลองรันใน สภาพแวดล้อม sandbox แบบคอนเทนเนอร์ เพื่อปิดกั้นการเข้าถึงเครือข่ายและการรันโค้ดตามอำเภอใจ
  • ใช้ ชุดข้อมูล Ukiyo-eVG สำหรับฝึกด้วยภาพพิมพ์แกะไม้ญี่ปุ่นประมาณ 11,000 ภาพและข้อมูล annotation โดยทำผลงานได้ Mean Rank 34.30, R@5 ราว 53% ด้วยโมเดลที่อิง CLIP
  • การปรับปรุงหลักมาจาก การผ่อนข้อจำกัดของพารามิเตอร์ temperature (-113 Mean Rank) และ การจูนไฮเปอร์พารามิเตอร์ (-30 Mean Rank) โดยบันทึกการปรับปรุงประสิทธิภาพ 54% ผ่านการคอมมิต 13 ครั้งจากการทดลอง 42 ครั้งในหนึ่งวัน
  • เอเจนต์ LLM มีประสิทธิภาพเมื่อพื้นที่ค้นหาถูกกำหนดไว้อย่างชัดเจน แต่หลังเข้าสู่ช่วงเปลี่ยนโครงสร้าง ความไม่เสถียรเพิ่มขึ้นจนเห็น ข้อจำกัดของการวิจัยอัตโนมัติเต็มรูปแบบ

แนวคิดหลัก

  • Autoresearch คือโครงสร้าง constraint optimization loop ที่มีเอเจนต์ LLM เป็นศูนย์กลาง โดยเอเจนต์จะปรับแก้ train.py เพื่อปรับปรุงตัวชี้วัดการประเมินแบบวนซ้ำ
    • เอเจนต์จะอ่านคำสั่งจาก program.md และใช้ scratchpad.md เป็นบันทึกงานเพื่อจดกระบวนการทดลอง
  • การสำรวจแบ่งเป็นหลาย เฟส (phase) โดยเริ่มจากการจูนไฮเปอร์พารามิเตอร์ ต่อด้วยการเปลี่ยนโครงสร้างขนาดเล็ก และขยายไปสู่การสำรวจแบบอิสระที่มีข้อจำกัดน้อยลง
  • ลูปทั้งหมดถูกออกแบบเป็นวงจร ตั้งสมมติฐาน → แก้โค้ด → ฝึก → ประเมิน → คอมมิตหรือย้อนกลับ → ทำซ้ำ
  • แต่ละการทดลองถูกจำกัดให้เสร็จภายในราว 5 นาที เพื่อเร่งการวนซ้ำและลดการ overfit
  • เอเจนต์สามารถแก้ train.py ได้อย่างอิสระภายในเวลาที่กำหนด

  • การทำ Sandbox

    • เพื่อป้องกันความเสี่ยงจากการรันโค้ดตามอำเภอใจ จึงรันลูปการฝึกใน สภาพแวดล้อมคอนเทนเนอร์ และปิดการเข้าถึงเครือข่าย
    • run.sh จัดการโฟลว์การทดลองทั้งหมด และ Claude Code สามารถแก้ได้เฉพาะ train.py กับ program.md
    • การรัน Python โดยตรง, การติดตั้ง pip, การเข้าถึงเครือข่าย, git push ฯลฯ ถูกจำกัดทั้งหมด
    • มีการเปิดเผย implementation ที่เกี่ยวข้องบน GitHub repository

ชุดข้อมูล

  • เนื่องจากไม่สามารถเข้าถึงชุดข้อมูล X-ray ทางการแพทย์ที่ใช้ในงานวิจัยเดิมได้ จึงเปลี่ยนมาใช้ชุดข้อมูล Ukiyo-eVG
    • มีภาพพิมพ์แกะไม้ญี่ปุ่นประมาณ 11,000 ภาพ พร้อม annotation แบบวลี-กล่องขอบเขต (bounding box)
    • แปลง bounding box เป็น Gaussian heatmap แล้วเพิ่มเข้าไปในอินพุตของโมเดล โดยใช้แนวทางคล้ายกับกลไก expert attention ในงาน eCLIP ดั้งเดิม
  • heatmap ช่วยชี้นำให้โมเดลโฟกัสกับบริเวณเฉพาะ

การตั้งค่าการทดลองกับ Claude Code

  • Claude Code อัปเกรดโค้ดวิจัยเดิมให้ทำงานบนสภาพแวดล้อม Python รุ่นใหม่ พร้อมเขียน data loading สำหรับชุดข้อมูลใหม่และ scaffold ของลูปการทดลอง
  • มีการตั้งค่า split สำหรับ cross-validation, logic การประเมิน และไอเดียตั้งต้นใน program.md
  • ใช้ Mean Rank เป็นตัวชี้วัดการประเมิน และรายงาน Recall@K ควบคู่ในผลลัพธ์สุดท้าย
    • มีการระบุว่า Mean Rank ใช้เพื่อการตัดสินแบบตรงไปตรงมา แต่ Median Rank อาจเหมาะกว่าเพราะไวต่อ outlier น้อยกว่า
  • องค์ประกอบของโมเดล: backbone แบบ CLIP คือ ViT-Small (22M) + DistilBERT (66M) + HeatmapProcessor รวมแล้วราว 90M พารามิเตอร์
    • การฝึก: 800 สเต็ป (ประมาณ 3 นาทีต่อการทดลอง บน RTX 4090)
    • การประเมิน: วัด Mean Rank และ Recall@K บนชุดทดสอบ 1,000 ภาพ
    • ประสิทธิภาพตั้งต้น: Val Mean Rank 344.68, img→txt R@1 17.2%, txt→img R@1 16.5%

ผลการทดลอง

  • ตลอดหนึ่งวันมีการทดลองทั้งหมด 42 ครั้ง ในจำนวนนี้คอมมิต 13 ครั้ง และย้อนกลับ 29 ครั้ง
    • Mean Rank ลดจาก 344.68 เหลือ 157.43 ลดลง 54%
  • เมื่อนำมาฝึกขั้นสุดท้ายบนชุดข้อมูลทั้งหมด คะแนนทดสอบกลับสูงกว่าคะแนน validation
    • สิ่งนี้บ่งชี้ว่าการทดลองสั้น 800 สเต็ปอยู่ในภาวะ underfitting
  • ประสิทธิภาพบนชุดทดสอบสุดท้าย: Mean Rank 34.30, img→txt R@5 53.0%, txt→img R@5 51.4%

จุดปรับปรุงสำคัญ

  • การแก้ temperature clamp (-113 Mean Rank)

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

  • Optuna++ (-30 Mean Rank)

    • การปรับปรุงถัดมาส่วนใหญ่เกิดจาก การจูนไฮเปอร์พารามิเตอร์
    • การเพิ่ม projection dimension และปรับ learning rate ใหม่ ช่วยเพิ่มผลลัพธ์ได้อีกราว 30 จุด
    • งานน่าเบื่อที่มนุษย์ต้องทำซ้ำ ๆ ถูกเอเจนต์ทำได้เร็วและเป็นระบบกว่า

  • ช่วงผลตอบแทนลดลง

    • หลังเฟส 4 (การเปลี่ยนโครงสร้าง) อัตราความสำเร็จของสมมติฐานจาก LLM ลดลงอย่างมาก
    • การเปลี่ยน กลไก attention หรือการลองไอเดียแบบ moonshot ส่วนใหญ่ล้มเหลว
    • ช่วงท้ายของการสำรวจมีการลองแบบค่อนข้างสุ่มมากขึ้น

  • ความสำคัญของ Sandbox

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

ข้อสังเกตส่งท้าย

  • ตลอดกระบวนการ 90% แรกดำเนินไปอย่างราบรื่น แต่ 10% ท้ายต้องการการแทรกแซงจำนวนมาก
  • เอเจนต์ LLM สามารถทำวิจัย ML ได้อย่างมีประสิทธิภาพเมื่ออยู่ใน พื้นที่ค้นหาที่กำหนดไว้อย่างชัดเจน
  • ลูปคอมมิต-ย้อนกลับของ Autoresearch มีประโยชน์ในฐานะกลยุทธ์การสำรวจที่มีโครงสร้าง
  • แต่เมื่อขยายไปสู่พื้นที่ที่ยังไม่รู้จัก ลูป optimization จะเริ่มไม่เสถียร
  • ข้อจำกัดที่ให้เปลี่ยนได้เพียงหนึ่งอย่างต่อการทดลองอาจ เข้มงวดเกินไป สำหรับการสำรวจไอเดียขนาดใหญ่
    • ในอนาคต มีการเสนอให้เพิ่ม ขั้นวางแผน หรือใช้ subagent เป็นทิศทางการปรับปรุง
  • หลังจบการทดลอง การทำงานร่วมกับ Claude Code ก็จบลงพร้อมการกลับสู่กิจวัตรประจำวัน

คำขอบคุณ

  • ชุดข้อมูล Ukiyo-eVG: มีภาพพิมพ์แกะไม้ญี่ปุ่นราว 11K ภาพพร้อม annotation แบบวลี-กล่องขอบเขต
  • Autoresearch: อ้างอิงจากไอเดียดั้งเดิมของ Andrej Karpathy

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

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

 
GN⁺ 2026-03-24
ความคิดเห็นจาก Hacker News

  • ถ้าลิงก์หลักช้า มีคนแนะนำให้ลองใช้ เวอร์ชัน archive.is

  • ฉันมักใช้ LLM เพื่อสำรวจงานวิจัยเดิมหรือใช้คิดปัญหาในมุมอื่น
    90% ของผลลัพธ์ใช้กับโดเมนของฉันไม่ได้ แต่ที่เหลืออีก 10% ค่อนข้างมีประโยชน์
    แต่การมี เอเจนต์ ที่ลองทุกอย่างที่ LLM แนะนำจริง ๆ มีต้นทุนสูงเกินไป ($$$)
    ในรายการคำแนะนำมักมี ไลบรารีเฉพาะทาง ที่เลิกดูแลไปแล้วเยอะ
    ในทางกลับกัน “ที่ปรึกษาผู้เชี่ยวชาญ” ของบริษัทก็มักเสนอไอเดียหลุดโลกแบบเดียวกัน เลยอยากให้เอเจนต์ไปจัดการพวกเขาแทนมากกว่า

    • คุณค่าของเอเจนต์คือมัน ทำการทดลองซ้ำอัตโนมัติ ได้ตอนที่ผู้ใช้พักอยู่
      แต่จะมีความหมายก็ต่อเมื่อการทดสอบแต่ละครั้งเร็วพอเท่านั้น ในงานของฉัน การทดสอบหนึ่งครั้งใช้เวลาครึ่งวัน เลยปล่อยรันข้ามคืนได้ยาก
    • อยากรู้ว่าคุณทำงานอยู่ในโดเมนไหน
    • ฉันรู้สึกว่า LLM มีประโยชน์กับ ประโยคสั้น ๆ ที่ขี้เกียจจำ หรือส่วนที่ผิดบ้างก็ไม่เป็นไร
      เวลาเห็นคนตั้งค่าอะไรอย่าง MCP server หรือ AGENTS.md ก็เหมือนเป็นหลักฐานว่า LLM ไม่ได้ทำงานอย่างที่โฆษณาไว้
      ถ้าปรับแต่งให้เข้ากับเวิร์กโฟลว์เฉพาะก็ดีมาก แต่ก็สงสัยว่าจะ สเกล ได้จริงไหม
      ถ้าไม่มีเงินทุนมหาศาลมาค้ำการเทรนและโครงสร้างพื้นฐาน มันจะเป็น โมเดลธุรกิจ ที่ยั่งยืนได้หรือ?
    • ปัญหาอาจเป็นเรื่องต้นทุนก็ได้ ฉันใช้ Claude Code แบบเบา ๆ แต่แม้อยู่ในแพลน Max โทเคนก็แทบไม่หมดเลย

  • ประโยคที่ว่า “เอเจนต์ทำตัวเหมือนอัลกอริทึมปรับแต่งไฮเปอร์พารามิเตอร์” น่าประทับใจมาก
    แกนหลักคือไฟล์ system prompt ชื่อ program.md เพียงไฟล์เดียว โดยวนซ้ำ “ปรับปรุง train.py → รันการเทรน → ประเมินผล → บันทึกผลลัพธ์”
    ที่เหลือก็เป็นเพียงโมเดล ML แบบใดก็ได้

  • การเอาโค้ดที่ทำงานอยู่ให้ LLM แล้วให้มันวนซ้ำแก้บั๊ก วัดประสิทธิภาพ และประเมิน test coverage เป็นแนวทางมาตรฐานของทีมเรา
    การใช้คนละโมเดลในแต่ละรอบให้ความรู้สึกว่าได้ มุมมองใหม่ ซึ่งดีมาก

    • อยากรู้ว่าวิธีนี้จะนำไปใช้กับการเทรน local LLM ที่เฉพาะเจาะจงกับภาษาหรือเฟรมเวิร์กบางอย่างได้ไหม

  • ฉันสงสัยว่าเหตุใด “Autoresearch” ถึงกลายเป็นประเด็นร้อนขนาดนี้
    ฉันคิดว่าคอขวดของ AI/ML มีแต่ คุณภาพข้อมูล หรือ ทรัพยากรคอมพิวต์ มาโดยตลอด และไม่แน่ใจว่านี่ช่วยเรื่องนั้นได้หรือเปล่า

    • ที่จริงความพยายามแบบนี้มีมานานแล้ว ตัวอย่างก็คือวงการ AutoML แต่ในทางปฏิบัติมันไม่ค่อยเวิร์ก
      เคยมีแนวทางอย่าง Bayesian optimization หรือ Gaussian Process เหมือนกัน แต่สุดท้าย random search กลับดีกว่า
      สิ่งที่ต่างคือ LLM สามารถอ่านงานวิจัยแล้ว อนุมานเชิงสามัญสำนึก ได้
      มันไม่สมบูรณ์แบบ แต่ก็อาจดีกว่าวิธีเดิม
    • สิ่งที่ต่างคือมันทำได้มากกว่าการจูนไฮเปอร์พารามิเตอร์แบบธรรมดา โดยรวมถึง การเปลี่ยนโครงสร้างแบบไม่พาราเมตริก ด้วย
      ไม่ใช่แนวคิดใหม่ทั้งหมด แต่ดูเหมือนคาดหวังว่าจะพึ่งพา brute-force น้อยลง
    • มีกลวิธีเดิมอย่าง “Swarm optimization” อยู่แล้ว แต่จุดต่างคือ LLM เรียนรู้จากงานวิจัยในอดีตและ โฟกัสที่แกนสำคัญ ได้
      กล่าวคือ LLM สามารถ นำไปใช้ประโยชน์ จากงานที่มีคนทำไว้แล้วได้
    • ฉันไม่เห็นด้วยกับคำพูดที่ว่า “ข้อมูลหรือคอมพิวต์คือคอขวด”
      แก่นของ ML คือการหาว่า ฟังก์ชันแมปปิง แบบไหนดีกว่าสำหรับอินพุต X เดิม
      แค่เพิ่มคอมพิวต์ไม่ได้แก้ปัญหาเสมอไป
    • สุดท้ายแล้ว Autoresearch ก็คือการ มอบหมายการคิดเองให้ LLM

  • โดยสรุป มันใช้ได้ผลจริง LLM ทั้ง หาบั๊ก และ ทำ optimization ได้

    • แต่ในความเป็นจริง การปรับปรุงส่วนใหญ่เกิดจาก การแก้บั๊ก + การจูนด้วย Optuna
      เรื่องพวกนี้ใช้ Claude Code ก็ทำได้เร็วมาก
      คุณค่าที่แท้จริงของ Autoresearch น่าจะอยู่ที่ การสำรวจสถาปัตยกรรม
      อยากรู้ว่ามีใครเคยลองใช้กับ exploratory modeling บ้างไหม

  • พอดู commit log (ลิงก์ GitHub) แล้วพบว่าส่วนใหญ่เป็น การจูนไฮเปอร์พารามิเตอร์
    ถ้าแค่นั้นก็รู้สึกว่าไม่คุ้มค่าโทเคน ($$$)

    • ถ้าเพิ่มขั้น ประเมินต้นทุนและจัดลำดับ ให้ Autoresearch แล้วให้มนุษย์ตรวจทานก่อนค่อยรัน น่าจะมีประสิทธิภาพขึ้น
      อาจปรับปรุงได้ด้วยการให้ฟีดแบ็กเรื่องต้นทุนผ่าน LoRa adapter
    • ที่จริงใช้เครื่องมือโอเพนซอร์สอย่าง Optuna หรือ skopt ก็ทำได้โดยไม่ต้องใช้ GPU

  • ในงานต้นฉบับเขาใช้ข้อมูล X-ray ทางการแพทย์ แต่เพราะเข้าถึงไม่ได้จึงเปลี่ยนมาใช้ Ukiyo-eVG (ภาพพิมพ์แกะไม้ญี่ปุ่น 11K ภาพ) แทน
    มันดูเป็นการเปลี่ยนแบบแปลก ๆ เพราะมีข้อมูลภาพการแพทย์ฟรีจำนวนมากอยู่ใน Cancer Imaging Archive ด้วย

    • เห็นด้วย เพียงแต่รู้สึกไม่สบายใจที่จะปล่อยให้เอเจนต์จัดการข้อมูลทางการแพทย์ และอยากทดลอง domain transfer ด้วย

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

    • มีคำตอบกลับมาว่าขอบคุณ และอ่านอย่างเพลิดเพลิน

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

    • การออกแบบ fitness function ที่ดีเป็นเรื่องยากเสมอ ไม่ว่าจะเมื่อก่อนหรือเดี๋ยวนี้
    • บางคนก็มองว่านั่นแหละคือ ระเบียบวิธีทางวิทยาศาสตร์ นั่นเอง