فريق AI Sous-chef يطلق تطبيقًا وبوتًا بذكاء اصطناعي سحابي خلال شهرين ونصف

تلقى التطبيق قائمة منتجات، وأعاد وصفة بالصيغة المطلوبة، وعرض على المستخدم سلطة من بطاطس نيئة وباذنجان. كانت مرحلة طهي هذه المكونات غائبة عن التعليمات. وبحسب فريق AI Sous-chef، هذا هو بالضبط الرد الذي وصل بعد الإطلاق. بالنسبة للمطور، المشكلة مألوفة: يجتاز رد النموذج الفحوص التقنية بنجاح، لكن المستخدم يحصل على نتيجة سيئة.

في تحليل نُشر على Habr، يعرض الفريق كيف بنى خلال شهرين ونصف تطبيق أندرويد وبوت تيليغرام بخلفية خادم مشتركة. وتكمن القيمة العملية للمادة في التفاصيل: كيف تُختار إصدارات الأوامر النصية، وما الذي يُفحص في الردود، ولماذا لا تكفي هذه الفحوص حتى الآن.

عميلان وخلفية مشتركة وأوامر نصية في ملفات

السيناريو بسيط: يصوّر الشخص المنتجات أو يكتبها نصًا، ثم يؤكد القائمة التي تم التعرف عليها ويحصل على خيارات أطباق. يعمل تطبيق الجوال المبني على React Native والبوت على خادم مشترك بلغة Python وFastAPI. وقد قُسّم التعرف على المنتجات وتوليد الوصفات بين نموذجين سحابيين؛ وتُرسل الطلبات إلى واجهة Yandex البرمجية (API).

تُخزَّن التعليمات بشكل منفصل عن الشيفرة: لكل مهمة ملف للنظام وملف للمستخدم. وتحدد pin.json الإصدارات المطلوبة. فمثلًا، يمكن إبقاء التعرف على المنتجات على الإصدار v1، واختيار إصدار آخر مُعدّ للوصفات. يقرأ المُحمِّل الملفات ويستبدل القيم في تعابير مثل {{ products }}. وإذا غاب ملف أو قيمة مطلوبة، يُصدر خطأ.

يتيح ذلك تعديل الصياغات دون إعادة كتابة دالة استدعاء النموذج. لكن ثمة تفصيلًا تشغيليًا: يُخزَّن مؤشر الإصدارات في ذاكرة العملية. وبعد تغيير pin.json يلزم إعادة التشغيل أو مسح الذاكرة المؤقتة. أما نصوص التعليمات فتُقرأ من جديد عند كل استدعاء للمُحمِّل.

وهناك حد أهم. فبحسب وصف المؤلفين، تُدرج قائمة المنتجات في تعليمة النظام أيضًا. أي أن الملفات المنفصلة وحدها لا تفصل بيانات المستخدم عن قواعد سلوك النموذج. ولا يزال يلزم اختبار الاستجابة للتوجيهات الدخيلة داخل النص المُدخل.

JSON يتحقق من البنية، أما الوصفة فتحتاج تقييمًا مختلفًا

عند توليد الوصفات، يطلب التطبيق JSON عبر معامل في واجهة API، ثم يحلل الرد عبر json.loads ويتحقق من البنية المتوقعة عبر model_validate. يساعد ذلك في اكتشاف رد لا تستطيع الشيفرة معالجته. لكن وجود الحقول المطلوبة لا يدل على اكتمال خطوات الطهي.

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

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

إضافة إلى ذلك، يحدّ استخدام latest في عناوين النماذج من قابلية إعادة الإنتاج. فقد يبقى إصدار الأمر النصي كما هو بينما يتحدّث النموذج خلف هذا العنوان. وللحصول على تشغيلات قابلة للمقارنة، ينبغي حفظ المُدخل والرد والإعدادات وأدق معرّف متاح للنموذج.

ما يفيد في منتجك الخاص

يوفر AI Sous-chef وضع AI_MODE=stub: بدل الطلبات السحابية، يتلقى التطبيق منتجات ووصفات مسجّلة مسبقًا. ومن المريح على هذه الردود اختبار الواجهة وتفاعل المكونات. أما جودة التوليد فلا يقيسها هذا الوضع، لأنه لا يوجد فيه توليد.

وبالنسبة لمدير المنتج، ثمة قيد آخر في الإصدار الأول له دلالته: كان بالإمكان تأكيد القائمة المُتعرَّف عليها، لكن لا يمكن تصحيحها. كان المستخدم يرى الخطأ ولا يستطيع حذف المكوّن الخاطئ قبل الخطوة التالية. وأصبح تحرير القائمة أحد التحسينات القريبة.

وبحسب المقال، نُشر المستودع الرئيسي برخصة GNU AGPL v3.0. ويمكن منه دراسة مُحمِّل الأوامر النصية، واختيار الإصدارات، والتحقق من الردود، واستبدال النماذج ببيانات جاهزة. وعند النقل سيلزم مراعاة بنى التطبيق المحدد والتخزين المؤقت.

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