حان الوقت لسلاسل اتصال llm://

تبسيط تكوين النموذج والمزود باستخدام عناوين llm:// URLs

تحديث: أدى هذا المقال إلى إنشاء مسودة إنترنت لمخطط URI llm://.

هل تذكرون الأيام السيئة عندما كان الاتصال بقاعدة البيانات يعني التعامل مع مجموعة عشوائية من متغيّرات البيئة؟

كان ذلك برجًا من الإعدادات الهشة. DB_HOST، DB_PORT، DB_USER، DB_PASSWORD، DB_NAME… أو انتظر، هل هو DB_USERNAME؟ هل هو DB_PASS أم DB_PWD؟ هل أحتاج إلى بادئات PG_* هذه المرة؟ وأين يذهب إعداد مهلة الاتصال؟

كان ذلك بيتًا من الورق الهش، جاهزًا لأن ينهار بناء الإنتاج لأنك نسيت كتابة HOST بحرف كبير.

ثم جاء أحدهم بالفكرة العبقرية لاستخدام URL¹ فقط:

postgres://user:pass@host:5432/dbname

سلسلة واحدة. كل ما تحتاجه. قابلة للتحليل عالميًا. محمولة. هل أجرؤ على القول… جميل؟

إذن لماذا نتعامل مع نماذج LLM كما لو كان العام 1999؟

انفجار متغيّرات البيئة

حاليًا، يبدو ملف .env الخاص بي كقبر لمفاتيح API المهجورة. OPENAI_API_KEY، ANTHROPIC_API_KEY، MISTRAL_API_KEY، GROQ_API_KEY. ولا تجعلوني أبدأ بالحديث عن Azure—تحتاج إلى نقطة نهاية، اسم نشر، نسخة API، ومفتاح فقط لتقول “مرحبًا”.

الأمر ليس قبيحًا فحسب؛ إنه احتكاك. في كل مرة أرغب فيها بتبديل نموذج أو اختبار مزود جديد، أُعيد كتابة كود التهيئة، أبحث في الوثائق عن أسماء المعاملات المحددة، وأضيف ثلاثة أسطر أخرى إلى إعدادات البيئة.

ماذا لو فقط… سرقنا استعارنا فكرة URL لقاعدة البيانات؟

تقديم سلاسل اتصال LLM

تخيل تكوين واجهة النموذج بالكامل بسطر واحد:

llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500
llm://api.z.ai/glm-4.7?top_p=0.9&cache=true

تشريح سلسلة اتصال LLM

المخطط هو llm://. المضيف هو عنوان قاعدة API للمزود. المسار هو اسم النموذج. ومعاملات الاستعلام تتعامل مع جميع خيارات وقت التشغيل التي عادةً ما تملأ كودك.

تحتاج مصادقة؟ ممتاز، أضفها.

مثلما يحدث مع postgres://، يمكننا دمج المصادقة مباشرةً:

llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7

ملاحظة: نعم، وضع الاعتمادات في عناوين URL قد يشكل خطرًا أمنيًا إذا قمت بلصقها في سجلات عامة. لكن خدمات التسجيل الحديثة جيدة إلى حد كبير في تنقية هذه الأنماط، وبصراحة، هل تتعامل مع ملف .env الخاص بك بشكل أفضل؟ تحقق، نظّف، واستخدم بحذر.

المرونة؟ لماذا لا.

العديد من مكتبات قواعد البيانات تدعم الفشل المتناوب (round‑robin) عبر تحديد عدة مضيفين. لماذا لا يحصل وكلاؤنا الذكائيون على نفس الاعتمادية؟

llms://primary.gpt,backup.gpt/gpt-6?temp=0.9

الحرف s في llms:// ليس خطأ مطبعي. إنه جمع. إذا تعطل primary.gpt، يعيد العميل تلقائيًا محاولة الاتصال بـ backup.gpt. لا حاجة لمنطق موجه معقّد.

سلسلة واحدة تحتوي على كل شيء من المصادقة إلى نقطة النهاية إلى معاملات الضبط.

صيغ بديلة

لست ملزمًا بـ llm://. تفاصيل المخطط أقل أهمية من المعيار نفسه.

يمكنني تخيّل عالم نستخدم فيه مخططات خاصة بالمزود لتقليل الكتابة، مع الحفاظ على بنية المعيار:

ollama://localhost:11434/llama3
vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}
bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral

بغض النظر عن الصياغة الدقيقة، الفوائد الأساسية لا يمكن إنكارها:

1. قابلية النقل: انسخ والصق تكوينك بالكامل من سكريبت محلي إلى عامل سحابي.
2. ملاءمة سطر الأوامر: مرّر حجة واحدة إلى سكريبتاتك. my-agent --model "llm://..." يتفوق على my-agent --model gpt-4 --temp 0.7 --key $KEY --host ....
3. محايدة اللغة: كل لغة برمجة تمتلك محلل URL قوي. نحصل على التحقق، التحليل، والتنقية مجانًا.

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

الحكم النهائي

لا نحتاج إلى معيار تكوين معقّد آخر أو ملف بيان مبني على YAML جديد. كل ما نحتاجه هو استخدام الأداة الوحيدة التي تعمل لبقية الإنترنت منذ ثلاثين سنة.

دعونا نتوقف عن اختراع العجلة من جديد ونعامل اتصالات LLM بنفس الاحترام الذي نمنحه لقواعد البيانات. ملف .env الخاص بك (وعقلك) سيشكرانك.