تُمَثِّل نماذج اللغة الكبيرة للبرمجة نقطة تحول رئيسية في الذكاء الاصطناعي. تم تصميمها خصيصًا لفهم وتوليد لغات البرمجة، مما يعزز بشكل كبير كفاءة سير عمل تطوير البرمجيات. في هذا التقرير الفني، نقدم CodeShell-Base، نموذجًا أساسيًا بسبعة مليارات معلمة وطول سياق 8K، والذي يُظهر كفاءة استثنائية في فهم الكود. من خلال دمج انتباه الاستعلام المجمع وترميز الموضع الدوار في GPT-2، يجمع CodeShell-Base بين المزايا الهيكلية لـ Starcoder و CodeLlama ويتميز بتصميم معماري فريد. بعد ذلك، أنشأنا عملية معالجة بيانات شاملة بعناية، تشمل إزالة التكرار للبيانات المتشابهة، وتصفية البيانات بناءً على الحيرة، وتصفية البيانات بناءً على النموذج. من خلال هذه العملية، جمعنا 100 مليار رمز تدريب مسبق عالية الجودة من GitHub. وبفضل البيانات عالية الجودة، يتفوق CodeShell-Base على CodeLlama في Humaneval بعد التدريب على 500 مليار رمز فقط (5 حقب). أجرينا تجارب واسعة النطاق عبر مجموعات بيانات متعددة اللغات، بما في ذلك Python، Java، و C++، وتشير النتائج إلى أن نموذجنا يمتلك قدرات أساسية قوية في فهم وتوليد الكود.
نماذج اللغة الكبيرة للبرمجة مثل CodeGen (codegen)، CodeLlama (codellama)، وStarCoder (starcoder) أحدثت ثورة في تطوير البرمجيات من خلال أتمتة المهام، تقليل الأخطاء، وتحسين الكفاءة (gpt4report). بالاستفادة من التعلم العميق ومجموعات البيانات الضخمة للكود (codegen,thestack)، تعزز هذه النماذج إنتاجية المطورين وتجعل تطوير البرمجيات أكثر سهولة لجمهور أوسع.
يمكن تقسيم نماذج اللغة الكبيرة للبرمجة الحالية إلى ثلاث فئات رئيسية: التدريب المسبق من الصفر (starcoder)، التدريب المسبق من نموذج لغة كبير موجود (codex,codellama)، والتعديل التوجيهي (wizardcoder). النماذج التي يتم تدريبها مسبقًا من الصفر تتطلب حجمًا كبيرًا من البيانات ووقتًا طويلاً (starcoder,llama2). من ناحية أخرى، يستفيد التدريب المسبق من نموذج لغة كبير موجود كأساس له، مما يوفر مزايا تقليل أوقات التدريب وتحسين الكفاءة مع بيانات أقل (codex,codellama). التعديل التوجيهي، من ناحية أخرى، يتضمن تعديل نموذج كبير موجود باستخدام بيانات توجيهية بهدف تحسين أداء النموذج بشكل كبير (codellama,wizardcoder). ومع ذلك، يبقى التحدي الأكبر في هذا المجال هو أن النماذج الكبيرة الموجودة تم تدريبها على مجموعات بيانات ضخمة من الكود دون حوكمة دقيقة للبيانات، مما قد يؤدي إلى إنتاج كود منخفض الجودة. على الرغم من وجود بعض استراتيجيات اختيار الكود (phi1) من منظور نموذج التدريب، لا يزال خطر إنتاج كود منخفض الجودة مصدر قلق.
في هذا التقرير الفني، نقدم نموذج كود كبير يُسمى CodeShell. يدمج CodeShell ترميز الموضع الدوار (rope) وانتباه الاستعلام المجمع (gqa) في GPT-2 (gpt2)، لبناء بنية فعالة وملائمة لتوسيع السياق. ثم طورنا خط أنابيب لاختيار الكود عالي الجودة، مما أدى إلى الحصول على 100 مليار رمز من الكود عالي الجودة. استنادًا إلى هذا الأساس من 100 مليار رمز، تم تدريب CodeShell على مدى خمس فترات. تظهر تجاربنا أن التدريب فقط على 100 مليار رمز فريد من الكود يمكّن CodeShell من تحقيق أداء يعادل، إن لم يكن أفضل من، النماذج الكبيرة الموجودة. للمقارنة، تم تدريب كل من StarCoder (starcoder) وCodeLlama (codellama) على 250 مليار رمز فريد. كما هو معروف، الكود عالي الجودة محدود ضمن المستودعات المفتوحة المصدر الحالية، مما يجعل اختيار الكود عالي الجودة أمرًا بالغ الأهمية لتطوير نموذج كود عالي الجودة. إليكم مساهماتنا الرئيسية:
أصدرنا CodeShell-7B، نموذجًا أساسيًا جديدًا للكود الكبير تم تدريبه مسبقًا من الصفر ويتميز بتصميم بنية جديد وفريد. من خلال الاختبارات على مجموعة متنوعة من المعايير العامة المتعلقة بالكود، أظهر أداءً تنافسيًا عبر لغات برمجة متعددة.
من أجل تقليل تكاليف تدريب نماذج الكود الكبيرة، أنشأنا خط أنابيب فعال لمعالجة البيانات قادر على تحديد مقاطع الكود عالية الجودة من مجموعات الكود الضخمة. تشير النتائج التجريبية إلى أن نموذجنا، المدرب على 500B رمز فقط، يتجاوز أداء StarCoder المدرب على 1 تريليون رمز.
لمعالجة مهام البرمجة الأكثر تعقيدًا وشمولاً (codereval,defects4j)، قمنا بزيادة طول سياق النموذج إلى 8K، مما يعزز قدرته على معالجة مقاطع الكود الأطول. تشير الأدلة التجريبية إلى أن تمديد مراحل التدريب المسبق مع زيادة أطوال الكود يحسن بشكل كبير كفاءة النموذج في إدارة تسلسلات الكود الطويلة، دون التأثير سلبًا على فعاليته في التعامل مع مقاطع الكود الأقصر.
لمزيد من التفاصيل حول المعلومات المقدمة في سياق بناء مجموعة بيانات تدريب CodeShell وعملية التصفية والتحسين اللاحقة، دعونا نستعرض كل خطوة بمعلومات أكثر تحديدًا:
جمع البيانات: كان مصدرنا الأساسي، GitHub (gharchive)، قد تم فحصه بعناية لجمع مجموعة شاملة من المستودعات. وشمل ذلك الزحف المباشر لـ 15TB من مستودعات GitHub لضمان الحصول على مجموعة بيانات واسعة ومتنوعة. كما ساهم تضمين مجموعات بيانات Stack (thestack) وStarCoder في إثراء تنوع المواد التدريبية بمجموعة غنية من أمثلة الأكواد والمناقشات البرمجية.
تصفية اللغات: كان قرار استبعاد اللغات التي يقل حجم مجموعة بياناتها عن 100 ميغابايت استراتيجيًا، مع التركيز على اللغات التي لها استخدام كافٍ وأمثلة تساهم في أنماط التعلم المهمة. وهدف إدراج 7 مجموعات بيانات متعلقة بالأكواد، مثل markdown للتوثيق، وgit-commits لممارسات التطوير، وGitHub-issues لمناقشات حل المشكلات، إلى توسيع فهم النموذج لأنظمة البرمجة.
قواعد التصفية الأولية: صممنا قاعدة لاستبعاد الأكواد ذات الأطوال الزائدة للأسطر والمحتوى المنخفض من الأحرف الأبجدية للقضاء على البيانات غير النمطية، والتي قد لا تكون ممثلة، مع التركيز على تدريب النموذج على أمثلة أكواد أكثر معيارية وقابلة للقراءة.
إزالة التكرار: سمح استخدام تجزئة MD5 بتحديد وإزالة النصوص المكررة بدقة، بينما تم استخدام تقنيات MinHash (minihash) للكشف عن المحتويات المتشابهة جدًا ولكن غير المتطابقة وتصفيةها. كانت هذه الخطوة حاسمة لتعزيز تنوع وجودة مجموعة البيانات.
التصفية بناءً على الحيرة: تم استخدام درجات الحيرة (pplf) كمقياس لقدرة التنبؤ وجودة نصوص الأكواد. من خلال تصفية الأكواد ذات درجات الحيرة العالية، هدفنا إلى استبعاد أمثلة الأكواد ذات الجودة المنخفضة أو المربكة، مما يعزز جودة مجموعة البيانات أكثر.
التصفية بناءً على القواعد: مكّن نظام التحليل والتصفية القائم على القواعد من التعرف الفعال واختيار أمثلة الأكواد عالية الجودة من خلال عملية فحص مخصصة. على وجه التحديد، نبدأ بتعريف وحساب سلسلة من المقاييس لملفات الأكواد، بما في ذلك عدد الأسطر، ووجود ومدى التعليقات، ومتوسط عدد الأحرف لكل سطر. ثم نحدد عتبة لعزل أمثلة الأكواد النموذجية التي تلبي معاييرنا. علاوة على ذلك، يقدم النظام تحيزًا تفضيليًا نحو الأكواد التي تستخدم مكتبات الطرف الثالث المعروفة، وهو مؤشر على ممارسات تطوير قوية. بالإضافة إلى ذلك، نؤكد على اختيار الأكواد التي تظهر مستوى مناسبًا من التعقيد المنطقي. يتم تحديد ذلك من خلال التحليل المتعمق لشجرة البناء المجردة وتدفق التحكم داخل الأكواد، بهدف ضمان أن الأمثلة التي نختارها ليست فقط وظيفية ولكن أيضًا متطورة. جانب حاسم آخر هو التزام الأكواد بمعايير البرمجة المعتمدة. يُعتبر الالتزام بهذه المعايير انعكاسًا لأفضل الممارسات في الصناعة.
| css | 30.09 | 5292.28 | 2.38% | 0.13 | 23.58 | 0.28% |
| assembly | 4.21 | 553.85 | 0.33% | 0.13 | 17.02 | 0.27% |
| powershell | 2.84 | 586.14 | 0.22% | 0.10 | 19.76 | 0.20% |
| json | 15.91 | 8939.52 | 1.26% | 0.07 | 39.84 | 0.15% |
| r | 0.59 | 77.32 | 0.05% | 0.06 | 8.38 | 0.13% |
| sql | 12.69 | 784.41 | 1.01% | 0.06 | 3.50 | 0.12% |
| dart | 9.85 | 2210.66 | 0.78% | 0.04 | 9.85 | 0.09% |
| jupyter-scripts-dedup-filtered | 7.03 | 910.54 | 0.56% | 0.03 | 4.06 | 0.06% |
| jupyter-structured-clean-dedup | 5.72 | 652.90 | 0.45% | 0.03 | 2.91 | 0.05% |
| tex | 5.70 | 493.84 | 0.45% | 0.03 | 2.20 | 0.05% |
| restructuredtext | 5.43 | 1036.81 | 0.43% | 0.02 | 4.62 | 0.05% |
| haskell | 5.41 | 1120.82 | 0.43% | 0.02 | 4.99 | 0.05% |
| ada | 0.53 | 56.26 | 0.04% | 0.02 | 2.35 | 0.05% |
| yaml | 3.25 | 2295.73 | 0.26% | 0.01 | 10.23 | 0.03% |
| common-lisp | 3.25 | 202.43 | 0.26% | 0.01 | 0.90 | 0.03% |
| pascal | 3.18 | 202.85 | 0.25% | 0.01 | 0.90 | 0.03% |
| makefile | 2.86 | 914.46 | 0.23% | 0.01 | 4.08 | 0.03% |
| java-server-pages | 2.79 | 519.49 | 0.22% | 0.01 | 2.32 | 0.03% |
| ocaml | 2.27 | 289.99 | 0.18% | 0.01 | 1.29 | 0.02% |
| fortran | 2.26 | 184.09 | 0.18% | 0.01 | 0.82 | 0.02% |
| visual-basic | 2.24 | 231.06 | 0.18% | 0.01 | 1.03 | 0.02% |
| mathematica | 2.10 | 46.81 | 0.17% | 0.01 | 0.21 | 0.02% |
| erlang | 1.99 | 253.50 | 0.16% | 0.01 | 1.13 | 0.02% |
| vhdl | 1.82 | 124.92 | 0.14% | 0.01 | 0.56 | 0.02% |
| elixir | 1.70 | 511.67 | 0.13% | 0.01 | 2.28 | 0.02% |
| groovy | 1.69 | 401.75 | 0.13% | 0.01 | 1.79 | 0.02% |
| smalltalk | 1.48 | 482.43 | 0.12% | 0.01 | 2.15 | 0.01% |
[tab:data_overview_1]
لتعزيز القدرة على التكيف مع سياق البرمجة الصينية، قمنا بإثراء مفردات StarCoder بإضافة كبيرة من المفردات الصينية. على وجه التحديد، جمعنا مليون ملف برمجة صيني وبيانات الأسئلة والأجوبة البرمجية باللغة الصينية. باستخدام مكتبة Tokenizer من Hugging Face، حددنا (40,000) مفردة صينية عالية التكرار. تم دمج هذه مع (30,000) مفردة إنجليزية عالية التكرار من مفردات StarCoder، مما أسفر عن مفردات CodeShell الشاملة. تشير النتائج التجريبية إلى أن مفردات CodeShell تظهر ميزة كبيرة في كفاءة تحليل الأسئلة والأجوبة البرمجية الصينية مقارنة بمفردات StarCoder.
يستفيد CodeShell من GPT-2 (gpt2) كمعمارية أساسية له، مستخدمًا تقنيات متقدمة مثل انتباه الاستعلام المجمع (gqa) وترميز المواقع الدوار (rope). تعمل آلية انتباه الاستعلام المجمع على تحسين عمليات الانتباه من خلال تجميع الاستعلامات المتشابهة، مما يحسن الكفاءة الحسابية ويقلل من التكرار. في الوقت نفسه، يقدم ترميز المواقع الدوار طريقة أكثر ديناميكية لتمثيل مواقع العناصر في التسلسلات، مما يوفر للنموذج فهمًا أفضل للترتيب والبنية داخل الشيفرات البرمجية.
في إعداد التدريب الخاص بنا، اخترنا AdamW كمحسن لنا، مع تهيئته بمعاملات \(\beta 1\) و \(\beta 2\) المضبوطة على 0.9 و 0.95 على التوالي. تتضمن عملية التدريب لدينا جدولًا زمنيًا لتبريد التعلم يبدأ بـ 1000 خطوة تسخين، بعدها ينخفض معدل التعلم من 3e-4 إلى 3e-5 في 127k تكرار. بالنسبة لدفعات التدريب الخاصة بنا، نعالج 4 ملايين رمز في دفعة واحدة، مقسمين إياها إلى تسلسلات من 2048 أو 8192 رمزًا لكل منها.
لتحقيق التوازن بين الكفاءة والحاجة إلى سياق أطول، اخترنا في البداية طول سياق يبلغ 2048 للمراحل الأولى من التدريب المسبق، وبعد التدريب على ما يقرب من 450 مليار رمز، قمنا بزيادة طول السياق إلى 8192. عقب هذا التعديل، انخفض معدل معالجة الوحدة الرسومية من 3200 رمز لكل وحدة رسومية في الثانية إلى 2600 رمز لكل وحدة رسومية في الثانية. في الوقت نفسه، أجرينا تجارب لمقارنة أداء النموذج قبل وبعد تغيير طول السياق. أظهرت النتائج أن أداء النموذج ظل ثابتًا إلى حد كبير، إن لم يتحسن. لوحظ انخفاض ملحوظ في الخسارة عندما تم توسيع طول السياق من 2048 إلى 8192. قد ينبع هذا الانخفاض من كون السياق الأطول يوفر معلومات أكثر، مما يبسط عملية التنبؤ. ومع ذلك، من الضروري التأكيد على أنه على الرغم من انخفاض الخسارة، لم تظهر مقاييس تقييم النموذج أي تحسن.
تستكشف هذه الفقرة أداء CodeShell. يتم تقييم CodeShell مقابل أحدث النماذج اللغوية الكبيرة المتقدمة:
StarCoder-7B وStarCoder-15B (starcoder)، نموذج بحجم معلمات ضخم يصل إلى 7 مليار و 15 مليار معلمة، متاح بشكل علني ويتفوق في مجموعة متنوعة من مهام البرمجة. يستفيد من جزء مختار بعناية من مجموعة بيانات Stack، التي تغطي 86 لغة برمجة.
CodeLlama (codellama)، يشمل مجموعة من نماذج اللغات الكبيرة المركزة على الكود (LLMs)، التي تطورت من نماذج LLaMA2 (llama2). تم تحسين نماذج CodeLlama من خلال التدريب المستمر على مجموعة كبيرة من الرموز تصل إلى 500 مليار رمز، مستفيدة من هندسة LLaMA2 الأساسية.
في هذا القسم، نقوم بتقييم أداء CodeShell على بايثون، مقارنة بالنماذج المفتوحة والمغلقة المصدر. نبدأ بالإبلاغ عن النتائج لتوليد كود بايثون باستخدام معياري HumanEval (codex) وMBPP (mbpp). تُلخص النتائج في الجداول [table:humaneval_mbpp]. تتألف مجموعة بيانات HumanEval من 164 مهمة بايثون مصممة يدويًا، تم التحقق منها من خلال حالات اختبار لتقييم أداء نموذج تعلم الآلة للكود في توليد الحلول دون أمثلة سابقة (إعداد الصفر). بالمقابل، يشمل معيار MBPP 500 تحدي بايثون مصمم لاختبار قدرة النموذج في سياق يتم فيه توفير عدد صغير من الأمثلة مسبقًا (إعداد القليل من الأمثلة).
تكشف النتائج التجريبية أن CodeShell-7B قد وضع معيارًا جديدًا في الأداء بين مجموعته، مسجلًا دقة متوسطة مثيرة للإعجاب بنسبة 34.3% على مجموعة بيانات HumanEval و38.7% على معيار MBPP. هذا الأداء لا يؤسس فقط CodeShell-7B كالرائد في فئته، بل يؤكد أيضًا تفوقه على Code-LLaMA-7B وStarCoder-Base 7B، وهما نموذجان مفتوحا المصدر مماثلا الحجم. على وجه التحديد، يُظهر CodeShell-7B ميزة تنافسية قوية، حتى عند مقارنته بنماذج الترميز الأكبر والأكثر تعقيدًا التي تتميز بزيادة كبيرة في عدد المعلمات.
يرجى ملاحظة أنه، من خلال تطبيق معايير صارمة لاختيار البيانات عالية الجودة وإجراء التدريب المتكرر على مدى عدة عصور، حقق CodeShell أداءً استثنائيًا في المهام الأساسية مثل HumanEval. ومع ذلك، قد تكون استراتيجية اختيار البيانات الحالية واستراتيجية التدريب غير كافية للتحديات الأكثر تعقيدًا مثل CoderUJB بسبب تعقيدها الهيكلي والمنطقي المتزايد. على الرغم من ذلك، من خلال تحسين عملية اختيار البيانات لدينا لتتماشى بشكل أفضل مع متطلبات مثل هذه المهام المعقدة، يمكننا تحسين أداء CodeShell على المهام الصعبة مثل CoderUJB.
بعد ذلك، نجري تقييمات لنماذجنا عبر طيف أوسع من لغات البرمجة، باستخدام معيار (multiple) الذي طوره كاسانو وآخرون في عام 2022 لهذا الغرض. تفاصيل النتائج لمجموعة متنوعة من اللغات، بما في ذلك جافا سكريبت، جافا، سويفت، بي إتش بي، وغيرها موضحة في الجدول [tb:results_multiple].
لقد لاحظنا أن كودشيل حقق نتائج أفضل في عدة لغات رئيسية، بما في ذلك جافا سكريبت، جافا، وسي بّي بّي، مقارنة بكودلاما-7ب، ستاركودر-7ب وستاركودر-15ب. ومع ذلك، كان أداؤه أدنى في لغات أصغر مثل دي، جوليا، ولووا. نعتقد أن هذا يرجع إلى سهولة الوصول إلى مجموعات بيانات عالية الجودة للغات الرئيسية، مما يسمح للنموذج بتحقيق نتائج أفضل مع تدريب بيانات كافٍ. بالإضافة إلى ذلك، من الجدير بالذكر أن نموذجنا أظهر أداءً تنافسيًا مع ستاركودر-15ب، مما يشير إلى أن التدريب المسبق لنماذج الكود الكبيرة على نماذج أصغر يحمل إمكانات كبيرة.
خلال مرحلة التدريب المسبق، تم تدريب نماذج CodeShell-7B بمعدل 0.5 لتقنية Fill-In-the-Middle (fim)، وهي تقنية تعزز قدرتها على توليد الكود من خلال ملء الفجوات بناءً على السياق المحيط بجزء الكود. تظهر هذه الطريقة فائدتها بشكل خاص لتطبيقات اكتمال الكود. تظهر قدرات مماثلة في النماذج مفتوحة المصدر مثل StarCoder-15B وCodeLlama-7B. وفقًا لـ (santacoder)، نقوم بإخفاء سطر نصي واحد من جسم الدالة، ونطلب من النموذج ملء ذلك السطر من الكود. نقوم بالتقييم على معيار MultiPLE (multiple) عبر ثلاث لغات برمجة، ونستخدم مطابقة السطر الواحد بالضبط (incoder) كمقياس.
النتائج، المفصلة بعناية في الجدول [tab:results_code_completion]، توضح أن CodeShell-7B يتفوق على كل من StarCoder وCodeLlama في هذه المعايير، مما يبرز الدور الحاسم لبيانات التدريب المسبق عالية الجودة. مشابهًا لـ CodeLlama، يستخدم CodeShell طول سياق يبلغ 2048 خلال المراحل الأولية من التدريب المسبق لتعزيز كفاءة التدريب. في المراحل النهائية من التدريب، وتحديدًا خلال آخر 50 مليار رمز، يمدد CodeShell طول السياق من 2048 إلى 8192. تكشف النتائج التجريبية أن القدرة على التعامل مع تسلسلات الكود الأطول يمكن تحقيقها بكمية ضئيلة فقط من بيانات التدريب. وبالتالي، خلال عملية التدريب المسبق، يمكننا استخدام طول سياق أصغر في البداية لتعزيز الكفاءة دون التضحية بكفاءة النموذج النهائية في التعامل مع تسلسلات الكود الواسعة.
لتقييم تأثير الانتباه متعدد الاستعلامات والانتباه المجمع للاستعلامات على أداء النموذج، أجرينا تجارب ضمن إطاري العمل للانتباه متعدد الاستعلامات والانتباه المجمع للاستعلامات. على وجه التحديد، لتسريع التحقق من صحة الهياكل المختلفة على أداء النموذج، طورنا نسخة “codeshell-small” بـ 24 طبقة، حجم خفي 2048، ومجموع 1 مليار معلمة. في هذه النسخة، نفذنا الانتباه متعدد الاستعلامات والانتباه المجمع للاستعلامات كوحدات انتباه لها، وأطلق عليهما على التوالي codeshell-small-mqa وcodeshell-small-gqa. تشير النتائج التجريبية إلى أنه، في ظل ظروف أقل من رموز التدريب، يظهر كل من codeshell-small-mqa وcodeshell-small-gqa أداءً متشابهًا. ومع ذلك، مع زيادة عدد رموز التدريب تدريجيًا، يتفوق codeshell-small-gqa على codeshell-small-mqa في أداء الاختبار@1.
للتحقق من فعالية آلية تصفية بيانات الشيفرة عالية الجودة، قمنا بتكوين مجموعتين من البيانات: مجموعة عشوائية، تم إنشاؤها عن طريق أخذ عينات عشوائية من 2 مليار رمز من مجموعة البيانات الأصلية غير المكررة، ومجموعة مصفاة، تم تجميعها بأخذ عينات من 2 مليار رمز من الأعلى إلى الأدنى بناءً على درجات من مقيم عالي الجودة. على وجه التحديد، لتسريع التحقق من فعالية الهياكل المختلفة على أداء النموذج، طورنا نسخة “صغيرة من قشرة الشيفرة” بـ 24 طبقة، وحجم خفي 2048، وإجمالي 1 مليار معلمة. أجرينا تجارب على هاتين المجموعتين باستخدام نموذج “صغير من قشرة الشيفرة”، وتظهر النتائج في الشكل أدناه. تظهر النتائج أن النموذج المدرب على المجموعة المصفاة يتفوق باستمرار على النموذج المدرب على المجموعة العشوائية من حيث الأداء. علاوة على ذلك، أظهر الأداء النهائي للنموذج المصفى تحسنًا بنسبة تقارب 100% مقارنة بالنموذج العشوائي. تؤكد هذه النتائج أيضًا الدور الحاسم لجودة البيانات في تدريب النماذج الكبيرة وتثبت أيضًا فعالية نهج تصفية البيانات لدينا.
لقد قدمنا نموذج الشيفرة كبير الحجم CodeShell. في هذه الورقة، استكشفنا تأثير هياكل النماذج المختلفة واستراتيجيات تصفية البيانات على أداء النموذج. تشير النتائج التجريبية إلى أن البيانات عالية الجودة تظل العامل الأكثر أهمية الذي يؤثر على أداء النماذج الكبيرة. من خلال اختيار البيانات عالية الجودة، حقق CodeShell أداءً مثاليًا عبر مجموعة متنوعة من لغات البرمجة بمقياس مماثل. علاوة على ذلك، في التجارب التي تمت باستخدام بيانات عالية الجودة، حققت طريقة تصفية البيانات التي اقترحناها تحسينًا في الأداء بنسبة 100% مقارنة بالاختيار العشوائي للبيانات.