زمن استجابة Spatial AI

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

ماذا يشمل زمن استجابة Spatial AI؟

يمر سؤال الموقع عبر عدة ساعات قياس، ودمجها في متوسط واحد باسم «زمن استجابة AI» يخفي المرحلة التي ينتظرها المستخدم فعليًا. استجابة المتصفح هي مدى سرعة تفاعل الصفحة مع نقرة. Time to first progress هو وقت إظهار الواجهة أن العمل بدأ. Time to first token هو وقت إنتاج أول token في التوليد. Time to first spatial action هو وقت ظهور مكان مؤهل أو مسار على الخريطة. Time to last token هو وقت انتهاء التوليد. Time to completed action هو وقت وصول المستخدم إلى نتيجة يمكن الاعتماد عليها.

Time to first progress وtime to first spatial action وtime to completed action هي أسماء تستخدمها Kaleidr لوصف تجربة المنتج. هذه الأسماء الثلاثة ليست معايير ويب. أما Time to first token وtime to last token فهما مقياسان راسخان لزمن استجابة النماذج.

تفصل البطاقات الست استجابة المتصفح عن بقية الطلب. ويشار إلى Time to first progress وtime to first spatial action وtime to completed action على أنها مقاييس تحريرية من Kaleidr، بينما يشار إلى Time to first token وtime to last token على أنهما مقياسان راسخان لزمن استجابة النموذج. Interaction to Next Paint هو مقياس المتصفح. ولا تعرض أي بطاقة قياسًا فعليًا من Kaleidr.

تتعامل إرشادات Google لأداء الويب مع Interaction to Next Paint باعتباره مقياسًا للاستجابة الفعلية، وتعد قيمة INP عند 200 ملي ثانية أو أقل جيدة عند الشريحة المئوية الخامسة والسبعين من تحميلات الصفحات (web.dev, 2025). هذا الحد يتعلق بأول رسم تالٍ للنقرة، وليس بحساب مسار أو فقرة مولدة. قد تحقق الصفحة هذا الحد ومع ذلك يظل المستخدم ينتظر الاسترجاع. كما أن بطء استدعاء النموذج لا يجعل INP سيئًا بحد ذاته. ينبغي رسم الميزانيتين بصورة منفصلة، وإلا فقد «يصلح» الفريق «زمن استجابة AI» عبر تحسين معالج نقرة لم يكن أصلًا على المسار الحرج.

لماذا يهم المسار الحرج؟

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

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

الـ trace المفيد يسمّي الـ span لا المنتج. يمكن أن تكون geocoding أو قراءة من نظام أعمال أو حساب مسار أو ranking أو generation هي الـ span البطيئة بحسب السؤال. ويعد Spatial AI observability الدليل المصاحب لتسجيل هذه الـ spans بصورة منفصلة، بما في ذلك سبب منظم عندما تكون النتيجة فارغة. من دون هذا الفصل قد يبدو بعد ظهر بطيء وكأن «النموذج أصبح أسوأ»، بينما كانت خدمة المسار هي المرحلة التي تغيرت.

لماذا لا يكون أول token هو أول نتيجة على الخريطة؟

يجيب Time to first token وtime to last token عن سؤالين مختلفين، ولا يمثل أي منهما اللحظة التي تصبح فيها الخريطة مفيدة. توثق Azure OpenAI العلاقة بأن time to last token يساوي time to first token مضافًا إليه الزمن بين التوكنات مضروبًا في عدد التوكنات المولدة (Microsoft, 2026). ويذكر المقال نفسه أن كل prompt token يضيف وقتًا قليلًا مقارنة بكل token مولد، وأن streaming يعيد التوكنات عندما تصبح جاهزة من دون تغيير الوقت اللازم لإنتاجها كلها. كما يذكر دليل OpenAI لخفض زمن الاستجابة قاعدة تقريبية ذات صلة: تقليل output tokens إلى نحو النصف قد يقلل زمن الاستجابة إلى نحو النصف (OpenAI, 2026). لذلك يمكن لشرح قصير أن ينتهي أبكر. وينبغي أن تحمل بطاقة الخريطة، لا الفقرة، المكان وساعات العمل والمسار.

يعرض النظام A النص مبكرًا وإجراء الخريطة متأخرًا. ويعرض النظام B النص لاحقًا وإجراء الخريطة مبكرًا. علامات الثواني والإجماليات في الشكل توضيحية، ويذكر الرسم أنها ليست بيانات benchmark. هذه العلامات ليست trace من Kaleidr ولا نتيجة من مقالي Azure أو OpenAI. المقارنة تتعلق بالترتيب فقط: token أبكر لا يعني خريطة أبكر.

هذا الفرق مهم فيما يحتفي به المنتج. لوحة معلومات ترتب الأنظمة حسب time to first token فقط ستفضل النظام الذي يبدأ الكلام أولًا ويرسم الخريطة لاحقًا. وينبغي لمنتج خرائط أيضًا تسجيل time to first spatial action، وألا يسجل هذا الإجراء إلا بعد اجتياز الأهلية. Pin مبكر لمكان مغلق أو غير مصرح به هو خطأ سريع. ويشرح Spatial context engineering القاعدة ذات الصلة بشأن الحقائق المسموح بوصولها إلى النموذج بعد تكوين مجموعة الأماكن المؤهلة.

ما الذي يمكن تخزينه مؤقتًا، وما الذي يجب إعادة التحقق منه؟

يوفر الـ cache رحلة شبكية فقط عندما تظل القيمة المحفوظة هي القيمة الصحيحة. نادرًا ما تتغير المعرّفات المستقرة وإحداثيات مكان معروف، لذلك فهي مرشحة شائعة لتخزين مؤقت طويل العمر. أما ساعات العمل والمسار المحسوب والنص الوصفي فتتغير بما يكفي لجعل time-to-live قصيرًا سياسة أكثر صدقًا. وينبغي إعادة قراءة المخزون وموقع المركبة والتفويض وحالة المعاملة عند وقت اتخاذ القرار. عبارة «متوفر في المخزون» المخزنة منذ الصباح ليست دليلًا على حالة بعد الظهر.

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

تضيف بيانات الأماكن من المزود قيدًا ثانيًا. فالشروط التي جاءت مع السجل تظل سارية على النسخة، بما في ذلك attribution وأي قيود على الاستخدام. وتضيف السجلات الخاصة قيدًا ثالثًا: يجب ألا يصبح cache مشترك بين المستخدمين وسيلة لتجاوز التفويض. المجهول يبقى مجهولًا. timeout للمخزون لا يسمح بعرض «غير متوفر»، وtimeout للمسار لا يسمح باختراع عدد الدقائق.

متى يمكن للخريطة أن تتحرك قبل انتهاء الشرح؟

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

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

يستخدم stream العام في Kaleidr تقنية Server-Sent Events ونوع text/event-stream، ويحدد العقد ما يمكن أن يصل قبل انتهاء النص (Kaleidr, 2026). يعني حدث phase أن الطلب قُبل وأن العمل بدأ، وقيمة المرحلة فيه دائمًا thinking. ويصل تعليق : keep-alive بعد 10 ثوانٍ من الصمت. قد يستغرق وصول أول نص عشرات الثواني في سؤال صعب، ولهذا يوجد حدث phase والـ heartbeat. ويمكن أن تصل route في سؤال اتجاهات قبل النص، فتُرسم الخطوط بينما يستمر بث النص. تحمل early_actions إجراءات خريطة يمكن تطبيقها قبل اكتمال الإجابة، وتُرسل عندما يمتلك مكانان أو أكثر إحداثيات. حدث end هو النتيجة المعتمدة، وإجراءاته تستبدل الإجراءات المبكرة. ولا يظهر كل حدث في كل طلب.

كيف ينبغي رسم مخطط الطلب؟

ارسم الاعتماديات أولًا ثم احذف الخطوات التي لا تغير الإجابة. يمكن أن تعمل عملية حل المكان وقراءة بيانات الأعمال معًا بعد التفويض. الأهلية هي نقطة الجمع. يستخدم routing والعمل المكاني الآخر هذه النتيجة. يرتب ranking المرشحين الباقين. وتشرحهم generation. وتعرض الخريطة المعرّفات نفسها. وضع generation قبل الأهلية يهدر tokens على أماكن لا يستطيع المنتج التوصية بها. ويحافظ Grounded spatial AI for business data على هذه الأهلية داخل الأنظمة التي تملك الحقائق.

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

يوضح المخطط نفسه متى يكون النموذج اللغوي الأداة الخاطئة. اختبار الاحتواء وفحص التفويض وفلتر «مفتوح الآن» وحد المسافة كلها عمليات حتمية. النموذج مفيد لقراءة الطلب وشرح نتيجة حسبتها الخدمات بالفعل وترتيب التفضيلات المرنة بين الأماكن المؤهلة. ويقدم دليل OpenAI لزمن الاستجابة الفصل نفسه بصياغة عامة: الطريقة التقليدية أسرع عندما لا تحتاج المهمة إلى استدلال لغوي. كما أن prompt واحدًا يعيد كل خطوات اللغة قد يتفوق على سلسلة من استدعاءات النماذج، لأن كل استدعاء إضافي يدفع تكلفة round trip أخرى. أما المسار والمخزون والإذن فتظل من خدماتها الخاصة.

لماذا قد يخفي المتوسط الطلبات البطيئة؟

المتوسط تلخيص ضعيف للانتظار، لأن عددًا قليلًا من الطلبات البطيئة يهيمن على ما يتذكره الناس. اعرض الوسيط و95th percentile و99th percentile لكل span، وافصلها حسب فئة الطلب. سؤال اتجاهات وسؤال قصير عن مكان لا ينتميان إلى الفئة نفسها. قد تنتج الذيل الطويل عن fan-out عبر الأدوات أو retry أو prompt كبير أو اختلاف بين المزودين أو إجابة مولدة طويلة. معادلة Azure تقول أصلًا إن الحالة الأخيرة تنمو مع output tokens. أما الأسباب الأخرى فلن تظهر في عدد التوكنات، ولهذا يجب فصل الـ spans.

المنحنى يوضح شكلًا، وليس trace من Kaleidr ولا عينة من لوحة معلومات مزود. تستخدم التسميات القراءة المعتادة لهذه الشرائح: نصف الطلبات عند الوسيط أو أقل، ومعظمها عند 95th percentile أو أقل، وتقريبًا كلها عند 99th percentile أو أقل. الأسباب الخمسة أسفل الرسم قائمة تحقق لأماكن البحث. وليست حصصًا مقاسة من حركة Kaleidr.

ينبغي لسياسة الذيل أن تحدد ما يفعله المنتج عندما تتجاوز span ميزانيتها. timeout للمسار يبقى مجهولًا، ويذكر الشرح أن المسار غير متاح. timeout للمخزون يبقى مجهولًا بدل أن يتحول إلى «غير متوفر». ويجب أن يظهر retry في الـ trace حتى لا يُفسر فشل مؤقت على أنه نموذج بطيء. تحسين الوسيط بينما يترك 99th percentile المستخدم أمام spinner ليس برنامج أداء مكتملًا.

ما المراحل التي تنتمي إلى الميزانية؟

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

لكل مرحلة وظيفة ولا مدة محددة. قبول الطلب هو عمل المتصفح. التفويض يسبق البيانات الخاصة. الاسترجاع والحساب المكاني وgeneration أسطر منفصلة. إجراء الخريطة يعرض pin أو مسارًا أو عرضًا مناسبًا. إجراء الأعمال هو handoff، ولا يوجد عندما لا يطلب السؤال ذلك. لا يحدد الشكل أي هدف رقمي.

ضع هدفًا لمرحلة فقط بعد أن يظهر الـ trace أن هذه هي المرحلة التي ينتظرها المستخدمون. رقم عالمي مثل «إجابات في ثانيتين» سيخلط بين النقرة والمسار والفقرة، وهذا المقال لا يستشهد بمثل هذا الرقم. حد INP أعلاه هدف للمتصفح. ومعادلة التوكنات أعلاه تصف زمن النموذج. Time to first spatial action هو هدف الخريطة، ويبقى مقياسًا تحريريًا حتى يعرفه الفريق في traces الخاصة به.

من أين ينبغي للفريق أن يبدأ؟

ابدأ بتقسيم الانتظار. سجّل Interaction to Next Paint للصفحة، وtime to first progress، وtime to first token، وtime to first spatial action، وtime to last token، وtime to completed action. أبق الأسماء التحريرية الثلاثة معنونة كمقاييس للمنتج. اقرأ p50 وp95 وp99 حسب فئة الطلب. قصّر الإجابة المولدة عندما تعرض الخريطة التفاصيل بالفعل. لا تشغّل بالتوازي إلا عمليات البحث التي لا تعتمد بعضها على بعض. أعد التحقق من كل ما يمكن أن يغير القرار. واجعل حدث end، لا أول pin، هو النتيجة التي يستطيع المستخدم التصرف بناء عليها.

استكشف Kaleidr Enterprise عندما يحتاج هذا المسار إلى تضمين أماكن المؤسسة وقواعدها الخاصة. ويعرض SSE wire contract ترتيب الأحداث المشار إليه أعلاه، بما في ذلك حدث phase وkeep-alive وإجراءات الخريطة المبكرة والنتيجة النهائية.

ملاحظة: تستخدم Kaleidr أدوات مدعومة بالذكاء الاصطناعي لإنشاء الصور وتحسين المحتوى والبحث ضمن عملياتها الإبداعية والتطويرية.

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

ما زمن استجابة Spatial AI؟

زمن استجابة Spatial AI هو الوقت من سؤال مكاني إلى استجابة مفيدة على الخريطة. ويشمل الواجهة والتفويض والاسترجاع والحساب المكاني والتوليد وإجراء الخريطة وأي handoff للأعمال. وهو ليس الرقم نفسه لوقت النموذج.

هل Interaction to Next Paint هو نفسه زمن استجابة النموذج؟

لا. يقيس Interaction to Next Paint سرعة استجابة الصفحة للنقرة. ولا تقول القيمة الجيدة، أي 200 ملي ثانية أو أقل عند الشريحة المئوية 75 من تحميلات الصفحات، أي شيء عن وقت انتهاء المسار أو الفقرة.

ما Time to first token؟

Time to first token هو الوقت من إرسال prompt حتى عودة أول token مولد. تستخدم Azure OpenAI هذا المقياس مع الوقت بين التوكنات وعدد التوكنات المولدة لوصف time to last token.

لماذا لا يكفي أول token للخريطة؟

تصبح الخريطة مفيدة عندما يظهر مكان مؤهل أو مسار. قد تأتي هذه اللحظة قبل أول token أو بعده بوقت طويل. يسجل Time to first spatial action لحظة الخريطة، بينما يسجل Time to first token لحظة النص.

هل يجعل streaming حساب المسار أسرع؟

لا. يغير streaming وقت ظهور العمل المكتمل، لكنه لا يقلل زمن حساب المسار أو الاسترجاع أو التوليد الكامل. يذكر مقال Azure عن زمن الاستجابة أن streaming لا يغير الوقت اللازم لإنتاج جميع التوكنات.

ماذا ترسل Kaleidr قبل انتهاء الإجابة؟

يمكن للـ stream العام إرسال حدث phase قيمته thinking، وkeep-alive أثناء الصمت، وroute قبل النص في سؤال اتجاهات، وearly_actions عندما يمتلك مكانان أو أكثر إحداثيات. حدث end هو النتيجة المعتمدة ويستبدل الإجراءات المبكرة. ولا يظهر كل حدث في كل طلب.

هل ينبغي تخزين المخزون الخاص مؤقتًا لتقليل زمن الاستجابة؟

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

أي شريحة مئوية ينبغي للفريق مراقبتها؟

راقب الوسيط و95th percentile و99th percentile لكل span، مع فصلها حسب فئة الطلب. قد يتحسن الوسيط بينما يظل الذيل البطيء الذي يتذكره المستخدمون كما هو.

References

1. web.dev. Interaction to Next Paint (INP). A good INP is at or below 200 milliseconds at the 75th percentile of page loads recorded in the field. An INP above 200 milliseconds and at or below 500 milliseconds needs improvement. Updated September 2, 2025. https://web.dev/articles/inp
2. Microsoft. Azure OpenAI in Microsoft Foundry Models performance & latency. Time to last token equals time to first token plus the time between tokens multiplied by tokens generated. Streaming returns tokens as they are ready and does not change the time required to produce all of them. Accessed October 31, 2026. https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency
3. OpenAI. Latency optimization. A stated heuristic: cutting about half of the output tokens may cut about half of the latency. Accessed October 31, 2026. https://developers.openai.com/api/docs/guides/latency-optimization
4. Kaleidr Developer Docs. SSE wire contract. Documents text/event-stream, a phase event that is always thinking, a keep-alive after 10 seconds of silence, tens of seconds before first prose on a hard question, early_actions once two or more places have coordinates, a route before the prose on a directions question, and end as the authoritative result. Accessed October 31, 2026. https://docs.kaleidr.com/platform-api/sse-wire-contract
5. Kaleidr. Spatial AI Observability. A related guide for recording each stage, including a structured reason when the result is empty. Accessed October 31, 2026. https://kaleidr.com/blog/spatial-ai-observability
6. Kaleidr. Spatial Context Engineering for Map-Aware AI. A related guide for which facts reach the model after eligibility. Accessed October 31, 2026. https://kaleidr.com/blog/spatial-context-engineering
7. Kaleidr. Grounded Spatial AI for Business Data. A related guide for keeping business facts in the systems that own them. Accessed October 31, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data

References in BibTeX

@misc{webdev_inp_2025,
  title  = {Interaction to Next Paint (INP)},
  author = {{web.dev}},
  year   = {2025},
  url    = {https://web.dev/articles/inp}
}

@misc{microsoft_azure_openai_latency_2026,
  title  = {Azure OpenAI in Microsoft Foundry Models performance \& latency},
  author = {{Microsoft}},
  year   = {2026},
  url    = {https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency}
}

@misc{openai_latency_optimization_2026,
  title  = {Latency optimization},
  author = {{OpenAI}},
  year   = {2026},
  url    = {https://developers.openai.com/api/docs/guides/latency-optimization}
}

@misc{kaleidr_sse_wire_contract_2026,
  title  = {SSE wire contract},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/sse-wire-contract}
}

@misc{kaleidr_spatial_ai_observability_2026,
  title  = {Spatial AI Observability},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-observability}
}

@misc{kaleidr_spatial_context_engineering_2026,
  title  = {Spatial Context Engineering for Map-Aware AI},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-context-engineering}
}

@misc{kaleidr_grounded_spatial_ai_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}