RAG أم Fine-Tuning؟ كيف تربط الذكاء الاصطناعي بمعرفة شركتك؟

الملخّص التنفيذي

أعلنت AWS في 5 أغسطس 2026 توفر البحث المتجهي داخل Amazon DynamoDB مع نوع فهرس متجه جديد وSearchVectors API. هذا يمنح فرق الهندسة خياراً لوضع المتجهات جنباً إلى جنب مع صفوف التشغيل بدلاً من تكرارها في قاعدة متجهات منفصلة.

متى تختار DynamoDB: إذا كانت بيانات التطبيق بالفعل في DynamoDB، وتحتاج استرجاعاً منخفض الكمون داخل نطاق مفتاح التقسيم (per-tenant)، وتريد تقليل مسارات المزامنة، فابدأ بتجربة سريعة. متى لا تختاره: إذا احتجت بحثاً شاملاً عبر تقسيمات متعددة، مرشحات معقدة أو ضوابط ضبط متقدّمة لفهرس المتجهات.

• اجعل قرارك نتيجة اختبار: نفّذ تجربة لمدة 2 أسابيع تقيس recall@K وذيل الكمون (p95/p99) وتكلفة الاستعلامات والتحديثات.
• راجع استراتيجيات تقسيم المستأجرين لأن البحث المتجهي في DynamoDB مقصور على قيمة مفتاح التقسيم.
• عالج ادعاءات الأداء كبيانات تحتاج تحققاً مستقلّاً داخل عبء عملك.

ما قدمته AWS فعلياً — الميزات والحدود

وفق إعلان AWS، توفر DynamoDB الآن نوع فهرس متجه وSearchVectors API. يدعم الفهرس أبعاداً حتى 4096 وبنى مسافة Cosine وEuclidean وDot، ويعيد أعلى 100 نتيجة لكل استدعاء.

القيود المُعلنة تشمل تقييد نطاق البحث بمفتاح التقسيم لكل استعلام ومرشحات داخلية بدعم المطابقة الدقيقة فقط. لا تُفصح الوثائق عن خوارزمية الفهرسة الداخلية أو تفاصيل التسعير التفصيلية.

• أبعاد مدعومة حتى 4096.
• دوال مسافة: Cosine، Euclidean، Dot.
• حد أعلى لنتائج SearchVectors: 100.
• نطاق البحث: مقصور على قيمة مفتاح التقسيم لكل استدعاء.
• مرشحات inline تدعم المطابقة الدقيقة فقط.

لماذا يهم هذا التغيير لأنظمة RAG

إمكانية حفظ المتجهات داخل DynamoDB تقلّل الحاجة لخط مزامنة مستقل إلى قاعدة متجهات منفصلة، وبالتالي تقلل السطح التشغيلي وخطر عدم التناسق بين الصفوف والمتجهات.

لكن القيود المعمارية — خصوصاً تقييد البحث بمفتاح التقسيم وعدم وجود مرشحات متقدّمة أو أدوات ضبط فهرسية ظاهرة — تغير قرار تصميم الأنظمة متعددة المستأجرين والعمليات التي تحتاج تجميع نتائج عبر تقسيمات عديدة.

• السرعة والحوكمة: فائدة لتطبيقات التشغيل التي تتطلب انخفاض كمون واستناداً محلياً إلى بيانات الصف.
• قابلية التشغيل: فائدة بوجود فواتير وحوكمة IAM موحدة في حساب AWS واحد.
• قيود الانتشار: تعقيدات في تحقيق Top‑K عالمي عبر تقسيمات متعددة.

اختيار مخزن المتجهات: خيارات معاصرة وخيارات AWS

اختيار مخزن المتجهات يجب أن يقيس ثلاثة أبعاد: متطلبات الاستدعاء (recall)، نطاق البحث (محلي داخل تقسيم أم عالمي)، واحتياجات الترشيح والهجين. اليوم هناك أنماط متعددة: DynamoDB المتجهية، DynamoDB → OpenSearch عبر zero‑ETL، S3 Vectors، أو قواعد متجهات مخصّصة مثل Pinecone أو Weaviate.

• DynamoDB المتجهية — مناسبة لتطبيقات ذات بيانات تشغيلية في DynamoDB وتحتاج استرجاعاً منخفض الكمون داخل مفتاح تقسيم محدد.
• DynamoDB → OpenSearch — مفيدة لدمج البحث النصي أو المرشحات المعقدة بدون خط مزامنة مخصص.
• S3 Vectors — خيار منخفض التكلفة للقراءات التحليلية الكبيرة.
• قواعد متجهات مخصّصة — تقدم ضبطاً دقيقاً للفهرس وTop‑K عالمي على حساب عملية مزامنة وتشغيل.

قوالب التصميم: المخطط وتقسيم المفاتيح لمجموعات متعددة المستأجرين

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

• مثال صف: { tenantId (PK), itemId (SK), embedding: List(Number), metadata, updatedAt }.
• لا تفترض Top‑K عبر مستأجرين دون فن‑أوت أو فهرس خارجي.
• قِس زمن انعكاس التحديث عند تصميم سياسة الاستجابة للتغيّرات.

قائمة فحص التنفيذ وخطة التجربة التجريبية

اقترح تنفيذ تجربة صغيرة تقيس recall@K وذيل الكمون (p95/p99) وزمن انعكاس التحديث وتكلفة الاستعلامات. حدّد مجموعة بيانات تجريبية لكل Partition وخط أساس على قاعدة متجهات مخصّصة.

• اختر نموذج تضمين ثابتاً وابعاداً مطابقة للفهرس.
• شغّل اختبارات recall@10/20/100، p95/p99 latency، وزمن انعكاس التحديث بعد عمليات الكتابة.
• قارن بالخط الأساس (FAISS/Pinecone/OpenSearch) لاكتشاف تأثير خوارزمية الفهرسة.

الأمن والحوكمة عند تجميع المتجهات مع بيانات تشغيلية

عند وضع المتجهات داخل نفس جدول DynamoDB مع البيانات التشغيلية، يزيد نطاق الأثر لخرق بيانات أو أخطاء الوصول. راجع سياسات IAM، التشفير، وسجلات التدقيق، واشتراطات الحذف لأن حذف العنصر يجب أن ينعكس في الفهرس.

• استخدم سياسات IAM دقيقة وصلاحيات منفصلة لعمليات SearchVectors وPutItem.
• سجل استدعاءات البحث والكتابة وربطها بهوية الطلب للحصول على أثر تدقيق.
• ضع خطة لحذف المتجهات وقياس زمن انعكاس الحذف ضمن سياسة الامتثال.

قائمة قرار سريعة

استعمل هذه الأسئلة لاتخاذ قرار مبدئي: هل بياناتك في DynamoDB؟ هل يحتاج التطبيق Top‑K عبر تقسيمات متعددة؟ هل تحتاج مرشحات معقدة أو ضبط فهرس؟ اجعل الإجابة تقودك إلى تجربة أو اختيار مخزن خارجية.

• هل بياناتك التشغيلية في DynamoDB؟ إذا نعم، نفّذ تجربة.
• هل تحتاج Top‑K عالمي دون فن‑أوت؟ إذا نعم، فكر في قاعدة متجهات مخصّصة.
• هل تحتاج مرشحات ونماذج سكور متقدمة؟ إذا نعم، فاختر OpenSearch/S3 Vectors أو قاعدة متجهات مخصّصة.

ملحق تشغيلي: Snowflake Cortex — ترحيل CORTEX_MODELS_ALLOWLIST إلى Model RBAC (Aug‑Sep 2026)

ملاحظة مهمة لفرق RAG وعمليات إنشاء المتجهات: نشرت Snowflake تغيير سلوكي (BCR‑2378) يُعلن إيقاف معلمة الحساب CORTEX_MODELS_ALLOWLIST وطرح ترحيلٍ آلي إلى نموذج تحكم بالوصول المرتكز على الأدوار (model RBAC). يُنَفَّذ الترحيل الأحادي مرة واحدة خلال نافذة زمنية بين 17 أغسطس و4 سبتمبر 2026. بعد اكتمال حزمة السلوك 2026_07 ستصبح منحه الوصول إلى النماذج عبر Model RBAC هو آلية الإنفاذ.

هذا يعني أن استدعاءات تكوين المتجهات وCortex Search Services وAI_EMBED/EMBED_TEXT_* ستتحقق من امتيازات نموذج‑RBAC بدلاً من أو بالإضافة إلى قائمة السماح على مستوى الحساب. الحسابات التي اعتمدت على CORTEX_MODELS_ALLOWLIST يجب أن تخطط لعملية تحقق وترحيل لتجنب انقطاع الإنتاج.

• الترحيل الآلي سيشغّل مرة واحدة خلال 17 Aug — 4 Sep 2026 ويحوّل إعدادات Allowlist الحالية إلى ربط أدوار تطبيق Model‑RBAC (CORTEX‑MODEL‑ROLE‑*).
• الوظائف المتأثرة: AI_EMBED، EMBED_TEXT_768، EMBED_TEXT_1024، Cortex Search Services، وCortex Agents التي تستدعي هذه الدوال.
• مخاطر مباشرة: إن لم تراجع الخرائط الناتجة فقد تُمنع استدعاءات الإنشاء أو الاسترجاع التي كانت تعمل سابقاً.
• توصية عاجلة: درّج اختبار تحقق خلال نافذة الترحيل في بيئة اختبار/ما قبل الإنتاج باستخدام نفس أدوار التشغيل.

1. 1جمع قائمة إنفاذ شاملة: استعلم عن استخدام الدوال AI_EMBED وEMBED_TEXT_* عبر QUERY_HISTORY، وابحث في الإجراءات المخزنة، المخططات المجدولة، DAGs في Airflow، ونقاط النهاية في CI.
2. 2حدّد أدوار Snowflake التي تنفّذ هذه الاستدعاءات (service roles، scheduler roles، user roles، أو أدوار ممنوحة لـ PUBLIC).
3. 3في بيئة اختبار، اضبط CORTEX_MODELS_ALLOWLIST = 'None' لاختبار سلوك RBAC وحدد أي استدعاءات تُمنع.
4. 4أثناء نافذة 17 Aug — 4 Sep 2026، راجع الخرائط الآلية المنشأة (CORTEX‑MODEL‑ROLE‑*) وصحّح أية منح/سحب صلاحيات يدوياً باستخدام أوامر GRANT/REVOKE.
5. 5حدّث IaC وملفات CI لإدارة ربط النماذج بالأدوار (إنشاء/إزالة CORTEX‑MODEL‑ROLE‑* ضمن مسارات الاعتماد).
6. 6نفّذ اختبارات رفض‑الخط (deny‑mode) في CI لتنبيه فرق التشغيل عند حصول رفض إذن بدلاً من فشل صامت.

المقايضات الفنية والمخاطر

الانتقال من عملية مركزية قائمة على معلمة حساب إلى RBAC يوفر دقّة تحكم أكبر لكنه يرفع عبء العمليات: يجب إدارة منح النماذج لكل دور، وتحديث CI/IaC لخلق وصيانة هذه الربطات، وإجراء مراجعات دورية.

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

• خطر الترحيل الآلي: قد تُنشأ منح لا تعبّر عن نية الحوكمة وتتطلب تصحيحاً يدوياً.
• تكاملات قديمة أو خارجية قد لا تتوافق مع نمط منح الأدوار وتحتاج تعديل.
• عدم وضوح لرسائل الخطأ التفصيلية عند الرفض قد يتطلب تحسين التعامل في التطبيقات.

التحقّق بعد الترحيل الموصى به

قائمة تحقق للتحقّق بعد اكتمال الترحيل: شغّل استدعاءات متكررة تمثيلية لكل دور، راجع سجلات Cortex Search وAI_EMBED، وتأكد أن فهارس البحث وAgents تعمل كما هو متوقع، وأن سجلات التدقيق تُظهر أحداث وصول النموذج مرتبطة بالأدوار الصحيحة.

• نفّذ اختبار استدعاء AI_EMBED لكل دور يعمل في الإنتاج وتحقق من عدم ظهور أخطاء DENIED.
• راجع رُتب المنافع (grants) من خلال الاستعلام عن APPLICATION ROLES المرتبطة بالنماذج والأدوار التي منحتها.
• أدرج تقارير دورية تُظهر استخدام النموذج لكل دور لتدعم مراجعات الحوكمة والتكاليف.

اختبارات CI والنشر وقياس الأثر

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

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

حوكمة وتوجيهات التحكم بالتكلفة

الانتقال إلى RBAC هو فرصة لتحسين حوكمة الاستخدام وتقليل التكاليف عن طريق تقييد الوصول إلى النماذج المكلِّفة أو ذات الملكية الخاصة لأدوار محددة مع سياسة موافقات واضحة.

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

نقاط عدم اليقين ومصادر الدعم

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

• هل يجوز إعادة تشغيل الترحيل الآلي؟ الوثائق لا توضح إمكانية التراجع أو إعادة تشغيل الترحيل في جميع الحالات.
• هل تُغطى النماذج المخصصة بنفس القواعد؟ قد تحتاج نماذج خارجية أو مسجلة داخل Model Registry إلى خطوات يدوية إضافية.
• راجع روابط الوثائق الرسمية وفتح تذكرة دعم Snowflake إذا وجدت خرائط ترحيل لا تعبّر عن نيتك.

خلاصة إجراءات سريعة (Appendix — خطوات عملية خلال 2‑4 أسابيع)

مجموعة خطوات قصيرة لتخفيض خطر الانقطاع: جرد الاستخدام، اختبار في بيئة بحثية مع CORTEX_MODELS_ALLOWLIST='None'، رصد الخرائط الآلية خلال 17 Aug — 4 Sep 2026، تصحيح منح الأدوار، وتحديث IaC/CI لإدارة ربط النماذج.

• أسبوع 0: جرد الاستدعاءات والبيئات والأدوار، وصياغة خطة اختبار.
• أسبوع 1: شغّل اختبارات RBAC في بيئة preprod مع CORTEX_MODELS_ALLOWLIST='None'.
• أسبوع 2 (نافذة الترحيل): راقب الخرائط الآلية وصحّح أي منح زائدة، ثم حدّث IaC.
• أسبوع 3: أضف اختبارات رفض وحالة إنذار في CI لمراقبة DENIED errors.

الأسئلة الشائعة

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

ماذا أفعل إذا كانت مهامي المجدولة تعمل كـ ACCOUNTADMIN؟ لا تعتمد على ACCOUNTADMIN كحل دائم؛ من الأفضل إنشاء دور خدمة محدد بمبدأ الأقل امتيازاً ومنحه ربطات نموذجية محدودة. راجع الخرائط الآلية وتحقق من منح ROLE المخصصة بدلاً من الاعتماد على ACCOUNTADMIN.

أين أجد توثيق Snowflake الرسمي ودعم الترحيل؟ اطلع على ملاحظات الإصدار BCR‑2378 وصفحات دليل Cortex AI (AI SQL وPrivileges and access) ويُستحسن فتح تذكرة دعم Snowflake للحالات الحسابية الخاصة.

الخلاصة

تغيّر Snowflake لمسار التحكم بالوصول إلى النماذج من معلمة حساب مركزية إلى نظام RBAC نموذج‑مرتكز يتطلب عمليات تشغيلية دقيقة. للفرق العاملة على أنابيب RAG ومتجهات التضمين، الخلاصة العملية: جرد، اختبار في preprod، راقب الترحيل الآلي خلال نافذة 17 Aug — 4 Sep 2026، صَحِّح منح الأدوار، وادمج إدخالات RBAC في IaC/CI قبل أن يُطبق الإنفاذ بالكامل.