النموذج السريع يكتب الشيفرة والنموذج الذكي يصلح المنطق: كيف تبني بحثاً باستخدام n8n وPostgreSQL

يُكتب الكثير عن النماذج الرائدة، لكن قلّما يُكتب عن كيفية توزيع الأدوار بين نموذج سريع ونموذج «يفكّر» في مهمة حقيقية. أخذ مؤلف هذا التحليل مشروعاً عملياً واختبر هذا النهج في الممارسة.

المهمة، ولماذا لا نموذج لغوي أثناء التشغيل

كانت الحاجة إلى بحث في كتالوج لمشغولات حجرية من تصميم المؤلف. على صفحة Tilda مغلقة، يحدد الأخصائي المجالات (الحب، المال، الصحة وغيرها) ويختار التصميم: نسائي أو رجالي أو للجنسين. وفي المقابل يحصل على ما يصل إلى خمس بطاقات من جدول PostgreSQL يضم 1684 سجلاً.

رفض المؤلف إغراء وضع نموذج «يفهم الطلب» بين النموذج وقاعدة البيانات، لثلاثة أسباب. الأول زمن الاستجابة: لا حاجة إلى استدعاء شبكي من أجل بحث في 1684 صفاً. الثاني التكلفة وتفاوت النتائج: قواعد البحث يمكن كتابتها صراحة. الثالث مصدر الحقيقة: لا يُرجع SQL إلا ما هو موجود في الكتالوج، بينما قد يضيف النموذج خاصية معقولة المظهر لكنها مختلقة. لذلك تعمل النماذج اللغوية في مرحلة التطوير فقط.

الأدوار كالتالي. كان Particle-1 في Cline «اليدين»: يكتب SQL وشيفرة عُقد n8n، ويصلح علامات الاقتباس وأسماء الحقول. وكان GPT-6 Luna Pro «العقل»: يُستدعى عندما لا تعود المشكلة في الصياغة بل في التشخيص. أما التشغيل والتحقق من استجابة HTTP والقرارات المتعلقة بالمنتج فاحتفظ بها المؤلف لنفسه.

ثمة تحفّظ مهم: هذا ليس اختبار A/B. فالجلسات مختلفة في الحجم، ولذلك لا يصح مقارنة 0.49 دولار مقابل 0.04 دولار على أنهما سعر حل المهمة نفسها. كما أن بيانات OpenRouter عن زمن الاستجابة مجرد مؤشر في تاريخ محدد.

خمسة أفخاخ بالترتيب

1. العامل &. لحساب الوسوم المشتركة، استخدم النموذج & مع text[]، وهو غير موجود في PostgreSQL. العامل && يجيب فقط عن سؤال «هل يوجد تقاطع» ولا يعدّ. الحل: && في WHERE لاختيار المرشحين، واستعلام فرعي باستخدام unnest لحساب التطابقات.

2. Syntax error near undefined. كانت عقدة Code تُخرج الحقل sql_query، بينما كانت عقدة Postgres تقرأ اسماً آخر. ومع ذلك ظلت عقدة Code خضراء. الخلاصة: قارنوا OUTPUT الفعلي للعقدة السابقة بـ INPUT للعقدة التالية، لا التعبير الجميل في المعاملات.

3. القيمة الحرفية للمصفوفة. يلزم مستويان من علامات الاقتباس: مزدوجة في الداخل للعناصر، ومفردة في الخارج لسلسلة SQL. فقد النموذج الطبقة الخارجية. لم ينجح المؤلف في تمرير المصفوفة كمعامل عبر $1، لكنه لا يزعم أن n8n عاجز عن ذلك. وفي إنتاج جديد كان سيسعى أولاً إلى استعلام مُعَلْمَن.

4. خمسة صفوف في SQL وبطاقة واحدة في الموقع. وفق التوثيق، تُنفَّذ Respond to Webhook مرة واحدة على أول عنصر. ويساعد وضع All Incoming Items. وزاد التشخيص إرباكاً أن سجلاً عاماً واسعاً بثمانية وسوم كان يظهر في الأعلى، فبدا أن SQL يُرجع الشيء نفسه دائماً.

5. الجنس النسائي: سجل واحد من 1684. المرشّح سليم، لكن البيانات منحرفة: فكل شيء تقريباً صُنّف ضمن unisex. لم يعدّل المؤلف الخوارزمية، بل ثبّت قاعدة منتج: الطلب النسائي يقبل female وunisex، وعند التساوي يتقدّم التطابق التام في الجنس. أما تحديد ما إذا كان ذلك خطأ في الاستيراد فلم يكن بوسع النموذج.

الثغرة التي لم تلحظها النماذج

في المراجعة النهائية لم يسأل المؤلف «لماذا يتعطل»، بل «ماذا سيحدث إذا تجاوزنا النموذج». كان يجري تهريب الشرطة المائلة العكسية وعلامة الاقتباس المزدوجة، لكن ليس المفردة، مع أن القيمة الحرفية كانت محاطة بعلامات اقتباس مفردة تحديداً. عبر curl كان بالإمكان كسر السلسلة وتغيير الاستعلام. وكلمة المرور على صفحة Tilda تحمي HTML فقط، لا الطلبات المتجهة إلى n8n. ومفتاح API في JavaScript من جهة العميل لن يغيّر شيئاً أيضاً. جرى الإصلاح على الخادم: قائمة بيضاء لقيم spheres وgender، مع تهريب صحيح للمستويين معاً.

ما الذي نستخلصه

ينجح الفصل بين «منفّذ سريع ومشخّص بطيء» إذا كنتم أنتم من يحدد لحظة التبديل: خطأ في الصياغة أم في سلوك النظام. اللون الأخضر لعقدة ما لا يثبت اتساق المسار كله. والترتيب حسب cardinality(tags) لا يمنع سجلاً واسعاً من الفوز. كما أن قائمة المجالات الفارغة تعطّل المرشّح بصمت، وفي واجهة API عامة من الأفضل إرجاع 400. تبقى مراجعة الأمان عملاً بشرياً: ففي هذه الحالة لم ينبّه أي من النموذجين إلى الحقن.