سلسلة المسرعات: بناء كاشط ويب مرن باستخدام LangGraph و TrueFoundry

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

عليهم فعل هذا 200 مرة.

بالنسبة للمهندسين، يؤدي هذا الطلب عادةً إلى نص برمجي سريع بلغة بايثون باستخدام Selenium أو BeautifulSoup. تقوم بفحص مصدر الصفحة، وتجد العنصر div الذي يحمل الفئة speaker-name، وتستخرج النص. يعمل بشكل مثالي لمدة أسبوع تقريبًا. ثم يقوم الموقع بتحديث إطار عمل الواجهة الأمامية الخاص به، وتتغير فئات CSS، ويتعطل النص البرمجي.

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

إليك كيف صممنا الحل باستخدام LangGraph للتنسيق، و Playwright للتفاعل، و TrueFoundry لإدارة البنية التحتية.

التحول: من محددات DOM إلى الاستخلاص الدلالي

السبب الرئيسي لفشل نصوص الاستخلاص البرمجية هو اعتمادها على نموذج كائن المستند (DOM). إذا طلبت من نص برمجي البحث عن div.content-wrapper > h2.title، فسوف يتعطل في اللحظة التي يغير فيها المطور اسم الفئة.

انتقلنا إلى نهج يعتمد على الوكلاء. لا نخبر الروبوت أين مكان وجود البيانات بالبكسل. بدلاً من ذلك، نُدخل HTML المعروض (المحول إلى Markdown) إلى نموذج لغة كبير (LLM). يقرأ النموذج النص تمامًا كما يفعل الإنسان. إنه يفهم أن قسمًا يحمل عنوان "المتحدثون الرئيسيون" يحتوي على البيانات التي نريدها، بغض النظر عن العلامات الأساسية.

• الطريقة القديمة (هشة): محددات CSS مبرمجة بشكل ثابت تتعطل عند تحديثات واجهة المستخدم.
• الطريقة الجديدة (مرنة): فهم دلالي يتكيف مع تغييرات التخطيط.

نظرة معمقة على البنية

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

اخترنا LangGraph لنمذجة سير العمل هذا كآلة حالات، خاصة عندما Langflow مقابل LangGraph تميل القرارات إلى التنسيق ذي الحالة.

سير المنطق

يعمل النظام في حلقة تكرارية بدلاً من مسار خطي:

1. موجّه الإدخال: يتحقق النظام مما إذا كان المستخدم قد قدم رابطًا مباشرًا (URL) أو مجرد اسم شركة. إذا كان اسمًا، فإنه يستخدم أداة بحث للعثور على النطاق الصحيح أولاً.
2. التنقل الخفي: نستخدم نسخة معدلة من Playwright لتحميل الصفحة. تتولى معالجة لافتات الموافقة على ملفات تعريف الارتباط وصور التحميل الكسول تلقائيًا.
3. تصفية المتجهات (التحسين): قد تحتوي صفحة مؤتمر واحدة على 200 رابط تنقل. تغذية كل هذه الروابط إلى نافذة سياق نموذج اللغة الكبير (LLM) بطيء ومكلف. نستخدم FastEmbed لتضمين نص الرابط والاستعلام من مثيل Qdrant محلي. هذا يقوم بتصفية القائمة لتقتصر على أفضل 10 روابط ذات صلة بـ "الفريق" أو "المتحدثين".
4. الاستخراج: يقوم LLM بتحليل المحتوى المصفى ويستخرج الكيانات المهيكلة (الاسم، الدور، الشركة).
5. الإثراء: أخيرًا، نمر عبر الأسماء المستخرجة ونستخدم أداة بحث (Tavily) للعثور على ملفاتهم الشخصية المحددة على LinkedIn.

فيما يلي بنية النظام:

‍

البنية التحتية وتكامل TrueFoundry

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

لقد قمنا بنشر هذا على TrueFoundry للتعامل مع هذه القيود المحددة.

1. بوابة الذكاء الاصطناعي (الرصد والتخزين المؤقت)

يستخدم هذا التطبيق نماذج اللغة الكبيرة (LLMs) بكثافة لاتخاذ قرارات التنقل. بدون حوكمة، تتصاعد التكاليف بسرعة. نوجه جميع استدعاءات النموذج عبر TrueFoundry AI Gateway.

• التخزين المؤقت: إذا قام الوكيل بجمع البيانات من نفس الموقع مرتين، فإن البوابة تقدم استجابات LLM المخزنة مؤقتًا لخطوات الاستخراج. وهذا يقلل بشكل كبير من زمن الاستجابة والتكلفة.
• تحديد المعدل: نضع قيودًا صارمة لكل مستخدم لمنع استنزاف حصة واجهة برمجة التطبيقات (API) أثناء مهام الدفعات الكبيرة.
• تجاوز الفشل: إذا واجهت OpenAI فترة توقف، فإن البوابة تعيد توجيه الطلبات تلقائيًا إلى Anthropic أو Azure OpenAI دون فشل عملية الزحف.

2. بروتوكول سياق النموذج (MCP)

لقد هيكلنا التطبيق باستخدام بروتوكول سياق النموذج (MCP). "الزاحف" ليس مجرد دالة بايثون؛ إنه خادم MCP. يتيح لنا ذلك عزل بيئة المتصفح. إذا تعطل المتصفح (وهو ما يحدث غالبًا مع المواقع كثيفة الاستخدام لجافاسكريبت)، فإنه لا يؤثر على منطق التطبيق الرئيسي.

مخطط البنية التحتية

مقارنة: نص برمجي مقابل وكيل

قمنا بتقييم نهج النص البرمجي القياسي في بايثون مقابل هذه البنية.

معالجة الحالات الهامشية

بناء المسار الطبيعي سهل. لكن جعلها موثوقة تطلب حل ثلاث مشكلات هندسية محددة:

1. البيانات المكررة: غالبًا ما تظهر الملفات الشخصية في صفحات متعددة (مثل "القيادة" و"من نحن" على حد سواء). أضفنا عقدة إزالة التكرار في نهاية الرسم البياني. تمرر القائمة الكاملة إلى نموذج لغوي كبير (LLM) أصغر وأقل تكلفة لدمج السجلات بناءً على تشابه الأسماء قبل الإثراء.
2. كشف الروبوتات: يتم اكتشاف Playwright القياسي بسهولة بواسطة جدران الحماية الحديثة لتطبيقات الويب (WAFs). قمنا بتطبيق undetected-playwright داخل حاوية Docker، والذي يقوم بتعديل بصمة المتصفح (كائن Navigator، بائع WebGL) ليظهر كجهاز مستخدم عادي.
3. حدود الرموز: الصفحات الكبيرة التي تحتوي على سياسات الخصوصية والتذييلات تهدر الرموز. نستخدم التقطيع المستند إلى الرؤوس لتقسيم الماركداون. يعالج النموذج اللغوي الكبير (LLM) فقط الأجزاء المتعلقة بـ "الفريق" أو "المتحدثين"، متجاهلاً الباقي.

الخلاصة

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

يمكنك نشر هذه البنية الدقيقة -- بما في ذلك تكوين البوابة والوكلاء المعبأة في Docker -- من مكتبة تطبيقات TrueFoundry اليوم.

‍