Ivan Nikitin ประธานเจ้าหน้าที่บริหารและผู้ร่วมก่อตั้ง Fortytwo – ซีรีส์สัมภาษณ์

Ivan Nikitin เป็นประธานเจ้าหน้าที่บริหารและผู้ร่วมก่อตั้ง Fortytwo ซึ่งเขากำลังพัฒนาเทคโนโลยีการอนุมานแบบฝูงที่นำโมเดล AI หลายตัวมาทำงานร่วมกัน เพื่อให้เหตุผลและประเมินผลงานของกันและกัน เขามีประสบการณ์ครอบคลุมทั้งเกม AI สำหรับการสนทนา AI เชิงสร้างสรรค์ และระบบอินเทอร์แอกทีฟจากการทำงานที่ Temporal และ Sensorium เขาร่วมก่อตั้ง Temporal ในปี 2011 กับ Vlad Larin ซึ่งปัจจุบันเป็นผู้ร่วมก่อตั้งและประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Fortytwo โดยได้สั่งสมประสบการณ์ในการพัฒนาประชากรเอเจนต์ที่เปลี่ยนแปลงไปตามกาลเวลาและระบบที่ผสานโมเดลเฉพาะทางเข้าด้วยกัน

Fortytwo พัฒนาโครงสร้างพื้นฐานด้าน AI ที่ช่วยให้โมเดลทำงานร่วมกันระหว่างการอนุมาน Fortytwo Engine ใช้ Swarm Decoder เพื่อกำกับกระบวนการให้เหตุผลร่วมกันขณะที่กระบวนการดำเนินไป โดยมีเป้าหมายเพื่อเพิ่มความแม่นยำและลดการสร้างโทเค็นที่ไม่จำเป็นในงานที่ใช้เวลานาน บริษัทให้บริการ API สำหรับนักพัฒนาผ่าน Fortytwo Engine และให้บริการติดตั้งใช้งานภายในองค์กรผ่าน Fortytwo Harbor

ก่อนร่วมก่อตั้ง Fortytwo คุณใช้เวลาหลายปีพัฒนาผลิตภัณฑ์ด้าน AI สำหรับการสนทนา AI เชิงสร้างสรรค์ และระบบอินเทอร์แอกทีฟที่ Sensorium และ Temporal ประสบการณ์เหล่านั้นหล่อหลอมมุมมองของคุณอย่างไรว่าโมเดลภาษาขนาดใหญ่แต่ละโมเดลมีข้อจำกัดตรงไหน และท้ายที่สุดนำไปสู่แนวทางแบบฝูงที่อยู่เบื้องหลัง Fortytwo ได้อย่างไร

สมาชิกทีมของเราส่วนใหญ่ รวมถึงตัวผมเอง เข้าสู่วงการ AI ผ่านเกม เกมเป็นแหล่งบ่มเพาะของคอมพิวเตอร์ส่วนบุคคลและ AI สมัยใหม่ เพราะเกมเป็นเหตุผลที่ทำให้มี GPU และการเล่นเกมก็เป็นสนามทดสอบสำคัญแห่งแรกของการเรียนรู้แบบเสริมกำลัง โลกของเกมมอบสภาพแวดล้อมที่ใช้งานได้จริงสำหรับสร้างเอเจนต์ที่เรียนรู้ ปรับตัว และแข่งขันได้ ที่ Temporal ซึ่งผมร่วมก่อตั้งในปี 2011 กับ Vlad Larin ซึ่งปัจจุบันเป็นผู้ร่วมก่อตั้งและประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Fortytwo เราเริ่มต้นจากแนวคิดเรื่องปัญญาที่วิวัฒนาการได้ นั่นคือประชากรของเอเจนต์ที่แข่งขันกันภายใต้แรงกดดันจากการคัดเลือก เราสนใจว่าประชากรจะทำสิ่งต่าง ๆ ได้มากกว่าเอเจนต์รายตัวอย่างไร หากมีกลไกที่ดีสำหรับระบุและต่อยอดจากผลงานที่แข็งแกร่งที่สุดของประชากรนั้น การคัดเลือกและการประเมินจึงกลายเป็นหัวใจสำคัญของแนวคิดที่เรามีต่อปัญญา

เมื่อโมเดลทรานส์ฟอร์เมอร์ถือกำเนิดขึ้น เราขยายงานไปสู่ AI สำหรับการสนทนา และสร้างแพลตฟอร์มสำหรับตัวละครที่ขับเคลื่อนด้วย AI ซึ่งสนทนาได้อย่างอิสระโดยไม่มีบทพูดกำหนดไว้ล่วงหน้า พร้อมทั้งมีความทรงจำและบุคลิกเฉพาะตัว เรื่องนี้เกิดขึ้นก่อน ChatGPT ราวสองสามปี และโมเดลที่เราใช้งานในตอนนั้นมีหน้าต่างบริบทเพียง 512 ถึง 1,024 โทเค็น การคาดหวังให้โมเดลภาษายุคแรกเพียงโมเดลเดียวรองรับข้อกำหนดที่แตกต่างกันทั้งหมดของประสบการณ์ดังกล่าวได้อย่างน่าเชื่อถือนั้นเป็นไปไม่ได้ เราจึงต้องสร้างไปป์ไลน์เฉพาะขึ้นมา โดยใช้โมเดลเฉพาะทางที่แต่ละโมเดลรับผิดชอบงานในขอบเขตแคบกว่า พร้อมตรรกะสำหรับผสานผลงานของแต่ละโมเดล การจัดอันดับและคัดเลือกคำตอบกลายเป็นสิ่งจำเป็นเพื่อให้ประสบการณ์ทั้งหมดใช้งานได้จริง สิ่งนี้ทำให้เราเห็นว่าระบบที่ออกแบบมาอย่างดีสามารถเพิ่มขีดความสามารถได้มากเพียงใด ด้วยการนำโมเดลที่มีข้อจำกัดมาผสานเข้าด้วยกัน

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

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

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

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

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

คุณเคยกล่าวว่าการที่โมเดลค่อย ๆ เบี่ยงเบนระหว่างทำงานเป็นเวลานานเป็นปัญหาใหญ่ อะไรเป็นสาเหตุของการเบี่ยงเบนนี้ และในทางปฏิบัติปัญหานี้ปรากฏอย่างไรในงานด้านต่าง ๆ เช่น วิศวกรรมซอฟต์แวร์ การวิจัย หรือเอเจนต์ AI อัตโนมัติ?

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

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

เราสามารถวัดผลเป็นตัวเลขได้ เราทดสอบ Qwen 3.8 27B กับงาน DeepSWE จำนวน 450 งาน ซึ่งเป็นงานวิศวกรรมซอฟต์แวร์จริงที่ใช้เครื่องมือและมีบริบทยาว โดยทดสอบทั้งการทำงานด้วยตัวโมเดลเองและผ่าน Fortytwo Engine เมื่อทำงานด้วยตัวเอง โมเดลใช้โทเค็นเฉลี่ย 16.3 ล้านโทเค็นต่อการทำงานหนึ่งครั้ง รวมทั้งหมด 7.4 พันล้านโทเค็น ส่วนเมื่อทำงานผ่าน Engine โมเดลเดียวกันใช้เฉลี่ย 12.3 ล้านโทเค็นต่อครั้ง รวม 5.6 พันล้านโทเค็น หรือลดลง 24.7% และยังแก้โจทย์ได้มากขึ้นด้วย โดยทำได้ 47.8% เทียบกับ 42.2% ตัวโมเดลไม่มีอะไรเปลี่ยนแปลง โทเค็นสี่ล้านโทเค็นต่อครั้งที่ประหยัดได้นั้นเกิดจากการลดการเบี่ยงเบน ได้แก่ การอ่านซ้ำ การลองใหม่ และการย้อนกลับไปทำขั้นตอนเดิม ซึ่งโมเดลเดี่ยวต้องทำเพราะไม่มีใครคอยจับข้อผิดพลาดระหว่างที่มันกำลังหลงทาง ฝูงโมเดลช่วยตรวจจับข้อผิดพลาดเหล่านั้น จึงไม่ต้องเสียค่าใช้จ่ายไปกับการแก้ไขตั้งแต่แรก

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

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

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

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

ในการทดสอบ Qwen 3.8 27B ทาง Fortytwo รายงานว่าใช้โทเค็นน้อยลง 24.7% จากการทำงาน DeepSWE จำนวน 450 รอบ พร้อมทั้งปรับปรุงผลลัพธ์ในเกณฑ์ทดสอบ 6 รายการ เบื้องหลังการทำงานของฝูงโมเดลเกิดอะไรขึ้น จึงช่วยเพิ่มประสิทธิภาพไปพร้อมกับลดการใช้โทเค็นได้?

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

ในด้านความแม่นยำ ประเด็นสำคัญคือความสามารถของโมเดลที่ไม่สม่ำเสมอ โดยทั่วไป โมเดลจะพัฒนาได้ไม่เท่ากันในแต่ละด้าน กล่าวคือ อาจให้เหตุผลในระดับปริญญาเอกในด้านหนึ่ง แต่กลับสร้างคำตอบไร้สาระโดยสิ้นเชิงในอีกด้านหนึ่ง เพราะการปรับแต่งอย่างละเอียด การเรียนรู้แบบเสริมกำลัง และการฝึกหลังการฝึกแบบอื่น ๆ ช่วยให้โมเดลทำงานได้ดีขึ้นกับข้อมูลที่ใช้ฝึก แต่ประโยชน์ที่ได้จะลดลงเมื่องานจริงห่างไกลจากข้อมูลดังกล่าว Swarm Decoder ไม่ได้เปลี่ยนแปลงตัวโมเดล แต่ช่วยปรับปรุงกระบวนการให้เหตุผลอย่างสม่ำเสมอ ดังนั้น เกณฑ์ทดสอบทั้ง 6 รายการจึงไม่ใช่ 6 ด้านที่เราเจาะจงปรับให้เหมาะสม แต่เป็น 6 จุดที่ใช้วัดสิ่งเดียวกัน โดยรวมแล้ว โมเดลฉลาดขึ้นและใส่ใจมากขึ้น อีกทั้งเมื่อมีโมเดลอื่นคอยตรวจสอบทุกขั้นตอน ก็ให้ความรู้สึกว่าโมเดลทุ่มเทกับงานของคุณมากขึ้น นี่จึงเป็นเหตุผลที่เราคิดค่าบริการ Engine ในอัตราต่อโทเค็นเท่ากับโมเดลพื้นฐาน ลูกค้าไม่ได้จ่ายเงินเพื่อเพิ่มงบประมาณ แต่จ่ายเพื่อให้ได้คำตอบที่ถูกต้องด้วยเส้นทางที่สั้นลง

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

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

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

Fortytwo Engine เข้ากันได้กับ OpenAI API ขณะที่รันโมเดลแบบเปิดน้ำหนัก ความเข้ากันได้กับสแต็กการพัฒนา AI ที่มีอยู่มีความสำคัญอย่างไร และนักพัฒนาสามารถย้ายแอปพลิเคชันจาก API แบบโมเดลเดียวทั่วไปไปเป็นสถาปัตยกรรมแบบ swarm ได้อย่างง่ายดายเพียงใด?

ความเข้ากันได้เป็นสิ่งจำเป็น ระบบนิเวศของเอเจนต์ เอเจนต์การเขียนโค้ด ระบบรองรับ เฟรมเวิร์ก และเครื่องมือประเมิน ถูกสร้างขึ้นบนรูปแบบ OpenAI API ดังนั้นสำหรับนักพัฒนาที่เข้าถึง Fortytwo Engine การสลับไปมานั้นเหมือนกับการย้ายจากผู้ให้บริการอนุมานรายหนึ่งไปยังอีกรายหนึ่ง สำหรับแอปพลิเคชัน เอเจนต์ ระบบรองรับ หรือบริการที่เข้ากันได้ โดยทั่วไปแล้วจะเป็นการเปลี่ยนแปลงการกำหนดค่าเพียงครั้งเดียว: จุดปลาย, คีย์ API และการเลือกรุ่น

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

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