شغّل STORM من جامعة ستانفورد على نقطة نهاية مخصصة متوافقة مع OpenAI.

Updated 2026-07-29

يبني STORM كل نموذج لغة كـ LitellmModel، ويقبل litellm معامل api_base. ضع https://api.apisrouter.com/v1 في openai_kwargs المشتركة الخاصة بك، أضف بادئة openai/ لمعرّفات النماذج، وتتوجّه فتحات LM الخمس لأنبوب المقال كلها عبر نقطة نهاية واحدة ومفتاح واحد.

إجابة سريعة: api_base في openai_kwargs، بادئة openai/ على المعرّفات.

يخزّن LitellmModel الخاص بـ STORM أياً كانت الوسائط التي تُنشئه بها ويدمجها في كل استدعاء litellm.completion(). معامل api_base في litellm هو كيفية توجيه مزوّد openai نحو مضيف مختلف، لذا إضافة api_base إلى قاموس openai_kwargs الذي تستخدمه أمثلة STORM نفسها بالفعل هو التجاوز بأكمله. أضف بادئة openai/ لكل معرّف نموذج حتى يتحدث litellm بروتوكول chat-completions إلى ذلك الـ base، والسلسلة بعد الشرطة المائلة تُمرَّر إلى البوابة. لأن الأمثلة تبني قاموس openai_kwargs واحداً وتعيد استخدامه لكل نموذج، مفتاح واحد مُضاف يُعيد توجيه الأنبوب بأكمله. لا تغييرات في كود STORM، لا تفريعة؛ هذا سلوك knowledge_storm الأصلي مبني فوق توجيه litellm الموثَّق.

openai_kwargs = {
    "api_key": os.getenv("APISROUTER_API_KEY"),
    "api_base": "https://api.apisrouter.com/v1",
    "temperature": 1.0,
    "top_p": 0.9,
}
fast = LitellmModel(model="openai/deepseek-v4-flash", max_tokens=500, **openai_kwargs)
strong = LitellmModel(model="openai/claude-sonnet-4-6", max_tokens=3000, **openai_kwargs)

كيف يقسّم STORM مقالاً عبر خمس فتحات LM.

يكتب STORM (stanford-oval على GitHub، بنحو 30 ألف نجمة) تقارير بطراز ويكيبيديا من الصفر: يبحث في موضوع عبر محادثات مُحاكاة متعددة المنظورات، يبني مخططاً مما تعلّمه، يُولِّد المقال الكامل قسماً تلو قسم، ثم يصقله. يكشف STORMWikiLMConfigs ذلك الأنبوب كخمسة نماذج قابلة للضبط بشكل مستقل: يقود conv_simulator_lm وquestion_asker_lm محادثات البحث، ويُهيكِل outline_gen_lm المقال، ويكتبه article_gen_lm، ويقوم article_polish_lm بالتمريرة النهائية. ملف README الأصلي صريح بشأن الاقتصاديات: يعمل محاكي المحادثة بأعلى حجم استدعاء، لذا يوصي بنموذج أسرع هناك ونموذج أقوى لتوليد المقال. افترضت تلك الإرشادات الاختيار بين نماذج OpenAI؛ خلف نقطة نهاية متعددة البائعين تعمم إلى شيء أكثر فائدة. كل فتحة هي LitellmModel خاص بها بسلسلة نموذج خاصة بها، لذا يمكن لثرثرة البحث العمل على معرّف DeepSeek سريع بينما يعمل توليد المخطط والمقال على Claude، والصقل على أي نموذج تثق به للنبرة، كلها مُصادَقة بنفس المفتاح مقابل نفس api_base. جانب الاسترجاع آلية منفصلة: يأخذ مُشغِّل STORM وحدة RM (You.com وBing وعدة خلفيات بحث أخرى مدعومة) بمفتاح API خاص بها. تغيير أين تشير نماذج اللغة لا يلمس كيفية جلب المصادر.

الإعداد الكامل: خمس فتحات، قاموس وسائط واحد.

النمط العامل يعكس نصوص التشغيل الخاصة بالمستودع نفسه: ابنِ الوسائط المشتركة مرة، أنشئ LitellmModel واحداً لكل دور، وأسنِدها عبر ضوابط STORMWikiLMConfigs. يمكن أن يكون api_key بأي اسم تريده لأنك تمرره صراحة؛ يستخدم المثال متغيّره الخاص ليوضّح أن هذا ليس بيان اعتماد حساب OpenAI. يحترم litellm أيضاً متغيرات بيئة على مستوى المزوّد، ويقرأ مزوّد openai متغيّر OPENAI_API_BASE، لذا تجاوز عبر البيئة فقط ممكن. مسار الوسائط الصريح لا يزال المُفضَّل: مرئي في الكود الذي أنتج مقالاً معيّناً، ينجو من التشغيل على جهاز بحالة بيئة مختلفة، ويجعل استثناءات لكل فتحة ممكنة إن أردت يوماً وضع مرحلة واحدة على نقطة نهاية مختلفة.

import os
from knowledge_storm import STORMWikiRunnerArguments, STORMWikiRunner, STORMWikiLMConfigs
from knowledge_storm.lm import LitellmModel
from knowledge_storm.rm import YouRM

openai_kwargs = {
    "api_key": os.getenv("APISROUTER_API_KEY"),
    "api_base": "https://api.apisrouter.com/v1",
    "temperature": 1.0,
    "top_p": 0.9,
}
fast = LitellmModel(model="openai/deepseek-v4-flash", max_tokens=500, **openai_kwargs)
strong = LitellmModel(model="openai/claude-sonnet-4-6", max_tokens=3000, **openai_kwargs)

lm_configs = STORMWikiLMConfigs()
lm_configs.set_conv_simulator_lm(fast)
lm_configs.set_question_asker_lm(fast)
lm_configs.set_outline_gen_lm(strong)
lm_configs.set_article_gen_lm(strong)
lm_configs.set_article_polish_lm(strong)

engine_args = STORMWikiRunnerArguments(output_dir="./results")
rm = YouRM(ydc_api_key=os.getenv("YDC_API_KEY"), k=engine_args.search_top_k)
runner = STORMWikiRunner(engine_args, lm_configs, rm)
runner.run(topic="Small modular reactors")

اختيار النماذج لكل مرحلة أنبوب.

عامل الضوابط الخمسة كمِفتاح ميزانية، لا كنص متكرر. إرشادات upstream تقول بالفعل بتقسيم النماذج السريعة والقوية عبر المراحل؛ نقطة نهاية متعددة البائعين توسّع فقط القائمة لكل مرحلة. غيّر فتحة واحدة في كل مرة بين التشغيلات على نفس الموضوع وقارن المُخرَجات بالاختلاف، مع تسعير سجل الاستخدام لكل مفتاح لكل إعداد.

  • conv_simulator_lm وquestion_asker_lm هما مرحلتا الحجم: مقابلات مُحاكاة متعددة الأدوار عبر عدة منظورات لكل موضوع. deepseek-v4-flash أو معرّف سريع آخر يُبقي مرحلة البحث من الهيمنة على الإنفاق، والثرثرة غير المثالية مقبولة لأنها تُطعِم ملاحظات، لا نثراً.
  • article_gen_lm هي الفتحة الرائدة. تكتب أقساماً طويلة ومُهيكَلة ومُستشهَداً بها من البحث المتراكم، وهو عمل توليد مستدام حيث يتفوّق claude-sonnet-4-6 أو gpt-5.5 بوضوح على معرّفات أصغر.
  • outline_gen_lm استدعاءات قليلة برافعة غير متناسبة، بنفس شكل فتحة تخطيط: مخطط ضعيف يحدّ المقال بغض النظر عن جودة الكاتب. هو المكان الطبيعي لاختبار claude-opus-4-7.
  • article_polish_lm يُعيد الكتابة من أجل الانسيابية ويُزيل التكرار عبر المقال المُجمَّع، وهو ما يستفيد من معرّف طويل السياق؛ gemini-3.1-pro-preview يستحق القياس هنا.

ادفع حسب الاستخدام · أقل من السعر الرسمي

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

النموذجالسعر الرسميسعرنا
DeepSeek V4 Flash$0.14 / $0.28 per M$0.10 / $0.30 per M
Claude Sonnet 4.6$3.00 / $15.00 per M$2.40 / $12.00 per M
Claude Opus 4.7$5.00 / $25.00 per M$4.00 / $20.00 per M
GPT-5.5$5.00 / $30.00 per M$4.00 / $24.00 per M
Gemini 3.1 Pro Preview$2.00 / $12.00 per M$1.60 / $9.60 per M

أنماط الفشل الخاصة بـ STORM.

معرّف نموذج عارٍ يتوجّه بالاستدلال، لا عبر api_base الخاص بك. يقرأ litellm البادئة لاختيار مزوّد، ومعرّف Claude بدون بادئة يُستنتَج كاستدعاء أصيل لـ Anthropic، الذي يريد حينها ANTHROPIC_API_KEY ويتجاهل بوابتك تماماً. كل معرّف مُتَّجِه إلى البوابة يجب أن يحمل بادئة openai/؛ البادئة تُسمّي البروتوكول، لا البائع. فتحة واحدة تُركَت متأخرة. يلتقط كل LitellmModel وسائطه عند الإنشاء. إذا شاركت أربع فتحات openai_kwargs وبُنيت خامسة بشكل مرتجل بدون api_base، تلك الفتحة تُرسِل بصمت إلى افتراضي البائع وتفشل بخطأ مصادقة، ويُسمّي الأثر مرحلة الأنبوب لا سطر الإعداد. ابنِ كل فتحة من نفس القاموس ويختفي هذا الصنف من الأخطاء. أعطال أداة الاسترجاع تُلام على نقطة النهاية. تحتاج مرحلة البحث خلفية بحث تعمل؛ مفتاح استرجاع غير صالح أو مُستنفَد (YDC_API_KEY، BING_SEARCH_API_KEY، أو أياً كانت وحدة RM التي اخترتها) يُفشِل التشغيلات أثناء جمع المعلومات. تلك المرحلة تتداخل مع استدعاءات LM، لذا اقرأ الأثر لمعرفة أي عميل رفع الخطأ قبل لمس إعداد LM. ملف secrets.toml الخاص بالعرض التجريبي ليس إعداد نصك البرمجي. يقرأ عرض Streamlit التجريبي secrets.toml؛ التشغيلات البرمجية تقرأ أياً كان ما يمرره نصك. تعديل أحدهما أثناء تشغيل الآخر تعارض كلاسيكي. max_tokens أيضاً لكل فتحة. تضبط أمثلة STORM حدوداً صغيرة على الفتحات السريعة (500) وأكبر على التوليد (3000). توجيه فتحة نحو نموذج طويل الشكل دون رفع max_tokens الخاص بها يُقتَطع بصمت الأقسام، وهو ما يبدو كمشكلة جودة نموذج لكنه رقم إعداد.

من يوجّه STORM عبر بوابة.

  • الفرق التي تُولِّد تقارير معرفة بحجم (موجزات، مستندات داخلية بطراز ويكي، مقدّمات موضوعية)، حيث يجعل تقسيم الفتحات الخمس ضبط التكلفة لكل مرحلة يستحق مالاً حقيقياً.
  • الباحثون الذين يدرسون تركيب الأنابيب: أي مرحلة تستفيد من نموذج أقوى سؤال تجريبي، ونقطة نهاية واحدة تجعل شبكة تركيبات الفتحة والنموذج تافهة السرد.
  • المُنشِئون الذين يشغّلون Claude أو Gemini في فتحات الكتابة لمكدس على شكل OpenAI، دون إضافة SDK بائع لكل عائلة نماذج.
  • أي شخص يشغّل قوائم مواضيع دُفعية، حيث يُضاعِف حجم مرحلة البحث عبر المواضيع ويصبح سجل الاستخدام دفتر التكلفة لكل موضوع.
  • المطورون الذين لا يملكون وصولاً إلى فوترة بائع معيّن. الوصول القائم على تعبئة الرصيد بدون شرط بطاقة يزيل الاعتماد على التسجيل لكل مزوّد.

تحقق من نقطة النهاية وصحّح أخطاء أول مقال.

اسرد نماذج البوابة أولاً: يجب أن تطابق السلسلة بعد openai/ في كل فتحة معرّفاً مخدوماً تماماً. تتبع أعطال أول تشغيل ترتيب الأنبوب. خطأ مصادقة يُسمّي Anthropic أو Google يعني أن معرّفاً بدون بادئة تُوجِّه نحو مزوّد أصيل؛ أضف openai/. 401 من البوابة يعني أن api_key في وسائطك ليس مفتاح البوابة. خطأ model-not-found يُسمّي الفتحة التي بها خطأ إملائي في معرّفها. أعطال أثناء مرحلة البحث تذكر خلفية البحث الخاصة بك هي بيانات اعتماد الاسترجاع، لا توجيه LM. وأقسام مقال مقتطَعة أو قصيرة بشكل غريب عادة max_tokens شحيحة على فتحة التوليد أكثر من أي شيء أعلى في التسلسل. تشغيل STORM الكامل انفجار كبير: محادثات مُحاكاة عبر منظورات، ثم مخطط وتوليد وصقل. بمجرد اكتمال واحد، تعرض لوحة APIsRouter النموذج لكل طلب، وعدد tokens، والإنفاق، وهو ما يُخطَّط بنظافة إلى الفتحات الخمس ويخبرك بالضبط أي مرحلة يجب إعادة ضبطها قبل دفعة المواضيع التالية.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

الأسئلة الشائعة

كيف يدعم STORM نقطة نهاية مخصصة متوافقة مع OpenAI؟

عبر litellm. يبني STORM كل نموذج لغة كـ LitellmModel، الذي يدمج وسائط منشئه في كل استدعاء litellm.completion()، ويقبل litellm معامل api_base لمزوّد openai. أضف api_base إلى قاموس openai_kwargs وكل فتحة مبنية منه تتوجّه إلى البوابة.

لماذا تحتاج معرّفات النماذج بادئة openai/؟

يختار litellm المزوّد من البادئة. openai/claude-sonnet-4-6 تعني "تحدّث ببروتوكول chat-completions الخاص بـ OpenAI إلى api_base الخاص بي مع نموذج claude-sonnet-4-6". بدون البادئة، يستنتج litellm البائع من الاسم ويتوجّه أصيلاً، متجاوزاً نقطة نهايتك.

هل يمكن لمراحل STORM المختلفة استخدام نماذج بائعين مختلفين؟

نعم. كل فتحة من الخمس هي LitellmModel مستقل، لذا يمكن لمحاكي المحادثة تشغيل معرّف DeepSeek بينما يشغّل توليد المقال Claude والصقل GPT، كلها عبر نفس api_base ونفس المفتاح. توصي upstream بالفعل بتقسيم النماذج السريعة والقوية عبر المراحل.

هل يتغيّر أداة الاسترجاع للبحث عند تغيير api_base؟

لا. يعمل الاسترجاع عبر وحدة RM التي تمررها إلى STORMWikiRunner (You.com وBing وخلفيات أخرى مدعومة) بمفتاحها الخاص. توجيه LM واسترجاع المصدر نظامان مستقلان يفشلان في مراحل مختلفة من التشغيل.

هل يوجد مسار متغيّر بيئة بدلاً من الوسائط؟

يحترم litellm متغيرات على مستوى المزوّد، ويقرأ مزوّد openai متغيّر OPENAI_API_BASE. يعمل، لكن وسيط api_base الصريح أكثر قابلية لإعادة الإنتاج: يسافر مع النص البرمجي، ينجو من أجهزة بحالة بيئة مختلفة، ويسمح باستثناءات لكل فتحة.

كم tokens يستهلك مقال STORM واحد؟

مرحلة البحث تهيمن: محادثات مُحاكاة متعددة المنظورات تُضاعِف الاستدعاءات قبل وجود كلمة واحدة من المقال، ثم يضيف التوليد والصقل مُخرَجاً طويل الشكل فوق ذلك. التشغيلات الكاملة تحطّ عادة في مئات الآلاف من tokens، ويُظهِر عرض الاستخدام لكل مفتاح التقسيم الدقيق لكل مرحلة.