في مقال نشر مؤخرًا، شارك مهندس Datadog Arnold Wakim ما نجح، وما لم ينجح، والدروس التي تعلموها أثناء تطوير نظام إنتاج مهم باستخدام الذكاء الاصطناعي للتغلب على القيود الصارمة في الواجهة الخلفية للتخزين وتحسين الأداء بشكل ملحوظ.
تم إنشاء الإصدار الأصلي من Stream Router، وهو واجهة برمجة التطبيقات (API) لإدارة التوجيه في مسار المقاييس، كنظام ثابت في نهاية المطاف باستخدام نموذج القيمة الرئيسية (KV). مع توسع جدول التوجيه، بدأت قاعدة بيانات KV في الوصول إلى حدود حجم المعاملات، وتباطأت العمليات الأكثر تطلبًا بشكل كبير، حيث استغرقت ما يصل إلى 45 دقيقة بسبب آلاف الرحلات ذهابًا وإيابًا المتسلسلة.
في نموذج KV، كان على الكود إعادة بناء هذه العلاقات. من شأنه أن يسحب عشرات الآلاف من الإدخالات إلى عمليات pod ويعمل بشكل فعال كقاعدة بيانات علائقية قيد المعالجة – يتعامل مع المنطق الذي ستفرضه المفاتيح الخارجية عادةً في نظام علائقي.
ولمعالجة هذه المشكلة، أعاد مهندسو Datadog تصميم المخطط بعناية ليعكس العلاقات بين كيانات المجال مما يسمح للمفاتيح الخارجية باستبدال المنطق الذي كان يجب إعادة بنائه مسبقًا في كود التطبيق. بمجرد تحديد المخطط الجديد، احتاجوا إلى إعادة هيكلة قاعدة التعليمات البرمجية بأكملها للانتقال من النموذج القديم إلى النموذج الجديد، وهي المهمة التي تحولوا من أجلها إلى الذكاء الاصطناعي:
لقد استخدمنا Claude وCursor لتسريع عملية إعادة الهيكلة المنهجية القائمة على الاختبار. لم يكونوا يقومون بإنشاء التعليمات البرمجية بشكل مستقل: بالنسبة لكل طريقة، قدمنا التنفيذ القديم والمخطط الجديد واختبار الفشل. ستقوم النماذج بتوليد النجاح الأول، وتخبرنا الاختبارات ما إذا كان ذلك صحيحًا.
وفقًا لواكيم، كانت هناك ثلاثة عناصر رئيسية جعلت الترحيل ممكنًا: نمطية التعليمات البرمجية القوية، التي سمحت لجهاز التوجيه الدفق الجديد بتنفيذ نفس واجهة برمجة التطبيقات على PostgreSQL بدلاً من FoundationDB دون الحاجة إلى تغييرات في مكان آخر؛ ومجموعة اختبار شاملة، كانت بمثابة معيار نجاح/فشل واضح لكل تغيير يتم إنشاؤه بواسطة الذكاء الاصطناعي؛ وبنية تحتية متوازية يتم فيها تشغيل مثيلين مستقلين لجهاز Stream Router جنبًا إلى جنب، للتعامل مع نفس الطلبات أثناء توجيه العملاء بينهما عبر علامات الميزات:
يتم تشغيل خدمة التحقق المخصصة في كل مجموعة، حيث تقوم بشكل دوري بمقارنة استجابات التوجيه بين الاثنين وتنبيه الفريق على الفور في حالة اختلاف أي شيء.
تمت الهجرات نفسها عبر ثلاث مراحل: أولاً، استخدام كلود لوصف الغرض من كل وظيفة رئيسية؛ ثانيًا، صياغة مطالبات مركزة لإصلاح الاختبارات الفاشلة من خلال توفير السلوك المتوقع جنبًا إلى جنب مع السياق من الخطوة السابقة؛ وأخيرًا، النشر إلى الإنتاج باستخدام نهج “الأزرق/الأخضر”، حيث تعمل أجهزة التوجيه الدفقية الجديدة المدعومة من PostgreSQL والمدعومة من FoundationDB بالتوازي وتمت مقارنتها بشكل مستمر.
ويشير واكيم أيضًا إلى بعض المجالات التي فشل فيها النهج، بما في ذلك الفعالية المحدودة للمطالبات ذات المستوى الأعلى وميل كلود إلى إنشاء استعلامات صحيحة ولكن دون المستوى الأمثل:
التحسينات المتخصصة مثل التجميع،
UNNESTتتطلب الحيل وتعبيرات الجدول الشائعة مدخلات بشرية. أعادت الاستعلامات التي تم إنشاؤها بواسطة الذكاء الاصطناعي النتائج الصحيحة ولكنها أصدرت رحلات ذهابًا وإيابًا أكثر بكثير من اللازم. لقد كتبنا الإصدارات المحسنة بأنفسنا، وبمجرد أن رأت النماذج النموذج، كان بإمكانها تكراره بطرق لاحقة. لكنهم لم يكتشفوا هذه الأنماط بشكل مستقل، على الرغم من وجودها في الأدبيات.
هناك مشكلة أخرى وهي الاستهلاك العالي للرموز، مدفوعًا بتغذية عمليات تفريغ مخرجات الاختبار الكاملة للذكاء الاصطناعي بدلاً من المقتطفات المشذبة، بالإضافة إلى الحلقة التكرارية لمخرجات الاختبار وسياق التعليمات البرمجية ومعلومات المخطط.
بعد أن انخفضت عمليات الترحيل من 45 دقيقة إلى حوالي ثانية واحدة، وانخفض زمن الوصول من مئات المللي ثانية إلى بضعة أجزاء فقط. أصبح تخزين البيانات أصغر بما يصل إلى 40 مرة، في حين قامت PostgreSQL وDuckDB بتبسيط التعامل مع العلاقات وتحسين كفاءة الاستعلام. انخفض استخدام وحدة المعالجة المركزية والذاكرة وانخفضت تكاليف قاعدة البيانات بنسبة 90%.
باختصار، يخلص واكيم إلى أن عامل النجاح الرئيسي في ترحيل Datadog باستخدام Claude كان قوة مجموعة الاختبار الخاصة بهم، والتي حددت في النهاية مدى ثقتهم في التعليمات البرمجية التي ينشئها الذكاء الاصطناعي.
