RAG المؤسسي على بيانات سيلزفورس: بنية بتصمد

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

ليه الـ RAG على بيانات الـ CRM بيفشل أكتر من الوثائق؟

لأن مجموعة بيانات الـ CRM بتكسر الافتراضات اللي الـ RAG بتاع الوثائق متبني عليها.

• السجلات قصيرة ومتكررة. عشرة آلاف حالة عن نفس المنتج بيطلّعوا تمثيلات متشابهة جدًا، فبحث التشابه بيرجّعلك عشر نسخ من إجابة واحدة.
• المعنى موزّع على كائنات كتير. إجابة سؤال "ليه العميل ده مشي" موزّعة على حساب وتلات فرص وعقد وسلسلة حالة. مفيش سجل واحد شايلها.
• البيانات بتتغيّر على طول. الفرص بتتنقل مراحل، والحالات بتتقفل، وجهات الاتصال بتغيّر أدوارها. مجموعة الوثائق شبه ثابتة، أما الـ CRM فهدف متحرك ووراه فهرس.
• الوصول لكل مستخدم على حدة. اتنين بيسألوا نفس السؤال لازم ياخدوا إجابات مختلفة بشكل مشروع، وده سيناريو أغلب شروحات الـ RAG مش حاططاه في الحسبان أصلًا.

إيه الـ chunk الصح لما المصدر سجل في سيلزفورس؟

التقسيم حقل بحقل هو أكتر غلطة بيتطلب مننا تصليحها. قيمة الحقل مش وحدة معنى قابلة للاسترجاع. جمّع بدل ما تقسّم.

1. قسّم على مستوى حدث شغل، مش حقل. في الحالة: الموضوع والوصف والحل وسلسلة التعليقات، كلهم مقطع واحد. وفي الفرصة: السجل مع سبب الإغلاق والملاحظات الأساسية.
2. فكّ الروابط وحطّ الأسماء اللي بني آدم هيستخدمها. اسم الحساب، واسم المنتج، والرقم التسلسلي، ورقم العقد. التمثيلات المتجهية مش بتحل المفاتيح الخارجية.
3. خلّي ميتاداتا صريحة جنب المتجه. نوع الكائن، ومعرّف السجل، والمالك، والحساب، وتاريخ آخر تعديل. أي فلتر هتحتاجه وقت الاستعلام لازم يبقى ميتاداتا، مش نص.
4. سيب المطابقة الحرفية شغالة. أرقام الحالات وأكواد المنتجات وأكواد الأخطاء بالظبط هي أضعف نقطة في البحث المتجهي الصرف. البحث الهجين من سيلزفورس بيجمع فهرس الكلمات المفتاحية مع الفهرس المتجهي ويدمج النتائج المرتبة، بأداء أفضل من أي منهم لوحده (Salesforce Engineering).
5. أعد التضمين مع التغيير مش بجدول زمني. اربط إعادة الفهرسة بأحداث تغيير السجلات، وإلا الوكيل هيقتبس حالة الربع اللي فات وهو واثق.

إزاي تخلي الاسترجاع محترم للصلاحيات من غير ما تعيد بناء المشاركة؟

ده المطلب اللي بيفصل نظام RAG مؤسسي عن عرض تجريبي، وله شكل آمن واحد بس: فلتر قبل ما تسترجع، بهوية المستخدم اللي بيسأل.

تلات أنماط، مرتبة من الأمتن للأضعف.

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

أيًا كان المخزن اللي هتستخدمه، الهوية لازم تمشي من الأول للآخر: الجلسة، والاسترجاع، والـ prompt، وسجل التدقيق. وعمرك ما تطلب من النموذج اللغوي إنه يطبّق الصلاحيات. هو متنبّئ نصوص مش محرّك سياسات، وتعليمة في الـ prompt مش وسيلة حماية.

إزاي تعرف إن الاسترجاع كويس فعلًا؟

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

1. ابنِ مجموعة مرجعية من 100 لـ 200 سؤال حقيقي من مستخدمين حقيقيين، كل سؤال معاه معرّفات السجلات اللي بتجاوبه فعلًا.
2. قيس الاسترجاع لوحده بـ recall at k وmean reciprocal rank. لو السجل الصح مش في أول k، مفيش حاجة بعد كده هتنقذك.
3. تابع كمان دقة السياق. حشو الـ prompt بمقاطع شبه مكررة بياكل الميزانية ويخلي النموذج يتلكك.
4. شغّل المجموعة المرجعية في الـ CI مع أي تغيير في التقسيم أو التضمين أو الترتيب أو الفلاتر، واعتبر أي هبوط فشل في البناء.
5. وبعد كده بس قيّم الإجابات، مع اقتباسات لمعرّفات السجلات علشان المراجع يقدر يتأكد من سيلزفورس نفسها.

الفرق اللي بتضيف القياس ده بتكتشف غالبًا إن نسبة الاسترجاع الصحيح كانت حوالي النص، وإن مفيش ترقية موديل كانت هتحل ده.

الحزمة اللي بتصمد شكلها إيه؟

الأصلي ولا الخارجي أقل أهمية من عقد الاسترجاع. Data 360 بيدعم البحث المتجهي وأدوات الاسترجاع على المحتوى غير المهيكل زي مقالات المعرفة وملفات PDF والنصوص المفرّغة (مساعدة سيلزفورس)، وده بيخلي التأصيل قريب من البيانات وجوه حوكمة المنصة. والمخزن المتجهي الخارجي بيديك تحكم أكبر في التقسيم والترتيب الهجين والمجموعات العابرة للأنظمة، وده مهم لما الإجابة موجودة كمان في الـ ERP أو نظام التذاكر.

اختار أي واحد فيهم، بس اكتب العقد الأول: إيه هو الـ chunk، وإيه الميتاداتا اللي كل chunk بيشيلها، وإزاي بتتطبّق الهوية، وإيه اللي المجموعة المرجعية بتسميه كويس. إحنا بنبني أنظمة RAG وكيلية بالنمط ده عبر سيلزفورس وأكتر من 70 نظام مؤسسي، والوقت الأكبر بيروح للعقد مش للموديل. تفاصيل أكتر عن طريقتنا في تِكوندا.

FAQ

هل الموديل الأكبر بيصلّح الاسترجاع السيّئ؟

لأ. لو السجل اللي فيه الإجابة عمره ما دخل نافذة السياق، حجم الموديل مالوش لازمة. صلّح الاسترجاع الأول وبعدين قارن الموديلات.

أعمل fine-tuning بدل الـ RAG على بيانات الـ CRM؟

نادرًا. بيانات الـ CRM بتتغيّر كل يوم والوصول لكل مستخدم على حدة، فالموديل المضبوط هيبقى قديم ومش قادر يحترم المشاركة. الـ fine-tuning للسلوك والشكل، والاسترجاع للحقائق.

إزاي أمنع الوكيل إنه يسرّب سجلات المستخدم مش مسموحله بيها؟

فلتر المرشحين حسب صلاحيات المستخدم السائل قبل الترتيب، وسجّل كل عملية استرجاع بالهوية اللي عملتها. تعليمات الـ prompt مش تحكم في الوصول.

الفهرس يتحدّث كل قد إيه؟

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