تخطّ إلى المحتوى
كل الرؤى بنية الذكاء الاصطناعي للقطاع المالي

استراتيجيات التخزين المؤقت لأنظمة نماذج اللغة الكبيرة في القطاع المالي

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

متخصصون في القطاع المالي يعملون على مبادرة للذكاء الاصطناعي

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

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

التخزين المؤقت للموجّهات: الطبقة المجانية

يعيش التخزين المؤقت للموجّهات (prompt caching) لدى مزوّد الخدمة. تُحدّد بادئة ثابتة من الموجّه، فيخزّن المزوّد حالة الانتباه (attention state) المحسوبة لها، بحيث يتخطّى الاستدعاء التالي الذي يحمل البادئة نفسها إعادة معالجة تلك الرموز. في الموجّهات المالية، تكون البادئة عادةً كبيرة وثابتة: تعليمات النظام، ومخططات الأدوات والدوال (tool and function schemas)، وجزء من وثيقة سياسة أو من جدول تعرفة، وأحياناً بضعة أمثلة محلولة. لا يتغيّر هذا المحتوى بين الطلبات، وكثيراً ما يبلغ آلاف الرموز. ودفع سعر الإدخال كاملاً له في كل استدعاء هدرٌ محض.

قاعدتان تجعلان هذا مُجدياً:

  • رتّب الموجّه بحيث يجلس كل ما هو ثابت في المقدّمة، وكل ما هو خاص بالطلب في النهاية. يطابق التخزين المؤقت على أساس البادئة، فرمز متغيّر واحد قرب الأعلى يُبطل الأمر برمّته. ضع العميل والحساب وتاريخ المرجعية (as-of date) والمقاطع المُستخرَجة في النهاية.
  • أبقِ البادئة متطابقة على مستوى البايت. طابع زمني مُعاد توليده، أو مفتاح JSON أُعيد ترتيبه، أو مسافة زائدة في النهاية، أي منها يكسر التطابق. إن كنت تُنشئ قالباً لموجّه النظام، جمّد القالب واحقن المتغيّرات فقط بعد حدّ التخزين المؤقت.

هذه الطبقة هي أول ما ينبغي تفعيله، لأن بناءها لا يكلّفك شيئاً ولا يغيّر ما يراه النموذج. المأخذ عليها هو قِصر مدّة البقاء (time-to-live) لدى المزوّد؛ فذاكرة مؤقتة تنتهي صلاحيتها خلال دقائق قليلة لا تفيد إلا في حركة المرور المتقطّعة (bursty traffic). أما مع الحِمل الثابت فهي أقرب إلى مال مجاني. وبالنسبة لمهمة إعادة معالجة ليلية تصيب البادئة نفسها مئة ألف مرة، فهي بند تكلفة ضخم يُوفَّر.

التخزين المؤقت الدلالي: سريع لكنه حادّ

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

الفخّ هو أن تشابه النص لا يعني تطابق الإجابة. اسأل “ما الرصيد المستحق على هذا الحساب؟” عن عميلين مختلفين، فتحصل على جملة واحدة بإجابتين صحيحتين مختلفتين، والتضمين (embedding) عاجز عن رؤية الحساب الكامن خلف الكلمات. قد يتطابق سؤالان في إجراءات “اعرف عميلك” (KYC) تطابقاً شبه تام في الصياغة، ويحملان إجابتين صحيحتين متعاكستين بمجرد تغيّر الشخص المعني. إن كان التضمين هو مفتاحك بأكمله، فستقدّم إجابة عميل لعميل آخر، وهذا حادث تسريب (leakage incident)، لا مجرد إخفاق في التطابق.

لذا فالمفتاح ليس أبداً التضمين وحده. إنه مفتاح مركّب:

  • التقسيم الصارم أولاً. يدخل المستأجر (tenant)، ومعرّف العميل أو الكيان، وتاريخ المرجعية أو إصدار البيانات في مكوّن يعتمد على التطابق التام (exact-match) من المفتاح. ولا يجري التطابق الدلالي إلا داخل ذلك التقسيم. وهذا يمنع أيضاً حركة مرور مستأجر من تسخين ذاكرة مستأجر آخر، وهو أمر مهمّ للعزل ولسرد التدقيق.
  • اضبط عتبة التشابه عالية، وعامِل التطابقات شبه المكتملة على أنها إخفاقات. بالنسبة لأسئلة تسويقية شائعة، عتبة متساهلة تفي بالغرض. أما بالنسبة لأي شيء يُنتج رقماً أو قراراً، فالجار الأقرب سؤال مختلف. تكلفة التطابق الزائف هنا هي رقم خاطئ في تقرير، لذا حرّف العتبة نحو الحساب من جديد.
  • احتفظ بمجموعة تقييم (eval set) من أزواج إعادة الصياغة ومن حالات عدم التطابق المعروفة، وقِس معدّل التطابق الزائف (false-hit rate) عليها قبل أن توسّع العتبة. للتخزين المؤقت الدلالي ميزانية إيجابيات زائفة تماماً كما لأي نموذج فحص (screening model)، وعليك تتبّع انحراف (drift) ذلك المعدّل مع مرور الوقت.

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

التخزين المؤقت للنتائج: مُفهرَس على البيانات، لا على الساعة

يخزّن التخزين المؤقت للنتائج (result caching) المخرجات النهائية لخطّ معالجة (pipeline)، مُفهرَسة على مدخلات تامة الدقة. إنها أقدم الأفكار وأكثرها أماناً، وفي القطاع المالي هي عادةً الأهمّ، لأن قدراً كبيراً من العمل عديم الأثر الجانبي (idempotent). إثراء معاملة، أو حلّ هوية كيان، أو استخراج حقول من إفصاح تنظيمي، أو تقييم مستند مقابل سياسة: مرّر المدخلات نفسها عبر إصدار الخطّ نفسه، وينبغي أن تحصل على المخرجات نفسها. وحسابها مرتين هدرٌ خالص.

المفتاح هو المُحدِّد الكامل للإجابة، وضبطه على نحو صحيح هو المهمّة برمّتها:

  • تجزئة محتوى (content hash) للإدخال، لا معرّف قابل لإعادة الاستخدام. إن أُعيد رفع مستند بالمعرّف نفسه لكن ببايتات مختلفة، فإن الذاكرة المُفهرَسة على المعرّف تقدّم الاستخراج القديم. جزّئ المحتوى.
  • إصدار الخطّ، وإصدار الموجّه، ومعرّف النموذج. حين تغيّر الموجّه أو تنقل النموذج، لا تعود النتائج القديمة إجابات صالحة للسؤال الجديد. ورفع رقم الإصدار يُبطلها دون الحاجة إلى مسح كامل (flush).
  • لقطة البيانات أو إصدار دفتر الأستاذ (ledger version) التي قرأتها العملية الحسابية. هذا هو انضباط النقطة الزمنية (point-in-time) الذي يُبقي الذاكرة نزيهة. اجعل المفتاح مبنياً على إصدار المصدر، فأيّ إعادة عرض (restatement) أو تصحيح متأخر الوصول يغيّر المفتاح، ومن ثمّ لا تستطيع عملية إعادة المعالجة تقديم أرقام حُسبت قبل التصحيح. لن تنقذك مدّة الصلاحية (TTL) وحدها هنا؛ فمدّة صلاحية من خمس دقائق ستعيد رصيداً قديماً بكل سرور بعد أربع دقائق من ترحيل قيد.

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

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

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

ما الذي ينبغي أن أخزّنه مؤقتاً أولاً إن كنت سأفعل شيئاً واحداً فقط؟

فعّل التخزين المؤقت للموجّهات (prompt caching) لدى مزوّد الخدمة للجزء الثابت من موجّهك: تعليمات النظام، ومخططات الأدوات (tool schemas)، ووثائق السياسات الطويلة. لا يتطلب ذلك أي بنية تحتية خاصة بك، ويخفّض تكلفة رموز الإدخال (input tokens) للجزء من الموجّه الذي لا يتغيّر أبداً بين الاستدعاءات.

هل التخزين المؤقت الدلالي (semantic cache) آمن لأعباء العمل المالية؟

فقط مع عتبة تشابه مرتفعة ومفتاح محصور بنطاق المستأجر (tenant-scoped key). قد يحمل سؤالان متشابهان في الصياغة إجابتين صحيحتين مختلفتين بمجرد اختلاف العميل أو الحساب أو تاريخ المرجعية (as-of date)، لذا يجب ألّا يكون التضمين (embedding) هو المفتاح بأكمله أبداً. حين يكون المقصد إفصاحاً تنظيمياً أو قراراً يخصّ عميلاً، عامِل التطابق شبه المكتمل على أنه إخفاق في التطابق.

كيف أمنع التخزين المؤقت من تقديم أرقام قديمة في نهاية الربع المالي؟

اجعل مفتاح التخزين المؤقت للنتائج مبنياً على إصدار البيانات أو لقطة دفتر الأستاذ (ledger snapshot) التي حُسبت الإجابة على أساسها، لا على مدة الصلاحية (TTL) وحدها. حين يُحدَّث المصدر الأساسي، يتغيّر الإصدار ولا يعود المدخل القديم قابلاً للوصول، ما يمنع عملية إعادة معالجة من تقديم أرقام حُسبت قبل إعادة العرض (restatement).

قراءات ذات صلة

#العمارة التقنية

ضبط تكلفة نماذج LLM حين يسأل قسم المالية عن كلفة كل استعلام

فاتورة LLM التي تبدو سليمة في إجماليها تُخفي أين يذهب المال فعلاً. إليك كيف نُبقي كلفة الاستعلام الواحد منخفضة بما يكفي لتصمد أمام أسئلة المدير المالي.

#توجيه

توجيه النماذج والتحوّل الاحتياطي من أجل التكلفة والموثوقية

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

#المراقبة

مراقبة نماذج اللغة الكبيرة وتتبّعها في أعباء العمل المالية

لا يمكنك تصحيح ما لا تستطيع رؤيته. إليك إعداد التتبّع (tracing) والتسجيل والتقييم في بيئة الإنتاج الذي نعتمده للحفاظ على قابلية تشخيص نظام مالي مبني على نماذج اللغة الكبيرة (LLM).

#الاستدلال

دفعي أم آني؟ أنماط الاستدلال في الذكاء الاصطناعي المالي

ليست كل درجة تقييم بحاجة إلى أن تُحسب لحظة الطلب. إليك كيف نفصل الحساب المسبق الدفعي عن الاستدلال الآني (real-time inference) لبلوغ أهداف الكلفة وزمن الاستجابة.

تعمل على شيء مشابه؟

أخبِرنا عن بياناتك وسير العمل المحيط بها، وسنعطيك رأياً صريحاً.

احجز مكالمة تعريفية مدتها 30 دقيقة