ملف العميل
يعمل الفريق ضمن شركة استشارات في الهندسة المعمارية البحرية والهندسة البحرية تخدم مشغلي ناقلات المواد الكيميائية، وأحواض بناء السفن، وهيئات التصنيف عبر قطاع الشحن التجاري. يتركز عملهم التوثيقي على رسومات DXF وDWG — تحويل ما يوجد داخل ملف CAD إلى جداول منظمة، وكتل عنوان محدثة، ومجموعات تسليم مُعبّأة رسميًا يحتاجها فعليًا كل من الأحواض ومفتشو التصنيف.
عادةً ما يسلّم المشروع جدول خزانات، وملخص Main Particulars، وتعديلًا واحدًا على الأقل في كتلة العنوان، ورسمًا عائدًا بإصدار DWG محدد. بالنسبة لمشروع Hanna — وهي ناقلة كيميائية — شمل النطاق بالضبط هذه المجموعة: جدولَي بيانات منظمين، وتغييرًا في كتلة العنوان، وتحويلًا ذهابًا وإيابًا إلى ملف AC1021 DWG مُتحقَّق منه. يعالج الفريق عدة سفن بالتوازي، لذا فإن عنق الزجاجة الخاص بالاستخراج اليدوي يتفاقم بسرعة عبر محفظة المشاريع.
المشكلة
إن استخراج البيانات المنظمة من رسومات DXF ليس مهمة تحليل نصوص بالمعنى المعتاد. فرسومات السفن تخزن التسميات والقيم والأبعاد وتعليقات الإطارات على هيئة كيانات نصية DXF موزعة عبر الطبقات، من دون بنية صفوف وأعمدة متسقة يمكن لأدوات الجداول قراءتها مباشرة. والطريقة الموثوقة الوحيدة هي تحليل صيغة DXF برمجيًا — أو فتح الرسم في محطة CAD كاملة وكتابة القيم يدويًا.
في مشروع Hanna، كان هدف الاستخراج جدولين بالإضافة إلى سبعة أسطر قياس منفصلة.
احتوت كتلة Main Particulars على أبعاد السفينة التالية:
- Length for scantlings: 106.254 m
- Length overall: 109.999 m
- Breadth moulded: 13.500 m
- Depth moulded: 5.140 m
- Draft — scantling: 4.200 m
- Draft — maximum: 4.200 m
- Cargo tank capacity: 4,560 m³
وكان كل سطر يحمل أيضًا أوصافًا إضافية — "abt." للدلالة على التقريب، و"mld." للدلالة على moulded — وكان لا بد من الحفاظ عليها في المخرجات إلى جانب القيم الرقمية والوحدات. إن فقدان واصف أو إسناده بشكل خاطئ يغيّر التفسير الهندسي للبُعد.
أما جدول الخزانات فكان يمثل تحديًا مختلفًا. فجدول خزانات كامل لناقلة كيميائية من هذه الفئة يمتد عبر العديد من الخزانات المرقمة، ولكل منها نطاق إطارات وسعة مرتبطة به. ولا يقتصر الخطر على خطأ الاستخراج فحسب، بل يشمل أيضًا الحذف الصامت: فقد لا يُكتشف إدخال خزان مفقود إلا عندما يصل المستند إلى مفتش تصنيف أو إلى فريق المشتريات في الحوض. وفي سير العمل السابق لدى الفريق — فتح الرسم على محطة CAD، وقراءة القيم يدويًا، وإدخالها في Excel — كان تمرير استخراج كامل لرسم سفينة واحدة يستغرق معظم يوم عمل، ومع ذلك كان هذا الخطر يظل من دون معالجة.
كما تطلب المشروع تحويلًا من DXF إلى DWG ينتج ملف AC1021 صالحًا. ولا يزال هذا المعيار للإصدار (صيغة AutoCAD 2007) مطلوبًا لدى العديد من أنظمة CAD القديمة المستخدمة في هيئات التصنيف وبعض الأحواض. إن مجرد إعادة تسمية الملف لا يكفي؛ فقد احتاج الفريق إلى تأكيد عدد الكيانات والطبقات لإصدار شهادة تسليم للمخرجات.
لماذا الآن
تتطلب هيئات التصنيف وأنظمة مشتريات أحواض بناء السفن بشكل متزايد بيانات قابلة للقراءة آليًا إلى جانب الرسومات. لم يعد DWG أو PDF وحده كافيًا عندما يحتاج النظام المستقبِل إلى استيعاب أرقام السعات، ونطاقات الإطارات، أو بيانات السفينة الأساسية في قاعدة بيانات، أو إلى التحقق منها برمجيًا قبل جدولة المسح.
مثّل مشروع Hanna نقطة تحول شائعة: سفينة تنتقل من مرحلة مراجعة الرسومات إلى التقديم الرسمي للتصنيف، حيث تُطلب عمليات تصدير البيانات المنظمة بالتوازي مع الرسم المحدث. إن التأخير في هذه المرحلة ينتقل إلى جدولة المسح، وفي النهاية إلى الجاهزية التشغيلية للسفينة. وكان الفريق بحاجة إلى ضغط مرحلة الاستخراج والتعبئة من دون إدخال أخطاء تستدعي إعادة التقديم.
لماذا energent.ai
قيّم الفريق ثلاثة أساليب قبل اختيار energent.ai: مشغّل محطة CAD يتولى الاستخراج يدويًا، ونص Python داخلي الصيانة لتحليل الملفات، ونموذج لغوي عام من دون قدرة مباشرة على التعامل مع الملفات.
ظل الاستخراج اليدوي ضروريًا للتأكيد البصري النهائي على الحالات الشاذة المُعلَّمة، لكنه كان بطيئًا جدًا ويعتمد على المشغّل أكثر من اللازم لمرحلة الاستخراج والتنظيم الروتينية. أما نص Python الداخلي فكان يتطلب صيانة مستمرة مع اختلاف هياكل الرسومات بين أنواع السفن والعملاء. وكان النموذج اللغوي العام قادرًا على وصف اصطلاحات صيغة DXF، لكنه لم يكن قادرًا على تحميل الملف وتحليله بنفسه.
تولى energent.ai سير العمل الكامل في جلسة واحدة. فقد حمّل ملف DXF، وشغّل Python لتحليل كيانات النص، ونظم المخرجات في أعمدة معنونة، وطبّق تغييرات كتلة العنوان في مكانها، وحوّل DXF المحدَّث إلى DWG مع التحقق من الإصدار، ثم عبّأ ستة ملفات تسليم. والأهم من ذلك أنه شغّل أيضًا تمرير تدقيق مستقل — معزول عمدًا عن عملية الاستخراج لتجنب تحيز التأكيد — كشف عن حالتين شاذتين قبل تسليم الملفات. وكان سلوك التدقيق هذا هو القدرة التي لم يستطع الفريق محاكاتها بأي من البدائل الأخرى.
سير العمل
اتبعَت الجلسة تسلسلًا قابلًا للتكرار من سبع خطوات:
الخطوة 1 — إدخال الرسم. رفع الفريق ملف Hanna DXF. قام الوكيل بتحليل بنية الملف وحدد المناطق الثلاث المستهدفة: جدول الخزانات، وكتلة Main Particulars، وكتلة العنوان.
الخطوة 2 — استخراج Main Particulars. استخرج الوكيل الكتلة المكونة من سبعة أسطر، مع مطابقة كل تسمية قياس بقيمتها ووحدتها ووصفها الإضافي. الناتج: مصنف XLSX وملف CSV، يحتوي كل منهما على شروح أعمدة باللغة الإنجليزية البسيطة تشرح أوصافًا مثل "abt." (تقريبي) و"mld." (moulded).
الخطوة 3 — استخراج جدول الخزانات. استُخرج جدول الخزانات الكامل في جدول منظم يغطي أرقام الخزانات، ونطاقات الإطارات، وقيم السعة. الناتج: XLSX وCSV.
الخطوة 4 — تعديل كتلة العنوان. طُبقت استبدالات النص المطلوبة في كتلة العنوان مباشرة على سجلات كيانات DXF. أكد الوكيل التغييرات عبر فحص المحتوى النصي للملف المحدَّث.
الخطوة 5 — تدقيق مستقل. راجع تمرير تدقيق معزول مخرجات الاستخراج مقابل البيانات المصدر. وسُجلت نتيجتان: كان Tank No. 12 غائبًا عن جدول الخزانات المستخرج — وصُنّف ذلك على أنه سؤال اكتمال بدلًا من قبوله بصمت — كما حمل Tank 5 نطاق إطارات 127–172 بدا واسعًا بشكل شاذ مقارنة بالإدخالات المجاورة، ما استدعى مراجعة بصرية مقابل الرسم المصدر.
الخطوة 6 — تحويل DXF إلى DWG والتحقق. حُوّل DXF المحدَّث إلى DWG باستخدام سير عمل تحويل منظم. وأكد التحقق: إصدار AC1021، وطبقتان (Model وLayout1)، و3,753 عنصرًا في modelspace. وسُجل تنبيه بأن الدقة البصرية تعتمد على إعداد الخطوط في محطة الاستقبال وتوفر ملفات SHX.
الخطوة 7 — تعبئة ملفات التسليم. جُمعت جميع الملفات الستة وتأكدت: ملف XLSX لجدول الخزانات، وCSV لجدول الخزانات، وXLSX لـ Main Particulars، وCSV لـ Main Particulars، وDXF المحدَّث، وDWG المُتحقَّق منه.
النتائج
أُنتجت ستة مخرجات منظمة من مدخل DXF واحد في جلسة واحدة:
- استخراج سبعة أبعاد للسفينة إلى XLSX وCSV معنونة مع الحفاظ على أوصاف الوحدات
- التقاط سعة شحن 4,560 m³ بشكل صحيح وربطها بسطرها في الجدول
- التحقق من 3,753 عنصرًا في modelspace عبر جولة DWG ذهابًا وإيابًا (تأكيد AC1021)
- ظهور 2 من إشارات التدقيق قبل التسليم — ما منع وصول الأخطاء الصامتة إلى المراجعين اللاحقين
- تعبئة 6 ملفات تسليم، بما يطابق صيغة التسليم القياسية للحوض وهيئات التصنيف
كما تلقى الفريق قالب جلسة قابلًا للتكرار. ويمكن تطبيق التسلسل نفسه المكون من سبع خطوات — الإدخال، واستخراج Main Particulars، واستخراج جدول الخزانات، وتعديل كتلة العنوان، والتدقيق، والتحويل، والتعبئة — على رسومات سفن إضافية من دون إعادة بناء سير العمل من الصفر لكل مشروع.
Proof
"كنا نقضي معظم يوم العمل على رسم سفينة واحد، وكنا أحيانًا نفوّت أيضًا قيودًا لا تظهر إلا أثناء مراجعة التصنيف. إن قيام الوكيل بالإشارة إلى خزان مفقود ونطاق إطارات مشبوه قبل أن نُجمّع الملفات كان بالضبط آلية الالتقاط التي احتجناها مدمجة في العملية، لا مضافة يدويًا في النهاية." — Lead Naval Architect, marine engineering consultancy
مجموعة التسليم الكاملة التي أنشأها الوكيل — tank table XLSX and CSV, Main Particulars XLSX and CSV, updated DXF, and validated AC1021 DWG — تعكس حزمة التسليم القياسية التي يقدّمها الفريق إلى مشتريات أحواض بناء السفن ومفتشي التصنيف. وتُحدِّد علامتا التدقيق بدقة العناصر التي تتطلب تأكيدًا بصريًا قبل الاعتماد، بدلًا من ترك هذا القرار للمراجع اللاحق.
Trust note
مرّ خرج DWG بالتحقق البنيوي (صيغة AC1021، مع تأكيد 3,753 عنصرًا في modelspace)، لكن التطابق البصري الدقيق يظل معتمدًا على إعدادات الخطوط وتوافر ملفات SHX في محطة العمل المستقبلة — وهي فجوة لا يمكن حلها من دون مراجعة على محطة CAD. وقد أشار التدقيق صراحةً إلى أن Tank No. 12 غير موجود في الجدول المستخرج، وأن نطاق الإطارات الخاص بـ Tank 5 (127–172) قد يكون غير طبيعي مقارنةً بالمدخلات المجاورة. ويتطلب كلا الأمرين من مراجع بشري فتح الرسم المصدر والتأكد بصريًا قبل تقديم جدول الخزانات لمراجعة التصنيف أو إدراجه في وثائق السفينة الرسمية. أما Main Particulars CSV فهو مكتمل بنيويًا للخطوط الأساسية السبعة، لكنه لا يُعد ورقة مواصفات تقنية كاملة.