انتقل إلى المحتوى الرئيسي
Fugen Services logo

الذكاء الاصطناعي والأتمتة

وكلاء ينفذون المهام ضمن الحدود التي تحددها

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

مؤشر

ابتداءً من £15,000

السعر الثابت متفق عليه كتابة قبل بدء أي عملية تطوير.

اطلب عرض سعر+44 7488 265083

المشكلة التي يحلها

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

ماذا ستحصل

أدوات ذات نطاق ضيق وواضح

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

أبواب الموافقة على الإجراءات غير القابلة للعكس

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

حدود الحلقات والتكلفة

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

مسار تدقيق كامل

تسجيل كل خطوة: ما طُلب منه، وما قرره، والأداة التي استدعاها، وما هي الحجج، وما جاء الرد. بدون هذا المسار، يصبح الوكيل غير قابل للتدقيق، مما يجعله غير صالح لمعظم الأعمال المنظمة.

التقييم قبل النشر

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

الفشل بسلاسة

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

كيف نعمل

  1. تحديد الوظيفة بدقة

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

  2. تصميم سطح الأدوات

    الحد الأدنى من الأدوات، لكل منها الحد الأدنى من الصلاحيات. يتم مراجعتها قبل البناء.

  3. بناء مجموعة التقييم

    مهام حقيقية ذات نتائج معروفة، تُكتب قبل وجود الوكيل.

  4. البناء مع سجل التدقيق أولاً

    لا تُضاف قابلية الملاحظة (Observability) لاحقاً إلى الوكيل — فلا يمكنك تصحيحه بدونها.

  5. الوضع الظلي

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

  6. توسيع الاستقلالية بحذر

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

ما يجب أن تتوقعه

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

مبني باستخدام

  • Mistral
  • أنثروبيك كلود
  • أوبن إيه آي
  • TypeScript
  • بايثون
  • PostgreSQL
  • pgvector
  • ريديس
  • تيبوريال
  • RabbitMQ
  • بروتوكول سياق النموذج
  • لانغراف

Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.

تطوير وكلاء الذكاء الاصطناعي — your questions

بما في ذلك الأسئلة المتعلقة بالتكلفة، والتي تتجاهلها معظم الشركات في صفحاتها.

يكلف الوكيل ذو الغرض الواحد بثلاثة أو أربعة أدوات وأبواب موافقة وسجل تدقيق عادةً ما بين £15,000 إلى £35,000. تختلف التكاليف التشغيلية حسب الحجم ولكنها عادة ما تكون modest — فالتكلفة الأكبر هي في الهندسة المحيطة بالنموذج، وليس في النموذج نفسه.

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

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

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

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

أيهما يتفوق في مجموعة تقييمك، خلف واجهة قابلة للتغيير. في الممارسة، نستخدم غالبًا موديلات مِسترال أو كلود لأداء المهام. المهم هو أن الاختيار يقاس بناءً على مهامك ويمكن عكسه، لأن ترتيب الصدارة يتغير كل بضعة أشهر.

تحدث إلى من سبق له بناء هذا

A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.