LLM สามารถกลายเป็นคอมพิวเตอร์ได้ไหม? — วิธีรันโปรแกรมโดยตรงภายในทรานส์ฟอร์เมอร์

 (percepta.ai)
16 คะแนน โดย GN⁺ 2026-03-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพื่อก้าวข้ามข้อจำกัดที่ LLM แม้จะแก้โจทย์ระดับโอลิมปิกคณิตศาสตร์ได้ แต่ยังทำงานอย่างการบวกเลขง่ายๆ หรือซูโดกุได้ไม่แม่นยำหากไม่มีเครื่องมือภายนอก จึงมีแนวทาง สร้างคอมพิวเตอร์จริงภายในทรานส์ฟอร์เมอร์
  • แปลงโค้ด C ใดๆ ให้เป็นโทเค็น แล้วให้โมเดล สร้าง execution trace เองโดยตรง นับล้านสเต็ป พร้อมสตรีมบน CPU ได้ที่ความเร็วมากกว่า 30,000 โทเค็นต่อวินาที
  • เทคโนโลยีแกนหลักคือการจำกัดมิติของ attention head ให้เป็น 2D เพื่อเปลี่ยนเป็น การค้นหาเชิงเรขาคณิตบน convex hull แทนที่การสแกนแบบเชิงเส้นด้วยเวลาแบบลอการิทึม
  • ติดตั้ง WebAssembly interpreter ไว้ในค่าน้ำหนักของทรานส์ฟอร์เมอร์ ทำให้ การรันโปรแกรมเกิดขึ้นอย่างโปร่งใส ภายในลูปการถอดรหัสของโมเดล โดยไม่ต้องเรียกใช้เครื่องมือภายนอก
  • ชี้ให้เห็นความเป็นไปได้ในการต่อยอดไปสู่ระบบ AI ที่คอมไพล์โปรแกรมลงในค่าน้ำหนักโดยตรง และ รวม representation ที่เรียนรู้กับอัลกอริทึมที่คอมไพล์แล้วเข้ากับฐานการคำนวณเดียวกัน

ข้อจำกัดด้านการคำนวณของ LLM

  • LLM ล้ำสมัยสามารถแก้โจทย์ระดับ เหรียญทอง ของ International Mathematical Olympiad หรือท้าทายปัญหาคณิตศาสตร์และวิทยาศาสตร์ที่ยังแก้ไม่ตกได้ แต่ยังล้มเหลวในงานคำนวณล้วนๆ
  • แม้แต่การบวกเลขพื้นฐานก็ยังเกิดข้อผิดพลาด และในเบนช์มาร์กอย่าง Sudoku-Bench ก็มี อัตราความสำเร็จในการแก้โดยไม่มีตัวช่วยภายนอกต่ำมาก
  • ปัจจุบันมีวิธีอ้อมอยู่ 2 แบบเพื่ออุดช่องว่างนี้
    • การใช้เครื่องมือ (Tool use): โมเดลเขียนโค้ด แล้ว interpreter ภายนอกเป็นผู้รันและส่งผลลัพธ์กลับมา
    • การ orchestration แบบเอเจนต์: ลูปภายนอกเก็บสถานะระหว่างทาง แยกงานย่อย และเรียกโมเดลซ้ำๆ
  • แนวทางเหล่านี้มีประโยชน์ แต่ก็เน้นให้เห็นข้อจำกัดพื้นฐานว่า ความสามารถในการคำนวณจริงยังคงอยู่นอกตัวโมเดล
  • เปรียบได้กับการที่มนุษย์สร้างเครื่องบินได้ ไม่ได้แปลว่ามนุษย์บินได้เอง
  • โมเดลอาจใช้เหตุผลเกี่ยวกับการคำนวณหรือประสานเครื่องมือได้ แต่ถ้า รันเองไม่ได้ ก็ยังไม่ใช่คอมพิวเตอร์อย่างแท้จริง

วิธีทำให้ทรานส์ฟอร์เมอร์กลายเป็นคอมพิวเตอร์

  • มีงานวิจัยหลายชิ้นพิสูจน์แล้วว่าในเชิงทฤษฎี สถาปัตยกรรมทรานส์ฟอร์เมอร์สามารถจำลอง Turing machine ได้ แต่ พลังในการแทนเชิงทฤษฎีไม่ได้รับประกันประสิทธิภาพการรันในทางปฏิบัติ
  • แทนที่จะใช้แบบจำลองการคำนวณเชิงทฤษฎีล้วนๆ งานนี้เลือกติดตั้ง คอมพิวเตอร์ RAM สมัยใหม่ ไว้ภายในทรานส์ฟอร์เมอร์ โดยแต่ละคำสั่งแมปได้สูงสุด 5 โทเค็น
  • แต่ปัญหาที่ลึกกว่านั้นอยู่ที่กระบวนการถอดรหัสเอง
    • การถอดรหัสแบบ autoregressive มาตรฐานต้องโต้ตอบกับประวัติทั้งหมดที่ยาวขึ้นเรื่อยๆ ในทุกสเต็ป
    • แม้ KV cache จะช่วยหลีกเลี่ยงการคำนวณ key/value เก่าซ้ำ แต่ต้นทุน attention ที่แปรตามขนาดแคชก็ยังคงอยู่
  • เพื่อแก้ข้อจำกัดนี้ จึง จำกัดมิติของ attention head ให้เป็น 2D และเปิดเส้นทางการถอดรหัสที่มีประสิทธิภาพสำหรับ execution trace แบบรันจริง
    • การค้นหา/อัปเดตหลักสามารถทำได้ในเวลา ลอการิทึม ตามความยาวลำดับ
    • ทำให้รันโปรแกรมนับล้านสเต็ปภายในทรานส์ฟอร์เมอร์ได้

ความหมายของการคำนวณ — การใช้เครื่องมือ vs การรันในโมเดล

  • วิธีใช้เครื่องมือแบบเดิม: โมเดลพิมพ์โค้ดอย่าง python -c "print(3+5)" → interpreter ภายนอกรัน → ฉีดผลลัพธ์กลับเข้าไปในสตรีมโทเค็น
  • วิธีของระบบนี้: ติดตั้ง WebAssembly interpreter ไว้ในค่าน้ำหนักของทรานส์ฟอร์เมอร์
    • WebAssembly คือชุดคำสั่งระดับต่ำสำหรับการรันที่รวดเร็วและกำหนดผลได้แน่นอน และยังเป็นคอมไพเลอร์เป้าหมายทั่วไปของ C/C++
    • เมื่อต้องคำนวณ 3 + 5 โมเดลจะปล่อยคำสั่ง wasm (i32.const, i32.add) ออกมาก่อน แล้วสลับเข้าสู่ โหมดถอดรหัสแบบเร็ว เพื่อสร้าง execution trace ทีละสเต็ปด้วยตัวเองโดยตรง
  • ความแตกต่างสำคัญ
    • การใช้เครื่องมือเป็นแบบ ทึบแสง (opaque): โมเดลส่งต่อการควบคุมออกไป แล้วรับคำตอบแบบกล่องดำกลับมา
    • การรันในโมเดลเป็นแบบ โปร่งใส (transparent): ทุกขั้นตอนระหว่างทางปรากฏอยู่ใน trace และโมเดลไม่เคยออกจากลูปการถอดรหัสของตัวเอง

เดโมซูโดกุ — การทดสอบความเครียดของการคำนวณยาวๆ ที่ต้องแม่นยำ

  • แนวทางโครงข่ายประสาทที่ผ่านการฝึกแล้วทำผลงานได้ดีในซูโดกุง่ายๆ แต่ ล้มเหลวโดยสิ้นเชิงในโจทย์ยาก
  • มักมีคำอธิบายทั่วไปว่าโมเดล autoregressive ไม่เหมาะกับปัญหา constraint satisfaction โดยพื้นฐาน แต่ระบบนี้เป็น autoregressive เต็มรูปแบบและยังทำ ความแม่นยำได้ 100%
    • คอขวดที่แท้จริงไม่ใช่พาราไดม์ autoregressive เอง แต่เป็นเพราะซูโดกุยากต้องการ execution trace ที่ยาวมาก และ attention แบบมาตรฐานทำให้การสร้างคอนเท็กซ์ยาวๆ ไม่คุ้มใช้งานจริง
  • ระบบรันตัวแก้ซูโดกุแบบสมบูรณ์ที่คอมไพล์แล้วภายในทรานส์ฟอร์เมอร์ โดย ดำเนินอัลกอริทึมจริงทีละสเต็ป ไม่ใช่ heuristic ที่เรียนรู้มา
  • แก้ “ซูโดกุที่ยากที่สุดในโลก” ของ Arto Inkala ได้อย่างถูกต้องในเวลา ไม่ถึง 3 นาที
  • หากตัวแก้ที่คอมไพล์มาถูกต้อง ก็มี หลักประกันทั่วไป ว่าการรันของทรานส์ฟอร์เมอร์ก็ถูกต้องเช่นกัน

วิธีเข้ารหัสการคำนวณ — trace ที่เพิ่มได้อย่างเดียว

  • เปรียบทรานส์ฟอร์เมอร์แบบ autoregressive ว่าเป็นเครื่องจักรที่อาศัยอยู่ในประวัติของตัวเอง
    • คอมพิวเตอร์แบบดั้งเดิมอัปเดตหน่วยความจำที่แก้ไขได้ แต่ทรานส์ฟอร์เมอร์ไม่มีแนวคิดเช่นนั้น
    • มันประกอบด้วยพรอมป์ตคงที่ (อินพุต/โปรแกรม) และ trace ที่มีแต่จะยาวขึ้นเรื่อยๆ (โทเค็นที่สร้างแล้ว)
  • อุปมาแบบ สมุดบันทึกที่เขียนเพิ่มได้อย่างเดียว
    • บรรทัดแรกๆ คืออินพุต (พรอมป์ต) จากนั้นแต่ละบรรทัดจะบันทึกสเต็ปถัดไปของการคำนวณ
    • ย้อนกลับไปแก้บรรทัดก่อนหน้าไม่ได้ และในแต่ละสเต็ปจะอ้างถึงตำแหน่งเก่าก่อนหน้าได้เพียงไม่กี่ตำแหน่ง
  • อัลกอริทึมจำนวนมากสามารถแทนในรูปแบบ “trace ที่เพิ่มได้อย่างเดียว และในแต่ละสเต็ปอ้างอิงตำแหน่งก่อนหน้าแบบคงที่เพียงไม่กี่จุด” ได้
  • ในระบบนี้ โทเค็นที่โมเดลสร้างจะแทนสถานะที่เปลี่ยนไปของ virtual machine เช่น instruction pointer, การดำเนินการกับหน่วยความจำ/สแตก, เลขคณิต, control flow, เอาต์พุต
  • attention head ทำงานเหมือนอาร์เรย์หนึ่งมิติที่ใช้ร่วมกัน โดยแต่ละโทเค็นเขียนค่าไว้ที่ดัชนีหนึ่งแล้วอ่านค่าจากอีกดัชนีหนึ่ง เป็น primitive แบบ write-after-read
  • attention ยังสามารถคำนวณ ผลรวมสะสม (cumulative sums) ได้ด้วย จึงใช้ติดตาม instruction pointer, ความลึกของสแตก ฯลฯ ในรูปของผลรวมสะสมจากค่าเพิ่มแบบเดลตา

กุญแจสำคัญ: attention ที่เร็วขึ้นแบบยกกำลัง

  • คอมพิวเตอร์จริงอัปเดตสถานะขนาดเล็กด้วยปริมาณงานแทบคงที่ต่อหนึ่งคำสั่ง แต่ทรานส์ฟอร์เมอร์มาตรฐานจะ โต้ตอบกับ prefix ที่ยาว t ในสเต็ปถอดรหัสลำดับที่ t ทำให้ต้นทุนรวมโตแบบกำลังสอง
  • มีการนำ HullKVCache มาใช้เพื่อแก้การระเบิดแบบกำลังสองนี้
    • ในเบนช์มาร์กจริง HullKVCache ทำได้ 31,037 โทเค็น/วินาที (6,747 บรรทัด/วินาที) ขณะที่ KVCache มาตรฐานทำได้ 272 โทเค็น/วินาที (59 บรรทัด/วินาที) ต่างกันราว 114 เท่า
    • แทนที่จะใช้เวลา Θ(t) ต่อสเต็ป ก็ทำการค้นหา attention ได้ในเวลา O(log t)

  • เส้นทางเร็วของ attention แบบ 2D

    • ไม่ได้พยายามเร่งทรานส์ฟอร์เมอร์โดยทั่วไปหรือเสนออาร์กิเท็กเจอร์ใหม่ แต่โฟกัสที่การกำหนดพารามิเตอร์ที่จัดการได้ง่าย โดย จำกัดมิติ head ให้เป็น 2D ใน vanilla transformer
    • ใช้ d_model = 36, n_heads = 18 จึงได้ 2 มิติต่อหนึ่ง head พอดี, มี 7 เลเยอร์, ใช้ nn.MultiheadAttention มาตรฐาน และ gated feedforward network
      • สร้างด้วย PyTorch แบบ vanilla ล้วนๆ โดยไม่มี custom attention kernel หรือ sparse mask
    • จำนวนเลเยอร์ จำนวน head และขนาด embedding สามารถตั้งให้ใหญ่ได้ตามต้องการ ดังนั้นไม่จำเป็นที่ทั้งโมเดลต้องเล็ก
      • ใช้ head มากขึ้นด้วย n_heads = d_model / 2

  • มุมมองเชิงเรขาคณิตของ attention แบบ 2D

    • กลไก attention: โทเค็นในอดีตให้คีย์เวกเตอร์ 2D kⱼ และค่า vⱼ ส่วนสเต็ปปัจจุบันสร้าง query q เพื่อคืนค่า ของคีย์ที่มี inner product สูงสุด (hardmax attention)
    • สิ่งนี้เท่ากับ “supporting point query” แบบคลาสสิกในเรขาคณิตเชิงคำนวณโดยตรง: เมื่อกำหนดทิศทาง q ให้หาจุดบน convex hull ที่อยู่ไกลที่สุดในทิศทางนั้น
    • ขณะสร้างโทเค็นก็รักษาโครงสร้างข้อมูล convex hull ไปพร้อมกัน จึง ค้นหาจากจุดในอดีตทั้งหมดได้ในเวลาแบบลอการิทึม
    • สำหรับการทำงานกับหน่วยความจำ/สแตก จำเป็นต้องค้นหา “ค่าที่ถูกเก็บล่าสุดไว้ที่ดัชนี i” และนี่คือเหตุผลที่ต้องใช้คีย์แบบ 2D
      • เก็บดัชนี j เป็นคีย์ 2D kⱼ = (2j, -j²) แล้ว query ด้วยทิศทาง q = (i, 1) เทอมกำลังสอง -j² จะทำหน้าที่เป็นค่าปรับเพื่อให้ มีแต่การจับคู่ที่ตรงกันพอดีเท่านั้นที่ชนะ
    • attention แบบ 2D ก็เพียงพอต่อความเป็น Turing complete และดังที่บล็อกนี้แสดงให้เห็น มันสามารถแทนคอมพิวเตอร์ RAM ทั้งระบบได้

แผนต่อจากนี้

  • กลไก attention ที่สมบูรณ์ยิ่งขึ้น

    • แม้การติดตั้งปัจจุบันจะใช้ hardmax attention แต่นี่ไม่ใช่ข้อจำกัดพื้นฐาน
    • สามารถประมาณด้วย k-sparse softmax attention ได้: ค้นหาคีย์อันดับต้นๆ k ตัวจาก convex hull ซ้อนกัน แล้วทำ softmax เฉพาะกับคีย์เหล่านั้น ด้วยต้นทุน O(k + log n)
    • เส้นทางเร็วเชิงเรขาคณิตนี้ไม่ได้จำกัดเฉพาะโครงสร้างแบบ executor เท่านั้น และโดยหลักการแล้วสามารถเร่งเวลาถอดรหัสของ ทรานส์ฟอร์เมอร์ทุกตัวที่มี head แบบ 2D ได้
    • ยังขยายไปยัง head แบบ 3D ได้อย่างเป็นธรรมชาติผ่าน 3D convex hull แต่เมื่อมิติสูงกว่านี้ ประสิทธิภาพจะลดลงอย่างรวดเร็ว

  • ฝึกโมเดลขนาดใหญ่ด้วย head แบบ 2D

    • การกำหนดพารามิเตอร์ head แบบ 2D ไม่ได้แปลว่าโมเดลจะต้องเล็กโดยเนื้อแท้ — ใช้ head และเลเยอร์เพิ่มขึ้นเพื่อคง จำนวนพารามิเตอร์รวมใกล้เคียงทรานส์ฟอร์เมอร์มาตรฐาน ได้
    • มีโหมดการใช้งานได้หลายแบบ
      • เป็น เส้นทางเร็วเฉพาะงาน ที่จับคู่กับโมเดลทั่วไปซึ่งช้ากว่า
      • เป็น สถาปัตยกรรมไฮบริดเร็ว/ช้า ภายในระบบเดียว
      • ใช้ speculative decoding โดยให้โมเดล 2D เสนอชุดโทเค็นอย่างรวดเร็ว แล้วโมเดล attention ทั่วไปเป็นผู้ตรวจสอบ
    • เพราะ execution trace เป็นส่วนหนึ่งของ forward pass กระบวนการทั้งหมดจึง ทำดิฟเฟอเรนเชียลได้ (differentiable) — แตกต่างจากเครื่องมือภายนอกโดยพื้นฐาน และเป็นฐานการคำนวณที่ฝึกได้ซึ่งผสานเข้ากับโมเดลใหญ่กว่าได้โดยตรง

  • คอมไพล์โปรแกรมลงในค่าน้ำหนัก

    • ปัจจุบันโมเดลยังเรียนรู้ interpreter ที่เข้ารหัสอยู่ในค่าน้ำหนัก แต่หากขยายเครื่องคอมไพล์ที่สร้างค่าน้ำหนักได้ ก็อาจ คอมไพล์โปรแกรมใดๆ ลงในค่าน้ำหนักโดยตรงโดยไม่ต้องมีลำดับโทเค็น
    • ค่าน้ำหนักเองจะกลายเป็น deployment target ของซอฟต์แวร์ ทำให้โมเดลไม่ได้แค่เรียนรู้พฤติกรรมคล้ายซอฟต์แวร์ แต่ บรรจุตรรกะของโปรแกรมที่คอมไพล์แล้วไว้เป็นส่วนหนึ่งของวงจรภายใน
    • หากคอมไพล์ตรรกะลงในค่าน้ำหนักได้ gradient descent ก็จะไม่ใช่วิธีเดียวในการแก้ไขโมเดลอีกต่อไป — จะมีอีกเส้นทางหนึ่งในการ ใส่โครงสร้าง อัลกอริทึม และหลักประกันลงในเครือข่ายโดยตรง
    • ท้ายที่สุดอาจพัฒนาไปสู่ระบบที่ไม่เพียงเรียนรู้จากประสบการณ์ แต่ยังแก้ไขหรือขยายค่าน้ำหนักของตัวเองเพื่อ เขียนเครื่องจักรภายในใหม่ด้วยตัวเอง

  • ทำให้ระบบ AI เติบโตแบบซอฟต์แวร์

    • เช่นเดียวกับที่ระบบนิเวศซอฟต์แวร์สมัยใหม่วิวัฒน์ผ่านการสะสมของโมดูล abstraction และคอมโพเนนต์ที่นำกลับมาใช้ใหม่ได้ ก็อาจเกิดกระบวนการคล้ายกันที่ เพิ่มความสามารถด้านการคำนวณใหม่ๆ เข้าไปอย่างค่อยเป็นค่อยไป ภายในระบบ AI
    • ฟังก์ชันใหม่สามารถเชื่อมเข้ากับวงจรเดิมได้โดยไม่ต้องฝึกทั้งระบบใหม่ทั้งหมด
    • ระบบ AI ในอนาคตจะไม่เพียงใช้ซอฟต์แวร์ แต่จะ บรรจุซอฟต์แวร์ไว้ภายในตัวเอง และรวม representation ที่เรียนรู้กับอัลกอริทึมที่คอมไพล์แล้วเข้ากับฐานการคำนวณเดียวกัน

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

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

 
GN⁺ 2026-03-14
ความคิดเห็นจาก Hacker News

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

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

    • แต่แนวทางนี้ไม่เหมาะกับการฝึก
      ต่างจาก softmax attention, average-hard attention ไม่สามารถหาอนุพันธ์ตามคีย์และคิวรีได้
      ต่อให้ชดเชยด้วย straight-through estimator ก็ไม่ได้ช่วยให้ backpropagation เร็วขึ้น
    • แม้การฝึกจะยาก แต่ก็มีงานที่เกี่ยวข้องน่าสนใจให้อ้างอิงคือ บทความนี้

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

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

  • สำนวนการเขียนดูเหมือน AI เขียน แต่สารหลักกลับไม่ชัดเจน
    ไม่ชัดว่าการให้โมเดลรันโปรแกรมภายในแทนระบบภายนอกนั้นดีกว่าอย่างไร และได้เปรียบในด้าน ความเร็ว·backpropagation·benchmark ด้านไหนกันแน่

    • แทนที่จะวิจารณ์แค่ว่า “เหมือนข้อความที่ AI เขียน” ก็ควรคุยกันที่เนื้อหาจริงมากกว่า
      บางคนเชื่อว่า symbolic logic เป็นสิ่งจำเป็น แต่ความพยายามแบบนี้ก็อาจมองได้ว่าเป็นแค่ การทดลองที่น่าสนใจ
    • ถ้าดูในตัวงานจริง จะเห็นว่า execution trace เป็นส่วนหนึ่งของ forward pass จึง สามารถหาอนุพันธ์ได้ และส่งกราเดียนต์ผ่านตัวการคำนวณเองได้
      ซึ่งต่างจากการเรียกเครื่องมือภายนอกโดยพื้นฐาน
      อีกทั้งมีต้นทุนการถอดรหัสที่ความซับซ้อน O(k + log n) และถ้าสามารถแก้ปัญหาอย่าง Sudoku ได้แม่นยำ 100% ก็ถือว่ามีนัยสำคัญพอสมควร
      ยังอาจนำแนวทางนี้ไปผสมแบบสไตล์ MoE หรือทดลอง interpreter หลายแบบ เช่น ฝัง VM ที่ใช้ WASM
    • ถ้าตัดการเรียกเครื่องมือภายนอกออกไป ความปลอดภัย ก็จะดีขึ้นด้วย เพราะไม่มีความเสี่ยงที่เครื่องมือภายนอกจะถูกเจาะ
    • ประเด็นสำคัญคือโมเดลสามารถเขียนและแก้ไขโค้ดได้ระหว่างการรัน ซึ่งเป็นการทำงานแบบไดนามิกคล้ายกับ “ช่วงอ๋อ!” ของมนุษย์
    • ความซ้ำของสำนวนอาจเป็นเพียงการอธิบายสำหรับผู้อ่านทั่วไป มนุษย์เองก็พลาดแบบนั้นบ่อยเหมือนกัน

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

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

    • ถ้าจะฮาร์ดโค้ดโปรแกรมขนาดเล็กลงในน้ำหนักของ Transformer อาจดู ALTA เพิ่มได้
    • สงสัยว่าคำว่า “neurosymbolic garbage” หมายถึงอะไร

  • ประโยคนี้คือแก่นสำคัญ:
    “เนื่องจาก execution trace เป็นส่วนหนึ่งของ forward pass จึงสามารถส่งกราเดียนต์ผ่านตัวการคำนวณเองได้”
    กล่าวคือ ต่างจากการเรียกเครื่องมือภายนอก มันจึงกลายเป็น ฐานการคำนวณที่ฝึกได้

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

  • งานวิจัยเหมือนกำลังซ่อนประเด็นสำคัญไว้
    ถ้าจำกัดมิติของ attention head ไว้ที่ 2 ก็จะสามารถค้นหาและอัปเดตโทเค็นได้ด้วย ความซับซ้อนระดับลอการิทึม
    แต่ก็ยังไม่ชัดว่าทำไมกลยุทธ์นี้ถึงใช้เฉพาะกับ “code token”
    การเลือก WASM เป็นเป้าหมายก็ชวนตั้งคำถามในแง่ประสิทธิภาพเช่นกัน

    • ถ้าใช้สองมิติร่วมกับ RoPE และ hard-max attention ก็สามารถทำ การอ้างแอดเดรสแบบสัมพัทธ์ ได้ด้วยเฮดเดียว
    • อย่างไรก็ตาม งานนี้ยังขาดทั้งสมการและรายละเอียดการฝึก และใช้ คำศัพท์ที่ไม่เป็นมาตรฐาน
      ตัวอย่างเช่น การอธิบาย self-attention ว่าเป็น “lookup table” นั้นไม่แม่นยำ
      ในตัวอย่างโค้ดใช้ d_model = 36, n_heads = 18 เพื่อทำ 2D per head แต่ก็ยังไม่ชัดเจนอยู่ดี

  • ไม่มีคำอธิบายเชิงรูปธรรมว่า คอมไพล์ Sudoku solver ไปเป็นน้ำหนักของ Transformer ได้อย่างไร
    ไม่ชัดว่าเป็นการคอมไพล์จากโค้ดไปสู่น้ำหนักโดยตรง หรือว่าเรียนรู้ขึ้นมาผ่านการฝึก

    • จากที่ตีความ น่าจะเป็นการ ฝัง virtual machine แบบง่ายๆ ไว้ในน้ำหนัก แล้วคอมไพล์ WASM runtime ลงไปบนนั้น ก่อนจะรันตัวแก้โจทย์
    • ในตัวงานก็ระบุชัดว่ามีการ ฝึก WASM interpreter

  • น่าสนใจ แต่ก็ยังมีคำถามว่า “แล้วทำไมต้องทำแบบนี้ด้วย”
    สมองมนุษย์ก็จำลอง Turing machine ได้ แต่ช้า จึงต้องใช้เครื่องมือภายนอก
    โมเดลเองก็น่าจะมีประสิทธิภาพกว่าหากใช้เครื่องมือภายนอกเช่นกัน

    • งานเสนอ การฝัง WebAssembly เพื่อลดโอเวอร์เฮดจากการเรียก Python แต่ก็คล้ายกับข้อถกเถียงเรื่อง process vs thread ในยุค 90
      หรือจะฝังภาษาอย่าง Elixir เพื่อให้รันโค้ดที่สั้นกว่าก็ยังได้
    • ข้ออ้างเชิงปรัชญาที่ว่า “ระบบที่คำนวณไม่ได้ ย่อมไม่สามารถเข้าใจการคำนวณได้” ก็ชวนสนใจ
      มันคือแนวคิดที่ว่าโมเดลอาจแก้โค้ดระหว่างรันหรือมี ความสามารถในการดีบัก ได้
    • เพียงแต่งานนี้ยังไม่ได้สำรวจความเป็นไปได้เหล่านั้น และหยุดอยู่แค่ระดับเอนจินสำหรับรัน
    • ถ้าจะคอมไพล์โปรแกรมลงในน้ำหนักจริงๆ การ ทำให้การเรียกเครื่องมือมีประสิทธิภาพขึ้น อาจสมเหตุสมผลกว่า
    • และยังอาจเปรียบได้ว่า ถ้ามนุษย์ฝังเครื่องคิดเลขไว้ในสมองได้ ก็น่าจะเร็วและมีประสิทธิภาพมากกว่า