ความไม่กำหนดแน่นอนของ GPT-4 เกิดจาก Sparse MoE

 (152334H.github.io)
1 คะแนน โดย GN⁺ 2023-08-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้ตั้งค่า temperature=0 แต่ GPT-4 และ GPT-3.5-turbo ยังให้ผลลัพธ์ต่างกันทุกครั้งเมื่อป้อนอินพุตเดียวกัน ซึ่งเป็นพฤติกรรมผิดปกติที่ไม่เกิดในโมเดล decoder แบบ dense เดิม
  • ที่ผ่านมา สาเหตุของความไม่กำหนดแน่นอนถูกอธิบายว่าเป็น ความไม่เสถียรของการคำนวณเลขทศนิยมของ CUDA แต่คำอธิบายนี้ยังไม่เพียงพอ
  • ในโครงสร้าง batched inference ของ สถาปัตยกรรม Sparse MoE โทเคนจากลำดับต่าง ๆ ภายใน batch เดียวกันจะแข่งขันกันเพื่อแย่งตำแหน่งในบัฟเฟอร์ของ expert ทำให้เกิดความไม่กำหนดแน่นอน
  • ในการทดลองเรียกซ้ำ 30 ครั้ง GPT-4 สร้างผลลัพธ์ที่ไม่ซ้ำกันจำนวนมากกว่ารุ่นอื่นอย่างท่วมท้น สนับสนุนสมมติฐานนี้ในเชิงประจักษ์
  • ประเด็นสำคัญของปัญหาความน่าเชื่อถือของ GPT-4 API คือ โมเดลมีความกำหนดแน่นอนเฉพาะในระดับ batch ไม่ใช่ระดับลำดับ

ตั้งคำถาม — ทำไมตั้ง temperature=0 แล้วผลลัพธ์ยังต่างกันทุกครั้ง

  • เป็นที่รู้กันแพร่หลายอยู่แล้วว่า GPT-4/GPT-3.5-turbo มีความไม่กำหนดแน่นอนแม้ตั้ง temperature=0.0
    • ในโมเดล dense decoder-only ค่า temp=0 หมายถึง greedy sampling และควรนำไปสู่ความกำหนดแน่นอนอย่างสมบูรณ์
    • เพราะ logits ของโทเคนถัดไปเป็นฟังก์ชันล้วน ๆ ของลำดับอินพุตและน้ำหนักของโมเดลเท่านั้น
  • คำตอบจากทีมเทคนิคในงานโต๊ะกลมนักพัฒนา OpenAI World Tour
    • ใจความคือ “พูดตรง ๆ เราก็สับสนเหมือนกัน อาจเป็นบั๊กของระบบ หรือเป็น ความไม่กำหนดแน่นอนของการคำนวณเลขทศนิยมที่ถูกปรับแต่งประสิทธิภาพ”
  • พฤติกรรมนี้น่าสงสัยตรงที่เป็นปัญหาที่ถูกพูดถึงมาตั้งแต่ 2 ปีก่อน แต่ก็ยังไม่ได้รับการแก้ไข
    • เนื่องจาก OpenAI เน้นเรื่อง reliability และไม่มีเหตุผลที่จะจงใจคงความไม่กำหนดแน่นอนไว้ ตอนแรกข้อจำกัดของฮาร์ดแวร์ที่แก้ไม่ได้จึงถูกมองว่าเป็นคำอธิบายที่สมเหตุสมผลที่สุด

สมมติฐานใหม่ — เบาะแสที่พบในเปเปอร์ Soft MoE

  • พบจุดเชื่อมโยงสำคัญในหัวข้อ 2.2 ของเปเปอร์ Soft MoE
    • ภายใต้ข้อจำกัดด้านความจุ (capacity constraints) วิธีการ Sparse MoE ทั้งหมดจะ route โทเคนเป็นกลุ่มขนาดคงที่ และบังคับหรือชักนำให้เกิดสมดุลภายในกลุ่ม
    • เมื่อกลุ่มมีโทเคนจากลำดับ/อินพุตที่ต่างกัน โทเคนเหล่านี้จะแข่งขันกันเพื่อแย่งพื้นที่ว่างในบัฟเฟอร์ของ expert
    • ผลคือโมเดล ไม่กำหนดแน่นอนในระดับลำดับ และกำหนดแน่นอนเฉพาะในระดับ batch โดยลำดับอินพุตบางรายการส่งผลต่อการทำนายสุดท้ายของอินพุตอื่น
  • การที่ GPT-4 เป็นโมเดล Mixture of Experts เป็นข้อเท็จจริงที่เปิดเผยไปแล้ว
    • GPT-4 ถูกฝึกก่อนไตรมาส 2 ปี 2022 และ Sparse MoE ก็มีอยู่ก่อนหน้านั้นแล้ว
  • สมมติฐานหลักที่เสนอ
    • GPT-4 API ถูกโฮสต์บนแบ็กเอนด์ที่ทำ batched inference
    • ปัจจัยอื่นอาจมีผลอยู่บ้าง แต่ ส่วนใหญ่ ของความไม่กำหนดแน่นอนใน API เกิดจากการที่สถาปัตยกรรม Sparse MoE ไม่สามารถบังคับความกำหนดแน่นอนแบบแยกตามลำดับได้

การตรวจสอบ — ยืนยันว่าไม่ใช่ปัญหาฮาร์ดแวร์

  • เพื่อทดสอบสมมติฐาน จึงขอให้ GPT-4 เขียนสคริปต์ทดสอบโดยตรง
    • เรียกโมเดล chat (gpt-4, gpt-3.5-turbo) และโมเดล completion (text-davinci-003/001, davinci-instruct-beta, davinci) ซ้ำด้วยพรอมป์เดียวกันที่ temperature=0 แล้วนับจำนวนผลลัพธ์ที่ไม่ซ้ำกัน
  • ปัญหาที่เกิดขึ้นระหว่างเขียนสคริปต์
    • การตอบกลับของ OpenAI API ช้ามาก แม้เรียก 3.5 turbo ก็หน่วงเกือบ 10 วินาที จึงเพิ่มการล็อก timestamp เพื่อยืนยันว่าไม่ใช่ข้อผิดพลาดของสคริปต์เอง
    • โมเดล completion บางตัวตัดคำตอบเร็วเกินไป จึงแก้ด้วยการใส่ logit bias ให้โทเคน EOS
    • ไม่สามารถใส่ bias แบบเดียวกันให้โทเคน <|im_end|> (100265) ของโมเดล chat ได้ เพราะ API ส่งข้อผิดพลาดว่า key เกินค่าสูงสุด 100257
      • เนื่องจาก completion ส่วนใหญ่ไปถึงความยาว max token และโมเดล chat ก็ไม่กำหนดแน่นอนกว่ามากอยู่แล้ว จึงมองว่าข้อจำกัดนี้ไม่ใช่ประเด็นหลัก

ผลลัพธ์เชิงประจักษ์

  • ผลลัพธ์ที่ไม่ซ้ำกันจากการลอง 3 รอบ ภายใต้เงื่อนไข N=30, max_tokens=128 (ค่าเฉลี่ย/30)
    • gpt-4: 12, 11, 12 — เฉลี่ย 11.67
    • gpt-3.5-turbo: 4, 4, 3 — เฉลี่ย 3.67
    • text-davinci-003: 3, 2, 4 — เฉลี่ย 3.00
    • text-davinci-001: 2, 2, 2 — เฉลี่ย 2.00
    • davinci-instruct-beta: 1, 1, 1 — กำหนดแน่นอน ผลลัพธ์พังลงเป็นลูปซ้ำ
    • davinci: 1, 1, 1 — กำหนดแน่นอน ผลลัพธ์พังลงเป็นลูปซ้ำ
  • ผลลัพธ์ภายใต้เงื่อนไข max_tokens=256 ก่อนค้นพบปัญหา logit_bias
    • gpt-4: 30, gpt-3.5-turbo: 9, text-davinci-003: 5, text-davinci-001: 2

การตีความผลลัพธ์

  • จำนวนผลลัพธ์ที่ไม่ซ้ำกันของ GPT-4 สูงผิดปกติ และในผลลัพธ์ยาว ๆ แทบจะไม่กำหนดแน่นอนเสมอ
  • โมเดลอื่นที่ไม่ได้พังลงเป็นลูปซ้ำก็มีความไม่กำหนดแน่นอนระดับหนึ่ง สอดคล้องกับคำกล่าวสาธารณะที่ว่า ความไม่เสถียรของการคำนวณบน GPU เป็นสาเหตุส่วนหนึ่งของความสุ่ม
  • คำถามที่ยังเหลืออยู่
    • ยังไม่มีคำอธิบายชัดเจนว่าทำไมความสุ่มจึงค่อย ๆ เพิ่มขึ้นจาก text-davinci-001 ไปถึง gpt-3.5-turbo
    • ยังตัดความเป็นไปได้ไม่ได้ว่าความไม่กำหนดแน่นอนที่รุนแรงของ GPT-4 อาจมาจากจำนวนพารามิเตอร์เพียงอย่างเดียว ไม่ใช่ MoE แต่การที่ Turbo ซึ่งเร็วกว่า กลับไม่กำหนดแน่นอนกว่า davinci นั้นขัดกับคำอธิบายนี้

นัยสำคัญ

เราตามหลังเกินไปมาก

  • หากความไม่กำหนดแน่นอนเป็นคุณสมบัติที่ฝังอยู่ใน batched inference ของ Sparse MoE ข้อเท็จจริงนี้ควรเป็นเรื่องชัดเจนสำหรับคนที่ทำงานในสาขานี้
  • ความจริงที่ว่าผู้ใช้ GPT-4 ส่วนใหญ่ไม่รู้สาเหตุของความไม่เสถียรของ API บ่งชี้ได้ว่า สมมติฐานนี้ผิด หรือมีคนที่เข้าใจโมเดล MoE น้อยเกินไปจนคำอธิบายนี้ไม่ถูกนำขึ้นมาถกเถียงในวงกว้าง
  • Google Deepmind รู้เรื่องนี้ และปฏิบัติต่อมันเป็นเรื่องเล็กน้อยถึงขั้นเขียนไว้เพียงประโยคผ่าน ๆ ในเปเปอร์ จึงเป็นเหตุผลให้มอง Deepmind ในแง่ดีกว่าองค์กรอื่นที่ทำงานเฉพาะกับโมเดล dense

GPT-3.5-Turbo ก็อาจเป็น MoE

  • มีข่าวลือว่า 3.5-turbo ใช้สถาปัตยกรรมเดียวกับ GPT-4 เพียงแต่มีจำนวนพารามิเตอร์น้อยกว่ามาก
  • สถานการณ์ปัจจุบันที่ต้องใช้ 70B พารามิเตอร์ เพื่อให้ถึงประสิทธิภาพระดับ Turbo อธิบายได้ยากด้วยโมเดล dense ตัวเดียว เมื่อพิจารณาขนาดทราฟฟิกและความเร็วที่ OpenAI ต้องรองรับ
  • Turbo เป็นอีกโมเดลเดียวใน API ที่ logprobs ถูกจำกัดไม่ให้เปิดเผย
    • คำอธิบายเดิมคือเพื่อป้องกันการเพิ่มความแม่นยำของ distillation แต่เมื่อดูกรณีอย่าง Orca แล้ว ความน่าเชื่อถือนี้ลดลง
    • การที่ OpenAI ประกาศต่อสาธารณะว่ากำลังทำงานเพื่อรวม logprobs เข้ากับ ChatCompletions ทำให้น้ำหนักเอียงไปทางการตีความว่า “โดยเนื้อแท้แล้วมันสุ่มเกินไปจนทำวิศวกรรมให้เสถียรได้ยาก” มากกว่า “เพื่อป้องกัน distillation”

สรุป

  • เป็นเรื่องที่ทุกคนรู้กันว่าโมเดล GPT ของ OpenAI ไม่กำหนดแน่นอนเมื่อ temperature=0
  • โดยทั่วไปสาเหตุถูกชี้ไปที่ ความไม่แม่นยำของการคำนวณเลขทศนิยมที่ปรับแต่งด้วย CUDA
  • สมมติฐานทางเลือกที่เสนอคือ: batched inference ของโมเดล Sparse MoE คือสาเหตุรากของความไม่กำหนดแน่นอนใน GPT-4 API ซึ่งเป็นสมมติฐานที่อธิบายได้เรียบร้อยกว่าคำอธิบายเดิม
  • พิสูจน์เชิงประจักษ์ว่า การเรียก API ของ GPT-4 (และบางโมเดล 3.5) มีความไม่กำหนดแน่นอนมากกว่าโมเดลอื่นของ OpenAI อย่างชัดเจน
  • จากความเร็ว ความไม่กำหนดแน่นอน และการเอา logprobs ออก จึงคาดว่า GPT-3.5-turbo ก็อาจเป็น MoE เช่นกัน

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

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

 
GN⁺ 2023-08-06
ความคิดเห็นจาก Hacker News

  • โดยปกติแล้ว ข้อผิดพลาดของเลขทศนิยมลอยตัว เป็นแบบกำหนดได้ ดังนั้นถ้ารันการคำนวณเดียวกันสองครั้ง ก็ควรได้ผลลัพธ์เหมือนกันถึงระดับบิต
    ผลลัพธ์จะแตกต่างกันได้ก็ต่อเมื่อมีสถานะอื่นหรือแหล่งกำเนิดเอนโทรปีเข้ามาเกี่ยวข้อง เช่น บัฟเฟอร์ไม่ได้ถูกตั้งต้นเป็น 0 อย่างถูกต้อง, มี race condition, หรือไม่ได้ตั้งค่าแฟลกโหมดการปัดเศษให้สม่ำเสมอ
    พอมองคุณภาพโค้ดที่ถูกเร่งทำกันในระบบนิเวศ AI/ML ก็รู้สึกว่าน่าจะเกิดครบทั้งสามอย่างนี้ หรืออาจมากกว่านั้นด้วยซ้ำ

    • บน GPU ไม่เป็นแบบนั้น: https://www.twosigma.com/articles/a-workaround-for-non-deter...
      ในกรณีนี้ ลำดับการบวกตัวเลขไม่เป็นแบบกำหนดได้เพราะความขนานของ GPU และทำให้ผลลัพธ์ต่างกันได้เล็กน้อย
      ควรหลีกเลี่ยงการไปดูแคลนโค้ดของคนอื่นเมื่อพูดถึงโค้ดที่เขียนอยู่บนระบบที่เราเองก็ไม่คุ้นดี
      CPU ก็อาจเจอเรื่องเดียวกันได้จากการประมวลผลแบบขนาน แต่คำสั่งเดี่ยวส่วนใหญ่ของ CPU เป็นแบบกำหนดได้ ขณะที่ CUDA มี primitive operation ที่ไม่เป็นแบบกำหนดได้
      นี่เป็นการออกแบบโดยตั้งใจเพราะมันเร็วกว่าแบบที่กำหนดได้ และปัญหาคือมีการอธิบายมันราวกับเป็นบั๊กจากโค้ดแย่ๆ
    • เมื่อมีความขนานเข้ามา คำกล่าวนั้นก็อาจไม่จริง
      ตัวอย่างเช่น การดำเนินการเลขทศนิยมลอยตัว บางอย่างอย่างการบวกหรือการคูณไม่เป็นไปตามสมบัติการเปลี่ยนหมู่ ดังนั้นผลลัพธ์จึงอาจเปลี่ยนไปตามลำดับการรันที่ใช้ปิดงาน reduction
      ในงานแบบขนาน บาง implementation ก็ทำให้ลำดับ reduction ไม่เป็นแบบกำหนดได้เพื่อประสิทธิภาพ และทำให้ผลลัพธ์สุดท้ายไม่เป็นแบบกำหนดได้ไปด้วย
    • ในทางคณิตศาสตร์ การคำนวณอาจเป็นแบบกำหนดได้ แต่ อุปกรณ์ทางกายภาพ ที่ใช้คำนวณจริงมีหลายทางที่ทำให้ผลลัพธ์ของซอฟต์แวร์กลายเป็นฟังก์ชันของเวลา
      แค่เรียก GetTimeOfDay() ก็ทำได้แล้ว และการดริฟต์ของความถี่นาฬิการะหว่างโปรเซสเซอร์หลายตัวก็เช่นกัน
    • สงสัยว่าถ้าจำลองปัญหาบิลเลียดวงกลมของ Alhazen เป็น n ขั้น จะได้ผลเหมือนเดิมทุกครั้งที่รันหรือไม่
      https://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
    • ในสเกลใหญ่ แค่ไม่มี หน่วยความจำ ECC ที่ดีพอก็เพียงพอแล้วที่จะทำให้เกิดเอนโทรปี

  • ไม่แน่ใจว่าตัวเองเข้าใจข้อความคัดจากงานอ้างอิงถูกไหม
    มันหมายความว่าการอนุมานที่มีประสิทธิภาพมากขึ้นบางส่วนอาศัยการผสมโทเค็นจากอินพุตที่แยกจากกันโดยสิ้นเชิง เช่น โทเค็นจากอินพุตของผู้ใช้อื่นหรือ? และสัดส่วนการจัดสรรไปยัง "ผู้เชี่ยวชาญ" จะเปลี่ยนไปตามอินพุตอื่นที่บังเอิญอยู่ในชุดเดียวกัน จนผลลัพธ์สุดท้ายต่างออกไปใช่ไหม?
    ถ้าอย่างนั้น มันไม่ใช่แค่การเพิ่มความไม่เป็นแบบกำหนดได้เท่านั้น แต่คุณภาพของคำตอบยังอาจขึ้นกับ จำนวนคำขอพร้อมกัน ที่กำลังแย่งการจัดสรรผู้เชี่ยวชาญชุดเดียวกันด้วย
    เช่น ส่วนของระบบที่แปล/ตีความภาษาฮินดีได้ดี อาจให้ผลแย่ลงในช่วงพีกของอินเดีย เพราะมีอินพุตจำนวนมากเข้ามาแย่งความสามารถเดียวกันพร้อมกัน
    นี่อาจเป็นอีกคำอธิบายหนึ่งว่าทำไมถึงรู้สึกว่าคุณภาพลดลงตามเวลา ก่อนหน้านี้การทดสอบบางอย่างอาจผ่านได้สม่ำเสมอเพราะผู้เชี่ยวชาญที่เกี่ยวข้องยังไม่แออัด แต่ตอนนี้ปริมาณการใช้งานพร้อมกันสูงขึ้นจนการทดสอบเดิมไม่ได้รับทรัพยากรจากผู้เชี่ยวชาญคนนั้นมากพอ
    มันยังอาจเกิดหลุมพรางที่เมื่อผู้เชี่ยวชาญย่อยบางตัวทำได้ดีน่าประทับใจในบางโดเมนช่วงแรก การใช้งานในโดเมนนั้นก็จะยิ่งหลั่งไหลเข้ามา และความแออัดใหม่ทำให้การใช้งานแบบเลียนแบบภายหลังไม่ได้รับการจัดสรรผู้เชี่ยวชาญแบบเดียวกันอีก ส่งผลให้ประสิทธิภาพที่เคยน่าประทับใจในช่วงแรกลดลง
    ถ้าผลกระทบนี้แรงมากและ OpenAI รู้เรื่องนี้แต่ไม่เปิดเผย ก็อาจมองได้ว่าเป็นเหมือนการใช้คุณภาพที่โดดเด่นแต่ไม่เป็นตัวแทนของระบบ Mixture-of-Experts ที่ยังไม่แออัดมาดึงผู้ใช้เข้าไป ก่อนจะส่งมอบผลลัพธ์คุณภาพต่ำกว่าจากระบบที่แออัดขึ้นในภายหลัง

    • ผลลัพธ์ดูเหมือนว่าในการลอง 30 ครั้ง มี คำตอบที่ไม่ซ้ำกัน 12 แบบ เป็นแก่นหลัก ซึ่งไม่ใช่สิ่งที่คาดว่าจะเห็นถ้ามีการผสมโทเค็น
      น่าจะเป็นการจัดกลุ่มแบตช์ต่างกันมากกว่า เวลาหาร 10 แบตช์ออกเป็น 2 กลุ่ม กลุ่มละ 5 แบตช์ คำตอบของฉันอาจเปลี่ยนไปตามว่าพรอมป์ต์ของฉันอยู่ในกลุ่มแรกหรือกลุ่มที่สอง และถ้าอยู่ตำแหน่งเดียวกันภายในแบตช์ก็จะได้คำตอบเหมือนกัน
      ถ้าเป็นแบตช์เดียวกัน คือมีลำดับและตำแหน่งเหมือนเดิม ทั้งแบตช์ก็ยังเป็นแบบกำหนดได้ แต่เมื่อสลับการจัดแบตช์นั้น ความเป็นแบบกำหนดได้ก็หายไป
    • ฟังดูเป็นผลลัพธ์ที่เป็นไปได้ และถ้าจริง โมเดลของ OpenAI อาจเสียเปรียบหนักเมื่อเทียบกับคู่แข่งหรือโมเดลโอเพนซอร์ส
      ตอนนี้เอง ความน่าเชื่อถือ ก็เป็นหนึ่งในอุปสรรคหลักที่ขัดขวางการนำ LLM ไปใช้ในวงกว้างกับเวิร์กโฟลว์งานสำคัญจำนวนมากอยู่แล้ว
      ถ้าข่าวลือว่า GPT-4 ไม่เป็นแบบกำหนดได้และไม่เสถียรโดยเนื้อแท้เป็นเรื่องจริง บริษัทส่วนใหญ่ก็น่าจะเลือกปรับจูน LLM โอเพนซอร์สที่ให้ประสิทธิภาพใกล้เคียงกันสำหรับโดเมนเฉพาะแทน
      โมเดลเฉพาะโดเมนย่อมทำได้ดีกว่าโมเดลทั่วไปเสมอ ดังนั้นทางนั้นยังได้เปรียบด้านประสิทธิภาพมากกว่าอีก

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

    • เห็นด้วย และหวังจริงๆ ว่า Meta จะกำลังทำอะไรในทิศทางนั้น
      วิธีลด อัตราส่วน FLOPs ต่อหน่วยความจำ อย่าง Soft MoE อาจทำให้การอนุมานบน CPU หรืออย่างน้อยบน Apple Silicon มีความเป็นไปได้มากขึ้นอย่างมีนัยสำคัญ
    • แต่มันอาจไม่ดีกับ สภาพแวดล้อมการอนุมาน ที่รันบน GPU สำหรับผู้ใช้ทั่วไปเพียงตัวเดียว

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

    • น่าจะใช่ แต่อย่างไรก็ดี การนำไปใช้โจมตีจริงคงยากมาก

  • นี่เป็นงานที่ยอดเยี่ยมมาก ฉันคัดค้าน MoE อย่างหนักมาตลอดด้วยหลายเหตุผล แต่นี่เป็นครั้งแรกที่ได้เห็น หลักฐานที่น่าเชื่อถือ ไม่ใช่แค่การเล่าซ้ำจากโพสต์ใน Substack หรือข่าวลือ
    ก่อนหน้านี้ไม่รู้เลยว่า GPT-4 ไม่เป็นแบบกำหนดแน่นอน ทั้งที่ใช้อยู่ประมาณวันละ 2 ชั่วโมง
    ตอนนี้เข้าใจแล้วว่าทำไมมองผ่าน ๆ ถึงสังเกตได้ยาก ในความทรงจำมันให้ “ความรู้สึก” คล้ายกันและใช้คำศัพท์คล้าย ๆ กันมาก แต่รูปแบบต่างกันโดยสิ้นเชิง และมีคำสำคัญบางคำเหมือนเดิมแต่ถูกสลับเป็นวลีพ้องความหมาย

    • ฉันไม่ใช่ผู้เชี่ยวชาญด้านงานวิจัย MoE แต่พอเห็นสิ่งที่เขียนไว้ในงาน Soft MoE ก็รู้สึกว่าควรลองตรวจสอบดู
      ถ้าดูตัวอย่าง gist ที่ลิงก์ไว้ ผลลัพธ์ที่ไม่เป็นแบบกำหนดแน่นอนนั้นคล้ายกันมากจริง ๆ: https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
      ส่วนนี้อย่างน้อยก็ไม่น่าแปลกใจนัก เพราะความสุ่มน่าจะถูกจำกัดไว้
      คิดว่าในสักวัน OpenAI น่าจะหาวิธีลดความสุ่มนี้ได้ ยิ่งดูเป็นไปได้เมื่อมีคำมั่นสาธารณะว่าจะนำ logprobs กลับมาเพิ่มใน ChatCompletions
    • ถ้าใช้ GPT-4 ผ่านเว็บแชตวันละสองชั่วโมงก็เป็นไปได้
      แต่ถ้าเป็นการพัฒนาโปรแกรมโดยเรียก API ซ้ำ ๆ ด้วยอินพุตเดิม ก็คงสังเกต ความไม่เป็นแบบกำหนดแน่นอน ได้ยากที่จะมองข้าม
    • อยากรู้ว่าทำไมถึงคัดค้าน MoE อย่างหนัก
    • อยากรู้ว่าเอาไปใช้อะไรบ้าง แล้วใช้ปลั๊กอินเยอะไหม
      คนที่ใช้งานมากขนาดนี้น่าจะมีมุมมองน่าสนใจ โดยเฉพาะเมื่อรวมชุดฟีเจอร์ที่ออกมาในสัปดาห์นี้ด้วย

  • MoE หมายถึง Mixture of Experts หรือก็คือการผสมผู้เชี่ยวชาญ

    • ขอบคุณ นึกว่าเป็น Margin of Error
      กว่าจะมีการขยายความตัวย่อแบบเกือบจะบังเอิญก็เกือบกลางบทความแล้ว เหมือนผู้เขียนตั้งใจเขียนให้คนอ่านที่รู้จัก Mixture of Experts อยู่แล้ว ซึ่งฉันไม่ใช่หนึ่งในนั้น

  • โมเดล davinci-instruct-beta ของ GPT-3.0 ก็คืนค่า logprobs แบบไม่เป็นกำหนดแน่นอนมาตั้งแต่ต้นปี 2021 แล้ว
    นี่เป็นการคาดเดา แต่ตัว CUDA เองก็มีบั๊กเรื่องความไม่เป็นกำหนดแน่นอนอยู่บ่อย ๆ
    text-davinci-001 และ text-davinci-002 ถูกฝึกด้วย FeedMe และ SFT ส่วน text-davinci-003 เป็น RLHF
    ตัวโมเดลเองก็มีความแปรปรวนมากขึ้นเมื่อใช้อุณหภูมิสูง

    • แล้วโมเดลฐานอย่าง davinci กับ code-davinci-002 ล่ะ?

  • ถ้า “โทเค็นเหล่านี้มักแข่งขันกันเพื่อแย่งช่องว่างที่ว่างอยู่ในบัฟเฟอร์ของผู้เชี่ยวชาญ” นั่นหมายความว่านี่คือเหตุผลที่เวลาให้ ChatGPT เขียนโค้ดยาว ๆ มันมักใส่แค่ placeholder ไว้ตรงตำแหน่งฟังก์ชันหรือเปล่า?

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

  • MoE ย่อมาจาก Mixture of Experts