LLM 0.37 يضيف تضمينات متعددة الوسائط ويدمج تصحيحات من 12 مساهما

تظهر المشكلة نفسها سريعا في أدوات سطر الأوامر المخصصة للعمل مع النماذج: كل مزود يتطلب إعدادا منفصلا، في حين أن البيانات لم تعد تقتصر على النصوص منذ وقت طويل. في LLM 0.37، عالج سايمون ويليسون الجانبين معا. يسهّل الإصدار ربط واجهات API المتوافقة مع OpenAI، ويتيح تمرير كائنات من أنواع مختلفة إلى نظام التضمينات، تشمل النصوص والصوت والصور والفيديو.

يعني ذلك عمليا الحاجة إلى قدر أقل من الشيفرة المتخصصة المحيطة بالنماذج. فإذا كان فريق ما يحتفظ بنصوص مفرغة للمكالمات وصور للمنتجات ومقاطع فيديو تدريبية، فلن يضطر بعد الآن إلى التظاهر بأن كل هذه المواد تنتمي إلى نوع المحتوى نفسه. يمكن منح كل كائن content type خاصا به، ثم يتولى نموذج متعدد الوسائط مناسب إنشاء تمثيله المتجهي.

واجهة واحدة لمزودين مختلفين

الأمر الجديد llm openai endpoint add مخصص للخدمات التي تحاكي تنسيق واجهة OpenAI API. في السابق، كان على المطور التعامل يدويا مع إعداد كل نموذج إضافي. أما الآن، فقد أصبح الربط متاحا عبر أمر CLI مستقل.

يبدو السيناريو البسيط كما يلي: يمتلك الفريق بوابة داخلية أو يستخدم مزودا خارجيا لديه واجهة API متوافقة مع OpenAI. يضيف المطور endpoint الخاص به، ويحدد نموذجا متاحا، ثم يستدعيه من خلال واجهة LLM المعتادة. وهذا ملائم خصوصا للنماذج الأولية والأدوات الداخلية التي تتطلب تبديل النماذج أو مقارنتها بانتظام.

أضاف الإصدار أيضا دعم gpt-6.1-sol وgpt-6.1-terra. وأصبح gpt-6-luna النموذج الافتراضي للمستخدمين الذين لم يختاروا نموذجا بأنفسهم. ووفقا لويليسون، تبلغ تكلفته نصف تكلفة النموذج الافتراضي السابق gpt-5.6-luna. ولا يغيّر هذا التحديث أي شيء في عمليات التثبيت الحالية التي حُدد فيها نموذج بصورة صريحة.

التضمينات لم تعد نصية فقط

يتمثل التغيير المعماري الأبرز في دعم أنواع مختلفة من المحتوى الثنائي عند إنشاء التضمينات. وهذا ضروري لنماذج مثل Gemini Embedding 2، القادرة على العمل ليس فقط مع النصوص، بل أيضا مع الصوت والصور والفيديو.

لنتخيل البحث في قاعدة بيانات للدعم الفني. يكتب المستخدم سؤالا نصيا، لكن الإجابة المناسبة قد تكون موجودة في دليل إرشادي أو لقطة شاشة للواجهة أو تسجيل لمحادثة أو مقطع من فيديو. تتيح التضمينات متعددة الوسائط وضع هذه المواد في مساحة بحث مشتركة. لا يبني LLM 0.37 بنفسه نظام بحث جاهزا، لكنه يزيل أحد العوائق المزعجة: لم تعد المكتبة تتطلب اعتبار جميع الكائنات الواردة متماثلة.

من المهم هنا التحقق من قدرات المزود المختار. فدعم المكتبة لتنسيق معين لا يعني أن أي نموذج متصل يمكنه معالجة أنواع البيانات الأربعة جميعها. كما تظل القيود المتعلقة بحجم الملفات والتكلفة والتنسيقات وجودة البحث مرتبطة بالنموذج المحدد.

طلبات السحب المنشأة بالذكاء الاصطناعي كتقارير أخطاء مفصلة

وصف ويليسون بصورة منفصلة تجربته مع المساهمات المدعومة بالذكاء الاصطناعي في مشروع مفتوح المصدر. تضمن الإصدار تصحيحات من 12 مساهما، وقد أُنشئ معظمها تقريبا بمساعدة الذكاء الاصطناعي. وبدلا من الثقة تلقائيا بالتصحيحات الجاهزة، استخدم المؤلف Opus 5.5 أو GPT-6 Astra لإجراء المراجعة الأولية للمقترحات.

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

الخلاصة العملية: يستحق LLM 0.37 تجربة الفرق التي تنتقل بين المزودين أو تبني أدوات بحث تعتمد على بيانات مختلطة. أما مالكو المستودعات المفتوحة، فيمكنهم الاستفادة من النهج التحريري نفسه: فصل قيمة المشكلة المكتشفة عن جودة التصحيح المنشأ بالذكاء الاصطناعي، والتحقق من كل منهما بصورة مستقلة.