LLM4Decompile - เทคโนโลยีดีคอมไพล์โค้ดไบนารีด้วย LLM

 (github.com/albertan017)
2 คะแนน โดย GN⁺ 2024-03-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • LLM4Decompile เป็นโปรเจกต์โอเพนซอร์ส large language model ที่ใช้แปลงไบนารี Linux x86_64 กลับเป็นซอร์สโค้ด C ที่มนุษย์อ่านได้ ภายใต้ระดับการปรับแต่ง GCC O0~O3
  • แนวทางคือแปลงไบนารีเป็นแอสเซมบลีด้วย Objdump ก่อน แล้วให้ LLM ดีคอมไพล์เป็นโค้ด C อีกที และยังมีสาย LLM4Decompile-Ref สำหรับปรับแต่ง pseudocode จากผลลัพธ์ของ Ghidra ด้วย
  • โมเดลเปิดเผยในขนาด 1.3B~22B และ llm4decompile-9b-v2 ทำสถิติ re-executability 64.9% บน Decompile benchmark
  • ตัวชี้วัดการประเมินคือ re-executability ซึ่งดูว่าโค้ดที่ดีคอมไพล์แล้วสามารถรันผ่านชุดทดสอบที่กำหนดไว้ได้จริงหรือไม่ โดยใช้ HumanEval-Decompile ฟังก์ชัน C จำนวน 164 รายการ และ ExeBench จำนวน 2,621 ฟังก์ชันเป็นเบนช์มาร์ก
  • โปรเจกต์ได้เปิดเผย decompile-bench และ SK²Decompile ในปี 2025 และกำลังขยายต่อเพื่อรองรับสถาปัตยกรรม การตั้งค่า และการเชื่อมต่อเครื่องมือดีคอมไพล์เพิ่มเติม

เป้าหมายและขอบเขตการรองรับของ LLM4Decompile

  • LLM4Decompile เป็นโปรเจกต์โอเพนซอร์ส large language model ที่เชี่ยวชาญด้านการดีคอมไพล์
  • เวอร์ชันปัจจุบันสามารถดีคอมไพล์ ไบนารี Linux x86_64 ภายใต้ระดับการปรับแต่ง GCC O0~O3 ให้กลับเป็นซอร์สโค้ด C ที่มนุษย์อ่านได้
  • โปรเจกต์กำลังขยายเพื่อรองรับสถาปัตยกรรมและการตั้งค่าที่หลากหลายยิ่งขึ้น
  • มีการใช้งานหลักอยู่ 2 แบบ
    • LLM4Decompile-End: ตระกูลโมเดลที่ดีคอมไพล์ไบนารีโดยตรง
    • LLM4Decompile-Ref: ตระกูลโมเดลที่ใช้ LLM ปรับแต่ง pseudocode ที่ Ghidra ดีคอมไพล์ออกมา

ขั้นตอนการฝึกและการประเมินผลการดีคอมไพล์

  • กระบวนการคอมไพล์เริ่มจากซอร์สโค้ด C ผ่านขั้นตอน preprocessing, compile, assemble และ link เพื่อสร้างไฟล์รันได้
  • การดีคอมไพล์คือการเดินกระบวนการนี้ย้อนกลับ โดยแปลงโค้ดไบนารีกลับเป็นไฟล์ซอร์สอีกครั้ง
  • เนื่องจาก LLM ไม่สามารถประมวลผลข้อมูลไบนารีได้โดยตรง จึงต้อง disassemble ไบนารีเป็นภาษาแอสเซมบลีก่อนด้วย Objdump
  • README อธิบายว่าไบนารีและ ASM ที่ disassemble แล้วสามารถแปลงกลับหากันได้ จึงถือว่าเทียบเท่ากัน
  • ระหว่างการฝึก จะคำนวณ loss ระหว่างโค้ดที่ดีคอมไพล์แล้วกับซอร์สโค้ดต้นฉบับ ส่วนการประเมินจะตรวจสอบความสามารถเชิงฟังก์ชันจากการผ่าน test assertion

ตัวชี้วัดการประเมินและเบนช์มาร์ก

  • ตัวชี้วัดหลักคือ Re-executability
    • ใช้ตรวจว่าโค้ดที่ดีคอมไพล์แล้วสามารถทำงานได้ถูกต้องหรือไม่
    • ประเมินจากการผ่าน test case ที่กำหนดไว้ทั้งหมด
  • HumanEval-Decompile คือชุดฟังก์ชัน C จำนวน 164 รายการที่พึ่งพาเพียง standard C library
  • ExeBench คือชุดฟังก์ชันจำนวน 2,621 รายการที่นำมาจากโปรเจกต์จริง
    • รวมทั้ง user-defined function, struct และ macro

โมเดลที่เปิดเผยและประสิทธิภาพ

  • LLM4Decompile มีโมเดลตั้งแต่ 1.3B~33B พารามิเตอร์ และเปิดเผยบน Hugging Face
  • ค่า re-executability ของโมเดลหลักมีดังนี้
  • สาย V1.5 ฝึกด้วยชุดข้อมูลขนาดใหญ่ขึ้น 15B โทเค็น และความยาวโทเค็นสูงสุด 4,096 โดยระบุว่ามีประสิทธิภาพเพิ่มขึ้นมากกว่า 100% เมื่อเทียบกับโมเดลก่อนหน้า
  • สาย V2 อิงกับ Ghidra และฝึกด้วย 2B โทเค็นเพื่อปรับแต่ง pseudocode ที่ Ghidra ดีคอมไพล์ขึ้นมา
  • ระบุว่า 22B-V2 มีประสิทธิภาพสูงกว่า 6.7B-V1.5 เพิ่มอีก 40.1%

รายการที่เปิดเผยล่าสุด

  • วันที่ 4 ตุลาคม 2025 มีการเปิดเผย SK²Decompile
    • ขั้นที่ 1 Structure Recovery หรือขั้น Skeleton จะแปลงไบนารีหรือ pseudocode ให้เป็น intermediate representation ที่ถูกทำให้อ่านยาก
    • ขั้นที่ 2 Identifier Naming หรือขั้น Skin จะสร้างซอร์สโค้ดที่มนุษย์อ่านได้พร้อมตัวระบุที่มีความหมาย
    • ลิงก์โมเดล: sk2decompile-struct-6.7b, sk2decompile-ident-6.7
  • วันที่ 20 พฤษภาคม 2025 มีการเปิดเผย decompile-bench
    • มีคู่ฟังก์ชันไบนารี-ซอร์สสำหรับการฝึก 2 ล้านคู่
    • มีคู่ฟังก์ชันสำหรับการประเมิน 70,000 คู่
    • รายละเอียดเพิ่มเติมอยู่ที่ โฟลเดอร์ decompile-bench
  • วันที่ 17 ตุลาคม 2024 มีการเปิดเผย decompile-ghidra-100k
    • มีตัวอย่างฝึกทั้งหมด 100,000 รายการ แบ่งเป็นระดับการปรับแต่งละ 25,000 รายการ
    • มี สคริปต์ฝึก ที่รันได้ในเวลาประมาณ 3.5 ชั่วโมงบน GPU A100 40G เพียงตัวเดียว
    • ต้นทุนการทำซ้ำแบบรวดเร็วรวมต่ำกว่า 20 ดอลลาร์ และทำค่า re-executability ได้ 0.26
  • วันที่ 23 กันยายน 2024 มีการเปิดเผย LLM4Decompile-9B-v2
    • ผ่านการ fine-tune บนพื้นฐานของ Yi-Coder-9B
    • ทำค่า 0.6494 สำหรับ re-executability บน Decompile benchmark

ขั้นตอนการใช้งาน

  • การเริ่มต้นอย่างรวดเร็วประกอบด้วยการ clone รีโพซิทอรี สร้างสภาพแวดล้อม Conda และติดตั้ง requirements.txt
  • ขั้น preprocessing คือคอมไพล์โค้ด C เป็นไบนารีด้วย GCC จากนั้นใช้ objdump -d เพื่อดึงคำสั่งแอสเซมบลีออกมา
  • ต้องเปลี่ยนชื่อฟังก์ชันจาก func0 ในตัวอย่างให้เป็นชื่อฟังก์ชันที่ต้องการดีคอมไพล์
  • แอสเซมบลีอินพุตคาดหวังให้อยู่ในรูปแบบต่อไปนี้
    • <FUNCTION_NAME>:
    • ตามด้วยหลายบรรทัดของคำสั่งแอสเซมบลี
  • ขั้นดีคอมไพล์จะใช้ AutoTokenizer และ AutoModelForCausalLM ของ transformers เพื่อโหลดโมเดลจาก Hugging Face และสร้างโค้ด C จากพรอมป์ต์แอสเซมบลี
  • สามารถใช้งานผ่าน Docker ได้เช่นกัน
    • หลัง build image แล้วให้รันคอนเทนเนอร์พร้อมตัวเลือก GPU
    • มีขั้นตอนให้รัน demo.py ในไดเรกทอรี ghidra

รูปแบบข้อมูล HumanEval-Decompile

  • ข้อมูล HumanEval-Decompile ถูกเก็บเป็นรายการ JSON ใน llm4decompile/decompile-eval/decompile-eval-executable-gcc-obj.json
  • จำนวนตัวอย่างคือ 164*4 รายการ จากฟังก์ชัน 164 รายการคูณกับระดับการปรับแต่ง O0, O1, O2, O3
  • แต่ละตัวอย่างมีคีย์ 5 รายการ
    • task_id: ID ของโจทย์
    • type: ระดับการปรับแต่ง ซึ่งเป็นหนึ่งใน O0, O1, O2, O3
    • c_func: คำตอบ C ของโจทย์ HumanEval
    • c_test: test assertion ของ C
    • input_asm_prompt: คำสั่งแอสเซมบลีและพรอมป์ต์
  • สคริปต์ประเมินผลอยู่ใน โฟลเดอร์ evaluation

รายการที่กำลังดำเนินการและไลเซนส์

  • รายการที่กำลังดำเนินการรวมถึงชุดข้อมูลฝึกที่ใหญ่ขึ้นและกระบวนการจัดระเบียบ การรองรับภาษา แพลตฟอร์ม และการตั้งค่ายอดนิยม การรองรับไฟล์รันได้ และการรวมเข้ากับเครื่องมือดีคอมไพล์อย่าง Ghidra และ Rizin
  • การรองรับชุดข้อมูลฝึกที่ใหญ่ขึ้นและไฟล์รันได้ถูกระบุว่าเป็นรายการที่เสร็จสิ้นแล้วเมื่อวันที่ 13 พฤษภาคม 2024
  • รีโพซิทอรีโค้ดอยู่ภายใต้ MIT License และ DeepSeek License
  • งานวิจัยอยู่ที่ arXiv:2403.05286 และโปรเจกต์ยังมีเอกสารประกอบบน Colab และ YouTube ด้วย

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

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

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

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

    • เพราะแบบนั้น การแปลงไป-กลับ จึงสำคัญ
      หลังจาก decompile ไบนารีกลับเป็นซอร์ส แล้วคอมไพล์กลับเป็นไบนารีอีกครั้ง ก็ควรได้ไบนารีเดิม และทำซ้ำไปจนกว่าการสูญเสียจะลดลงถึงระดับที่ยอมรับได้
      reinforcement learning เหมาะกับปัญหาแบบนี้มาก และเป็นที่รู้กันว่ามันได้ผลดีผิดปกติจริง ๆ ในปัญหาประเภทนี้
    • โดยพื้นฐาน LLM เป็นเชิงความน่าจะเป็น จึงทำงานได้ค่อนข้างดีใน โดเมนที่ไม่ต้องแม่นยำเป๊ะ อย่างการประมวลผลภาษาธรรมชาติ แต่โดยส่วนตัวมองว่าการนำมาใช้กับ decompilation หรือ disassembly นั้นค่อนข้างเป็นกรณี “เลือกเครื่องมือผิด”
      มันอาจเป็นการทดลองสำรวจมีมยอดนิยมช่วงนี้ที่ว่า “ก็ใช้ LLM ไปเลยสิ” ได้ แต่ข้อโต้แย้งที่ใหญ่กว่าคือ decompiler ที่มีอยู่เดิมทำได้ดีกว่าอยู่แล้วด้วยการคำนวณที่น้อยกว่ามาก
    • ใช้เครื่องมือ formal verification ที่รับอินพุต เอาต์พุต และ formal proof ว่าอินพุตตรงกับความหมายของเอาต์พุต แล้วให้ LLM สร้าง proof นั้นมาพร้อมกับเอาต์พุตก็ได้
      จากนั้นใช้เครื่องมือตรวจสอบยืนยันว่าผลลัพธ์ถูกต้องตาม proof ที่ LLM ให้มาหรือไม่
      แน่นอนว่าการสร้างและฝึก LLM ที่ทำ proof แบบนั้นได้เป็นโจทย์ที่ยากกว่า แต่ก็อาจเป็นวิธีจับ hallucination ได้อย่างปลอดภัย
    • ใช้ differential fuzzing ก็ได้
    • แม้จะเชื่อถือได้ไม่เต็มที่ แต่เวลาจะแก้ไขไบนารี โดยปกติแค่เปลี่ยนไม่กี่ฟังก์ชันก็มักพอแล้ว
      ดังนั้นคอมไพล์ใหม่เฉพาะไม่กี่ฟังก์ชันนั้นก็พอ

  • ถ้ารู้จักนักพัฒนาที่สร้างแอปพลิเคชันนั้น ก็น่าสนใจว่าจะใช้โค้ดในอดีตของพวกเขาเป็นข้อมูลฝึกเพื่อเทรน โมดูล decompile ได้หรือไม่
    ตัวอย่างเช่น Super Mario 64 และ Zelda 64 ถูก decompile สำเร็จทั้งหมดแล้ว และเกม N64 อื่น ๆ ก็กำลังดำเนินการอยู่ จึงอยากรู้ว่าจะทำ mapping นักพัฒนาที่มีส่วนร่วมในสองเกมนั้น และถึงขั้นประมาณได้ว่าใครทำโมดูลไหน เพื่อนำไปใช้ decompile เกมอื่นได้หรือไม่
    ถ้าสิ่งนี้ทำได้ดีจริง ๆ ก็อาจฝันถึงชีวิตที่ถอดรหัส binary blob ทุกตัวในพีซี เปิดเผยไดรเวอร์ และเปิด OS ออกมาได้ด้วย
    อาจจินตนาการได้ถึงการไม่พอใจกับ Linux แล้วปลุก Windows XP ขึ้นมาใหม่ พร้อม backport ความปลอดภัยสมัยใหม่และความเข้ากันได้กับแอป แล้วปล่อย Windows 11 ของ Microsoft ไว้อย่างเดิม

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

  • การสร้างชุดข้อมูลคู่ input/output จำนวนมากจาก C code สาธารณะทำได้ง่าย ดังนั้นนี่เป็น use case ที่ดีมากสำหรับ การ fine-tune LLM

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

  • ถ้าผมอ่านตัวเลข ความสามารถในการรันซ้ำ ในภาพผลลัพธ์ถูกต้อง ไอเดียนี้ยอดเยี่ยม แต่ในทางปฏิบัติดูเหมือนจะทำงานได้ไม่ดี
    https://raw.githubusercontent.com/albertan017/LLM4Decompile/...
    ขอเสริมว่า ความสามารถในการรันซ้ำเป็นตัวชี้วัดหลักสำหรับวัดความถูกต้องเชิงความหมาย
    โดยคอมไพล์ผลลัพธ์จาก decompilation กลับใหม่ แล้วรัน test case เพื่อประเมินว่าตรรกะและพฤติกรรมของโปรแกรมถูกรักษาไว้หรือไม่ ส่วนความสามารถในการคอมไพล์ใหม่และความสามารถในการรันซ้ำแสดงถึงการกู้คืนไวยากรณ์และการรักษาความหมายตามลำดับ

  • ปัญหานี้น่าสนใจอย่างน้อยสองด้าน
    อย่างแรก decompiler ในอุดมคติอาจลดทอนความหมายของ ซอร์สโค้ดแบบ proprietary ได้
    อย่างที่สอง มี C code แบบเปิดเผยอยู่มาก ทำให้สร้างชุดข้อมูลคู่ระหว่าง assembly กับซอร์สโค้ดได้ง่าย และยังมีระดับการ optimize, compiler, platform ที่หลากหลายด้วย
    แต่สงสัยว่าทำไมผู้เขียนถึง fine-tune DeepSeek-Coder
    อยากรู้ว่าสามารถฝึก LLM ตั้งแต่ต้นด้วยชุดข้อมูลคล้าย ๆ กันได้หรือไม่ ต้องมีขนาดแค่ไหน และรันแบบ local ได้หรือเปล่า

    • โค้ด proprietary ส่วนใหญ่รันอยู่หลัง firewall ดังนั้นน่าจะไม่ได้รับผลกระทบมากจากวิธีนี้
      แม้งานที่ต้องการจะไม่ได้ใกล้กับโมเดลตั้งต้นมากนัก แต่การเริ่มจาก โมเดลที่ผ่าน pretraining มาแล้วมักดีกว่าการเริ่มจากการสุ่มค่าเกือบเสมอ
    • decompiler ในอุดมคติไม่มีอยู่จริง
      เพราะ compiler ทำให้ข้อมูลสูญหาย ในบางความหมายจึงไม่มีทางมีได้ และแม้มองแบบผ่อนปรนว่าเป็น “ความเข้าใจระดับสูงของโค้ดผลลัพธ์” นี่ก็เป็นปัญหาระดับ AGI ของสาขาความปลอดภัยคอมพิวเตอร์
      จนถึงตอนนี้ยังไม่มีใครเข้าใกล้มันได้เลย
    • การฝึก language model ตั้งแต่ต้นต้องใช้ข้อมูลจำนวนมาก
      Llama2 ถูกพัฒนาด้วย 2 ล้านล้านโทเคน แต่ชุดข้อมูลนี้มีประมาณ 4 พันล้านโทเคน
      ขนาดโมเดลที่เหมาะสมก็ไม่ได้กำหนดง่าย ๆ และในการทดลอง โมเดล 7 พันล้านพารามิเตอร์มีความสามารถในการรันได้ 21% ขณะที่โมเดล 1 พันล้านพารามิเตอร์ได้เพียง 10%
      อย่างไรก็ตาม ความสามารถในการคอมไพล์ใหม่ของทั้งสองค่อนข้างใกล้เคียงกัน
      โมเดล 1 พันล้านพารามิเตอร์ต้องใช้หน่วยความจำ GPU อย่างน้อย 2GB จึงใช้ได้กับ GPU ส่วนใหญ่ ส่วนโมเดล 7 พันล้านต้องใช้ 14GB จึงเหมาะกับตระกูล 3090/4090
      โมเดล 33 พันล้าน ถ้าเป็นการ์ดเดียวตัวเลือกคือ A100 80GB และในทางเทคนิคอาจทำได้บน MacBook ด้วย แต่คงไม่ใช่สิ่งที่อยากใช้งานจริง
    • น่าจะเป็นเพราะความต่างของต้นทุนระหว่างการฝึกตั้งแต่ต้นกับการ fine-tune
      อาจเป็นจุดเริ่มต้นเพื่อพิสูจน์ไอเดียก็ได้

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

    • สงสัยว่าการใช้ LLM กับไบต์โค้ด Python มีข้อดีอะไรไหม
      จากประสบการณ์ ไบต์โค้ด Python เป็นระดับสูงพอที่จะ แปลงกลับเป็นซอร์สโค้ดได้โดยตรง
    • สงสัยว่าทำไมต้องเป็น Python
      Python มีอีโคซิสเต็มไลบรารีโอเพนซอร์สขนาดใหญ่ก็จริง แต่ไม่คิดว่ามันถูกใช้มากนักในซอฟต์แวร์ที่แจกจ่ายในรูปแบบไบนารี
    • มี PyLingual อยู่ แต่เสียดายที่ไม่ใช่โอเพนซอร์ส
      และก็ไม่แน่ใจด้วยว่าเป็น LLM-based หรือไม่
    • งานดีคอมไพล์ดูเหมือนจะไปหนักทาง C มากกว่า
      ดูเหมือนจะมีโปรเจกต์ Python ที่คอมไพล์เป็นไบนารีไม่มากนัก

  • เคยวางแผนว่าจะลองทำอะไรแบบนี้อยู่
    สักวันหนึ่งคงมีใครสักคนทำ pipeline แบบ อินพุตไบนารี → เอาต์พุตซอร์สโค้ดที่ดี ได้สำเร็จ แต่คิดว่าน่าจะยังต้องใช้เวลาอีกหลายปี
    เหตุผลที่คิดแบบนั้นคือปลายทางของปัญหานี้ดูไม่ได้มีกองเงินก้อนใหญ่รออยู่มากนัก แต่อาจคิดผิดก็ได้
    วิธีชั่วคราวที่ดีคือสร้าง pipeline ดีคอมไพล์ที่รัน Ghidra ในโหมด headless แล้วผสานความถูกต้องทางไวยากรณ์อันเข้มงวดของดีคอมไพเลอร์เข้ากับความสามารถเชิงสัญชาตญาณของ LLM
    คล้าย AlphaGeometry คือดีคอมไพเลอร์กับ LLM ควรชดเชยจุดอ่อนของกันและกัน: https://deepmind.google/discover/blog/alphageometry-an-olymp...
    นอกจากนี้ยังต้องมีวิธีใช้สิ่งอย่าง AICI เป็นกาวเชื่อม เพื่อประสานการสร้างซอร์ส C: https://github.com/microsoft/aici
    แทนที่จะใช้ค่าน้ำหนักของ LLM ไปกับการสร้างซอร์ส C ที่ถูกต้องตามไวยากรณ์ ควรให้มันคิดเรื่องชื่อตัวแปร รูปแบบของ snippet และการเลือกสถาปัตยกรรม แล้วให้เครื่องมืออย่าง Ghidra หรือ LLVM จัดการส่วนที่เหลือจะดีกว่า
    นี่เป็นคอมเมนต์แบบนั่งเทียนของอดีตนักศึกษาบัณฑิตที่ค่อนข้าง hand-waving แต่การที่นักวิจัยเหล่านี้ลงมาลุยก็น่าทึ่ง และจากที่ผู้เขียนพูดถึงการผสาน Ghidra ในงานอนาคต ก็ทำให้ดูเหมือนว่าทิศทางถูกต้องแล้ว

  • น่าสนใจที่ โมเดล 6 พันล้านพารามิเตอร์ ทำได้ดีกว่าโมเดล 33 พันล้าน
    สงสัยว่านี่หมายความว่าโมเดล 33 พันล้านต้องการข้อมูลฝึกมากกว่านี้หรือไม่
    ถ้าเทียบโมเดลที่ pretrain ด้วยโปรแกรม C ประมาณ 1 ล้านโปรแกรม กับ DeepSeek-Coder ที่ฝึกในระดับหลายล้านล้านโทเคน ปริมาณข้อมูลต่างกันหลายลำดับขั้น
    และก็สงสัยด้วยว่าถ้าเทียบกับวิธีแก้ที่ไม่ใช่ LLM จะเป็นอย่างไร

    • แนวโน้มแบบนี้เกิดขึ้นใน LLM มาสักพักแล้ว
      LLM ส่วนใหญ่ ฝึกมาน้อยเกินไป อย่างมาก และโมเดล 7 พันล้านเป็นหนึ่งในโมเดลกระแสหลักที่ฝึกมาน้อยเกินไปน้อยกว่าตัวอื่น จึงแพร่หลายในชุมชน fine-tuning ของ LLM
    • การฝึกโมเดล 33 พันล้านไม่ใช่เรื่องง่าย
      ใน การ fine-tuning แบบไร้เดียงสา ที่ใช้วิธีมาตรฐานตรง ๆ การฝึกโมเดลใหญ่ทำได้ยาก และไม่ใช่แค่ปริมาณข้อมูลเท่านั้น แต่ทุกอย่างตั้งแต่การคัดกรองข้อมูล, learning rate, ไปจนถึง decay ล้วนส่งผลต่อสมรรถนะสุดท้าย
    • สงสัยว่าจะเอาโปรแกรม C ประมาณ 1 ล้านโปรแกรมไปเทียบกับ 2 ล้านล้านโทเคนแบบตรง ๆ ได้หรือไม่
      ถ้าจะทำเช่นนั้นต้องสมมติว่าขนาดเฉลี่ยของโปรแกรม C เหล่านั้นเล็กกว่า 2 ล้านโทเคนอยู่หลายลำดับขั้น ซึ่งในความเป็นจริงอาจเป็นเช่นนั้นได้ แต่ฟังดูเป็นสมมติฐานที่ค่อนข้างมองโลกในแง่ดี

  • สงสัยว่าถ้าสำเร็จแล้ว จะเท่ากับการ ทำสำเนา 1:1 ของโค้ดภาษาเครื่องจากคอมไพเลอร์หรือไม่
    ถ้าใช่ ก็หมายความว่าโค้ดที่สมบูรณ์อาจมีอยู่ใน latent space ในรูปของการแจกแจงความน่าจะเป็น
    หรือที่น่าจะเป็นไปได้มากกว่าคืออาจเป็นการทำซ้ำเฉพาะตรรกะ แล้วแปลไปเป็นภาษาเป้าหมาย
    ไบนารีที่ต้องใช้อินพุตแบบไม่กำหนดตายตัวในการคอมไพล์ เช่น key หรือ hash น่าจะพัง
    น่าสนใจจริง ๆ

  • น่าประหลาดใจที่ GPT-4 ยังทำได้ค่อนข้างดีในการเปรียบเทียบ
    มันสร้างโค้ดที่คอมไพล์ได้ดีกว่าโมเดลนี้มาก แต่ความแม่นยำในการสร้าง โค้ดที่ทำงานถูกต้อง ซ้ำนั้นต่ำกว่า
    ถึงอย่างนั้นก็ยังน่าประทับใจทีเดียว

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