Saisit
تحويل ملفات PDF لكود البناء السعودي من 848 صفحة ومخططات CAD ثنائية الأبعاد إلى أحكام مطابقة مؤتمتة وموثوقة.
SAISIT
Building Code Compliance
- استخراج القواعد
- 98%
- دقة قراءة DWG
- 100%
- وكلاء المطابقة
- 6
- العميل
- Saisit
- القطاع
- تقنيات البناء · المملكة العربية السعودية
- طبيعة التعاون
- منصة متكاملة من الواجهة الأمامية إلى الخلفية + مسارات مطابقة متعددة الوكلاء
- الحالة
- قيد التنفيذ · إدماج MVP
- المدة
- يناير 2026 – مستمر
- النطاق
- مدقق المطابقة قيد التشغيل · المستشار + المولّد على خارطة الطريق
01 نظرة عامة
من هو العميل؟
Saisit منصة مطابقة لسوق البناء السعودي، حيث يجب أن تُثبت كل رخصة بناء مطابقتها لكود البناء السعودي، وهو مجموعة من وثائق اللوائح (SBC 201 و301 و401 و501 و601/602 و701–704) تغطي الحماية من الحرائق والمتطلبات الإنشائية وسبل الخروج والأنظمة الكهربائية والميكانيكية والتمديدات الصحية (MEP). وتبلغ وثيقة SBC 201 وحدها 848 صفحة. ورؤية المنتج ثلاث أدوات في منصة واحدة: مدقق المطابقة، مستشار المطابقة ومولّد ملفات التقديم؛ وقد ركّز التعاون حتى الآن على الأولى، وهي الأساس التقني للأداتين الأخريين.
حقيقة سوقية واحدة شكّلت تنفيذ المشروع كله: فرغم التوجه الإلزامي لاعتماد نمذجة معلومات البناء (BIM) في المملكة العربية السعودية، لا يزال معظم المهندسين المعماريين يعملون في AutoCAD. لذلك لا يمكن أن تقتصر المنصة على IFC، بل عليها أن تقبل ملفات DWG ثنائية الأبعاد أيضًا، وأن تستعيد منها فهمًا كافيًا للمبنى لإجراء فحوصات حقيقية للمطابقة مع كود البناء.
02 بيان المشكلة
ما المشكلة التي واجهوها؟
فحص تصميم المبنى مقابل كود البناء عملية يدوية يقودها الخبراء حاليًا، وهي بطيئة ومكلفة وغير متسقة إلى حد أن مراجعَين اثنين قد يصلان إلى استنتاجين مختلفين على المخطط نفسه.
848 صفحة من اللوائح بلا أي بنية
وثائق SBC ملفات PDF طويلة مليئة بالجداول والإحالات المرجعية بين الوثائق («وفق SBC 701 القسم 3.2...»)، وشروط التطبيق موزعة على ثلاثة مستويات: الوثيقة والقسم والقاعدة. ويُفحص المشروع مقابل أي إصدار من SBC كان ساريًا وقت إصدار الرخصة، ولذلك يجب أن تبقى مجموعة الوثائق ذات إصدارات.
المخططات لا تحمل البيانات التي تحتاجها الفحوصات
يحمل نموذج IFC ثلاثي الأبعاد جدرانًا وأبوابًا وفراغات صريحة، أما ملف DWG ثنائي الأبعاد فيحمل خطوطًا ونصوصًا فقط: مقاومة الحريق لأي باب ليست في المخطط أصلًا، بل في جدول، وأحيانًا في ملف PDF منفصل، ولا يربطها بالباب سوى وسم مثل «DR-1000».
معظم السوق لا يزال يُعِدّ مخططاته في AutoCAD
رغم التوجه الإلزامي لاعتماد BIM في المملكة العربية السعودية، لا يمكن أن تقتصر المنصة على IFC؛ فعليها أن تستخرج فهمًا حقيقيًا للمبنى من ملفات CAD ثنائية الأبعاد التي ينتجها المهندسون المعماريون فعلًا.
نتيجة «PASS» ناتجة عن هلوسة أسوأ من غياب الأداة
يواجه أي نظام يستخدم نموذجًا لغويًا كبيرًا (LLM) لإصدار أحكام المطابقة مشكلة ثقة واضحة: فالثقة الزائفة في قاعدة للحماية من الحرائق عبء ومسؤولية لا ميزة.
03 الحل
كيف حللناها؟
ما هو قائم اليوم مسار كامل من ملف PDF للوائح إلى تقرير مطابقة تفاعلي، بُني كنظام متجانس معياري (Modular Monolith) بلغة Go ينسّق عمّال حوسبة بلغة Python عبر gRPC، وتُدار كل عمليات سير العمل عبر قوائم انتظار Redis لا عبر معالجات الطلبات.
اللوائح تتحول إلى بيانات. يرفع المسؤول ملف SBC بصيغة PDF؛ يحلله Docling إلى صفحات وجدول المحتويات؛ ثم يرسم وكيل البنية خريطة الوثيقة، وتُوزَّع مهام الاستخراج على أجزاء عبر مستهلك قائمة انتظار مقيَّد بمعدل، ويستخرج زوج وكلاء (مستخرِج ومتحقِّق) كل قاعدة مع نصها وشروط تطبيقها وإحالاتها المرجعية وموقعها في المصدر. وتُحفظ القواعد في Postgres لمراجعة المسؤول واعتمادها، ويعمل المسار من البداية إلى النهاية بدقة استخراج تبلغ نحو 98% مقابل SBC 201.
المباني تتحول إلى بيانات. تمر ملفات IFC عبر عامل IfcOpenShell يستخرج البنية الطوبولوجية كاملة. أما ملفات DWG فيقوم استخراجها على Aspose.CAD، ويستخرج الغرف وعدد الوحدات ومواقع الأبواب والنوافذ ووسومها وسماكات الجدران وارتفاعات الأدوار، وقد تحققنا من تطابق مخرجاته مع مخرجات Autodesk نفسها بنسبة 100% على ملفات مشاريع حقيقية، منها ملف واحد يضم ثمانية أنواع من المباني في مخطط واحد.
الفحص فريق من الوكلاء، لا تلقين واحد. يمر تشغيل المطابقة عبر ستة وكلاء متخصصين: المصنِّف، محمِّل القواعد، المدقق الحسابي الحتمي، مدقق LLM، مولِّد التوصيات والمُجمِّع، مع حلقات مسودة ← مراجعة ← إعادة محاولة تُبقي الأحكام الناتجة عن هلوسة خارج النتائج التفسيرية. وتعود النتائج في تقرير PDF بلقطات شاشة مُصيَّرة، وملف BCF يُفتح مباشرة في Revit أو Navisworks، وملف JSON يشغّل عارضًا ثلاثي الأبعاد داخل المتصفح مبنيًا على ThatOpen/Three.js.
- GO Go Backend المنسّق + قوائم الانتظار chi routerقوائم انتظار asynqأحداث SSE
- PY Python Workers خدمات gRPC التابعة IfcOpenShellAspose.CADBlender
- LLM Agent Pipelines اللوائح + المطابقة Geminiمسودة ← مراجعة ← إعادة محاولة
- Go
- chi
- Python
- gRPC
- PostgreSQL
- Redis + asynq
- MinIO
- IfcOpenShell
- Aspose.CAD
- Docling
- Gemini
- Next.js
- ThatOpen / Three.js
صفحات حيّة: تجربة المستخدم المُعاد بناؤها، بالاعتماد على بيانات تجريبية
04 الجدول الزمني للمشروع
أبرز المعالم والمدة
المرحلة 1 25 يناير – 1 فبراير 2026
تجارب استكشافية للتحقق (Spike)
اختبرنا أخطر الافتراضات أولًا: استخراج القواعد من SBC 201، والبنية الطوبولوجية في IFC لفحوصات حقيقية، وتصميم مسار الاستخراج. وحوّلت التجربة الاستكشافية الخاصة بجودة LLM (29–30 يناير) مدقق المطابقة من صفر أحكام إلى أحكام «PASS»/«FAIL» حقيقية.
المرحلة 2 1–12 فبراير 2026
المسارات الأساسية
خادم خلفي بلغة Go مع سبعة عمّال يعتمدون على قوائم الانتظار، وخدمات Python لمعالجة البيانات الهندسية والتصيير، ومسار المطابقة بستة وكلاء، وإنشاء تقارير PDF/BCF، ومسار استيعاب اللوائح، وكلها تعمل من البداية إلى النهاية. حصر كامل حتى 12 فبراير: 31 نقطة نهاية API، ومساران إنتاجيان، وعارض واحد ثلاثي الأبعاد.
المرحلة 3 12–26 فبراير 2026
إمكانات DWG
بحث استمر أسبوعين في دعم مخططات CAD ثنائية الأبعاد: تسع جلسات استكشافية موثّقة على ملفات مشاريع سعودية حقيقية، انتهت بقرار الانتقال من LibreDWG إلى Aspose.CAD وببنية مصمَّمة لمطابقة قائمة على DWG.
المرحلة 4 من 1 مارس 2026 – مستمر
إعادة بناء منتج الحد الأدنى (MVP) بتجربة المستخدم أولًا
إعادة تصميم واجهة المنتج من الصفر: 11 مجموعة مسارات تغطي 107 مسارات مستخدم، يمر كل منها بتجربة استكشافية ← تنفيذ تجريبي ← مراجعة الكود ← تحقق حيّ في المتصفح. اكتمل بناء المجموعات الإحدى عشرة كلها والتحقق منها بحلول 10 مارس؛ ويشمل ما تبقى مواءمة نظام التصميم وربط الواجهة الأمامية الجديدة بالخادم الفعلي.
05 التحديات وحلولها
ما العقبات التي واجهتنا وكيف تجاوزناها؟
النموذج الذي لا يحسم
المشكلةعمل المسار من البداية إلى النهاية، لكن النموذج أعاد SKIPPED لجميع قواعد التفسير، وعددها 62: يعمل تقنيًا، لكنه عديم الفائدة عمليًا.
الحلشخّصنا خمسة أسباب متراكمة: غياب التحكم في درجة الحرارة (temperature)، وغياب الأمثلة المحلولة، و62 قاعدة محشورة في طلب واحد، ومخرج سهل، وبيانات عناصر غير كافية. وبمعالجة الأسباب الخمسة كلها أصبح المدقق يصدر أحكامًا فعلية.
الاعتماد على LLM في أحكام المطابقة
المشكلةتقرير مليء بأحكام تبدو واثقة لكنها خاطئة أسوأ من غياب الأتمتة تمامًا، خصوصًا في قواعد الحماية من الحرائق وسلامة الأرواح.
الحلالقواعد التي يمكن اختزالها في بحث بجدول تمر عبر مدقق حسابي حتمي لا يملك LLM فيه أي صوت. أما القواعد التفسيرية فتمر بمراحل المسودة والمراجعة وإعادة المحاولة. وحيث تكون البيانات غير كافية، تقفل المنصة الفحص: لا خيار للتشغيل القسري.
كاد دعم DWG ألّا ينجو من مكتبته الأولى
المشكلةلم ينجح أسلوب الاستخراج الأولي على الملفات الحقيقية، ومنها مخطط يضم ثمانية أنواع من المباني في ملف واحد.
الحلبدل الالتفاف على المشكلة، أجرى الفريق سلسلة منظمة من التجارب الاستكشافية لمدة أسبوعين على مخططات مشاريع سعودية فعلية، قبل الانتقال إلى Aspose.CAD والتحقق من مخرجاته كيانًا بكيان مقابل مخرجات Autodesk.
ملف PDF من 848 صفحة لا يمر عبر LLM دفعة واحدة
المشكلةالوثيقة التنظيمية الواحدة أكبر وأكثف من أن يُستخرج منها المحتوى بموثوقية دفعة واحدة، كما يجب أن تُحَلّ الإحالات المرجعية بين وثائق SBC حلًّا صحيحًا.
الحليقسّم مسار الاستيعاب الوثائق إلى أجزاء، ويوزّع الأجزاء عبر مستهلك قائمة انتظار مقيَّد بمعدل، ويشغّل زوج وكلاء (مستخرِج ومتحقِّق) لكل جزء، فيراجع نموذج ما أنتجه نموذج آخر قبل تخزين أي قاعدة.
انضباط الحالة في نظام غير متزامن
المشكلةنظام غير متزامن إلى هذا الحد (تنسيق بلغة Go، عمّال Python عديمو الحالة وتحديثات فورية للواجهة) كان يحتاج إلى قاعدة واضحة لمن يملك ماذا، وإلا انتشرت الحالة في كل مكان.
الحلتملك Go كل الحالة والتنسيق؛ وعمّال Python حوسبة عديمة الحالة يُوصَل إليها عبر gRPC؛ ولا تُطلق واجهة API أي سير عمل مباشرة. وتصل التحديثات الفورية في تدفق SSE واحد لكل مشروع بأحداث مصنّفة (typed events)، بدل تشابك اتصالات منفصلة لكل عملية.
06 قبل وبعد
مقارنة بين الوضع قبل المشروع وبعده
| قبل | بعد |
|---|---|
| اللوائح: ملفات PDF من 848 صفحة، وبحث يدوي | قواعد منظَّمة وذات إصدارات وقابلة للاستعلام، بشروط تطبيق وإحالات مرجعية (دقة استخراج نحو 98%) |
| مراجعة القواعد: لا سير عمل مخصص | مسار إداري: رفع، تقدّم الاستخراج، جدول القواعد، وتعديل واعتماد |
| فحص IFC: مراجعة يدوية يجريها خبراء | استخراج مؤتمت للبنية الطوبولوجية + تشغيل مطابقة بستة وكلاء |
| دعم DWG: غير قابل للقراءة الآلية عمليًا | استخراج مُتحقَّق منه للغرف والمساحات والوحدات والأبواب والنوافذ والجدران والأدوار، بتطابق 100% مع Autodesk على ملفات الاختبار |
| بيانات المخطط الناقصة: تُلاحَق يدويًا عبر ملفات PDF للجداول | استيراد الجداول مع مطابقة الوسوم، ولوحة مراجعة جانبية، واستبيان احتياطي |
| الثقة بأحكام LLM: لم تتأسس بعد | فحوصات حتمية حيث أمكن، ومسودة ← مراجعة ← إعادة محاولة حيث لا يمكن، وأقفال صارمة حيث البيانات غير كافية |
| المخرجات: ملاحظات مراجعة مكتوبة | تقرير PDF بلقطات مُصيَّرة، وملف BCF يُفتح في Revit/Navisworks، وعارض ثلاثي الأبعاد تفاعلي تُبرَز فيه النتائج |
| واجهة المنتج: نموذج أولي يبدأ من المحرك | 107 مسارات مستخدم أُعيد تصميمها في 11 مجموعة: تعدد المستأجرين، المشاريع، الفجوات، الإصدارات، عمليات التشغيل، المكتبة، التصدير والإدارة |
07 فوائد العميل ونتائجه
ما القيمة التي حصل عليها العميل؟
- دقة الاستخراج
- 98%
- مقابل SBC 201، مقيسة لا مقدَّرة
- دقة قراءة DWG
- 100%
- تطابق مع Autodesk على ملفات حقيقية
- نقاط نهاية API
- 31
- حتى 12 فبراير 2026
- مسارات المستخدم المُعاد بناؤها
- 107
- 11 مجموعة مسارات، جميعها مُتحقَّق منها
نواة تقنية مُتحقَّق منها لمنتج صعب حقًّا
ثبتت صحة أخطر ادعاءين للمشروع على وثائق حقيقية ومخططات مشاريع حقيقية: أن ملفات PDF لكود البناء يمكن أن تتحول إلى قواعد منظَّمة موثوقة، وأن بيانات مبنى قابلة للاستخدام يمكن استخراجها من ملفات CAD ثنائية الأبعاد التي ينتجها السوق فعلًا، وذلك بدقة مقيسة لا بتفاؤل.
بنية الوكلاء هي الأصل الدائم
بُنيت عمليتا استيعاب اللوائح وفحص المطابقة كمسارات وكلاء قابلة للتركيب بمراحل تحقق، أما مستشار المطابقة ومولّد ملفات التقديم المدرجان على خارطة الطريق فيعيدان استخدام القواعد نفسها والبيانات الهندسية المستخرجة نفسها والوكلاء أنفسهم موجَّهين إلى أسئلة مختلفة.
مخرجات تلائم القطاع كما هو
تُفتح ملفات BCF في الأدوات التي يستخدمها المهندسون المعماريون بالفعل، وتخدم تقارير PDF عملية استخراج رخصة البناء، ويتيح العارض ثلاثي الأبعاد لأصحاب المصلحة من غير مستخدمي BIM رؤية النتائج في سياقها؛ فاعتماد المنصة لا يتطلب من أحد تغيير سلسلة أدواته.
حماية من فقدان المعرفة
كل جلسة مسجّلة، وكل قرار بنيوي موثّق بمبرراته، ونتائج كل تجربة استكشافية مدوَّنة. وفي بناء كثيف البحث والتطوير، يساوي انضباط التوثيق هذا ما تساويه الشيفرة نفسها.
08 الدروس المستفادة
ماذا تعلّمنا من هذا المشروع؟
استكشف الأجزاء المخيفة أولًا
الافتراضان اللذان يقوم عليهما المنتج كله، أي قواعد قابلة للاستخراج ومخططات قابلة للاستخراج، اختُبرا في الأسبوع الأول والأسبوع الرابع على التوالي، قبل أي استثمار كبير. وغيّرت تجربة DWG الاستكشافية المكتبة المختارة؛ الأسبوع الرابع خير من الشهر السادس.
حين يقصّر LLM، دقّق في الأمور المملة
لم يكن فشل «كل القواعد SKIPPED» قصورًا في النموذج، بل تراكمًا لعوامل: درجة الحرارة، بنية التلقين، حجم الدفعة، المخرج السهل وبيانات إدخال غير كافية. كان كل إصلاح صغيرًا؛ والتشخيص هو العمل نفسه.
لا تدع LLM يفعل ما يستطيعه جدول
فصل القواعد الحتمية عن التفسيرية قلّص المساحة التي يمكن أن تحدث فيها الهلوسة أصلًا، وجعل أحكام LLM المتبقية أقل كلفة في ضمان صحتها.
الامتناع الصريح خير من ضجيج واثق
قفل اللوائح التي تفتقر إلى بيانات كافية، من دون أي خيار للتجاوز، قرار يتعلق بالمنتج لا بالتقنية، وهو الفرق بين أداة مطابقة وبين عبء ومسؤولية.
النماذج التجريبية بوصفها مواصفات منهجية حقيقية
أبقت إعادة بناء تجربة المستخدم على بيانات تجريبية، بعقد صريح يجعل كل نموذج تجريبي مواصفة API، التصميم ماضيًا أثناء عائق في الخادم، وأنتجت متطلبات للخادم قائمة على شاشات فعلية لا على التخمين.
دوّن كل شيء
ضمنت سجلات الجلسات وسجلات القرارات ونتائج التجارب الاستكشافية ألّا يعتمد مشروع امتد عبر عشرات جلسات العمل على ذاكرة أحد في معرفة سبب اتخاذ أي قرار.
كيف يعمل فعليًا · من قائمة انتظار إلى قائمة انتظار
المسار
تعمل المنصة بمسارين: لوائح تتحول إلى قواعد منظَّمة، ومبانٍ تُفحص مقابلها.
- 01 رفع PDF يرفع المسؤول وثيقة لوائح SBC
- 02 تحليل Docling استخراج الصفحات وجدول المحتويات
- 03 وكيل البنية يرسم خريطة الوثيقة ← الأقسام ← القواعد
- 04 الاستخراج المجزّأ قائمة انتظار مقيَّدة بمعدل، تُوزَّع على الأجزاء جزءًا جزءًا
- 05 المستخرِج / المتحقِّق زوج الوكلاء يستخرج كل قاعدة مع تحقق متبادل
- 06 مراجعة المسؤول اعتماد أو تعديل: دقة 98% مقابل SBC 201
- 01 المصنِّف يحدد القواعد التي تنطبق على هذا المبنى
- 02 محمِّل القواعد يحمّل القواعد المنطبقة وشروط تطبيقها
- 03 المدقق الحسابي بحث حتمي في الجداول، دون أي تصويت من LLM
- 04 مدقق LLM مسودة ← مراجعة ← إعادة محاولة للقواعد التفسيرية
- 05 مولِّد التوصيات يحوّل حالات عدم المطابقة إلى إجراءات مرتبة بحسب الأولوية
- 06 المُجمِّع يُعدّ مخرجات PDF وBCF والعارض ثلاثي الأبعاد
شاشات مبنية · تعمل ببيانات تجريبية على تجربة المستخدم المُعاد تصميمها
المنتج
من تسجيل الدخول إلى المشروع، وصولًا إلى إدارة المنصة: كل شاشة معروضة هنا تصيير حقيقي للتطبيق قيد التشغيل. انقر على أي صورة لتكبيرها.
