حان وقت سلاسل اتصال llm://
بسّط إعدادات النماذج وموفّري الخدمات باستخدام عناوين URL من نوع llm://
تحديث: قاد هذا المقال إلى مسودة إنترنت لمخطط URI
llm://وإلى حزمة npm مساندة هيllm-strings. كما أن التنفيذ متاح على GitHub.
هل تتذكرون الأيام السيئة القديمة، حين كان الاتصال بقاعدة بيانات يعني التعامل مع خليط عشوائي من متغيرات البيئة؟
كان الأمر برجًا من إعدادات هشة. 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://. والمضيف هو عنوان URL الأساسي لواجهة API الخاصة بالمزود. والمسار هو اسم النموذج. أما معاملات الاستعلام فتتولى جميع خيارات التشغيل التي كانت عادةً تزدحم بها شيفرتك.
هل تحتاج إلى المصادقة؟ رائع، أضفها.
كما هي الحال مع postgres://، يمكننا تضمين بيانات المصادقة مباشرةً:
llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7
ملاحظة: نعم، قد يشكل وضع بيانات الاعتماد في عناوين URL خطرًا أمنيًا إذا كنت تلصقها في سجلات عامة. لكن خدمات التسجيل الحديثة جيدة إلى حد كبير في تنقيح هذه الأنماط، وبصراحة، هل تتعامل مع ملف .env لديك بعناية أكبر؟ تحقّق ونقِّ البيانات واستخدمها بحذر.
المرونة؟ ولمَ لا بحق الجحيم.
تدعم العديد من مكتبات قواعد البيانات تجاوز الأعطال بالتناوب عبر تحديد مضيفين متعددين. فلماذا لا تحصل وكلاؤنا للذكاء الاصطناعي على الموثوقية نفسها؟
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
وبغض النظر عن الصياغة الدقيقة، فإن الفوائد الأساسية لا جدال فيها:
- قابلية النقل: انسخ إعدادك الكامل والصقه، من برنامج نصي محلي إلى عامل سحابي.
- ملاءمة واجهة سطر الأوامر: مرّر وسيطًا واحدًا إلى برامجك النصية. فالأمر
my-agent --model "llm://..."أفضل منmy-agent --model gpt-4 --temp 0.7 --key $KEY --host .... - استقلال اللغة: تمتلك كل لغة برمجة محللًا متينًا لعناوين URL. ونحصل على التحقق والتحليل والتنقية مجانًا.
استغرق عالم قواعد البيانات عقودًا حتى يكتشف هذا.
والخبر الجيد هو أنه، وفقًا للجداول الزمنية للذكاء الاصطناعي، لم يمضِ على ذلك سوى نحو نصف سنة-إحساس.
الحكم النهائي
لسنا بحاجة إلى معيار إعداد معقد آخر أو ملف بيان جديد قائم على YAML. نحتاج فقط إلى استخدام الأداة التي أثبتت نجاحها مع بقية الإنترنت طوال الثلاثين عامًا الماضية.
فلنتوقف عن إعادة اختراع العجلة، ولنبدأ في التعامل مع اتصالات LLM بالاحترام نفسه الذي نمنحه لقواعد بياناتنا. سيشكرك ملف .env (وعقلك) على ذلك.
