وقتی درباره مدل هوش مصنوعی صحبت می‌کنیم، معمولاً تولید متن و تصویر به ذهن می‌رسد. اما برای بسیاری از کسب‌وکارها سؤال مهم عددی است: فردا چه مقدار تقاضا داریم، ظرفیت سرور چه زمانی کم می‌آید یا موجودی کدام کالا زودتر تمام می‌شود؟ Timestral برای همین جنس مسئله معرفی شده است؛ پیشبینی سری زمانی، نه گفت‌وگو. این مقاله توضیح می‌دهد چگونه آن را ارزیابی کنیم و چطور نتیجه پیشبینی را به یک سرویس قابل استفاده تبدیل کنیم.
منابع رسمی در ۲۲ اکتبر ۲۰۲۶ بررسی شدهاند. در این راهنما اجرای واقعی وزن مدل، بنچمارک روی زیرساخت پاستا یا دقت پیشبینی فروش فارسی اندازه‌گیری نشده است. نمونه عددی آموزشی است و توصیه خرید، سرمایه‌گذاری یا تضمین ظرفیت نیست. همچنین Timestral را مدل آماده در API پاستا معرفی نمی‌کنیم؛ مسیر پیشنهادی، بررسی اجرای مستقل برنامه و استفاده جدا از مدل زبانی برای توضیح داده تأییدشده است.
Timestral چیست و چرا با یک مدل چت فرق دارد؟
مدل پیشبینی سری زمانی، توالی اندازه‌گیری‌شده را دریافت میکند تا درباره ادامه همان توالی برآورد بدهد. پرسش «در روزهای آینده چند درخواست خواهیم داشت؟» با پرسش «این نمودار را توضیح بده» یکسان نیست. در اولی، خطای عددی، افق پیشبینی و عدم قطعیت مهم‌اند. در دومی، کیفیت توضیح و وفاداری به داده اهمیت دارد. فرستادن یک جدول بلند به مدل چت، به‌خودی‌خود روش معتبر پیشبینی ایجاد نمیکند.
طبق معرفی رسمی Mistral در ۱۵ اکتبر، این خانواده برای پیشبینی احتمالاتی چندمتغیره طراحی شده و چهار اندازه ۵، ۲۸، ۱۲۳ و ۲۰۹ میلیون پارامتری دارد. ظرفیت زمینه بر حسب گام زمانی بیان می‌شود، نه توکن متن. ادعای کارایی CPU نیز مربوط به آزمون سازنده است و زمان پاسخ برنامه شما را تضمین نمیکند. پیش از انتخاب مدل، مسئله و داده را مشخص کنید تا مقایسه معنی‌دار باشد.
چه مسئله‌ای برای اولین آزمایش مناسب است؟
از یک شاخص قابل اندازه‌گیری با تاریخچه نسبتاً منظم شروع کنید: تعداد درخواست ساعتی، سفارش روزانه یا مصرف یک منبع مشخص. مسئله باید مالک و تصمیم روشن داشته باشد. اگر خروجی قرار است فقط روی نمودار نمایش داده شود، هزینه خطا با زمانی که بر اساس آن منابع خریداری می‌شوند فرق دارد. برای نسخه اول، نتیجه را پیشنهاد قابل بازبینی نگه دارید و عملیات پرهزینه را خودکار نکنید.
نمونه مناسب میتواند پیشبینی تعداد درخواست روز بعد برای برنامه وب باشد. تصمیم مربوط به آن، آماده‌سازی ظرفیت است و معیار موفقیت میتواند خطای پیشبینی در ساعت‌های پرترافیک باشد. نمونه ضعیف‌تر این است که «همه داده‌های شرکت را بدهیم تا آینده را بگوید». در آن حالت، افق، واحد و معیار پذیرش مشخص نیست. یک آزمایش محدود کمک میکند بفهمید مشکل از مدل است یا از تعریف ناقص داده و تصمیم.
داده زمانی سالم از مدل بزرگ‌تر مهم‌تر است
هر ردیف باید زمان، شناسه سری و مقدار با واحد روشن داشته باشد. درخواست در دقیقه را با درخواست در ساعت مخلوط نکنید. زمان ذخیره‌سازی و تقویم نمایش را جدا نگه دارید؛ برای تیم ایرانی، نمایش شمسی مفید است اما ترتیب و فاصله زمانی باید در پردازش بدون ابهام بماند. اگر ساعت‌های تکراری یا ردیف‌های خارج از ترتیب دارید، پیش از مدل آن‌ها را تشخیص دهید و سیاست اصلاح را ثبت کنید.
صفر با داده غایب یکی نیست. صفر سفارش در یک روز باز ممکن است واقعی باشد؛ نبود فایل آمار، اندازه‌گیری ناموجود است. پرکردن هر شکاف با صفر میتواند مدل را درباره افت تقاضا گمراه کند. همین‌طور حذف روزهای بدون فروش ممکن است فاصله زمانی را به‌هم بزند. ابتدا یک تقویم منظم بسازید، شکاف را علامت بزنید و دلیل نبود داده را تا حد ممکن نگه دارید. پاکسازی نباید واقعیت کسب‌وکار را پنهان کند.
تقویم، تعطیلی و تبلیغ را چگونه وارد تحلیل کنیم؟
فروش یا ترافیک فقط از تاریخچه خودش تأثیر نمیگیرد. تعطیلی، ساعت کاری، کمپین و تغییر قیمت می‌توانند الگو را عوض کنند. اما هر متغیر کمکی باید با زمان آگاهی واقعی سازگار باشد. برنامه تبلیغی که از قبل تصویب شده، اطلاعات آینده معلوم است؛ تعداد کلیک نهایی همان تبلیغ هنوز معلوم نیست. اگر مقدار دوم را در آزمون به مدل بدهید، نتیجه زیبا اما غیرقابل تکرار در محصول خواهد شد.
برای داده ایرانی، روز هفته و تعطیلی رسمی میتواند معنا داشته باشد، اما این متغیرها را کورکورانه اضافه نکنید. تاریخ اثر را روی داده واقعی بررسی کنید و تغییر تقویم کاری را ثبت کنید. برای فروشگاه، موجودنبودن محصول ممکن است فروش را کم کند بدون اینکه تقاضا کم شده باشد. پیشبینی فروش مشاهده‌شده و تقاضای پنهان دو مسئله متفاوت‌اند. این تفاوت را پیش از وعده کاهش کمبود موجودی به تیم تجاری توضیح دهید.