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

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

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

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

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

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

وفق إعلان AWS، توفر DynamoDB الآن نوع فهرس متجه وSearchVectors API لتخزين واستعلام المتجهات ضمن عناصر الجدول باستخدام نوع القائمة من الأرقام (List(Number)). يدعم الفهرس أبعاداً حتى 4096 وبنى مسافة Cosine وEuclidean وDot، ويعيد حتى أعلى 100 نتيجة.

القيود المُعلنة: البحث متقيّد بقيمة مفتاح التقسيم لكل عملية بحث، والمرشحات المضمّنة تدعم المطابقة الدقيقة فقط (exact-match). لم تُفصح AWS عن خوارزمية الفهرسة الداخلية أو تفاصيل ضبط المعاملات أو نماذج التسعير المفصّلة للمتجهات.

• أبعاد المدعومة: حتى 4096.
• دوال المسافة: Cosine، Euclidean، Dot.
• حد أعلى لعدد النتائج: Top-K حتى 100.
• نطاق البحث: مقصور على قيمة مفتاح التقسيم.
• نوع تخزين المتجه: List(Number) داخل صفوف DynamoDB.
• مرشحات مضمّنة: مطابقة دقيقة فقط؛ لا توجد مرشحات نطاقية أو نصية معقدة مضمّنة.

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

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

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

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

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

اختيار مخزن المتجهات يجب أن يقيس ثلاثة أبعاد: متطلبات الاستدعاء (recall)، نطاق البحث (محلي داخل تقسيم أم عالمي)، واحتياجات الترشيح والهجين. اليوم هناك أربعة أنماط عملية داخل منظومة AWS: (1) DynamoDB متجهات داخلية، (2) DynamoDB → OpenSearch عبر تكامل zero-ETL، (3) S3 Vectors كخيار مخزّن خادمي، و(4) قواعد متجهات مخصّصة مثل Pinecone أو Weaviate أو FAISS مستضاف.

• DynamoDB المتجهية — مناسبة لتطبيقات ذات بيانات تشغيلية موجودة حالياً في DynamoDB وتحتاج استرجاعاً منخفض الكمون داخل قيمة مفتاح تقسيم محددة. تمنع البحث عبر تقسيمات متعددة دون تنفيذ فن-أوت (fan-out).
• DynamoDB → OpenSearch (zero-ETL) — مفيدة عندما ترغب بدمج قدرة البحث النصي أو مرشحات معقدة مع بيانات DynamoDB دون بناء خط مزامنة مخصص.
• S3 Vectors — خيار خادم سحابي قابل للتوسع يقدم تكلفة تخزين منخفضة لمجاميع كبيرة وملاءمة لعمليات تحليل مؤجلة أو فهارس خارج ذاكرة العمليات.
• قواعد متجهات مخصّصة — تقدم ضبطاً دقيقاً للفهرس، مرشحات متقدّمة، وإمكانيات استرجاع عالمية دون قيود تقسيمية، لكنها تضيف تعقيد المزامنة والتشغيل.

Amazon DynamoDB (البحث المتجهي) — متى تفكر فيه

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

متى لا تختاره: عندما تحتاج إلى دمج نتائج عبر تقسيمات متعددة كـ"Top-K عالمي" دون فن-أوت أو عندما تعتمد على مرشحات نطاقية ومعقّدة أو ضبط فهرس متقدّم لتحسين recall/latency.

• المزايا: حذف خط نسخ المتجهات، إدارة موحّدة للوصول والفوترة داخل حساب AWS، وممشى كتابة موحّد يقلّل احتمال التناقض.
• القيود: بحث مقصور على قيمة مفتاح التقسيم، مرشحات مضمّنة بمطابقة دقيقة فقط، حدود Top-K=100 حسب الإعلان، وقلة إعدادات الضبط التي يطلبها فرق اختيار الأداء.

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

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

للبحث العالمي، فكّر في واحد من هذه النهج: فن-أوت لاستعلامات متعددة PartitionKey ودمج النتائج في التطبيق، أو بناء فهرس مخبأ خارجي (S3 Vectors أو OpenSearch أو قاعدة متجهات مخصّصة) مخصّص للبحث العالمي.

• نموذج صف المثال: { tenantId (PK), itemId (SK), embedding: List(Number), metadata: {...}, updatedAt }. اجعل البُعد والمسافة متطابقين مع نموذج التضمين.
• تجنّب مرشحات عالية التعداد كمرشحات مضمّنة؛ استخدم التقسيم لتقليل نطاق البحث أو طبقة ما بعد المعالجة (post-filtering).
• قِس حجم وسرعة التحديث لكل مفتاح تقسيم لتجنّب نمو فهرس متجه واحد بشكل يؤثر على الكمون.

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

اقترح تنفيذ تجربة صغيرة تمكّنك من قياس الادعاءات الأساسية قبل اعتماد الإنتاج. حدِّد مجموعة بيانات تجريبية (1–10k عنصر لكل Partition) وقيّم المقاييس التالية: recall@K وprecision@K وp50/p95/p99 latency، وزمن تحديث الفهرس بعد عمليات PUT/UPDATE/DELETE، وتكلفة الاستعلام المتوقعة.

تضمّن التجربة مقارنة مع خط أساس (قاعدة متجهات مخصّصة أو S3 Vectors/OpenSearch) باستخدام نفس المتجهات ونفس نموذج التضمين لمعرفة أثر خوارزمية الفهرس ومسافة التشابه.

• قبل البدء: ثبت نموذج التضمين والمعالجة المسبقة، حدِّد البُعد المناسب ودالة المسافة في فهرس DynamoDB.
• اختبارات يجب تشغيلها: recall@10/20/100، p99 latency عند الحمل، تأثير عمليات التحديث المتزامنة على نتائج البحث، وتكلفة الاستدعاءات على مدى أسبوع.
• مقارنة مرشحة: نفّذ نفس استعلامات البحث على قاعدة متجهات مخصّصة أو OpenSearch لقياس الفرق في recall/latency وTCO.

خطة القياس والاختبارات المقارنة

جهّز سيناريوهات تمثيلية: أحجام بيانات صغيرة ومتوسطة وكبيرة، وأنماط استعلام أحادية التقسيم وفنية فن-أوت لبحث عبر تقسيمات متعددة. سجّل هذه المقاييس: recall@K، p50/p95/p99 latency، تكلفة الاستعلامات لكل مليون طلب، زمن ملاحظة التحديث (staleness) بعد كتابة عنصر.

وثّق أدوات القياس والأوامر المستخدمة لتكون قابلة لإعادة التشغيل وقياس تأثير تغيّر نموذج التضمين أو المسافة.

• مقاييس ضرورية: recall@10/20/100، precision@K، p99 latency، تكلفة استدعاءات SearchVectors، زمن انعكاس التحديث.
• حجم العينة الموصى به للتجربة: 1k، 10k، 100k عنصر لكل Partition كنقطة بداية، وزد الحجم لاختبار النمو الأفقي.
• قارن بالخط الأساس: نفس المتجهات على FAISS/Pinecone/OpenSearch أو S3 Vectors.

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

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

ضع فواصل حساسية: هل تُخزن المتجهات لمستوى حساسية أعلى أم تفصل في جدول منفصل أو ميثاق تقسيم منفصل؟

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

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

استعمل هذه الأسئلة لاتخاذ قرار مبدئي: هل بياناتك في DynamoDB؟ هل تحتاج استرجاعاً داخل نطاق مستأجر واحد غالباً؟ هل تقبل حدود Top-K ومرشحات المطابقة الدقيقة؟ هل تتطلب ضبط فهرس متقدم؟

إذا كانت الإجابة عن الأسئلة الأولى نعم، نفّذ تجربة DynamoDB المتجهية. إذا كانت الحاجة إلى بحث عالمي أو مرشحات معقدة أو ضبط متقدّم — فكر في S3 Vectors أو OpenSearch أو قاعدة متجهات مخصّصة.

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

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

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

كيف أتحقق من ادعاءات الأداء والـ99% recall التي تشير إليها AWS؟ قم بتصميم التجربة التجريبية الموضّحة أعلاه: شغّل اختبارات recall@K وp99 latency مقابل خط أساس على نفس المتجهات وحمولات الاختبار الحقيقية لتطبيقك. صنّف النتائج كجزء من معايير قبول التجربة.

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

الخلاصة

سيوفّر دعم المتجهات داخل DynamoDB خياراً عملياً للفرق التي تبحث عن تقليل التعقيد التشغيلي ورفع قرب المتجهات من بيانات التشغيل. لكنه ليس بديلاً شاملاً لكل حالات البحث المتجهي المتقدّم. اعتمد مبدأ القياس: نفّذ تجربة مبكرة، قِس recall وكمون التهيئة، واختبر سيناريوهات متعددة المستأجرين قبل قرار الانتقال إلى الإنتاج.