مهندس يبني خدمة RAG محلية لوثائق واجهات CAD API وينشر تجربته على Habr

نشر مهندس على Habr شرحًا لكيفية بنائه خدمة RAG محلية للعمل مع وثائق واجهات برمجة التطبيقات (API) في أنظمة التصميم بمساعدة الحاسوب (CAD)، معلّلًا ذلك بالضغط الذي يمارسه العملاء على الشركات الهندسية عبر تقليص ميزانيات المشاريع ومددها.

لماذا أصبحت وثائق CAD مرشحة للأتمتة

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

• المؤلف مهندس بنى بنفسه خدمة RAG محلية لواجهات CAD API
• سبب المشروع: عمليات تصميم روتينية يمكن تفويضها إلى السكربتات
• السياق العام: تقليص العملاء للميزانيات والمواعيد في الخدمات الهندسية

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

ما الذي تقدمه RAG المحلية في هذا السيناريو

RAG (توليد معزَّز بالاسترجاع، retrieval-augmented generation) نهج يبحث فيه النموذج قبل الإجابة عن مقاطع ذات صلة في قاعدة وثائقه الخاصة، بدل الاعتماد فقط على ما حفظه أثناء التدريب. وهذا مناسب بصورة خاصة لوثائق CAD API، لأن هذه الواجهات كثيرًا ما تُوصف في أدلة ضخمة ومتفرقة تُحدَّث باستمرار. أما النشر المحلي فيتيح إبقاء البيانات الهندسية الحساسة والوثائق الملكية داخل نطاق الشركة، دون إرسالها إلى خدمات سحابية خارجية.

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

ما الصعوبات التي تواجه مشاريع كهذه عادةً

تشكّل وثائق API التقنية مادة غير مريحة لمسار RAG التقليدي: ففيها جداول كثيرة للمعاملات، وإحالات إلى أقسام أخرى، وملاحظات خاصة بالإصدارات، ومصطلحات محددة بمنصة CAD بعينها يصعب تقسيمها إلى مقاطع (chunks) بالطرق القياسية. ويضطر مطورو هذه الخدمات عادةً إلى التفكير بصورة منفصلة في تقسيم الوثائق إلى وحدات ذات معنى، وتحديث الفهرس عند صدور إصدار جديد من API، والتحقق من أن النموذج لا يخلط بين أساليب متشابهة في الاسم ومختلفة في السلوك. وهذا عمل يدوي مضنٍ لا يظهر عادةً في النتيجة النهائية، لكنه يستهلك جزءًا كبيرًا من وقت المشروع.

ماذا يعني ذلك

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