تصور کنید مدیر مالی شرکتی هستید که برای گزارش فروش روزانه به هوش مصنوعی اعتماد کرده است، اما متوجه می‌شوید اعداد گزارش‌شده با واقعیت بانک تطبیق ندارند. این شکست خاموش، نتیجه‌ی چیزی است که می‌توان آن را «نابینایی زمانی» نامید.
وقتی از یک مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — می‌پرسید «درآمد امروز چقدر است؟»، مدل معمولاً یک پرس‌وجوی SQL با دستور CURRENT_DATE تولید می‌کند. مدل فرض می‌کند منطقه زمانی (Timezone) نشست پایگاه‌داده با منطق تجاری شما یکی است؛ فرضی که در محیط‌های عملیاتی تقریباً همیشه غلط است.
همان‌طور که در تحلیل قبلی ما درباره‌ی نشت داده‌ها در زمان اجرا اشاره کردیم، این شکاف سیستمی نشان می‌دهد که خطاهای منطقی دقیقاً به اندازه حفره‌های امنیتی خطرناک هستند. بر اساس بررسی‌های فنی، اگر کاربری در کپنهاگ در ساعت ۰۰:۱۵ بامداد درخواست فروش کند، بسته به اینکه اتصال پایگاه‌داده روی UTC تنظیم شده باشد یا روی سرویس منطقه‌ای، اعداد متفاوتی دریافت می‌کند.
طبق راهنمای فنی منتشرشده در ۳۰ جولای ۲۰۲۶، تنها راه حل جایگزینی پرامپت‌های ساده با «قراردادهای سخت‌گیرانه» است. توسعه‌دهندگان باید منطقه زمانی کسب‌وکار را با شناسه‌های IANA (مانند Europe/Copenhagen) تعریف کنند و مرزهای زمانی را پیش از ارسال پرس‌وجو به UTC تبدیل نمایند.
برای جلوگیری از خطاهای رایج، این راهنما مشخصات فنی زیر را توصیه می‌کند:
- بازه های نیمه‌باز: استفاده از عبارت
WHERE occurred_at >= :start_utc AND occurred_at < :end_utcبرای جلوگیری از تداخل در مرزهای زمانی. - آگاهی از تغییر ساعت تابستانی (DST): هرگز دقیقاً ۲۴ ساعت به زمان شروع UTC اضافه نکنید، زیرا تغییرات ساعت تابستانی می‌تواند روزهایی با ۲۳ یا ۲۵ ساعت ایجاد کند.
- نشانگرهای تازگی (Freshness Watermarks): تعریف سیاست مشخص برای داده‌هایی که دیر می‌رسند، مانند وب‌هوک‌های پرداخت که ساعت‌ها بعد تلاش مجدد می‌کنند.
به نقل از این مستندات، تست سیستم باید از بررسی ساده‌ی اعداد نهایی فراتر رود. اعتبارسنجی واقعی مستلزم «منجمد کردن ساعت» برای تست موارد خاص است: یک میکروثانیه قبل از قطع شدن بازه، روزهای کبیسه و تغییرات پایان ماه برای مشتریانی با مناطق زمانی مختلف.
این چرخش راهبردی، مسئولیت «حقیقت» را از پرامپت مدل به ابزار مدیریت‌شده‌ی پایگاه‌داده منتقل می‌کند. با تبدیل کلماتی مثل «این هفته» به قواعد تجاری صلب به‌جای زبان طبیعی، شرکت‌ها می‌توانند جلوی اختراع خودسرانه مرزهای گزارش‌دهی توسط AI را بگیرند.
برای شما به عنوان کاربر، این یعنی سطح اعتماد به AI کاملاً به قراردادهای داده‌ای زیربنایی وابسته است. اگر مدل انتخاب‌های خود — مثل پنجره زمانی و منطقه مورد استفاده — را شفاف نکند، پاسخ او صرفاً یک احتمال است، نه یک حقیقت.
گام بعدی شما
- قالب‌های تولید SQL در سیستم خود را بررسی کنید تا متوجه شوید آیا از توابع تاریخ مبتنی بر نشست (Session-based) استفاده می‌کنند یا تزریق صریح مرزهای UTC.
- در پرامپت‌های سیستمی خود، الزام کنید که مدل پیش از ارائه عدد، منطقه زمانی مبنا را ذکر کند.
- یک تست «منجمد کردن ساعت» برای حساس‌ترین گزارشات مالی خود طراحی کنید.
اما داستان سخت‌افزاری مدیریت این حجم از داده‌ها حتی پیچیده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی حافظه در vLLM مراجعه کنید.
گفتگو