مقارنة Ollama Cloud في مراجعة الشيفرة: DeepSeek v3.1 تتفوق على Qwen وGPT-OSS

هل يمكن الوثوق بنموذج لغوي كبير (LLM) في مراجعة شيفرة كاملة؟ في اختبار عملي عبر Ollama Cloud، فحصت ثلاثة نماذج، هي Qwen 3.5 وGPT-OSS وDeepSeek v3.1، طلبات سحب (PR) حقيقية من مشروع Python قديم، وذلك بالموجّه (prompt) نفسه والإعدادات نفسها وسياق RAG نفسه. كانت DeepSeek الأكثر فائدة من حيث عمق التحليل وجودة الإصلاحات. أما Qwen فقد فاجأت بأدائها الجيد، بينما تخلّفت GPT-OSS بوضوح من حيث القيمة العملية لملاحظاتها.

معالج بواسطة الذكاء الاصطناعي من Habr AI؛ بتحرير Hamidun News
مقارنة Ollama Cloud في مراجعة الشيفرة: DeepSeek v3.1 تتفوق على Qwen وGPT-OSS
المصدر: Habr AI. كولاج: Hamidun News.
استمع للمقال
بطاقة الحقائق والأرقام
المعيارالتفاصيل
المصدر الأصليHabr AI ↗
رئيس التحرير
حقيقة رئيسية #1دقة اكتشاف المشكلات الحقيقية في الشيفرة
حقيقة رئيسية #2فهم المخاطر الأمنية
حقيقة رئيسية #3الميل إلى الهلوسة

أظهر اختبار عملي أن النماذج السحابية عبر Ollama باتت قادرة على تغطية جزء من مهام مراجعة الشيفرة على طلبات سحب (Pull Request) حقيقية، لا على أمثلة توضيحية فحسب. وفي المقارنة بين Qwen 3.5 وGPT-OSS وDeepSeek v3.1، قدّمت DeepSeek أعمق تحليل وأكثر التوصيات قابلية للتطبيق، وإن لم يخلُ الأمر من تحفظ مهم يتعلق بالإعدادات.

كيف أُجري الاختبار

لم يختبر كاتب المقال النماذج على مهام نظرية، بل على طلبات سحب (Pull Request) من مشروعه القديم (legacy) المكتوب بلغة Python، والبالغ عمره نحو أربع سنوات. أُعدّ طلب سحب مستقل لكل نموذج، مع إبقاء الظروف متطابقة: الموجّه (prompt) نفسه، والوصول نفسه إلى سياق المشروع، وتفعيل RAG حتى يتمكن النظام من جلب ملفات إضافية بدل الاقتصار على diff وحده. وتكمن أهمية هذا النهج في أن نقص السياق كثيرًا ما يجعل مراجعة الذكاء الاصطناعي سطحية.

وجرى توحيد الإعدادات إلى أقصى حد: temperature بقيمة 0.2، وحد أقصى قدره 4000 رمز (token)، ومستوى عالٍ من الصرامة في الملاحظات، وتفعيل البحث عن المشكلات الأمنية ومشكلات الأداء والأسلوب، مع السماح للنموذج باقتراح إصلاحات. وحلّلت النماذج الشيفرة المرتبطة بالتغيير، لا diff وحده فقط.

شمل الاختبار Qwen 3.5 وGPT-OSS وDeepSeek v3.1، وهي ثلاثة نماذج بارزة مفتوحة الأوزان (open-weight) يُنظر إليها اليوم كثيرًا بوصفها بديلًا لأدوات المطورين المقدّمة كخدمات SaaS.

قُيّمت النماذج على مقياس من خمس درجات، وكانت المعايير الرئيسية كما يلي:

  • دقة اكتشاف المشكلات الحقيقية في الشيفرة
  • فهم المخاطر الأمنية
  • الميل إلى الهلوسة
  • عمق التحليل وفهم تبعات التغييرات
  • الفائدة العملية للإصلاحات المقترحة

كما راقب الكاتب على حدة معدل القبول البشري (human acceptance rate)، أي مدى احتمال أن يقبل المطوّر تعليقات النموذج فعلًا بدل تجاهلها كضجيج.

نتائج النماذج

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

في المقابل، جاء أداء GPT-OSS أضعف بوضوح، إذ حصلت على 2.9 درجة. وتتمثل الملاحظة الرئيسية عليها في الطابع العام المفرط لتعليقاتها. فقد اكتشف النموذج جزءًا من المشكلات الحقيقية، لكنه ربط التعليقات بالتغييرات المحددة في طلب السحب (PR) بدرجة أقل، وقدّم إصلاحات تلقائية (auto-fix) قابلة للتطبيق بوتيرة أقل، وانزلق في كثير من الأحيان إلى افتراضات لا أساس كافيًا لها. وبقي أسلوب إجاباتها الواضح ميزة، لكنه لم يكن كافيًا لمراجعة شيفرة عملية، فالمطوّر لا يحتاج إلى صياغات أنيقة بل إلى ملاحظات دقيقة ومفيدة.

أما DeepSeek v3.1 فقد حققت أقوى نتيجة تقنية. فمن دون احتساب الخصم، بلغ تقييمها النهائي 4.25 درجة: إذ شرحت أسباب المشكلات أفضل من غيرها، ولاحظت المخاطر الأمنية بوتيرة أعلى، واقترحت إصلاحات سليمة هندسيًا، وحلّلت تبعات التغييرات بعمق أكبر. وقد خفّض الكاتب النتيجة رسميًا إلى 3.25 درجة، لأن النموذج لم يتمكن من استخدام الأداة دون تفعيل وضع التفكير (think mode). ومع ذلك، وُصفت DeepSeek تحديدًا بأنها الخيار الأعمق والأكثر عملية بين النماذج المختبرة.

«يمكن فعلًا استخدام النماذج السحابية عبر

Ollama في مهام مراجعة الشيفرة».

أين تناسب Ollama

لا يتمثل الاستنتاج الرئيسي للمقال في أن Ollama تحل تلقائيًا محل الخدمات المتخصصة مثل CodeRabbit وClaude Review وQoDo. بل العكس إلى حد ما: فجودة مراجعة الذكاء الاصطناعي تعتمد بدرجة كبيرة على النموذج المختار وإعداداته ومقدار السياق الذي مُنحه. فإذا اختير نموذج غير موفّق، أو اقتُصر على diff دون الوصول إلى ملفات المشروع، تحولت النتيجة سريعًا إلى مجموعة ملاحظات سطحية.

لكن لدى Ollama سيناريو استخدام قويًا حيث تهم الفريق السيطرة والمرونة. ويؤكد الكاتب تحديدًا أن هذا النهج مثير للاهتمام بصفة خاصة للمشاريع ذات الشيفرة الحساسة، والمقيّدة باتفاقيات عدم الإفصاح (NDA)، والتي لا يريد أصحابها إرسال الشيفرة المصدرية إلى بنية تحتية خارجية. كما تتيح المنصة التبديل السريع بين النماذج، وبناء خطوط معالجة (pipelines) خاصة فوق API، والانتقال عند الحاجة إلى التشغيل المحلي بدل السحابة.

أما إذا لم تكن لدى الفريق متطلبات صارمة للخصوصية، ولم تكن الميزانية حرجة، فقد تظل حلول SaaS الجاهزة قادرة على تقديم نتيجة أكثر استقرارًا «من العلبة». فتكاملها مع سير العمل (workflow) أقوى، وأتمتتها الجاهزة أكبر، وحاجتها إلى الإعداد اليدوي أقل. ويُظهر التجربة إجمالًا أن النماذج المفتوحة تلحق بهذه الفئة من المنتجات أسرع مما توقعه كثيرون.

ماذا يعني ذلك

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

القصة

أسئلة وأجوبة حول الخبر

ما أبرز التفاصيل حول كيف أُجري الاختبار؟

لم يختبر كاتب المقال النماذج على مهام نظرية، بل على طلبات سحب (Pull Request) من مشروعه القديم (legacy) المكتوب بلغة Python، والبالغ عمره نحو أربع سنوات. أُعدّ طلب سحب مستقل لكل نموذج، مع إبقاء الظروف متطابقة: الموجّه (prompt) نفسه، والوصول نفسه إلى سياق المشروع، وتفعيل RAG حتى يتمكن النظام من جلب ملفات إضافية بدل الاقتصار على diff وحده. وتكمن أهمية هذا النهج في أن نقص السياق كثيرًا ما يجعل مراجعة الذكاء الاصطناعي سطحية. وجرى توحيد الإعدادات إلى أقصى حد: temperature بقيمة 0.2، وحد أقصى قدره 4000 رمز (token)، ومستوى عالٍ من الصرامة في الملاحظات، وتفعيل البحث عن المشكلات الأمن

ما أبرز التفاصيل حول نتائج النماذج؟

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

ما أبرز التفاصيل حول أين تناسب Ollama؟

لا يتمثل الاستنتاج الرئيسي للمقال في أن Ollama تحل تلقائيًا محل الخدمات المتخصصة مثل CodeRabbit وClaude Review وQoDo. بل العكس إلى حد ما: فجودة مراجعة الذكاء الاصطناعي تعتمد بدرجة كبيرة على النموذج المختار وإعداداته ومقدار السياق الذي مُنحه. فإذا اختير نموذج غير موفّق، أو اقتُصر على diff دون الوصول إلى ملفات المشروع، تحولت النتيجة سريعًا إلى مجموعة ملاحظات سطحية. لكن لدى Ollama سيناريو استخدام قويًا حيث تهم الفريق السيطرة والمرونة. ويؤكد الكاتب تحديدًا أن هذا النهج مثير للاهتمام بصفة خاصة للمشاريع ذات الشيفرة الحساسة، والمقيّدة باتفاقيات عدم الإفصاح (NDA)، والتي لا يريد أصح

ZK
جمال حميدون — مدير المنتجات في Alpina Digital ومدير منتج AlpinaGPT. يبني منتجات الذكاء الاصطناعي منذ 2019. بدأ Hamidun News كمشروع شخصي ثم أصبح مُجمِّعًا إنتاجيًا بأكثر من 6000 قارئ.
✦ Hands-On AI Engineering · Hamidun Academy

Build & Ship Production AI Agents Without Boilerplate Code

Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.

Start 72h Free Trial →Vibe-Coding Intensive
ما رأيك؟
جارٍ تحميل التعليقات…