ما هي أحدث طريقة (2026) للحصول على مخرجات JSON منظمة وموثوقة من نماذج اللغة المحلية في n8n؟
أستخدم نماذج محلية (عبر Ollama) في n8n وأحتاج إلى مخرجات JSON متسقة لأشياء مثل التوجيه وإنشاء SQL.
ما أفضل ممارسة حالية يستخدمها الناس في 2026؟
هل لا يزال الناس يعتمدون على:
أم أن هناك نهجًا أحدث وأكثر موثوقية؟
لن أجعل هذه مشكلة بطبقة واحدة.
بالنسبة لمسارات التوجيه أو سير العمل المتعلقة بقواعد البيانات، سأتعامل مع JSON كعقد واجهة:
بالنسبة لـ SQL تحديداً، سأتجنب السماح للنموذج بإنتاج SQL خام يتم تنفيذه مباشرة. النمط الأكثر أماناً هو أن ينتج النموذج النية المنظمة والمرشحات واختيارات الجداول/الحقول من قائمة مسموحة، ثم تعيين ذلك إلى قالب استعلام تتحكم فيه.
لذا فإن الجزء الموثوق به ليس فقط “هل يمكن للنموذج إخراج JSON؟” بل “ماذا يحدث عندما يكون JSON مفقوداً أو معطوباً أو صحيحاً لكن خاطئاً أو غير آمن؟”
سؤال جيد — لقد عملت على هذا مع Ollama و n8n كثيراً. إليك ما يعمل بشكل موثوق فعلاً في عام 2026:
**1. استخدم معامل `format: json` الأصلي في Ollama (الطبقة الأكثر موثوقية)**
عند تكوين عقدة Ollama Chat Model، أضف `format: json` في الحقول الإضافية / معاملات النموذج. هذا يجبر Ollama على تقييد أخذ العينات من الرموز إلى رموز JSON صالحة فقط — إنها ليست هندسة فوريات، بل هي مفروضة على مستوى النموذج. نماذج مثل `llama3` و `mistral` و `qwen2.5` تدعم هذا جيداً. هذا وحده يزيل حوالي ~80٪ من الإخراج غير المشكل بشكل صحيح.
**2. اقرنها مع محلل الإخراج المنظم في n8n**
أكدم Ollama format:json + محلل الإخراج المنظم (مع مخطط JSON). يخبر المخطط النموذج بالحقول التي تتوقعها؛ يتحقق المحلل من صحتها واستخراجها. إذا كنت تقوم بالتوجيه، قد يكون المخطط الخاص بك بسيطاً مثل `{ “route”: { “type”: “string”, “enum”: [“billing”, “support”, “sales”] } }`.
**3. عقدة Code كشبكة أمان لك**
بعد المحلل، أضف عقدة Code تفعل:
```js
const out = $input.first().json;
if (!out.route || ![‘billing’,‘support’,‘sales’].includes(out.route)) {
throw new Error('Invalid route: ’ + JSON.stringify(out));
}
return [{ json: out }];
```
هذا يحمي العقد التالعة بحيث لا توجهها أبداً بشكل خاطئ بصمت.
**4. بشكل خاص لنية SQL**
لا تطلب من النموذج إخراج SQL. اطلب منه إخراج النية المنظمة: `{ “table”: “orders”, “filters”: [{“field”: “status”, “op”: “eq”, “value”: “pending”}], “limit”: 10 }`. بعد ذلك، تعين عقدة Code هذا إلى استعلام معامل. أكثر أماناً وأكثر موثوقية من SQL الحر.
**5. حلقة إصلاح من محاولة واحدة إذا لزم الأمر**
بالنسبة للمخططات المعقدة حيث قد يفشل النموذج أحياناً بشكل متكرر، قم بتوصيل عقدة IF للتحقق من أخطاء التحليل → إعادة الإرسال إلى Ollama مع رسالة الخطأ المرفقة بالفورية. إعادة محاولة واحدة تلتقط معظم المتأخرين. إذا فشلت مرتين، قم بتوجيه إلى بديل / مراجعة بشرية بدلاً من التخمين.
مزيج format:json + schema + التحقق من الكود هو ما أستخدمه في سير العمل بأسلوب الإنتاج. يعمل بدون أي عقد مدفوعة.
أهلاً وسهلاً @osman1!
هناك شيء يستحق إضافته إلى المكدس: n8n يتضمن عقدة “Auto-fixing Output Parser” التي تغلف Structured Output Parser. إذا أرجع النموذج JSON بصيغة خاطئة، فإنها تُرسل الخطأ تلقائياً إلى LLM لمحاولة إصلاح ذاتي واحدة - بدون الحاجة إلى منطق IF يدوي أو إعادة محاولة. بالنسبة إلى Ollama تحديداً، مرّر أيضاً format: "json" في خيارات body الخاصة بعقدة Ollama Chat Model لتقييد أخذ العينات من الرموز على مستوى النموذج، ثم دع Auto-fixing Parser يفرض مخططك في الأعلى. إن هذا الإعداد ثنائي الطبقات (قيد التنسيق على مستوى النموذج + إصلاح على مستوى المحلل) هو أكثر الأساليب موثوقية التي استخدمتها مع النماذج المحلية.
الإجابات أعلاه تغطي الطبقة الهيكلية بشكل جيد. هناك طبقة أخرى جديرة بالإضافة وهي التحقق الدلالي – اكتشاف JSON الذي يتم تحليله بشكل نظيف لكنه يحتوي على قيم لا معنى لها.
بعض الأمثلة: حقل تاريخ يتم تحليله كنص لكنه ليس تاريخًا صحيحًا. حقل الحالة بالنوع الصحيح لكن بقيمة خارج التعداد المسموح به. حقل السعر أو العدد بصيغة معقولة لكن نطاق غير معقول (0.0001 أو 99999999). يتعامل محلل التصحيح التلقائي مع الحالة التي يعيد فيها النموذج JSON مشوهًا ويحاول مرة أخرى. لكن إذا نجحت المحاولة الثانية من الناحية الهيكلية، فإن الإخراج لا يزال ينسكب لاحقًا حتى لو كانت القيم بلا معنى. الطبقة الهيكلية لا تعرف أن shipping_cost يجب أن يكون موجبًا.
الحل هو عقدة Code بعد محلل يقوم بفحوصات صريحة: وجود الحقول المطلوبة، وتأكيدات النوع، وعضوية التعداد، وحراس النطاق. إذا فشل أي فحص، توقف العنصر أو وجهه إلى قائمة مراجعة بدلاً من السماح للبيانات السيئة بالتقدم.
الجزء الذي يؤتي ثماره بمرور الوقت هو تسجيل كل فشل مع مخرجات LLM الأولية والحقل الذي فشل والطابع الزمني. شيئان يصبحان مرئيين في هذا السجل وليس مرئيين بطريقة أخرى: أي الحقول تفشل 30 بالمائة من الوقت (مشكلة في الطلب تستحق الإصلاح) مقابل أي منها تفشل بنسبة 1 بالمائة من الوقت (حالة حدية يجب التعامل معها في التوجيه). وعندما تقوم بترقية النموذج المحلي، يمكنك مقارنة معدلات الفشل قبل وبعد.
فحوصات Tony و pirateprentice الهيكلية الموصوفة هي الطبقة الأولى الصحيحة. الطبقة الدلالية هي ما يحول “يتم تحليله” إلى “موثوق بما يكفي للتصرف بناءً عليه.”}