โมเดลปฏิสัมพันธ์ - แนวทางที่ขยายขนาดได้สำหรับความร่วมมือระหว่างมนุษย์กับ AI

 (thinkingmachines.ai)
4 คะแนน โดย GN⁺ 4 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • แทนที่จะเป็น harness ภายนอก ตัวโมเดลรับและส่งออกเสียง วิดีโอ และข้อความพร้อมกันแบบเรียลไทม์ เพื่อทำงานร่วมกับมนุษย์อย่างเป็นธรรมชาติ
  • โมเดลแบบผลัดตาเดิมมี คอขวดด้านการทำงานร่วมกัน เพราะต้องรอให้ผู้ใช้พูดจบก่อน และระหว่างที่กำลังสร้างคำตอบก็ไม่สามารถรับอินพุตใหม่ได้
  • ด้วยการออกแบบ microturn ระดับ 200ms ระบบจึงประมวลผลอินพุตและเอาต์พุตเป็นสตรีมต่อเนื่อง รองรับโหมดปฏิสัมพันธ์หลากหลาย เช่น การแทรกจังหวะพูด การพูดพร้อมกัน และการตอบสนองทางภาพ
  • ระบบใช้ Interaction Model สำหรับบทสนทนาแบบเรียลไทม์ และ Background Model สำหรับการให้เหตุผลระยะยาวและการใช้เครื่องมือ โดยทั้งสองแชร์บริบทเดียวกัน
  • เมื่อความสามารถในการโต้ตอบถูกฝังอยู่ในตัวโมเดลเอง การสเกลจึงทำให้มันไม่เพียงฉลาดขึ้น แต่ยังเป็น ผู้ร่วมงานที่ดีกว่าเดิม ด้วย

คอขวดของการทำงานร่วมกันและเป้าหมายของ Interaction Model

  • Thinking Machines Lab เปิดตัวพรีวิวงานวิจัย Interaction Model ที่ให้ตัวโมเดลเองจัดการปฏิสัมพันธ์ แทนการพึ่งพา harness ภายนอก
  • เป้าหมายคือทำให้ไม่ใช่แค่ความฉลาดของ AI เท่านั้นที่สเกลได้ แต่รวมถึง ความสามารถในการโต้ตอบ ด้วย โดยให้โมเดลรับเสียง วิดีโอ และข้อความอย่างต่อเนื่อง และคิด ตอบสนอง และลงมือทำแบบเรียลไทม์
  • ปัจจุบัน งานวิจัยและอินเทอร์เฟซ AI จำนวนมากให้ความสำคัญกับความสามารถของ AI ในการทำงานได้นานอย่างอัตโนมัติ แต่ในงานแบบ hands-on-keyboard ที่มนุษย์ยังคงแทรกแซงตลอด โมเดลอาจดูช้าเกินไปจนทำให้คุณค่าของมันแสดงออกมาได้น้อยลง
    • ไม่ได้ถูกปรับให้เหมาะกับการที่มนุษย์อยู่ในลูปตลอดเวลา
  • ในการทำงานจริง การระบุความต้องการทุกอย่างให้ครบตั้งแต่ต้นแล้วปล่อยให้ระบบทำต่อเองเป็นเรื่องยาก และกระบวนการทำงานร่วมกันที่มนุษย์คอยให้คำชี้แจงและฟีดแบ็กระหว่างทางช่วยให้ได้ผลลัพธ์ที่ดีกว่า
  • โมเดลแบบผลัดตาเดิมต้องรอจนผู้ใช้ป้อนข้อมูลเสร็จ และระหว่างที่โมเดลกำลังสร้างผลลัพธ์ก็รับข้อมูลใหม่ไม่ได้ จึงรับรู้โลกเหมือนเป็น เธรดเดียว
    • โครงสร้างนี้ทำให้ทั้งขอบเขตที่ความรู้ เจตนา และวิจารณญาณของผู้ใช้จะถูกส่งต่อไปยังโมเดล และขอบเขตที่มนุษย์จะเข้าใจงานของโมเดล แคบลง
  • Thinking Machines Lab มองว่าการแก้คอขวดนี้ต้องอาศัย การโต้ตอบแบบเรียลไทม์ในทุกโมดาลิตี และ AI ควรปรับให้เข้ากับวิธีทำงานของมนุษย์ แทนที่จะให้มนุษย์ต้องปรับตัวเข้าหาอินเทอร์เฟซของ AI
  • โมเดล AI ที่มีอยู่ส่วนใหญ่ใช้ harness ที่ประกอบจากหลายคอมโพเนนต์เพื่อเลียนแบบการทำงานแบบต่อเนื่อง มัลติโหมด และพร้อมกัน แต่ตาม The Bitter Lesson ระบบที่สร้างด้วยงานฝีมือเช่นนี้อาจพ่ายแพ้ต่อการขยายตัวของความสามารถทั่วไป
  • หากต้องการให้ความสามารถในการโต้ตอบสเกลไปพร้อมกับความฉลาด มันต้องเป็น ฟังก์ชันภายในของโมเดล และเมื่อขยายโมเดลให้ใหญ่ขึ้น มันไม่ควรแค่ฉลาดขึ้น แต่ควรเป็นผู้ร่วมงานที่ดีขึ้นด้วย

ความสามารถที่การโต้ตอบภายในโมเดลเปิดทางให้

  • การจัดการบทสนทนาอย่างเป็นธรรมชาติ

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

  • การแทรกแซงด้วยเสียงและภาพ

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

  • การพูดพร้อมกัน

    • ผู้ใช้และโมเดลสามารถพูดพร้อมกันได้ ซึ่งมีประโยชน์ในสถานการณ์อย่าง การแปลแบบเรียลไทม์

  • การรับรู้เวลา

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

  • เรียกใช้เครื่องมือ ค้นหา และสร้าง UI ไปพร้อมกัน

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

แนวทาง

  • ไมโครเทิร์นที่จัดแนวตามเวลา

    • Interaction Model แบ่งสตรีมอินพุต·เอาต์พุตต่อเนื่องออกเป็น ไมโครเทิร์น และจัดโครงสร้างปฏิสัมพันธ์ตามเวลา
    • โมเดลแบบเทิร์นจะมองลำดับโทเค็นที่สลับกันไปมา แต่ Interaction Model ที่รับรู้เวลาจะมองสตรีมไมโครเทิร์นต่อเนื่อง จึงยังคงมีความเงียบ การทับซ้อน และการแทรกบทอยู่ในบริบทของโมเดล
    • โมเดลรักษาสถานะการแลกเปลี่ยนแบบสองทางกับผู้ใช้อย่างต่อเนื่อง และทำทั้งการรับรู้กับการตอบสนองไปพร้อมกัน
    • งานหุ่นยนต์และการขับขี่อัตโนมัติตั้งอยู่บนสมมติฐานของการทำงานแบบเรียลไทม์เพราะข้อกำหนดของโลกกายภาพ และโมเดลออดิโอแบบ full-duplex อย่าง Moshi, PersonaPlex, nemotron-voicechat, Seeduplex ก็เป็นตัวอย่างของปฏิสัมพันธ์แบบสองทางและต่อเนื่องเช่นกัน

  • องค์ประกอบของระบบ

    • ระบบประกอบด้วย Interaction Model ที่รับรู้เวลา ซึ่งคงการมีอยู่แบบเรียลไทม์ไว้ และ Background Model แบบอะซิงโครนัส ที่รับหน้าที่การให้เหตุผลต่อเนื่อง การใช้เครื่องมือ และงานระยะยาว
    • เมื่อการให้เหตุผลที่ลึกขึ้นไม่สามารถสร้างได้ในทันที Interaction Model จะมอบหมายไปยัง Background Model
    • แม้อยู่ระหว่างการมอบหมาย Interaction Model ก็ยังคงอยู่ต่อหน้าผู้ใช้ คอยตอบคำถามต่อเนื่อง รับอินพุตใหม่ และรักษาบริบทการสนทนา
    • ผลลัพธ์ของ Background Model จะถูกสตรีมกลับมาทันทีที่สร้างได้ และ Interaction Model จะผสานผลนั้นเข้าในการสนทนาในจังหวะที่สอดคล้องกับพฤติกรรมปัจจุบันของผู้ใช้
    • ทั้งสองระบบใช้บริบทร่วมกัน โดยผู้ใช้สามารถใช้ทั้งการวางแผน การใช้เครื่องมือ และเวิร์กโฟลว์แบบเอเจนต์ของโมเดลให้เหตุผลได้ ภายใต้ความหน่วงของการตอบสนองในระดับโมเดลที่ไม่ใช้การให้เหตุผล
    • ทั้ง Background Model และ Interaction Model ต่างก็มีความฉลาด และแม้ใช้ Interaction Model เพียงอย่างเดียวก็ยังทำผลงานได้แข่งขันได้ในเบนช์มาร์กด้านปฏิสัมพันธ์และความฉลาด

  • โครงสร้างของ Interaction Model

    • จุดตั้งต้นของการออกแบบคือ ออดิโอและวิดีโอต่อเนื่อง ซึ่งโดยธรรมชาติเป็นแบบเรียลไทม์ ข้อความรอได้ แต่การสนทนาแบบเรียลไทม์รอไม่ได้
    • โมเดลรับบางส่วนย่อยใดก็ได้ของข้อความ ออดิโอ และวิดีโอเป็นอินพุต และทำนายข้อความกับออดิโอ
    • โมเดลทำงานเป็นไมโครเทิร์น โดยสลับไปมาระหว่างการประมวลผลอินพุตยาว 200ms และการสร้างเอาต์พุตยาว 200ms อย่างต่อเนื่อง
    • แทนที่จะกินยูสเซอร์เทิร์นที่เสร็จสมบูรณ์และสร้างคำตอบที่เสร็จสมบูรณ์ โมเดลจะประมวลผลทั้งโทเค็นอินพุตและโทเค็นเอาต์พุตเป็นสตรีม
    • วิธีนี้ทำให้เกิดความพร้อมกันเกือบเรียลไทม์ของหลายโมดาลิตีอินพุต·เอาต์พุต และลบเส้นแบ่งเทิร์นแบบประดิษฐ์ที่โมเดลต้องคอยปฏิบัติตาม
    • ระบบเรียลไทม์แบบเดิมจำนวนมากพยายามทำให้โมเดลแบบเทิร์นดูเหมือนเรียลไทม์ โดยใช้ฮาร์เนสอย่างการตรวจจับกิจกรรมเสียงพูด (VAD) เพื่อคาดเดาขอบเขตของเทิร์น
    • คอมโพเนนต์ฮาร์เนสเหล่านี้มีความฉลาดต่ำกว่าตัวโมเดลเอง จึงจำกัดโหมดปฏิสัมพันธ์อย่างการแทรกบทเชิงรุกหรือการตอบสนองต่อสัญญาณภาพ
    • ใน Interaction Model โหมดปฏิสัมพันธ์เหล่านี้จึงไม่ใช่ฮาร์เนสพิเศษอีกต่อไป แต่เป็นกรณีพิเศษที่โมเดลสามารถทำได้ และคุณภาพสามารถดีขึ้นได้ตามการขยายขนาดโมเดลและข้อมูลฝึก

  • การผสานล่วงหน้าแบบไม่มีเอนโค้ดเดอร์

    • เลือกสถาปัตยกรรมที่ใช้ การประมวลผลล่วงหน้าน้อยที่สุด แทนการประมวลผลออดิโอและวิดีโอด้วยเอนโค้ดเดอร์อิสระขนาดใหญ่
    • โมเดล omnimodal จำนวนมากต้องฝึกเอนโค้ดเดอร์คล้าย Whisper หรือดีโค้ดเดอร์คล้าย TTS แยกต่างหาก แต่โมเดลนี้รับสัญญาณออดิโอในรูป dMel และแปลงด้วยชั้น embedding แบบเบา
    • dMel อ้างอิงตาม Bai, et al. 2024
    • ภาพถูกแบ่งเป็น แพตช์ 40x40 แล้วเข้ารหัสด้วย hMLP
    • ใช้ flow head สำหรับออดิโอดีโค้ดเดอร์
    • ทุกคอมโพเนนต์ถูกฝึกร่วมกับทรานส์ฟอร์เมอร์ตั้งแต่ต้น

  • การเพิ่มประสิทธิภาพการอนุมาน

    • ระหว่างการอนุมาน ชังก์ 200ms ต้องการ prefill และ decode ขนาดเล็กบ่อยครั้ง และแต่ละขั้นต้องผ่านเงื่อนไขด้านความหน่วงที่เข้มงวด
    • ไลบรารีอนุมาน LLM เดิมไม่ได้ปรับให้เหมาะกับสถานการณ์ที่มี prefill ขนาดเล็กเกิดขึ้นบ่อย จึงมีโอเวอร์เฮดสูงในแต่ละเทิร์น
    • เพื่อแก้ปัญหานี้ จึงมีการทำ streaming session โดยเมื่อไคลเอนต์ส่งแต่ละชังก์ 200ms มาเป็นคำขอแยก เซิร์ฟเวอร์อนุมานจะต่อชังก์เหล่านั้นเข้ากับลำดับต่อเนื่องในหน่วยความจำ GPU
    • วิธีนี้หลีกเลี่ยงการจัดสรรหน่วยความจำใหม่บ่อยครั้งและการคำนวณเมทาดาทา และได้ส่งฟังก์ชันนี้เวอร์ชันหนึ่ง upstream ไปยัง SGLang
    • ยังมีการปรับ kernel ให้เหมาะตาม shape และความหน่วงที่พบในการเสิร์ฟแบบสองทาง
    • สำหรับ MoE kernel ใช้กลยุทธ์ gather+gemv แทน grouped gemm มาตรฐาน เช่นเดียวกับงานก่อนหน้าของ PyTorch และ Cursor

  • การจัดแนว Trainer-Sampler

    • trainer-sampler alignment ระดับบิตมีประโยชน์ต่อเสถียรภาพของการฝึกและการดีบักคอมโพเนนต์ของระบบ
    • มีการใช้งาน batch-invariant kernels โดยมีโอเวอร์เฮดด้านประสิทธิภาพรวมต่ำกว่า 5%
    • ใช้ NVLS สำหรับ all-reduce และ reduce-scatter เพื่อทำเคอร์เนลสื่อสารความหน่วงต่ำแบบกำหนดแน่นอนบน Blackwell
    • เคอร์เนลนี้ทำให้บรรลุการจัดแนวระดับบิตได้แม้ข้ามกลยุทธ์ parallelization ที่ต่างกัน เช่น Sequence Parallelism และ Tensor Parallelism
    • โจทย์หลักของ Attention คือ Split-KV ซึ่งโดยทั่วไปอาจสร้างความไม่ตรงกันของลำดับการสะสมระหว่าง decode กับ prefill
    • หากเลือก split ให้สม่ำเสมอระหว่าง decode กับ prefill ก็จะรักษาลำดับการสะสมไว้ได้ ตัวอย่างเช่น ประมวลผล SM แบบ left-aligned ทีละ 4096 โทเค็น เพื่อให้ได้ประสิทธิภาพทั้งฝั่ง prefill และ decode

  • การประสานงานของสองโมเดล

    • เมื่อ Interaction Model มอบหมายงาน จะส่ง แพ็กเกจบริบทที่สมบูรณ์และเข้มข้น ซึ่งรวมทั้งบทสนทนาทั้งหมดไปด้วย ไม่ใช่เพียงคิวรีเดี่ยวแบบแยกขาด
    • ผลลัพธ์ของ Background Model จะถูกส่งกลับมาทันทีที่สร้างได้ และ Interaction Model จะร้อยเรียงผลนั้นเข้าไปในการสนทนาในจังหวะที่สอดคล้องกับพฤติกรรมปัจจุบันของผู้ใช้ แทนการสลับบริบทอย่างฉับพลัน

  • ความปลอดภัย

    • ปฏิสัมพันธ์แบบเรียลไทม์กดดันด้านความปลอดภัยต่างจากการแลกเปลี่ยนแบบเทิร์น ดังนั้นงานจึงมุ่งไปที่ การปฏิเสธให้สอดคล้องกับโมดาลิตี และ ความทนทานของบทสนทนาระยะยาว
    • เพื่อให้การปฏิเสธด้วยเสียงฟังเป็นธรรมชาติแบบภาษาพูด จึงใช้โมเดล TTS สร้างข้อมูลฝึกสำหรับการปฏิเสธในขอบเขตหัวข้อที่ไม่อนุญาตและการปฏิเสธเกินจำเป็น
    • มีการปรับขอบเขตการปฏิเสธให้ชอบถ้อยคำที่เป็นธรรมชาติ แต่ไม่ลดความหนักแน่นลง
    • เพื่อเพิ่มความทนทานในการสนทนา speech-to-speech ที่ยาวนาน จึงสร้างข้อมูลการปฏิเสธหลายเทิร์นด้วยฮาร์เนส red-team อัตโนมัติ
    • และยังคงรักษาความใกล้เคียงของพฤติกรรมกับการปฏิเสธแบบข้อความไว้ด้วย

เกณฑ์มาตรฐานและการประเมิน

  • สติปัญญาและความสามารถในการโต้ตอบ

    • ชื่อโมเดลคือ TML-Interaction-Small และถูกนำเสนอว่าเป็นโมเดลแรกที่มีทั้งสติปัญญาสูง การทำตามคำสั่งได้ดี และ ความสามารถในการโต้ตอบ
    • คุณภาพการโต้ตอบวัดด้วย FD-bench
    • FD-bench v1.5 กำหนดให้โมเดลต้องตอบสนองในช่วงเวลาที่กำหนดเมื่อได้รับเสียงที่บันทึกไว้ล่วงหน้า และวัดพฤติกรรมของโมเดลในสถานการณ์ที่มีการขัดจังหวะจากผู้ใช้ การตอบรับสั้น ๆ การสนทนากับผู้อื่น และเสียงพูดพื้นหลัง
    • สติปัญญาวัดด้วย Audio MultiChallenge ซึ่งเป็นเบนช์มาร์กทั่วไปที่ติดตามทั้งสติปัญญาและความสามารถในการทำตามคำสั่ง
    • TML-Interaction-Small ทำเวลาแฝงในการผลัดกันพูดของ FD-bench V1 ได้ 0.40 วินาที ซึ่งต่ำกว่าโมเดลเปรียบเทียบในตาราง
    • คะแนนเฉลี่ยของ FD-bench V1.5 อยู่ที่ 77.8 สูงกว่าคู่เทียบอย่าง GPT-realtime-2.0, GPT-realtime-1.5, Gemini-3.1-flash-live และ Qwen 3.5 OMNI-plus-realtime
    • ใน FD-bench V3 Audio+Tools โมเดลทำได้ คุณภาพการตอบสนอง 82.8% / Pass@1 68.0% เมื่อเปิดใช้งาน Background Agent
    • ความแม่นยำของ QIVD Video+Audio อยู่ที่ 54.0% ซึ่งต่ำกว่าหรือใกล้เคียงกับบางโมเดลเปรียบเทียบ
    • ค่า APR ของ Audio MultiChallenge อยู่ที่ 43.4% แม้จะต่ำกว่า 48.5% ของ GPT-realtime-2.0 xhigh แต่สูงกว่าโมเดล instant
    • BigBench Audio ถูกรายงานไว้ที่ 75.7 / 96.5 เมื่อเปิดใช้งาน Background Agent
    • IFEval ทำได้ 82.1% บน VoiceBench Audio และ 89.7% บน Text
    • อัตราการปฏิเสธข้อความของ Harmbench อยู่ที่ 99.0%

  • มิติของการโต้ตอบที่การประเมินเดิมยังจับไม่ได้

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

  • การรับรู้เวลาและการพูดพร้อมกัน

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

  • ความสามารถเชิงรุกด้านภาพ

    • ปัจจุบัน API แบบเรียลไทม์เชิงพาณิชย์ส่วนใหญ่ตรวจจับการผลัดกันพูดผ่านฮาร์เนสจัดการบทสนทนาที่อิงเสียงเป็นหลัก และไม่สามารถเลือกได้เองว่าจะพูดเมื่อใดเมื่อโลกภาพมีการเปลี่ยนแปลง
    • StreamBridge, Streamo, StreamingVLM, MMDuet2 ว่าด้วยเรื่องการเลือกว่าจะปล่อยข้อความเมื่อใดจากอินพุตวิดีโอแบบสตรีมมิง
    • งานวิจัยด้านการปล่อยข้อความเหล่านี้ไม่ได้จัดการกับข้อจำกัดของ ปฏิสัมพันธ์ผ่านเอาต์พุตเสียงพูด ซึ่งการเปล่งเสียงมีระยะเวลา อาจทับซ้อนกับผู้ใช้ และต้องประสานกับการผลัดกันพูด การขัดจังหวะ และการตอบรับสั้น ๆ
    • AURA เป็นสถาปัตยกรรมที่ให้ VideoLLM ตัดสินใจว่าจะส่งข้อความหรือเงียบไว้ แล้วติดเดโม ASR/TTS เข้าไป ขณะที่โมเดลของ Thinking Machines Lab แตกต่างตรงที่เป็น speech-native และ full-duplex

  • การประเมินความสามารถเชิงรุกด้านภาพ

    • RepCount-A ถูกดัดแปลงจากวิดีโอการเคลื่อนไหวซ้ำให้เป็นงานนับแบบออนไลน์
    • โมเดลจะได้รับคำสั่งเสียงว่า “ช่วยนับจำนวนครั้งของการทำซ้ำ {action}” พร้อมวิดีโอที่สตรีมเข้ามา และให้คะแนนจากการที่ตัวเลขสุดท้ายที่โมเดลพูดหลังจากการทำซ้ำครั้งรองสุดท้ายของคำตอบจริงนั้นต่างจากคำตอบจริงไม่เกิน 1
    • งานนี้วัดทั้ง การติดตามภาพอย่างต่อเนื่อง และการนับให้ทันเวลา
    • ProactiveVideoQA ประกอบด้วยวิดีโอที่มีคำถามซึ่งจะรู้คำตอบได้ในช่วงเวลาที่กำหนด
    • หลังสตรีมคำถามเป็นเสียงแล้วจึงส่งวิดีโอ โดยหากมีซับไตเติลก็จะฝังลงในวิดีโอ และปิดเสียงวิดีโออินพุตเพื่อเน้นความสามารถเชิงรุกด้านภาพ
    • การประเมินใช้เมตริก PAUC@ω=0.5 แบบถ่วงน้ำหนักตามเทิร์นจากงานวิจัย โดยสเกลเป็น 0~100 แล้วเฉลี่ยตามเทิร์นและหมวดหมู่ และหากเงียบต่อเนื่องจะได้ 25.0 คะแนน
    • คะแนนสูงต้องอาศัยทั้งการพูดคำตอบที่ถูกต้องและพูดในจังหวะที่ถูกต้อง ขณะที่คำตอบผิดจะถูกหักคะแนน
    • Charades เป็นเบนช์มาร์กมาตรฐานสำหรับการระบุตำแหน่งการกระทำตามเวลา โดยวิดีโอแต่ละรายการมีการกระทำที่เกิดขึ้นในช่วงเวลาที่ติดป้ายกำกับไว้
    • โมเดลจะได้รับคำสั่งเสียงว่า “เมื่อคนเริ่ม {action} ให้พูดว่า ‘start’ และเมื่อหยุดให้พูดว่า ‘Stop’” พร้อมสตรีมวิดีโอ และให้คะแนนด้วย temporal IoU ระหว่างช่วงที่ทำนายกับช่วงอ้างอิง

  • ข้อจำกัดของโมเดลปัจจุบัน

    • โมเดลที่มีอยู่ยังไม่สามารถทำงานด้านการรับรู้เวลา การพูดพร้อมกัน และความสามารถเชิงรุกด้านภาพเหล่านี้ได้อย่างมีนัยสำคัญ
    • เพื่อความครบถ้วน มีการรายงานผลของ GPT Realtime-2 minimal แต่โมเดลทุกตัวที่ใช้ประเมินรวมถึงโมเดล thinking high ให้ผลใกล้เคียงกันหรือแย่กว่า โดยมักเงียบหรือให้คำตอบผิด
    • ความสามารถในการโต้ตอบถูกมองว่าเป็นประเด็นวิจัยสำคัญในอนาคต และมีการประกาศแผนทุนวิจัยสำหรับโมเดล Interaction และกรอบการประเมินความร่วมมือระหว่างมนุษย์กับ AI เป็นต้น

ข้อจำกัดและแผนการเผยแพร่

  • เซสชันยาว

    • เสียงและวิดีโอต่อเนื่องทำให้บริบทสะสมอย่างรวดเร็ว
    • การออกแบบ streaming-session จัดการการโต้ตอบระยะสั้นและระยะกลางได้ดี แต่สำหรับเซสชันที่ยาวมากจำเป็นต้องมี การจัดการบริบท อย่างรอบคอบ

  • คอมพิวต์และการปรับใช้

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

  • การจัดแนวและความปลอดภัย

    • อินเทอร์เฟซแบบเรียลไทม์เปิดพื้นที่วิจัยใหม่ทั้งในด้านการจัดแนวและความปลอดภัย และขณะนี้กำลังมีการเก็บความคิดเห็นและทบทวนทุนวิจัย

  • การขยายขนาดโมเดล

    • ปัจจุบัน TML-Interaction-Small เป็น MoE ขนาด 276B พารามิเตอร์ และมีพารามิเตอร์ที่แอ็กทีฟ 12B
    • คาดว่าเมื่อขนาดโมเดลใหญ่ขึ้น ความสามารถในการโต้ตอบก็จะดีขึ้นด้วย แต่โมเดลพรีเทรนที่ใหญ่กว่ายังช้าเกินไปสำหรับการให้บริการในค่าตั้งนี้
    • มีแผนจะเปิดเผยโมเดลที่ใหญ่กว่านี้ในช่วงปลายปี

  • การปรับปรุง Background Agent

    • แม้จุดโฟกัสหลักจะเป็นความสามารถในการโต้ตอบแบบเรียลไทม์ แต่ สติปัญญาของเอเจนต์ ก็เป็นความสามารถที่จำเป็นเช่นกัน
    • นอกเหนือจากการยกระดับสติปัญญาของเอเจนต์ให้ถึงระดับฟรอนเทียร์แล้ว วิธีที่ Background Agent ทำงานร่วมกับ Interaction Model ยังอยู่ในระยะเริ่มต้น

  • กำหนดการเผยแพร่

    • ภายในไม่กี่เดือนข้างหน้าจะเปิด research preview แบบจำกัด เพื่อเก็บความคิดเห็น และมีแผนเปิดเผยในวงกว้างมากขึ้นในช่วงปลายปีนี้

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

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

 
xguru 2 시간 전

ต้องดูวิดีโอที่แนบมาด้วยนะครับ แค่หน่วงระดับนี้ก็ดูสมจริงมากแล้ว ถ้าพัฒนาไปอีกนิด ก็คงได้คุยกันเหมือนในหนังจริง ๆ เลยครับ
 
GN⁺ 4 시간 전
ความคิดเห็นบน Hacker News

  • วิดีโอพวกนี้น่าดูมาก มีหลายฉากที่น่าประทับใจ แต่สิ่งที่ทำให้ผมเชื่อทันทีคือฉากแรกที่ผู้หญิงพูดว่า “เดี๋ยวฉันจะเล่าเรื่องหนึ่งนะ” แล้วโมเดลก็ไม่ทำอะไร แค่รอเฉยๆ ระหว่างที่เธอดื่มกาแฟอยู่นาน ทำให้อยากยอมจ่ายเงินใช้เลย
    พอพูดถึงเรื่องเงิน ก็สงสัยว่า โมเดลทางเศรษฐกิจ ของบริษัทแบบนี้คืออะไร พวกเขาเปิดเผยสถาปัตยกรรมพอสมควร และดูเหมือนจะเปิดเผยมากพอที่แล็บแนวหน้าจะทำตามได้ สิทธิบัตร? ความลับทางการค้า? มันยากจะเข้าใจว่าจะชนะปริมาณการคำนวณฝึกโมเดลและองค์ความรู้ของ Anthropic/GOOG/oAI/Meta ได้อย่างไรโดยไม่มีการคุ้มครองทางกฎหมาย
    น่าตื่นเต้นว่าถ้าสถาปัตยกรรมโมเดลแบบนี้ ลด latency ได้ 30~40% และฉลาดขึ้นอีกจะเป็นอย่างไร อย่างไรก็ดี โมเดลนี้ดูเหมือนจะมีขนาดประมาณ 275B, active 12B ซึ่งราวๆ 1/10 ของตระกูล Opus 4.7 / GPT 5.x ดังนั้นยังมีพื้นที่ให้เพิ่มความฉลาดได้อีกมาก และก็น่าจะคาดหวัง latency ที่ต่ำลงได้ด้วย

    • สถาปัตยกรรมที่เปิดเผยอาจเป็นแค่ยอดภูเขาน้ำแข็ง การปรับแต่งไฮเปอร์พารามิเตอร์, data recipe, การเก็บข้อมูล, custom kernel, โครงสร้างพื้นฐานสำหรับ reinforcement learning/การประเมินผล ล้วนเป็นหัวข้อที่ลึกมาก และการจะดันประสิทธิภาพล้ำสมัยแบบนี้ได้ต้องอัดเวลาหลายสิบปีของนักวิจัยระดับปริญญาเอกหลายคนเข้าไป
      การแค่รอเฉยๆ น่าจะใกล้กับฝั่ง post-training มากกว่า ดังนั้นไม่ควรตีความมากเกินไปว่าที่ Gemini หรือ oAI ไม่ได้ให้ความสำคัญกับมันก่อนหน้านี้มีนัยอะไรใหญ่โต ความสามารถแบบ full duplex ที่แสดงตรงนี้ต่างหากที่เป็นความสำเร็จทางเทคนิคที่ยากกว่ามาก
    • ในจีน เป็นที่รู้กันดีว่าบริษัทเกิดใหม่ที่มีอนาคตมักได้รับข้อเสนอซื้อกิจการจาก Alibaba หรือ Tencent สักแห่งหนึ่ง สหรัฐฯ ก็น่าจะคล้ายกัน สิ่งที่เปิดเผยออกมามีโอกาสถูกซื้อหรือไม่ก็ถูกลอก Thinking Machines อาจกำลังคาดหวังสิ่งนั้นอยู่ก็ได้
    • โมเดลทางเศรษฐกิจเดิมอาจเป็น LLM สำหรับองค์กร ไม่ใช่หรือ tinker ใช้สำหรับ fine-tune โมเดลองค์กรแบบกำหนดเอง ส่วน interaction models คือแนวทางที่ทำงานเหมือนพนักงานคู่หูดิจิทัล โดยไม่ต้องให้บริษัทต้องคิดกระบวนการทั้งหมดใหม่โดยยึด AI agent เป็นศูนย์กลาง
    • ถ้าจะจ้างนักวิจัยแนวหน้า คุณต้องเปิดโอกาสให้พวกเขา ตีพิมพ์งานวิจัย ได้ ไม่อย่างนั้นพวกเขาก็ไม่ทำงาน

  • สิ่งที่สะดุดตาคือสถาปัตยกรรมนี้เป็น Transformer ที่รับอินพุตเป็นข้อความ รูปภาพ และเสียง แล้วให้เอาต์พุตเป็นข้อความและเสียง โดยฝึกทั้งหมดร่วมกัน อีกทั้งแทนที่จะสร้างผลลัพธ์แบบล้วนๆ จากพรอมป์ที่ได้รับ มันกลับทำงานเกือบเรียลไทม์ด้วยการสอดแทรกอินพุตกับเอาต์พุตเข้าหากัน
    “Time-Aligned Micro-Turns. The interaction model works with micro-turns continuously interleaving the processing of 200ms worth of input and generation of 200ms worth of output. Rather than consuming a complete user-turn and generating a complete response, both input and output tokens are treated as streams. Working with 200ms chunks of these streams enables near real-time concurrency of multiple input and output modalities.”
    สำหรับผม นี่คือแก่นสำคัญที่ทำให้มันแตกต่างจากโมเดลมัลติโหมดของแล็บแนวหน้าอื่นๆ

    • ถ้าออกแบบเป็น สถาปัตยกรรมมัลติโหมด มาตั้งแต่แรก มันน่าสนใจมากเพราะอาจทำให้เกิดแอปพลิเคชันที่มองโมดาลิตีต่างๆ เป็น “ด้าน” ของวัตถุเดียวกันได้ เช่น coding agent อาจมอง “โค้ด” + “IDE” + “memory mapping” + feedback จากปลั๊กอินหลายตัวเป็นคนละโมดาลิตี และเอาต์พุตก็ออกเป็นข้อความเมื่อจำเป็นต้องใช้ข้อความ หรือออกเป็น action แทน call_something(params) เมื่อจำเป็นต้องลงมือทำแบบตอนนี้
      ความสามารถในการ “อยู่นิ่งได้” จนกว่าจะมีบางโมดาลิตีกระตุ้นก็น่าสนใจเหมือนกัน สิ่งแบบนี้ทำได้อยู่แล้วตอนนี้ แต่จะออกแนวเป็นการเสริมทีหลัง และถึงอย่างนั้นก็ค่อนข้างทำงานได้ดี เลยอยากรู้ว่าถ้าฝึกแบบผสานรวมมาตั้งแต่ต้นจะไปได้ดีแค่ไหน
    • สงสัยว่าการ “สอดแทรกการประมวลผลอินพุต 200ms กับการสร้างเอาต์พุต 200ms” ทำงานอย่างไร LLM/Transformer ไม่จำเป็นต้องมีบริบททั้งหมดก่อนหรือถึงจะสร้างชุดโทเคนถัดไปได้?

  • จากเดโม ดูเหมือนหลายกรณีจะเป็นการย้ายองค์ประกอบที่เคยอยู่ใน external harness เข้าไปไว้ในตัวโมเดลเอง ซึ่งไม่แน่ใจว่านี่จะเป็นวิธีที่ยืดหยุ่นจริงหรือไม่
    หลายครั้งน่าจะวนปรับปรุงได้เร็วกว่าเมื่อ user interaction harness อยู่ภายนอกโมเดล ตัวอย่างเช่น ถ้ามี UI คั่นระหว่างผู้ใช้กับโมเดล และ UI นั้นต้องเปลี่ยน ผู้ใช้ก็อาจปรับแต่งเองได้
    ผมคิดว่า ความยืดหยุ่นเป็นสิ่งจำเป็น สำหรับ use case แบบตายตัวอย่างการแปลแบบเรียลไทม์หรือบอตเสียงง่ายๆ โมเดลแบบนี้อาจมีประโยชน์ แต่ในแต่ละกรณีแบบนั้น สุดท้ายก็น่าจะถูกทางเลือกที่เฉพาะทางกว่ากลบไป

  • แยกจากเรื่องตัวโมเดลที่น่าประทับใจ เดโมที่นี่ทำออกมาได้ดีมาก ต่างจากที่เคยเห็นจาก Anthropic หรือ OpenAI คือมัน สั้นและมีเอกลักษณ์

    • เห็นด้วยว่าทั้งน่าสนใจ น่าประทับใจ และเดโมก็ดี
      แต่ในเดโม “ท่าหลังค่อม” มุกตลกทางร่างกายแบบไม่คาดคิดที่ผู้หญิงคนนั้นแสดงออกมานี่ตลกมาก เป็นคอเมดี้ที่สมบูรณ์แบบจนไม่ต้องแก้อะไรเลย
      ผมชอบ บรรยากาศที่มีความเป็นมนุษย์ แบบนี้มากกว่าเดโมสไตล์ OpenAI/Anthropic เสียอีก กล้าพอจะเรียกสิ่งนี้ว่าเป็นตัวอย่างของ “human-centered design” ไหม (https://en.wikipedia.org/wiki/Human-centered_design)

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

    • ในทางทฤษฎี ผมคาดหวังว่ามันจะเป็นรูปแบบที่ทำทุกอย่างที่โมเดลแนวหน้าปัจจุบันทำได้อยู่แล้ว พร้อมเพิ่ม การโต้ตอบแบบเรียลไทม์ เพื่อการทำงานร่วมกันที่ดีขึ้น จุดแข็งที่สุดอาจเป็นอินพุตวิดีโอแบบเรียลไทม์ แทนที่จะรับวิดีโอทั้งก้อนหรือรับภาพทีเดียวแล้วค่อยปล่อยเอาต์พุตครั้งเดียว มันสามารถสร้างเอาต์พุตที่ถูกปรับตามอินพุตนั้นไปพร้อมกับการรับอินพุตได้แบบขนาน
    • ผมรู้สึกเรื่องนี้มากกับเดโม AI ทุกอัน ถ้า use case ที่ดีที่สุดที่คิดขึ้นมาเพื่อโชว์เทคโนโลยี คือการ จองวันหยุดพักผ่อน ที่ผมทำเองได้ง่ายๆ อยู่แล้ว บริการนั้นเพิ่มคุณค่ามหาศาลจริงหรือ? หรือว่าการใช้งานจริงมันละเอียดอ่อนและเฉพาะทางกว่านั้นจนไม่เหมาะกับเดโมสั้นๆ สำหรับคนทั่วไป? ไม่แน่ใจเหมือนกัน

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

  • ไม่อยากพูดแบบนี้ แต่แม้มันจะดูน่าประทับใจและเหมือนเป็นความก้าวหน้าพอสมควรในวิธีที่เราโต้ตอบกับ AI ขณะเดียวกัน use case และ UX ที่นำเสนอก็ดูไม่สมจริงหรือไม่ค่อยมีประโยชน์
    การแปลแบบเรียลไทม์เป็นข้อยกเว้น และมันน่าจะควรเป็นผลิตภัณฑ์แยกต่างหากไปเลย นอกนั้นฟีเจอร์อย่างการนับจำนวนสัตว์หรือจับเวลาเล่นควิซก็ดูไม่ค่อยมีประโยชน์ เดโมตรวจจับท่าทางแม้จะตลก แต่ก็ค่อนข้างดิสโทเปียและแปลกๆ ผมก็ไม่ชอบที่ AI แทรกเข้ามาตำหนิกลางคันโดยไม่รอให้เล่าเรื่องพาพ่อแม่สูงวัยไปปั่นจักรยานเสือภูเขาให้จบ
    UX ก็มีปัญหา การที่โมเดลขัดจังหวะผู้ใช้ทำให้จังหวะสะดุด แม้แต่ในกรณีที่ตาม use case แปลกๆ นั้นจะดูเหมือนจำเป็นก็ตาม ในวิดีโอเดโมที่เผยแพร่ออกมา ยังเห็นเลยว่าพนักงาน/นักแสดงต้องตั้งใจมากพอสมควรเพื่อพูดต่อไปให้ได้เหมือนไม่ได้โดนเครื่องจักรหุ่นยนต์ทื่อๆ ขัดจังหวะ คนจริงเวลามี “การขัดจังหวะแบบได้รับเชิญ” ที่หาได้ยากแบบนี้ สามารถพูดซ้อนอยู่ใต้ผู้พูดหลักได้ และโดยปกติก็จับจังหวะได้ละเอียดกว่านี้มาก
    แม้แต่ในเดโมแปลอัตโนมัติ แม้จะลดระดับเสียงคนพูดลง แต่ AI ก็ยังดันเสียงแทรกเข้ามา และในทางปฏิบัติ ถ้าจะเดโมแบบนั้นจริง ก็คงต้องควบคุมการพูดอย่างมาก หรือที่น่าจะเป็นไปได้กว่าคือปิดเสียงเอาต์พุตไว้ ล่ามมนุษย์มีวิธีส่ง “เอาต์พุต” ไปยังผู้ฟังที่ตั้งใจไว้
    ส่วนที่ดีที่สุดของเทคโนโลยีนี้คือฉากในวิดีโอแรกที่ AI ไม่ขัดผู้ใช้โดยไม่จำเป็น มันดูเหมือนแก้บั๊กสำคัญที่โมเดลปัจจุบันยังมีอยู่
    use case ที่ดีอาจเป็นการนับ คำติดปากอย่าง “เอ่อ” เวลาเราซ้อมพูดในที่สาธารณะ

    • โมเดลแบบ omni ดูมีประโยชน์มากกับ ปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์แบบเรียลไทม์ ตัวอย่างที่นึกออกทันทีคือผู้ช่วยเสียง, customer experience, เกม, ผู้ช่วยประชุม, โค้ชแบบเรียลไทม์หรือผู้ช่วยผู้ใช้สำหรับการใช้งานซอฟต์แวร์, การแปล, และงานคอมพิวเตอร์ที่ควบคุมด้วยเสียง
      ตัวอย่างเช่นงาน frontend/mobile development, CAD, 3D modeling งานแนว use case ของ LLM agent แบบดั้งเดิมเหล่านี้มักมี latency สูง เพราะโมเดลต้องรอให้ผู้พูดพูดจบก่อนถึงจะตัดสินใจได้ว่าจะเรียกใช้เครื่องมือหรือตอบกลับ และถ้าเรียกใช้เครื่องมือ ก็ต้องประมวลผลผลลัพธ์จากเครื่องมือก่อนแล้วค่อยตัดสินใจอีกว่าจะเรียกเครื่องมือต่อหรือตอบกลับ

  • นี่ดูคล้ายกับสิ่งที่คนกำลังทำกันในเครื่องตัวเองด้วย Gemma4 และ TTS อยู่แล้ว แค่ดูหวือหวากว่านิดหน่อย
    อีกไม่นานโมเดลโลคัลก็น่าจะตามทัน

  • เจตนาอาจดี แต่ถ้าไปอยู่ในมือที่ไม่เหมาะสม มันดูเหมือนจะยิ่งเสริม เทคโนโลยีสอดส่อง ถึงเวลาที่ต้องตั้งรับแล้ว