تتبع LLM عند بوابة الذكاء الاصطناعي: شاهد كل استدعاء للنموذج

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

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

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

ما الذي يجب أن يلتقطه تتبع LLM

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

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

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

لماذا تعتبر البوابة أفضل مكان للبدء

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

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

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

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

تتبع LLM عند بوابة الذكاء الاصطناعي يدعم التقييم.

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

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

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

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

استخدم المعايير حيثما تفيد. لا تحتاج الفرق إلى اختراع صيغة تتبع خاصة إذا كانت إشارة معيارية تعمل بالفعل. تتبع OpenTelemetry.

مصمم لتمثيل العمل كامتدادات متصلة، مما يجعله مناسبًا لطلبات الذكاء الاصطناعي المعقدة التي تمر عبر عدة خدمات.

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

كن حذرًا مع بيانات الطلب والاستجابة

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

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

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

قائمة تحقق عملية لتتبع LLM

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

أين يناسب ShareAI

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

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

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