OpenAI แสดงประสิทธิภาพน่าทึ่งในการกู้โค้ดกลับจากโค้ดที่ถูกย่อ (Unminifying)

 (glama.ai)
3 คะแนน โดย GN⁺ 2024-08-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาคนหนึ่งต้องการทำความเข้าใจการทำงานของ คอมโพเนนต์ ASCII art ที่เห็นบนเว็บ จึงนำ JavaScript ที่ถูกย่อไปใส่ใน ChatGPT และมันก็คลี่โครงสร้างที่อ่านได้ออกมาจากลำดับการทำงานที่ดูสับสน
  • ต้นฉบับเป็น React คอมโพเนนต์ที่คำนวณจำนวนคอลัมน์และแถวตามขนาดหน้าต่าง แล้วอัปเดตกริดสตริงที่ 60fps ด้วย setInterval
  • ChatGPT อธิบายการเลือกชุดอักขระ การคำนวณอักขระจากพิกัดและเวลา และลำดับการอัปเดต div.textContent ก่อนจะเขียนใหม่เป็น โค้ด TypeScript/React ที่เทียบเท่ากัน
  • ตอนแรกคิดว่าการทำงานต่างจากเดิมเพราะไม่มีอักขระบล็อกอย่าง ░▒▓█ แต่เมื่อตรวจสคริปต์ต้นฉบับอีกครั้งก็พบว่าเป็น ปัญหา encoding จากการคัดลอกและวาง
  • เมื่อแก้ให้ใช้ชุดอักขระที่ถูกต้องแล้ว ผลลัพธ์ก็เหมือนกับคอมโพเนนต์ต้นฉบับ แสดงให้เห็นว่า ChatGPT ใช้งานได้จริงในการทำความเข้าใจและสร้างโค้ดที่ถูกย่อขึ้นใหม่

ค้นหาการทำงานของ ASCII art จาก JavaScript ที่ถูกย่อ

  • ตรวจดูซอร์สโค้ดเพื่อหาว่า บล็อก ASCII art บนหน้า reactive.network hackathon ถูกสร้างขึ้นอย่างไร
  • โค้ดที่เกี่ยวข้องถูกย่อไว้จนมนุษย์อ่านได้ยากทันที และโดยทั่วไปแล้วสถานการณ์แบบนี้มักต้องถอดเองหรือหาไฟล์ .map เพื่อกู้ซอร์สต้นฉบับกลับมา
  • ครั้งนี้จึงลองวางโค้ดที่ถูกย่อทั้งหมดลงใน ChatGPT แล้วขอให้อธิบายว่าโค้ดทำงานอย่างไร

โครงสร้างที่มองเห็นได้จากโค้ดที่ถูกย่อ

  • โค้ดนี้ใช้ JavaScript และ React เพื่อสร้างเนื้อหาข้อความแบบไดนามิก
  • องค์ประกอบหลักมีดังนี้
    • ใช้นามแฝงสั้น ๆ ให้กับฟังก์ชันคณิตศาสตร์อย่าง Math.floor, Math.abs, Math.min
    • มี ชุดอักขระ ที่ประกอบด้วย "reactive.network REACTIVE.NETWORK" และอักขระพิเศษกับอักขระบล็อก
    • เลือกชุดอักขระที่จะใช้ตามผลลัพธ์ของ Date.now() % 3
    • คำนวณดัชนีอักขระที่จะแสดงในแต่ละพิกัดจากความยาวของชุดอักขระที่เลือก
  • ฟังก์ชันหลัก eT รับค่าพิกัดตำแหน่งและค่าเวลา แล้วคืนค่าอักขระที่จะแสดงออกมาหนึ่งตัว
    • ค่าเวลาถูกแปลงเป็น t.time * 8e-5
    • ปรับพิกัดโดยอาศัยค่าที่น้อยกว่าระหว่างจำนวนคอลัมน์กับแถว รวมถึงอัตราส่วนหน้าจอ
    • ใช้ผลของ Math.cos(position.x * position.x - position.y * position.y) ร่วมกับค่าเวลาเพื่อกำหนดดัชนีอักขระ

วิธีเรนเดอร์ของ React คอมโพเนนต์

  • คอมโพเนนต์อ้างอิง div ที่จะใส่ข้อความด้วย useRef และเก็บค่า height กับ width ของหน้าต่างไว้ด้วย useState
  • useEffect ตัวแรกตั้งค่าขนาดเริ่มต้นจาก window.innerHeight, window.innerWidth และอัปเดตขนาดเมื่อเกิดอีเวนต์ resize
  • useEffect ตัวที่สองคำนวณขนาดของกริด ASCII จากขนาดหน้าจอ
    • cols คือ Math.floor(width / 12) * 1.6
    • rows คือ Math.floor(height / 12)
    • aspect คือ cols / rows
  • setInterval ทำงานทุก 1_000 / 60 เพื่อสร้างสตริงใหม่ให้ตรงกับ 60fps
  • ในแต่ละเฟรม มันจะวนครบทุกแถวและคอลัมน์เพื่อต่ออักขระที่คำนวณได้เข้าด้วยกัน แล้วใส่สตริงสุดท้ายลงใน element.textContent

เขียนโค้ดใหม่ให้อ่านง่ายด้วย TypeScript

  • จากนั้นนักพัฒนาขอให้สร้างโค้ดที่เทียบเท่ากันใน TypeScript แต่ทำให้อ่านง่ายสำหรับมนุษย์
  • โค้ดที่ ChatGPT สร้างขึ้นคลี่ความหมายของโค้ดที่ถูกย่อออกมาเป็นชื่อต่อไปนี้
    • selectedCharacterSet
    • characterSetLength
    • calculateCharacter
    • ชนิด Size
    • React คอมโพเนนต์ AsciiArtGenerator
  • ชื่อตัวแปรที่เข้าใจยากถูกเปลี่ยนเป็นชื่อที่สะท้อนเจตนาของการทำงาน
    • calculateCharacter คำนวณอักขระที่ต้องแสดงจากพิกัด จำนวนคอลัมน์และแถว อัตราส่วนหน้าจอ และค่าเวลา
    • textRef ชี้ไปยัง div ที่จะใช้แสดงข้อความจริง
    • size และ setSize แทนสถานะของขนาดหน้าต่าง
  • โค้ดที่เขียนใหม่อ่านง่ายกว่าโค้ดที่ถูกย่อเดิมมาก และเพียงพอสำหรับเรียนรู้วิธีสร้างคอมโพเนนต์ดังกล่าว

ความเข้าใจผิดเรื่องอักขระหายและปัญหา encoding

  • ในการเปรียบเทียบช่วงแรก ดูเหมือนว่า LLM จะพลาดรายละเอียดการทำงานบางส่วน
  • โดยเฉพาะมีการตัดสินว่าอักขระอย่าง ░▒▓█ ที่เห็นในคอมโพเนนต์ต้นฉบับหายไปจากผลลัพธ์ของ ChatGPT
  • ต่อมาผู้ใช้ในฟอรัม HN ชี้ว่าอาจเป็น ปัญหาจากการคัดลอกและวาง และเมื่อตรวจเพิ่มก็พบว่าในโค้ดต้นฉบับมีอักขระต่างจากที่ถูกวางเข้าไปใน ChatGPT
  • เมื่อลองดาวน์โหลดสคริปต์โดยตรงก็ได้อักขระที่ถูกต้อง และยืนยันได้ว่าสาเหตุของปัญหาคือ ความต่างของ encoding
  • หลังแก้ชุดอักขระแล้ว ผลลัพธ์ที่แสดงออกมาก็เหมือนกับคอมโพเนนต์ต้นฉบับ

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

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

 
GN⁺ 2024-08-30
ความเห็นจาก Hacker News

  • ฉันเป็นคนทำ HumanifyJS และได้สร้างเครื่องมือที่ใช้ LLMแยกต่างหากสำหรับงานลักษณะนี้
    ใช้ LLM ในระดับ AST เพื่อรับประกันว่าโค้ดยังคงทำงานต่อได้แม้หลังจากคลายการทำให้อ่านยากแล้ว: https://github.com/jehna/humanify

    • สงสัยว่าจะเพิ่มฟีเจอร์ตั้งชื่อใหม่ทั้งหมดตั้งแต่ต้นได้ยากไหม
      หมายถึงฟีเจอร์ที่ลบชื่อที่มีความหมายของผู้ใช้ออกจากโค้ดทั่วไปทั้งหมด แล้วเลือกชื่อใหม่จากอัลกอริทึมและชื่อที่ยังเหลืออยู่ เช่นชื่อ built-in
      ตอนรีแฟกเตอร์ฉันบางครั้งก็ใช้ LLM ทำแบบ manual และมันมีประโยชน์ในการหาคำที่เป็นมาตรฐานมากกว่าอย่าง antiparallel_line แทน parallel_line_opposite_direction หรือเจอชื่อที่ทำให้เป็นนามธรรมได้มากขึ้นอย่าง find_instance_in_list แทน find_animal_instance_in_animals
    • ควรมีเครื่องมืออีกมากที่สร้างบนพื้นฐานของAST, งานยอดเยี่ยมมาก
      พูดตามตรง ฉันยังคงรอระบบจัดการเวอร์ชันในระดับ AST อยู่
    • สงสัยว่าคุณถามอะไรกับ LLM
      เป็นวิธีให้ทั้งฟังก์ชันแล้วถามว่า “ควรเปลี่ยนชื่ออะไรบ้าง?” ซ้ำไปเรื่อยๆ จนกว่าจะเปลี่ยนครบทั้งหมด หรือสั่งทั้งชุดในครั้งเดียวแล้ว parse output และตรวจว่า AST ยังตรงกันอยู่หรือเปล่า
    • สงสัยว่ามันทำงานกับไฟล์ขนาดใหญ่มากได้ไหม
      หมายถึงประมาณ 50,000 บรรทัด
      แก้ไข: ตอนนี้กำลังลองรันไฟล์ JS ขนาดแค่ 1.2k บรรทัดในโหมด openai และผ่านไป 20 นาทีแล้วยังเสร็จแค่ 70% เท่านั้น ในทางทฤษฎีถึงจะใช้กับไฟล์ 50,000 บรรทัดได้ ก็คงไม่ควรลอง

  • การบีบอัด JS ค่อนข้างเป็นเชิงกลและเรียบง่าย ดังนั้นงานย้อนกลับก็ควรจะค่อนข้างง่ายด้วย
    แน่นอนว่าโดยทั่วไปมันน่าเบื่อพอสำหรับมนุษย์ที่จะทำเอง แต่ตัวการแปลงมีข้อจำกัดมากพอสมควร จนถ้ามีโน้ตไว้ตามตัวระบุที่ถูกทำให้อ่านยาก ก็ยังพออ่านได้
    แต่การคลายการบีบอัดหรือการคลายการทำให้อ่านยากในกรณีทั่วไปก็ดูเหมือนยังเป็นปัญหาที่เปิดอยู่ ฉันเคยเขียนโปรแกรมที่จงใจทำให้อ่านยากไว้ไม่กี่ตัว และจากประสบการณ์ของฉัน ChatGPT ยังเข้าใจไม่ได้แม้แต่ในระดับผิวเผิน
    ตัวอย่างเช่น เคยมีคอมเมนต์ที่ใช้ GPT-4 พยายามอธิบายโค้ดใน gist ที่เป็นอินเทอร์พรีเตอร์ Brainfuck เขียนด้วย C ขนาด 160 ไบต์ [1] และ “เวอร์ชันที่ทำให้ชัดเจนขึ้น” นั้นแทบไม่เหมือนโค้ดต้นฉบับเลย
    [1] https://gist.github.com/lifthrasiir/596667#gistcomment-47512...

    • แค่งานหนึ่งทำได้ง่าย ไม่ได้แปลว่างานย้อนกลับของมันจะต้องง่ายด้วย
      ตัวอย่างเช่น การคูณ/การแยกตัวประกอบเฉพาะ, การหาอนุพันธ์/การหาอินทิกรัล, การจำอดีต/การทำนายอนาคต
      การคลายโค้ดที่ถูกทำให้อ่านยากชัดเจนว่าเป็นหนึ่งในปัญหาย้อนกลับที่ยากแบบนี้ และอาจยิ่งยากขึ้นได้ง่ายจากบั๊ก, รูทีนที่ไม่ได้ใช้หรือไม่เกี่ยวข้อง, และ implementation ที่ผิดแต่บังเอิญให้ผลลัพธ์ถูก
      ในแง่นั้น ถ้า ChatGPT ให้ผลที่ใช้ได้ในการคลายโค้ดที่ถูกทำให้อ่านยากก็นับว่าเป็นเรื่องดี ไม่ใช่สิ่งที่ควรคาดหวังได้โดยปริยายตั้งแต่แรก การใช้ปัญหาที่ยากกว่านี้เพื่อดูข้อจำกัดของ ChatGPT ก็เป็นเรื่องดี แต่ผมคิดว่าสิ่งที่ค้นพบคือเพียงขีดจำกัดด้านบนเท่านั้น ผมไม่มองว่าตัวอย่างในต้นฉบับเป็นเรื่องเล็กน้อย
    • การเปลี่ยน let userSignedInTimestamp = new Date() เป็น let x = new Date() นั้นง่ายมาก แต่การย้อนกลับต้องอ่านและทำความเข้าใจโค้ดรอบๆ เพื่อดูว่า x ถูกใช้ในบริบทไหน
      ยิ่งไปกว่านั้น โค้ดส่วนที่เหลือก็ถูกบีบอัดอยู่ด้วย จึงยากขึ้น และถึงจะทำถูกทั้งหมด มันก็ยังเป็นการแปลงแบบสูญเสียข้อมูล เพราะชื่อตัวแปรอาจบรรจุลักษณะที่ไม่ได้ระบุไว้ในโค้ดอย่างชัดเจน
    • การเปลี่ยนภาพสีให้เป็นขาวดำอาจค่อนข้างง่าย แต่การย้อนกลับไปเป็นสีเดิมไม่ง่ายนัก
      นั่นเป็นเพราะข้อมูลบางส่วนหายไประหว่างกระบวนการ
      การบีบอัดก็ทำงานแบบเดียวกัน ข้อมูลจำนวนมากที่จำเป็นต่อการเข้าใจโค้ดหายไป และการกู้ข้อมูลนั้นกลับมาทำได้ยากมาก
    • การเปลี่ยนชื่อตัวแปรที่อธิบายความหมายได้อย่าง timeFactor ให้เป็น i ที่สั้นกว่ามากอาจเป็นขั้นตอนที่เป็นเชิงกลและเรียบง่าย แต่กระบวนการนี้ทำลายข้อมูลและย้อนกลับได้ไม่ง่ายนัก
      อันที่จริงทำไม่ได้เลยหากไม่มีความเข้าใจที่ค่อนข้างลึกว่าโค้ดทำอะไร และนี่แหละคือส่วนที่ LLM ทำได้ ซึ่งไม่ได้น่าประหลาดใจแต่ก็เจ๋งมาก ท่าทีที่รีบลดคุณค่ามันทันทีนั้นไม่น่าชอบนัก
    • ลองสุ่มครั้งแรกด้วย Claude 3.5 Sonnet: https://claude.site/artifacts/246c1b1a-3088-447a-a526-b1e716...
      ยังไม่ได้ทดสอบเพราะไม่ได้อยู่บน PC

  • ในหัวข้อไม่ควรใช้ชื่อบริษัทอย่าง OpenAI แต่ควรใช้ChatGPTหรือชื่อโมเดลอย่างGPT-4มากกว่าหรือ?

    • พอนึกถึงว่า OpenAI เอา GPT ซึ่งเคยเป็นคำเทคนิคทั่วไปไปทำเป็นแบรนด์ การใช้ OpenAI เหมือนเป็นชื่อผลิตภัณฑ์ก็มีความยุติธรรมเชิงประชดอยู่ระดับหนึ่ง

  • LLM โดดเด่นมากในด้านการแปลงข้อความ
    นี่คือจุดแข็งหลัก แต่ดูเหมือนจะยังไม่ได้ถูกใช้อย่างเต็มที่

    • ไม่ใช่แค่เป็นจุดแข็งหลักเท่านั้น แต่นั่นคือสิ่งที่ทรานส์ฟอร์เมอร์ถูกออกแบบมาให้ทำ และถ้าจะเถียงกันแบบสุดโต่ง ก็อาจมองได้ว่ามันทำได้แค่นั้น
      ความสามารถอื่นอย่างการให้เหตุผลหรือการเก็บรักษาความรู้ ก็เป็นเพียงผลข้างเคียงของความสามารถเหนือมนุษย์ในการสร้างข้อความซ้ำขึ้นมาใหม่โดยไม่ได้ “เข้าใจ” ความหมายที่ตั้งใจสื่อ
    • มันเก่งเป็นพิเศษกับงานแปลงแบบแทบจะเชิงเส้น ที่ลำดับไม่ได้เปลี่ยนมากและไม่จำเป็นต้องพิจารณาความสัมพันธ์ระหว่างรายการอย่างลึกซึ้ง
      เช่น มันอาจเรียงลำดับรายการไม่ได้ แต่แปลภาษาได้ เพราะรายการที่เรียงเกือบถูกนั้นถือว่าผิด แต่คำแปลที่เกือบถูกเรามักยอมรับกันได้
    • ถ้ามีเครื่องมือที่เหมาะสมพ่วงเข้าไป ก็น่าจะย้ายโค้ดเบสไปยังภาษาและเฟรมเวิร์กอื่นได้แทบจะด้วยการกดปุ่มครั้งเดียว
      ถ้าทีมกำลังชั่งใจว่าคุ้มไหมที่จะเปลี่ยนโค้ด Python ก้อนใหญ่ไปเป็น Elixir ก็ไม่จำเป็นต้องเดาอีกต่อไป
      ไม่นานมานี้ฉันลองแปลสคริปต์ Python เป็น JavaScript แล้วผลออกมาไร้ที่ติ และถ้ามี guardrail เพิ่มอีกนิดก็น่าจะขยายสเกลได้
    • นี่ไม่ใช่กรณีใช้งานหลักในภาคธุรกิจอยู่แล้วหรือ?
      พวกเราใช้มันหลัก ๆ เพื่อดึงข้อมูลที่มีโครงสร้างออกมาจากรูปแบบอื่น
    • ปัญหาคือมันต้องเป็นกรณีที่ไม่ต้องกังวลกับความเสี่ยงจากอาการหลอน หรืออย่างน้อยก็เป็นกรณีที่แม้จะไม่มีข้อมูลในรูปแบบที่ใช้งานได้อยู่แล้ว ก็ยังตรวจสอบผลลัพธ์ได้
      แถมยังต้องไม่มีความรู้หรือทักษะที่จะจัดการได้เร็วกว่าด้วย awk, Python, Perl ฯลฯ

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

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

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

    • นี่ก็แค่การแปลงข้อความ
      คุณแน่ใจหรือว่าบนเว็บไม่มีคู่โค้ดบีบอัดกับไม่บีบอัดอยู่มากนัก? มันสร้างจาก JS เดิมได้ง่ายเพื่อใช้เป็นชุดฝึก และโค้ด JS แบบไม่บีบอัดที่ถูกใช้ฝึกก็มหาศาลอยู่แล้ว
    • ฉันมอง AI ในแง่บวกนะ แต่ไม่แน่ใจว่านี่เป็นตัวอย่างของปรากฏการณ์ที่พูดถึงหรือเปล่า
      เหตุผลที่มนุษย์เข้าใจโค้ดบีบอัดได้ยาก ก็เพราะชื่อตัวแปรที่กำกวม ลูปที่ดูประหลาด ช่องว่างที่ถูกย่อ ฯลฯ แต่คอมพิวเตอร์ไม่ได้ลำบากกับสิ่งเหล่านี้ และนั่นก็เป็นเหตุผลที่เราบีบอัดโค้ดตั้งแต่แรกด้วยซ้ำ โครงสร้างแบบattentionควรทำงานพวกนี้ได้ดี
      ฉันคิดว่าคู่โค้ดบีบอัด/ไม่บีบอัดก็น่าจะมีเยอะมากด้วย จุดประสงค์ของไฟล์ source map ก็คือสิ่งนี้เอง เมื่อดูจากที่ OpenAI ลงทุนกับการท่องเว็บและการพัฒนาซอฟต์แวร์ ก็ไม่น่าแปลกถ้าข้อมูลฝึกจะมีข้อมูลบีบอัด/ไม่บีบอัดรวมอยู่ด้วย
    • ฉันไม่ได้เชี่ยวชาญเรื่อง AI หรือการทำความเข้าใจสติปัญญา แต่เราจะพูดได้ไหมว่าเครื่องคิดเลขพกพาเข้าใจเลขคณิตอย่างแท้จริงและมีความสามารถด้านสติปัญญาเหนือมนุษย์เช่นกัน?
    • ทำไมเราไม่ควรนับความจริงที่ว่ามนุษย์สร้างเครื่องมือที่ช่วยในการถอดบีบอัดเข้าไปในคะแนนของมนุษย์ด้วยล่ะ?
      การที่คอมพิวเตอร์คูณเลข 1000 หลักได้ทันที ก็เป็นกรณีที่มนุษย์สร้างเครื่องมือนั้นขึ้นมาก่อนและทำให้การคูณสำเร็จ แล้วตรงนั้นมีอะไรที่สำเร็จเชิงสติปัญญาอีก? คอมพิวเตอร์ก็ไม่ได้สร้างตัวมันเองขึ้นมาด้วย
      ถ้าเราจะลากเส้นขอบเขตของสติปัญญามนุษย์ไว้แค่กะโหลกศีรษะ และไม่นับเครื่องมือที่สติปัญญานั้นสร้างและใช้งานเป็นส่วนหนึ่งของกระบวนการแก้ปัญหา เราก็ต้องยอมรับด้วยว่ามนุษย์ไม่ได้ฉลาดพอจะบินสู่อวกาศ ทำการผ่าตัด หรือปรุงอาหารส่วนใหญ่ที่กินกันอยู่ได้
    • GPT-4 ได้บริโภคโค้ดมากกว่าที่บรรพบุรุษทั้งหมดของคุณเคยเห็นตลอดชีวิต และเข้าใจรูปแบบแฝงภายในระหว่างโค้ดกับเวอร์ชันที่ถูกบีบอัด
      การที่มันมองเห็นรูปทรงนามธรรมของโค้ดที่ชื่อตัวแปรหายไป แล้วจับคู่กับชื่อตัวแปรที่มนุษย์อ่านออกจากแพตเทิร์นคล้ายกันที่มันเคยเห็นทั่วอินเทอร์เน็ตขนาดใหญ่ ก็ไม่ได้ฟังดูเหลือเชื่ออะไร

  • น่าสนใจ และดูเหมือนว่ามันดีขึ้นมาก
    เมื่อปีกว่า ๆ ก่อน ฉันได้รับอีเมลขอให้ช่วยดูปลั๊กอินแบบคัสตอมของเว็บ WordPress ที่ถูกแฮ็ก และพยายามใช้ GPT กับการถอดความกำกวมของมัลแวร์ ตอนนั้นการไล่โค้ดด้วยตัวเองทีละขั้นกลับคืบหน้าได้ดีกว่ามาก
    พออ่านโพสต์นี้แล้วก็ลองอีกครั้ง [0] มันให้คำอธิบายที่พอเข้าใจได้ แต่โค้ดถูกทำให้อ่านยากถึงระดับที่แทบจะเป็นการ eval สตริงที่อ่านผ่านออบเจ็กต์ Window ไม่ได้ ดังนั้นแค่นั้นยังไม่พอ
    ส่วนหนึ่งของรายงานที่ฉันส่งไปตอนนั้นมีใจความประมาณว่า: ฉันสามารถขุดเข้าไปในโค้ด JavaScript ที่ถูกทำให้อ่านยากอย่างหนัก ตรวจจับการโหลดหน้าเว็บ แกะตรรกะที่เรียกใช้ฉากหน้าของการคำนวณซึ่งตามทฤษฎีแล้วควรเป็นค่าคงที่ และพบกลไกที่รีไดเรกต์หน้าไปยังเว็บไซต์อันตราย
    [0] https://chatgpt.com/share/f51fbd50-8df0-49e9-86ef-fc972bca6b...

  • มีใครกำลังทำ LLM สำหรับ decompiler อยู่ไหม?
    ดูเหมือนว่าจะทำให้โค้ดทั้งหมดกลายเป็นโอเพนซอร์สได้
    ในกรณีนี้ ข้อมูลฝึกสร้างได้ง่าย แค่เอาโค้ดฟรีบน GitHub มาสร้างบิลด์จำนวนมากด้วยคอมไพเลอร์หลายตัว แล้วฝึกให้ย้อนการคอมไพล์กลับมาก็พอ เป็นกรณีที่ข้อมูลฝึกแบบสังเคราะห์เหมาะสมและสร้างได้ค่อนข้างง่าย
    ให้ decompiler เรียนรู้แค่การย้อนการคอมไพล์ ส่วนงานอย่างการเพิ่มคอมเมนต์ก็ใช้ code LLM ขนาดใหญ่ที่มีอยู่แล้วได้

    • ผลกระทบที่เป็นไปได้มหาศาลมาก
      ไม่ใช่แค่การทำให้เป็นโอเพนซอร์สเท่านั้น แต่ยังจินตนาการได้ถึงการ decompile และแก้ไขแอปแบบ proprietary ได้ง่าย เพื่อแก้บั๊กหรือเพิ่มฟีเจอร์ โดยเฉพาะกับโปรแกรมเก่าที่ตายไปนานแล้ว มันอาจเป็นการปลดปล่อยครั้งใหญ่
      ด้วยเหตุผลทางกฎหมาย ฟังก์ชันลักษณะนี้มีโอกาสสูงที่จะกลายเป็น ความสามารถที่ถูกบล็อก ในโมเดลหลัก
    • การมีซอร์สเป็นแค่ขั้นแรก และยังต้องมี สิทธิ์ ในการอ่าน แก้ไข รัน และเผยแพร่โค้ดที่แก้ไขแล้วด้วย
      สิทธิเหล่านั้นมีแต่ผู้เขียนโค้ดเท่านั้นที่มอบให้ได้
    • เห็นด้วย ผมมองว่า “AI สร้าง/เข้าใจซอร์สโค้ดได้” เป็น เหยื่อล่อให้ไขว้เขว ชิ้นใหญ่
      ถ้า AI เข้าใจโค้ดได้ดีจริง มันก็ควรสร้างหรือแก้ไบนารีได้เลย
      ผมเชื่อว่าถ้ามี AI โปรแกรมเมอร์ตัวจริงเกิดขึ้น มันจะไม่สนโค้ดที่มนุษย์อ่านได้ และจะเขียนทุกอย่างเป็นภาษาเครื่องทั้งหมด ถ้าได้รับงานให้ดูแลระบบเดิม มันก็คงจะเข้าใจทั้งซอฟต์แวร์และฮาร์ดแวร์สแตกทั้งหมดแบบยกชุด
      คล้ายกับที่โมเดล diffusion สำหรับสร้างภาพไม่ได้สนใจจะเรียนรู้เทคนิคการวาดภาพจริง
    • มี LLM ที่ decompile จาก x86 ไปเป็น C อยู่: https://github.com/albertan017/LLM4Decompile
    • การคลายการบีบอัดไม่ใช่ decompile
      มันใกล้เคียงกับการเปลี่ยนชื่อตัวแปรและฟังก์ชัน แล้วใส่ขึ้นบรรทัดใหม่มากกว่า

  • มันคล้ายกับวิธีที่ผมใช้ LLM บ่อยมาก [0]
    เวลาที่ต้องอ่านโค้ดด้วยแรงตัวเอง ผมใช้มันเป็นขั้นแรกของการถอดความหมาย
    การโยนโค้ดสปาเกตตีที่เละเทะเข้าไป แล้วให้มันคลี่ออกให้อ่านง่ายขึ้นก่อนเริ่มต่อจากตรงนั้น เป็นอะไรที่รู้สึกปลดปล่อยมาก
    อย่างที่ผู้เขียนเจอ LLM บางครั้งก็พลาดรายละเอียด แต่จุดพวกนั้นผมตามเก็บเองได้
    อีกกรณีใช้งานคือเมื่อผมเข้าใจว่าโค้ดทำอะไร แต่ยังไม่ค่อยเข้าใจว่าทำไมมันถึงถูกเขียนแบบนั้น โดยเฉพาะเมื่อคนที่เขียนโค้ดนั้นไม่ได้อยู่บริษัทแล้ว ตอนนั้นผมจะเอาเมธอดใส่ในแชต LLM ให้มันอธิบายว่าทำอะไร แล้วถามต่อว่าทำไมบางอย่างถึงอาจถูกทำไว้แบบนั้น
    มันไม่ได้สมบูรณ์แบบเสมอไป แต่บ่อยครั้งก็ตอบออกมาได้สมเหตุสมผล ทนต่อการตรวจทาน และให้มุมมองใหม่ หนึ่งหรือสองครั้งมันยังช่วยกันไม่ให้ผมรีแฟกเตอร์ไปในทางที่จะกลายเป็นปัญหาทีหลังด้วย
    [0] ใช้ chatGPT และช่วงหลังใช้หลายโมเดลอื่นด้วย โดยหลักคือใช้ openwebUI เป็นฟรอนต์เอนด์กับ Claude รุ่นต่าง ๆ เพื่อดูความแตกต่าง และยังจัดชุดสนุก ๆ ให้โมเดลต่างตัวตรวจคำตอบของกันและกันได้ด้วย

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

    • การเปลี่ยนชื่อจริง ๆ ต้องใช้เครื่องมืออื่นอย่าง HumanifyJS: https://github.com/jehna/humanify
    • โค้ดที่คลายการบีบอัดแล้วดูเหมือนจะใกล้กับต้นฉบับพอสมควร
      ในบางกรณี ChatGPT ถึงขั้นทำ refactoring ของตัวเองเพิ่มจากการคลายการบีบอัดด้วย
      โค้ดต้นฉบับไม่ได้เรียก handleResize ทันที แต่เอาเนื้อหาของมันมา inline ไว้ น่าจะเป็นเพราะตัว minifier ทำ inlining จริง ๆ ความต่างที่แท้จริงเพียงอย่างเดียวตรงนี้คือเงื่อนไข if (typeof window < "u") หายไป
    • ตรงนั้นหมายถึงว่าเวอร์ชันที่ ChatGPT สร้างขึ้นมีอักขระบางตัวจากตัวอย่างต้นฉบับหายไป
      หมายถึงอักขระบล็อกโดยเฉพาะ ดูเหมือน HN จะไม่ยอมให้วางอักขระยูนิโค้ด เวอร์ชันต้นฉบับมองเห็นได้ แต่เวอร์ชันที่ ChatGPT สร้างไม่เห็น
      แต่ก็มีความเป็นไปได้มากเช่นกันว่าเป็นเพราะผมไม่ได้ใส่บริบทที่จำเป็นทั้งหมด
      การลดค่าผลลัพธ์ทั้งหมดเพียงเพราะมีอักขระหายไปไม่กี่ตัว ก็ดูจะเป็นการจับผิดแบบละเอียดเกินไป นอกเหนือจากนั้นสำหรับผม เอาต์พุตก็ดูเหมือนกัน
    • แถมยังสั่งให้ reimplement จาก JavaScript เป็น TypeScript ด้วย
      ถ้าสั่งแค่ให้เปลี่ยนชื่อตัวแปรกับชื่อเมธอด ก็น่าจะใกล้กับต้นฉบับมากกว่านี้