لقد اجتاز اختبارك يوم الاثنين. نفس الإدخال، نفس الكود، temperature=0. يوم الثلاثاء فشل، ولم تغير أنت شيئًا. فحص التأكيد سلسلة نصية مطابقة تمامًا، وأعاد النموذج نفس الإجابة بصياغة مختلفة قليلاً. الاختبار أحمر، الوكيل جيد، والآن أنت تقوم بتصحيح أخطاء مجموعة الاختبار الخاصة بك بدلاً من منتجك.
هذه هي ضريبة اختبار أي شيء يستدعي نموذج لغة. يتغير الإخراج، حتى عندما طلبت منه ألا يتغير. اضبط درجة الحرارة على صفر ولن تحصل على استجابات متطابقة بالبايت عبر عمليات التشغيل. يتعلم معظم المطورين هذا بالطريقة الصعبة، مرة واحدة، ثم يعيدون كتابة كيفية اختبارهم. يرشدك هذا الدليل إلى كيفية كتابة تأكيدات تصمد عندما يستمر النص الموجود أسفلها في التحول. إنه الغوص العميق في وضع الفشل الثالث من دليلنا حول لماذا تفشل وكلاء الذكاء الاصطناعي في الإنتاج.
لماذا لا تعني temperature=0 حتمية
تتحكم درجة الحرارة في كيفية أخذ النموذج للرمز التالي. عند الصفر، يأخذ الرمز الأكثر احتمالاً في كل مرة، وهو ما يبدو وكأنه يجب أن يكون قابلاً للتكرار. ولكنه ليس كذلك، والأسباب تكمن تحت النموذج.
حسابات الفاصلة العائمة ليست ترابطية على وحدة معالجة الرسوميات (GPU). إذا جمعت نفس الأرقام بترتيب مختلف، فستحصل على نتيجة مختلفة قليلاً في آخر منزلة عشرية. هذا الاختلاف الصغير يمكن أن يغير ترتيب الرموز الأكثر احتمالاً، وتغيير رمز واحد يغير كل شيء بعده. يعتمد ترتيب هذه العمليات الحسابية على كيفية تجميع الموفر لطلبك مع حركة المرور الأخرى، وأي جهاز يقوم بتشغيله، وأي إصدار نواة (kernel) يتم نشره في ذلك اليوم. أنت لا تتحكم في أي من ذلك.
يغير المزودون أيضًا أشياءً من جانبهم. فهم يبدلون وحدات معالجة الرسوميات، ويحدثون مكتبات الاستدلال، ويعيدون تحديد كمية الأوزان، ويوجهون مكالمتك إلى منطقة مختلفة. يناقش نقاش طويل حول vLLM سبب عدم كفاية البذور الثابتة و temperature=0 لتحقيق قابلية التكرار على مستوى البتات. الخلاصة: الحتمية هي خاصية للمكدس الخدمي بأكمله، وليست علامة تضبطها في طلبك.
لذا توقف عن اعتبار المخرجات المتطابقة هي الأساس. يمنحك النموذج إجابة تعني نفس الشيء، مهما كانت صياغتها في هذا التشغيل. يجب أن تقبل اختباراتك ذلك.
تأكيدات السلاسل النصية الدقيقة تجعل مجموعتك غير مستقرة
إليك الفخ. تكتب assert response == "Your order total is $42.00." لأن هذا ما عاد في المرة الأولى. ينجح الاختبار. ثم يعيد النموذج "Your total comes to $42.00" ويفشل الاختبار على إجابة صحيحة.
الاختبار الذي يفشل على إجابة صحيحة أسوأ من عدم وجود اختبار على الإطلاق. يتعلم الفريق أن هذه المجموعة تصرخ كذبًا. يعيد الناس تشغيلها حتى تصبح خضراء، ثم يتوقفون عن قراءة الإخفاقات، ثم يفوتهم التراجع الحقيقي المدفون في الضوضاء. الاختبارات المتقلبة لا تضيع الوقت فحسب، بل تقوض الثقة في المجموعة بأكملها، وقد كتبنا من قبل عن أسباب الاختبارات المتقلبة ولماذا تنتشر. الإخراج غير الحتمي هو أحد أسرع الطرق لتصنيعها.
الغريزة هي تثبيت المخرجات بشكل أقوى: التقاط السلسلة الدقيقة، أخذ لقطة لها، مقارنتها. هذا يجعل التقلقل أسوأ، لأنك ربطت اختبارك بالشيء الوحيد المضمون للتغيير. أنت بحاجة إلى الخطوة المعاكسة.
أكّد على البنية والمعنى، وليس النص الدقيق
يتغير الإخراج، لكن العقد الكامن وراءه يجب ألا يتغير. قد يصيغ وكيل الدعم تأكيد استرداد الأموال بمائة طريقة، لكن كل استجابة صالحة تحمل نفس الحقائق: مبلغ استرداد، ومعرف طلب، وحالة. اختبر الحقائق، وليس الصياغة.
هذا هو التحول الكامل. توقف عن السؤال "هل قال النموذج هذا بالضبط" وابدأ في السؤال "هل الاستجابة لها الشكل الصحيح، والحقول الصحيحة، والقيم ضمن النطاق الصحيح". هذه الخصائص تنجو من إعادة الصياغة. لا يزال الانحدار الحقيقي، أو الحقل المفقود، أو الرقم خارج النطاق، أو الحمولة غير المشكلة، يؤدي إلى فشل التأكيد. إليك الاستراتيجيات التي تطبق هذا عمليًا.
تحقق من الاستجابة مقابل مخطط JSON
إذا كان وكيلك يعيد بيانات مهيكلة، حدد مخطط JSON لها وتحقق من صحة كل استجابة مقابل هذا المخطط. يفحص المخطط الأنواع، الحقول المطلوبة، التعدادات المسموح بها، والتنسيقات دون الاهتمام بالقيم المحددة. يجب أن يكون حقل status أحد القيم refunded أو pending أو denied. يجب أن يتطابق order_id مع نمط معرفك. يجب أن يكون amount رقمًا، وليس سلسلة نصية.
هذا هو أقوى تأكيد فردي يمكنك كتابته ضد استجابة غير حتمية، لأنه يلتقط الإخفاقات التي تضر: النموذج أسقط حقلاً، أو قام بتضمين الكائن بشكل خاطئ، أو أعاد نصًا حيث كنت تتوقع JSON. قم بتحميل مخطط استجابتك إلى Apidog وتحقق من صحة استجابات الوكيل الحية مقابلها. يشير عدم التطابق إلى الحقل المحدد الذي حدث فيه الخطأ، وليس اختلافًا في سلسلة نصية مكونة من 400 حرف.
أكد أن استدعاء الأداة له الشكل والهدف الصحيحين
عندما يقرر وكيلك استدعاء أداة، اختبر الاستدعاء، وليس الجملة التي أدت إليه. أكد على ثلاثة أشياء: لقد اختار الأداة الصحيحة، ووجهها إلى الهدف الصحيح، وتطابق الحمولة مع مخطط الأداة. يجب على وكيل حجز يستدعي POST /reservations إرسال guests كرقم صحيح و date صالحة، بغض النظر عن الاستدلال باللغة الطبيعية الذي أنتج هذا الاستدعاء.
هذا هو نفس الانضباط المتبع في التحقق من صحة جسم الاستجابة، المطبق على الطلب الصادر. تحقق من وجود المعلمات المطلوبة، وأن الأنواع صحيحة، وأنه لم تتسلل أي حقول مخترعة. تغطي الطريقة الشاملة لاختبار استدعاءات API لوكيل الذكاء الاصطناعي كيفية التقاط مخططات هذه الأدوات والتأكيد عليها. تحتوي حمولة استدعاء الأداة على عقد حتى عندما لا تحتوي الصياغة المحيطة بها على عقد.
استخدم النطاقات الرقمية بدلاً من القيم الدقيقة
بالنسبة لأي رقم ينتجه النموذج أو يمرره، أكد نطاقًا، وليس قيمة. يحسب وكيل سلة التسوق إجماليًا. لا تعرف الرقم الدقيق عبر كل عملية تشغيل، وعربة، وقاعدة ضريبية، لكنك تعلم أنه لا يمكن أن يكون سالبًا ولا يمكن أن يتجاوز قيمة العربة بالإضافة إلى الحد الأقصى للشحن والضرائب. لذا أكد ذلك: يحتوي الرد على total بين 0 وهذا السقف.
هذا الحد الواحد يلتقط الإخفاقات الهامة، مثل إجمالي سالب، أو إجمالي أكبر بعشر مرات، أو إجمالي صفر لعربة مليئة، مع تجاهل التباين الذي لا يهمك. تعمل النطاقات لدرجات الثقة، وعدد العناصر، واستخدام الرمز، وميزانيات الكمون، وأي رقم مشتق. اختر أوسع حد لا يزال يفشل في حالة وجود خطأ حقيقي.
تحقق من وجود المفاتيح المطلوبة وعدم وجود الحقول المحظورة
اثنان من التأكيدات الرخيصة يحملان الكثير من الوزن. أولاً، المفاتيح التي تعتمد عليها موجودة وغير فارغة. ثانياً، المفاتيح التي يجب ألا تظهر أبدًا غير موجودة. يجب على الوكيل الذي يتعامل مع تذكرة دعم أن يعيد resolution، ويجب ألا يسرب أبدًا حقلاً مثل internal_notes أو raw_prompt إلى العميل.
تعتبر فحوصات الوجود والغياب محصنة ضد إعادة الصياغة بطبيعتها، لأنها تختبر هيكل الاستجابة، وليس محتواها. كما أنها أرخص حماية لك ضد فئة كاملة من تسرب البيانات الخاصة، حيث يقوم النموذج بتضمين حقل كان يجب أن يظل خاصًا به بشكل مفيد.
استخدم الفحوصات الدلالية وفحوصات العتبة للنصوص الحرة
أحيانًا تكون الحمولة نصًا نثريًا ولا يزال يتعين عليك اختباره. لن يعمل التطابق الدقيق، لذا تحقق من الخصائص بدلاً من ذلك. هل يحتوي الرد على رقم الطلب الذي مررته؟ هل يبقى تحت حد الطول؟ هل يتجنب قائمة الكلمات المحظورة التي لا تريد إرسالها إلى المستخدم أبدًا؟
عندما تحتاج حقًا إلى اختبار المعنى، قارن عن طريق تشابه التضمين (embedding similarity) مع إجابة مرجعية وأكد أن النتيجة تتجاوز عتبة معينة، بدلاً من المطالبة بتطابق السلاسل النصية. تعامل مع هذه الفحوصات الدلالية كبوابة تقريبية، وليست دقيقة. إنها تلتقط الاستجابة التي انحرفت عن الموضوع. لن تلتقط خطأً واقعيًا دقيقًا، لذا قم بإقرانها بالتأكيدات الهيكلية المذكورة أعلاه.
نطاقات اللقطات، وليس لقطات دقيقة
لا يزال للاختبار باللقطات مكان، طالما أنك تقوم بتصوير الأجزاء المستقرة. قم بتجميد شكل الاستجابة، ومجموعة المفاتيح، والأنواع، وقيم التعداد، واسمح للحقول المتغيرة بحرية ضمن الحدود. في الممارسة العملية، تسجل لقطتك "تحتوي هذه الاستجابة على مفاتيح a و b و c، مع b ضمن هذا النطاق و c من هذه المجموعة" بدلاً من كتلة مجمدة من النص الدقيق. عندما تتعطل اللقطة، فإنها تتعطل بسبب تغيير هيكلي يستحق المراجعة، وليس بسبب مرادف.
الحالة والذاكرة تجعل هذا أصعب
كل ما سبق يفترض طلبًا واحدًا، واستجابة واحدة. الوكلاء لا يعملون بهذه الطريقة. فهم يحملون ذاكرة عبر الدورات، وتضاعف هذه الحالة مصادر الاختلاف.
تعتمد إجابة الوكيل ذي الحالة على ما استرجعه، وما خزنه سابقًا، والترتيب الذي سارت عليه الدورات السابقة. يمكن أن يتباعد تشغيلان لنفس المحادثة لأن خطوة الاسترجاع صنفت المستندات بشكل مختلف، أو لأن ملخصًا مكتوبًا في الدورة الثانية شكل الاستدلال في الدورة الخامسة. الآن تختلف مخرجاتك لسببين مركبين: عدم حتمية النموذج نفسه، وحالة بدء مختلفة. يشرح مقالنا حول كيف تعمل ذاكرة وكيل الذكاء الاصطناعي أين توجد هذه الحالة وكيف يتم بناؤها.
هناك عادتان تجعلان هذا قابلاً للاختبار. أولاً، تحكم في الحالة التي يمكنك التحكم فيها. قم بتهيئة ذاكرة الوكيل إلى نقطة بداية معروفة قبل كل اختبار، حتى يتغير شيء واحد وليس شيئين. ثانيًا، أكد على الثوابت التي تصمد بغض النظر عن المسار. يجب ألا يصبح الرصيد الجاري سالبًا أبدًا. يجب أن تنتهي المحادثة التي حجزت رحلة طيران واحدة بحجز واحد بالضبط، بغض النظر عن عدد الدورات التي استغرقتها. التأكيدات المستقلة عن المسار هي التي تنجو من وكيل ذي حالة وغير حتمي.
قم بمحاكاة التبعيات لكي يتكرر الاختبار
لا يمكنك ممارسة أي من هذا على واجهات برمجة التطبيقات (APIs) الحية التابعة لجهات خارجية. فهي تحد من معدل طلباتك، وتغير بياناتها، وتضيف مصدرًا ثانيًا للعشوائية علاوة على النموذج. للحصول على اختبار قابل للتكرار، ثبت كل شيء ليس هو السلوك الذي تختبره.
قم بمحاكاة واجهات برمجة التطبيقات التي يستدعيها الوكيل وبرمجة استجابات ثابتة. الآن، تعيد واجهة برمجة تطبيقات الدفع دائمًا نفس الإيصال، وتعيد واجهة برمجة تطبيقات البحث دائمًا نفس النتائج الثلاثة، والشيء الوحيد الذي لا يزال يتحرك هو منطق الوكيل نفسه، وهذا هو ما تريد ملاحظته. تتيح لك التبعية المزيفة أيضًا فرض حالات الحافة التي لن تنتجها واجهة برمجة تطبيقات صحية عند الطلب، ثم التأكيد على أن الوكيل يتعامل معها. وجه Apidog إلى تبعيات الوكيل لإعداد هذه المحاكاة بأجسام ثابتة وقابلة للتحكم، وقم بإقرانها بتأكيدات المخطط المذكورة أعلاه. يندرج هذا ضمن الممارسة الأوسع لـ اختبار وكلاء الذكاء الاصطناعي، حيث تعمل المحاكاة والتأكيد معًا.
أين يتناسب Apidog (وأين لا يتناسب)
كن دقيقاً بشأن مهمة الأداة. Apidog هو منصة لتصميم واجهة برمجة التطبيقات (API)، واختبارها، ومحاكاتها. إنه ليس إطار عمل لوكيل، أو مضيف نموذج، أو بيئة تشغيل وكيل، أو منصة تقييم ومراقبة. لا يقوم ببناء وكيلك، أو تشغيله، أو تنسيق خطواته، أو تقييم منطقه.
ما يملكه هو طبقة واجهة برمجة التطبيقات التي يتحدث إليها وكيلك، وهذا هو المكان الذي تعيش فيه هذه الاختبارات. حالتان صادقتان. تقوم بكتابة تأكيدات على استجابات API للوكيل (التحقق من صحة المخطط، شكل الاستجابة، النطاقات الرقمية، المفاتيح المطلوبة والمحظورة، شكل حمولة استدعاء الأداة) التي تصمد أمام الإخراج غير الحتمي. وتقوم بمحاكاة تبعيات الوكيل بحيث يتم تشغيل الاختبار بنفس الطريقة مرتين. هذا هو الشق الذي يملأه Apidog: العقد على الطلبات والاستجابات، وليس النموذج الذي ينتجها.
اختبر العقد، وليس الصياغة
عدم الحتمية ليست خطأ يمكنك التخلص منه بالتهيئة. إنها خاصية لتشغيل نموذج لغوي، و temperature=0 لا يوقفها. توقفت الفرق التي تشحن وكلاء موثوقين عن محاربتها. يختبرون الأشياء الثابتة، مثل المخطط، والشكل، والنطاقات، والحقول المطلوبة، ويتركون الصياغة تتحرك. افعل ذلك وستصبح مجموعتك هادئة بطريقة جيدة: تبقى خضراء بينما يتغير النص، وتتحول إلى اللون الأحمر فقط عندما يكون هناك شيء معطل.
اختر تأكيدًا متقلبًا واحدًا في مجموعتك هذا الأسبوع وأعد كتابته كتحقق من المخطط والنطاق. قم بتنزيل Apidog للتحقق من صحة استجابات وكيلك مقابل عقد ومحاكاة التبعيات التي تجعل الاختبارات قابلة للتكرار.