Postgres واحد لكل شي
قائمة المهام، حالة التطبيق، الـ embeddings، الـ caches، سجل التدقيق — كلها في قاعدة واحدة. نسخة احتياطية واحدة، connection pool واحد، مجموعة مقاييس واحدة.
Intelligence, Orchestrated.
يحوّل إيميلات RFQ إلى مسودات عروض جاهزة بالأسعار. الموظف يتحول من "اكتب كل شي" إلى "راجع وأرسل".
يراقب صندوق المبيعات المشترك. لمن يوصل إيميل، النظام يحدّد إذا كان طلب عرض سعر، يستخرج بيانات العميل والبنود، يطابق كل بند مع منتج في الكتالوج، يجيب أي عرض سابق لنفس العميل من الـ ERP، ويجهّز مسودة العرض ولوحة معاينة بالنتائج. الموظف يراجع، يصحح اللي يحتاج تصحيح، ويرسل.
قبل النظام: المندوبون كانوا ينسخون أوصاف البنود من الإيميلات إلى Excel. البحث عن SKU كل بند ياخذ دقائق — بعض الـ RFQs فيها 80 بند. العميل ينتظر 2 إلى 7 أيام للعرض. وكثير منهم يشترون من غيرك. ما في رؤية للـ backlog — الـ RFQs العالقة تنسى لما العميل يطالب. بعد النظام: متوسط زمن إصدار العرض نزل إلى أقل من 30 دقيقة للحالات النظيفة. 107 يوم تشغيل فعلي وقت كتابة الوثيقة.
عامل خلفي يفحص صندوق المبيعات كل 30 ثانية. الإيميلات الجديدة تنحفظ وتدخل قائمة الانتظار.
نموذج LLM يقرر إذا كان الإيميل RFQ. لو نعم، نموذج ثاني يستخرج العميل والبنود (وصف، كمية، مواصفات) واسم المشروع والموعد النهائي بصيغة JSON صارمة.
لكل بند: جرّب أولاً مطابقة SKU مباشرة. إذا ما في، استخدم بحث vector عبر 3,500 متغير منتج. خذ أفضل 20 مرشح وخلِ نموذج LLM يقيّمهم بدليل منظم. اختر الأفضل، سجل نتيجة 0-100، واقفله لو النتيجة ≥ 85.
ابحث في الـ ERP (قراءة فقط) عن عروض سابقة لنفس العميل. لو في مشابه، اعرضه جنب المسودة الجديدة عشان الموظف يشوف السياق.
اللوحة تعرض النتائج المسجّلة والفجوات. الموظف يصحح اللي يحتاج، النظام يتعلم من التصحيح، ثم يرسل PDF العرض بالإيميل.
تشغيل فعلي
107 يوم
متوسط زمن العرض
أقل من 30 دقيقة
حجم الكتالوج
~3,500 متغير
تكلفة LLM اليومية
0.15-0.40 دولار
معدّل cache hit
~70%
هذه ليست تصاميم. كل صورة من النظام الشغّال في الإنتاج.
لأي شخص يقيّم النظام من جانب الهندسة: لماذا اختيرت هذي القرارات وما البدائل.
قائمة المهام، حالة التطبيق، الـ embeddings، الـ caches، سجل التدقيق — كلها في قاعدة واحدة. نسخة احتياطية واحدة، connection pool واحد، مجموعة مقاييس واحدة.
الـ embeddings تلقى الجيرة الصحيحة بسرعة وبتكلفة منخفضة. الـ LLMs تختار الجواب الصحيح من 20 مرشح. تشغيلهم بالتسلسل يعطيك الاثنين.
كل مطابقة لها نتيجة 0-100. الاختيار التلقائي يشتغل فوق 85 فقط. تحت 30 البند يصير "بدون مطابقة." الموظفون يرتبون حسب النتيجة ويبدأون من الأسفل.
ما نكتب أبداً. الكتابة الخاطئة في الـ ERP تكلف أكثر من أي فائدة. المزامنة كل 6 ساعات.
إعادة تشغيل التصنيف أو المطابقة أو الإرسال يجب ألا تكرر. جدول المهام يفرض هذا بـ unique index.
لو بنيته اليوم من جديد، بتجنّب تخزين الـ embeddings كـ JSON arrays وأستخدم pgvector من اليوم الأول. حساب cosine في JS يشتغل عند هذا الحجم لكن pgvector يخلي الكتالوج يكبر بدون إعادة بناء. وكنت بضيف harness تقييم مدمج عشان التغييرات على الـ matcher تتقاس قبل النشر.
شارك سير العمل والأنظمة الحالية. خلال 24 ساعة نرد بنطاق وKPIs وجدول وسعر بالريال السعودي.
ابدأ الآنيحوّل إيميلات RFQ إلى مسودات عروض جاهزة بالأسعار. الموظف يتحول من "اكتب كل شي" إلى "راجع وأرسل".
يراقب صندوق المبيعات المشترك. لمن يوصل إيميل، النظام يحدّد إذا كان طلب عرض سعر، يستخرج بيانات العميل والبنود، يطابق كل بند مع منتج في الكتالوج، يجيب أي عرض سابق لنفس العميل من الـ ERP، ويجهّز مسودة العرض ولوحة معاينة بالنتائج. الموظف يراجع، يصحح اللي يحتاج تصحيح، ويرسل.
قبل النظام: المندوبون كانوا ينسخون أوصاف البنود من الإيميلات إلى Excel. البحث عن SKU كل بند ياخذ دقائق — بعض الـ RFQs فيها 80 بند. العميل ينتظر 2 إلى 7 أيام للعرض. وكثير منهم يشترون من غيرك. ما في رؤية للـ backlog — الـ RFQs العالقة تنسى لما العميل يطالب. بعد النظام: متوسط زمن إصدار العرض نزل إلى أقل من 30 دقيقة للحالات النظيفة. 107 يوم تشغيل فعلي وقت كتابة الوثيقة.
عامل خلفي يفحص صندوق المبيعات كل 30 ثانية. الإيميلات الجديدة تنحفظ وتدخل قائمة الانتظار.
نموذج LLM يقرر إذا كان الإيميل RFQ. لو نعم، نموذج ثاني يستخرج العميل والبنود (وصف، كمية، مواصفات) واسم المشروع والموعد النهائي بصيغة JSON صارمة.
لكل بند: جرّب أولاً مطابقة SKU مباشرة. إذا ما في، استخدم بحث vector عبر 3,500 متغير منتج. خذ أفضل 20 مرشح وخلِ نموذج LLM يقيّمهم بدليل منظم. اختر الأفضل، سجل نتيجة 0-100، واقفله لو النتيجة ≥ 85.
ابحث في الـ ERP (قراءة فقط) عن عروض سابقة لنفس العميل. لو في مشابه، اعرضه جنب المسودة الجديدة عشان الموظف يشوف السياق.
اللوحة تعرض النتائج المسجّلة والفجوات. الموظف يصحح اللي يحتاج، النظام يتعلم من التصحيح، ثم يرسل PDF العرض بالإيميل.
تشغيل فعلي
107 يوم
متوسط زمن العرض
أقل من 30 دقيقة
حجم الكتالوج
~3,500 متغير
تكلفة LLM اليومية
0.15-0.40 دولار
معدّل cache hit
~70%
هذه ليست تصاميم. كل صورة من النظام الشغّال في الإنتاج.
لأي شخص يقيّم النظام من جانب الهندسة: لماذا اختيرت هذي القرارات وما البدائل.
قائمة المهام، حالة التطبيق، الـ embeddings، الـ caches، سجل التدقيق — كلها في قاعدة واحدة. نسخة احتياطية واحدة، connection pool واحد، مجموعة مقاييس واحدة.
الـ embeddings تلقى الجيرة الصحيحة بسرعة وبتكلفة منخفضة. الـ LLMs تختار الجواب الصحيح من 20 مرشح. تشغيلهم بالتسلسل يعطيك الاثنين.
كل مطابقة لها نتيجة 0-100. الاختيار التلقائي يشتغل فوق 85 فقط. تحت 30 البند يصير "بدون مطابقة." الموظفون يرتبون حسب النتيجة ويبدأون من الأسفل.
ما نكتب أبداً. الكتابة الخاطئة في الـ ERP تكلف أكثر من أي فائدة. المزامنة كل 6 ساعات.
إعادة تشغيل التصنيف أو المطابقة أو الإرسال يجب ألا تكرر. جدول المهام يفرض هذا بـ unique index.
لو بنيته اليوم من جديد، بتجنّب تخزين الـ embeddings كـ JSON arrays وأستخدم pgvector من اليوم الأول. حساب cosine في JS يشتغل عند هذا الحجم لكن pgvector يخلي الكتالوج يكبر بدون إعادة بناء. وكنت بضيف harness تقييم مدمج عشان التغييرات على الـ matcher تتقاس قبل النشر.
شارك سير العمل والأنظمة الحالية. خلال 24 ساعة نرد بنطاق وKPIs وجدول وسعر بالريال السعودي.
ابدأ الآن