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

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

تحديث: أدى هذا المقال إلى إصدار مسودة إنترنت لمخطط 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، ومفتاح فقط لتقول “مرحبًا”.

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

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

تقديم سلاسل اتصال 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 قوي. نحصل على التحقق، التحليل، والتنقية مجانًا.

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

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

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

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