مطوّر يفتح نواة وكيل للبحث عن العملاء في المشتريات مع 726 اختباراً

نشرت شركة مناقصة لشراء خوادم، أي أن لدى البائع سبباً لبدء حديث. لكن بين إشعار المناقصة ومكالمة مفيدة عملاً يدوياً: فتح المواصفات الفنية، وفهم المعدات، والاطلاع على التقارير المالية للجهة المشتريّة، وإيجاد شخص يمكن الاتصال به. يروي مؤلف AI Tender Radar كيف أسند هذا التحضير إلى وكيل ذكاء اصطناعي، ونشر النواة البحثية للمشروع على GitHub.

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

من المواصفات الفنية إلى بطاقة ما قبل المكالمة

يجمع البرنامج المناقصات الحكومية والتجارية لشراء الخوادم وأنظمة تخزين البيانات والمكوّنات، وينزّل الوثائق ويستخرج منها النص. وتُدعم صيغ PDF وDOCX وDOC وXLSX وTXT والأرشيفات ZIP و7z. أما المسوح الضوئية التي لا تحتوي على طبقة نصية، وملفات RAR، وXLS القديمة، فلا تزال ثغرات في البيانات.

لنفترض أن عنوان المناقصة يقول فقط «توريد معدات». هذا لا يكفي المسؤول التجاري. على الوكيل أن يفتح الملاحق ويحدد مكوّنات التوريد وكمياته ومواعيده، ثم يجد جهة اتصال لدى الجهة المشتريّة. ويحصل على بيانات الإيرادات والأرباح ورأس المال من آخر تقارير منشورة لدى مصلحة الضرائب الروسية (FNS). يساعد ذلك في التحضير للحديث، لكنه لا يجيب بحد ذاته عن سؤال: هل ستدفع الشركة ثمن توريد بعينه؟

تحتوي البطاقة على زرّي «قيد العمل» و«تجاوز»، ويمكن ترك ملاحظة عليها. وتُصدَّر العملاء المحتملون إلى Excel. ولا يتواصل الوكيل مع الجهة المشتريّة من تلقاء نفسه ولا يَعِد بشروط توريد، لأنه لا يعرف أسعار البائع ولا إمكاناته.

الوكيل يختار المسار والكود يتحقق من جهات الاتصال

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

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

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

ثم يمنح النظام البطاقة فئة: A — عُثر على شخص مع هاتف، B — هاتف دون اسم أو جهة اتصال من دليل خارجي، C — لا يوجد هاتف. ولا تُرسل إلى المسؤول التجاري إلا الفئتان الأوليان. وإذا لم يجد الوكيل شخصاً مع رقم، تُحال المناقصة إلى نموذج احتياطي.

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

ما يمكن نقله إلى منتجك

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

تكمن القيمة العملية لهذه الحالة في توزيع المسؤولية. فالنموذج يحلّل وثائق متباينة ويختار مسار البحث، بينما يحدّ البرنامج من النفقات ويتحقق من المعلومات قبل الإرسال. وجرت معالجة التكرارات وانتظار الوثائق وردود Telegram الملتبسة كلٌّ على حدة، فمثل هذه التفاصيل هي التي تحدد راحة العمل اليومي.

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