تخزين طلبات Gemini API مفعّل افتراضيًا: كيف تضبط store=false لكل طلب ولكل مشروع

يُفعَّل تخزين طلبات Gemini API الآن افتراضيًا في المشاريع المدفوعة الجديدة. فأي مشروع مدفوع أُنشئ في 26 أكتوبر 2026 أو بعده يسجّل مطالبات Generate Content واستجاباتها ما لم يغيّر أحدٌ إعداد التخزين فيه. وتستمر الطلبات في النجاح في الحالتين، لذا قد يمر هذا التغيير دون أن يلاحظه أحد. وتتوقف أهمية ذلك على محتوى مطالباتك، وينبغي أن يكون الجواب قرارًا يُتخذ لكل مشروع على حدة. وتحوّل مراجعة التخزين AUCV أدناه (التدقيق Audit، والترقية Upgrade، والضبط Configure، والتحقق Verify) هذا الاختيار إلى فحص قابل للتكرار.

الخلفية: ما الذي تغيّر في مشاريع Gemini المدفوعة الجديدة

منذ 26 أكتوبر 2026، تخزّن مشاريع Gemini API المدفوعة الجديدة مطالبات Generate Content واستجاباتها افتراضيًا. أما المشاريع التي أُنشئت قبل ذلك التاريخ فيبقى التخزين فيها معطّلًا. وقد يتصرف مشروعان في المؤسسة نفسها، يشغّلان الشيفرة ذاتها، بشكل مختلف لمجرد اختلاف تاريخ إنشائهما.

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

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

ما الذي تحتفظ به Google، وإلى متى

مدة الاحتفاظ الافتراضية بالسجلات 55 يومًا، تنتهي بعدها صلاحية السجلات وتُعلَّم للحذف. ويمكن لمالكي المشاريع تقصير هذه المدة إلى 7 أو 14 أو 28 يومًا.

تحتاج مجموعات البيانات إلى اهتمام منفصل لأنها تتبع قواعد مختلفة. فالسجلات المحفوظة في مجموعة بيانات ليست لها مدة احتفاظ، وتبقى إلى أن يحذفها أحد. ويمكن تصدير مجموعات البيانات بصيغة CSV أو JSONL أو إلى Google Sheets، ما يجعلها مفيدة لأعمال التقييم. وتعني عمليات التصدير هذه أن النسخ قد تنتقل إلى خارج المشروع إن لم يتتبعها أحد.

افتراضيًا، لا تُستخدم المطالبات والاستجابات في سجلات المشاريع المفعّلة فيها الفوترة لتحسين منتجات Google أو تطويرها. وتُعد فئة المساهمين (Contributor Tier)، التي نتناولها في التحفظات أدناه، الاستثناء الذي ينبغي الانتباه إليه.

بعض النماذج والمدخلات لا تدعم التسجيل أصلًا. ويسرد ملخص BaristaLabs لدليل Google نماذج Imagen وVeo، ونماذج التضمين في Gemini، ونموذج Gemini Robotics، والمدخلات التي تحتوي على مقاطع فيديو أو صور GIF أو ملفات PDF، والوكلاء في المعاينة العامة.

أما الإسناد (grounding) فمسار احتفاظ منفصل تمامًا. إذ يُحتفظ ببيانات الإسناد باستخدام بحث Google والإسناد باستخدام خرائط Google لمدة 30 يومًا، ولا يمكن تعطيل هذا الاحتفاظ.

المرحلة 1 (التدقيق): جرد المشاريع وحِزم SDK والمسؤولين عن البيانات

ابدأ بقائمة تضم كل مشروع مدفوع في Gemini API تملكه مؤسستك، مع تاريخ إنشائه. وتعامل مع أي مشروع أُنشئ في 26 أكتوبر 2026 أو بعده على أنه يخزّن الطلبات إلى أن تتأكد من خلاف ذلك.

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

تستحق الخدمات التي تصل أيضًا إلى Vertex AI سطرًا منفصلًا في الجرد. إذ تصف ملاحظات إصدار Python وJavaScript كلتاهما خيار store بأنه «Gemini Developer API only» (لواجهة Gemini Developer API فقط). فإذا كانت بعض الخدمات تستدعي Vertex AI عبر SDK نفسها، فلا تفترض أن هذا الدليل يغطيها. راجع وثائق حوكمة بيانات Vertex AI في Google Cloud لتلك الخدمات، وسجّل ذلك القرار بجانب مشاريع Gemini Developer API لديك.

وبعد أن تعرف المشاريع وحِزم SDK العاملة، يبقى سؤال التدقيق الأخير سؤالًا يتعلق بالسياسة: ما أحمال العمل التي يجوز لها الاستمرار في التسجيل؟ احسم ذلك مع المسؤول عن البيانات ودوّن الإجابة مشروعًا تلو الآخر. ويُعد تصحيح الأخطاء الداخلي وأعمال التقييم مرشحين معقولين. أما الطلبات التي تحمل بيانات شخصية للعملاء فعادةً لا. وعلى سبيل التوضيح، تخيّل فريقًا لديه مشروعان في Gemini: مساعد دعم يلخّص التذاكر التي تحتوي على أسماء العملاء وتفاصيل حساباتهم، وبرنامج تقييم داخلي يعيد تشغيل مطالبات اصطناعية لمقارنة إصدارات النماذج. يُعطَّل التسجيل على مستوى المشروع في مشروع الدعم ويُضبط store=false في الشيفرة. أما مشروع التقييم فيمكنه الإبقاء على التسجيل مع نافذة احتفاظ قصيرة، لأن الطلبات المخزّنة هناك تساعد الفريق على تصحيح التراجعات وبناء مجموعات البيانات، ولن يثير أيٌّ من المحتوى تساؤلًا حول الخصوصية.

المرحلة 2 (الترقية): انقل كل خدمة إلى SDK تدعم store

يتطلب store على مستوى الطلب إصدارات SDK التالية على الأقل:

صدر كلٌّ من إصدار Python 2.33.0 وإصدار JavaScript 2.31.0 في 22 أكتوبر 2026، ويضيف كلاهما store إلى GenerateContentConfig. أما في Java وGo، فالحد الأدنى المذكور هو google-genai 1.79.0 وgoogle.golang.org/genai 1.76.0.

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

المرحلة 3 (الضبط): اضبط التسجيل على مستوى المشروع في AI Studio أولًا

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

بالنسبة للمشاريع التي لا ينبغي أن تخزّن الطلبات أبدًا، عطّل التسجيل على مستوى المشروع في AI Studio باتباع الخطوات الواردة في وثائق السجلات ومجموعات البيانات. وحيث يبقى التسجيل مفعّلًا لتصحيح الأخطاء أو التقييمات، قصّر مدة الاحتفاظ من 55 يومًا الافتراضية إلى 7 أو 14 أو 28 يومًا، بحسب ما يناسب سياسة بياناتك. وتحتاج مجموعات البيانات الموجودة إلى مراجعة خاصة بها، لأن تغيير مدة الاحتفاظ بالسجلات لن ينظّفها: احذف ما لا يحتاجه أحد، وسجّل أي عمليات تصدير بصيغة CSV أو JSONL أو إلى Google Sheets حتى تخضع لإجراءات التعامل المعتادة مع البيانات.

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

المرحلة 3، تتمة: إيقاف التخزين لكل طلب باستخدام store=false

الخطوة 1: اضبط store على false في GenerateContentConfig

الإعداد حقل اسمه store في GenerateContentConfig. وتتبع مقتطفات Python وJavaScript الشكل الموصوف في ملاحظات الإصدار. أما مقتطفات Java وGo فتعامل معها على أنها غير مُتحقَّق منها: إذ لم نتأكد من دالة البناء (builder) في Java أو نوع معاملها، ولا مما إذا كان الحقل Store في Go من النوع bool أو *bool، في الإصدارين v1.79.0 وv1.76.0. راجع ملاحظات الإصدار ووثائق حزمة Go قبل اعتمادها في الإنتاج.

Python:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="YOUR_MODEL_ID",
    contents="Summarize this support ticket...",
    config=types.GenerateContentConfig(store=False),
)

JavaScript:

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({});

const response = await ai.models.generateContent({
  model: "YOUR_MODEL_ID",
  contents: "Summarize this support ticket...",
  config: { store: false },
});

Java:

// Unverified shape: confirm the builder method and parameter type in 1.79.0.
GenerateContentConfig config = GenerateContentConfig.builder()
    .store(false)
    .build();

GenerateContentResponse response = client.models.generateContent(
    "YOUR_MODEL_ID", "Summarize this support ticket...", config);

Go:

// Unverified shape: confirm whether Store is bool or *bool in v1.76.0.
config := &genai.GenerateContentConfig{
    Store: genai.Ptr(false),
}

resp, err := client.Models.GenerateContent(ctx, "YOUR_MODEL_ID",
    genai.Text("Summarize this support ticket..."), config)

الخطوة 2: اجمع الإعداد في غلاف عميل واحد

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

الخطوة 3: افرضه باختبار أو بقاعدة lint

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

البث المتدفق والمعالجة الدفعية والمزوّدون الآخرون

الإعداد الافتراضي الجديد موصوف لطلبات Generate Content. وقبل افتراض أن مسارات البث المتدفق (streaming) أو المعالجة الدفعية (batch) تتصرف بالطريقة نفسها، راجع وثائق السجلات ومجموعات البيانات من Google وملاحظات إصدار Gemini API.

ويمكن للفرق التي تعتمد على أكثر من مزوّد أن تتشارك سياسة واحدة. فواجهة Responses API من OpenAI تحتفظ أيضًا بحالة التطبيق لمدة 30 يومًا افتراضيًا وتقبل store: false.

المرحلة 4 (التحقق): أثبت إيقاف التخزين باختبار العلامة المميزة

تُظهر الشيفرة ما طلبته. أما لوحة السجلات فتُظهر ما خُزّن فعلًا. والتحقق من الثانية يستغرق بضع دقائق.

1. أنشئ سلسلة علامة مميزة فريدة، مثل معرّف عشوائي مضافًا إليه تاريخ اليوم.
2. من المشروع قيد الاختبار، أرسل طلبًا واحدًا يحتوي على العلامة مع store=false.
3. من المشروع نفسه، أرسل طلبًا ضابطًا بعلامة مختلفة مع السماح بالتسجيل، إن كانت سياستك تسمح بتخزين مطالبة اختبار غير ضارة.
4. في لوحة سجلات AI Studio لذلك المشروع، رشّح السجلات الحديثة أو تصفّحها حسب الطابع الزمني وابحث عن العلامتين.
5. النجاح: يظهر الطلب الضابط فقط. الفشل: يظهر طلب store=false، فأعد التحقق من إصدار SDK أو الغلاف أو إعداد المشروع.
6. احذف إدخال السجل الخاص بالطلب الضابط إن كانت سياستك تتطلب ذلك.

إذا كان التسجيل على مستوى المشروع معطّلًا بالفعل

في هذه الحالة لن يظهر الطلب الضابط أيضًا، وعدم ظهور أيٍّ من العلامتين هو النتيجة المتوقعة. وهذا يُثبت أن شيئًا لم يصل إلى السجلات. لكنه لا يُثبت أن store=false يعمل بمفرده، لأن إعداد المشروع يمنع تخزين الطلب في كلتا الحالتين. ولعزل تأثير العلامة، كرّر الاختبار من مشروع اختبار مخصّص يكون التسجيل فيه مفعّلًا، باستخدام إصدار SDK والغلاف نفسيهما ومطالبات غير ضارة فقط.

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

الأخطاء الشائعة عند إيقاف تخزين طلبات Gemini

افتراض أن SDK أقدم ستحترم store. دون الحدود الدنيا الواردة في المرحلة 2، لا يتوفر هذا الحقل في GenerateContentConfig.

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

التعامل مع إيقاف التخزين على أنه انعدام تام للاحتفاظ. وفقًا لمقال على DEV Community، لا تزال مراقبة إساءة الاستخدام المنفصلة لدى Google تحتفظ بالمطالبات والمخرجات لمدة 55 يومًا، وتُستخدم فقط لإنفاذ السياسات. وتعطيل التسجيل لا يغيّر ذلك، كما أن الاحتفاظ ببيانات الإسناد يقع خارج هذه الإعدادات أيضًا.

ترك مجموعات البيانات القديمة في مكانها. لا تنتهي صلاحية مجموعات البيانات، وتقصير مدة الاحتفاظ بالسجلات لا يمسّها.

افتراض أن العلامة تشمل Vertex AI. تحصر ملاحظات إصدار SDK نطاق store في Gemini Developer API. استخدم خطوة Vertex AI الواردة في المرحلة 1.

قائمة التحقق لمراجعة التخزين AUCV

• [ ] التدقيق: اجرد مشاريع Gemini API المدفوعة وحدّد تلك التي أُنشئت في 26 أكتوبر 2026 أو بعده
• [ ] التدقيق: سجّل لغة SDK والإصدار المثبّت لكل خدمة، وحدّد استدعاءات Vertex AI
• [ ] التدقيق: اتفق مع المسؤول عن البيانات على أحمال العمل التي يجوز لها التسجيل
• [ ] الترقية: انتقل إلى Python 2.33.0 أو JavaScript 2.31.0 أو Java 1.79.0 أو Go 1.76.0 أو أحدث، وثبّت الإصدارات
• [ ] الضبط: عطّل التسجيل على مستوى المشروع حيث لا يُسمح بالتخزين، أو قصّر مدة الاحتفاظ إلى 7 أو 14 أو 28 يومًا
• [ ] الضبط: راجع مجموعات البيانات القديمة، وسجّل عمليات تصديرها، ثم احذفها
• [ ] الضبط: اضبط store=false في غلاف مركزي، مع فرضه باختبار أو بقاعدة lint
• [ ] الضبط: تحقّق من تغطية البث المتدفق والمعالجة الدفعية في وثائق Google
• [ ] التحقق: شغّل اختبار العلامة المميزة واحفظ سجلًا مؤرَّخًا
• [ ] التحقق: وثّق الاحتفاظ ببيانات الإسناد ومراقبة إساءة الاستخدام في إشعارات الخصوصية

التحفظات والأسئلة المفتوحة

لم تذكر Google ما إذا كانت المشاريع القائمة ستنتقل إلى الإعداد الافتراضي الجديد. وهذا وحده سبب كافٍ لضبط store=false في الشيفرة في المشاريع الأقدم أيضًا. وتوجد قواعد تغطية نقاط النهاية والأولوية في صفحتي السجلات وسجل التغييرات لدى Google، وقد تتغير دون إشعار، لذا أعد التحقق منها كلما رقّيت حِزم SDK.

رقم الـ 55 يومًا الخاص بمراقبة إساءة الاستخدام مصدره منشور مجتمعي وليس وثائق Google نفسها، لذا تحقّق منه مقابل شروط استخدام البيانات لدى Google قبل إدراجه في وثيقة سياسات.

قد يدفع التسعير المخفّض في الاتجاه المعاكس. إذ تصف Google فئة المساهمين (Contributor Tier) المتاحة بالدعوة فقط في معاينة خاصة، يحصل فيها المطورون المؤهلون على خصم يصل إلى 50% من تكاليف الرموز (tokens) على نماذج مختارة مقابل السماح باستخدام البيانات الواردة من تلك النماذج بموجب شروط الخدمات غير المدفوعة (Unpaid Services). وهذا يعكس الحماية الافتراضية لسجلات المشاريع المدفوعة، لذا أشرك المسؤول عن الخصوصية قبل الانضمام.

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

وإن كان مراجع خارجي سيفيدك، فبإمكان Optijara إجراء مراجعة التخزين هذه مع فريقك عبر Gemini ومزوّدي الذكاء الاصطناعي الآخرين الذين تستخدمهم.