7 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เริ่มต้นจากการค้นพบว่าเมื่อ สังเคราะห์ (synthesize) ผลลัพธ์จากหลายโมเดลเข้าด้วยกัน สามารถให้ประสิทธิภาพเหนือกว่าโมเดลเดี่ยวอย่างชัดเจน
  • แนวทาง การไตร่ตรองแบบหลายโมเดล (multi-model deliberation) ที่ให้ โมเดลผู้เชี่ยวชาญ หลายตัววิเคราะห์พรอมป์ต์เดียวกันแบบขนาน แล้วให้ judge model สังเคราะห์ผลเพื่อเขียนคำตอบสุดท้าย
  • โมเดลในพาเนลจะทำ การค้นหาเว็บ และ การดึงข้อมูลเว็บ โดยเปิดใช้งานไว้ พร้อม วิเคราะห์แบบขนาน จากนั้น judge model จะสรุปเป็นการวิเคราะห์เชิงโครงสร้างของ ฉันทามติ, ความขัดแย้ง, ความสอดคล้องบางส่วน, มุมมองเชิงลึกเฉพาะตัว, จุดบอด
  • ค่าเริ่มต้นคือ พรีเซ็ต Quality และสามารถสลับไปใช้พรีเซ็ต Budget เพื่อใช้โมเดลที่ถูกกว่า หรือกำหนดพาเนลและผู้ตัดสินใหม่ทั้งหมดผ่านฟิลด์ fusion plugin
  • เหมาะกับงาน วิจัย, การวิจารณ์โดยผู้เชี่ยวชาญ หรือสถานการณ์ที่ต้นทุนจากคำตอบผิดสูงกว่าต้นทุนการสร้างคำตอบเพิ่มเติม
  • เนื่องจากมีการเรียกใช้ทั้งสมาชิกทุกตัวในพาเนลและ judge ค่าบริการต่อคำขอจึงคิดแบบ รวมค่าการสร้างคำตอบ (completion) ของแต่ละตัว ไม่ใช่แบบโมเดลเดี่ยว

วิธีการทำงาน

  • เป็นวิธีเปลี่ยนพรอมป์ต์เดียวให้กลายเป็น การไตร่ตรองแบบหลายโมเดล ขนาดเล็ก
    • พาเนลของโมเดลผู้เชี่ยวชาญจะวิเคราะห์พรอมป์ต์แบบขนาน โดยเปิดใช้ web search และ web fetch
    • judge model จะสังเคราะห์คำตอบจากพาเนล แล้วสร้างการวิเคราะห์แบบมีโครงสร้างเป็น ฉันทามติ (consensus), ความขัดแย้ง (contradictions), การครอบคลุมบางส่วน (partial coverage), มุมมองเชิงลึกเฉพาะตัว (unique insights), จุดบอด (blind spots)
    • จากการวิเคราะห์เชิงโครงสร้างนี้ judge model จะเขียนคำตอบสุดท้าย

องค์ประกอบและการตั้งค่าของพาเนล

  • พาเนลเริ่มต้นใช้ พรีเซ็ต Quality
    • หากต้องการสมาชิกที่ราคาถูกกว่า สามารถสลับไปใช้ พรีเซ็ต Budget ได้
    • สามารถ override พาเนลและผู้ตัดสินได้ทั้งหมดผ่านฟิลด์ analysis_models และ model ของ fusion plugin
  • แนะนำให้ใช้เมื่อโมเดลเดี่ยวไม่เพียงพอ
    • เหมาะกับ งานวิจัย, การวิจารณ์โดยผู้เชี่ยวชาญ หรือโดเมนที่ต้นทุนของคำตอบผิดสูงกว่าต้นทุนการสร้างคำตอบเพิ่มเติม

ราคาและข้อจำกัด

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

พรีเซ็ตใช้ 6 โมเดล

  • คุณภาพสูงสุด: Claude Opus, OpenAI GPT, Google Gemini Pro
  • ต้นทุนต่ำสุด: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi

ประกาศที่เกี่ยวข้อง: "Fusion ก้าวข้ามประสิทธิภาพระดับ frontier"

  • เป็นเครื่องมือที่สังเคราะห์ผลลัพธ์จากหลายโมเดลเพื่อให้เหนือกว่าประสิทธิภาพของโมเดลเดี่ยว โดยสามารถเลือกได้เองทั้ง พาเนลของโมเดลที่เข้าร่วม และ judge model ที่ใช้หลอมรวมผลลัพธ์ แล้วเรียกใช้ได้เหมือนโมเดลเดี่ยว
  • จากการวัดผล 100 งาน deep research ของ เกณฑ์มาตรฐาน DRACO พบว่าพาเนลทำได้ดีกว่าแต่ละโมเดลเดี่ยวอย่างสม่ำเสมอ
    • การหลอมรวม Fable 5 + GPT-5.5 ได้ 69.0% สูงกว่าโมเดลเดี่ยวทุกตัว รวมถึง Fable 5 เดี่ยว (65.3%)
    • พาเนลต้นทุนต่ำ (Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro) ใช้ ต้นทุน 50% แต่ทำคะแนนห่างจาก Fable 5 ไม่ถึง 1% และเหนือกว่า GPT-5.5 กับ Opus 4.8
  • พรอมป์ต์จะถูก ส่งแบบขนาน ไปยังโมเดลในพาเนล จากนั้น judge จะวิเคราะห์จุดที่เห็นพ้อง ความขัดแย้ง มุมมองเชิงลึกเฉพาะตัว และจุดบอด แล้วโมเดลที่ถูกเรียกใช้จะเขียนคำตอบสุดท้ายบนพื้นฐานดังกล่าว
  • ไปป์ไลน์ทั้งหมดทำงานแบบ server-side จึงใช้งานได้ในลักษณะเดียวกับการเรียกโมเดลเดี่ยว
  • แม้แต่กรณีที่นำ Opus 4.8 มา หลอมรวมกับตัวเอง ก็ยังได้ 65.5% เพิ่มขึ้น 6.7 จุดจากการใช้เดี่ยว (58.8%) ยืนยันผลของขั้นตอน synthesis เอง
  • พบ ความเสี่ยงของการปนเปื้อน ที่โมเดลในพาเนลอาจค้นหาเกณฑ์การให้คะแนนทางออนไลน์ จึงมีตัวเลือกตั้งค่าเพียงบรรทัดเดียวเพื่อบล็อกรายการยกเว้นของ web search และ web fetch
  • มี 4 วิธีในการใช้งาน: Chatroom (ไม่ต้องเขียนโค้ด), Model slug (แทนที่สตริง), Server tool (ควบคุมได้สูงสุด), Plugin (กำหนดพาเนล)
  • ไม่ใช่ตัวแทนแบบ drop-in ของ Fable, ยังไม่รวม งานแบบ long-horizon ที่ Fable เด่น และในการเขียนโค้ดเหมาะกับการใช้เป็นเครื่องมือเรียกใช้แบบเลือกเฉพาะกรณี

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

 
GN⁺ 6 시간 전
ความคิดเห็นจาก Hacker News
  • เมื่อหลายเดือนก่อนฉันลองทำ Fusion ด้วย MCP ที่ใช้ OpenRouter แนวคิดคืออยากมี “คณะผู้เชี่ยวชาญ” ไว้ให้ไปถามตอนที่ Claude ตัน
    หลังจากลองทดสอบและทำเบนช์มาร์กเยอะมาก ก็พบว่าการให้โมเดลหนึ่งประเมินคำตอบของอีกโมเดล ไม่ได้ให้คำตอบที่ดีกว่าอย่างแท้จริง สุดท้ายมันก็เหมือนถามว่า “คำตอบนี้คล้ายกับคำตอบที่คุณจะตอบเองแค่ไหน” และรอบเพิ่มหรือวิธีแก้แบบ “ชัดเจนอยู่แล้ว” ที่ผุดขึ้นมา ก็แทบไม่ต่างจากการเพิ่มอุณหภูมิ เจอวิธีแก้อยู่บ้าง แต่ค่าใช้จ่ายแพงเกินเหตุ ถ้าวิธีนี้เริ่มได้รับความสนใจมากขึ้น ฉันอาจปล่อยของฉันออกมาด้วย

    • พรอมป์ต์ สำคัญมาก ถ้าอยากได้ความเห็นจากโมเดลอื่น ก็แน่นอนว่าควรให้มันสร้างคำตอบจากพรอมป์ต์เดียวกันตั้งแต่ต้นแล้วค่อยสังเคราะห์รวมกัน และถ้าต้องการก็ยังให้มันทำงานกับคำตอบเดิมที่มีอยู่แล้วได้ด้วย
      ของฉันจะระบุชัดเจนให้มันหาปัญหาตามระดับความรุนแรง แล้วส่งปัญหาเหล่านั้นผ่านคณะโมเดลตัดสิน ก่อนจะให้แก้เฉพาะสิ่งที่เกินค่า threshold ที่กำหนดในคำตอบต้นฉบับ สิ่งที่ทำให้ผลดีขึ้นมากคือให้โมเดลตัดสินประเมินแยกกันระหว่างแกน ความจริง กับแกน “มีประโยชน์/ควรแก้ไหม” เพราะถ้าบังคับให้หาปัญหา สุดท้ายมันจะกลายเป็นการจับผิดเรื่องเล็กน้อย และแกนความจริงก็ยังดีกว่าสำหรับประเมินโมเดลตรวจจับปัญหาที่เหมาะกับงานของฉัน วิธีนี้ถูกนำไปใช้บางส่วนกับการสร้างคำอธิบายแบบนี้: https://hanzirama.com/character/%E6%9D%A5#explain — ตอนนี้เว็บไซต์นี้กลายเป็นผลพลอยได้เล็ก ๆ จากระบบประเมิน LLM ของฉันไปแล้ว ถ้าต้องการคุณภาพสูงสุด ก็น่าจะต้องตรึงผู้ให้บริการบน OpenRouter ไว้ :exacto อย่างเดียว โดยเฉพาะกับโมเดล open-weight ยังทำให้ได้ผลลัพธ์ที่ดีและทำซ้ำได้ยาก
    • ฉันเคยเห็นว่าถ้าบอกโมเดลตัดสินว่าคำตอบนั้นมาจาก LLM โลคัลขนาดเล็กและความสามารถต่ำ มันจะวิจารณ์คำตอบนั้นแบบโหดมาก แต่ก็ยังไม่ได้ทำอย่างเป็นระบบ เลยไม่แน่ใจว่ามันสรุปทั่วไปได้เกินกว่าความรู้สึกส่วนตัวไหม
      อยากรู้เหมือนกันว่ามีคนอื่นรู้สึกไหมว่า ถ้าหลอกให้ LLM เข้าโหมด “ฉันเหนือกว่า” ได้ มันจะนิสัยเสียขึ้นพอตัว
    • ฉันเคยทำเวอร์ชันหยาบ ๆ ของไอเดียนี้ไว้ในปี 2024[0] และก็น่าสนใจที่แนวคิดนี้ยังไปต่อได้อีก เกณฑ์คุณภาพ เคยตั้งได้ แต่ดูเหมือนไม่ค่อยต่างเท่าไร และโมเดลแถวหน้าก็มักจะเห็นพ้องกันเกือบตลอดพร้อมให้คะแนนคำตอบสูง
      ตอนนี้สถานการณ์ต่างจากเมื่อ 2 ปีก่อนโดยสิ้นเชิง เลยน่ากลับไปดูอีกที [0] https://github.com/Ceroxylon/konsensis
    • ฉันคิดว่ามันขึ้นอยู่กับว่า คำตอบนั้น ตรวจสอบยืนยันได้หรือไม่
      ในแอปของฉันเคยทดสอบโมเดลตัดสินสองตัว ตัวแรกเป็นโมเดลตัดสินสำหรับโมเดลปรับเรซูเม่ โดยเอาเรซูเม่ผลลัพธ์ไปเทียบกับเรซูเม่ต้นฉบับและประกาศงาน แล้วให้คะแนนความเหมาะสมกับความซื่อสัตย์เต็ม 10 คะแนน ซึ่งทำงานได้ดีและมีประโยชน์ ส่วนตัวที่สองเป็นโมเดลรีวิวสำหรับแพลตฟอร์มบอตเทรดดิ้ง LLM โดยใช้ตรวจทานการตัดสินใจของโมเดลหลัก ในกรณีนี้เพราะบอตต้องจัดการกับความกำกวม มันอาจให้โทษมากกว่าประโยชน์ เว้นแต่จะจับความผิดพลาดชัด ๆ ได้ เช่น ตัดสินจากราคาของแท่งเทียนผิด หรือ BUY ทั้งที่ควรเป็น SELL อย่างแรกคือมันเพิ่มความหน่วงในการตัดสินใจ จาก 30 วินาทีเป็น 60 วินาทีสำหรับ Gemma 4 31B หรือก็คูณสองไปเลย อีกอย่างคือโมเดลรีวิวนี้ทำงานเฉพาะกับการตัดสินใจ BUY/SELL ไม่ทำกับ HOLD ดังนั้นเพราะความหน่วงและต้นทุน มันอาจทำให้บอตระวังตัวเกินไปแทนที่จะเพิ่มจำนวนการเทรด เลยคิดว่าถ้าคำตอบตรวจสอบได้ไม่ง่าย ก็ควรใช้โมเดลที่ดีกว่าเพื่อทำให้จบในรอบเดียว มากกว่าจะใช้โมเดลรีวิว ถ้าเป็นอย่างนั้นก็เริ่มไม่ชัดว่าทำไมต้องมีโมเดลตัดสิน และทำไมไม่ให้เอเจนต์ตัวเดิมรีวิวตัวเอง แถมพอไปอ่านข้อความการให้เหตุผลของโมเดลสาย reasoning อย่าง Gemma 4 ก็จะเห็นว่ามันรีวิวตัวเองอยู่แล้ว มันเหมือนพยายามเต็มที่อยู่แล้ว ดังนั้นการทบทวนซ้ำจึงไม่ค่อยเพิ่มข้อมูลอะไร เป็นการทดลองที่น่าสนใจ แต่ต้องประเมินเป็นกรณีไป
    • ประสบการณ์เหมือนกัน การหาคำตอบที่ ดีกว่าอย่างเป็นรูปธรรม นั้นยากกว่าที่คิด แถมมีต้นทุนและช้าด้วย
  • ฉันเคยมีพรอมป์ต์ที่ใช้แนวนี้โดยใช้แค่ Claude Code
    มาทบทวนปัญหาด้านสถาปัตยกรรมกัน เปิดเอเจนต์ 10 ตัว ให้แต่ละตัวสร้าง persona ของตัวเอง จากนั้นให้รีวิว _api.go และเขียนรีวิวลง reviews/-review.md ให้แต่ละเอเจนต์อ่านสรุปหน้าของแต่ละรีวิว แล้วตอบกลับรีวิวที่ตัวเองต้องการ 3 อันแบบ round-robin พร้อมเขียนลง response/--response.md จากนั้นให้เขียนคำโต้แย้งต่อคำตอบเหล่านั้นลง rebuttals/-rebuttal.md สุดท้ายให้แต่ละเอเจนต์เปิดเอเจนต์ใหม่ขึ้นมาอีกตัวเพื่อตรวจทานรีวิว คำตอบ และคำโต้แย้งของตัวเอง แล้วสรุปผลลง findings/-findings.md จากนั้นให้อีกเอเจนต์หนึ่งรวมผลทั้งหมดและเขียนลง review-findings.md โดยให้มีเวอร์ชันที่กระชับด้วย วิธีนี้ใช้ได้ดีทั้งกับโมเดลแถวหน้าและโมเดลที่โฮสต์ในเครื่อง ล่าสุดที่ฉันใช้คือ Qwen 3.5

    • ฉันยังไม่คุ้นกับการใช้หลายเอเจนต์ในโฟลว์เดียว เลยมีหลายเรื่องที่สงสัย
      คุณตรวจดูไฟล์ที่สร้างขึ้นทั้งหมดเพื่อเช็กว่าไม่มี hallucination หรือดูแค่ไฟล์ผลลัพธ์ฉบับย่อสุดท้าย? สงสัยด้วยว่าเจตนาคือให้ hallucination จากหลายเอเจนต์มาหักล้างกันเองจนสุดท้ายเหลือแต่ความจริงหรือเปล่า และเคยเห็นไหมว่าเวอร์ชันสุดท้ายมีอะไรผิดหนัก ๆ ค่าใช้จ่ายก็ดูน่ากังวล แต่ถ้าใช้โมเดลที่โฮสต์ในเครื่องก็น่าจะเบาเรื่องนั้นลงได้ อย่างไรก็ตาม โมเดลที่โฮสต์ในเครื่องยังมีปัญหากับการรันคำสั่งบนเครื่องหรือการเข้าถึงอินเทอร์เน็ตอยู่ไม่ใช่หรือ? ถ้าใช่ แปลว่ามันทำงานโดยอาศัยแค่บริบทของไฟล์นั้น ๆ โดยไม่อ้างอิงส่วนอื่นของโปรเจกต์หรือเปล่า
    • มันดูเหมือนมี กลไกเยอะพอสมควร มากกว่าการรันรีวิวเดิมซ้ำ n ครั้งแล้วรวมผล อยากรู้ว่าทำไมถึงออกแบบมาแบบนี้
  • บริบทพื้นหลังอยู่ที่นี่: Surpassing Frontier Performance with Fusion
    https://news.ycombinator.com/item?id=48525392
    ที่ UI ดูดีกว่านิดหน่อยคือ https://openrouter.ai/fusion เอง Fusion API ของ OpenRouter จะส่งคำขอไปยังหลายโมเดลพร้อมกัน แล้วให้โมเดลตัดสินนำคำตอบมารวมเป็นคำตอบสุดท้าย บอกกันว่าวิธีนี้ใช้เวลามากขึ้น แต่เพิ่มประสิทธิภาพได้มาก อย่างน้อยก็ในเบนช์มาร์ก deep research ที่พวกเขาทดสอบไว้พอสมควร พรีเซ็ต Budget ประกอบด้วยโมเดลที่ถูกกว่าจำนวน 3 ตัว และในเบนช์มาร์กนั้นให้ผลใกล้เคียง Fable แต่มีค่าใช้จ่ายเพียงครึ่งเดียว พรีเซ็ต Quality ประกอบด้วยโมเดลราคาแพง 3 ตัว ชนะ Fable ได้ แต่มีค่าใช้จ่ายเป็น 2 เท่าของ Fable กราฟพาเรโต: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost... ที่น่าสนใจคือแม้จะหลอมรวมโมเดลเดียวกันกับตัวเอง ประสิทธิภาพก็ยังเพิ่มขึ้น 2xOpus4.8 ให้ผลใกล้เคียง Fable ในเบนช์มาร์ก แต่มีค่าใช้จ่ายเป็น 2 เท่าของ Fable ถ้าผสมโมเดลต่างชนิดกันก็ยังได้ประโยชน์เพิ่มอีกเล็กน้อย ดูเหมือนว่าประโยชน์หลักจะมาจาก การคำนวณเพิ่มในช่วงทดสอบ อยากเห็นงานวิจัยเพิ่มเติม โดยเฉพาะกับโมเดลราคาถูกที่เพิ่งออกมาอย่าง DSV4 เมื่อนำมาหลอมรวมกับตัวเองหรือกับ Mimo และอยากเห็นการแลกเปลี่ยนระหว่างการหลอมรวมซึ่งเป็นการคำนวณแบบขนานในช่วงทดสอบ กับการเพิ่มปริมาณ reasoning หรือการเพิ่มจำนวนเทิร์นด้วย

    • ประเด็นที่ว่า “แม้จะหลอมรวมโมเดลเดียวกันกับตัวเอง ประสิทธิภาพก็ยังเพิ่มขึ้น” เป็นวิธีที่พบได้ค่อนข้างบ่อยในยุคที่กำลังก้าวจาก GPT-2 ไป GPT-3
      โดยพื้นฐานแล้วมันคือการ สุ่มตัวอย่างจากพื้นที่ผลลัพธ์ที่เป็นไปได้ให้มากขึ้น ถ้าโมเดลมีโอกาสทำงานบางอย่างสำเร็จ 60% ก็แค่สุ่มตัวอย่าง 5–10 ครั้งแล้วทำอะไรอย่างเสียงข้างมากขึ้นมาได้ พอความแม่นยำของโมเดลสูงขึ้นในโจทย์ที่รวมผลลัพธ์ได้ง่าย วิธีนี้ก็ถูกใช้น้อยลง แต่ถ้ามีตัวตัดสินที่ซับซ้อนขึ้น คือ LLM ที่มีความสามารถ การสุ่มตัวอย่างพื้นที่ผลลัพธ์เพิ่มแล้วคัดเอาส่วนที่ดีออกมาก็ยังเพิ่มประสิทธิภาพได้อยู่
    • น่าสนใจที่พาเนล Fable 5 + GPT 5.5 ชนะสมรรถนะระดับ frontier ของทั้งสองตัวได้ค่อนข้างชัด แต่พอผสม Gemini เข้าไป พาเนลสามโมเดลกลับไม่ดีขึ้น แถมแย่ลง
      สำหรับผม ฟังดูเหมือน Gemini จะอ่อนกว่าในงานนั้น แต่เก่งกว่าในการโน้มน้าวโมเดลตัดสินให้เชื่อวิธีแก้ของตัวเอง และที่ว่า พาเนล Opus 4.8 สองตัว ได้ผลแทบจะตรงกับ Fable 5 ตัวเดียวเป๊ะ ๆ ก็ชวนให้สงสัยเหมือนกัน มีทางรู้ไหมว่า Anthropic แอบทำอะไรทำนองนี้อยู่เบื้องหลังหรือเปล่า?
    • น่าเสียดายที่แทบไม่ได้พูดเลยว่า มันช้าลงแค่ไหน เพราะมีขั้นตอนสังเคราะห์รวมอยู่ด้วย ในเบนช์มาร์ก deep research มันอาจไม่สำคัญมาก แต่ก็น่าสนใจว่าจะใช้กับงานเขียนโค้ดได้อย่างไร
    • ไม่แน่ใจว่ากับโมเดลตอนนี้ยังเป็นแบบนั้นไหม แต่มีงานวิจัยของ Microsoft เมื่อหลายเจเนอเรชันก่อนที่พบว่า ถ้าให้โมเดลทำซ้ำ N ครั้ง ประสิทธิภาพจะดีขึ้นมาก และจุดที่ดีที่สุดคือ ทำซ้ำ 4 รอบ
  • ผมลองประเมินแบบเร็ว ๆ เพื่อดูว่ามันต่างเชิงคุณภาพอย่างไรจากการเรียก Opus 4.7 หรือ GPT 5.5 โดยตรง
    ตามคาด Fusion ช้ากว่า 7 เท่าและแพงกว่า 4 เท่า ไม่ได้ตั้งใจจะวิจารณ์นะ ผมมองว่า Fusion อยู่ในหมวด “ใช้เมื่อจำเป็นเท่านั้น” https://3fpi5avcqq.evvl.io/

    • Fusion ดูดีมากจริง ๆ ในฐานะ เป้าหมายสำหรับการ distill
    • ขอบคุณที่แชร์ ความเร็วคือความกังวลใหญ่สุดของผม แต่ทางนั้นไม่ได้พูดถึงเรื่องนี้เลย
    • อยากรู้ว่าใช้โมเดลอะไรอยู่ข้างใต้ ถ้าใช้ ค่าเริ่มต้น Quality ในอินเทอร์เฟซ ก็สมเหตุสมผลที่ต้นทุนจะประมาณ 4 เท่า เพราะมันคือโมเดลระดับ frontier 3 ตัวและให้หนึ่งในนั้นเป็นตัวตัดสิน
      ไอเดียหลักน่าจะเป็นการใช้ Fusion กับโมเดลที่ง่ายและถูกกว่านี้
    • ผมว่ามันค่อนข้างสวนทางกับสัญชาตญาณ โอกาสที่การหากรอบและโครงสร้างที่เหมาะสมให้สิ่งนี้ทำงานได้ดีจะไม่ใช่เรื่องง่ายมีสูง โมเดลพวกนี้ไม่ค่อยชอบเล่นร่วมกันเท่าไรนัก
      เลยอยากรู้ว่าเวอร์ชันของพวกเขาจะทนแค่ไหนในการใช้งานจริง
  • ผมคิดเรื่องนี้มามาก และถ้าจะทำให้เข้าใจง่ายก็อาจมองแต่ละโมเดลเป็น การกระจายทรงระฆัง บนองค์ความรู้ของมนุษย์ ซึ่งแต่ละโมเดลก็มีการกระจายต่างกัน
    ถ้าใช้หลายโมเดล คุณสามารถเปลี่ยนการกระจายของอีกโมเดลได้ด้วยข้อความที่อยู่นอกโค้งเดิม แต่พอคิดอีกที ก็สงสัยว่า SFP กับ reinforcement learning ได้เปลี่ยนการกระจายข้อความตั้งต้นไปมากพอหรือยัง จนผลลัพธ์รวมของโมเดลต่าง ๆ จะกลายเป็นสิ่งที่ดีกว่าเดิมได้จริง หรือสุดท้ายก็เป็นแค่ ห้องเสียงสะท้อน กันแน่ ตอนนี้ยังพิสูจน์ไม่ได้ แต่ผมเชื่อว่าไม่ใช่อย่างนั้น

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

  • ช่วงสุดสัปดาห์ ผมได้แรงบันดาลใจจากโมเดล OpenRouter Fusion ใหม่ เลยลองทำดูว่าจะรันสิ่งนี้ใน Claude Code ได้ไหม และจะทำให้คนอื่นลองใช้ได้ง่ายไหม
    สิ่งที่ทำขึ้นคือ claude-fusion-launcher — รัน Claude Code บนพาเนลของโมเดล แทนที่จะเป็นโมเดลเดี่ยว และแสดงค่าใช้จ่ายด้วย https://github.com/smorinlabs/claude-fusion-launcher

    • มันไม่แพงขึ้นอย่างรวดเร็วเหรอ? พรอมป์ต์ครั้งเดียวที่ผมลองบนเว็บไซต์ เกือบจะตก 1 ดอลลาร์ต่อพรอมป์ต์ เลย
  • สงสัยว่าการให้โมเดลเดียวกันสร้างซ้ำหลายครั้งด้วยพรอมป์ต์เดิม แต่ใช้อุณหภูมิสูงขึ้น จะเทียบเท่ากับการรันคนละโมเดลหรือไม่
    ผมสงสัยว่าความแปรผันที่สัมผัสได้ระหว่างโมเดล frontier ต่าง ๆ ส่วนหนึ่งค่อนข้างมากอาจมาจากความสุ่มเมื่ออุณหภูมิไม่เป็นศูนย์ โมเดลเหมือนถูกฝึกให้คืนรายการเป็นจำนวนกลม ๆ ที่ดูดี เช่น 5, 10, 15 อาจเป็นเพราะการรบกวนจากการเรียนรู้จากเอกสารการตลาดด้วย นอกจากนี้ recall ในบริบทขนาดใหญ่ก็ยังห่างไกลจาก 100% ดังนั้นถ้าในโค้ดมีบั๊ก 27 จุด ไม่ว่าจะใช้หลายโมเดลหรือเรียกโมเดลเดิมซ้ำหลายรอบ แต่ละรอบอาจเจอ ปัญหา 10 ข้อ ที่ต่างกันจากใน 27 ข้อนั้น

  • สงสัยว่ามีงานวิจัยอย่างเป็นทางการในด้านนี้หรือไม่ ฉันเองก็เคยลองแนวทางลักษณะนี้ในแบบดัดแปลงมาแล้ว แต่ก็พูดอย่างมั่นใจได้ยากว่าผลลัพธ์ดีกว่า
    กังวลว่ามันอาจคล้ายกับการไปถามที่ปรึกษา 2-3 คนแยกกันถึงกลยุทธ์ที่เหมาะสมที่สุดสำหรับธุรกิจ ไม่ค่อยแน่ใจว่าการเอาคำตอบมารวมกันจะได้สิ่งที่ดีกว่าอย่างมีนัยสำคัญจริงหรือไม่

  • ฉันก็เปิดตัวฟีเจอร์คล้ายกันนี้ใน TrustedRouter แบบโอเพนซอร์ส พร้อมใช้ การเข้ารหัสแบบต้นทางถึงปลายทาง ด้วย: https://trustedrouter.com/

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