Home
Blog
تتحسن مراجعة كود الذكاء الاصطناعي عندما تتناظر النماذج: كلود ضد جيميني ضد كودكس ضد كوين ضد ميني ماكس

تتحسن مراجعة كود الذكاء الاصطناعي عندما تتناظر النماذج: كلود ضد جيميني ضد كودكس ضد كوين ضد ميني ماكس

Engineering

February 26, 2026

Li Liu

لقد استخدمت مؤخرًا نماذج الذكاء الاصطناعي لمراجعة طلب سحب، وكانت النتائج متناقضة: أشار كلود إلى وجود سباق بيانات، بينما قال جيميني إن الكود نظيف. أثار هذا الأمر فضولي لمعرفة كيف ستتصرف نماذج الذكاء الاصطناعي الأخرى، لذلك قمتُ بتشغيل أحدث النماذج الرئيسية من Claude وGemini وCodx وQwen وMiniMax من خلال معيار منظم لمراجعة الشيفرة. والنتائج؟ اكتشف النموذج الأفضل أداءً 53% فقط من الأخطاء المعروفة.

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

يستعرض هذا المنشور تصميم التجربة، ونتائج كل نموذج، وما تكشفه آلية المناظرة حول كيفية استخدام الذكاء الاصطناعي في مراجعة التعليمات البرمجية.

قياس أداء كل من كلود وجيميني وكودكس وكوين وميني ماكس لمراجعة التعليمات البرمجية

إذا كنت تستخدم النماذج لمراجعة التعليمات البرمجية، فربما لاحظت أنها لا تختلف في الدقة فحسب؛ بل تختلف في كيفية قراءة التعليمات البرمجية. على سبيل المثال:

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

تميل الجوزاء إلى البدء بحكم قوي ("هذا سيء" / "يبدو جيدًا") ثم تعمل بشكل عكسي لتبرير ذلك من زاوية التصميم/الهيكل. أحيانًا يكون ذلك مفيدًا. وأحيانًا يبدو الأمر وكأنه اختلس النظر ثم التزم بأخذها.

الدستور أكثر هدوءًا. ولكن عندما يشير إلى شيء ما، غالبًا ما يكون ملموسًا وقابلًا للتنفيذ - أقل تعليقًا، وأكثر "هذا السطر خاطئ لأن X."

هذه انطباعات وليست قياسات. للحصول على أرقام فعلية، قمت بإعداد معيار.

الإعداد

تم اختبار خمسة نماذج رئيسية:

كلود أوبوس 4.6
جيميني 3 برو
GPT-5.2-Codex
Qwen-3.5-Plus
ميني ماكس-M2.5

الأدوات (Magpie)

لقد استخدمت Magpie، وهي أداة قياس مفتوحة المصدر قمتُ ببنائها. وتتمثل مهمتها في القيام ب "إعداد مراجعة الشيفرة" التي تقوم بها عادةً يدويًا: سحب السياق المحيط (سلاسل الاستدعاء والوحدات ذات الصلة والشيفرة المجاورة ذات الصلة) وتغذية النموذج قبل أن يراجع العلاقات العامة.

حالات الاختبار (علاقات عامة ميلفوس ذات الأخطاء المعروفة)

تتألف مجموعة البيانات من 15 طلب سحب من Milvus (قاعدة بيانات مفتوحة المصدر تم إنشاؤها وصيانتها بواسطة Zilliz). تُعدّ طلبات العلاقات العامة هذه مفيدة كمعيار مرجعي لأن كل منها تم دمجها، فقط لتتطلب لاحقًا إعادة أو إصلاح سريع بعد ظهور خطأ في الإنتاج. لذا فإن كل حالة لها خطأ معروف يمكننا تسجيلها.

مستويات صعوبة الأخطاء

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

L1: يمكن رؤيتها من الفرق وحده (استخدام خالي من الاستخدام، خارج نطاق واحد).
L2 (10 حالات): يتطلب فهم الكود المحيط لاكتشاف أشياء مثل التغييرات الدلالية للواجهة أو سباقات التزامن. تمثل هذه الأخطاء الأكثر شيوعًا في المراجعة اليومية للأكواد البرمجية.
L3 (5 حالات): تتطلب فهماً على مستوى النظام لاكتشاف مشاكل مثل التناقضات بين الوحدات أو مشاكل توافق الترقية. هذه هي أصعب الاختبارات لمدى عمق قدرة النموذج على فهم قاعدة الشيفرة.

ملاحظة: التقط كل النماذج جميع أخطاء L1، لذا استبعدتها من التقييم.

وضعان للتقييم

تم تشغيل كل نموذج في وضعين:

الخام: يرى النموذج العلاقات العامة فقط (الفرق + كل ما هو موجود في محتوى العلاقات العامة).
R1: يقوم Magpie بسحب السياق المحيط (الملفات ذات الصلة / مواقع الاستدعاء / التعليمات البرمجية ذات الصلة) قبل مراجعة النموذج. هذا يحاكي سير العمل حيث تقوم بإعداد السياق مقدمًا بدلًا من أن تطلب من النموذج تخمين ما يحتاجه.

النتائج (L2 + L3 فقط)

الوضع	كلود	الجوزاء	كودكس	ميني ماكس	كوين
خام	53% (الأول)	13% (الأخير)	33%	27%	33%
R1 (مع السياق بواسطة العقعق)	47% ⬇️	33%⬆️	27%	33%	40%⬆️

أربع نتائج

1. يهيمن كلود على المراجعة الأولية. فقد حصل على 53% في الاكتشاف الإجمالي و5/5 على أخطاء L3، دون أي مساعدة في السياق. إذا كنت تستخدم نموذجًا واحدًا ولا تريد قضاء الوقت في إعداد السياق، فإن Claude هو الخيار الأفضل.

2. يحتاج الجوزاء إلى سياق يُسلَّم إليه. كانت نتيجته الأولية 13% هي الأقل في المجموعة، ولكن مع توفير Magpie للرمز المحيط، قفزت إلى 33%. لا يجمع Gemini السياق الخاص به بشكل جيد، لكنه يؤدي أداءً محترمًا عندما تقوم بهذا العمل مقدمًا.

3. Qwen هو أقوى أداء بمساعدة السياق. فقد سجل 40% في وضع R1، مع 5/10 على أخطاء L2، وهي أعلى درجة في مستوى الصعوبة هذا. بالنسبة للمراجعات اليومية الروتينية الروتينية التي ترغب في إعداد السياق فيها، فإن Qwen هو اختيار عملي.

4. المزيد من السياق لا يساعد دائمًا. لقد رفعت من مستوى الجوزاء (13% ← 33%) وMiniMax (27% ← 33%)، لكنها في الواقع أضرت بـ Claude (53% ← 47%). تتفوق Claude بالفعل في تنظيم السياق من تلقاء نفسها، لذلك من المحتمل أن المعلومات الإضافية قد أحدثت ضوضاء بدلاً من الوضوح. العبرة المستفادة: طابق سير العمل مع النموذج، بدلاً من افتراض أن المزيد من السياق أفضل عالميًا.

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

دع نماذج الذكاء الاصطناعي تتناظر مع بعضها البعض

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

لذا أضفت طبقة مناظرة فوق نفس المعيار. تشارك جميع النماذج الخمسة في خمس جولات:

في الجولة 1، يراجع كل نموذج نفس العلاقات العامة بشكل مستقل.
بعد ذلك، أبث جميع المراجعات الخمسة لجميع المشاركين.
في الجولة 2، يقوم كل نموذج بتحديث موقفه بناءً على النماذج الأربعة الأخرى.
أكرر حتى الجولة 5.

في النهاية، لا يتفاعل كل نموذج مع الرمز فقط - بل يتفاعل مع الحجج التي تم نقدها ومراجعتها بالفعل عدة مرات.

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

النتائج: أفضل وضع منفرد مقابل وضع المناظرة

الوضع	L2 (10 حالات)	L3 (5 حالات)	إجمالي الكشف
أفضل فردي (كلود خام)	3/10	5/5	53%
المناظرة (جميع النماذج الخمسة)	7/10 (مضاعفة)	5/5 (تم القبض على الجميع)	80%

ما يبرز

1. تضاعف اكتشاف L2. قفزت الأخطاء الروتينية متوسطة الصعوبة من 3/10 إلى 7/10. هذه هي الأخطاء التي تظهر بشكل متكرر في قواعد البرمجة الحقيقية، وهي بالضبط الفئة التي تخطئ فيها النماذج الفردية بشكل غير متسق. أكبر مساهمة لآلية المناقشة هي سد هذه الثغرات اليومية.

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

3. المناظرة تملأ النقاط العمياء بدلاً من رفع السقف. لم تكن الأخطاء على مستوى النظام هي الجزء الصعب بالنسبة للفرد الأقوى. كان لدى كلود بالفعل تلك الأخطاء. تتمثل المساهمة الأساسية لآلية المناظرة في تصحيح ضعف كلود في أخطاء L2 الروتينية، حيث اكتشف كلود الفردي 3 فقط من أصل 10، لكن مجموعة المناظرة اكتشفت 7. من هنا تأتي القفزة التي بلغت 53% → 80%.

كيف تبدو المناظرة في الواقع العملي

تُظهر الأرقام أعلاه أن المناظرة ناجحة، ولكن هناك مثال ملموس يوضح سبب نجاحها. إليك شرحًا موجزًا لكيفية تعامل النماذج الخمسة مع PR #44474، الذي قدم التحميل البطيء للمفاتيح الأساسية أثناء البحث.

العلاقات العامة رقم 44474: تحسين التحميل البطيء الذي غيّر البحث لجلب المفاتيح الأساسية عند الطلب بدلاً من تحميلها كلها مقدمًا.

الجولة 1

افتتح الجوزاء بقوة:

"هذه العلاقات العامة هي حقل ألغام من الممارسات السيئة، والسلوك غير المحدد المحتمل، وتراجعات الأداء المتخفية في شكل "تحسين".

ركز كل من كلود وكوين على السلوك والأداء غير المحدد، وتوافقا على نفس الاهتمام:

“The C++ memory model doesn’t guarantee safety for concurrent writes to different indices of the same vector without proper synchronization.”

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

الجولة 2

التقط كلود اكتشاف كودكس وتتبع النتيجة النهائية:

"لقد وجدتها: SortEqualScoresByPks يعمل قبل ReduceResultData. لذلك عندما يتم تنفيذ SortEqualScoresByPks ، لم يتم جلب أي PKs بشكل كسول حتى الآن. يكون متجه primary_keys_ بأكمله مليئًا بقيم PkType الافتراضية المكوّنة افتراضيًا."

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

"حددت Codex-cli خطأً حقيقيًا خطيرًا في التصحيح. لقد فاتني هذا في جولتي الأولى."

أي مجموعة من النماذج يمكنها العثور على أكبر عدد من الأخطاء؟

حدثت القفزة من 53% إلى 80% لأن النماذج الخمسة غطت النقاط العمياء لبعضها البعض. ولكن لا يستطيع الجميع تحمل تكلفة إعداد وتشغيل خمسة نماذج خلال خمس جولات من المناقشة لكل مراجعة برمجية.

لذلك قمت باختبار النسخة الأبسط: إذا كان بإمكانك تشغيل نموذجين فقط، فأي نموذجين فقط يجعلك تقترب من سقف النماذج المتعددة؟

لقد استخدمت عمليات التشغيل بمساعدة السياق (R1) وقمت بحساب عدد الأخطاء المعروفة الـ 15 التي وجدها كل نموذج:

كلود: 7/15 (47%)
كوين: 6/15 (40%)
جيميني: 5/15 (33%)
ميني ماكس: 5/15 (33%)
كودكس: 4/15 (27%)

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

الاقتران بين النموذجين	التغطية المشتركة
كلود + جيميني	10/15
كلود + كوين	9/15
كلود + كودكس	8/15
كلود + ميني ماكس	8/15

جميع النماذج الخمسة معًا غطت 11 من أصل 15، مما يترك 4 أخطاء لم يلاحظها كل نموذج.

كلود + جيميني، كزوج من نموذجين، يصل بالفعل إلى 91% من سقف الخمسة نماذج. بالنسبة لهذا المعيار، فهو المزيج الأكثر كفاءة.

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

نوع الخطأ	المجموع	كلود	الجوزاء	كودكس	ميني ماكس	كوين
ثغرات التحقق من الصحة	4	3	2	1	1	3
دورة حياة بنية البيانات	4	3	1	1	3	1
السباقات المتزامنة	2	0	1	0	0	0
التوافق	2	0	1	1	0	1
المنطق العميق	3	1	0	1	1	1
المجموع الكلي	15	7	5	4	5	6

يكشف تحليل نوع الخطأ عن سبب عدم وجود ثنائي واحد هو الأفضل عالميًا.

بالنسبة لأخطاء دورة حياة بنية البيانات، تعادل كلود وميني ماكس بنسبة 3/4.
بالنسبة لثغرات التحقق من الصحة، تعادل كلود وكوين بنسبة 3/4.
بالنسبة لمشكلات التزامن والتوافق، سجل Claude صفرًا في كليهما، وGemini هو الذي يسد تلك الثغرات.
لا يوجد نموذج يغطي كل شيء، لكن كلود يغطي النطاق الأوسع ويقترب من كونه نموذجًا عامًّا.

أغفل كل نموذج أربعة أخطاء. أحدها يتعلق بأولوية قاعدة ANTLR النحوية. كان أحدها عدم تطابق دلالات قفل القراءة/الكتابة عبر الدوال. تطلب أحدها فهم الاختلافات في منطق العمل بين أنواع الضغط. وأحدها كان خطأ مقارنة صامتًا حيث استخدم أحد المتغيرات ميغابايت واستخدم آخر بايت.

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

بعد العثور على الأخطاء، ما هو النموذج الأفضل في إصلاحها؟

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

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

النموذج	الدقة	قابلية التنفيذ	العمق	الوضوح	الإجمال
كوين	8.6	8.6	8.5	8.7	8.6 (تعادل 1)
كلود	8.4	8.2	8.8	8.8	8.6 (تعادل 1)
الدستور الغذائي	7.7	7.6	7.1	7.8	7.5
الجوزاء	7.4	7.2	6.7	7.6	7.2
ميني ماكس	7.1	6.7	6.9	7.4	7.0

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

الخلاصة

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

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

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

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

كانMiniMax الأضعف في العثور على الأخطاء من تلقاء نفسه. من الأفضل استخدامه لملء مجموعة متعددة النماذج بدلاً من استخدامه كمراجع مستقل.

حدود هذه التجربة

هناك بعض المحاذير لإبقاء هذه التجربة في منظورها الصحيح:

حجم العينة صغير. لا يوجد سوى 15 من العلاقات العامة، وكلها من نفس مشروع Go/C+++G (Milvus). هذه النتائج لا يمكن تعميمها على جميع اللغات أو قواعد الشفرات. تعامل معها على أنها اتجاهية وليست نهائية.

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

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

جرب بنفسك

جميع الأدوات والبيانات من هذه التجربة مفتوحة المصدر:

Magpie: أداة مفتوحة المصدر تجمع سياق التعليمات البرمجية (سلاسل الاستدعاء، والعلاقات العامة ذات الصلة، والوحدات المتأثرة) وتنظم مناظرة متعددة النماذج لمراجعة التعليمات البرمجية.
AI-CodeReview-Arena: خط أنابيب التقييم الكامل والتكوينات والنصوص البرمجية.
حالات الاختبار: جميع العلاقات العامة الـ 15 مع الأخطاء المعروفة المشروحة.

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