لماذا يحتاج الذكاء الاصطناعي الإنتاجي إلى إدارة مخصصة للمطالبات

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

كانت مجموعة أدوات جيسون واسعة النطاق: قواعد بيانات متجهية حديثة، ومجموعات Kubernetes محسّنة للغاية، وخطوط أنابيب CI/CD متطورة. لكن جوهر العملية، المطالبات الفعلية التي تدفع هذه الميزات التي تبلغ قيمتها ملايين الدولارات، كانت تعيش في نظام بيئي محفوف بالمخاطر.

كانت بعض المطالبات مبرمجة بشكل ثابت في سلاسل Python f-strings، مدفونة بعمق داخل المنطق الشرطي كتحف أثرية. بينما كانت مطالبات أخرى موجودة في مستند Google مشترك من 40 صفحة بعنوان "FINAL_PROMPTS_v3_REAL_FINAL(2).docx"، ويتم تحديثه بواسطة ثلاثة مديري منتجات مختلفين. أما أحدث المطالبات التجريبية، فكان الرئيس التنفيذي يرسلها إلى جيسون عبر Slack في الساعة 11:30 مساءً.

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

لم يعد جيسون يقوم بعمل هندسي. كان جيسون يقوم بأعمال صيانة رقمية. لقد بنى الفريق محرك فيراري لكنه كان يقوده بقطع خيط مفككة.

الحقيقة الصعبة حول الذكاء الاصطناعي التوليدي في بيئة الإنتاج

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

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

عندما تكون المطالبات مرتبطة ارتباطًا وثيقًا بقواعد التعليمات البرمجية، تظهر عدة مشكلات حرجة:

1. تباطؤ سرعة التكرار: يريد خبير في المجال تعديل بضع كلمات لتحسين النبرة. لا ينبغي أن يتطلب ذلك تذكرة Jira، أو طلب سحب Git، أو تشغيل خط أنابيب CI/CD كامل، وموافقة هندسية.
2. نقص الرؤية: يصبح من المستحيل تقريبًا الإجابة على السؤال البسيط: "ما الذي يعمل بالضبط في بيئة الإنتاج الآن، وكيف يختلف عن الأسبوع الماضي؟"
3. صعوبات التعاون: يصبح المهندسون عنق الزجاجة. غالبًا ما يكون الأشخاص الأنسب لكتابة المطالبات (مديرو المنتجات، كتاب المحتوى، خبراء الموضوع) هم الأبعد عن قاعدة التعليمات البرمجية التي توجد بها المطالبات.

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

فوضى المطالبات غير المدارة

قبل تطبيق نهج منظم، غالبًا ما يبدو سير العمل وكأنه شبكة معقدة من سوء التواصل والجهد اليدوي.

نقدم TrueFoundry: البنية التحتية للذكاء الاصطناعي التوليدي

هنا يصبح نظام إدارة المطالبات المخصص ضروريًا. إنه الجسر بين الفن التجريبي لهندسة المطالبات والانضباط الصارم لهندسة برمجيات الإنتاج.

يعمل TrueFoundry كنظام التحكم المركزي هذا. وهو مصمم لفصل إدارة المطالبات عن منطق التطبيق، مما يسمح للفرق بالتعاون، وتحديد الإصدارات، وتقييم، ونشر المطالبات بنفس الدقة التي يطبقونها على التعليمات البرمجية التقليدية، ولكن بواجهات مصممة لتلبية الاحتياجات الخاصة لسير عمل نماذج اللغة الكبيرة (LLM).

يحول TrueFoundry إدارة المطالبات من مهمة عشوائية إلى طبقة بنية تحتية منظمة وقابلة للتدقيق. 

1. مصدر واحد للحقيقة (السجل)

يوفر TrueFoundry سجلًا مركزيًا للمطالبات. لا مزيد من البحث في مستندات Google أو قواعد التعليمات البرمجية. كل مطالبة، لكل حالة استخدام، توجد في مكان واحد آمن ويمكن الوصول إليه.

‍

2. فصل المطالبات عن التعليمات البرمجية

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

هذا يعني أن مدير المنتج يمكنه تكرار العمل على مطالبة، واختبارها ضمن بيئة TrueFoundry التجريبية، و"ترقيتها" إلى مرحلة الإنتاج دون أن يحتاج مهندس إلى لمس رمز التطبيق أو تشغيل إعادة نشر.

3. سير العمل المنظم

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

4. التقييم المدمج مع الإدارة

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

لمزيد من المعلومات، يرجى زيارة https://www.truefoundry.com/docs/ai-gateway/prompt-management

خاتمة: منهجية هندسية للذكاء الاصطناعي

بالعودة إلى قصتنا، قام جيسون بتطبيق TrueFoundry. تمت أرشفة مستندات جوجل. وتم استبدال السلاسل المبرمجة باستدعاءات SDK.

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

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