FunSearch: การค้นพบใหม่ในคณิตศาสตร์และวิทยาศาสตร์ด้วย LLM

 (deepmind.google)
1 คะแนน โดย GN⁺ 2023-12-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • FunSearch ของ Google DeepMind ผสาน LLM ที่ผ่านการ pretrain กับตัวประเมินอัตโนมัติ เพื่อค้นหาวิธีแก้ปัญหาใหม่ที่ตรวจสอบได้ในโจทย์คณิตศาสตร์และวิทยาการคอมพิวเตอร์ใน รูปแบบโค้ด
  • LLM สร้างโปรแกรมใหม่ จากนั้นตัวประเมินอัตโนมัติให้คะแนน แล้วนำโปรแกรมที่ได้คะแนนสูงกลับเข้า pool อีกครั้ง เพื่อปรับปรุงวิธีแก้ด้วย การวนซ้ำเชิงวิวัฒนาการ
  • ใน cap set problem พบ cap set ที่ใหญ่ที่สุดเท่าที่เคยพบมาในบางการตั้งค่า และยังแสดงประสิทธิภาพได้แม้ในสเกลที่ solver เชิงคำนวณระดับล้ำสมัยเดิมรับมือได้ยาก
  • แนวทางเดียวกันนี้ถูกนำไปใช้กับ online bin packing ด้วย โดยโปรแกรมที่ปรับให้เข้ากับลักษณะของข้อมูลสามารถบรรจุไอเท็มจำนวนเท่ากันลงใน bin ได้น้อยกว่าฮิวริสติกเดิม
  • ผลลัพธ์เป็น โปรแกรมสั้นๆ ที่มนุษย์อ่านได้ นักวิจัยจึงสามารถใช้ตรวจสอบโครงสร้างของวิธีแก้ และใช้ในการทำงานร่วมกันระหว่างมนุษย์กับ AI เพื่อปรับปรุงการตั้งโจทย์ได้

แนวคิดพื้นฐานของ FunSearch

  • FunSearch ค้นหา ฟังก์ชันที่เขียนเป็นโค้ดคอมพิวเตอร์ เพื่อหาวิธีแก้ใหม่ในคณิตศาสตร์และวิทยาการคอมพิวเตอร์
  • ชื่อนี้มาจากแนวคิดว่ามันค้นหาฟังก์ชัน (function)
  • เนื่องจาก LLM อาจสร้างข้อมูลที่ไม่ตรงกับข้อเท็จจริงได้ FunSearch จึงผสาน LLM ที่เสนอไอเดียเชิงสร้างสรรค์เข้ากับ ตัวประเมิน (evaluator) อัตโนมัติ เพื่อคัดกรองไอเดียที่ผิดออก
  • นับเป็นกรณีแรกของการใช้ LLM เพื่อสร้างการค้นพบใหม่ในปัญหาเปิดด้านวิทยาศาสตร์และคณิตศาสตร์ที่ยาก

โครงสร้างการวนซ้ำเชิงวิวัฒนาการ

  • ผู้ใช้เริ่มจากเขียนคำอธิบายปัญหาใน รูปแบบโค้ด
    • รวมถึงขั้นตอนสำหรับประเมินโปรแกรม
    • และใส่ โปรแกรม seed สำหรับเริ่มต้น pool ของโปรแกรมไว้ด้วย
  • ในแต่ละรอบการวนซ้ำ ส่วนหนึ่งของ pool โปรแกรมปัจจุบันจะถูกป้อนให้ LLM
    • LLM สร้างโปรแกรมใหม่โดยอิงจากโปรแกรมเดิม
    • โปรแกรมใหม่จะถูกนำไปรันและประเมินโดยอัตโนมัติ
    • โปรแกรมที่ได้คะแนนสูงจะถูกเพิ่มกลับเข้าไปในฐานข้อมูลโปรแกรม
  • ผู้ใช้สามารถดึง โปรแกรมที่ได้คะแนนสูงสุด เท่าที่ค้นพบจนถึงตอนนั้นได้ทุกเมื่อ
  • FunSearch ใช้ Google PaLM 2 แต่ก็เข้ากันได้กับ LLM อื่นที่ฝึกกับโค้ดมาเช่นกัน
  • เพื่อรับมือกับปัญหาเชิงจัดหมู่ที่ยาก โครงสร้างการค้นหาก็ได้รับการเสริมความแข็งแรงด้วย
    • เริ่มจากความรู้ทั่วไปเกี่ยวกับปัญหา แล้วโฟกัสไปที่ไอเดียหลักที่จำเป็นต่อการค้นพบใหม่
    • เพิ่มความหลากหลายของไอเดียเพื่อหลีกเลี่ยง ภาวะหยุดนิ่ง
    • รันกระบวนการวิวัฒนาการแบบขนานเพื่อเพิ่มประสิทธิภาพ

ผลลัพธ์ใน Cap set problem

  • เป้าหมายแรกที่นำไปใช้คือ cap set problem ซึ่งเป็นปัญหาที่สร้างความท้าทายให้แก่นักคณิตศาสตร์ในหลายสาขาการวิจัยมาหลายสิบปี
  • ปัญหานี้คือการหาขนาดสูงสุดของเซตของจุดในกริดมิติสูงที่ไม่มีจุดสามจุดใดอยู่บนเส้นตรงเดียวกัน หรือที่เรียกว่า cap set
  • มันยังทำหน้าที่เป็นโมเดลสำหรับปัญหาอื่นใน extremal combinatorics ด้วย
  • เนื่องจากจำนวนกรณีที่เป็นไปได้เพิ่มขึ้นอย่างรวดเร็วจนมากกว่าจำนวนอะตอมในจักรวาล การคำนวณแบบ brute force จึงใช้ไม่ได้
  • FunSearch สร้างวิธีแก้ในรูปแบบโปรแกรม และพบ cap set ที่ใหญ่ที่สุดเท่าที่เคยพบมาในบางการตั้งค่า
  • ผลลัพธ์นี้ถือเป็นการเพิ่มขึ้นของขนาด cap set ที่ใหญ่ที่สุดในรอบ 20 ปีที่ผ่านมา และยังแสดงประสิทธิภาพที่ดีกว่าในขอบเขตที่ขนาดปัญหาเกินความสามารถปัจจุบันของ solver เชิงคำนวณระดับล้ำสมัยเดิม
  • แสดงให้เห็นว่าสามารถก้าวข้ามผลลัพธ์เดิมได้ในปัญหาเชิงจัดหมู่ที่สร้างสัญชาตญาณได้ยาก และอาจต่อยอดไปสู่ปัญหาทฤษฎีเชิงจัดหมู่ที่คล้ายกัน รวมถึงสาขาอย่างทฤษฎีการสื่อสารในอนาคต

โปรแกรมสั้นๆ ที่มนุษย์ตีความได้

  • FunSearch ไม่ใช่ black box ที่ให้เพียงรายการคำตอบ แต่สร้างโปรแกรมที่แสดงว่าวิธีแก้ถูกประกอบขึ้นอย่างไร
  • สิ่งนี้ยังสอดคล้องกับวิธีทั่วไปของวิทยาศาสตร์ที่อธิบายการค้นพบหรือปรากฏการณ์ใหม่ผ่านกระบวนการสร้าง
  • FunSearch ชอบวิธีแก้ที่แสดงออกเป็นโปรแกรมกระชับซึ่งมี Kolmogorov complexity ต่ำ
    • Kolmogorov complexity คือความยาวของโปรแกรมคอมพิวเตอร์ที่สั้นที่สุดซึ่งสามารถสร้างผลลัพธ์ของวิธีแก้นั้นได้
    • โปรแกรมสั้นๆ สามารถอธิบายวัตถุที่ใหญ่มากได้ จึงช่วยขยายไปสู่ปัญหาขนาดใหญ่แบบค้นหาเข็มในมหาสมุทรได้
    • ผลลัพธ์ของโปรแกรมทำให้นักวิจัยเข้าใจได้ง่าย
  • ในโค้ดผลลัพธ์บางส่วนที่ได้คะแนนสูง พบ สมมาตร ที่น่าสนใจ และอาศัยสิ่งนี้เพื่อปรับแต่งการตั้งโจทย์จนได้วิธีแก้ที่ดีกว่า
  • Jordan Ellenberg กล่าวว่า FunSearch มอบ “กลไกใหม่โดยสิ้นเชิงสำหรับการพัฒนากลยุทธ์การโจมตี” และวิธีแก้ที่สร้างขึ้นนั้นมีความมั่งคั่งทางแนวคิดมากกว่ารายการตัวเลขอย่างมาก

การนำไปใช้กับ Online bin packing

  • FunSearch ยังถูกนำไปใช้กับ bin packing ซึ่งเป็นปัญหาวิทยาการคอมพิวเตอร์เชิงปฏิบัติ
  • bin packing คือปัญหาการบรรจุไอเท็มที่มีขนาดต่างกันลงใน bin ให้น้อยที่สุดเท่าที่เป็นไปได้
  • ตัวอย่างการใช้งานจริงรวมถึงการโหลดคอนเทนเนอร์ และการจัดสรรงานประมวลผลใน data center เพื่อลดต้นทุน
  • online bin packing มักจัดการด้วย ฮิวริสติก ที่อิงจากประสบการณ์ของมนุษย์
    • ในสถานการณ์เฉพาะที่มีขนาด เวลา และความจุต่างกัน อาจเป็นเรื่องยากที่จะหาชุดกฎที่เหมาะสม
  • แม้จะแตกต่างจาก cap set problem อย่างมาก แต่ FunSearch ก็สามารถตั้งค่าได้ง่าย และสร้างโปรแกรมที่ปรับโดยอัตโนมัติให้เข้ากับลักษณะของข้อมูล
  • โปรแกรมที่สร้างขึ้นบรรจุไอเท็มจำนวนเท่ากันลงใน bin ได้น้อยกว่าฮิวริสติกเดิม
  • แนวทาง AI อื่นๆ เช่น neural network หรือ reinforcement learning ก็อาจมีประสิทธิภาพกับปัญหาเชิงจัดหมู่ที่ยากเช่นกัน แต่การนำไปใช้งานจริงอาจต้องใช้ทรัพยากรจำนวนมาก
  • FunSearch ส่งออก โค้ด ที่ตรวจสอบและนำไป deploy ได้ง่าย จึงสามารถสร้างวิธีแก้ในรูปแบบที่นำไปใส่ในระบบอุตสาหกรรมจริงหลากหลายประเภทได้

อัปเดตและการขยายในปี 2024

  • รายงาน arXiv ที่เผยแพร่ในเดือนธันวาคม 2024 แสดงให้เห็นว่าแนวทางของ FunSearch สามารถใช้เพิ่มขีดความสามารถของมนุษย์ในการแข่งขันเขียนโปรแกรมเชิงจัดหมู่ได้
  • การแข่งขันเขียนโค้ดแบบดั้งเดิม เช่น Codeforces ต้องการวิธีแก้ที่สมบูรณ์สำหรับปัญหาอัลกอริทึมคลาสสิก ภายใต้ข้อจำกัดด้านเวลาและหน่วยความจำ
  • การแข่งขันเชิงจัดหมู่จัดการกับปัญหาซับซ้อนที่ไม่ได้ต้องการคำตอบเดียว แต่ต้องหาวิธีแก้แบบ ประมาณค่า ที่ดีที่สุดเท่าที่เป็นไปได้
  • วิธีนี้สามารถสร้างวิธีแก้ที่ดีกว่าวิธีแก้ที่ผู้เข้าแข่งขันในกลุ่มเปอร์เซ็นไทล์สูงสุดค้นพบได้
  • ใช้โครงสร้างการทำงานร่วมกันที่โปรแกรมเมอร์มนุษย์เขียน backbone ของโค้ดวิธีแก้ และ LLM วิวัฒน์ฟังก์ชันที่ควบคุมโค้ดนั้นอย่างสร้างสรรค์
  • เมื่อ LLM ทั่วไปพัฒนาขึ้น ก็ไม่จำเป็นต้องใช้โมเดลเฉพาะทางด้านโค้ดอีกต่อไป และสามารถใช้ Gemini 1.5 Flash เป็นพื้นฐานได้
  • นอกจากการแข่งขันเขียนโปรแกรมแล้ว FunSearch ยังถูกใช้เพื่อค้นหาวิธีเพิ่มประสิทธิภาพฟังก์ชันให้ดีขึ้นในเฟรมเวิร์ก Bayesian optimization

ทิศทางของการค้นพบที่ใช้ LLM

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

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

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

 
GN⁺ 2023-12-15
ความคิดเห็นจาก Hacker News

  • ผมสงสัยว่า LLM จำเป็นแค่ไหน ในกรณีนี้
    เท่าที่ดู บทบาทของ LLM น่าจะเป็นการสร้างสิ่งที่ดูสมเหตุสมผลเหมือนฟังก์ชัน Python ที่ทำตาม type signature ที่กำหนด
    แต่แม้ไม่มี LLM ก็น่าจะสามารถสร้างฟังก์ชัน Python แบบสุ่มที่ถูกต้องและตรงตาม type signature ที่กำหนดได้อยู่แล้ว คล้ายแบบฝึกหัดอย่าง [1] แต่คราวนี้ทำกับภาษาที่ซับซ้อนกว่ามาก และภาษาที่ถูกจำกัดอาจเขียนได้สะดวกกว่าด้วย วิธีอย่าง PushGP [2] ก็น่าจะเป็นไปได้ไม่ใช่หรือ
    คำถามคือ (1) มูลค่าเพิ่มของ LLM ในที่นี้คืออะไร มันลดจำนวนครั้งในการประเมินที่ต้องใช้เพื่อให้ลู่เข้าได้มากหรือไม่ และถ้าใช่ ลดได้อย่างไร, (2) ในปัญหาเดียวกัน เทคนิค genetic programming แบบอื่นแข่งขันได้น้อยกว่าหรือไม่ และให้คำตอบที่มี fitness ต่ำกว่าหรือไม่, (3) ถ้า genetic programming แบบดั้งเดิมกว่าสามารถไปถึง fitness ใกล้เคียงกันได้ จะมีความต่างด้านต้นทุนการคำนวณอย่างไรเมื่อรวมต้นทุนการฝึก LLM เข้าไปด้วย
    [1] http://www.davidmontana.net/papers/stgp.pdf
    [2] https://faculty.hampshire.edu/lspector/push.html

    • พื้นที่สถานะของโปรแกรมที่รันได้มีขนาดใหญ่กว่าโปรแกรมที่มีประโยชน์มาก
      แค่ลิงกับเครื่องพิมพ์ดีดไม่พอ และเหตุผลที่ใช้ Palm2 ที่นี่ก็เพราะตัวเลือกต้องไม่ใช่สุ่มล้วน ๆ แต่ต้องดูสมเหตุสมผล เพื่อไม่ให้เสียเวลากับโปรแกรมที่ไร้สาระ
      ยิ่งกว่านั้น genetic algorithm ที่อิงการสร้างโปรแกรมแบบสุ่มมีปัญหา cold start ใหญ่มาก หาก fitness ของทุกตัวเลือกเป็น 0 ก็มีโอกาสสูงที่ช่วงแรกจะไม่คืบหน้า และอาจไม่คืบหน้าไปจนจบด้วย
    • ฟังก์ชันที่ค้นพบอยู่ที่นี่: https://github.com/google-deepmind/funsearch/blob/main/cap_s...
      ผมไม่ได้คุ้นกับ genetic algorithm มากนัก แต่ระดับนี้ดูไม่ใช่ว่า genetic algorithm จะหาไม่เจอ อย่างไรก็ดี ถ้ามีคนลองจริงมาเยอะแล้วก็คงน่าประหลาดใจ
      ในทางกลับกัน ตามที่เห็นในภาคผนวก A.2 ของ论文 แนวทางเชิงพันธุกรรมที่ไม่มี LLM น่าจะต้องมี การออกแบบด้วยมือ มากกว่าแนวทางที่ใช้ LLM
    • genetic algorithm ถึงใส่ข้อจำกัดเข้าไป ก็ยังมักสร้างโปรแกรมที่ไร้ความหมายจำนวนมาก หากพยายามมากพอก็อาจทำให้ส่วนใหญ่ถูกต้องตามไวยากรณ์ได้ แต่นั่นก็เท่านั้น
      ความต่างที่ LLM สร้างในที่นี้คือมันจำกัดพื้นที่การกลายพันธุ์ที่เป็นไปได้ให้ส่วนใหญ่เป็น โปรแกรมที่สมเหตุสมผลในเชิงความหมาย
      สำหรับข้อ 3 นั้น LLM ที่ฝึกมาแล้วมีประโยชน์กับเป้าหมายจำนวนมาก ดังนั้นหากกระจายต้นทุนการฝึกตั้งแต่ต้นออกไปก็ไม่ได้สูงนัก อาจมีต้นทุนเพิ่มเติมในการ fine-tune ให้เข้ากับเฟรมเวิร์ก FunSearch แต่ต้นทุน fine-tuning ค่อนข้างเล็ก การใช้มันในเฟรมเวิร์กนี้มีแนวโน้มว่าจะคุ้มกว่าการใช้ genetic programming อย่างเดียว
    • inductive program synthesis แทบหยุดนิ่งมาหลายทศวรรษเพราะพื้นที่ค้นหาใหญ่เกินไป จึงยากที่จะไปไกลกว่าโปรแกรมเล็กน้อยมาก ๆ
      LLM ช่วยลดพื้นที่ค้นหาได้อย่างมาก แน่นอนว่ามันก็มักลดผิดทางด้วย แต่จากนั้นสามารถใช้ inductive program synthesis เพื่อปรับละเอียดและทดสอบต่อได้ เท่าที่ทราบ วิธีแบบนี้เป็นไปไม่ได้หากไม่มี LLM เพราะแม้แต่กรณีเล็กน้อยก็ต้องทดสอบโปรแกรมไร้สาระเป็นพันล้านรายการ
    • ผมเคยคิดว่า stochastic gradient descent กับ LLM ลู่เข้าเร็วกว่า genetic programming มาก อย่างน้อยก็เร็วกว่า random search อย่างแน่นอน

  • บริบทสำคัญคือ การค้นพบนี้แสดงให้เห็นว่าค่าหนึ่งใน combinatorics ไม่ได้อยู่ในช่วง 2.218~2.756 ที่ทราบกันเมื่อปีที่แล้ว แต่ตอนนี้อยู่ระหว่าง 2.2202~2.756
    การปรับปรุงนี้เกิดจากการหาลำดับเฉพาะที่มีคุณสมบัติพิเศษ มากกว่าจะเป็นการพิสูจน์ทางคณิตศาสตร์ที่เน้นตรรกะ แต่นั่นไม่ได้หมายความว่าไม่ rigorous
    มันเป็นวิธีสร้างตัวอย่างที่น่าสนใจและน่าจะมีประโยชน์ และในทางปฏิบัติก็ใกล้เคียงกับ genetic algorithm ที่มี LLM พ่วงอยู่

  • คอมเมนต์ของ Subbarao เกี่ยวกับ “self-play”: https://twitter.com/rao2z/status/1728121216479949048
    ตามโพสต์ FunSearch ใช้วิธีเชิงวิวัฒนาการที่ขับเคลื่อนด้วย LLM เพื่อส่งเสริมและพัฒนาไอเดียที่ได้คะแนนสูง ไอเดียเหล่านี้อยู่ในรูปของโปรแกรมคอมพิวเตอร์ จึงสามารถรันและประเมินได้โดยอัตโนมัติ
    ผู้ใช้เขียนคำอธิบายปัญหาในรูปแบบโค้ด คำอธิบายนี้มีทั้งขั้นตอนสำหรับประเมินโปรแกรม และ seed program สำหรับเริ่มต้น pool ของโปรแกรม
    ในแต่ละรอบ FunSearch จะเลือกโปรแกรมบางส่วนจาก pool ปัจจุบัน ให้ LLM ขยายต่ออย่างสร้างสรรค์เพื่อสร้างโปรแกรมใหม่ จากนั้นโปรแกรมใหม่จะถูกประเมินโดยอัตโนมัติ ตัวที่ดีที่สุดจะถูกเพิ่มกลับเข้าไปใน pool เดิม ก่อให้เกิด ลูปการปรับปรุงตัวเอง
    ในการค้นเว็บ ผมใช้ pplx.ai และ phind.com ในบทบาทคล้ายผู้ประเมิน โดยตั้งคำถาม ดูว่ามันดึงเอกสารอ้างอิงและเว็บลิงก์แบบไหนมา แล้วจึงปรับคำถามหรือถามต่อเพื่อให้ดึงแหล่งข้อมูลที่ลึกขึ้นหรือแตกต่างออกมา วิธีนี้ได้ผลดีกว่าการไล่ค้น reddit หรือ Google ในการหาเพชรที่ซ่อนอยู่
    ใน Tech Twitter ก็มีคอนเทนต์ยอดเยี่ยมมากมาย ตอนนี้ Grok เปิดให้ทุกคนใช้แล้ว จึงหวังว่าจะมีการนำไปใช้เพื่อการวิจัย

  • https://twitter.com/gfodor/status/1735348301812383906
    มีคนกล่าวไว้ว่า “ถ้า DeepMind พิสูจน์ได้อย่างแน่ชัดว่าโครงข่ายประสาทสามารถสร้างความรู้ใหม่ได้จริง นี่คือการค้นพบที่สำคัญที่สุดนับตั้งแต่ไฟ”
    ถ้าเป็นเช่นนั้นจริง ก็สงสัยว่าทำไมทุกคนถึงไม่ได้พูดถึงเรื่องนี้กัน จุดที่ทำได้ด้วย PaLM 2 ซึ่งพัฒนาน้อยกว่า GPT-4 หรือ Gemini นั้นน่าประทับใจมาก น่าตื่นเต้นมากว่าถ้าโมเดลอีกไม่กี่รุ่นถัดไปใช้วิธีแบบนี้ จะทำอะไรได้บ้าง

    • งานยากตรงนี้ทำโดย อัลกอริทึมเชิงวิวัฒนาการ
      LLM แค่แทนที่ตัวดำเนินการกลายพันธุ์แบบสุ่ม โดยประมาณคือได้รับคำขอว่า “ช่วยเสนอการแก้ไขที่สมเหตุสมผลให้ Python 20 บรรทัดนี้หน่อย” การให้เครดิตการสร้างความรู้แก่โครงข่ายประสาทแบบนี้ดูจะใจดีไปหน่อย
      อีกทั้งนอกจากต้องมีโครงสร้างแบบ “สร้างยาก แต่ประเมินง่าย” แล้ว ยังขึ้นอยู่กับลักษณะของปัญหาอย่างมาก ส่วนที่อยากให้วิวัฒน์ต้องสามารถแยกย่อยออกมาเป็นฟังก์ชัน Python สั้น ๆ เพียงตัวเดียวได้
    • ถึงกับพูดออกมาว่า “ว้าว!”
      การที่ LLM สามารถค้นพบวิธีแก้ใหม่ใน เรขาคณิตมิติสูง ที่ไม่มีความคืบหน้ามา 20 ปีได้นั้น ไปไกลกว่าระดับการนำเศษชิ้นส่วนข้อมูลฝึกที่ลอกมา มาเชื่อมต่อกันให้ดูน่าเชื่อถือมาก
      มันบ่งชี้ว่า หากเราหาวิธีพรอมป์และประเมินอย่างถูกต้องได้ ความสามารถของ LLM ยังมีความลึกที่ซ่อนอยู่
      เป็นผลลัพธ์ที่ทำลายความคาดหวังเดิมอย่างมาก เราไม่รู้เลยว่ามีการค้นพบอะไรซ่อนอยู่หลังพรอมป์ถัดไปและ seed สุ่มถัดไป
    • โครงข่ายประสาทสามารถสร้าง “ความรู้ใหม่” ได้มาตั้งนานแล้ว
      LLM ก็เช่นกัน: https://www.nature.com/articles/s41587-022-01618-2
    • ตามบทความวิจัย FunSearch ทำงานได้ดีที่สุดในปัจจุบันกับปัญหาที่มีคุณสมบัติต่อไปนี้
      a) มีตัวประเมินที่มีประสิทธิภาพ, b) มี ฟีดแบ็กคะแนนที่ละเอียดมากพอ เพื่อวัดปริมาณการปรับปรุง กล่าวคือไม่ใช่สัญญาณแบบไบนารี, c) สามารถให้โครงร่างที่มีส่วนโดดเดี่ยวสำหรับให้วิวัฒน์ได้
      ตัวอย่างเช่น ปัญหาการสร้างบทพิสูจน์ทฤษฎีบทอยู่นอกขอบเขตนี้ เพราะยังไม่ชัดเจนว่าจะให้สัญญาณคะแนนที่ละเอียดเพียงพอได้อย่างไร
    • ตัวอย่างนี้ดูค่อนข้างจำกัดอยู่กับการหาอัลกอริทึมหรือฟังก์ชันใหม่
      แม้จะเป็นผลงานที่ยอดเยี่ยม แต่เมื่อเทียบกับการค้นพบไฟ หรือสิ่งมากมายระหว่างทาง เช่น ไฟฟ้า ก็ดูไม่ใช่ระดับเดียวกัน

  • สรุปคือ เมื่อมีเทมเพลต/โครงร่างโปรแกรมและฟังก์ชัน fitness ให้ จะใช้ LLM สร้างประชากรของโปรแกรม และใช้พรอมป์ที่สร้างโปรแกรมใหม่จากเวอร์ชันอื่น ๆ จำนวน k ตัว โดยพบว่า k=2 ดี ลักษณะออกแนวชีววิทยาเล็กน้อย จากนั้นรันโปรแกรมกับอินพุตและให้คะแนนด้วยฟังก์ชัน fitness ส่วนการวิวัฒน์ใช้ island model
    โดยหลักการแล้ว พรอมป์น่าจะให้ความรู้สึกประมาณนี้
    def foo_v1(a, b): ...
    def foo_v2(a, b): ...
    # ใช้ foo_v1 และ foo_v2 สร้างฟังก์ชันใหม่ให้หน่อย เปลี่ยนได้เฉพาะส่วนที่อยู่ในวงเล็บปีกกาคู่แบบ {{ THIS }} เท่านั้น
    def foo(a, b): return a + {{}}
    ถ้าการได้ผลลัพธ์ใหม่ต้องเรียก LLM แค่ประมาณ 1e6 ครั้ง จริง ๆ ก็ถือว่าเป็นจำนวนที่น้อยอย่างน่าประทับใจ มีบอกด้วยว่าการประเมิน/ให้คะแนนใช้เวลาหลายนาที
    จุดนี้น่าคิดเรื่อง trade-off ระหว่างความลึกกับความกว้าง ซึ่งเชื่อมโยงกับ latency และ throughput ตอนให้คะแนนโปรแกรมแต่ละตัวและประชากร ถ้าทำ memoization กับทุกโปรแกรมจะเป็นอย่างไร ถ้ารักษา loss function ให้เป็นหลายมิติ โดยให้แต่ละมิติแทนอินพุตหรือ bucket ของอินพุต อาจทำให้เราหาประชากรของโปรแกรมที่เก่งในพื้นที่ต่างกันก่อน แล้วค่อยนำมาผสานภายหลังได้หรือเปล่า
    ยังสงสัยด้วยว่ามีความรู้ล่วงหน้าหรือไม่ว่า cap set นั้นหายากแค่ไหน ก่อนหน้านี้เคยมีความพยายามเชิงคำนวณแล้วไม่สำเร็จหรือเปล่า แต่ไม่ว่าอย่างไรก็เจ๋งมาก

  • ถ้าพูดใหม่จากโพสต์ Twitter / X ก็คือ ต่อจากนี้มันมีแต่จะดีขึ้น
    กล่าวคือ ศักยภาพของ AI เพิ่มขึ้นแบบไม่ลดลง และเป็นแบบนั้นมาหลายสิบปีแล้ว ในกรณีนี้ ศักยภาพยังเป็นการปรับปรุงตัวเองแบบ recursive ด้วย ตอนนี้เห็นแล้วว่า autocomplete ด้วย AI, refactoring ที่ใช้ AI และ diff ของ code review ที่ AI สร้างอัตโนมัติในคอมเมนต์ ช่วยเพิ่ม productivity การเขียนโค้ดส่วนตัวได้ราว 20~30%
    รู้สึกเหมือน AI กำลังเข้าสู่ยุคคล้าย Intel ช่วงทศวรรษ 90 ถ้าอยากให้โค้ดเร็วขึ้น 2 เท่า ก็แค่รอ CPU Intel รุ่นปรับปรุงถัดไป ตอนนี้โมเดล AI กำลังรับบทนั้น ถ้าเชื่อมต่อบางส่วนของกระบวนการธุรกิจ เช่น coding, customer support, bug triage เข้ากับระบบ LLM ไว้ การ “ปรับปรุง” ระบบก็เหลือแค่เปลี่ยนชื่อโมเดล
    หลังจาก integration ช่วงแรกแล้ว เราสามารถคาดหวังสถานการณ์ที่ “ทุกอย่างค่อย ๆ ดีขึ้นอย่างวิเศษ” ในอีกไม่กี่ปีข้างหน้า ด้วยความพยายามเพียงเล็กน้อย

    • เท่าที่ผมเห็น ไม่พบเนื้อหาแบบนั้นเลยทั้งในบล็อกโพสต์หรือบทความวิจัยที่ลิงก์ไว้
      โดยเฉพาะอย่างยิ่ง ไม่ได้เปรียบเทียบผลลัพธ์ระหว่างการใช้ LLM กับไม่ใช้ LLM ตามความเข้าใจของผม งานวิจัยนี้แสดงผลของ genetic programming ที่ใช้ LLM สร้างฟังก์ชัน Python kernel ซึ่งน่าจะเป็นไปตาม type signature ที่กำหนด งานนี้ไม่จำเป็นต้องใช้ LLM เสมอไป
      ดังนั้นคำถามที่ว่า LLM ทำอะไรที่พิเศษเป็นการเฉพาะหรือไม่ในที่นี้ ยังคงเป็นคำถามเปิดอยู่

  • หนึ่งในปัญหาที่เข้าไปจัดการคือ cap set problem
    https://en.m.wikipedia.org/wiki/Cap_set
    ปัญหานี้คือการหาชุดจุดที่ใหญ่ที่สุดใน lattice มิติสูงซึ่งไม่มีจุดสามจุดใดอยู่บนเส้นตรงเดียวกัน หรือที่เรียกว่า cap set มันสำคัญเพราะทำหน้าที่เป็นโมเดลให้กับปัญหาอื่น ๆ ใน extremal combinatorics ซึ่งศึกษาได้ว่าชุดของตัวเลข กราฟ หรือวัตถุอื่น ๆ สามารถใหญ่หรือเล็กได้เพียงใด การคำนวณแบบ brute force ใช้กับปัญหานี้ไม่ได้ เพราะจำนวนความเป็นไปได้ที่ต้องพิจารณาเพิ่มขึ้นอย่างรวดเร็วจนเกินจำนวนอะตอมในจักรวาล
    FunSearch สร้างคำตอบในรูปแบบของโปรแกรม และในบางการตั้งค่า ก็พบ cap set ที่ใหญ่ที่สุดเท่าที่เคยพบมา นี่เป็นการเพิ่มขึ้นของขนาด cap set ที่มากที่สุดในรอบ 20 ปีที่ผ่านมา อีกทั้งเมื่อปัญหานี้ขยายขนาดขึ้นจนเกินความสามารถของตัวแก้เชิงคำนวณระดับ state-of-the-art ในปัจจุบันไปมาก FunSearch จึงทำผลงานเหนือกว่าตัวแก้เหล่านั้น

  • สงสัยว่าจะผสาน symbolic reasoning เข้ากับ LLM ได้อย่างไร หรือเป็นไปได้หรือไม่

    • สิ่งที่พวกเราทำอยู่ก็คือเรื่องนี้แหละ ผมมองว่าไม่เพียงเป็นไปได้ แต่ยังจำเป็นสำหรับแอปพลิเคชันที่ไปไกลกว่าการสร้างแบบลองผิดลองถูกด้วย
    • ดูเหมือนจะมีส่วนขนานกับแนวคิด neuro-symbolic ที่ Lab V2 ของ ASU กำลังสำรวจอยู่บ้าง
    • LEAN

  • บทความวิจัย FunSearch ล่าสุดของ DeepMind เน้นย้ำว่าได้ใช้ โมเดลภาษาขนาดใหญ่ที่ผ่านการฝึกล่วงหน้า เพื่อสร้างการปรับปรุงโค้ด
    ที่น่าสนใจคือ LLM หลักคือ Codey ซึ่งอิงตระกูลโมเดล PaLM2 แต่ในเอกสารประกอบยังกล่าวถึง StarCoder ซึ่งเป็น LLM โอเพนซอร์สด้วย
    อย่างไรก็ตาม รีโพซิทอรี GitHub ของ FunSearch ไม่ได้รวมการใช้งาน LLM เหล่านี้ไว้ ตัวอย่างเช่น ใน sampler.py มีโค้ดดังนี้

    class LLM:  
"""Language model that predicts continuation of provided source code."""

def __init__(self, samples_per_prompt: int) -> None:  
self._samples_per_prompt = samples_per_prompt

def _draw_sample(self, prompt: str) -> str:  
"""Returns a predicted continuation of `prompt`."""  
raise NotImplementedError('Must provide a language model.')

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

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