بيانات شخصية مقسومة بين جزأين: لماذا يمرّرها الفحص الجاري على كل جزء وحده

إعادة الإنتاج: «user@exa» ثم «mple.com»

يبثّ النموذج إجابته دفعاتٍ مقسومة على حدود الرموز لا على المعنى. ولذلك يصل عنوان البريد الإلكتروني أو رقم البطاقة أو مفتاح API مقسومًا في العادة:

chunk 1:  "...you can reach me at user@exa"
chunk 2:  "mple.com whenever you like."

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

لماذا لا يرى الفحصُ الجاري على كل جزء هذا العطل

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

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

لا يجوز إخراج نصّ قبل أن يثبت أن لا مطابقة يمكن أن تمتدّ إليه. الاكتشاف ليس منعًا.

أربعة مشاريع وقعت فيه باستقلال، وخامس وثّقه

قواعد كود منفصلة، ولغات منفصلة، وفرق منفصلة؛ ولا بلاغ منها يستشهد بالآخر. والحالة كما تحقّقنا منها في 24 سبتمبر 2026:

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

صار للصنف اسم: «split-boundary leaks»

في 22 سبتمبر 2026 نشر Ninad Phalak تقرير Split-Boundary Leaks in Streaming Guardrails على Zenodo برخصة CC BY 4.0 — doi.org/10.5281/zenodo.22909585. يجمع التقرير الحالات الأربع أعلاه، ويعدّ حالة Vercel نقصًا معترفًا به لا إخفاقًا خامسًا، ويسمّي الخاصية التي تنقص الأربعة.

وتوضيحان لازمان: التقرير صادر عن منتج منافس، وهو لا يفحص أي مكتبة ولا يزكّي أيًّا منها، بما فيها مكتبتنا. والاسم اسمه: فإن كتبت عن هذا الصنف فاستشهد بالـDOI بدل إعادة تسميته، لأن صنفًا باسم واحد أسهل على الفريق التالي أن يجده من الصنف نفسه بأربعة أسماء.

الشرط الثابت: ناتج مطابق بايت ببايت لتصفية النص كاملًا

لأي طريقة لتقسيم المُدخل نفسه، يجب أن يكون الناتج المبثوث مجمّعًا مطابقًا بايت ببايت لتصفية النص كاملًا دفعة واحدة.

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

هل تفحص مكتبتك كل جزء وحده أم تحتفظ بحالة بينها؟

ثلاثة فحوص تجيب دون قراءة كود أحد:

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

وجود مخزن مؤقّت ليس احتجازًا للنص

هذا هو الفارق الذي يوقع مهندسين جيّدين. فحالة الاكتشاف وسياسة الإخراج قراران منفصلان، والثاني وحده هو ما يوقف التسريب. وقد جاءت حزمة Umbraco للذكاء الاصطناعي بهذا الشكل تمامًا: نافذة منزلقة تكتشف بشكل صحيح بينما يخرج كل جزء فور وصوله. والإصلاح المدموج في 22 سبتمبر 2026 عنوانه «make streaming post-generate guardrails actually block/redact»، والذي تغيّر فيه هو سياسة الإخراج لا الكاشف.

احتجاز ثابت بمقدار N محرفًا تسريبٌ قابل للضبط

احتجِز آخر 20 أو 50 أو 64 محرفًا، وألحقها بالجزء التالي، ثم افحص وأخرِج: تنجح الحيلة حتى تأتي مطابقة أطول من N — وحينها تفشل صامتة، لأن الناتج يظلّ يبدو محجوبًا. ويحمل LiteLLM إعدادًا اسمه stream_holdback_chars عبر ثمانية ملفات مصدرية، وفي 24 سبتمبر 2026 عبر صفر ملفات توثيق؛ أي أن الرقم الذي يقرّر إن كنت تسرّب لا يراه معظم المشغّلين.

وتذكر وثائق Vercel AI SDK الآن الصيغة العامة لذلك في ملاحظة تحت مثالها: على أي تنفيذ تدريجي أن يحتفظ بكل مطابقة ناقصة محتملة، والمخزن ذو الحجم الثابت وحده غير آمن مع الأنماط متغيّرة الطول بلا حدّ. وكتلة مفتاح PEM أو رمز JWT طويل مثالان على ذلك.

وللإصلاح نفسه عطله

عطلان يأتيان مع الإصلاح:

• الإفساد. الحجب يغيّر طول النص، فإن قطعت النص المحجوب بمواضع حُسبت على النص الخام وقعت داخل علامة الحجب وأكلت محارف صحيحة. وبلاغ Mastra يذكر هذه الحالة إلى جانب التسريب.
• إنذارات كاذبة عند إعادة اللصق. يصف NVIDIA NeMo Guardrails #1197 مسافةً تُدرَج عند سحب الرموز من المخزن: فمع مُرمِّز دون الكلمة تصل «assisting» على هيئة «ass» و«isting» فتبلغ مسار المخرجات «ass isting»، مُطلِقةً مخالفة على كلمة لم توجد أصلًا.

«خزّن كل شيء أو ابثّ وسرّب» مفاضلة زائفة

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

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

الاختبار الذي يكشف الصنف كلّه

ليس إطارًا جديدًا، بل تأكيد واحد يُشغَّل على كل تقسيم لكل حالة:

for (const text of fixtures) {
  const whole = filterWholeString(text);
  for (let size = 1; size <= text.length; size++) {
    let streamed = '';
    const f = createFilter();
    for (let i = 0; i < text.length; i += size) streamed += f.push(text.slice(i, i + size));
    streamed += f.flush();
    assert.equal(streamed, whole);        // chunking invariance
  }
}

وضَع في الحالات نمطًا غير محدود الطول — كتلة PEM أو JWT طويلًا — وإلا نجحت المجموعة على تنفيذ يُطلق عند التجاوز. وأضِف قيمة ملتصقة بنصّ غير ASCII، ولغةً تُكتب بلا مسافات، لأن ذيلًا محدودًا بفواصل الكلمات ينمو فيها بلا حدّ.

من أين جاء هذا النص

ننشر llm-stream-guardrails، وهي مكتبة برخصة MIT تنفّذ تصميم نقطة الحسم وتعلن الشرط الثابت عقدًا لها، ومشرفها هو من أبلغ Vercel AI SDK في 20 سبتمبر 2026 بأن المثال تُرك دون تنفيذ؛ ثم دُمجت بعد يومين ثلاثة طلبات توثيق تشير إلى ذلك البلاغ، فتحتها أتمتة المشروع نفسه. هذه هي المصلحة التي يجب الإفصاح عنها قبل أن تقرأ ما سبق باعتباره محايدًا.

وكل واقعة هنا جرى التحقّق منها من مصدرها في 24 سبتمبر 2026 لا نقلًا عن التقرير: حالات المسائل وطلبات الدمج عبر واجهة GitHub البرمجية، وسجلّ Zenodo وملفه، وتوثيق الوسيط على الفرع الأساسي للحزمة. وما تعذّر التحقّق منه ليس في هذه الصفحة.