معايير أداء ساكانا فوجو: ماذا يعني أن يضاهي فيبل 5؟

معايير Fugu من Sakana هي ادعاءات تكافؤ أبلغ عنها البائع، وليست نتائج تم التحقق منها مستقلًا. وفقًا لصفحة إصدار Sakana، فإن Fugu Ultra "يقف كتفًا بكتف مع النماذج الرائدة مثل Fable 5 وMythos Preview" في مهام الهندسة والعلوم والاستدلال، وأن Fugu "يتفوق باستمرار" على Gemini 3.1 Pro وOpus 4.8 وGPT 5.5 في مجموعة محددة من التطبيقات. قبل قراءة أي رقم، تذكّر أن Fugu منسق يستدعي نماذج متقدمة من بائعين آخرين؛ لذلك نتائجه ليست انتصارات لنموذج واحد بالطريقة التي تُقرأ بها نتائج Fable 5.

جرّب Apidog اليوم

ما هو Fugu فعلًا؟

Fugu ليس نموذجًا أساسيًا واحدًا. هو نظام تنسيق متعدد الوكلاء يظهر لك كأنه نموذج واحد خلف API واحدة متوافقة مع OpenAI.

تصفه Sakana بأنه نموذج لغوي متخصص في:

• التفويض بين الوكلاء
• اتصال الوكلاء
• تجميع العمل
• اختيار ما إذا كان سيرد مباشرة أو سيبني فريقًا داخليًا للمهمة

هذا يغيّر طريقة قراءة المعايير.

عندما يسجل نموذج تقليدي نتيجة، فالرقم يعكس غالبًا أداء أوزان النموذج نفسه. أما عندما يسجل Fugu نتيجة، فقد يكون استدعى Opus 4.8 أو GPT 5.5 أو Gemini 3.1 Pro، ثم جمع مخرجاتها في إجابة واحدة.

لذلك، عبارة مثل "Fugu يهزم Opus 4.8" قد تعني عمليًا: نظام تنسيق استخدم Opus مع نماذج أخرى وخرج بنتيجة أفضل. هذه نتيجة لنظام من النماذج، وليست دليلًا على أن نموذجًا واحدًا من Sakana يتفوق وحده على Opus.

للسياق المعماري، راجع شرحنا لماهية Sakana Fugu.

ادعاء التكافؤ: "كتفًا بكتف مع Fable 5 وMythos Preview"

الادعاء الأول من Sakana هو أن Fugu Ultra "يقف كتفًا بكتف مع النماذج الرائدة مثل Fable 5 وMythos Preview" عبر معايير الهندسة والعلوم والاستدلال.

اقرأ الصياغة بدقة:

• هذا ادعاء تكافؤ.
• ليس ادعاء تفوق.
• Sakana لا تقول إن Fugu Ultra يهزم Fable 5.

هناك نقطتان مهمتان للمطورين عند تقييم هذا الادعاء.

أولًا، المقارنة مع "Mythos Preview"، وليس Mythos 5 الحالي المتاح بشكل عام. إذا كنت قرأت عن نموذج فئة Mythos، فستعرف أن Preview والنسخة المشحونة منتجان مختلفان.

ثانيًا، لا توجد حتى الآن منهجية منشورة يمكن إعادة تشغيلها خارج Sakana:

• لا توجد شبكة نقاط لكل مهمة.
• لا توجد أداة تقييم عامة.
• لا توجد إعادة إنتاج من طرف ثالث.
• لا توجد إعدادات كاملة قابلة للتحقق للمقارنات.

تعامل مع "كتفًا بكتف" كصياغة بائع لنتائج داخلية، لا كقياس مستقل.

الادعاء الأقوى: "يتفوق باستمرار" في تطبيقات محددة

تقدم Sakana ادعاءً ثانيًا أقوى: أن Fugu "يتفوق باستمرار" على منافسين مهيئين في مجموعة تطبيقات محددة.

المنافسون المذكورون هم:

• Gemini 3.1 Pro، بإعداد "عالي"
• Opus 4.8، بإعداد "أقصى"
• GPT 5.5، بإعداد "فائق العلو"

والتطبيقات المذكورة تشمل:

• AutoResearch
• مكعب روبيك
• التصميم الميكانيكي
• تحليل الخط اليدوي الياباني
• الشطرنج بلقطة واحدة
• التنبؤ بالسلاسل الزمنية المالية

هذه ليست مجموعة معايير أكاديمية عامة. إنها مهام تطبيقية شاملة end-to-end، وهذا النوع من المهام مناسب جدًا لمنسق مثل Fugu، لأنه يستطيع تقسيم المشكلة، توجيه أجزاء منها إلى نماذج مختلفة، ثم تجميع النتيجة.

لكن القراءة الصحيحة هي:

Fugu قد يتفوق كنظام تنسيق، لا كنموذج واحد مستقل.

إذا كانت نتيجة AutoResearch أفضل من Opus 4.8، فقد يكون Fugu قد استدعى Opus نفسه، ثم أضاف نماذج أخرى، ثم دمج النتائج. هذا مفيد عمليًا، لكنه ليس دليلًا على أن نموذج Sakana واحد أقوى في الاستدلال من Opus.

لا تصغ الادعاء على أنه "Fugu يهزم Fable 5". Sakana لم تقل ذلك. ادعاء التكافؤ يستهدف Fable 5 وMythos Preview، بينما ادعاء التفوق يستهدف Gemini 3.1 Pro وOpus 4.8 وGPT 5.5 في تطبيقات محددة.

لماذا لا يمكن التحقق من هذه الأرقام مستقلًا بعد؟

لا يوجد تكرار مستقل بعد. كل رقم من معايير Fugu في هذه الصفحة هو تقرير من البائع، وتم قياسه على إعدادات Sakana الخاصة، مع تهيئات المنافسين التي اختارتها Sakana. اعتبارًا من 22 يونيو 2026، لم يُعد أي طرف ثالث تشغيل هذه المهام، ولم تُنشر شبكة نقاط لكل مهمة، ولم تصدر أداة تقييم عامة. الموقف العملي هو التعامل مع كل ذلك كادعاءات، لا كقياسات.

هذا ليس انتقادًا خاصًا لـ Sakana. في يوم إطلاق أي نموذج، تكون معظم الأرقام عادة من البائع. لكن Fugu يضيف تعقيدًا إضافيًا لأن التحقق منه يتطلب أكثر من مجرد النموذج والاختبار.

لإعادة إنتاج معيار نموذج واحد، تحتاج عادة إلى:

1. النموذج
2. مجموعة الاختبار
3. إعدادات التشغيل

أما لإعادة إنتاج معايير Fugu، فستحتاج إلى:

1. Fugu نفسه
2. كل نموذج أساسي يوجّه إليه
3. نفس إصدارات تلك النماذج
4. نفس إعدادات الجهد
5. نفس طوبولوجيا التنسيق
6. نفس منطق اختيار الوكلاء لكل مهمة

وبما أن Fugu يكيف طوبولوجيا الوكلاء ديناميكيًا، فقد لا يستخدم تشغيلان للمطالبة نفسها الفريق الداخلي نفسه. هذه ميزة للمستخدمين، لكنها تجعل القياس القابل للتكرار أصعب.

لهذا السبب، يجب أن تكون متشككًا في أي جدول متداول بعنوان "Fugu سجل X" من مصادر ثانوية. بعض المقالات تخلط أيضًا بين Mythos Preview وMythos الحالي. لذلك تبقى مقارنتنا بين Fugu Ultra وFable 5 وMythos نوعية للسبب نفسه.

السجلات البحثية وراء Fugu

تسويق Sakana يستند إلى أبحاث حقيقية، لكن لا ينبغي الخلط بين الأوراق البحثية ومواصفات المنتج النهائي.

هناك ورقتان من ICLR 2026 تستحقان القراءة كسياق بحثي.

الأولى هي Trinity: "منسق نماذج لغوية كبيرة LLM متطور" (arXiv:2512.04695).

Trinity هو منسق بأقل من 20,000 معلمة، تم تحسينه بالتطور الخالي من المشتقات، ويستخدم أدوارًا مثل:

• المفكر
• العامل
• المحقق

الثانية هي Conductor: "تعلم تنسيق الوكلاء باللغة الطبيعية" (arXiv:2512.04388).

Conductor هو نموذج بحجم 7B تم تدريبه بالتعلم المعزز، ويتعلم بنية الاتصال بين الوكلاء. تزعم الورقة أنه يتفوق على Mixture-of-Agents بتكلفة أقل.

لا تخلط بينهما:

الورقة	الحجم	الأسلوب	ملاحظة
Trinity	أقل من 20K معلمة	تطور خالٍ من المشتقات	منسق صغير
Conductor	7B	تعلم معزز	يتعلم اتصال الوكلاء

ولا تفترض أن مواصفات أي ورقة تصف بالضبط المنتج المشحون باسم Fugu. ربط الرقم 7B أو أي نموذج أساسي محدد بمنتج Fugu هو استنتاج من طرف ثالث، وليس مواصفة منشورة رسميًا.

ملخص المواصفات المؤكدة وغير المؤكدة

البند	ما تقوله Sakana / المصادر	الثقة
نوع النظام	منسق متعدد الوكلاء خلف نموذج واحد	مذكور في صفحة الإصدار
المتغيرات	Fugu للاتزان وزمن الانتقال المنخفض، وFugu Ultra لأقصى جودة	مذكور في صفحة الإصدار
الاسم التجريبي القديم	كان المتغير الصغير يسمى "Fugu Mini" في النسخة التجريبية والصحافة	تاريخي
API	نقطة نهاية واحدة متوافقة مع OpenAI لكلا المتغيرين	مذكور في صفحة الإصدار
النماذج الأساسية	يستدعي نماذج لغوية كبيرة متطورة متعددة، بما في ذلك نفسه بشكل متكرر	مذكور في صفحة الإصدار
عدد معلمات المنتج	غير منشور؛ تفاصيل 7B / Conductor استنتاجات من طرف ثالث	[تحقق]
منهجية المعايير	تقرير من البائع، إعداد Sakana الخاص، لا توجد أداة عامة	[تحقق]

ملاحظة التسمية مهمة: كان المتغير الصغير يسمى "Fugu Mini" خلال النسخة التجريبية التي ضمت نحو 500 مستخدم وبدأت تقريبًا في 24-25 أبريل 2026. صفحة الإصدار الحالية تستخدم "Fugu" و"Fugu Ultra". استخدم الأسماء الحالية في التوثيق والكود.

كيف تختبر Fugu بنفسك؟

لا يمكنك التحقق من معايير Sakana الداخلية، لكن يمكنك بناء تقييمك الخاص.

بما أن Fugu يستخدم بروتوكول Chat Completions المتوافق مع OpenAI، يمكنك توجيه عميل OpenAI الحالي إلى عنوان URL الأساسي الخاص بـ Fugu، ثم تشغيل مهامك الحقيقية.

لم يكن عنوان URL الأساسي منشورًا في صفحة عامة اعتبارًا من 22 يونيو 2026. انسخه من لوحة التحكم في console.sakana.ai، ولا تعتمد على مضيف منقول من طرف ثالث.

مثال Python:

from openai import OpenAI

# انسخ عنوان URL الأساسي الحقيقي من console.sakana.ai بعد تسجيل الدخول.
client = OpenAI(
    api_key="YOUR_FUGU_API_KEY",
    base_url="<YOUR_FUGU_BASE_URL_FROM_CONSOLE>",
)

resp = client.chat.completions.create(
    model="fugu-ultra",  # استخدم "fugu" للمتغير المتوازن، وتحقق من المعرفات في لوحة التحكم
    messages=[
        {
            "role": "system",
            "content": "You are a precise code reviewer."
        },
        {
            "role": "user",
            "content": "Review this function for security issues:\n<paste code>"
        },
    ],
)

print(resp.choices[0].message.content)

المعرفات المتداولة حتى الآن هي:

• fugu
• fugu-ultra

لكن لا تثبتها في الكود دون تحقق. اقرأ المعرفات الدقيقة من لوحة التحكم أو من ملف إعدادات قابل للتغيير.

مثال أبسط لتجنب hardcoding:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["FUGU_API_KEY"],
    base_url=os.environ["FUGU_BASE_URL"],
)

model = os.environ.get("FUGU_MODEL", "fugu")

resp = client.chat.completions.create(
    model=model,
    messages=[
        {"role": "user", "content": "Summarize this incident report in 5 bullet points:\n<paste report>"}
    ],
)

print(resp.choices[0].message.content)

ما الذي يجب قياسه؟

لا تختبر Fugu على AutoResearch أو الشطرنج فقط لأن البائع ذكرها. اختبره على المهام التي تهم منتجك.

استخدم مجموعة صغيرة من الحالات الواقعية، مثل:

• مراجعة كود أمني
• تلخيص تذاكر دعم طويلة
• توليد اختبارات وحدات
• استخراج بيانات منظمة من نصوص
• تصنيف أخطاء إنتاج
• كتابة استعلامات SQL
• تحليل مستندات داخلية

وسجل لكل تشغيل:

المقياس	لماذا يهم؟
جودة الإجابة	هل حل المهمة فعلًا؟
زمن الاستجابة	Fugu قد يبني فريق وكلاء داخليًا، ما قد يغير الزمن
التكلفة	التوجيه التكيفي قد يزيد أو يقلل عدد الاستدعاءات
عدد الرموز	مهم للتكلفة والحدود
الاستقرار	هل يعطي نتائج متقاربة عبر التشغيلات؟
الأخطاء	رموز الحالة، timeouts، فشل الأدوات

بما أن Fugu يقرر لكل طلب هل يرد مباشرة أو يجمع فريقًا، فقد تختلف التكلفة وزمن الاستجابة بين تشغيل وآخر للمطالبة نفسها. لذلك شغّل كل حالة أكثر من مرة، ولا تعتمد على تشغيل واحد.

كيف تبني مقارنة عادلة؟

استخدم نفس المدخلات بالضبط عبر كل نموذج.

مثال هيكل تقييم بسيط:

test_cases = [
    {
        "name": "security_review_1",
        "prompt": "Review this function for SQL injection risks:\n<paste code>"
    },
    {
        "name": "support_summary_1",
        "prompt": "Summarize this support ticket and extract action items:\n<paste ticket>"
    },
    {
        "name": "json_extraction_1",
        "prompt": "Extract the following fields as JSON: customer_name, issue, severity:\n<paste text>"
    },
]

ثم شغّلها على Fugu وعلى النماذج الفردية التي تستخدمها فعلًا:

models = [
    {"name": "fugu", "client": fugu_client, "model": "fugu"},
    {"name": "fugu-ultra", "client": fugu_client, "model": "fugu-ultra"},
    {"name": "baseline-model", "client": baseline_client, "model": "your-baseline-model"},
]

وسجل النتائج في CSV أو قاعدة بيانات داخلية:

import csv
import time

with open("eval_results.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.DictWriter(
        f,
        fieldnames=["case", "model", "latency_seconds", "output"]
    )
    writer.writeheader()

    for case in test_cases:
        for m in models:
            start = time.time()

            resp = m["client"].chat.completions.create(
                model=m["model"],
                messages=[
                    {"role": "user", "content": case["prompt"]}
                ],
            )

            latency = time.time() - start
            output = resp.choices[0].message.content

            writer.writerow({
                "case": case["name"],
                "model": m["name"],
                "latency_seconds": round(latency, 3),
                "output": output,
            })

هذا النوع من التقييم يخبرك بما يهمك أنت: هل Fugu مفيد في سير عملك، وبأي تكلفة وزمن استجابة؟

كيف يتناسب هذا مع سير عملك في Apidog؟

لا تحتاج إلى أداة خاصة لاختبار ادعاءات البائع. تحتاج إلى طريقة لإرسال الطلب نفسه إلى عدة نقاط نهاية، ثم مقارنة الاستجابات والمقاييس جنبًا إلى جنب.

يمكنك استخدام Apidog لتسجيل نقطة نهاية Fugu كواجهة API متوافقة مع OpenAI، ثم حفظ مطالبات التقييم كطلبات قابلة لإعادة التشغيل.

سير عمل عملي:

1. أنشئ بيئة لفحص النماذج.
2. أضف متغيرات مثل:
   • FUGU_BASE_URL
   • FUGU_API_KEY
   • FUGU_MODEL
3. أنشئ طلب Chat Completions متوافقًا مع OpenAI.
4. انسخ الطلب للنماذج الأخرى التي تريد مقارنتها.
5. استخدم نفس جسم الطلب لكل نموذج.
6. شغّل السيناريو وسجل:
   • الاستجابة
   • رمز الحالة
   • زمن الاستجابة
   • استخدام الرموز إن كان متاحًا
   • الأخطاء

بهذه الطريقة يمكنك مقارنة Fugu وFable 5 وOpus أو أي نقطة نهاية أخرى باستخدام مدخلات متطابقة. هذه نتيجة أكثر فائدة من ادعاء تكافؤ عام بدون منهجية منشورة.

الأسئلة المتكررة

هل يتفوق Fugu على Fable 5 في المعايير؟

لا. Sakana لم تدّعِ ذلك. الادعاء هو التكافؤ: Fugu Ultra "يقف كتفًا بكتف مع" Fable 5 وMythos Preview، وفقًا لـ Sakana. ادعاء "يتفوق باستمرار" يستهدف Gemini 3.1 Pro وOpus 4.8 وGPT 5.5 في تطبيقات محددة، وليس Fable 5. للجانب الخاص بالنموذج الواحد، راجع معايير Claude Fable 5.

هل أرقام معايير Fugu تم التحقق منها مستقلًا؟

لا. اعتبارًا من 22 يونيو 2026، كل رقم هو تقرير من البائع، وتم قياسه على إعدادات Sakana الخاصة. لم يُعد أي طرف ثالث تشغيل المهام، ولم تُنشر أداة تقييم. تعامل مع الأرقام كادعاءات حتى يتم إعادة إنتاجها خارج Sakana.

لماذا يهم أن يكون Fugu منسقًا؟

لأن Fugu يستدعي نماذج متطورة من بائعين آخرين، وقد يستدعي نفسه بشكل متكرر. لذلك، نتيجة مثل "يهزم Opus 4.8" قد تكون ناتجة عن استدعاء Opus مع نماذج أخرى وتجميع المخرجات. هذا انتصار لنظام تنسيق، وليس انتصارًا لنموذج واحد. Fable 5 وسلسلة Mythos نماذج Anthropic مفردة، لذا المقارنة المباشرة تحتاج حذرًا.

أي إصدار من Mythos قارنته Sakana؟

Sakana تشير إلى Mythos Preview الأقدم من أبريل، وليس Mythos 5 الحالي. بعض المقالات الثانوية تخلط بينهما. شرح فئة Mythos يغطي الفرق بين Preview والنسخة المشحونة.

ما الفرق بين Trinity وConductor؟

Trinity (arXiv:2512.04695) هو منسق بأقل من 20,000 معلمة تم تحسينه بالتطور الخالي من المشتقات. Conductor (arXiv:2512.04388) هو نموذج 7B تم تدريبه بالتعلم المعزز لتعلم بنية الاتصال بين الوكلاء. هما ورقتان مختلفتان، ولا تمثل أي منهما بالضرورة مواصفات المنتج المشحون باسم Fugu.

كيف يمكنني اختبار أداء Fugu بنفسي؟

وجّه عميلًا متوافقًا مع OpenAI إلى عنوان URL الأساسي من console.sakana.ai، ثم أرسل مهامك الحقيقية وقِس الجودة وزمن الاستجابة والتكلفة. يمكنك تسجيل نقطة النهاية في Apidog ومقارنتها بالنماذج الفردية التي تستخدمها بالفعل باستخدام مطالبات متطابقة ومقاييس مسجلة.