ห้ามใช้โค้ดที่ LLM สร้างในดีเพนเดนซี

 (joeyh.name)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตลอดหนึ่งเดือนที่ผ่านมา มีการใช้เวลาราว 100 ชั่วโมง เพื่อตรวจสอบให้แน่ใจว่า git-annex สามารถบิลด์ได้โดยไม่มี ดีเพนเดนซีที่มีโค้ดซึ่ง LLM สร้าง
  • งานนี้เผยให้เห็นความจริงที่ว่าต้องคอยติดตาม dependency tree ทั้งหมด อย่างต่อเนื่อง ไม่ใช่แค่โค้ดแต่ละส่วน ซึ่งเพิ่มภาระการบำรุงรักษาอย่างมาก
  • ระหว่างการตรวจสอบ พบกรณีอย่างการย้อนกลับการเปลี่ยนแปลงขนาดใหญ่ที่สร้างโดย LLM โดยไม่มีคำอธิบาย, การเปลี่ยน 10,000 บรรทัดในโค้ดเบสขนาด 26,000 LOC, และข้อความคอมมิตยาว 1,489 บรรทัดที่ไม่สอดคล้องกัน
  • แม้การได้ข้อมูลเพิ่มเกี่ยวกับ คุณภาพของดีเพนเดนซี จะเป็นเรื่องเชิงบวก แต่ก็ยังมีมุมมองที่กังขาต่อการรับมือในระดับองค์กรอย่าง Software Freedom Conservancy หรือ FSF
  • แม้ LLM จะช่วยเพิ่มการตั้งค่าหรือเปลี่ยนฟอร์แมตได้ง่าย แต่คอมมิตลักษณะนั้นอาจสร้างต้นทุนโดยตรงต่อความไว้วางใจในการทำงานร่วมกันและการมีส่วนร่วมในโปรเจกต์

การตรวจสอบดีเพนเดนซีของ git-annex

  • git-annex ใช้เวลาราว 100 ชั่วโมงตลอดประมาณหนึ่งเดือนเพื่อตรวจสอบให้บิลด์ได้โดยไม่มีดีเพนเดนซีที่มี โค้ดที่ LLM สร้าง
  • จนถึงตอนนี้ดูเหมือนว่าจะบรรลุเป้าหมายแล้ว
  • มีหน้าที่เกี่ยวข้องคือ git-annex no LLM code
  • แก่นของปัญหาอยู่ที่ภาระในการต้องตรวจสอบ dependency tree ทั้งหมด ของโปรแกรมอย่างต่อเนื่อง

กรณีที่พบระหว่างการตรวจสอบและผลกระทบ

  • กรณีที่ตรวจพบไม่ใช่แค่เรื่องรสนิยม แต่เชื่อมโยงไปถึงปัญหาด้านการบำรุงรักษาและความน่าเชื่อถือ
    • มีการ เปลี่ยนแปลงที่สร้างโดย LLM ขนาดใหญ่ซึ่งถูกย้อนกลับในรีลีสถัดไปโดยไม่มีคำอธิบายใด ๆ
    • มีการเปลี่ยน 10,000 บรรทัดในโค้ดเบสขนาด 26,000 LOC และข้อความคอมมิตมีความยาว 1,489 บรรทัดอย่างไม่สอดคล้องกัน
    • มี พรอมป์ต์ของ LLM ที่บอกให้คัดลอกโค้ดจากโปรเจกต์อื่น และดูเหมือนว่าโชคดีที่หลีกเลี่ยงการละเมิดลิขสิทธิ์มาได้
  • งานครั้งนี้ทำให้ได้ข้อมูลเพิ่มเติมเกี่ยวกับคุณภาพของดีเพนเดนซี และข้อมูลนี้อาจส่งผลต่อการตัดสินใจในอนาคต
  • ดูเหมือนว่า Software Freedom Conservancy จะ ข้ามประเด็นนี้ไป ในคำแนะนำเกี่ยวกับ generative AI ที่อิง LLM และก็ยังไม่แน่ชัดว่า FSF จะทำได้ดีกว่าหรือไม่
  • ท่ามกลางการเปลี่ยนแปลงเหล่านี้ มีการทบทวนการมีส่วนร่วมในคอมมูนิตี้ที่เกี่ยวข้อง แต่ยังคงทำงานและสนับสนุนผู้ใช้ต่อไป
  • การให้พรอมป์ต์กับ LLM เช่น Add fourmolu config and restyled, neat, format a module แล้วนำผลลัพธ์ไปคอมมิตอาจดูเหมือนเป็นวิธีที่ง่าย แต่ควรคำนึงถึง ผลกระทบในวงกว้าง ของพฤติกรรมนั้น

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

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

 
GN⁺ 3 시간 전
ความเห็นจาก Lobste.rs

  • วันนี้เพิ่งรู้ว่า git-annex เขียนด้วย Haskell ซึ่งเจ๋งดี

    ระหว่างนั่งรถไฟใต้ดินกลับบ้านวันนี้ คนข้าง ๆ เปิด YouTube Shorts ด้วยเสียงดังสุด ทำเอาน่าหงุดหงิดเพราะในขบวนที่เงียบและแน่นขนัดมันเป็นมลพิษทางเสียง
    ที่น่าหงุดหงิดยิ่งกว่าคือวิดีโอที่เขาดูกลับเป็นวิดีโอคุณภาพต่ำที่สร้างด้วย AI ทั้งหมด

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

    ไม่ใช่คำบ่นใหม่อะไร แต่เริ่มกวนใจมากขึ้นเรื่อย ๆ
    รู้สึกเหมือนเรากำลังสูญเสียส่วนสำคัญบางอย่างของ ความเชื่อมโยงแบบมนุษย์ ที่เคยทำให้งานและชีวิตสนุกและเติมเต็ม

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

    • ผมมองว่าสิ่งที่ LLM เปลี่ยนไปคือ ราคาเชิงสัมพัทธ์ของคุณภาพ
      ถ้าเปรียบกับบ้าน แต่ก่อนบ้าน McMansion แย่ ๆ ที่หลังคารั่วและฐานรากไม่ดีราคา 1000X ส่วนบ้านดี ๆ ที่ไม่มีปัญหาแอบแฝงราคา 2000X

      ตอนนี้ด้วยเทคโนโลยี LLM คนที่มีฝีมือสามารถโยนงานเชิงกลที่ตรวจสอบง่ายบางส่วนให้มันทำได้ จึงอาจลดราคาบ้านดี ๆ ลงมาเหลือ 1500X ในทางทฤษฎี
      แต่บ้าน McMansion ห่วย ๆ นั้นตกลงมาเหลือแค่ 100X

      ดังนั้นบ้าน McMansion คุณภาพต่ำเหล่านี้มีแนวโน้มสูงที่จะเบียดงานคุณภาพดีออกไปอย่างน่าเกลียด
      ผมไม่ได้อยากไปกวนใจช่างฝีมือที่ทำให้บ้านดี ๆ จาก 2000X เหลือ 1500X แต่ถ้าบ้านกาก ๆ ราคา 100X เข้ามาเบียดของที่ดีกว่าออกจากตลาดและสร้าง ตลาดเลมอน ลูกค้าอาจเริ่มไม่ไว้ใจซอฟต์แวร์โดยรวมมากขึ้นมาก
      ตลาดเลมอนนั้นน่าเกลียดเพราะผู้ซื้อไม่มีทางแยกคุณภาพออกจากขยะได้
      ตัวอย่างที่ดังที่สุดในโลกซอฟต์แวร์คือวิกฤตวิดีโอเกมปี 1983 ที่เกิดคลื่นเกมขยะมหาศาลจนลูกค้าจำนวนมากเข็ดและเลิกซื้อไปเลย

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

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

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

    จะโกงด้วยการไปหยิบ GitHub archive ช่วงต้นปี 2023 มาก็ได้คร่าว ๆ แต่ถ้าเป็น snapshot ของ commit ล่าสุดต่อโปรเจ็กต์แทนที่จะเป็น snapshot ของเวลาใดเวลาหนึ่งเฉย ๆ ก็น่าจะน่าสนใจกว่า
    ดูเหมือนจะมีผลลัพธ์น่าสนใจมากมายจากชุดข้อมูลแบบนี้ และยังช่วยคนที่อยากสร้าง ecosystem ด้วยซอฟต์แวร์ที่ไม่ใช้ LLM อย่างบทความนี้ด้วย

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

    • มีโปรเจ็กต์หนึ่งที่ใกล้เคียงกับการติดตาม เวอร์ชันล่าสุดที่ไม่ใช้ LLM แยกตามโปรเจ็กต์อยู่บ้าง
      คือ https://codeberg.org/ethical-foss/open-slopware ซึ่งดูแลโดยคนที่ต่อต้าน AI แบบจริงจัง
      บางโปรเจ็กต์มี “เวอร์ชันหรือ commit ID ล่าสุดที่ยังไม่ปนเปื้อน” แต่ไม่ได้ครอบคลุมทุกโปรเจ็กต์

  • เหตุผลที่ผมส่งบทความนี้มาก็เพราะชอบที่ผู้เขียนลงมือไล่ดู commit เฉพาะที่บ่งชี้การใช้ LLM ใน dependency ด้วยตัวเอง แล้วทำหน้าเพจสรุปสิ่งที่พบออกมา

    ส่วนตัวแล้วผมไม่แน่ใจว่าควรติดแท็ก vibecoding ไหม เพราะบทความนี้ดูเป็นเรื่องของ ชุมชนและแนวปฏิบัติ มากกว่าการ vibe coding

  • มีช่วงหนึ่งที่บอกว่า “ผมรู้ว่านี่อาจเป็นการพยายามหยุดกระแสน้ำที่ถาโถมเข้ามา”

    ถ้า คอมไพเลอร์ ที่โปรเจ็กต์พึ่งพาโดนผลกระทบเข้า ก็สู้ไม่ไหว
    ผมเองก็พยายามควบคุมความเสียหายอยู่ แต่สุดท้ายก็มาถึงจุดที่อีกทางเลือกแย่กว่าจนต้องยอมประนีประนอม

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

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

    นี่คือ ความล้มเหลวทางวิศวกรรมซอฟต์แวร์ ที่แยกจากการใช้ LLM หรือไม่ใช้ LLM

    อนึ่ง ผมชอบ Joey Hess และซอฟต์แวร์ของเขา และคิดว่าการมีส่วนร่วมด้านโค้ดควรถูกตัดสินจากคุณค่าของผลลัพธ์ ไม่ว่าจะสร้างด้วยเครื่องมืออะไร

  • วิธีอธิบายค่อนข้างน่าผิดหวัง
    commit ของ persistent ดูไม่น่าใช่สิ่งที่ LLM เขียน
    ผมอยากให้คนเลิกพูดว่า commit ทุกอันที่มี “Co-authored-by” เป็นของที่สร้างโดย LLM

    ลิงก์ yesod อันแรกเป็นการเปลี่ยนแปลง CI ดังนั้นผมไม่คิดว่ามันจะนับเป็นโค้ดที่นำไปพึ่งพา
    พอเขียนว่าเป็น “commit ที่สร้างโดย LLM พร้อมข้อความ commit ยาว 1489 บรรทัด” ผมนึกว่า commit เองคงหลุดโลกไปแล้ว แต่จริง ๆ มันเป็นการ squash merge ที่สมเหตุสมผล เพียงแต่ diff ใหญ่มากเท่านั้น

    commit ของ cabal ก็บอกว่า LLM สร้างแค่ตัวทดสอบ และผมก็ยังไม่แน่ใจว่าสิ่งนั้นควรถูกนับเป็นโค้ดที่ผมพึ่งพาหรือไม่
    ส่วน commit ของ git ก็เป็นแค่ CI

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