การสร้างสมดุลระหว่างเวลาในการตอบสนองต่ำมากกับความคุ้มค่าของระบบคลาวด์ในตัวแทนเสียงเสมือน

Devin Reimer

ยินดีต้อนรับสู่การสร้างสมดุลระหว่างเวลาในการตอบสนองต่ำมากกับความคุ้มค่าของระบบคลาวด์ในตัวแทนเสียงเสมือน

ผมชื่อ Devin Reimer

ฉันเป็นผู้ก่อตั้งและ CEO ของ AstroBeam

ก่อนหน้านี้ ผมเป็น CEO และผู้ร่วมก่อตั้ง Owlchemy Labs ซึ่งเป็นที่รู้จักมากที่สุดจากเกม Job Simulator

ดังนั้น AstroBeam จึงมุ่งเน้นที่การสร้าง AI แบบเรียลไทม์ในเกม

โดยเฉพาะอย่างยิ่ง เรามุ่งเน้นที่การใช้เสียงเป็นอินพุต

จนถึงตอนนี้เราได้เปิดตัวเกมไปแล้ว 2 เกม ได้แก่ Stellar Cafe ซึ่งเป็นเกม VR และ PC

เกมนี้เป็นเกมที่คุณจะได้พูดคุยกับหุ่นยนต์ในคาเฟ่บนสถานีอวกาศและช่วยแก้ปัญหาให้หุ่นยนต์เหล่านั้น

ซึ่งขับเคลื่อนด้วยเสียง 100%

คุณเล่นเกมทั้งหมดได้ รวมถึงเมนูและการนำทาง โดยใช้เพียงเสียงของคุณ

เกมถัดไปของเราที่เพิ่งประกาศเปิดตัวในวันนี้อย่าง Robo Detective สร้างขึ้นสำหรับ Android XR และ Project Aura ของ XREAL โดยเฉพาะ

ในเกมนี้ คุณจะเล่นเป็นนักสืบที่ทำงานร่วมกับพาร์ทเนอร์หุ่นยนต์เพื่อช่วยสัมภาษณ์หุ่นยนต์เพื่อไขคดีอาชญากรรมของหุ่นยนต์ และเกมนี้ก็ขับเคลื่อนด้วยเสียง 100% เช่นกัน

ดังนั้น เอเจนต์เสียงจึงเป็นเรื่องที่ยากมาก และในเกมก็ยิ่งยากขึ้นไปอีก

เหตุผลก็คือเกมเป็นสิ่งที่มีต้นทุนต่ำมาก และตอนนี้เอเจนต์เสียงก็เป็นต้นทุนใหม่ที่เพิ่มเข้ามาในไปป์ไลน์นั้น

นอกจากนี้ เราไม่ได้แข่งขันกับตัวแทนเสียงรายอื่นๆ แต่เรากำลังแข่งขันกับคุณภาพของเกมทุกเกมที่เคยสร้างมา จริงไหม

ดังนั้น เราจึงต้องสร้างสรรค์ผลงานที่มีคุณภาพสูงมาก

แต่ก็ไม่ได้หมายความว่าไม่มี Use Case ของ Voice Agent ที่เฉพาะเจาะจงซึ่งมีความท้าทายที่ไม่เหมือนใคร หรือมีความเสี่ยงสูงกว่ามาก แต่เกมเป็นสิ่งที่ท้าทายทางเทคนิคอย่างมากในพื้นที่นี้

แต่เนื่องจากเป็นเกม จึงมีพื้นที่ให้ทดลองวิธีแก้ปัญหาที่ยากๆ เหล่านี้ได้มากมาย

ดังนั้นฉันจึงเชื่อว่าหากเอเจนต์เสียงทำงานในเกมได้ ก็จะทำงานได้เกือบทุกที่

ดังนั้น สิ่งที่ผมพูดถึงในการบรรยายนี้จึงไม่ได้ใช้กับเกมเท่านั้น แต่ยังใช้กับแอปพลิเคชันที่เน้นเสียงเป็นหลักซึ่งคุณต้องการสร้างด้วย

ดังนั้นเมื่อนึกถึง Voice Agent ผมคิดว่ามีความท้าทายหลักๆ อยู่ 3 ประการ

เราจึงมีเวลาในการตอบสนอง ความชาญฉลาด และค่าใช้จ่าย

สิ่งหนึ่งที่ฉันอยากจะอธิบายให้ชัดเจนก็คือ เมื่อฉันพูดถึงเอเจนต์เสียง ฉันหมายถึงเอเจนต์เสียงในรูปแบบการสนทนา ไม่ใช่พรอมต์

เราไม่ได้พูดถึง Wrapper ไมโครโฟนที่ส่งข้อมูลไปยัง LLM แล้วรอการตอบกลับ

ผมกำลังพูดถึงการโต้ตอบแบบเรียลไทม์ในชีวิตจริง ซึ่งเป็นสิ่งที่สร้างได้ยากมาก

มาเริ่มกันที่เวลาในการตอบสนอง

คุณต้องการให้เร็วแค่ไหน

ซึ่งคำตอบคือต้องเร็วมาก แต่ทั้งนี้ก็ขึ้นอยู่กับสิ่งที่คุณอ่านมา เพราะอาจไม่ได้เร็วอย่างที่คิด หรืออาจเร็วกว่าที่คิดมากก็ได้

เรามาพูดถึงตัวเลขบางส่วนที่เราค้นพบจากการทดสอบหลายๆ ครั้งกัน

ดังนั้นเมื่อพูดถึงเวลาในการตอบสนองตั้งแต่ต้นจนจบ สิ่งที่ผมพูดถึงคือเวลาตั้งแต่คำพูดสุดท้ายของผู้ใช้ เสียงสุดท้ายที่ผู้ใช้สร้างขึ้น จนถึงเวลาที่พวกเขาได้ยินเสียงตอบกลับมา

สิ่งที่เราค้นพบจากการทดสอบคือประมาณ 1.5 วินาทีเป็นจุดที่เมื่อเราได้รับความคิดเห็นเกี่ยวกับการทดสอบการเล่นจากผู้ใช้ ผู้ใช้จะเริ่มไม่พูดถึงความเร็วหรือความช้าหรืออะไรทำนองนั้น

ซึ่งดูเหมือนว่าจะเป็นจุดที่ผู้คนเริ่มรู้สึกสบายใจที่จะใช้ฟีเจอร์นี้จริงๆ

หากเราตอบช้ากว่านั้น ผู้คนมักจะพูดว่า "ก็ดีนะ แต่..." ดังนั้นเวลาดังกล่าวจึงดูเหมือนจะเป็นจุดที่เหมาะสมที่สุด

จากนั้นเมื่อคุณพูดเร็วขึ้น เราพบว่าที่ความเร็วประมาณ 1.2 วินาที การโต้ตอบไปมาที่เป็นธรรมชาติมากขึ้นจะเริ่มเกิดขึ้น

ดังนั้นเมื่อฉันพูดอะไรบางอย่าง ในกรณีนี้หุ่นยนต์จะพูดอะไรบางอย่างอย่างรวดเร็ว และคุณจะโต้ตอบไปมา

ดูเหมือนว่าจะมีจุดที่เหมาะสมที่ปลดล็อกอยู่

อย่างไรก็ตาม การทำเวลา 1.2 วินาทีนั้นค่อนข้างยากเมื่อต้องเรียงซ้อนกัน

นอกจากนี้ เรายังพบสิ่งที่น่าสนใจอีกอย่างหนึ่งคือเราได้ทำการทดสอบหลายครั้ง และสุดท้ายก็ได้สถานการณ์บางอย่างที่ทำให้ใช้เวลาไม่ถึง 1 วินาที

คุณอาจจะคิดว่า "โอ้ ต้องเจ๋งแน่ๆ"

ซึ่งบางครั้งก็เป็นเช่นนั้น และบางครั้งก็รู้สึกแย่มาก ไม่คุ้นเคยเลย

ดังนั้น คุณอาจได้ยินคนพูดถึงเวลาในการตอบสนอง 800 มิลลิวินาทีว่าเป็นตัวเลขที่เหมาะสม หรือ 500 มิลลิวินาที

ฉันยังอ่านบทความเกี่ยวกับ 300 ด้วย เพราะนั่นคือจุดที่การรับรู้ของมนุษย์เกิดขึ้นจริงๆ

ความจริงก็คือเรื่องนี้ขึ้นอยู่กับบริบทอย่างมาก

ตัวอย่างเช่น ถ้าฉันถามว่าคุณชื่ออะไร ฉันจะคาดหวังว่าคุณจะใช้เวลาตอบนานแค่ไหน

ถ้าฉันถามคุณว่าความหมายของชีวิตคืออะไร ฉันก็คาดหวังว่าจะได้คำตอบในเวลาที่แตกต่างกันมาก

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

คำตอบที่ใช้เวลานาน ผู้คนกลับบอกว่าเร็ว และในทางกลับกัน เพราะปรากฏว่าขึ้นอยู่กับบริบทเป็นอย่างมาก

รวมถึงตำแหน่งที่ผู้ใช้รายนั้นอยู่ในการสนทนาด้วย

โดยทั่วไปแล้ว ผู้คนคาดหวังว่าการตอบกลับครั้งแรกจะเร็วกว่าการตอบกลับครั้งต่อๆ ไปเนื่องจากมีเวลาคิด

แต่บางครั้งคุณก็อาจได้โต้ตอบกันสั้นๆ ซึ่งทำให้คุณคาดหวังมากขึ้น

ดังนั้นจึงไม่มีหลักการที่สมบูรณ์แบบว่าต้องมีจำนวนเท่าใด แต่เราพบว่าหากคุณมีอัตราส่วนประมาณ 1.5 ก็ถือว่าค่อนข้างดี

ดังนั้น เมื่อคุณทำได้ถึง 1.5 วินาทีแล้ว คุณจะเริ่มให้ความสำคัญกับความสม่ำเสมอใช่ไหม

เพราะหากคุณพบว่าเหตุการณ์นี้เกิดขึ้น 90% ของเวลาทั้งหมด แต่ 10% ของเวลาทั้งหมดใช้เวลา 3 วินาที ประสบการณ์ของคุณจะรู้สึกว่าไม่ดี ไม่ใช่แย่ แต่ไม่ดี

และเมื่อคุณเริ่มเร็วพอแล้ว คุณจะสนใจเรื่องความสม่ำเสมอ คือเร็วตลอดเวลา ไม่ใช่แค่ส่วนใหญ่

Devin Reimer

นี่คือสถาปัตยกรรมไปป์ไลน์เสียงมาตรฐาน

เราจึงนำการแปลงเสียงพูดเป็นข้อความมาใช้ โดยส่งไปยัง LLM แล้วส่งผลลัพธ์จาก LLM กลับไปยังการอ่านออกเสียงข้อความ

ซึ่งหมายความว่าในการแปลงเสียงพูดเป็นข้อความ เราจะส่งเสียงไปยังเซิร์ฟเวอร์แล้วแปลงเป็นข้อความ

ในฝั่ง LLM เราจะนำข้อความนั้น บทสนทนาตอบกลับนั้น หรือแปลงเป็นบทสนทนาตอบกลับ แล้วดูว่าตัวละครนั้นจะดำเนินการอะไรต่อไป

เราเชื่อมโยงทั้ง 2 อย่างนี้เข้าด้วยกันอย่างแน่นหนาเพราะคิดว่าสำคัญมาก

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

ปัญหาหนึ่งของการดำเนินการนี้คือการเรียกใช้ตามลำดับอาจค่อนข้างช้า เนื่องจากคุณต้องดำเนินการตามขั้นตอนเหล่านี้ทีละขั้นตอน

คำถามที่พบบ่อยที่ฉันได้รับคือ ถ้าวิธีนั้นช้าและคุณต้องทำ 3 ขั้นตอน ทำไมไม่ใช้โมเดลการแปลงเสียงพูดเป็นเสียงพูดแทนล่ะ

เพราะแบบนั้นจะเร็วกว่าใช่ไหม

และใช่ ส่วนใหญ่แล้ววิธีนี้จะเร็วกว่าเพราะคุณเรียกใช้เพียงสิ่งเดียว

แต่ก็มีข้อเสียที่ต้องแลกมาด้วย

ดังนั้น แม้ว่าวิธีนี้จะรวดเร็ว แต่ก็มีข้อเสียที่สำคัญสำหรับเรา และข้อเสียที่ใหญ่ที่สุดคือค่าใช้จ่าย

โดยทั่วไปแล้ว เราพบว่าการเรียกใช้โมเดล Speech-to-Speech มีค่าใช้จ่ายสูงกว่าแนวทางแบบคู่ขนานนี้ประมาณ 3-5 เท่า

ดังนั้น สำหรับเราแล้ว การทำเช่นนี้ไม่คุ้มค่าทางเศรษฐกิจ

ในด้านความปลอดภัยนั้นค่อนข้างซับซ้อนกว่ามาก เพราะการตรวจสอบคำตอบที่ Agent จะให้ก่อนที่ Agent จะพูดนั้นทำได้ยากกว่า

แต่ในระหว่างนี้ หากคุณมีแนวทางแบบไปป์ไลน์ คุณสามารถนำคำตอบที่ LLM พูดมาตรวจสอบและตรวจสอบความปลอดภัยได้ทันทีก่อนที่จะส่งสิ่งต่างๆ ไปยังผู้ใช้

ในส่วนของรูปแบบเสียง คุณจะถูกจำกัดให้ใช้ค่าที่กำหนดล่วงหน้าภายในโมเดลการแปลงเสียงพูดเป็นเสียงพูดนั้น

คุณจะพูดว่า "โอ้ รู้ไหมว่าอะไร

สำหรับเคสนี้ ฉันอยากใช้เสียงประเภทนี้จริงๆ"

คุณจะติดอยู่กับชื่อนั้น

ในแนวทางแบบไปป์ไลน์ คุณอาจคิดว่า "ฉันจะเปลี่ยนแนวทาง

ฉันจะเลือกโมเดลนี้เพราะโมเดลนี้ทำงานได้ดีมากสำหรับกรณีการใช้งานนี้"

และเช่นเดียวกันกับความฉลาดใช่ไหม

ถ้าคุณมีโมเดล Speech-to-Speech ที่ดีมากๆ ซึ่งสร้างเสียงที่ดี แต่ความฉลาดไม่ตรงกับที่คุณต้องการ คุณก็เปลี่ยนโมเดลไม่ได้ใช่ไหม

คุณจะถูกจำกัดให้ใช้ได้เฉพาะบางฟีเจอร์

ในแนวทางแบบไปป์ไลน์ คุณจะคิดว่า "โอ้ สำหรับกรณีการใช้งานนี้ ฉันต้องการใช้โมเดลหนึ่งๆ"

สิ่งหนึ่งที่ฟีเจอร์เสียงพูดเป็นเสียงพูดทำได้ดีกว่าอย่างแน่นอนคือการเข้าใจน้ำเสียงของผู้ใช้

เช่น การเสียดสีและอะไรทำนองนั้น

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

นั่นเป็นข้อดีอย่างหนึ่งของฟีเจอร์เสียงพูดเป็นเสียงพูด

ดังนั้น Speech-to-Speech จึงมีข้อได้เปรียบในเรื่องความเร็ว แต่ก็มีความท้าทายในเรื่องความสามารถในการกำหนดค่า และค่าใช้จ่ายที่สูง โดยเฉพาะสำหรับเรา ซึ่งเป็นปัจจัยที่ทำให้เราไม่เลือกใช้

แล้วมีวิธีอื่นไหม

ได้

สิ่งที่เราควรทำคือพยายามอย่างเต็มที่เพื่อทำให้ไปป์ไลน์ทำงานแบบขนาน

ดังนั้น สิ่งที่เราทำก็คือเราจะเรียกใช้ LLM ก่อนที่การแปลงเสียงพูดเป็นข้อความจะมีความมั่นใจอย่างเต็มที่

ซึ่งความมั่นใจในที่นี้หมายถึงความมั่นใจในคำที่สร้างขึ้นในการถอดเสียง และความมั่นใจในการสิ้นสุดเทิร์น

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

ดังนั้น สถานการณ์ที่เลวร้ายที่สุดคือเราคิดผิดใช่ไหม

ผู้ใช้พูดต่อ

แต่ถึงอย่างนั้น สิ่งที่เราทำก็มีเพียงแค่ยกเลิก LLM แล้วเรียกใช้อีกครั้ง

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

นอกจากนี้ เรายังไม่รอให้ LLM สร้างคำตอบทั้งหมดให้เสร็จก่อนที่จะเริ่มส่งไปยังฟีเจอร์อ่านออกเสียงข้อความ

สิ่งที่เรากำลังรอคือส่วนแรกที่พูดได้

ในสถานการณ์ส่วนใหญ่จะเป็นประโยค

บางครั้งอาจมีการกำหนดค่าอื่นๆ แต่ทันทีที่เรามีกลุ่มประโยคแรก เราจะส่งไปยังฟีเจอร์อ่านออกเสียงข้อความ

จากนั้น หากเรามีฟีเจอร์อ่านออกเสียงข้อความที่ดีซึ่งจะสตรีมได้ทันทีที่พร้อมสตรีม ผู้ใช้ก็จะได้รับข้อมูลนั้น

นอกจากนี้ เรายังระมัดระวังอย่างมากเกี่ยวกับจำนวนโทเค็นที่ต้องสร้าง

ดังนั้นเราจึงไม่ใช้สิ่งต่างๆ เช่น Wrapper ของ JSON และสิ่งอื่นๆ ที่อาจเพิ่มโทเค็นเพิ่มเติม

เราพยายามหาวิธีที่ง่ายที่สุดในการรับคำตอบที่รวดเร็วที่สุด

นอกจากนี้ เรายังใช้สิ่งต่างๆ เช่น การเติมข้อมูลล่วงหน้าของผู้ช่วย หากเราทราบว่าโทเค็นกลุ่มแรกจะมาจากตัวแทนล่วงหน้า

ดังนั้นสำหรับฟีเจอร์อ่านออกเสียงข้อความ จึงกลายเป็น 2 ส่วนนี้ใช่ไหม

ดังนั้นข้อมูลส่วนแรกที่อ่านออกเสียงได้จะเข้ามา แล้วเราจึงเรียกใช้ส่วนอื่นๆ ทั้งหมดหลังจากนั้น

แต่เนื่องจากการฟังเสียงที่เล่นใช้เวลานานกว่าการสร้างเสียง โดยทั่วไปแล้วเสียงส่วนแรกจะเล่นให้ผู้ใช้ฟังเสร็จก่อนที่เสียงส่วนที่ 2 จะสร้างเสร็จ

ซึ่งผู้ใช้จะมองไม่เห็น

ซึ่งจะมาถึงเร็วที่สุดเท่าที่จะเป็นไปได้

ดังนั้นเมื่อคุณคิดจะเลือกบริการต่างๆ ต่อไปนี้คือหลักเกณฑ์คร่าวๆ ของเรา

เมื่อต้องเลือกประเภทเสียงและเฟรมเวิร์ก Agent ที่ดี สิ่งที่คุณควรให้ความสำคัญคือเวลาในการตอบสนองต่ำสุดทั้งขาเข้าและขาออก

ฉันจะส่งและดึงข้อมูลได้เร็วแค่ไหน

ในด้านการแปลงเสียงพูดเป็นข้อความ เราให้ความสำคัญกับเวลาที่ใช้ในการสร้างความมั่นใจ

ดังนั้นนี่คือความมั่นใจในการถอดเสียงและความมั่นใจในการสิ้นสุดเทิร์น

อุปกรณ์เหล่านั้นจับคู่กันอยู่ใช่ไหม

ถ้าคุณไม่มั่นใจในสิ่งใดสิ่งหนึ่งอย่างรวดเร็ว มันก็จะช้าแบบนั้นใช่ไหม

ดังนั้นความเร็วจะเท่ากับความเร็วของอุปกรณ์ที่ช้าที่สุดในนั้นเท่านั้น

ในด้าน LLM เราให้ความสำคัญกับเวลาที่ใช้ในการสร้างประโยคแรก ซึ่งเป็นส่วนแรกที่พูดได้

ซึ่งก็คือ 2 ส่วนใช่ไหม

ซึ่งเป็นเวลาที่ได้โทเค็นแรกรวมกับโทเค็นต่อวินาที

ดังนั้น หากจู่ๆ คุณพบโมเดลที่ดีมากซึ่งให้เวลาในการสร้างโทเค็นแรกที่ดีมาก แต่สร้างโทเค็นต่อวินาทีได้ช้า ก็อาจแย่กว่าทางเลือกอื่น

ดังนั้นคุณต้องหาชุดค่าผสมที่เหมาะสมสำหรับเรื่องนี้

และในด้านการอ่านออกเสียงข้อความ คุณจะให้ความสำคัญกับเวลาที่ใช้ในการสร้างเสียงแรก

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

ดังนั้นคุณจึงต้องวัดผลจนถึงจุดที่ผู้ใช้ได้ยินเสียง

และอย่างที่ฉันได้กล่าวไปก่อนหน้านี้ สิ่งที่สำคัญที่สุดคือคุณให้ความสำคัญกับความเสถียร ไม่ใช่ความเร็วสูงสุด ไม่ใช่สถานการณ์ที่ดีที่สุด

เวลาในการตอบสนองที่สม่ำเสมอของสแต็กทั้งหมดนี้คือเท่าใด

Devin Reimer

ดังนั้น ปัจจุบันเราจึงใช้ LiveKit สำหรับเฟรมเวิร์ก Agent เสียง

สำหรับการแปลงเสียงพูดเป็นข้อความ เราใช้ Deepgram

สำหรับ LLM เราใช้ Gemma 4 31B และโฮสต์ไว้ใน LiveKit

ในด้านการอ่านออกเสียงข้อความ เราใช้ Inworld AI Text-to-Speech 2

นอกจากนี้ เรายังได้สร้างระบบควบคุมการทำงานของ AI Agent ของ AstroBeam ทั้งหมด ซึ่งไม่เพียงแต่เชื่อมโยงสิ่งเหล่านี้เข้าด้วยกัน แต่ยังเพิ่มองค์ประกอบทั้งหมดที่คุณต้องมีเพื่อให้มี Agent เสียงที่ดีจริงๆ โดยเฉพาะ Agent ที่มีการโต้ตอบสูงอย่างของเราสำหรับเกม

สิ่งหนึ่งที่ฉันยังไม่ได้พูดถึงคือโมเดลความปลอดภัย

โดยปกติแล้ว โมเดลความปลอดภัยจะเป็นส่วนหนึ่งของ LLM Pass แต่จะเพิ่มเวลาในการตอบสนองและเพิ่มขั้นตอนเพิ่มเติมเข้าไป

แล้วถ้าคุณจัดกิจกรรมของตัวเองแทนล่ะ

ดังนั้น สแต็กของเราจึงมีลักษณะดังนี้

สิ่งที่เราทำคือเมื่อได้รับข้อความชุดแรกกลับมา ซึ่งเป็นข้อความชุดแรกที่อ่านออกเสียงได้ที่เราจะส่งไปยังการอ่านออกเสียงข้อความ เราจะส่งข้อความนั้นไปยังโมเดลความปลอดภัยในเวลาเดียวกัน

และเนื่องจากโมเดลความปลอดภัยมีขนาดเล็กกว่าและทำงานได้เร็วกว่าการแปลงเสียงพูดเป็นข้อความ จึงเกือบจะทำงานเสร็จก่อนเสมอ

และนั่นหมายความว่าการเพิ่มโมเดลความปลอดภัยจะไม่เพิ่มเวลาในการตอบสนองให้กับสแต็กของเรา และยิ่งไปกว่านั้น โมเดลนี้ยังมีขนาดใหญ่พอที่เราจะเรียกใช้โมเดลความปลอดภัยที่ใหญ่กว่าที่คนส่วนใหญ่คิดว่าจะเรียกใช้ได้

ซึ่งเป็นสิ่งสำคัญอย่างยิ่งสำหรับเรา โดยเฉพาะอย่างยิ่งเพราะเรากำลังสร้างเกม

มีบริบทมากมายในโลกนั้นที่มีความสำคัญอย่างยิ่ง

ตัวอย่างเช่น สมมติว่าคุณกำลังสร้างเกมยุคกลาง และมี NPC ในเกมยุคกลางนี้ที่ตะโกนว่า "บุกเลย!

ตัดหัวมันเลย!" ใช่ไหม

โมเดลความปลอดภัยแบบดั้งเดิมอาจเป็นแบบ "ว้าว ไม่ดีเลย

คุณไม่ควรพูดแบบนั้น"

แต่ในบริบทของเกมนี้ ถือว่าสมเหตุสมผลอย่างยิ่ง

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

คุณอาจสังเกตเห็นว่าเราเรียกใช้โมเดลความปลอดภัย 2 ครั้ง โดยครั้งแรกจะเรียกใช้กับข้อมูลส่วนแรก และเรียกใช้อีกครั้งกับข้อมูลทั้งหมดเมื่อเรามีข้อมูลส่วนสุดท้ายทั้งหมด

เราต้องเรียกใช้โมเดลนี้ 2 ครั้ง แต่จะไม่เพิ่มเวลาในการตอบสนองให้กับสแต็ก

ตอนนี้เราเร็วพอแล้ว แต่ก็ไม่มีประโยชน์หากเราไม่ฉลาดพอ

Devin Reimer

แล้วต้องฉลาดแค่ไหนล่ะ

โดยต้องฉลาดพอสำหรับผู้ใช้ และที่สำคัญกว่านั้นคือต้องฉลาดพอให้คุณนำไปพัฒนาต่อได้

และนี่มักเป็นสิ่งที่ผู้คนไม่ได้นึกถึงเมื่อเลือกสิ่งที่ต้องการสำหรับข้อมูลข่าวกรองที่นี่

เราพัฒนาเอเจนต์เสียงมาประมาณ 3 ปีแล้ว ตัวอย่างเช่น ในช่วงแรกๆ เราใช้โมเดล LLaMA รุ่นแรกๆ และแม้ว่าจะทำให้โมเดลทำงานได้ในระดับหนึ่งสำหรับผู้ใช้ แต่ฝั่งการพัฒนากลับมีค่าใช้จ่ายสูงมากเพราะทุกอย่างเปราะบางมาก

โมเดลอาจสร้างคำตอบที่ไม่พึงประสงค์หรือสิ่งที่ไม่สมเหตุสมผลได้ง่ายๆ เราจึงทุ่มเทความพยายามด้านวิศวกรรมอย่างมากเพื่อให้โมเดลทำงานได้ดี

เราจึงให้ความสำคัญกับเรื่องนี้ เพราะหากเราสร้างสิ่งเหล่านี้ได้ไม่เร็วพอ เราก็จะไม่สามารถนำเสนอสิ่งต่างๆ ให้กับผู้ใช้ได้

ดังนั้น คุณจึงควรพิจารณาทั้ง 2 อย่างนี้

ดังนั้น เมื่อผู้คนนึกถึงความชาญฉลาด พวกเขามักจะนึกถึง LLM ใช่ไหม

แต่นั่นเป็นเพียงส่วนหนึ่งเท่านั้น

เราต้องคิดถึงทุกส่วนเมื่อพูดถึงข่าวกรอง

เรามาพูดถึงความอัจฉริยะของการแปลงเสียงพูดเป็นข้อความกัน

ดังนั้นสิ่งที่เราให้ความสำคัญในที่นี้คืออัตราข้อผิดพลาดของคำที่ต่ำ

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

หากอัตราข้อผิดพลาดต่ำ แต่การดำเนินการผิดพลาดสูงมาก LLM จะประสบปัญหามากขึ้นในการพยายามค้นหาเจตนาที่แท้จริง

อีกสิ่งหนึ่งที่ควรคำนึงถึงคือแพลตฟอร์มเป้าหมายของคุณ

ตัวอย่างเช่น หากฉันกำลังสร้างโมเดลสำหรับ XR และมีไมโครโฟนที่อยู่ใกล้กับปากของผู้ใช้มาก ฉันก็จะได้ข้อมูลเสียงจากไมโครโฟนที่มีคุณภาพสูงและดีมาก ซึ่งอาจทำงานได้ดีมากสำหรับโมเดลบางประเภท

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

ดังนั้นคุณต้องคำนึงถึงเรื่องนี้ และตรวจสอบว่าคุณเลือกแพลตฟอร์มที่เหมาะสมกับแอปที่กำลังสร้าง

จากนั้นก็มาถึงส่วนการอ่านออกเสียงข้อความของสมการความอัจฉริยะ

ฟังดูเป็นธรรมชาติใช่ไหม

เป้าหมายของเราคือการสื่อสารกับผู้ใช้ว่าผู้ใช้จะเข้าใจอะไรได้บ้าง

แต่นั่นเป็นเพียงส่วนหนึ่งเท่านั้นใช่ไหม

ความสามารถในการแสดงออกของ Agent นั้นก็สำคัญมากเช่นกัน เพราะการแสดงออกนั้นมีข้อมูลอยู่ และจากการทดสอบการเล่น เรายังพบว่ายิ่ง Agent แสดงออกได้มากเท่าไร ผู้ใช้ก็ยิ่งรู้สึกว่า Agent นั้นฉลาดมากขึ้นเท่านั้น ซึ่งก็สมเหตุสมผลดี

และเร็วพอไหม

และฉันรู้ว่าในส่วนก่อนหน้านี้ ฉันพูดถึงเวลาในการตอบสนอง แต่จริงๆ แล้วเวลาในการตอบสนองก็มีความสำคัญต่อความฉลาดที่รับรู้ได้ด้วย

ผู้ใช้รับรู้ความเร็วในการตอบสนองที่สัมพันธ์โดยตรงกับความเร็วที่แท้จริงเมื่อพูดถึงความฉลาด

ถ้าฉันตอบได้เร็ว ก็อาจจะดูฉลาดขึ้นนะ

ดังนั้นสิ่งเหล่านี้จึงมีความสำคัญอย่างยิ่งต่อวิธีที่ผู้ใช้รับรู้ประสบการณ์ และความดื่มด่ำกับประสบการณ์นั้นๆ

มาต่อกันที่ด้าน LLM ของระบบอัจฉริยะ

นี่เป็นสิ่งที่สร้างสมดุลได้ยากที่สุด เพราะมีข้อกำหนดที่แตกต่างกันมากมายใช่ไหม

เราจึงมีความเข้าใจคำพูด บริบท และการอ้างอิงข้อมูล

ในเกม เรื่องนี้เป็นเรื่องที่ยากมาก เพราะคุณต้องสร้างโลกและจักรวาลทั้งใบขึ้นมาใช่ไหม

นี่ไม่ใช่กล่องข้อความที่สามารถสร้างสิ่งต่างๆ ที่กำลังเกิดขึ้นได้

หากเอเจนต์ในเกมพูดว่า "มีแอปเปิลอยู่บนโต๊ะ" แต่ไม่มีแอปเปิลอยู่บนโต๊ะจริงๆ ก็จะทำให้ประสบการณ์ของผู้ใช้เสียไป

นอกจากนี้ เรายังต้องการสิ่งต่างๆ เช่น การปฏิบัติตามกฎอย่างเคร่งครัด

เกมเป็นสิ่งที่อิงตามกฎอย่างมาก

LLM จะจัดการเรื่องนั้นได้ไหม

เราจะทำให้อัตราการเกิดภาพหลอนต่ำได้ไหม

เราจะสร้างตัวละครที่สอดคล้องกันเมื่อคุณโต้ตอบกับ Agent ตัวเดิมซ้ำๆ ได้ไหม

คุณรู้สึกว่าตัวแทนคนนี้เป็นคนเดียวกันไหม

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

เพราะเมื่อคุณพัฒนาต่อไปเรื่อยๆ คุณจะต้องใส่ข้อมูลลงในพรอมต์มากขึ้นอย่างหลีกเลี่ยงไม่ได้

แต่เมื่อผู้ใช้เล่นต่อไปเรื่อยๆ ก็จะมีประวัติการแชทในพรอมต์นั้นมากขึ้น

พรอมต์นั้นจะจัดการกับการเติบโตนั้นได้ไหม

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

แต่นี่เป็นเพียงตัวอย่างเล็กๆ น้อยๆ เท่านั้น และยังขึ้นอยู่กับสิ่งที่คุณกำลังสร้างด้วย

ดังนั้นคุณต้องคิดอย่างรอบคอบเกี่ยวกับสิ่งที่คุณกำลังสร้างและสิ่งที่คุณพยายามทำให้สำเร็จ

ตอนนี้เราเร็วพอและฉลาดพอแล้ว แต่ทั้งหมดนี้จะไม่มีความหมายเลยหากมีค่าใช้จ่ายสูงเกินไป

Devin Reimer

แล้วราคาต้องถูกแค่ไหน

แต่จริงๆ แล้วมีความซับซ้อนมากกว่านั้นเล็กน้อย

เราจึงต้องคำนึงถึงเศรษฐศาสตร์ของแอปพลิเคชันหรือเกมที่เรากำลังสร้างขึ้นใช่ไหม

คุณจึงต้องถามคำถาม 2-3 ข้อ

ผู้ใช้จะโต้ตอบกับตัวแทนแบบเสียงของคุณนานเท่าใด

คุณสร้างรายได้เท่าใดต่อผู้ใช้ 1 คน

และสแต็กเสียงนั้นมีค่าใช้จ่ายเท่าใดต่อชั่วโมงในการทำงาน

เรานำข้อมูลเหล่านั้นมารวมกันเพื่อพยายามหาคำตอบและดูว่าสมเหตุสมผลหรือไม่

นี่คือเศรษฐศาสตร์ของเกมแรกของเราอย่าง Stellar Cafe

ดังนั้นเวลาเล่นใน Stellar Cafe จะอยู่ที่ประมาณ 1 ชั่วโมงครึ่งถึง 3 ชั่วโมงครึ่ง เราจึงเฉลี่ยเวลาเล่นอยู่ที่ประมาณ 2 ชั่วโมง

ต้นทุนในการใช้งานเอเจนต์เสียงของเราอยู่ที่ประมาณ $1.20 ต่อชั่วโมงต่อผู้ใช้ และผู้ใช้โต้ตอบกับเอเจนต์เสียงตลอดเวลา

เกมนี้เป็นเกมที่ใช้เสียง 100%

เราเรียกเก็บค่าธรรมเนียมคงที่ $10 สำหรับเกม ซึ่งเป็นรูปแบบดั้งเดิม

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

ก่อนหน้านี้เราเรียกเก็บเงิน $15 แต่เราได้พยายามลดค่าใช้จ่ายเซิร์ฟเวอร์เหล่านี้ลง ตอนนี้เราจึงลดราคาลงเหลือ $10 แล้ว

และ $1.20 นี้คือจุดที่เราอยู่

ซึ่งค่าใช้จ่ายนี้ไม่ใช่ค่าใช้จ่ายที่ตายตัว

ฉันเห็นว่าสิ่งเหล่านี้มีราคาแตกต่างกันไป และบางครั้งก็แพงกว่ามาก

ดังนั้น คุณจึงต้องพิจารณาด้วยว่าคุณอยู่ในจุดใดในด้านต้นทุน

เราอาจทำให้ราคาถูกลงได้ แต่เราพยายามรักษามาตรฐานคุณภาพให้สูงที่สุดเท่าที่จะทำได้

ดังนั้น เมื่อพิจารณาจากทั้งหมดนี้แล้ว หมายความว่าที่เวลาเล่น 2 ชั่วโมง สแต็กเสียงของเราจะมีค่าใช้จ่ายประมาณ $2.40 ต่อผู้ใช้

และเนื่องจากเราเรียกเก็บเงิน $10 และ App Store เรียกเก็บค่าธรรมเนียม นั่นหมายความว่าเราจะได้รับเงินประมาณ $4.59 ต่อผู้ใช้ 1 คน ถูกไหม

ดังนั้นเศรษฐศาสตร์ของเรื่องนี้จึงได้ผลใช่ไหม

เสียงคือจุดขายของเรา นั่นคือสิ่งที่เราต้องการลงทุน และมันได้ผล

เกมนี้จึงมีขนาดเล็กมาก

มาพูดถึงเรื่องที่ใหญ่ขึ้นกันบ้าง

เรามาพูดถึงเกมสมมติกัน เกมแบบเล่าเรื่องที่ใช้เวลาเล่นประมาณ 5-9 ชั่วโมง หรือเฉลี่ย 7 ชั่วโมง

ในความเป็นจริง คนส่วนใหญ่หรือหลายคนเล่นเกมไม่จบ พวกเขาเล่นเกมเพียงเล็กน้อยแล้วก็เลิกเล่น แต่ฉันต้องการเลือกสิ่งที่สูงขึ้นเล็กน้อยเพื่อให้แน่ใจว่าเศรษฐศาสตร์ยังคงทำงานได้

ดังนั้น เราจะยังคงคิดค่าบริการ $1.20 ต่อชั่วโมง แต่สิ่งที่เราจะเปลี่ยนแปลงคือจะใช้คอมโพเนนต์เสียง 60% ของเวลาทั้งหมด เนื่องจากเกมที่ใหญ่ขึ้นจะมีกลไกมากกว่าแค่เสียง

ดังนั้น เกมนี้จะยังคงเป็นเกมที่ขับเคลื่อนด้วยเสียงเป็นหลัก แต่จะมีฟีเจอร์ประเภทอื่นๆ อยู่ในเกมด้วย

ดังนั้น หากเราเรียกเก็บเงิน $20 และลองคำนวณทั้งหมดนี้อีกครั้ง เราจะมีต้นทุนประมาณ $5 ต่อผู้ใช้ ซึ่งหมายความว่าในท้ายที่สุด เราจะทำเงินได้ประมาณ $9 ต่อผู้ใช้

ดังนั้น ขอย้ำอีกครั้งว่าด้วยวิธีนี้ เศรษฐศาสตร์จะทำงานได้

แต่ก็ไม่ได้หมายความว่าเศรษฐศาสตร์จะใช้ได้กับทุกอย่าง

ตัวอย่างเช่น สิ่งที่ไม่ควรทำคือการคิดว่า "ฉันอยากสร้างเกมที่เล่นฟรี และผู้ใช้เกมนี้น่าจะเล่นเกมประมาณ 1 ชั่วโมงถึง 100 ชั่วโมงขึ้นไป"

ดังนั้น เราจะเฉลี่ยเป็น 10 ชั่วโมง

เกมนี้ขับเคลื่อนด้วยเสียง 100% แต่สมมติว่าเรามีเกมที่ฮิตติดตลาด และเกมนี้สร้างรายได้ประมาณ $3 ต่อผู้ใช้ ซึ่งถือว่ายอดเยี่ยมมากสำหรับเกมที่เล่นฟรี

คุณจะเสียเงิน $10 ต่อผู้ใช้

ดังนั้นจึงยังไม่สามารถทำงานเหล่านี้ได้ทั้งหมด และคุณต้องคิดถึงสิ่งที่คุณกำลังสร้างอยู่ตอนนี้ว่าสมเหตุสมผลหรือไม่

อย่ารอจนถึงตอนท้ายเพื่อพยายามทำความเข้าใจเรื่องเศรษฐศาสตร์

Devin Reimer

คำถามถัดไปที่มักจะถามกันก็คือ แล้วโมเดลในเครื่องล่ะ

เพราะหากคุณมีปัญหาใหญ่เรื่องต้นทุน โมเดลในเครื่องจะช่วยแก้ปัญหานี้ได้ไหม

และแน่นอนว่าใช่

แต่ก็มีข้อดีข้อเสียบางอย่างที่เราต้องพิจารณา

ดังนั้นในด้านต้นทุน เราจะตัดค่าใช้จ่ายเกี่ยวกับเซิร์ฟเวอร์ออกไป ซึ่งจะเป็นประโยชน์อย่างมากและเปิดโอกาสให้เราได้อีกมากมาย

แต่ตอนนี้มีหลายอย่างที่ระบบคลาวด์สามารถแก้ปัญหาที่อุปกรณ์ในเครื่องทำได้ยาก

เช่น compute

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

ดีเลย แต่สิ่งที่เราต้องคำนึงถึงคือไม่ได้ใช้โมเดลเดียว แต่ใช้หลายโมเดลใช่ไหม

ในกรณีของเราคือ 4 รายการ ซึ่งอาจเกิดขึ้นพร้อมกัน ดังนั้นการเรียกใช้เพียงครั้งเดียวจึงไม่เพียงพอ แต่ต้องเรียกใช้หลายครั้งพร้อมกัน

และหากคุณดำเนินการดังกล่าวแล้ว คุณได้ทิ้งอะไรไว้ให้เกมหรือแอปพลิเคชันทำงานหรือไม่

หากคุณใช้ GPU จนเต็มประสิทธิภาพ คุณจะแสดงผลวิดีโอเกมได้ไม่มากนัก

สมมติว่าคุณเอาชนะความท้าทายเหล่านั้นได้แล้ว

ต่อไปคือความเร็วใช่ไหม

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

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

ขณะนี้การสร้างโมเดลที่จะทำงานด้วยความเร็วที่เหมาะสมเพื่อให้ฟีเจอร์นี้ทำงานได้ถือเป็นเรื่องท้าทาย

ต่อไป สมมติว่าคุณเอาชนะเรื่องการประมวลผลและความเร็วได้แล้ว ตอนนี้เราต้องคิดถึงเรื่องคุณภาพใช่ไหม

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

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

ดังนั้น หากโมเดลนั้นสร้างได้ยาก ก็เป็นเรื่องที่ควรพิจารณาอย่างแน่นอน

สมมติว่าคุณเอาชนะเรื่องการประมวลผล ความเร็ว และคุณภาพได้แล้ว สิ่งต่อไปคือความสามารถในการพกพา

หากคุณชนะและผ่านกระบวนการทั้งหมดนี้มาได้ และคุณทำให้สิ่งนี้ทำงานบน RTX 5070 ได้ นั่นอาจเป็นที่เดียวที่สิ่งนี้จะทำงานได้

ดังนั้น หากมีโอกาสที่จะนำเกมไปลงแพลตฟอร์มใหม่ คุณอาจทำไม่ได้

ในส่วนของระบบคลาวด์ สิ่งที่คุณต้องมีคืออินเทอร์เน็ต

ซึ่งถือเป็นความสำเร็จครั้งใหญ่

ช่วยให้ไลฟ์สดไปยังหลายแพลตฟอร์มได้

ต่อไปเรามาพูดถึงแนวทางแบบผสมผสานกันดีกว่า

ดังนั้น เรามาเรียกใช้บางอย่างในระบบคลาวด์และบางอย่างในเครื่องกัน

ก็พอได้นะ แบบนี้ได้ไหม

แต่ก็ไม่ได้เป็นชัยชนะที่ยิ่งใหญ่อย่างที่คุณคิด

ดังนั้น หากคุณได้โมเดลที่มีขนาดเล็กพอที่จะเรียกใช้ในแพลตฟอร์มส่วนใหญ่ที่ใช้ หากคุณเรียกใช้โมเดลเดียวกันนั้นในระบบคลาวด์ ก็อาจมีค่าใช้จ่ายเพียงเล็กน้อย

ดังนั้น โดยทั่วไปแล้วคุณจะไม่ได้รับชัยชนะครั้งใหญ่จนกว่าจะไขปริศนาทั้งหมดได้

จากนั้นสิ่งถัดไปที่มักจะถูกหยิบยกขึ้นมาคือ จะเป็นอย่างไรหากคุณเรียกใช้ในเครื่องแทน หากเป็นไปได้

พวกเขามีฮาร์ดแวร์ที่เหมาะสม และในระบบคลาวด์หากคุณไม่มี ใช่ไหม

คุณสามารถเรียกใช้สิ่งที่มีประสิทธิภาพมากขึ้นในระบบคลาวด์ได้

ซึ่งก็มีความท้าทายใหม่ๆ ใช่ไหม

หากคุณใช้โมเดลอื่นในท้ายที่สุด การดำเนินการนี้อาจส่งผลต่อการพัฒนาค่อนข้างมาก

และสุดท้ายคุณก็ต้องใช้เวลาจำนวนมากในการทำงานกับสเปกขั้นต่ำอยู่ดี

และคุณอาจมีโมเดลที่มีลักษณะการทำงานที่แตกต่างกันอย่างมาก

ดังนั้น หากคุณไม่ได้ใช้โมเดลเดียวกัน คุณอาจต้องเพิ่มเวลาและค่าใช้จ่ายในการพัฒนาเป็นจำนวนมาก

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

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

ดังนั้นเมื่อพูดถึงโมเดลในเครื่อง แน่นอนว่ามันเป็นชัยชนะทางเศรษฐกิจครั้งใหญ่ แต่ก็ยังอยู่ในช่วงเริ่มต้น

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

ปัจจุบัน การใช้งานนอกเหนือจากกรณีการใช้งานที่เฉพาะเจาะจงนั้นค่อนข้างยุ่งยาก โดยเฉพาะอย่างยิ่งในเรื่องที่เกี่ยวข้องกับคำสั่ง

ดังนั้นในวันนี้ เราจึงต้องการมอบประสบการณ์การใช้งานที่ดีที่สุดเท่าที่จะเป็นไปได้

นี่คือเหตุผลที่เราใช้ระบบคลาวด์

แต่พื้นที่นี้มีการเปลี่ยนแปลงอย่างรวดเร็ว และสิ่งต่างๆ ก็เปลี่ยนแปลงไปอย่างรวดเร็วเช่นกัน

ส่วนถัดไปคือการคิดถึงโมเดลที่เราใช้

คำถามถัดไปคือเรื่อง Open Weights กับ Closed Weights

เราควรทำอะไรที่นี่

ฉันอยากจะเน้นไปที่ LLM เมื่อเราพูดถึงเรื่องนี้ เพราะเราพบว่านี่เป็นส่วนที่ได้รับผลกระทบมากที่สุดจากคำถามเรื่องโอเพนซอร์สกับโคลสซอร์ส

ดังนั้นจึงมีทั้งข้อดีและข้อเสีย

ดังนั้นเมื่อพูดถึงโมเดลแบบปิดและแบบถ่วงน้ำหนัก โดยทั่วไปแล้วโมเดลเหล่านี้จะเป็นโมเดลอัจฉริยะระดับแนวหน้าใช่ไหม

ดังนั้น หากต้องการข้อมูลอัจฉริยะมากที่สุด คุณมักจะต้องไปที่นี่

ในขณะที่ฝั่งโอเพนซอร์สมักจะตามหลังอยู่ 1 รุ่น

ดังนั้น คุณจึงต้องพิจารณาข้อดีข้อเสียให้ดี

ในด้านความเร็ว ผมได้พูดถึงการให้ความสำคัญกับเวลาที่ใช้ในการสร้างประโยคแรก

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

ซึ่งอาจเกิดจากหลายสาเหตุ

อาจมีผู้ใช้โมเดลมากขึ้น หรืออาจมีการเปลี่ยนฮาร์ดแวร์เป็นรุ่นใหม่

แต่ก็เป็นสิ่งหนึ่งที่เราสังเกตเห็น

ดังนั้นคุณต้องระมัดระวังเพราะอาจทำให้เกิดปัญหาได้ โดยหากคุณจัดส่งบางอย่างที่ยอดเยี่ยม เมื่อเวลาผ่านไป สิ่งนั้นอาจใช้งานไม่ได้

ถัดไปคือยอดแหลม

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

ถัดไปคืออายุการใช้งานของโมเดล

ดังนั้น โมเดลแบบปิดจึงมักจะเลิกใช้งานหลังจากผ่านไปประมาณ 1 ปี

ซึ่งหมายความว่าหากคุณพัฒนาบางอย่างเป็นเวลา 1 ปี และคาดว่าจะใช้งานจริงเป็นเวลา 3 ปี คุณอาจต้องเปลี่ยนโมเดลมากกว่า 3 ครั้ง

และเพียงเพราะโมเดลหนึ่งดีกว่าไม่ได้หมายความว่าจะทำงานได้ดีกว่าสำหรับคุณ

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

สุดท้ายคือต้นทุน

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

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

ในด้านที่เปิดอยู่ คุณมีความยืดหยุ่นในการย้ายไปมา และมีโอกาสที่ราคาจะไม่เพิ่มขึ้นอย่างมากเนื่องจากเป็นโมเดลเดียวกันทุกประการ

เราจึงใช้ Gemma 4 31B ซึ่งช่วยปลดล็อกศักยภาพได้อย่างมาก เพราะสำหรับเราแล้ว นี่เป็นการผสมผสานที่ลงตัวที่สุดระหว่างความเร็ว ความชาญฉลาด และต้นทุน

นอกจากนี้ยังช่วยให้เราทำงานได้อย่างรวดเร็วอีกด้วย

การพัฒนาด้วย Gemini ค่อนข้างง่ายกว่าเครื่องมือบางอย่างที่เราเคยใช้มาก่อน

แต่ไม่ได้หมายความว่าเราใช้เพียงวิธีนี้เท่านั้น

เราใช้โมเดลแบบเปิดและแบบปิดที่แตกต่างกันหลายแบบผสมผสานกัน

เช่น การสร้างความทรงจำ ความปลอดภัย และการปรับแต่ง

สิ่งสำคัญคือการเลือกโมเดลที่ดีที่สุดสำหรับความต้องการเฉพาะของคุณในงานนั้นๆ

แต่ Gemma 4 31B เป็นโมเดลหลักของเราเมื่อพูดถึงเอเจนต์เสียง

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

และกำหนดการของคุณจะไม่ได้รับผลกระทบจากการเลิกใช้งานโมเดล

Devin Reimer

สรุปก็คือการสร้างสมดุลระหว่างทั้ง 3 สิ่งนี้ใช่ไหม

เราพยายามสร้างสมดุลระหว่างเวลาในการตอบสนองในแง่ของการสตรีม แง่ของการทำงานแบบคู่ขนาน ความเร็ว และความสม่ำเสมอ

ในด้านความชาญฉลาดนั้น มีความชาญฉลาดเพียงพอสำหรับผู้ใช้ และชาญฉลาดเพียงพอที่จะนำไปต่อยอด

ในส่วนของต้นทุน เราจำเป็นต้องทราบว่าต้นทุนต่อผู้ใช้เป็นเท่าใด และเราจะสร้างรายได้ต่อผู้ใช้ได้เท่าใด เพื่อให้มั่นใจว่าเศรษฐศาสตร์จะทำงานได้

อย่าสร้างก่อนแล้วค่อยคิดเรื่องเศรษฐศาสตร์ทีหลัง

คิดถึงเรื่องนี้ตั้งแต่เริ่มต้น

แม้ว่าตอนนี้จะยังอยู่ในช่วงเริ่มต้น แต่เศรษฐกิจในส่วนนี้ก็เริ่มทำงานแล้ว

ดังนั้น โมเดลที่ถูกกว่าและฉลาดกว่าจะดีกว่าอย่างแน่นอน

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

ผมจึงตื่นเต้นมากที่จะได้นำพลังของเสียงและพลังของ Voice Agent มาสู่ทุกคน

ขอขอบคุณ