LangSmith تطلق AI Search: البحث في تتبعات الوكلاء عبر وصف سلوكها

أضافت LangChain إلى LangSmith وضع AI Search، ما يتيح البحث في التتبعات بلغة عادية. يصف المطوّر السلوك الذي يبحث عنه، فتعيد المنصة عمليات التشغيل التي حدث فيها. صدر الإعلان في 13 أكتوبر 2026، وهو قصير: يعرض الفكرة لكنه لا يسمّي النموذج ولا يذكر الحدود ولا السعر. ومع ذلك تمسّ الفكرة مشكلة قديمة لدى كل من يشغّل الوكلاء في بيئة الإنتاج.

ما الذي أُطلق بالضبط

LangSmith منصة للمراقبة والتقييم من مطوّري LangChain. يُسجَّل كل تشغيل للوكيل بوصفه تتبعًا (trace): سلسلة من استدعاءات النموذج والأدوات والاستدلالات الوسيطة والإجابات. وحين يعمل الوكيل منذ أكثر من يوم، تتراكم آلاف التتبعات من هذا النوع.

كان البحث فيها حتى الآن يجري عبر حقول منظمة: الحالة، والمدة، والوسوم، واسم الأداة، والتكلفة. وهذا ينجح إذا كنت تعرف مسبقًا أي سمة تبحث عنها. أما AI Search فيغيّر مدخل البحث. فبدلًا من مجموعة شروط، تكتب عبارة مثل «المستخدم منزعج من الإجابة» أو «الوكيل يستدعي الأداة نفسها مرارًا». ويحدد النظام بنفسه أي التتبعات تطابق هذا الوصف.

أبرز الحقائق من الإعلان:

• صيغة الاستعلام: لغة طبيعية، دون صيغة خاصة.
• معيار البحث: سلوك الوكيل، لا قيم الحقول.
• النتيجة: مجموعة تتبعات وقع فيها هذا السلوك.
• تاريخ الإعلان: 13 أكتوبر 2026، مدونة LangChain.
• لم يُكشف عنه: النموذج المستخدم لتفسير الاستعلامات، والحدود، والسعر، ولغات الاستعلام المدعومة.

لماذا يحتاج الوكلاء تحديدًا إلى البحث بالسلوك

يظهر عطل الخدمة التقليدية على شكل خطأ 500 أو ارتفاع مفاجئ في زمن الاستجابة. أما الوكيل فيفشل بطريقة أدق. فقد ينهي المهمة شكليًا، ومع ذلك ينفّذ عشرة استدعاءات زائدة، أو يتجاهل تعليمة في موجّه النظام، أو يختلق بيانات بثقة. وستكون حالة مثل هذا التتبع «ناجح»، ولن يُظهره الفلتر القائم على الحالة.

لذلك يضطر الفريق إلى قراءة عيّنات من التتبعات يدويًا، أو كتابة مقيِّمات منفصلة لكل نوع من المشكلات. أما البحث بالوصف فيغيّر ترتيب العمل. تبدأ بصياغة فرضية («يبدو أن الوكيل يرتبك حين يغيّر المستخدم الشروط في منتصف الحوار»)، ثم ترى الأمثلة فورًا. ومن الأمثلة الجيدة يمكن لاحقًا بناء مجموعة اختبار أو مقيِّم.

وهذه خطوة منطقية من LangChain. فمنافسوها في مراقبة LLM، من Langfuse إلى Arize وBraintrust، يتجهون بدورهم إلى التحليل الدلالي للتتبعات. والمنتج الذي يعيش على بيانات ما فعله الوكلاء يضيف بطبيعة الحال طبقة تتيح استجواب هذه البيانات.

ما الذي يبقى سؤالًا مفتوحًا

يتعذر من نص الإعلان معرفة عدة أمور، وعليها تتوقف القيمة الفعلية للميزة.

الأول هو الدقة. فقد يفوّت البحث الدلالي في تتبعات طويلة ذات استدعاءات متداخلة ما هو مطلوب، أو يأتي بنتائج مشوِّشة. ولم تُنشر بعد أي إجابة عن نسبة الحالات الفائتة.

الثاني هو النطاق. فليس معروفًا هل يبحث النظام في المشروع كله أم في نافذة زمنية محددة، ولا كم يكلّف ذلك بالرموز (tokens).

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

كيف تستخدمها عمليًا

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

صُغ الاستعلامات عبر الفعل الملحوظ لا عبر التقييم: «الوكيل استدعى البحث أكثر من ثلاث مرات متتالية» أكثر موثوقية من «الوكيل عمل بشكل سيئ». ومن الأفضل حفظ التتبعات التي تجدها في مجموعة بيانات لاختبارات الانحدار، كي يتحول ما عثرت عليه مرة واحدة إلى فحص دائم.

وأخيرًا: ما دامت LangChain لم تنشر أرقامًا عن الجودة والتكلفة، فتعامل مع AI Search بوصفه وسيلة سريعة للاستطلاع، لا مصدرًا وحيدًا للحقيقة عن سلوك الوكيل. ويظل الأفضل تغطية السيناريوهات الحرجة بمقيِّمات ومقاييس صريحة.