لماذا يُرجع الـ Semantic Cache الخاص بك إجابات خاطئة

أبلغ أحد المستخدمين أن إضافة الترجمة الخاصة بنا تُرجع نفس النتيجة المخزنة مؤقتًا لكل طلب، بغض النظر عن المدخلات. قمنا بالتحقيق ووجدنا شيئًا أسوأ: 95% من جميع عمليات المطابقة في التخزين المؤقت الدلالي عبر منصتنا كانت إيجابيات كاذبة (false positives). 199 طلب ترجمة مختلف، 198 نص طلب فريد، واستجابة واحدة مخزنة مؤقتًا تم تقديمها لهم جميعًا.

إذا كنت تهتم بحالة الوكيل (agent state) طويلة الأمد ومعالجة طلبات الإنتاج، فإن هذا المقال يتكامل جيدًا مع لماذا يفقد وكيل الذكاء الاصطناعي الخاص بك ذاكرته، ودليل روبوت الدردشة بمفتاح API واحد، ودليل تحديد معدل طلبات واجهة برمجة تطبيقات الذكاء الاصطناعي.

النقاط الرئيسية

• كانت 95% من عمليات المطابقة في التخزين المؤقت الدلالي عبر المنصة إيجابيات كاذبة، حيث تم تقديم نفس الاستجابة المخزنة مؤقتًا لـ 198 طلبًا فريدًا.
• السبب الجذري هو المدخلات المهيكلة (structured input). حيث يهيمن نص القالب الثابت على متجه التضمين (embedding vector)، مما يجعل المحتوى المتغير بالكاد يؤثر على تشابه جيب التمام (cosine similarity).
• رفع عتبة التشابه لا يحل هذه المشكلة، لأن توزيعات المطابقة الصحيحة وغير الصحيحة تتداخل. تؤكد الأبحاث الحديثة حول موثوقية التخزين المؤقت الدلالي نفس النمط.
• يعمل الحل على طبقتين: استخراج المحتوى الهادف قبل التضمين، ثم التحقق من كل مطابقة باستخدام بصمة FNV-1a سريعة. أدى هذا إلى خفض الإيجابيات الكاذبة من حوالي 95% إلى أقل من 5%.
• يؤثر اختيار النموذج على مدى التعرض للمشكلة. تجعل مطالبات النظام (system prompts) الطويلة والمدخلات المغلفة بـ JSON المشكلة أسوأ بغض النظر عن النموذج الذي يقدم الإكمال؛ تحقق من دليل النماذج الخاص بـ TokenLab (تمت ملاحظته في 2026-07-07) لمعرفة خيارات النماذج الحالية إذا كنت تقرر أيها ستستخدمه لتوجيه حركة المرور المخزنة مؤقتًا.

تقرير الخطأ

كان التقرير بسيطًا: "لقد قمت بتعطيل التخزين المؤقت الدلالي، ولكن كل ترجمة تُرجع نفس النتيجة."

ثلاثة معرفات طلب، ثلاثة أجزاء ترجمة مختلفة، استجابات مخزنة مؤقتًا متطابقة. تراوحت نصوص الطلبات من 1,564 إلى 8,676 بايت. كان معرف الاستجابة المخزنة مؤقتًا هو نفسه عبرهم جميعًا: chatcmpl-DG6J03nhdvcF7Ek0C8rJkjh7lN9pF.

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

بيانات الإنتاج

قمنا بسحب بيانات مطابقة التخزين المؤقت لمدة 24 ساعة من ClickHouse. كانت الأرقام سيئة.

النموذج	إجمالي الطلبات	مطابقات التخزين المؤقت	طلبات فريدة	استجابات فريدة	معدل المطابقة
DeepSeek V4 Flash	200	199	198	1	99.5%
glm-4.6-thinking	100	38	13	1	38%
gpt-5-nano	31	29	28	2	93.5%
gpt-oss-120b	18	17	17	1	94.4%
qwen3-vl-flash	17	16	16	1	94.1%

198 طلب ترجمة فريد، جميعها تُرجع نفس الاستجابة المخزنة مؤقتًا. هذا ليس تخزينًا مؤقتًا، بل وظيفة معطلة تُرجع قيمة ثابتة.

اشترك كل نموذج متأثر في صفتين: جميع الطلبات جاءت من مستخدم واحد، وجميعها استخدمت قالب مطالبة نظام ثابت مع محتوى مستخدم متغير. للحصول على قائمة حالية بالنماذج المتاحة على المنصة، يُعد دليل النماذج الخاص بـ TokenLab (تمت ملاحظته في 2026-07-07) هو المصدر الموثوق نظرًا لأن التشكيلات تتغير كثيرًا.

كيفية اكتشاف ذلك في نظامك الخاص

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

إليك الاستعلام بأسلوب ClickHouse الذي استخدمناه، بشكل عام:

SELECT
  model,
  count() AS total_hits,
  uniqExact(substring(response_body, 1, 200)) AS unique_responses,
  round(uniqExact(substring(response_body, 1, 200)) / count(), 3) AS diversity_ratio
FROM request_logs
WHERE cache_hit = true
GROUP BY model
ORDER BY total_hits DESC;

يحتوي التخزين المؤقت السليم على diversity_ratio قريب من 1.0، مما يعني أن معظم المطابقات تُرجع استجابات متميزة لمدخلات متميزة. النسبة القريبة من 0 تعني أن العديد من الطلبات تنهار إلى حفنة من الإجابات المخزنة مؤقتًا. أي شيء أقل من 0.5 تقريبًا على نموذج ذي تنوع مدخلات حقيقي يستحق التحقيق.

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

علامة ثانية هي شكاوى المستخدمين التي تتجمع حول أعباء العمل المهيكلة. إضافات الترجمة، والمُلخصات، وأدوات ملء النماذج، وأدوات JSON-in/JSON-out هي المشتبه بهم المعتادون لأنها تغلف المحتوى المتغير في قالب ثابت.

لماذا تفشل التضمينات (Embeddings) في المدخلات المهيكلة

ترسل إضافة الترجمة طلبات مثل هذه:

System: "Act as a translation API. Output a single raw JSON object only.
         Input: {"targetLanguage":"","title":"...","segments":[...]}"

User:   {"targetLanguage":"zh","title":"Product Page",
         "description":"Translate product descriptions",
         "tone":"formal",
         "segments":[{"text":"actual varying content here"}]}

مطالبة النظام متطابقة عبر جميع الطلبات. رسالة المستخدم هي كائن JSON حيث targetLanguage و title و description و tone ثابتة. فقط segments[].text يتغير.

عندما يستخرج التخزين المؤقت الدلالي الخاص بنا النص للتضمين، فإنه يدمج مطالبة النظام ورسالة المستخدم. يمثل القالب الثابت حوالي 80% من النص. يقوم نموذج التضمين (all-mpnet-base-v2، 768 بُعدًا) بضغط هذا في متجه حيث تهيمن بنية القالب. محتوى الترجمة الفعلي بالكاد يحرك المؤشر.

النتيجة: يتجاوز تشابه جيب التمام بين "ترجم 'Hello world'" و "ترجم 'The quarterly financial report shows a 15% increase in revenue'" نسبة 0.95. عتبتنا هي 0.95. كل طلب ترجمة يطابق الإدخال المخزن مؤقتًا الأول.

بالتعمق في السجلات، وجدنا ثلاث طرق يحدث بها هذا الخلل:

إضافة الترجمة هي الأسوأ. مفاتيح وقيم JSON الثابتة تطغى على أجزاء الترجمة الفعلية. كلا النموذجين DeepSeek V4 Flash و gpt-5-nano وقعا في هذا.

كان لدى مساعد تلخيص السياق نوع مختلف من نفس المشكلة. كانت مطالبة النظام الخاصة به طويلة جدًا لدرجة أن محتوى المستخدم، الذي يتراوح من 5 كيلوبايت إلى 47 كيلوبايت، بالكاد ظهر في التضمين. هكذا انتهى الأمر بنموذج glm-4.6-thinking بإرجاع نفس الملخص لكل محادثة.

كان النمط الثالث أكثر دقة. بالنسبة لـ gpt-oss-120b و qwen3-vl-flash، كانت أول 500 حرف من كل طلب متطابقة بايت ببايت. جاء المحتوى المتغير بعد ذلك، ولكن التضمين كان مهيمنًا بالفعل بواسطة البادئة المشتركة.

ماذا تقول الأبحاث

هذه ليست مشكلة جديدة. لقد قامت أوراق بحثية حديثة بقياسها.

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

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

الحل المكون من طبقتين

الطبقة الأولى هي استخراج المحتوى. قبل التضمين، قم بإزالة مطالبة النظام الثابتة وسقالات القالب، وقم بتضمين الحمولة المتغيرة فقط: محتوى segments[].text الفعلي، وليس مفاتيح JSON المحيطة والقوالب الجاهزة. هذا وحده يزيد بشكل كبير من نسبة الإشارة إلى الضجيج في متجه التضمين.

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

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

معًا، أدت هاتان الطبقتان إلى خفض معدل الإيجابيات الكاذبة لدينا من حوالي 95% إلى أقل من 5% في حركة المرور المتأثرة.

متى يكون التخزين المؤقت الدلالي هو الأداة الخاطئة

التخزين المؤقت ليس هندسة مجانية، وبعض أعباء العمل لا تستحق التخزين المؤقت على الإطلاق.

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

يتألق التخزين المؤقت في عمليات الإكمال المتكررة، والثقيلة بالقوالب، والمكلفة، وهي بالضبط أعباء العمل التي يسهل فيها إدخال إيجابية كاذبة. هذا التوتر هو سبب أهمية طبقة التحقق. إذا كان هدفك هو التحكم في التكلفة بشكل أساسي، فمن الجدير إقران التخزين المؤقت بتوجيه أرخص للنماذج أيضًا. تغطي مقارنة الأسعار ودليل أفضل نماذج الذكاء الاصطناعي للبرمجة من أين تأتي الوفورات لكل رمز فعليًا، ويُظهر دليل النماذج الخاص بـ TokenLab (تمت ملاحظته في 2026-07-07) الخيارات الحالية، بما في ذلك خيارات التوجيه منخفضة التكلفة مثل DeepSeek V4 Flash و Gemini 3.5 Flash، إذا كنت توازن بين أي نموذج ستوجه إليه حركة المرور المخزنة مؤقتًا مقابل غير المخزنة مؤقتًا. تحقق من الأسعار الحالية في الدليل المرتبط قبل الالتزام بخطة توجيه.

لماذا لا نرفع العتبة فقط؟

عتبتنا هي بالفعل 0.95. رفعها لا يساعد. المشكلة هي أن المدخلات المتشابهة هيكليًا تنتج درجات تشابه أعلى من 0.95 بغض النظر عما يقوله المحتوى الفعلي.

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

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

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

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

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

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

هل تعتمد هذه المشكلة على النموذج الذي يقدم الإكمال؟ لا، تكمن مشكلة الإيجابيات الكاذبة في طبقة التضمين والمطابقة، وليس في نموذج الإكمال. أي نموذج خلف تخزين مؤقت دلالي، سواء كان DeepSeek V4 Flash، أو glm-4.6-thinking، أو شيئًا أحدث، سيتأثر بنفس الطريقة إذا قام التخزين المؤقت بتضمين نص قالب ثابت جنبًا إلى جنب مع محتوى متغير. تحقق من دليل النماذج الخاص بـ TokenLab (تمت ملاحظته في 2026-07-07) لمعرفة مدى توفر النماذج الحالية عند اتخاذ قرار بشأن النماذج التي يجب توجيهها عبر خط أنابيب مخزن مؤقتًا.