4 คะแนน โดย GN⁺ 2024-05-15 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • needle-in-a-needlestack เป็นหน้าเว็บสาธารณะที่รวบรวมบทความการทดลองและโค้ดเกี่ยวกับ GPT-4o, Llama, Jamba, Sonnet และ Gemini ไว้ในที่เดียว
  • มี คลังโค้ด ของโปรเจกต์ให้มาด้วย จึงสามารถตรวจสอบข้อมูลการทดลอง Needle in a Needlestack ได้โดยตรง
  • บทความของแต่ละโมเดลเปรียบเทียบผลลัพธ์ของ Llama 3.1 8B, Jamba 1.5 และอื่น ๆ โดยเน้นที่ การประมวลผลคอนเท็กซ์ยาว และความแตกต่างด้านความสามารถในการขยาย
  • GPT-4o-mini ถูกนำเสนอเป็นกรณีที่มีความสามารถใกล้เคียง GPT-4 Turbo แต่ราคาต่ำกว่าถึง 98.5% ส่วน Sonnet 3.5 ถูกแนะนำว่าเป็นกรณีที่ทำได้ดีกว่า Sonnet 3.0 ใน NIAN
  • ตัวหน้าเว็บเองเป็น โอเพนซอร์ส จึงสามารถมีส่วนร่วมแก้ไขเอกสารได้ผ่านลิงก์ “Improve this page” บน GitHub

ลิงก์ที่เกี่ยวข้องกับ Needle in a Needlestack

บทความเปรียบเทียบตามโมเดล

เอกสารโอเพนซอร์ส

  • เว็บไซต์นี้เป็น โอเพนซอร์ส
  • สามารถแก้ไขหน้าเว็บบน GitHub ได้ผ่านลิงก์ Improve this page

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

 
wedding 2024-05-18

ความก้าวหน้าทางเทคโนโลยีนี่สุดยอดจริง ๆ.. ฮือ

 
GN⁺ 2024-05-15
ความคิดเห็นจาก Hacker News
  • การทดสอบนี้อิงจาก ชุดข้อมูลลิเมอริก ที่เผยแพร่ในปี 2021: https://zenodo.org/records/5722527
    ผมคิดว่ามีความเป็นไปได้สูงมากที่ GPT-4o จะถูกฝึกด้วยข้อมูลนี้ เพราะไม่มีเหตุผลอะไรที่จะจงใจไม่ใส่เข้าไป สงสัยว่าทำไมทีม NIAN ถึงไม่ให้หลาย ๆ โมเดลสร้างลิเมอริก แล้วตรวจสอบว่าผลลัพธ์นั้นไม่มีอยู่ในชุดข้อมูลหรือไม่ แบบนั้นจะช่วยตัดความเป็นไปได้ที่โมเดลถูกฝึกมาด้วยลิเมอริกเหล่านั้นได้

    • ได้ทดสอบแล้วว่าถ้าไม่ให้ลิเมอริก LLM จะตอบคำถามไม่ได้หรือไม่ เนื่องจาก ยกเว้น 4o แล้ว ประสิทธิภาพในเบนช์มาร์กนี้แย่มาก จึงไม่คิดว่าการมีข้อมูลอยู่ในชุดฝึกจะทำให้การทดสอบเป็นโมฆะ
    • ทำไมไม่สร้าง ข้อความสุ่มทั้งหมด แล้วให้มันหาในนั้นเลยล่ะ?
    • NIAN เป็นไอเดียที่เจ๋งมาก แต่ทำไมไม่แปลเป็น N ภาษาที่ต่างกัน แล้วถามล่ะ? อาจผสมใช้ DeepL, Google Translate, การแปลด้วย LLM เอง ฯลฯ ก็ได้
  • ลองเปรียบเทียบ เอกสารกฎหมายขนาดเล็กสองฉบับ แล้วมัน hallucinate ไปเต็ม ๆ ว่ามีข้อกำหนดอยู่ในฉบับหนึ่งแต่ไม่มีในอีกฉบับหนึ่ง เป็นแบบนั้นในสามช่วงต่างกันของสัญญา
    พอเช็กด้วย ctrl-f ก็พบว่ามีอยู่เหมือนกันทั้งสองฝั่ง นี่เป็นแค่ตัวอย่างเดียว แต่ตัวเลข 90% ดูไม่น่าเชื่อเท่าไร ทั้งหมดมีประมาณ 80,000 โทเค็น

    • รู้สึกคล้ายกันเลย ให้มันหาข้อมูลซ้ำในรายการ 6,000 รายการ แล้วคำตอบทั้งชุดแทบจะ hallucinate หลายครั้ง บางครั้งก็เจอรายการซ้ำบางส่วน แต่แทรกรายการที่ hallucinate ขึ้นมาระหว่างนั้น
      ผมไม่คาดหวังคำตอบที่ถูกต้องอยู่แล้ว เพราะคิดว่านี่เป็นงานที่ยากสำหรับ attention head จำนวนคงที่ แต่ดูเหมือนจะแย่กว่า Claude Opus หรือ GPT-4 มาก
    • นั่นไม่ใช่การหาเข็มในกองฟาง
      LLM จะทำงานนี้ได้ดีกว่าถ้าแบ่งเอกสารสองฉบับออกเป็นช่วงที่เล็กลง แล้วประมวลผลซ้ำทีละช่วง มันไม่มีความสามารถในการให้เหตุผลหรือความจำที่จะวิเคราะห์ข้อความก้อนใหญ่สองก้อนที่เกินชิ้นส่วนค่อนข้างเล็กได้อย่างมีโครงสร้าง แต่ถ้าค่อย ๆ ไล่ดูเป็นชิ้นเล็ก ๆ ที่แยกจากกันทางความหมายและเกี่ยวข้องกัน มันก็ทำงานได้ค่อนข้างดี
      การสมมติว่าพวกมันเป็นเครื่องจักรวิเศษนั้นผิด มันมีข้อจำกัดและความสามารถ และเราควรเข้าใจเหมือนเครื่องมืออื่น ๆ ว่าอะไรทำได้ อะไรทำไม่ได้ และควรรู้ด้วยว่าทำไม สำหรับนักพัฒนา 99.9% นี่ก็ยังเป็นพัฒนาการที่ค่อนข้างใหม่มาก ไม่เข้าใจว่าทำไมความคาดหวังถึงสูงแทบไร้ขีดจำกัดแบบนั้น เทคโนโลยีก่อนหน้านี้มีมาตรฐานที่สมเหตุสมผลกว่าว่า “โอเค มาหาวิธีใช้ให้ถูกต้องกันเถอะ” อาจเป็นเพราะมันพูดเหมือนคนจนดูเหมือนมีความสามารถที่จริง ๆ ไม่มี หรือเพราะมันฟังดูเหมือนมนุษย์มากจนเราไปตำหนิมันที่ไม่ใช่มนุษย์ มีทั้งการอวยเกินจริงและการประเมินต่ำเกินไปเกิดขึ้นพร้อมกัน แม้แต่ XML ก็เคยผ่านวงจรความร้อนแรงคล้าย ๆ กัน จนครั้งหนึ่งดูเหมือนจะยุติความอดอยากของโลกได้
    • นั่นเป็นการทดสอบที่ต่างจาก needle-in-a-needlestack แต่ก็แสดงให้เห็นได้ดีว่าโมเดลเปราะบางแค่ไหน ในบางด้านมันเก่ง แต่ในบางด้านก็แย่อย่างน่าหายนะ
      needle-in-a-needlestack คือปัญหาการหาข้อมูลเฉพาะท่ามกลางข้อมูลที่คล้ายกัน ต่างจาก needle-in-a-haystack ที่เป็นการหาในหมู่สิ่งที่แตกต่างกัน เช่น การหาลิเมอริกหนึ่งบทจากลิเมอริกหลายพันบท
    • ผมลองทดลองแบบเดียวกันกับกฎหมายท้องถิ่น แล้วจับได้ว่า GPT hallucinate เรื่อง ค่าปรับและค่าธรรมเนียม นี่เป็นปัญหาที่มีอยู่จริง
    • น่าสนใจนะ อย่างน้อยในทางการ context window ของ GPT-4o คือ 128k
  • การทดสอบ needle-in-a-haystack แสดงความสามารถในการจัดการบริบทยาวจริง ๆ ของโมเดลได้อย่างจำกัดมากเท่านั้น เหตุผลหลักที่มันถูกใช้กันคือโมเดลยุคแรกทำงานนี้ได้แย่มากและทดสอบได้ง่าย
    ที่จริง โมเดลสมัยใหม่ส่วนใหญ่ทำงานเดี่ยวนี้ได้ค่อนข้างดี แต่ในทางปฏิบัติ ความสามารถในการทำงานซับซ้อนเกิน 32K โทเค็นลดลงอย่างมาก RULER เป็นการทดสอบที่ดีกว่ามาก: https://github.com/hsiehjackson/RULER

    แม้จะทำคะแนนได้เกือบสมบูรณ์แบบในการทดสอบ needle-in-a-haystack (NIAH) พื้นฐาน แต่ทุกโมเดล (ยกเว้น Gemini-1.5-pro) แสดงประสิทธิภาพลดลงมากในงาน RULER เมื่อความยาวของซีเควนซ์เพิ่มขึ้น
    แม้ทุกโมเดลจะอ้างว่ารองรับขนาดบริบทเกิน 32k โทเค็น (ยกเว้น Llama3) แต่มีเพียงครึ่งหนึ่งเท่านั้นที่สามารถจัดการซีเควนซ์ยาว 32K ได้อย่างมีประสิทธิภาพ โดยเกินเกณฑ์เชิงคุณภาพคือประสิทธิภาพ 4K ของ Llama2-7b (85.6%) ผลงานที่เกินเกณฑ์ถูกขีดเส้นใต้ไว้

    • อาจเป็นอย่างนั้น แต่ข้อแรก บทความนี้ไม่ได้พูดถึง NIHS แต่เป็นการทดสอบแบบดัดแปลงของตัวเอง จึงอาจเกี่ยวข้องมากกว่า ข้อสอง ประเด็นหลักของบทความคือ GPT-4o ทำได้ดีกว่า แต่การทดสอบที่กล่าวถึงไม่ได้เบนช์มาร์ก GPT-4o
    • โมเดลที่ RULER เบนช์มาร์กไว้ทำผลงานแย่กว่าใน needle-in-a-needlestack อยากรู้ว่า 4o จะออกมาเป็นอย่างไรใน RULER
  • อยากเห็นการทดสอบนี้กับ Gemini Pro 1.5 ด้วย สัปดาห์ก่อนผมลองใส่ Moby Dick ทั้งเล่ม เข้าไป และอีกครั้งหนึ่งลองใส่หนังสือทั้งหมดที่ Byung Chul-Han เขียนไว้ ทั้งสองกรณีมันหาประโยคบางส่วนที่พูดถึงหรือตอบคำถามของผมได้ตรงเป๊ะทุกครั้ง และไม่มี hallucination เลย

    • หลายคนในแล็บกำลังศึกษา การประเมินบริบทยาวของ LLM สำหรับงานนวนิยาย อยู่ Moby Dick มีโอกาสสูงมากที่จะอยู่ในข้อมูลฝึก ดังนั้นคนในแล็บจึงสำรวจหนังสือที่เพิ่งตีพิมพ์เพื่อหลีกเลี่ยงปัญหานี้
      ดู BooookScore(https://openreview.net/forum?id=7Ttk3RzDeu) ที่นำเสนอใน ICLR เมื่อสัปดาห์ก่อน และพรีพรินต์ล่าสุด FABLES(https://arxiv.org/abs/2404.01261) ได้
    • เนื้อหานั้นน่าจะอยู่ใน ชุดข้อมูลฝึก หรือเปล่า? ถ้าลองทำแบบเดียวกันกับชุดหนังสือที่ตีพิมพ์หลังรีลีสล่าสุดของโมเดลก็น่าจะน่าสนใจ
    • ผมลองใส่ตัวอย่าง 2,500 รายการที่ลิงก์ไว้ในบทความลงใน Gemini 1.5 Flash แล้ว และมันตอบคำตอบที่ถูกต้องคือ “The tree has diseased leaves and its bark is peeling.” ได้: https://aistudio.google.com/
    • ผมมีสิทธิ์เข้าถึงโมเดลนั้น และเคยเห็น การดึงข้อมูลจากบริบท ที่น่าประทับใจด้วย ใส่โค้ดเบสขนาดใหญ่ทั้งก้อนเข้าไป มันก็สรุปได้ดีมาก
      ผมยังเห็นคนเอาไฟล์ล็อกขนาดมหึมามาวิเคราะห์ด้วย แต่ถ้าจะระบุจุดที่โมเดลเริ่มพลาดจริง ๆ ก็ต้องมีอะไรแบบ needle-in-a-needlestack แบบนี้ อย่างน้อยนักพัฒนาโมเดลก็ใช้วิเคราะห์โมเดลที่เสนอได้
    • อีกสัก 2~5 ปีน่าจะใส่ ePub แล้วได้ เวอร์ชันกราฟิกโนเวล ที่ถูกต้องภายในไม่กี่นาที ผมพร้อมดูภาพต้นไม้สไตล์ Tolkien 4,000 ภาพแล้ว
  • น่าจะมีคนสร้างการทดสอบ “การสังเคราะห์ใน haystack” ที่ไม่ได้ทดสอบแค่การค้นหา แต่ทดสอบ ความลึกของความเข้าใจ การเชื่อมโยง และการนามธรรม ระหว่างข้อมูลหลากหลายชนิดด้วย
    เมื่อคนอ่านหนังสือ เขาจะเกิด “สัญชาตญาณโดยรวม” ต่อหนังสือเล่มนั้น เราต้องมีวิธีวัดสิ่งนี้เชิงปริมาณ การทดสอบ needle-in-haystack รู้สึกเรียบง่ายเกินไปและไปได้ไม่ไกลพอ

    • น่าจะทำ การหาตัวคนร้ายแบบ Agatha Christie ที่ซับซ้อนได้ ใส่ plot twist กับ alibi หลายชุด แล้วตัดท้ายเรื่องออก ทำให้ผู้ต้องสงสัยที่น่าจะเป็นไปได้ที่สุดเปลี่ยนไป
    • อีกแบบคือให้เข็มทั้งหลายประกอบกันเป็น กราฟ และพรอมป์ถามงานที่อิงกับกราฟ
    • มีไอเดียซื้อ นวนิยายหรือบทภาพยนตร์ที่ยังไม่เผยแพร่ ซึ่งมีโลกสมมติละเอียดและสอดคล้องภายใน รวมถึงตัวละครที่มีแรงจูงใจออกแบบมาอย่างดี แล้วให้โมเดลเขียนเนื้อเรื่องใหม่ต่อจากจุดสุ่มหลังกลางเรื่อง โดยโยงตัวละครสองตัวที่ยังไม่เคยพบกัน
      ถ้าเข้าใจบริบทจริง ก็ควรเขียนส่วนใหม่ของเรื่องได้ และใช้แรงจูงใจของตัวละครที่ผู้อ่านสัมผัสได้โดยสัญชาตญาณเพื่อพัฒนาเส้นเรื่องของพวกเขาได้ แต่ถ้าจะให้มีประโยชน์ จำเป็นต้องเก็บทั้งหมดไว้เป็นความลับอย่างเข้มงวด จึงใช้ได้ใกล้เคียงกับ benchmark ส่วนตัวเท่านั้น หรือไม่ก็ทำให้เป็นรางวัลที่มีอำนาจน่าเชื่อถือ ซึ่งถูกประเมินจากความน่าเชื่อถือของข้อสรุปเอง มากกว่าจะเปิดเผยวิธีวิทยาเพื่อช่วยพัฒนาวงการ
    • เคยคิดคล้าย ๆ กัน ให้ส่วนหนึ่งของคำถามมีข้อมูลพอให้ LLM หา limerick ได้ แล้วในส่วนที่สองถามสิ่งที่ต้องใช้ ความเข้าใจที่ลึกกว่า เกี่ยวกับ limerick นั้นหรือข้อความอื่น
    • ทำแบบนั้นไม่ได้หรอก เพราะ ความเข้าใจไม่มีอยู่จริง
      GPT-4o ยังจัดการจุดตัดของไอเดียสองอย่างที่ต่างกันและไม่ได้อยู่ในชุดข้อมูลฝึกไม่ได้ แม้แต่การสร้างรูปแบบดัดแปลงแบบสุ่มของจุดตัดระหว่างไอเดียสองอย่างที่ต่างกันก็ยังทำไม่ได้ ยิ่งไปกว่านั้น เราไม่ควรคาดหวังให้โมเดลทำสิ่งแบบนี้ มันไม่ยุติธรรมต่อโมเดล ต่อประโยชน์ใช้งานจริง และต่อสิ่งน่าทึ่งที่มันทำได้แม้ไม่มีความเข้าใจ การเชื่อว่าโมเดลเข้าใจคือการหลอกตัวเอง
  • ตอนนี้ใช้ GPT แปลงข้อมูลดิบแบบไดนามิกให้เป็น เลย์เอาต์ HTML ที่ดูดี ได้ทันทีแล้ว สำหรับหน้าที่ทราฟฟิกต่ำอย่าง change log หรือ audit log ช่วยลดเวลาพัฒนาได้มาก และยังทำให้ HTML อัปเดตตามโครงสร้างข้อมูลที่เปลี่ยนไปได้
    ความพยายามก่อนหน้านี้ใช้ไม่ได้สม่ำเสมอ เพราะ GPT-4-Turbo บางครั้งแทบจะเมินบริบทและคำสั่งไปเกือบทั้งหมด

  • บทความนี้แสดงให้เห็นว่าความสามารถของ GPT-4o ในการใส่ใจกับอินพุตทั้งหน้าต่างนั้นดีขึ้นกว่า GPT-4 Turbo และ Claude-3 Sonnet มากแค่ไหน
    เราต้องการการอัปเกรด needle-in-a-haystack มาสักพักแล้ว และ “Needle In A Needlestack” นี้ก็เป็นก้าวถัดไปที่ดี NIAN สร้างพรอมป์ที่มี limerick หลายพันบท แล้วถามคำถามเกี่ยวกับ limerick ในตำแหน่งหนึ่ง ๆ

    • เห็นด้วย ผมจ่ายเงินให้ Claude อยู่พักหนึ่ง มันโฆษณาอย่างหนักว่ารองรับบริบทขนาดใหญ่ และพอใช้บริบทใหญ่ก็เผาโทเค็นมหาศาล แต่ถ้ามี ซอร์สโค้ด จากก่อนหน้าแค่ไม่กี่หน้าอยู่ในบริบท ก็แทบใช้ไม่ได้เลย
      เรื่องอื่น ๆ มันโอเคหมด และผมก็ชอบโทนของมัน เลยยิ่งหงุดหงิด เมื่อคืนลองใช้ 4o แล้ว มันยังจำคลาส C++ ที่ผมวางไว้เมื่อ 20 คำถามก่อนหน้าได้อย่างสมบูรณ์ ผมไม่สนว่ามันฉลาดแค่ไหน สนว่ามันมีประโยชน์ไหม และนี่ช่วยเรื่องประโยชน์ใช้งานได้มากจริง ๆ
  • ผมเริ่มมั่นใจมากขึ้นเรื่อย ๆ ว่าบนอินเทอร์เน็ตสาธารณะดูเหมือนจะไม่มีใครทำ การประเมิน LLM ที่เหมาะสม เป็นเลย

    • อย่างน้อยก็ดีที่ในที่สุดเราก้าวพ้นการประเมิน LLM แบบที่ทุกคนทำกันในปี 2022~2023 เช่น “ประธานาธิบดีคนที่ 29 ของสหรัฐฯ คือใคร”, “วาดในสไตล์ Van Gogh” มาได้แล้ว
  • ถ้าการทดสอบนี้จะมีความหมาย ต้องรู้ว่า ข้อมูลชุดทดสอบ ไม่ได้รวมอยู่ในข้อมูลฝึก

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

    • จากประสบการณ์ของผมจนถึงตอนนี้ก็เป็นแบบนั้น บทสนทนาปัจจุบันยาวกว่าบทสนทนา GPT-4 เดิมแบบไม่น่าเชื่อ เมื่อก่อนต้องคัดลอกบริบทบ่อย ๆ แล้วไปเริ่มใหม่ในแชตใหม่
    • ผมก็เจอแบบเดียวกัน ในพรอมป์ 16k Turbo แทบสมบูรณ์แบบ แต่ที่ 32k ไม่ค่อยดี และที่ 100k ขึ้นไปใช้ไม่ได้เลย ถ้าต้องการผลลัพธ์ดีในพรอมป์ยาว ต้องใส่ข้อมูลซ้ำ ๆ