كنت أعامل مسار RAG الخاص بي كأنه صندوق أسود. تدخل التضمينات (Embeddings)، وتخرج الإجابات، وفي مكان ما بينهما، كانت فاتورة السحابة الخاصة بي تتضخم. ومثل معظم المطورين الذين تحدثت معهم، افترضت أن نماذج المتجهات الكثيفة (dense vector models) هي المسبب الرئيسي للتكاليف؛ فقد بدت باهظة الثمن. كان تحويل ألف صفحة إلى أرقام عشرية عالية الأبعاد (high-dimensional floats) يبدو وكأنه عملية تصنيع ثقيلة، لذا تعاملت مع الأمر بحذر شديد. حتى أنني قمت ببناء طبقة تخزين مؤقت (caching layer) خصيصًا لتجنب إعادة تضمين البيانات التي قمت بمعالجتها بالفعل. كنت فخورًا بهذا التحسين، ثم فتحت الفاتورة وأجريت الحسابات.

لقد كنت أقوم بتحسين الشيء الخاطئ تمامًا.

فخ التضمين (The Embedding Trap)

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

ومع ذلك، لا تزال الأسطورة قائمة. جزء من الارتباك هو هيكلي؛ فمسار الاستيعاب (ingestion pipeline) هو المكان الذي يبذل فيه المهندسون طاقتهم الأولى. أنت تكتب أداة تقسيم النصوص (chunker)، وتصارع أداة الترميز (tokenizer)، وتراقب أشرطة التقدم وهي تزحف عبر شاشة الطرفية (terminal). هذا الجهد المرئي يخلق وهمًا بالتناسب؛ إذ يبدو وكأنه الجزء المكلف لأنه الجزء الذي يتطلب جهدًا مكثفًا. لكن الجهد والتكلفة ليسا شيئًا واحدًا، وفي أنظمة RAG، غالبًا ما تكون العلاقة بينهما عكسية.

ثلاث فواتير مختلفة تمامًا

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

التضمينات (Embeddings) هي تكلفة تصنيع تُدفع لمرة واحدة. أنت تدفع لتحويل المستندات إلى متجهات، ثم تنتهي المهمة. إذا كانت مستنداتك ثابتة، فإن هذا البند يكاد لا يظهر في فاتورتك الشهرية.

قواعد بيانات المتجهات (Vector databases) هي إيجار للبنية التحتية. أنت تدفع لإبقاء النظام يعمل على مدار الساعة. تدفع مقابل أقراص SSD التي تحفظ ملايين الأجزاء، ومقابل نوى المعالج (CPU cores) التي تحافظ على الفهارس، ومقابل الشبكة التي تقدم عمليات بحث في أقل من 100 مللي ثانية. هذه التكلفة حقيقية، وتتوسع مع حجم البيانات، لكنها قابلة للتنبؤ بشكل عام. إنها تشبه اشتراك النادي الرياضي؛ سواء قمت بإجراء استعلام واحد أو عشرة آلاف مرة، تظل تكلفة البنية التحتية الأساسية كما هي تقريبًا.

النماذج اللغوية الكبيرة (LLMs) هي ضرائب استهلاك. كل سؤال يطرحه المستخدم يؤدي إلى فاتورة. كل رمز (token) يخرج من طبقة الاسترجاع (retrieval layer) ويدخل في المطالبة (prompt) يكلف مالاً. كل خطوة استدلال، وكل تعليمات تنسيق، وكل استشهاد تطلب من النموذج إنتاجه يضيف وزنًا مجهريًا. لكن هذه الرسوم المجهرية تتضاعف مع عدد الجلسات، وعدد الجلسات في اتجاه تصاعدي. هنا يتراكم زمن الاستجابة (latency) مع الإنفاق؛ فالاستعلام البطيء ليس مزعجًا للمستخدم فحسب، بل هو يحرق الأموال فعليًا بينما ينتظر المستخدم.

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

أين تذهب الأموال حقًا

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

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

كيفية خفض التكاليف دون تعطيل مسار العمل الخاص بك

يتطلب توفير المال في نظام RAG مطابقة التكتيك مع نموذج التكلفة. إليك ما ينجح حقًا.

قم بإزالة التكرار قبل المعالجة

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

من الناحية العملية، قم بتخزين بيان (manifest) خفيف الوزن يربط مسارات الملفات بمجموع التحقق (checksums) الخاص بها. عندما يستيقظ المجدول، اجعله يتحقق من البيان أولًا. يجب ألا يمر عبر الـ chunker إلا الأقلية من الملفات التي تغيرت.

قم بتحديث المستندات، لا تستبدلها

عندما يتغير مستند ما، قاوم غريزة التعامل معه كملف جديد تمامًا. قد تتلقى مواصفة تقنية مكونة من خمسين صفحة مراجعة من فقرتين فقط في القسم الرابع. إذا قام مسار العمل الخاص بك باستبدال الملف بالكامل، فستقوم بإعادة التجزئة (re-chunk) وإعادة التضمين (re-embed) لتسعة وأربعين صفحة سليمة تمامًا دون سبب.

بدلاً من ذلك، قارن النسخة الجديدة بالقديمة. حدد الفرق (delta). ثم أعد التجزئة وإعادة التضمين للأقسام التي تغيرت فقط. استخدم البيانات الوصفية (metadata) مثل أرقام الصفحات، أو معرفات الأقسام، أو مرساة العناوين، أو نطاقات الفقرات لتتبع الحدود. إذا كانت استراتيجية التجزئة لديك تحترم هيكل المستند، فسيكون هذا أمرًا مباشرًا. وإذا لم تكن كذلك، فإن إصلاح الـ chunker الخاص بك هو استثمار أفضل من شراء عنقود استدلال (inference cluster) أكبر. إن التكلفة الهندسية للحفاظ على مسار عمل يدرك الفروقات (diff-aware) ستعوض نفسها في غضون أسابيع بمجرد توسع عدد مستنداتك.

واجه التكاليف المتكررة مباشرة

بما أن استدعاءات LLM تتم مع كل استعلام، فإن توفير حتى بضع رموز (tokens) أو تخزين حفنة من الاستجابات مؤقتًا يحقق عوائد ضخمة. ابدأ بتخزين الأوامر مؤقتًا (prompt caching). إذا سأل مستخدم عن سياسة الاسترداد وسأل مستخدم آخر نفس الشيء بعد عشر دقائق، فلا يوجد سبب لاستدعاء النموذج مرتين. قم بتخزين أزواج (الاستعلام-الاستجابة) الأخيرة مع مطابقة التشابه الدلالي (semantic similarity). عندما يقع سؤال جديد ضمن عتبة تشابه مع سؤال مخزن مؤقتًا، قم بإرجاع الإجابة المخزنة مباشرة. لن يتم توليد رموز، ولن تُنفق دولارات.

بعد ذلك، انظر بدقة في جودة الاسترجاع (retrieval quality) لديك. فالمسترجع (retriever) غير الدقيق يجبر الـ LLM على قراءة كومة قش للعثور على إبرة. إذا حشوت الأمر (prompt) بعشرين جزءًا غير ذي صلة لأن حد الـ top-k الخاص بك فضفاض للغاية، فأنت تدفع للنموذج لقراءة الضجيج. قم بتضييق نطاق الاسترجاع. قلل من الـ top-k. قم بضغط الأجزاء (chunks) قبل إرسالها. قم بإزالة التذييلات والترويسات النمطية (boilerplate) أثناء الإدخال حتى لا تصل أبدًا إلى الأمر. كل رمز (token) تزيله من نافذة السياق (context window) هو جزء من سنت يتم توفيره، وتلك الأجزاء تتراكم عبر آلاف الاستعلامات اليومية.

كما أن الاسترجاع الأفضل يحسن زمن الاستجابة (latency)، وهو شكل آخر من أشكال التكلفة. فالمستخدمون يتخلون عن الواجهات البطيئة. الإجابة الأسرع هي الأرخص إنتاجًا والأفضل للاحتفاظ بالمستخدمين.

الخلاصة الحقيقية

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

المصدر: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing

انضم إلى النقاش في مجتمع GyaanSetu AI للتعلم.