วิธีเอาชนะความไม่เป็นเชิงกำหนดในการอนุมานของ LLM

 (thinkingmachines.ai)
2 คะแนน โดย GN⁺ 2025-09-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในการอนุมานของ LLM (โมเดลภาษาขนาดใหญ่) มักเกิดปัญหา ความไม่เป็นเชิงกำหนด (nondeterminism) ที่ทำให้แม้ใช้อินพุตและเงื่อนไขเดียวกัน ผลลัพธ์ก็ยังออกมาแตกต่างกันได้
  • เดิมทีเชื่อกันว่าสาเหตุหลักของความไม่เป็นเชิงกำหนดคือ ภาวะพร้อมกัน (concurrency) และ สมบัติไม่เปลี่ยนหมู่ของการคำนวณเลขทศนิยมลอยตัว (non-associativity) ของ floating-point
  • แต่สาเหตุที่แท้จริงคือ การเปลี่ยนแปลงลำดับการคำนวณภายในเคอร์เนล (โค้ดคำนวณ) ที่เกิดจาก การเปลี่ยนแปลงขนาดแบตช์ (batch size)
  • หากทำให้ทุกการคำนวณภายในเคอร์เนลมี ความคงที่ต่อแบตช์ (batch invariance) ก็สามารถรับประกัน ความสามารถในการทำซ้ำ (reproducibility) ได้อย่างสมบูรณ์
  • สามารถสร้างเคอร์เนลที่คงที่ต่อแบตช์สำหรับโอเปอเรชันหลักอย่าง RMSNorm, matmul และ attention ได้ด้วย การคำนวณแบบขนานข้อมูล, split reduction, กลยุทธ์ split ขนาดคงที่ เป็นต้น

บทนำและภาพรวมของปัญหา

  • ความสามารถในการทำซ้ำ (reproducibility) ซึ่งเป็นองค์ประกอบสำคัญของความก้าวหน้าทางวิทยาศาสตร์ กลับไม่ค่อยถูกรักษาไว้ในการอนุมานของ LLM (โมเดลภาษาขนาดใหญ่)
  • แม้จะถามคำถามเดียวกันกับ ChatGPT หลายครั้ง ก็ยังพบได้บ่อยว่าได้ คำตอบที่แตกต่างกัน
  • เหตุผลคือกระบวนการ sampling ผลลัพธ์ของ LLM เป็น การเลือกเชิงความน่าจะเป็น ที่อาศัยการกระจายความน่าจะเป็น
  • อย่างไรก็ตาม แม้จะ ตั้งค่า temperature เป็น 0 ในทางปฏิบัติ LLM API ก็ยัง ไม่เป็นเชิงกำหนดเสมอไป (กล่าวคือ อินพุตเดียวกันไม่ได้ให้ผลลัพธ์เหมือนเดิมทุกครั้ง)
  • ปัญหา ความไม่เป็นเชิงกำหนด นี้ยังคงมีอยู่แม้รันบนไลบรารีอนุมานโอเพนซอร์ส (เช่น vLLM, SGLang) และฮาร์ดแวร์ที่ดูแลเอง

สมมติฐานเดิมและข้อจำกัด

  • สมมติฐานที่เป็นที่รู้จักอย่างกว้างขวาง: ความไม่เป็นเชิงกำหนดเกิดจาก ภาวะพร้อมกัน + สมบัติไม่เปลี่ยนหมู่ของ floating-point
    • การคำนวณ floating-point บน GPU อาจให้ผลต่างกันเล็กน้อยตามลำดับการคำนวณและลำดับการจบงานของเธรด
  • แต่ในความเป็นจริง หากทำการคูณเมทริกซ์แบบเดิมกับข้อมูลเดิมซ้ำ ๆ ก็จะได้ผลลัพธ์ เหมือนกันทุกบิต (bw=bitwise equal) เสมอ
  • การหาสาเหตุที่แท้จริงจึงต้องอาศัยการวิเคราะห์ที่ลึกกว่านี้

การวิเคราะห์เชิงลึกถึงสาเหตุของความไม่เป็นเชิงกำหนดในการอนุมานของ LLM

แก่นแท้ของสมบัติไม่เปลี่ยนหมู่ของ floating-point

  • การคำนวณ floating-point มีความสัมพันธ์แบบ (a+b)+c ≠ a+(b+c)
  • เมื่อนำค่าที่มีขนาดต่างกัน (exponent ต่างกัน) มาคำนวณ จะเกิดการสูญเสียความแม่นยำและข้อมูล ทำให้ ผลลัพธ์เปลี่ยนไปตามลำดับการคำนวณ
  • เนื่องจากลำดับการคำนวณอาจเปลี่ยนได้ หากทำการรวมค่าหลายครั้งแบบสุ่ม ก็จะได้ ผลลัพธ์ที่หลากหลาย (ยืนยันได้จากการทดลอง)
โฆษณา

การเปลี่ยนลำดับการคำนวณในเคอร์เนลและภาวะพร้อมกัน

  • โดยทั่วไปมักชี้ว่า atomic add และปัญหาจากภาวะพร้อมกันคือสาเหตุหลักของความไม่เป็นเชิงกำหนด
  • แต่เคอร์เนลส่วนใหญ่ที่ใช้ในการอนุมานของ LLM (โดยเฉพาะใน forward pass) สามารถทำงานได้โดยไม่ต้องใช้ atomic add
  • ด้วยกลยุทธ์การขนานและ split (reduction) ที่เหมาะสมล่วงหน้า ก็สามารถ คงลำดับการคำนวณเดิมไว้ได้

สาเหตุหลักที่แท้จริง: การขาด "ความคงที่ต่อแบตช์ (batch invariance)"

  • เคอร์เนลแต่ละตัว หากอินพุตเหมือนกัน ก็จะคืนผลลัพธ์เดิมเสมอ (run-to-run deterministic)
  • แต่เนื่องจากคำขอพร้อมกันจากผู้ใช้หลายคน (batch size) เปลี่ยนแปลงอย่างไม่เป็นเชิงกำหนด จึงทำให้ ผลลัพธ์ที่ได้จริงสำหรับแต่ละคำขอไม่คงที่
  • ตาม ขนาดแบตช์ ลำดับการแยกหรือรวมการคำนวณภายในจะเปลี่ยนไป และทำให้เกิดความไม่เป็นเชิงกำหนด
  • กล่าวคือ ประเด็นสำคัญคือ ภาระของเซิร์ฟเวอร์และระดับความขนาน (ขนาดแบตช์) นั้นไม่เป็นเชิงกำหนด

การออกแบบเคอร์เนลที่คงที่ต่อแบตช์และกรณีของโอเปอเรชันหลัก

RMSNorm

  • ใช้กลยุทธ์ data-parallel: ให้หนึ่งคอร์ประมวลผลแต่ละองค์ประกอบของแบตช์แบบอิสระ
  • เมื่อขนาดแบตช์ใหญ่ จะรักษาระดับความขนานได้เพียงพอ ทำให้กลยุทธ์การขนานคงที่และได้ ความคงที่ต่อแบตช์
  • หากขนาดแบตช์เล็กมาก อาจต้องใช้กลยุทธ์ทางเลือกอย่าง split reduction ซึ่งในกรณีนี้จะต้องยอมเสียความคงที่ต่อแบตช์บางส่วน

การคูณเมทริกซ์ (matmul)

  • ใช้กลยุทธ์ data-parallel โดยขนานงานตามแต่ละไทล์ (tile)
  • เพื่อให้เหมาะกับการใช้ tensor core จำเป็นต้องแบ่งเป็นไทล์แบบ 2D และในแบตช์ที่เล็กมากอาจต้องใช้กลยุทธ์พิเศษอย่าง split-K
  • เมื่อใช้กลยุทธ์ split-K อาจทำให้ความคงที่ต่อแบตช์เสียไป
  • แม้ต้องยอมเสียประสิทธิภาพบางส่วน ก็สามารถบังคับให้ใช้คอนฟิกเคอร์เนลเดียวกันเพื่อรักษาลำดับการคำนวณที่สม่ำเสมอ (reproducible) ได้

Attention

  • ใน FlashAttention2 เป็นต้น ใช้กลยุทธ์ ขนานตามทิศทาง query และทำ reduction ของ Key/Value พร้อมกัน เพื่อรักษาความคงที่ต่อแบตช์
  • หากลำดับ reduction เปลี่ยนไปตามขนาดแบตช์หรือการแบ่งซีเควนซ์ (เช่น chunked prefill, prefix caching) ความคงที่ก็จะเสียไป
  • ในกลยุทธ์ split-reduction อย่าง split-KV (FlashDecoding) จะคงลำดับการคำนวณให้เดิมโดย ตรึงขนาด split ให้คงที่ (fixed split-size)
  • ในการทำงานภายใน ต้องไม่แยกจัดการ key/value cache กับโทเคนใหม่คนละแบบ แต่ต้องรักษาเลย์เอาต์ของ key/value ให้สม่ำเสมอในทุกการคำนวณ
โฆษณา

การติดตั้งใช้งาน

  • มีเดโมการอนุมานแบบกำหนดได้โดยใช้ batch-invariant kernel ร่วมกับ vLLM และ torch.Library
  • สามารถดู kernel ทดแทนสำหรับโอเปอเรชันที่เกี่ยวข้องได้จาก GitHub repo (thinking-machines-lab/batch-invariant-ops)

การทดลองและประสิทธิภาพ

การทดลองวัดความไม่เป็นเชิงกำหนด

  • ใช้โมเดล Qwen/Qwen3-235B-A22B-Instruct-2507 สร้างผลลัพธ์ 1000 ครั้งด้วยพรอมป์เดียวกัน (“Tell me about Richard Feynman”) ภายใต้เงื่อนไข temperature 0
  • ได้ คำตอบที่แตกต่างกัน 80 แบบ (แม้เป็นพรอมป์เดียวกันก็ยังมีความไม่เป็นเชิงกำหนด)
  • 102 โทเคนแรกเหมือนกันทั้งหมด และเริ่มแยกครั้งแรกที่โทเคนลำดับที่ 103 (“Queens, New York” vs “New York City”)
  • เมื่อใช้ batch-invariant kernel ทั้ง 1000 ครั้งได้ผลลัพธ์เหมือนกันทั้งหมด ทำให้ได้ความสามารถในการทำซ้ำอย่างสมบูรณ์

การประเมินประสิทธิภาพ

  • ใช้ GPU 1 ตัว รัน Qwen-3-8B และส่งคำขอ 1000 รายการที่มีซีเควนซ์ยาว 90~110 แต่ละรายการ
    • vLLM ปกติ: 26 วินาที
    • deterministic vLLM แบบยังไม่ปรับแต่ง: 55 วินาที
    • เมื่อนำ attention kernel ที่ปรับปรุงแล้วมาใช้: 42 วินาที
  • แม้การปรับแต่งยังไม่สมบูรณ์ แต่ยัง คงระดับประสิทธิภาพที่ใช้งานได้จริง

คุณค่าใน on-policy RL

  • เดิมทีความแตกต่างเล็กน้อยทางตัวเลขระหว่าง training กับ inference ทำให้ on-policy RL ไม่สามารถนำไปใช้ได้อย่างแม่นยำ
  • หากทำให้การอนุมานเป็นแบบกำหนดได้ ก็จะสามารถทำให้ทั้ง sampling และ training เหมือนกันทุกบิต (bitwise identical) และทำให้ on-policy RL ที่แท้จริงเป็นไปได้
  • ยืนยันได้ว่าผลลัพธ์ ตรงกันอย่างสมบูรณ์ ในเมตริกสำคัญ เช่น KL-divergence และ reward
โฆษณา

บทสรุป

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

ข้อมูลการอ้างอิง

  • เมื่อต้องการอ้างอิงงานวิจัยนี้ ให้ใช้ข้อมูลต่อไปนี้
He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference", 
Thinking Machines Lab: Connectionism, Sep 2025.

หรือ

@article{he2025nondeterminism,
  author = {Horace He and Thinking Machines Lab},
  title = {Defeating Nondeterminism in LLM Inference},
  journal = {Thinking Machines Lab: Connectionism},
  year = {2025},
  note = {https://thinkingmachines.ai/blog/…},
  doi = {10.64434/tml.20250910}
}

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

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

 
GN⁺ 2025-09-12
ความเห็นจาก Hacker News

  • แม้จะแก้ปัญหาความไม่เป็นเชิงกำหนดแบบ "ในทางทฤษฎี" ได้สำหรับคู่ข้อมูลนำเข้า-ผลลัพธ์แบบปิดอย่างสมบูรณ์ ก็ยังเหลือปัญหาความไม่เป็นเชิงกำหนดจริงอีกสองแบบ คือ อินพุตเดียวกันอาจให้ผลลัพธ์ต่างกันตามบริบทก่อนหน้า และอินพุตที่ถูกดัดแปลงเล็กน้อยอาจไม่ให้ผลลัพธ์ที่ควรถูกดัดแปลงตามอย่างถูกต้อง ตราบใดที่ปัญหาเหล่านี้ยังไม่ถูกแก้ ความไม่เป็นเชิงกำหนดในระบบปิดก็ไม่ได้ช่วยมากนัก ยกเว้นในกรณีที่แค่ตาราง lookup ก็เพียงพออยู่แล้ว และก็ยากที่จะพิสูจน์อะไรจาก unit test หรือชุดประเมินผลที่ "แม่นยำ" สำหรับอินพุตที่ยังไม่เคยทดสอบ

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

      • ต้องการให้ประโยค prompt หลายแบบที่มีความหมายเหมือนกัน (เช่น "What is the capital of France" กับ "What is France's capital") ให้คำตอบเดียวกันเป๊ะ
      • ต้องการให้บริบทก่อนหน้าไม่ส่งผลต่อผลลัพธ์ ถ้ามันไม่ได้มีปฏิสัมพันธ์กับคำถามจริง ๆ ตัวอย่างเช่น prompt "what is 2 + 2" ควรได้คำตอบเดิมเสมอ และไม่ควรเปลี่ยน เว้นแต่ในบริบทจะกำหนดไว้ว่า 2 + 2 = 5 ข้อเรียกร้องแบบนี้แสดงให้เห็นว่ากำลังเข้าใจธรรมชาติของ LLM ผิดไป

    • ทำไมการที่ 'บริบทก่อนหน้า' ทำให้ผลลัพธ์ต่างกันถึงเป็นปัญหา? ถ้าบริบทไม่ส่งผลต่อผลลัพธ์ ก็ทิ้งบริบทไปเลยก็ได้ แล้วจะอยากได้พฤติกรรมแบบนั้นไปทำไม? ถ้าเป็นเครื่องมือจริง เราก็คาดหวังให้มันตอบสนองต่างกันตามเจตนาหรือการสลับโหมดของเรา (เช่น ใน vim เมื่อสลับไป insert mode แล้วพฤติกรรมเปลี่ยน) และก็อยากให้ความฉลาดทำงานแบบนั้นด้วย การเพิกเฉยต่อบริบทกลับให้ความรู้สึกใกล้กับ confirmation bias แบบสุดขั้วมากกว่า

    • มีประโยชน์มากเวลาไล่หาวิธีทำให้บั๊กเกิดซ้ำ

    • ผมเห็นด้วยจนถึงจุดที่บอกว่า "ไม่ได้ช่วยมาก" น่าจะหมายถึง "มันไม่ได้แก้ปัญหานี้ได้หมดจด"

  • สงสัยว่าทำไมผู้คนถึงให้ความสำคัญกับความเป็นเชิงกำหนดมากนักในระบบเชิงความน่าจะเป็น จากมุมผู้ใช้ ต่อให้ระบบตอบอินพุต "How do I X?" ด้วยคำตอบเชิงกำหนดเดิมทุกครั้ง แต่มันกลับตอบ "how do i x?", "how do I x", "how do I X??" ซึ่งมีความหมายเดียวกันด้วยผลลัพธ์ที่ต่างกันโดยสิ้นเชิง ก็แทบไม่มีประโยชน์ สิ่งที่ LLM ต้องการจริง ๆ คือความสามารถในการรับประกันว่าอินพุตที่เทียบเท่ากันในเชิงความหมายจะให้เอาต์พุตที่เทียบเท่ากันในเชิงความหมายเสมอ ซึ่งเป็นแนวคิดที่ต่างจากความเป็นเชิงกำหนดแบบที่เราพูดถึงในอัลกอริทึมโดยทั่วไปอย่างสิ้นเชิง

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

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

    • ผมกำลังทำโปรเจกต์ที่ฝังข้อมูลด้วยสเตกาโนกราฟีในเอาต์พุตของ LLM: innocuous เราดึงมาใช้เพียงประมาณ 10 โทเค็นอันดับบนสุดของโมเดล และทดสอบเป็นหลักกับโมเดล 8B บน CPU ดังนั้นจึงไม่ได้กังวลมากนักว่าอันดับโทเค็นจะเปลี่ยนเพราะฮาร์ดแวร์ แต่ก็ตั้งใจว่าจะใส่เงื่อนไข guard แบบ eventually ไว้ด้วย เพื่อป้องกันไม่ให้ตัวเลือกเปลี่ยนเพราะการสูญเสียความละเอียดเล็กน้อย

    • อาจมีประโยชน์มากสำหรับลูกค้าแพลตฟอร์ม AI คุณสามารถรัน prompt เดิมด้วย temperature 0 หลายครั้งเพื่อตรวจว่าผลลัพธ์เหมือนกันทุกครั้งหรือไม่ เพื่อยืนยันว่าผู้ให้บริการ AI ไม่ได้แอบสลับโมเดล PRO เป็นโมเดลที่ถูกกว่าตัวอื่น

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

  • (มีประสบการณ์ทำงานกับ JAX/XLA) เรื่องนี้เป็นที่รู้กันพอสมควร ผมเองก็เคยเจอปรากฏการณ์นี้หลายครั้งเช่นกัน (ความแปรปรวนระดับแบตช์) และได้รับคำอธิบายใน issue เหล่านี้: penzai issue #82, คอมเมนต์ใน jax issue

    • ผมคิดว่านี่ควรเป็นคอมเมนต์อันดับบนสุด

  • บางครั้งสาเหตุของความไม่เป็นเชิงกำหนดก็มาจากรายละเอียดของการติดตั้งใช้งาน ตัวอย่างเช่น ในซอร์สโค้ดของ GPT-2 ถึงจะตั้ง temperature เป็น 0 ใน GUI แต่ค่าที่ส่งเข้าไปจริงกลับเป็น "epsilon" (ค่าจำนวนน้อยมาก) ที่ไม่ใช่ 0 ซึ่งก็สมเหตุสมผลเพราะช่วยหลีกเลี่ยงข้อผิดพลาด division by zero ความไม่เป็นเชิงกำหนดนั้น "ไร้ประโยชน์" สำหรับแอปพลิเคชันจำนวนมาก นี่เป็นปัญหาเก่าในโมเดลหัวข้อ LDA ด้วย โดยเฉพาะในแวดวงกฎหมาย การเงิน และการกำกับดูแล การใช้วิธีที่ไม่เป็นเชิงกำหนดอาจผิดกฎหมายได้ หรือไม่ก็อาจสร้างภาระเพิ่มเติมที่ไม่ต้องการ (เช่น ต้องเก็บบันทึกภาพหน้าจอทุกครั้งเพื่อให้สามารถย้อนตรวจได้ทีละขั้นว่าเกิดอะไรขึ้น)

  • มีการพูดถึง "การทำงานร่วมกับคนอื่นที่ Thinking Machines" ทำให้นึกถึงช่วงที่เคยเห็นเครื่องนั้นด้วยตาตัวเอง ตอนลูกบาศก์ LED สีแดงส่องแสงอยู่หน้า MIT AI Lab Richard Feynman ทำงานที่ยอดเยี่ยมจริง ๆ และมีบทความเกี่ยวกับเรื่องนี้ Feynman and the Connection Machine. ในสหรัฐฯ เครื่องหมายการค้า “THINKING MACHINES” ไม่ได้จดในชื่อ Hillis แต่จดในชื่อบริษัทที่เขาก่อตั้ง และถูกยกเลิกไปในปี 1998–1999 บริษัทล้มละลายในปี 1994 และทรัพย์สินถูกโอนไปยัง Sun Microsystems (ต่อมาคือ Oracle) เป็นต้น ส่วน Thinking Machines Lab Inc. ของ Amira Murati ได้ยื่นขอเครื่องหมายการค้า “THINKING MACHINES” ใหม่ในปี 2025

    • ทุกครั้งที่เห็นชื่อบริษัทนี้ ผมก็สับสนแบบนี้ทุกที

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

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

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

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

    • คุณกำลังพูดถึงบริษัท “Thinking Machines” ที่หายไปตั้งแต่ปี 1994 ใช่ไหม? ผมต้องไปค้นถึงได้รู้ และมันก็ไม่ได้ดังขนาดนั้น เลยไม่น่าจะมีเจตนาแบบนั้น ผมแค่มองว่ามันเป็นชื่อที่เท่และเข้าใจง่าย

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

  • เนื้อหาน่าสนใจมาก สำหรับคนที่ยังไม่รู้ บริษัทนี้คือบริษัทที่ Mira Murati อดีต CTO ของ OpenAI เป็นผู้ก่อตั้ง