Tokenomics: การหาปริมาณว่ามีการใช้โทเคนตรงไหนบ้างในวิศวกรรมซอฟต์แวร์แบบเอเจนต์

 (arxiv.org)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • งานวิจัยที่แมป execution trace ของระบบพัฒนาซอฟต์แวร์หลายเอเจนต์ที่ใช้ LLM เข้ากับขั้นตอน SDLC เพื่อวัดโครงสร้างการใช้โทเคน ซึ่งพบว่าการใช้โทเคนไม่ได้กระจุกอยู่ที่การสร้างโค้ดตั้งต้น แต่ไปกระจุกที่ การรีวิวโค้ด และการตรวจสอบความถูกต้อง
  • จากซอฟต์แวร์เดเวลอปเมนต์ทาสก์ 30 งานที่ ChatDev ดำเนินการ พบว่าขั้นตอนรีวิวโค้ดใช้โทเคนเฉลี่ย 59.4% มากที่สุด
  • องค์ประกอบโทเคนเฉลี่ยของทุกทาสก์คือ input 53.9%, output 24.4%, reasoning 21.6% โดยการส่งต่อบริบทซ้ำๆ ระหว่างเอเจนต์ก่อให้เกิด communication tax ขนาดใหญ่
  • ขั้นตอนการเขียนโค้ดมีสัดส่วน output token สูงที่ 58.0% ขณะที่ขั้นตอนจัดทำเอกสารมีสัดส่วน input token สูงที่ 80.2% แสดงให้เห็นว่ารูปแบบการใช้โทเคนแตกต่างกันชัดเจนตามแต่ละช่วงของการพัฒนา
  • สรุปว่าจำเป็นต้องมีโปรโตคอลการทำงานร่วมกันของเอเจนต์ที่ใช้โทเคนได้มีประสิทธิภาพมากขึ้น และมีเฟรมเวิร์กการประเมินแบบมาตรฐาน เพื่อการคาดการณ์ต้นทุนและการปรับเวิร์กโฟลว์ให้เหมาะสม

บทคัดย่อ

  • ระบบหลายเอเจนต์ที่ใช้ LLM (LLM-MA) ถูกนำมาใช้มากขึ้นเรื่อยๆ เพื่อทำงานวิศวกรรมซอฟต์แวร์ที่ซับซ้อนให้เป็นอัตโนมัติ เช่น requirements engineering, การสร้างโค้ด, และการทดสอบ
  • แต่ประสิทธิภาพการดำเนินงานและการใช้ทรัพยากรยังไม่เป็นที่เข้าใจดีพอ ทำให้ต้นทุนและผลกระทบต่อสิ่งแวดล้อมคาดการณ์ได้ยาก ซึ่งเป็นอุปสรรคต่อการใช้งานจริง
  • งานนี้วิเคราะห์ execution trace ของซอฟต์แวร์เดเวลอปเมนต์ทาสก์ 30 งานที่เฟรมเวิร์ก ChatDev รันด้วย GPT-5 reasoning model และแมปขั้นตอนภายในเป็นขั้นออกแบบ, เขียนโค้ด, ทำโค้ดให้สมบูรณ์, รีวิวโค้ด, ทดสอบ, และจัดทำเอกสาร
  • ผลเบื้องต้นพบว่าขั้นตอนรีวิวโค้ดแบบวนซ้ำใช้โทเคนเฉลี่ย 59.4% มากที่สุด
  • input token คิดเป็นสัดส่วนมากที่สุดอย่างสม่ำเสมอที่ค่าเฉลี่ย 53.9% เป็นหลักฐานเชิงประจักษ์ว่าการทำงานร่วมกันของเอเจนต์อาจมีความไร้ประสิทธิภาพสูง
  • ต้นทุนหลักของวิศวกรรมซอฟต์แวร์แบบเอเจนต์ไม่ได้อยู่ที่การสร้างโค้ดตั้งต้น แต่กระจุกอยู่ที่กระบวนการปรับปรุงและตรวจสอบอัตโนมัติ
  • ระเบียบวิธีนี้สามารถนำไปใช้กับการคาดการณ์ต้นทุน การปรับเวิร์กโฟลว์ และการวิจัยโปรโตคอลการทำงานร่วมกันของเอเจนต์ที่ใช้โทเคนได้มีประสิทธิภาพมากขึ้น

บทนำ

  • วิศวกรรมซอฟต์แวร์ขนาดใหญ่กำลังสำรวจการใช้ระบบหลายเอเจนต์ที่อิง LLM เพื่อทำงานอัตโนมัติที่ซับซ้อนตลอดทั้ง SDLC
  • เฟรมเวิร์ก LLM-MA จำลองบทบาททีมมนุษย์ เช่น product manager, architect, developer, และ tester ด้วยเอเจนต์ LLM ที่เชี่ยวชาญเฉพาะด้าน และทำงานออกแบบ เขียนโค้ด และตรวจสอบแบบร่วมมือกัน
  • โดยหลักการแล้ว ระบบ LLM-MA สามารถแบ่งงานระหว่างเอเจนต์เพื่อเพิ่มความเป็นอิสระและความทนทานได้
  • งานวิจัยก่อนหน้านี้ชี้ว่าระบบ LLM-MA ช่วยส่งเสริม divergent thinking, เพิ่มความสามารถด้าน reasoning และ factuality และขยายไปสู่ปัญหาที่เกินความสามารถของเอเจนต์เดี่ยวได้
  • ในวิศวกรรมซอฟต์แวร์ มีความเป็นไปได้ที่จะทำเวิร์กโฟลว์แบบ end-to-end ตั้งแต่ requirements ไปจนถึง testing ให้เป็นอัตโนมัติในรูปแบบบูรณาการ
  • เฟรมเวิร์ก AGENTTAXO ให้ระบบจัดหมวดหมู่สำหรับวิเคราะห์การกระจายตัวของโทเคนในระบบ LLM-MA ทั่วไป และนำแนวคิด “communication tax” มาใช้อธิบายโอเวอร์เฮดจากการปฏิสัมพันธ์ระหว่างเอเจนต์
  • การจัดหมวดหมู่ความล้มเหลวของ MAST ยืนยันว่าปัญหาจำนวนมากในระบบ LLM-MA ไม่ได้มาจากข้อจำกัดของ LLM รายตัว แต่เกิดจากปัญหาด้านการออกแบบและการประสานงานของระบบ เช่น การวนซ้ำของขั้นตอนและการตรวจสอบที่ไม่สมบูรณ์
  • งานวิจัยเดิมวิเคราะห์พฤติกรรมของเอเจนต์ในบริบททั่วไป แต่ยังมีช่องว่างความรู้เรื่องประสิทธิภาพการใช้ทรัพยากรของระบบที่ถูกนำไปใช้กับเวิร์กโฟลว์วิศวกรรมซอฟต์แวร์หลายขั้นตอน
  • คำถามสำคัญต่อการใช้งานจริงว่า “โทเคนถูกใช้ไปที่ไหน” ยังได้รับคำตอบไม่เพียงพอในโดเมนวิศวกรรมซอฟต์แวร์
  • Tokenomics คือคำที่ใช้เรียกการศึกษาประสิทธิภาพการดำเนินงานและการใช้ทรัพยากรของระบบ LLM-MA
  • การวิเคราะห์นี้พิจารณาการกระจายการใช้โทเคนโดยแมปขั้นตอนภายในของ ChatDev เข้ากับขั้นตอนการพัฒนา
  • ChatDev จำลองบริษัทซอฟต์แวร์เสมือน โดยมีหลายบทบาทเอเจนต์ เช่น programmer และ tester ที่ทำ SDLC ให้เสร็จผ่านการสนทนาหลายรอบ
  • มีการเผยแพร่ชุดข้อมูล execution trace ที่คัดสรรแล้ว 30 รายการ พร้อม แพ็กเกจสำหรับทำซ้ำทั้งหมด

การออกแบบการวิจัย

  • เป้าหมายและขอบเขตการวิเคราะห์

    • เป้าหมายคือการตรวจสอบเชิงประจักษ์ว่าการใช้โทเคนกระจายตัวอย่างไรเมื่อระบบ LLM-MA ทำงานพัฒนาซอฟต์แวร์แบบ end-to-end
    • เป้าหมายของการวิเคราะห์เบื้องต้นคือ ChatDev
    • สถาปัตยกรรม “chat chain” ของ ChatDev แสดงโมเดลแบบน้ำตกที่เป็นลำดับชัดเจนคือ ออกแบบ → เขียนโค้ด → ทดสอบ จึงเหมาะกับการแมปเข้ากับขั้นตอนการพัฒนาซอฟต์แวร์
    • ChatDev เป็นหนึ่งในเฟรมเวิร์กโอเพนซอร์สที่ได้รับความนิยมและถูกอ้างอิงมาก

  • การคัดสรรชุดข้อมูล

    • รัน ChatDev กับซอฟต์แวร์เดเวลอปเมนต์ทาสก์ที่แตกต่างกัน 30 งาน
    • พรอมป์ต์รวบรวมมาจาก ProgramDev Dataset ที่ใช้ในงานวิจัย MAST
    • พรอมป์ต์ที่เลือกมีตั้งแต่อัลกอริทึมง่ายๆ เช่น การสร้างเลขฟีโบนักชี ไปจนถึงแอปพลิเคชันที่ซับซ้อนกว่า เช่น เกมหมากรุก
    • ยืนยันความหลากหลายโดยอิงงานวิจัยล่าสุดที่เสนอว่าจำนวน reasoning token สามารถใช้เป็นตัวชี้วัดแทนความซับซ้อนของทาสก์ได้
    • ช่วงการใช้ reasoning token ของ 30 ทาสก์อยู่ระหว่าง 17,280 ถึง 40,000 โทเคน ซึ่งบ่งชี้ว่ามีความหลากหลายของความซับซ้อนเพียงพอสำหรับการวิจัย
    โฆษณา

  • การเลือกโมเดล

    • โมเดลพื้นฐานของเอเจนต์ทั้งหมดคือ GPT-5 reasoning model
    • เกณฑ์การเลือกคือความนิยมและความทันสมัยของโมเดล ความเหมาะสมกับกรณีใช้งานแบบเอเจนต์ และความสามารถด้าน reasoning ที่แข็งแกร่งซึ่งสอดคล้องกับความคาดหวังต่อเอเจนต์อัตโนมัติ
    • เวอร์ชันโมเดลที่ใช้ในการทดลองคือ gpt-5-2025-08-07
    • พารามิเตอร์ temperature ไม่รองรับในโมเดลนี้ จึงใช้ค่าเริ่มต้น 1.0
    • หน้าต่างบริบทมีขนาด 400,000 โทเคน และจำนวน output token สูงสุดคือ 128,000 โทเคน
    • knowledge cutoff คือ 30 กันยายน 2024

  • ไปป์ไลน์การวิเคราะห์

    • ในขั้นตอนเก็บ trace ได้ทำ instrumentation กับ ChatDev เพื่อบันทึก execution trace ทั้งหมดของแต่ละทาสก์ทั้ง 30 งานเป็นล็อก
    • เก็บพรอมป์ต์ คำตอบ และจำนวน input, output, reasoning token ของแต่ละการเรียก LLM
    • การแมปขั้นตอนเป็นระเบียบวิธีสำคัญที่แปลงขั้นตอนภายในของเฟรมเวิร์ก ChatDev ให้เป็นขั้นตอนการพัฒนาทั่วไป
    • การทำ abstraction นี้ช่วยให้วิเคราะห์ได้แบบทั่วไป และสามารถขยายไปยังเฟรมเวิร์ก LLM-MA ด้านวิศวกรรมซอฟต์แวร์อื่นๆ ได้
    • การรวมยอดโทเคนทำด้วยสคริปต์ Python
    • ทำการ parse trace ที่เก็บมา และรวมจำนวนโทเคนตามขั้นตอนการพัฒนาตลอดการรันทั้ง 30 ครั้ง
    • แยกย่อยเป็น input, output, และ reasoning token

  • การแมปขั้นตอนภายในของ ChatDev กับขั้นตอนการพัฒนา

    • ขั้นตอนออกแบบสอดคล้องกับ DemandAnalysis, LanguageChoose โดยเน้นการทำความเข้าใจความต้องการและการตัดสินใจเชิงเทคโนโลยีระดับสูง
    • ขั้นตอนเขียนโค้ดสอดคล้องกับ Coding และเกี่ยวข้องโดยตรงกับการเขียนซอร์สโค้ดตั้งต้น
    • ขั้นตอนทำโค้ดให้สมบูรณ์สอดคล้องกับ CodeComplete และใช้เติม placeholder หรือไฟล์โค้ดที่ยังไม่สมบูรณ์ซึ่งเหลือจากขั้นตอนเขียนโค้ด
    • ขั้นตอนรีวิวโค้ดสอดคล้องกับ CodeReview และทำการตรวจสอบ แก้ไข และปรับปรุงโค้ดผ่านการสนทนาแบบวนซ้ำระหว่าง programmer agent กับ code reviewer agent
    • ขั้นตอนทดสอบสอดคล้องกับ Test และเน้นการทดสอบระบบแบบไดนามิกเพื่อค้นหาและแก้บั๊กที่กระทบต่อการรันได้จริง
    • ขั้นตอนจัดทำเอกสารสอดคล้องกับ EnvironmentDoc, Reflection, Manual และใช้สร้างคู่มือผู้ใช้กับเอกสาร dependency ของสภาพแวดล้อมที่จำเป็น

ผลการวิจัยและการอภิปราย

  • คำถามวิจัย

    • คำถามหลักคือรูปแบบการใช้โทเคนของระบบ LLM-MA ในซอฟต์แวร์เดเวลอปเมนต์ทาสก์
    • การเข้าใจ tokenomics ของระบบวิศวกรรมซอฟต์แวร์แบบเอเจนต์มีความสำคัญต่อการนำไปใช้จริงอย่างยั่งยืน
    • การใช้โทเคนสูงเชื่อมโยงโดยตรงกับต้นทุนทางการเงิน การใช้พลังงาน และผลกระทบต่อสิ่งแวดล้อมที่เพิ่มขึ้น
    • หากระบุตำแหน่งที่โทเคนถูกใช้ภายใน SDLC ได้ ก็สามารถสร้าง “แผนที่ต้นทุน” ที่นำไปใช้กับการคาดการณ์ต้นทุนและการปรับเวิร์กโฟลว์ให้เหมาะสมได้
    • การวิเคราะห์ดำเนินไปในสองแกน
    • การกระจายตัวของโทเคนรวมตามขั้นตอนการพัฒนาที่แมปไว้ เช่น ออกแบบและเขียนโค้ด
    • สัดส่วนของ input, output, reasoning token ภายในแต่ละขั้นตอน
    โฆษณา

  • ข้อค้นพบ 1: ขั้นตอนรีวิวโค้ดครองการใช้โทเคน

    • การใช้โทเคนตลอดกระบวนการพัฒนามีการกระจายตัวที่ไม่สม่ำเสมออย่างมาก
    • ขั้นตอนรีวิวโค้ดใช้โทเคนเฉลี่ย 59.4% ของทั้ง 30 ทาสก์ และเป็นช่วงที่ใช้มากที่สุด
    • ขั้นตอนทำโค้ดให้สมบูรณ์เกิดขึ้นใน 6 จาก 30 ทาสก์ และใช้โทเคนเฉลี่ย 26.8% ในการรันเหล่านั้น
    • ขั้นตอนจัดทำเอกสารใช้เฉลี่ย 20.1% และขั้นตอนทดสอบใช้เฉลี่ย 10.3%
    • ขั้นตอนทดสอบเกิดขึ้นใน 12 จาก 30 ทาสก์
    • การเขียนโค้ดตั้งต้นใช้เฉลี่ย 8.6% และการออกแบบใช้เฉลี่ย 2.4% ซึ่งถือว่าต้นทุนค่อนข้างต่ำ
    • ต้นทุนหลักของวิศวกรรมซอฟต์แวร์แบบเอเจนต์ไม่ได้อยู่ที่การสร้างโค้ดเริ่มต้น แต่อยู่ที่กระบวนการปรับปรุงและตรวจสอบแบบวนซ้ำและอาศัยการสนทนา
    • ค่า n ในรูปหมายถึงจำนวนทาสก์จาก 30 งานที่มีการรันขั้นตอนนั้น
    • ไม่ใช่ว่าทุกขั้นตอนจะถูกรันเสมอไป เพราะเอเจนต์ในระบบหลายเอเจนต์สามารถตัดสินใจเองได้ว่าจะรันขั้นตอนใด
    • แถบความคลาดเคลื่อนคือ ±1 ส่วนเบี่ยงเบนมาตรฐาน เพื่อแสดงความแปรปรวนของการใช้โทเคนในแต่ละขั้นตอน

  • ข้อค้นพบ 2: การใช้โทเคนมีศูนย์กลางอยู่ที่ input token

    • ทุกขั้นตอนยกเว้นขั้นตอนเขียนโค้ดมีรูปแบบที่ input token สูงกว่า output และ reasoning token อย่างชัดเจน
    • องค์ประกอบการใช้โทเคนเฉลี่ยรวมต่อทาสก์คือ input 53.9%, output 24.4%, reasoning 21.6%
    • อัตราส่วนประมาณ 2:1 ระหว่าง input token กับ output token เป็นหลักฐานเชิงประจักษ์ที่ชัดเจนของ “communication tax” ที่งานวิจัยก่อนหน้าเสนอไว้
    • เอเจนต์ใช้โทเคนไปกับการส่งต่อบริบทขนาดใหญ่ซ้ำๆ ระหว่างการสนทนาเพื่อร่วมมือกัน
    • โปรโตคอลการทำงานร่วมกันของเอเจนต์ในปัจจุบันมีความไร้ประสิทธิภาพที่ใช้โทเคนส่วนใหญ่ไปกับการส่งผ่านบริบท มากกว่าการสร้างผลลัพธ์ใหม่
    • communication tax อาจเป็นคุณลักษณะโดยกำเนิดของสถาปัตยกรรมหลายเอเจนต์แบบสนทนา และควรเป็นหัวข้อวิจัยเพิ่มเติมในอนาคต

  • ข้อค้นพบ 3: tokenomic profile แตกต่างกันตามขั้นตอนการพัฒนา

    • สัดส่วนโทเคนในแต่ละขั้นตอนสร้างรูปแบบเฉพาะของกิจกรรมวิศวกรรมซอฟต์แวร์แต่ละประเภท
    • ขั้นตอนเขียนโค้ดเป็นกรณียกเว้นที่เน้น output โดยมี output 58.0% และ input 6.9%
    • โครงสร้างที่เน้น output ของขั้นตอนเขียนโค้ดสอดคล้องกับลักษณะงานที่สร้างซอร์สโค้ดยาวจากสเปกการออกแบบที่กระชับ
    • ขั้นตอนตรวจสอบและจัดทำเอกสาร เช่น รีวิวโค้ดและจัดทำเอกสาร มีศูนย์กลางอยู่ที่ input
    • สัดส่วน input ของรีวิวโค้ดคือ 51.4%
    • สัดส่วน input ของการจัดทำเอกสารคือ 80.2%
    • ขั้นตอนเหล่านี้ใช้โค้ดเดิมเป็นบริบทขนาดใหญ่ และสร้างผลลัพธ์เชิงวิเคราะห์ที่เล็กกว่า
    • token profile ตามขั้นตอนสามารถใช้เป็นแผนที่ต้นทุนตามกิจกรรมวิศวกรรมได้
    • ผู้ปฏิบัติงานจึงระบุโอกาสในการคาดการณ์ต้นทุนและเพิ่มประสิทธิภาพกระบวนการได้ดีขึ้น

  • สัดส่วนโทเคนรายขั้นตอน

    • สัดส่วนเฉลี่ยของขั้นตอนออกแบบคือ input 60.4%, output 3.6%, reasoning 36.0%
    • สัดส่วนเฉลี่ยของขั้นตอนเขียนโค้ดคือ input 6.9%, output 58.0%, reasoning 35.1%
    • สัดส่วนเฉลี่ยของขั้นตอนทำโค้ดให้สมบูรณ์คือ input 47.7%, output 41.7%, reasoning 10.5%
    • สัดส่วนเฉลี่ยของขั้นตอนรีวิวโค้ดคือ input 51.4%, output 24.7%, reasoning 23.9%
    • สัดส่วนเฉลี่ยของขั้นตอนทดสอบคือ input 60.8%, output 20.7%, reasoning 18.4%
    • สัดส่วนเฉลี่ยของขั้นตอนจัดทำเอกสารคือ input 80.2%, output 8.3%, reasoning 11.5%
    • สัดส่วนเฉลี่ยรวมต่อทาสก์คือ input 53.9%, output 24.4%, reasoning 21.6%
    โฆษณา

  • อภิปราย

    • ผลเบื้องต้นนี้ให้แผนที่ต้นทุนเริ่มต้นของการพัฒนาซอฟต์แวร์แบบเอเจนต์
    • ต้นทุนโทเคนที่สูงของขั้นตอนรีวิวโค้ดสามารถตีความได้ว่าเป็น “ต้นทุนของการสนทนา”
    • ต้นทุนนี้เกิดขึ้นโดยตรงจากสถาปัตยกรรมแบบสนทนาของระบบ LLM-MA ที่เอเจนต์ต้องส่งบริบทโค้ดทั้งหมดกลับไปกลับมาซ้ำๆ เพื่อปรับปรุงโค้ด
    • โปรโตคอลการทำงานร่วมกันของเอเจนต์เพื่อการตรวจสอบในปัจจุบันอาจไร้ประสิทธิภาพอย่างมาก เพราะแม้งานจะต้องแก้เพียงเล็กน้อยก็อาจใช้ทรัพยากรจำนวนมหาศาล
    • สิ่งนี้สอดคล้องกับผลของการจัดหมวดหมู่ MAST เรื่องความล้มเหลวในการตรวจสอบและการวนซ้ำของขั้นตอน
    • การใช้โทเคนสูงอาจเป็นอาการที่บ่งชี้ว่าระบบเอเจนต์กำลังพยายามฝืนแก้ปัญหาการประสานงานภายในด้วยการสนทนาอย่างเข้มข้น
    • ผู้ปฏิบัติงานสามารถประเมินต้นทุนของโปรเจกต์ที่ใช้เอเจนต์ได้ตามประเภทงานที่ต้องทำ
    • โปรเจกต์ greenfield ที่มีสัดส่วนการเขียนโค้ดตั้งต้นสูง กับโปรเจกต์ที่เน้น refactoring และ debugging โค้ดเดิม มีโครงสร้างต้นทุนต่างกัน
    • ในโปรเจกต์ที่เน้น refactoring และ debugging โค้ดเดิม วงจรรีวิวโค้ดที่มีราคาแพงและเน้น input จะครองต้นทุน
    • การใส่ checkpoint แบบ “human-in-the-loop” ก่อนขั้นตอนรีวิวโค้ด สามารถใช้เป็นการตัดสินใจเชิงออกแบบเพื่อป้องกันลูปการวนซ้ำที่มีต้นทุนสูง และเพิ่มประสิทธิภาพทั้งเชิงเศรษฐศาสตร์และการคำนวณ
    • วาระการวิจัยสำคัญคือการออกแบบโปรโตคอลการทำงานร่วมกันที่ใช้โทเคนได้มีประสิทธิภาพมากขึ้นสำหรับการตรวจสอบและการปรับปรุง
    • ต้องมีแนวทางที่ไปไกลกว่าการส่งบริบททั้งหมดแบบตรงๆ
    • จำเป็นต้องมีเฟรมเวิร์กการประเมินที่เป็นมาตรฐานและครอบคลุม
    • เฟรมเวิร์กนี้สามารถทำหน้าที่เป็นฐานร่วมสำหรับ benchmark และเปรียบเทียบประสิทธิภาพของสถาปัตยกรรม LLM-MA ที่แตกต่างกัน เช่น hierarchical conversational workflow ของ ChatDev และสายการประกอบแบบ SOP-based ของ MetaGPT
    • มันยังอาจทำหน้าที่เป็น “Rosetta Stone” ที่แปลพฤติกรรมเฉพาะของแต่ละเฟรมเวิร์กให้เป็นกิจกรรมวิศวกรรมซอฟต์แวร์สากลได้

ภัยคุกคามต่อความเที่ยงตรงและงานในอนาคต

  • ภัยคุกคามต่อความเที่ยงตรง

    • การวิเคราะห์นี้อิงกับระบบ LLM-MA เดียวคือ ChatDev และ LLM เดียวคือ GPT-5 Reasoning Model
    • รูปแบบการใช้โทเคนที่สังเกตได้อาจแตกต่างออกไปในสถาปัตยกรรม LLM-MA อื่น หรือ LLM อื่นที่มีประสิทธิภาพด้านโทเคนต่างกัน
    • แม้ซอฟต์แวร์เดเวลอปเมนต์ทาสก์ทั้ง 30 งานจะมีความหลากหลาย แต่ก็อาจไม่ได้เป็นตัวแทนของทุกสถานการณ์และทุกระดับความซับซ้อนในการพัฒนาซอฟต์แวร์
    • ขนาดของชุดข้อมูลที่คัดสรรมาเกิดจากการขาด benchmark สาธารณะขนาดใหญ่สำหรับ agent trace ที่เฉพาะทางด้านวิศวกรรมซอฟต์แวร์โดยตรง
    • การคัดสรรข้อมูลเป็นกระบวนการที่ใช้ทั้งเวลาและต้นทุนสูง
    • บางขั้นตอนการพัฒนาถูกรันเพียงใน subset ขนาดเล็กของ 30 ทาสก์
    • การทำโค้ดให้สมบูรณ์เกิด n=6 และการทดสอบเกิด n=12 จึงถูก trigger ค่อนข้างน้อย
    • ดังนั้นข้อสรุปเกี่ยวกับ tokenomic profile ของขั้นตอนเฉพาะเหล่านี้อิงกับตัวอย่างขนาดเล็ก อาจมีความเป็นตัวแทนต่ำและมีข้อจำกัดด้านการสรุปทั่วไป
    • วิธีแมปขั้นตอนภายในของ ChatDev เข้ากับขั้นตอนการพัฒนาซอฟต์แวร์เป็นการทำ abstraction
    • แม้จะเป็นการแมปที่มีเหตุผลและมีประโยชน์สำหรับการสร้างเฟรมเวิร์กการประเมินแบบมาตรฐาน แต่ก็เป็นเพียงหนึ่งในหลายวิธีที่เป็นไปได้ในการแมปกิจกรรมของเอเจนต์

  • บทสรุปและงานในอนาคต

    • ในวิศวกรรมซอฟต์แวร์แบบเอเจนต์ ต้นทุนโทเคนไม่ได้กระจายเท่าๆ กัน แต่กระจุกอย่างท่วมท้นอยู่ที่ขั้นตอนรีวิวโค้ดแบบวนซ้ำและอาศัยการสนทนา
    • input token ที่ประกอบกันเป็น “communication tax” คิดเป็นสัดส่วนส่วนใหญ่ของการใช้โทเคนทั้งหมด และเป็นพื้นที่สำคัญที่สุดสำหรับการเพิ่มประสิทธิภาพในอนาคต
    • งานแรกในอนาคตคือขยายชุดข้อมูลด้วยทาสก์ที่มากขึ้นเพื่อปรับปรุงความสามารถในการสรุปทั่วไป
    • งานที่สองคือขยายการวิเคราะห์ไปยัง LLM อื่นเพื่อทำความเข้าใจผลกระทบเฉพาะของแต่ละโมเดล
    • งานที่สามคือขยายการวิเคราะห์ไปยังระบบ LLM-MA อื่นเพื่อเปรียบเทียบว่าความต่างของสถาปัตยกรรมส่งผลต่อ tokenomics อย่างไร
    • งานที่สี่คือศึกษาความสัมพันธ์ระหว่างรูปแบบการใช้โทเคนกับโหมดความล้มเหลว
    • งานที่ห้าคือการพัฒนาและตรวจสอบเพิ่มเติมของเฟรมเวิร์กการแมปขั้นตอนการพัฒนาที่แข็งแรงและใช้ได้ทั่วไป สำหรับ benchmark ประสิทธิภาพของเอเจนต์วิศวกรรมซอฟต์แวร์

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

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

    • มีวิดีโอเดโมของสิ่งที่ทำไว้ที่นี่: https://streamable.com/e49cgt
    • คุณพูดถึงค่าใช้จ่ายไว้ เลยอยากรู้ว่าพอจะอธิบาย โครงสร้างต้นทุนคร่าว ๆ ตามประเภทของปัญหาได้ไหม
      อยากรู้ด้วยว่าใช้กลยุทธ์อะไรบ้าง และต้นทุนต่างกันอย่างไรในแต่ละกลยุทธ์
    • อยากรู้ว่าใช้ execution harness อะไร และใช้ LLM ตัวไหน
    • ผมก็เคยสร้างระบบคล้าย ๆ กัน แต่เน้นที่ วงจรป้อนกลับ มากกว่าการปรับปรุงพรอมป์ต์แบบสำรวจ
      เป็นแนวไซเบอร์เนติกส์ คือค่อย ๆ เพิ่มชุดไลบรารีสำหรับการตรวจสอบแบบกำหนดแน่นอนและการแก้ไขอัตโนมัติเพื่อให้เอาต์พุตจากพรอมป์ต์มีเสถียรภาพ
      “ปัญหา” ที่ไลบรารีชุดนั้นจัดการไม่ได้ก็จะถูกเปิดเผยให้คนที่คุมกระบวนการเห็น

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

    • ผมว่ามันใกล้เคียงกับการเร่งดันมูลค่าสูงสุดหรือ IPO มากกว่า
      มีข่าวลือด้วยว่าอัตรากำไรจาก inference เกิน 70%
      ถ้ายก SpaceX เป็นตัวอย่าง ตลอด 6 เดือนที่ผ่านมาเขาขึ้นราคาสินค้าผู้บริโภคโดยรวม แต่ Alphabet กับ Anthropic รวมกันก็จ่ายเกิน 2 พันล้านดอลลาร์ต่อเดือนอยู่แล้ว เลยไม่ใช่ว่าขาดเงิน
      Microsoft/GitHub อยู่ในสถานะเอาสินค้าคนอื่นมาแพ็กใหม่ เลยกลายเป็นฝ่ายขาดทุนในที่นี้
    • กรณี GitHub ใกล้เคียงกับข้อยกเว้นที่ดูรุนแรงเป็นพิเศษ เพราะเพิ่งมี การเปลี่ยนนโยบายราคา ไม่นานนี้
      โดยทั่วไปแล้วราคาถูกกำหนดจากปัจจัยพื้นฐานหลายอย่าง ไม่ได้แปลว่ามันเป็นอะไรที่ตามอำเภอใจในตัวมันเอง
      เช่น ถ้าผู้บริหาร GitHub ใช้เครื่องสุ่มตัวเลขมากำหนดราคาโทเค็น แบบนั้นถึงจะเรียกว่าการตั้งราคาแบบตามอำเภอใจ

  • ตรงที่บอกว่า “โทเค็นอินพุตคิดเป็นค่าใช้จ่ายเฉลี่ย 53.9% ซึ่งเป็นสัดส่วนมากที่สุด” สำหรับการใช้งานของผม สัดส่วนมันใกล้กับ 10:1 มากกว่า
    โทเค็นที่ถูกใช้ไปส่วนใหญ่ท่วมท้นเป็นฝั่งอินพุต และบ่อยครั้งเอเจนต์จะอ่านเป็นล้านโทเค็นเพื่อแก้โค้ดแค่บรรทัดเดียว
    ถ้าใกล้ 1:1 หรือฝั่งเอาต์พุตใหญ่กว่า ผมจะมองว่าไม่เอเจนต์มีปัญหา ก็โค้ดเบสยังใหม่หรือว่างเปล่า

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

  • พอใช้เอเจนต์กับงานเขียนโค้ด มันอยากเขียน unit test เป็นหลักพัน แต่กลับไม่ค่อยมีแนวโน้มจะทดสอบแบบไดนามิก

    • มันยังชอบ เผาโทเค็นมหาศาล ไปกับการเขียนและดีบักเทสต์ที่พังในเชิงความหมายด้วย
    • unit test ก็เป็นการทดสอบแบบไดนามิกชนิดหนึ่ง
      การทดสอบแบบสแตติกคือพวก lint หรือ type check
      ถ้าคุณต้องการการทดสอบแบบไดนามิกชนิดอื่นนอกจาก unit test ก็สงสัยว่าเคยระบุเป็นข้อกำหนดไว้ตั้งแต่ขั้นวางแผนหรือ PRD ไหม
    • แม้แต่ AWS ก็ยังผลักโซลูชัน Lambda ที่ซับซ้อน ซึ่งพยายามผูกบริการ AWS ที่คิดเงินได้ให้มากที่สุด แม้เป็นความต้องการง่าย ๆ
      ผลประโยชน์ของพวกเขาไม่ได้ตรงกับผลประโยชน์ของคุณเสมอไป
      ในกรณีนี้ก็คืออยากให้คุณใช้เงินโดยไม่จำเป็นกับงานที่ไม่มีประโยชน์
      น่าจะเลิกใช้คำเลี่ยงอย่าง “โทเค็น” ได้แล้ว
    • ก็แค่สั่งให้มันทำการทดสอบแบบไดนามิกเพิ่มขึ้น
      ผมคิดว่าส่วนหนึ่งที่มันเลี่ยงการทดสอบแบบไดนามิกก็เพราะมันทำให้ช้าลง และอาจทำให้ซอฟต์แวร์หยุดทำงานในจุดที่คาดไม่ถึงได้

  • ทำให้นึกถึงงานวิจัยจากปีที่แล้วที่ให้ข้อมูลแนะแนวงบประมาณเพื่อเพิ่มประสิทธิภาพ การใช้โทเค็น
    [1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...

  • มันคล้ายไมล์สะสมชดเชยของสายการบิน และในมุมบริษัทก็ไม่มีข้อได้เปรียบเหนือการเช่า เวลา GPU แบบ bare-metal

    • หวังว่าช่วงเวลาเลวร้ายนี้จะจบลงในไม่ช้าเมื่อมีบริษัทฮาร์ดแวร์ออก NPU ราคาถูกมากขึ้น และขนาดโมเดลก็ถูกปรับให้เหมาะสมมากขึ้น
      ถ้าความต้องการ AI ส่วนใหญ่ถูกตอบสนองได้ด้วยฮาร์ดแวร์และโมเดลแบบ on-premise หรือ on-device ก็ชวนสงสัยว่าฟาร์มคอมพิวต์และโมเดลขนาดมหึมาที่มีต้นทุนดำเนินงานสูงแบบนั้นจะยังมีประโยชน์กับอะไร
      สุดท้ายลูกค้าที่เหลืออยู่คงมีแต่รัฐบาลขนาดใหญ่ และท้ายที่สุดผู้เสียภาษีก็จะเป็นคนจ่ายเงินหลายพันล้านดอลลาร์ที่กลุ่มผูกขาด AI ลงทุนไป

  • ผมเขียน โพสต์บน Substack เกี่ยวกับเรื่องนี้ไว้เมื่อเดือนธันวาคม: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...

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

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

  • มีเรื่องข้างเคียงที่น่าสนใจอยู่เรื่องหนึ่ง ผมอยู่ในประชุมเพื่อพิจารณาผลิตภัณฑ์ใหม่ตัวหนึ่ง ทุกอย่างกำลังไปได้ดีจนมีหน้าจอที่บอกว่าเขาเพิ่ม AI เข้าไปในผลิตภัณฑ์นั้น
    แน่นอนว่ามี AI แปะอยู่ และดูชัดมากว่าถูกยัดเข้ามาแบบฝืน ๆ
    หนึ่งในจุดที่เห็นชัดคือมีคอลัมน์แสดงจำนวนโทเค็นที่ใช้ในแต่ละคำถาม
    ผมถามว่าใครเป็นคนจ่ายค่าโทเค็น เขาตอบว่ารวมอยู่ในไลเซนส์แล้ว ผมเลยถามต่อว่ามีเพดานงบหรือไม่ หรือใช้ได้ไม่จำกัด เขาตอบว่าเป็นคำถามที่ดีและจะกลับไปตรวจสอบ
    เหตุผลที่ผมถามก็เพราะเมื่อกี้คำถามง่าย ๆ เกี่ยวกับอุปกรณ์เพียงครั้งเดียว เผาไป 250,000 โทเค็น
    ตอนนั้นผมได้ยินผู้บริหารฝั่งโน้นคนหนึ่งพูดเสียงดังว่า “เรากำลังโชว์สิ่งนี้ให้ลูกค้าดูทำไมกัน?” แล้วพวกเราก็หัวเราะกันพอสมควร
    บทเรียนที่ได้คือ ค่าใช้จ่ายของการยัด AI เข้าไปในทุกอย่างยังไม่ได้ถูกคำนวณอย่างเหมาะสม และยิ่งไม่ต้องพูดถึงต้นทุนที่แท้จริงของการปฏิบัติการ AI
    ทุกอย่างที่มี AI แปะมาจะมีราคาแพงขึ้น แม้คุณจะไม่ได้ต้องการมันก็ตาม

    • AIshittification

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

    • Tokenomics ก็เป็นคำที่ใช้กันมานานในหมู่คนชอบกัญชาด้วย
    • เป็นกระแสใหม่
      ลืมกระแสเก่าไปเถอะ อันนี้เองก็จะเก่าในไม่ช้าเหมือนกัน ต้องรีบขึ้นรถก่อนจะสาย
    • cryptocurrency economics = cryptonomics
    • “Crypto” เองก็เป็นคำที่มีอยู่ก่อนที่วงการคริปโตเคอร์เรนซีจะยึดไปใช้เป็นของตัวเอง
      “Web 3.0” ก็มีอยู่ก่อนที่ฝั่งคริปโตจะทำให้ Web3 กลายเป็นคำที่มีศูนย์กลางอยู่ที่คริปโต
      เพราะงั้นผมไม่เห็นว่าปัญหาคืออะไร
      คำศัพท์ต่าง ๆ ถูกนำกลับมาใช้ใหม่ในบริบทที่ต่างกันอยู่เรื่อย ๆ
      อีกอย่าง คนส่วนใหญ่ก็ย้ายออกจากคริปโตไปแล้ว โอกาสที่จะสับสนเลยไม่น่าจะมากนัก