التخزين المؤقت الدلالي: عندما يتوقف النص عن كونه مفتاح التخزين المؤقت الصحيح

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

لماذا يفشل الخيار الافتراضي القديم

التخزين المؤقت التقليدي لواجهة برمجة التطبيقات (API) هو جدول تجزئة. يتم تجزئة الطلب، ويتم ربط الاستجابة بالتجزئة، ويعيد الطلب التالي المتطابق بالبايت القيمة المخزنة مؤقتًا. هذا النموذج صحيح لواجهات برمجة التطبيقات الحتمية لأن التجزئة تلتقط كل ما يهم في الطلب. لا توجد معلومات في الاستدعاء ليست موجودة في بايتاته.

أحمال عمل نماذج اللغة الكبيرة (LLM) تكسر هذا الافتراض ظاهريًا. ثلاثة مستخدمين في تدفق دعم العملاء يسألون عن نفس الشيء بثلاثة أشكال مختلفة:

حركة مرور المستخدمين · نافذة 60 ثانية

-- المستخدم أ: "كيف أعيد تعيين كلمة المرور الخاصة بي؟"

-- المستخدم ب: "لقد نسيت كلمة المرور الخاصة بي — ماذا أفعل؟"

-- المستخدم ج: "أين صفحة إعادة تعيين كلمة المرور؟"

بالنسبة لذاكرة تخزين مؤقت SHA-256، هذه ثلاثة مفاتيح، وثلاثة إخفاقات، وثلاث استدعاءات كاملة للمزود. أما بالنسبة للنموذج، فالقصد متطابق ويجب أن تكون الاستجابة متطابقة. ذاكرة التخزين المؤقت التي تجزئ النص الخام ليست ذاكرة تخزين مؤقت خاطئة؛ إنها ذاكرة تخزين مؤقت للطبقة الخاطئة من المعنى. النص هو وسيلة غير دقيقة لنقل القصد — نفس القصد له أسطح متعددة — والتخزين المؤقت بالمطابقة التامة يربط السطح بدلاً من الجوهر.

الفجوة كبيرة بما يكفي لتستحق الاهتمام. ذاكرة التخزين المؤقت التي تستجيب فقط للطلبات المتطابقة بالبايت تلتقط جزءًا صغيرًا من الاستدعاءات التي يمكن أن تلتقطها ذاكرة تخزين مؤقت تستجيب للقصد. سد هذه الفجوة هو ما يهدف إليه التخزين المؤقت الدلالي.

كيف يعمل التخزين المؤقت الدلالي

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

تفصيل دقيق: تتم مقارنة الرسالة الأخيرة فقط دلاليًا. كل شيء آخر — اسم النموذج، درجة الحرارة، الرسائل السابقة، موجه النظام، معرف المستأجر — يتم تجزئته بدقة. إذا لم يتطابق أي منها، فإن ذاكرة التخزين المؤقت تتعامل مع الطلبات على أنها مختلفة حتى لو كان السطر الأخير للمستخدم متطابقًا كلمة بكلمة. هذا هو الخيار الافتراضي الصحيح. سياق المحادثة المحمل مسبقًا يغير المعنى أكثر مما يتوقعه معظم المهندسين، وتريد أن تميل ذاكرة التخزين المؤقت إلى عدم دمج هذه السياقات.

لماذا تشابه جيب التمام، وليس المسافة الإقليدية

تعيش متجهات التضمين في فضاء عالي الأبعاد — 384 بُعدًا لـ MiniLM، و768 لـ BGE-base، و1536 لـ text-embedding-3-small. في تلك الهندسة، تهيمن على المسافة الإقليدية قيمة المتجه، وهي في الغالب ضوضاء؛ ما يحمل المعنى الدلالي هو الاتجاه. تشابه جيب التمام يزيل تأثير القيمة عن طريق حساب جيب تمام الزاوية بين متجهين — إنه ثابت بالنسبة للمقياس، لذا فإن متجهين يشيران في نفس الاتجاه يحصلان على درجة 1.0 بغض النظر عن الطول.

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

آلية عمل HNSW

البحث الساذج عن أقرب جار هو O(N) — حيث تقارن كل استعلامة بكل متجه مخبأ. عند مليون إدخال، تصبح ميزانية المقارنة غير عملية. تبني HNSW (الشبكة العالمية الصغيرة القابلة للتنقل الهرمي) رسمًا بيانيًا طبقيًا حيث تتصل كل عقدة بعدد قليل من الجيران المقربين، مع روابط أكثر تباعدًا في الطبقات العليا. يبدأ الاستعلام في الطبقة العليا، ويتجه بشراهة نحو أقرب تطابق، ثم ينزل طبقة، ويكرر العملية. تزور عملية البحث O(log N) من العقد — وهي تقريبية، ولكنها تحقق عادةً استدعاءً بنسبة 95-99% مقارنة بالبحث الدقيق، وهي أرخص بكثير. يأتي كل من Milvus و Qdrant مزودين بـ HNSW؛ ويستخدم TrueFoundry ما يتم تكوين النشر عليه.

اختيار نموذج التضمين

توازن التخزين المؤقت الدلالي بين قوة المعالجة ووقت الاستجابة وتكلفة المزود، لذا فإن نموذج التضمين هو القرار الأكثر أهمية في النظام. هناك خياران حقيقيان.

توفر النماذج المدارة — مثل text-embedding-3-small من OpenAI، و Cohere، و Voyage — فهمًا دلاليًا قويًا عبر المجالات المختلفة فورًا. التكلفة هي رحلة ذهاب وعودة عبر الشبكة في كل طلب، مما يؤثر مباشرة على مكاسب وقت الاستجابة الناتجة عن التخزين المؤقت. في TrueFoundry SaaS، يعتبر text-embedding-3-small (1536 بُعدًا) هو الافتراضي وغير قابل للتكوين من قبل المستخدم؛ وهذا اختيار متعمد للطبقة المدارة — وهو أساس جيد ومعروف ورخيص بما يكفي لتغطية تكلفته في كل استدعاء.

البدائل التي تعمل في الذاكرة مثل BGE-micro (384 بُعدًا) أو all-MiniLM-L6-v2 (384 بُعدًا) تعمل داخل عملية البوابة، وتلغي الاعتماد على الشبكة تمامًا، وتزيل رحلة التضمين ذهابًا وإيابًا من مسار الطلب. في الطبقة المحلية (on-premise)، يمكن تكوين نموذج التضمين عبر لوحة التحكم (عناصر التحكم ← الإعدادات ← التخزين المؤقت الدلالي)؛ وينطبق هذا الاختيار على مستوى البوابة بأكملها. بالنسبة لأعباء العمل الداخلية — مثل مساعدي البرمجة، والوثائق التقنية، وسير عمل دعم العملاء — عادةً ما يكون ضبط نموذج محلي صغير على مفردات المجال هو الخطوة الأعلى عائدًا على الاستثمار في المكدس بأكمله. يجب أن يتم تضمين “k8s” و “Kubernetes” في متجه متطابق تقريبًا. يعاملهما النموذج العام كأقارب؛ بينما يعاملهما النموذج المضبوط بدقة كمرادفات. وتتغير نسبة الإصابة وفقًا لذلك.

هناك ملاحظة عملية حول الأبعاد. تحمل التضمينات ذات الأبعاد الأعلى (1536) معلومات دلالية أكثر ولكنها تكلف أكثر للفهرسة والبحث؛ تستغرق HNSW ذات 1536 بُعدًا حوالي 4 أضعاف الذاكرة و 2 ضعف وقت البحث مقارنة بـ 384 بُعدًا. بالنسبة لمعظم أعباء عمل التخزين المؤقت، فإن مكاسب الاستدعاء الهامشية لـ 1536 مقارنة بنموذج 384 بُعدًا مضبوط بدقة تكون صغيرة بما يكفي لتجعل الوفورات التشغيلية هي الغالبة. ابدأ بـ 384 بُعدًا وانتقل إلى الأعلى فقط إذا بررت دقة الاستدعاء المقاسة على حركة المرور الحقيقية ذلك.

الجدول 1 — نموذج التضمين هو العامل الذي يحدد ما إذا كان التخزين المؤقت الدلالي يحقق مكسبًا في وقت الاستجابة أم لا يؤثر عليه بشكل كبير. في بيئة الإنتاج، المسار الذي يعمل في الذاكرة هو المسار الذي يبرر تكلفته.

تحديد عتبة التشابه الصحيحة

عتبة التشابه هي المفتاح الذي يوازن بين التوفير والمخاطر. كلما خفضتها، زادت نسبة الإصابة، وانخفضت التكلفة — وكذلك زادت فرصة حدوث إصابة خاطئة، مما يعيد إجابة قديمة أو خاطئة سياقيًا. يوجد هذا المفتاح داخل الطلب عبر x-tfy-cache-config:

HTTP · ترويسة الطلب

x-tfy-cache-config: {
  "type": "semantic",
  "similarity_threshold": 0.94,
  "ttl": 600,
  "namespace": "tenant-123"
}

نقطة البداية الموصى بها من TrueFoundry هي 0.9، مع نطاق يعتمد على مدى التسامح مع إصابات التخزين المؤقت غير الصحيحة.

الجدول 2 — نطاق العتبة. لا توجد قيمة "صحيحة" عالمية؛ العتبة الصحيحة هي تلك التي تتناسب مع تكلفة الإصابة الخاطئة في مجالك.

تجربة الفرز الطبي الفكرية تجعل الخطر ملموسًا. يمكن أن تسجل عبارتا "ذراعي اليسرى تؤلمني" و "ذراعي اليمنى تؤلمني" 0.91 في مساحة تضمين عامة الغرض. عند عتبة 0.90، يعيد التخزين المؤقت بكل سرور نصيحة متطابقة لحالتين متعاكستين جسديًا. بالنسبة لروبوت أسئلة شائعة عام، قد يكون 0.88 آمنًا تمامًا. أما بالنسبة للفرز الطبي، فهو سوء ممارسة. العتبة ليست معلمة فائقة عالمية؛ إنها ترميز لكل عبء عمل يوضح مدى تكلفة الإجابة الخاطئة.

منحنى الدقة/الاستدعاء

اختيار عتبة هو اختيار نقطة على منحنى الدقة/الاستدعاء الخاص بحركة المرور لديك. فيما يلي ما يبدو عليه هذا المنحنى عادةً لعبء عمل دعم العملاء — منحناك قد ينزاح إلى اليسار أو اليمين، لكن الشكل يظل كما هو:

‍

المنهجية الصحيحة لاختيار نقطة هي وضع الظل (shadow mode). لفترة زمنية قابلة للتكوين — عادةً أسبوع — يقوم التخزين المؤقت بحساب أوجه التشابه ويسجل ما كان سيتطابق عند كل عتبة دون تقديم استجابات مخبأة فعليًا. يراجع المهندسون السجل، ويرسمون نسختهم من المنحنى أعلاه مقابل حركة المرور الحقيقية، ويختارون عتبة تدفع الإصابات الخاطئة إلى مستوى يمكن أن يتحمله عبء العمل. العتبة ليست ثابتًا عالميًا؛ إنها مقبض ضبط لكل عبء عمل، ويجب أن تأتي بيانات الضبط من حركة مرور الإنتاج، وليس من الاستعلامات الاصطناعية.

في كل استجابة، تعيد البوابة ثلاث ترويسات تجعل هذه الحلقة قابلة للتصحيح: x-tfy-cache-status (إصابة / خطأ / عدم إصابة)، و x-tfy-cache-similarity-score (درجة جيب التمام عند الإصابات)، و x-tfy-cached-trace-id (معرف التتبع للطلب الأصلي الذي ملأ الإدخال). الثالث هو الذي ستعود إليه مرارًا وتكرارًا — فهو يتيح لك تتبع أي إجابة مخبأة إلى المحادثة التي أنتجتها، وهي الطريقة الوحيدة لتصحيح أي خطأ.

TTL وإلغاء الصلاحية للاستعلامات الديناميكية

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

تحتاج أعباء العمل إلى فترات صلاحية (TTL) خاصة بها. تعمل مساعدات التوثيق الثابتة بفترة صلاحية مريحة تمتد لعدة أيام لأن الحقيقة الأساسية هي المستندات، وتتغير المستندات بسرعة الإصدارات. تستخدم تطبيقات RAG إبطال الكاش بناءً على تجزئة المستند: عندما يتغير المستند المصدر، يتم مسح كل إدخال في الكاش مشتق منه تلقائيًا. الحقائق الحساسة للوقت (الأسعار، الجداول الزمنية) تحصل على فترات صلاحية قصيرة وصارمة ولا تتجمع أبدًا عبر فواصل الأيام. بالنسبة لهذه الحالات، غالبًا ما يكون التخزين المؤقت الدلالي هو الأداة الخاطئة، ويجب عليك العودة إلى المطابقة التامة أو عدم التخزين المؤقت على الإطلاق.

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

تدافع الكاش والكتابة الخلفية

هناك خطر تشغيلي واحد يستحق التصميم حوله بشكل صريح: تدافع الكاش. إذا انتهت صلاحية استعلام شائع ووصلت ألف طلب متطابق في نفس الثانية، فإن الكاش الساذج سيسمح لجميع الألف بالمرور إلى نموذج اللغة الكبير (LLM)، ثم سيحاول جميع الألف كتابة النتيجة مرة أخرى. تستخدم بوابة TrueFoundry دلالات "الرحلة الواحدة" (single-flight semantics) — أول طلب يفشل في العثور على إجابة يحصل على قفل لكل مفتاح؛ الطلبات المتطابقة اللاحقة أثناء استدعاء LLM تنتظر تلك الاستجابة الواحدة وتعيد استخدامها. الكتابة الخلفية غير متزامنة (يتم إرجاع الاستجابة إلى العميل فورًا، ويتم تثبيت المتجه في Milvus/Qdrant في الخلفية)، لذلك لا تظهر عمليات كتابة الكاش أبدًا في زمن استجابة مسار الطلب.

عزل متعدد المستأجرين

في أي نشر لبرمجيات كخدمة (SaaS) بين الشركات (B2B)، لا يُعد تلقي المستأجر "أ" لاستجابة مخزنة مؤقتًا تم إنشاؤها للمستأجر "ب" خطأً برمجيًا. إنه اختراق. يجب أن تكون بنية الكاش مصممة لتكون معادية لهذه النتيجة، وليس عن طريق التصفية اللاحقة.

تعزل TrueFoundry إدخالات الكاش على مستويين ولا يحتاج المستخدم للتفكير في المستوى الأول.

• المستوى الأول — المستخدم / الحساب الافتراضي (تلقائي). يتم تحديد نطاق كل إدخال في الكاش للمستخدم أو الحساب الافتراضي الذي أنشأه. لا يكون إدخال الكاش الذي أنشأه المستخدم "أ" مرئيًا أبدًا للمستخدم "ب"، حتى لو أرسلا نفس الطلب تمامًا. يتم فرض ذلك على طبقة التخزين، وليس وقت البحث.
• المستوى الثاني — مساحة اسم مخصصة (اختياري). ضمن مستخدم واحد أو حساب افتراضي واحد، يمكن تقسيم الإدخالات بشكل أكبر بواسطة سلسلة مساحة اسم. حالة الاستخدام الأكثر شيوعًا هي برمجيات كخدمة (SaaS) متعددة المستأجرين التي تواجه البوابة بحساب افتراضي واحد: تعيين مساحة الاسم إلى معرف المستأجر يمنح كل مستأجر مجموعة كاش معزولة داخل نفس الحساب. مررها عبر رأس تكوين الكاش جنبًا إلى جنب مع النوع وعتبة التشابه (similarity_threshold).

المستوى الأول كافٍ لمعظم الفرق. المستوى الثاني هو الأداة التي تلجأ إليها عندما يتفرع حساب افتراضي واحد إلى العديد من المستخدمين النهائيين — على سبيل المثال، خدمة SaaS تقوم بتوكيل طلبات LLM نيابة عن عملائها — ويكون الكاش الخاص بكل عميل هو ما تتطلبه التزاماتك المتعلقة بإقامة البيانات. في كلتا الحالتين، لا يوجد تجمع متجه عالمي يمكن أن يتسرب منه. هذا هو التنفيذ الذي يرضي مراجعي SOC 2 و HIPAA.

كيف يتكامل التخزين المؤقت الدلالي مع التخزين المؤقت من جانب المزود

لقد أطلقت كل من Anthropic و OpenAI ميزة التخزين المؤقت من جانب المطالبة (prompt-side caching): يقوم المزود بتجزئة بادئة من مطالبة النظام ويعيد استخدام الحالة الداخلية عند نجاح الكاش، مما يقلل التكلفة على رموز الإدخال المخزنة مؤقتًا. هذه طبقة مختلفة عما كنا نناقشه، وهما يتكاملان.

يقلل التخزين المؤقت للمطالبات من جانب المزود من وقت الوصول إلى الرمز الأول ويخفض تكلفة رموز الإدخال المخزنة مؤقتًا، لكن النموذج لا يزال يولد إكمالًا جديدًا. يلغي التخزين المؤقت الدلالي للبوابة استدعاء النموذج بالكامل. تستفيد معظم الفرق التي تستفيد من أحدهما من كليهما، ويُعد الكاش من جانب البوابة هو الرافعة الأكبر — تحسين زمن الاستجابة بمقدار كبير عند النجاح، وإلغاء التكلفة بالكامل، وطبقة يمكن للمؤسسة تصحيحها ومراجعتها وضبطها دون تدخل المزود. كاش المزود مبهم؛ كاش البوابة ملكك.

النقطة الأعمق

هناك ملاحظة قديمة في الأنظمة الموزعة: الكاش يحافظ على الدقة فقط عند طبقة المعنى التي صُمم لالتقاطها. يعمل كاش الصفحات لأن الصفحات هي وحدة الدقة. يعمل كاش الاستعلامات لأن الاستعلامات المتطابقة تنتج نتائج متطابقة. كاش LLM الذي يقوم بتجزئة النص يقوم بالتخزين المؤقت عند طبقة المعنى الخاطئة، ويظهر هذا الخطأ على شكل إخفاقات حيث كان ينبغي أن تكون هناك نجاحات.

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

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

هل أحتاج إلى كاشات منفصلة للمطابقة التامة والكاشات الدلالية؟

لا. التخزين المؤقت الدلالي هو مجموعة شاملة صارمة — المطابقة التامة هي مجرد تشابه جيب التمام (cosine similarity) بقيمة 1.0. في TrueFoundry، يؤدي تعيين نوع الكاش إلى دلالي أيضًا إلى إرجاع نجاحات المطابقة التامة. تشغيل كلتا الطبقتين بشكل منفصل هو بنية تحتية مكررة تعقد عملية الإبطال، وتتعامل البوابة معهما كطبقة واحدة.

ألن يؤدي استدعاء التضمين في كل طلب إلى إلغاء وفورات زمن الوصول؟

فقط إذا كنت تستخدم نموذج تضمين مستضاف عبر الشبكة على عبء عمل تفشل فيه معظم الاستدعاءات في العثور على البيانات المخزنة مؤقتًا. الهدف الأساسي من تشغيل نموذج صغير في الذاكرة على عقد البوابة هو إبقاء تكلفة التضمين أقل بكثير من العتبة التي قد تلغي الفائدة المحققة من الاستجابات الناجحة. في طبقة SaaS، نموذج التضمين الافتراضي هو text-embedding-3-small، والذي يضيف تقريبًا رحلة ذهاب وعودة واحدة عبر الشبكة؛ هذه هي تكلفة عدم الاضطرار إلى تشغيل أي بنية تحتية للتضمين بنفسك.

كيف أتجنب الإصابات الخاطئة الكارثية أثناء النشر؟

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

كيف تتفاعل الذاكرة المؤقتة مع التدفق واستدعاءات الأدوات طويلة الأمد؟

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

ماذا يحدث إذا تعطل فهرس المتجهات؟

تتراجع البوابة إلى إعادة توجيه كل طلب إلى مزود LLM. تكلف الاستدعاءات الفاشلة في الذاكرة المؤقتة ما كانت ستكلفه بدون الذاكرة المؤقتة؛ لا شيء يتعطل. الإشارة التشغيلية الوحيدة هي رأس x-tfy-cache-status: error في الاستجابات، والذي يجب ربط تنبيه لوحة التحكم به. موثوقية مسار الطلب تتفوق على توفر طبقة الذاكرة المؤقتة.

‍