Lovable تقلّل حالات الجمود بنسبة 5% بفضل ملفات المعرفة وتقنية RAG

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

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

أولًا: تضييق المهمة

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

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

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

التعليمات أثبتت فائدة أكبر من نموذج مضبوط مبكرًا

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

قبل كل عملية توليد جديدة كان البحث ينتقي القواعد المناسبة ويضيفها إلى سياق النموذج. وهذا في جوهره المزيج المألوف اليوم بين قاعدة تعليمات وRAG. وهكذا بدأ كل خلل جرى تحليله يساعد المستخدمين التاليين دون دورة تدريب جديدة. ووفق بيانات Lovable نفسها، خفّضت النسخة الأولى من نظام البحث عن المشكلات وحلولها نسبة المستخدمين العالقين أثناء العمل بنسبة 5%. وهذا مقياس داخلي للشركة، لذا لا يجوز اعتباره نتيجة عامة.

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

السرعة تعتمد على الفحص، لا على النموذج وحده

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

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