1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Echo ผสานโมเดล open-weight หลายตัว เช่น GLM-5.2 และ Kimi K2.7 แบบต่อคำขอ เพื่อชดเชยข้อจำกัดของวิธีที่มอบงานทั้งหมดให้โมเดลเดียว
  • ในแต่ละคำขอ จะกำหนด ปริมาณการคำนวณและโมเดลที่เข้าร่วม รวมถึงปรับวิธีรวมผลลัพธ์ ทำให้พรอมป์ง่าย ๆ ใช้ทรัพยากร inference น้อยลง
  • ในชุดประเมินแรก ทำผลงานเหนือกว่าโมเดลเดี่ยวที่ดีที่สุดในพูลอย่างสม่ำเสมอ และได้ ผลลัพธ์รวมใกล้เคียงกับ Fable ด้วยต้นทุน inference ประมาณหนึ่งในสาม
  • แม้โมเดลที่โดยรวมอ่อนกว่าก็ยังมีความสามารถที่เสริมกันจนเป็นประโยชน์ในปัญหาหรือการผสมบางแบบ แต่ยังมีกรณีที่ ตัดสินใจจัดสรรและรวมผลผิดพลาด อยู่
  • เปิดให้ใช้แชตอินเทอร์เฟซและ API ที่เข้ากันได้กับ OpenAI แล้ว และกำลังทดสอบว่าแนวทางเดียวกันนี้ยังใช้ได้ผลกับงานโค้ดและเอเจนต์ ซึ่งวัดคุณภาพได้ยากกว่าหรือไม่

การเลือกโมเดลและการรวมผลลัพธ์

  • ในการทดลองช่วงแรก นำ GLM-5.2, Kimi K2.7 ฯลฯ เข้าไปทำการประเมินเดียวกัน และวัดผลโดยสมมติว่ารู้ล่วงหน้าว่าแต่ละปัญหาควรใช้โมเดลใดและวิธีรวมเอาต์พุตแบบใดจึงเหมาะสม
    • ระบบสมมตินี้ทำผลงานได้สูงกว่าโมเดลเดี่ยวใด ๆ ที่อยู่ในพูลอย่างมาก
    • เนื่องจากระบุการตัดสินใจที่ดีได้หลังจากเห็นผลลัพธ์แล้วเท่านั้น จึงใช้กับการ deploy จริงไม่ได้ และ Echo เป็นความพยายามที่จะกู้คืนข้อได้เปรียบบางส่วนโดยไม่ต้องมีข้อมูลล่วงหน้า
  • เลือกปริมาณการคำนวณ โมเดลที่เข้าร่วม และวิธีรวมผลลัพธ์ตามลักษณะของคำขอ
    • สำหรับพรอมป์ง่าย ๆ จะจัดสรร inference ค่อนข้างน้อย
    • สำหรับปัญหาอื่น ๆ จะจัดให้หลายโมเดลรับผิดชอบคนละส่วน
  • ความสามารถของโมเดลต่าง ๆ นั้น เสริมกัน ดังนั้นแม้โมเดลที่ประสิทธิภาพรวมต่ำกว่าอย่างชัดเจน ก็อาจมีประโยชน์มากในปัญหาหรือการผสมบางแบบ

ผลการประเมินและการทดสอบสาธารณะ

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

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

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News
  • นี่เป็น dark pattern แบบคลาสสิกที่แสดง ช่องป้อนข้อความของ Message Echo ให้ดูเหมือนว่าสามารถรับคำตอบได้ แล้วค่อยพาไปยังหน้าสมัครสมาชิก
    โดนขัดขาตั้งแต่การกระทำแรกที่เว็บชักนำไว้ ก็เลยออกทันทีและคงไม่กลับมาอีก

    • ฉันก็รู้สึกเหมือนกัน และเกลียด dark pattern แบบนี้มากจนตอนนี้ไม่สนใจผลิตภัณฑ์นี้เลย
    • ตอนนี้กำลังลบออกอยู่
    • ในอีกมุมหนึ่ง ถ้าอนุญาตให้ใช้งานก่อนล็อกอิน ผู้สร้างก็ต้องแบกรับต้นทุนของคำถามเริ่มต้น และอาจโดนใช้งานในทางที่ผิดจนเกิดบิลมหาศาลได้
      ถ้ามองจากฝั่งคนทำผลิตภัณฑ์ AI ก็เป็นทางเลือกที่พอเข้าใจได้
  • ขอบคุณทุกคนที่ใช้ Echo และให้ฟีดแบ็ก นี่แหละคือเหตุผลที่เราเปิดตัวตั้งแต่เนิ่นๆ
    เราจะเผยแพร่การประเมินที่แสดงช่องว่างกับระดับชั้นนำล่าสุดให้แม่นยำยิ่งขึ้นต่อไป รวมถึง เบนช์มาร์กด้านโค้ดและเอเจนต์ที่ยากขึ้น และจะขยายแดชบอร์ดการประเมินแบบสาธารณะด้วย ปัญหาที่พบใน UI ของแดชบอร์ดการประเมินและขั้นตอนสมัครสมาชิกได้แก้ไขแล้วในระบบจริง
    การทดลองใช้ Echo ไม่ต้องใช้บัตรเครดิต และแต่ละบัญชีจะได้รับ เครดิตฟรี 10 ดอลลาร์ สำหรับใช้ทั้ง API และแชต
    เรากำลังสำรวจวิธีจัดสรรทรัพยากรการอนุมานอย่างมีประสิทธิภาพระหว่างโมเดล open-weight ในภาพที่กว้างกว่าแค่การ route โมเดลแบบธรรมดา ไม่ได้ตัดสินใจแค่ว่าจะใช้โมเดลไหน แต่รวมถึงจะทุ่มคอมพิวต์ให้คำขอมากแค่ไหน และจะรวมผลลัพธ์ระหว่างทางอย่างไรด้วย
    ensemble เป็นแนวคิดที่รู้จักกันมาตั้งแต่ก่อน random forest แต่แก่นของ Echo คือการจำลองและใช้ประโยชน์จากสิ่งนี้โดยไม่ต้องจ่ายต้นทุน ensemble เต็มชุดในทุกคำขอ แม้จะมีส่วนที่คล้ายกับ Fusion หรือ Fugu ในเชิงแนวคิด แต่สถาปัตยกรรมและเป้าหมายการปรับให้เหมาะสมต่างกัน

    • ฟีดแบ็กเล็กน้อย: create password บังคับให้มีอักขระพิเศษ แต่รหัสผ่านที่ Google Password Manager สร้างให้ตามค่าเริ่มต้นไม่มีอักขระพิเศษ
      ถ้าเป็นชุดตัวอักษรและตัวเลขยาวสองหลักก็น่าจะพอแล้ว แต่ไอเดียโดยรวมยอดเยี่ยมมาก
    • สงสัยว่าทำไมถึงใช้ dark pattern ตอนแรกสนใจอยู่ แต่ตอนนี้หายไปแล้ว
    • ลองสมัครแค่ครั้งเดียว แต่กลับขึ้นข้อผิดพลาด too many authentication attempts
    • ควร ลบ dark pattern ออก
    • พูดถึง open-weight อยู่ตลอด แต่ไม่เปิดเผยเลยว่าใช้โมเดลอะไรบ้าง
      ถ้าไม่มีความโปร่งใส ก็ไม่เข้าใจว่าการใช้โมเดล open-weight ให้ประโยชน์อะไรกับผู้ใช้ปลายทาง
  • คำอธิบายว่า ได้ผลลัพธ์ระดับ Fable ที่ต้นทุนหนึ่งในสาม ดูไม่น่าดึงดูดนักสำหรับผู้ใช้แพ็กเกจ 200 ดอลลาร์ต่อเดือน ที่มีการอุดหนุนอย่างมาก
    ไม่รู้ว่าแพ็กเกจนี้จะอยู่ได้นานแค่ไหน แต่ในระหว่างนี้ แม้แต่ราคา API สาธารณะเพียงหนึ่งในสามก็ยังไม่ได้น่าสนใจขนาดนั้น

    • ในแพ็กเกจ 200 ดอลลาร์ต่อเดือน หลังใช้โควตา Fable รายสัปดาห์หมดแล้ว ฉันลองรันแผนงานโค้ดขนาดกลางด้วยเครดิตโปรโมชัน 200 ดอลลาร์ แล้วใช้ไป 120 ดอลลาร์ใน 1 ชั่วโมง 15 นาที
      มี sub-agent หลายตัวรันพร้อมกัน และ Claude ก็ลืมคำสั่งที่ให้ใช้โมเดลราคาถูก เลยมีอินสแตนซ์ Fable หลายตัวทำงานอยู่ แต่การคิดเงินตามโทเค็นนั้นรับไม่ไหว 200 ดอลลาร์ต่อเดือนก็แพงแล้ว แต่ 200 ดอลลาร์ในคืนเดียวนั้นเหลือเชื่อ
    • ลูกค้าองค์กรที่ใช้ในการทำงานไม่สามารถใช้แพ็กเกจอุดหนุนได้ ดังนั้นสัดส่วนของแพ็กเกจแบบนั้นในปริมาณการใช้งานรวมก็น่าจะเป็นเพียงส่วนน้อย
    • แพ็กเกจนี้น่าจะอยู่ต่อไปจนถึง IPO แต่หลังจากนั้นคงอยู่ได้ไม่นาน
      ถ้าผู้ใช้แพ็กเกจ 200 ดอลลาร์ต่อเดือนใช้เครดิต API มูลค่า 10,000 ดอลลาร์ อัตรากำไรต่อผู้ใช้จะเป็น -98% ซึ่งไม่ช่วยเรื่องผลประกอบการ
    • ถ้าจุดประสงค์คือการมีข้อจำกัดการใช้งาน หรือหลีกเลี่ยงการถูกระงับบัญชีเมื่อข้ามเส้นที่กำหนด เรื่องก็จะต่างออกไป
    • ตามอีเมลที่ได้รับจาก Anthropic วันนี้ Fable 5 จะเปลี่ยนเป็นระบบเครดิตตามการใช้งานตั้งแต่ 20 กรกฎาคม
      ยังใช้งานต่อได้ แต่ต้องใช้เครดิตแบบจ่ายตามการใช้ และจะไม่ถูกรวมอยู่ในโควตาการใช้งานของแพ็กเกจสมัครสมาชิก
  • คงไม่น่าแปลกใจถ้าในอีกไม่กี่ปีข้างหน้า แนวคิดเรื่อง โมเดลที่ดีที่สุด จะกลายเป็นเรื่องเฉพาะกลุ่ม
    ในระบบที่ใช้งานจริงส่วนใหญ่ ผู้ชนะอาจเป็น orchestrator ที่รู้ว่าเมื่อไรควรใช้โมเดลราคาถูก เมื่อไรควรสลับไปใช้โมเดลที่ทรงพลัง และเมื่อไรควรรวมหลายเอาต์พุตเข้าด้วยกัน

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

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

  • วิธีนี้จะทำงานได้ไม่ดี ถ้าไม่รู้ความซับซ้อนของปัญหาล่วงหน้า และไม่มีหลักประกันว่าบทสนทนาถัดไปจะถูกส่งไปยังโมเดลเดิม
    ถ้าส่งบทสนทนาเดียวกันไปให้หลายโมเดลแบบ round robin แคชจะพัง และอาจมีค่าใช้จ่ายมากกว่าระบบที่คำนึงถึงแคชเสียอีก

    • ใช้เทคนิค Ralph Wiggum ได้: https://ghuntley.com/ralph/
    • cache hit ก็ควรเป็นส่วนหนึ่งของกลยุทธ์ด้วย
  • ฉันใช้ Anthropic Opus 4.8 กับ Fable 5 มาพักหนึ่งแล้ว และก็ลองโมเดล OpenAI รุ่นล่าสุดด้วย แต่ทั้งหมดสร้างเอาต์พุตที่ไม่จำเป็นมากเกินไปอย่างมาก
    ฉันเริ่มลองโมเดลอื่นไม่ใช่เพราะราคา แต่เพราะคุณภาพ และในขอบเขตงานของฉัน GLM 5.2 เหนือกว่า Fable 5 มากในทุกด้าน ถึงขั้นน่าแปลกใจเสียมากกว่าถ้ามันทำงานไม่สำเร็จ
    Kimi K2.7 ต้องการคำสั่งเพิ่มอีกนิดหน่อย แต่ให้ประสบการณ์ใช้งานที่ดีกว่า Opus 4.8 ส่วน K3 ฉันยังไม่ได้ลอง โมเดล OpenAI รุ่นล่าสุดมีความสามารถด้านการออกแบบและการพัฒนาซอฟต์แวร์ที่แย่อย่างไม่น่าเชื่อ
    นี่เป็นการประเมินที่จำกัดอยู่ในขอบเขตงานของฉันซึ่งมีงานด้านการวิเคราะห์ข้อมูล แมชชีนเลิร์นนิง และวิศวกรรมซอฟต์แวร์จำนวนมาก

  • ไม่มีทั้งเบนช์มาร์กและข้อมูลว่าใช้โมเดลอะไร มีแค่วิดีโอที่สร้างด้วย AI กับหน้า signup
    มันทำให้นึกถึงมุกสถาปัตยกรรมที่ว่า “เราเปลี่ยน monolith ให้เป็น microservices เพื่อให้ทุก incident กลายเป็นเหมือนคดีฆาตกรรมปริศนา”

    • ตัวประเมินแบบสาธารณะอยู่ที่ https://echo.tracerml.ai/eval/
      ตอนนี้เปิดเผย 907 แถวที่บันทึกไว้จากตระกูลเบนช์มาร์ก 7 ชุด โดยสามารถดูพรอมป์ต์ เอาต์พุต การประเมิน และบันทึกค่าใช้จ่ายได้ และมีแผนจะเพิ่มอีก
      ตัวนโยบาย routing ต่อคำขอคือสินค้าหลักของเรา จึงยังไม่เปิดเผย แต่เราสามารถเปิดเผยบางส่วนของรายการโมเดล open weight ที่ใช้งานได้ วันที่ของเวอร์ชัน สัดส่วนการจัดสรรรวม และการตั้งค่าการประเมินได้ ตราบใดที่ไม่เปิดเผยเคล็ดลับรายคำขอ กำลังทำวิดีโอใหม่อยู่ด้วย
    • เบนช์มาร์กอยู่ที่ https://echo.tracerml.ai/eval/
      มันไม่ใช่เบนช์มาร์กที่ดีนัก แต่อย่างน้อยก็มีอยู่
    • โดยพื้นฐานแล้วมันดูเหมือนความพยายามจะทำ OpenRouter ขึ้นมาใหม่ OpenRouter เป็น ชั้น abstraction ด้านโครงสร้างพื้นฐาน ที่ชาญฉลาดและทำงานได้ค่อนข้างดี โดยซ่อนความต่างของผู้ให้บริการรายต่าง ๆ ผ่าน failover การวัดการใช้งาน การสลับอัตโนมัติ ฯลฯ
      มันเลยน่าเสียดายที่ดูเหมือนเป็นความพยายามจะบอกนักลงทุนว่า “OpenRouter กลายเป็นยูนิคอร์นไปแล้ว งั้นฉันก็ใช้ vibe coding ทำอะไรคล้าย ๆ กันได้เหมือนกัน” มากกว่าจะเป็นการแก้ปัญหาจริง
      การเรียกมันว่า ระดับ Fable ก็ให้ความรู้สึกว่าขี้เกียจทางปัญญาหรือไม่ก็ไม่ซื่อสัตย์
    • มันทำให้นึกถึงวลีของ tenderlove ที่ว่า “microservices เปลี่ยนการเรียกฟังก์ชันให้กลายเป็นปัญหาการประมวลผลแบบกระจาย
    • เท่าที่ฉันรู้ แอปที่ถูกป้องกันด้วยล็อกอิน ไม่ถูกอนุญาตใน Show HN
  • สงสัยว่านี่คือการสร้าง Dogpile.com ขึ้นมาใหม่ ซึ่งเคยรวบรวมผลลัพธ์จาก Ask Jeeves, AltaVista และ Lycos หรือเปล่า เวลาดูเหมือนจะวนกลับมาอีกครั้ง

    • ไอเดียที่ดีมักยังคงดีอยู่ แม้ยุคสมัยและเครื่องมือจะเปลี่ยนไป
    • โมเดลแบบ ensemble มักให้ประสิทธิภาพดีที่สุดใน Kaggle มาโดยตลอด
      เราก็ทำแนวทางเดียวกันนี้ไว้: https://trustedrouter.com/blog/prometheus-2-new-draco-state-...
    • เป็นแนวทางที่ไม่ใช้ ขนาด EC2 instance เดียวกันกับทุกงานของบริการ
    • คุณจะสร้างล้อสามเหลี่ยมก็ได้ แต่ที่ล้อมันกลมย่อมมีเหตุผล
    • มองได้ว่าเป็น Mixture of Models
      ผลิตภัณฑ์ AI gateway อื่น ๆ อย่าง OpenRouter, JusCode และ Fireworks ก็แนะนำโครงแบบเดียวกันนี้ในช่วงหลัง จึงมีโอกาสว่ามันมีส่วนที่มีประโยชน์อยู่มาก