مدل را برای مشتری جدید می‌سنجید یا سفارش جدید؟

تیم فروش می‌خواهد مدل را برای مشتری‌هایی به کار بگیرد که شرکت هنوز با آن‌ها کار نکرده است. تیم داده گزارش آزمون را نشان می‌دهد: هیچ سفارش مشترکی میان آموزش و آزمون وجود ندارد. بااین‌حال، سفارش‌های هر دو مجموعه به همان مشتری‌ها تعلق دارند. اختلاف از محاسبه نمره شروع نشده؛ دو تیم از ابتدا دو سؤال متفاوت داشته‌اند.

این موقعیت فرضی است، نه گزارش یک مشتری ژرف. پرسش اصلی برای سازنده مدل و مدیر محصول این است: قرار است سفارش بعدی مشتری آشنا را پیش‌بینی کنیم یا رفتار مشتری ناآشنا را؟ اگر محصول هر دو را پوشش می‌دهد، باید هر دو را بسنجیم. انتخاب درصد تقسیم داده، بعد از این تصمیم می‌آید.

اول معلوم کنید «مشتری جدید» یعنی چه

مشتری تازه برای مدل، مشتری تازه برای شرکت و کسی که نخستین سفارش عمرش را ثبت می‌کند، یکسان نیستند. شاید سوابق یک مشتری قدیمی را از آموزش کنار گذاشته باشید، ولی هنگام پیش‌بینی، چند سال سابقه خرید او را در اختیار مدل بگذارید. چنین آزمونی با آزمون خریداری که هیچ سابقه‌ای ندارد فرق دارد.

وعده محصول را با موقعیت پیش‌بینی بنویسید. مثلاً «هنگام ثبت سفارش، با اطلاعات موجود در همان لحظه، برگشت خوردن آن را پیش‌بینی می‌کنیم». سپس مشخص کنید مشتری قبلاً در داده‌های توسعه مدل حضور داشته یا نه. عبارت کلی «مدل مرجوعی را دقیق پیش‌بینی می‌کند» این تفاوت را پنهان می‌کند.

جدول زیر پیشنهاد تحلیلی ژرف برای انتخاب آزمون است؛ نتیجه آزمایش یا نسخه واحد برای همه داده‌ها نیست.

اگر مدیر محصول یک عدد خلاصه می‌خواهد، نسبت دو گروه را بر پایه کاربرد مورد انتظار تعیین کنید. نسبتی که بالاترین نمره را می‌سازد، مبنای مناسبی نیست. نمره جداگانه هر گروه را هم نگه دارید تا افزایش جذب مشتری تازه، ضعف پنهان‌شده در میان خریداران تکراری را آشکار کند.

هشت سفارش چگونه دو سؤال متفاوت می‌سازند؟

چهار مشتری فرضی با نام‌های الف تا د داریم؛ هرکدام دو سفارش ثبت کرده‌اند. در این مثال نه مدلی آموزش می‌دهیم و نه ادعای افزایش دقت داریم. فقط می‌خواهیم ببینیم با جابه‌جایی مرز، چه اطلاعات مشترکی در دو سوی آن باقی می‌ماند.

در هر دو تقسیم، چهار ردیف آموزشی و چهار ردیف آزمون داریم. هیچ شناسه سفارشی هم در دو طرف تکرار نشده است. اما در تقسیم اول، هر چهار مشتری آزمون در آموزش حاضرند؛ هم‌پوشانی مشتری ۱۰۰ درصد است. در تقسیم دوم، هیچ‌یک از دو مشتری آزمون در آموزش نیست؛ این نسبت به صفر می‌رسد. شمار ردیف‌ها به‌تنهایی این تفاوت را نشان نمی‌دهد.

تقسیم اول فقط یکی از حالت‌های ممکن تقسیم ردیفی است، نه سرنوشت حتمی هر تقسیم تصادفی. تقسیم دوم نیز هنوز آزمون کامل و معتبری را تضمین نمی‌کند: تاریخ سفارش، زمان دسترسی به ویژگی‌ها و نماینده بودن مشتری‌های ج و د معلوم نیست. برای ساده ماندن مثال، مجموعه اعتبارسنجی را هم نیاورده‌ایم؛ در توسعه واقعی، آن مجموعه نقش جداگانه‌ای دارد.

مهندس داده می‌تواند همین مثال کوچک را به آزمون خودکار تبدیل کند. یک نام مستعار برای مشتری الف و یک نسخه تولیدشده از سفارش ج۱ اضافه کنید. اگر سامانه این نسخه‌ها را مستقل بداند و در دو سوی مرز قرار دهد، آزمون تقسیم باید پیش از شروع آموزش خطا بدهد.

وابستگی همیشه خطا نیست؛ ادعای اشتباه خطاست

یکتا بودن شناسه سفارش به معنای مستقل بودن مشاهده‌ها نیست. مشتری، تاریخچه حساب، شرکت مادر یا قالب سند ممکن است مشترک باشد. حذف نسخه کاملاً تکراری مفید است، ولی وابستگی میان سفارش‌های یک مشتری را از بین نمی‌برد. مدل ممکن است الگوی پایدار خرید همان مشتری را یاد گرفته باشد، نه الگویی که به مشتری دیگر منتقل می‌شود.

پژوهش کاپور و نارایانان میان تکرار نمونه، نشت زمانی و وابستگی داده‌های آموزش و آزمون فرق می‌گذارد و اعتبار ادعا را به جمعیت مورد نظر پیوند می‌زند. موضوع پژوهش، کاربرد یادگیری ماشین در علم است؛ نمی‌توان از آن نرخ شکست نرم‌افزارهای تجاری را استخراج کرد. پژوهش نشت داده و بحران بازتولیدپذیری.

برای پیش‌بینی سفارش فردای یک حساب قدیمی، استفاده از سابقه واقعاً موجود همان حساب طبیعی است. پس حضور مشتری در هر دو مجموعه، به‌خودی‌خود اثبات خطا نیست. مشکل وقتی رخ می‌دهد که نتیجه چنین آزمونی را شاهد عملکرد برای مشتری ناآشنا معرفی کنیم. نام مشتری یا وجود تاریخچه را بدون توجه به کاربرد حذف نکنید؛ اول ادعا را روشن کنید.

در راهنمای آلودگی بنچمارک بحث بر سر دسترسی مدل یا سازندگان آن به محتوای آزمون بود. محرمانه نگه داشتن پاسخ‌ها آن مسئله را هدف می‌گیرد، اما تعیین نمی‌کند کدام ردیف‌های مرتبط باید کنار هم بمانند. اینجا واحد جداسازی اهمیت دارد.

گروه مشتری را از روی شواهد بسازید

واحد گروه‌بندی را متناسب با ادعا انتخاب کنید: مشتری، شرکت، گفت‌وگو، سند اصلی یا منشأ دیگری که وابستگی را ایجاد کرده است. صفحات یک سند و بازنویسی‌های مصنوعی آن ممکن است یک خانواده باشند. درباره شرکت‌ها نیز باید روشن شود که دو شرکت تابعه، برای این محصول دو مشتری ناآشنا به حساب می‌آیند یا اعضای یک گروه آشنا.

طبق مستندات GroupKFold، گروه‌ها در بخش آموزش و آزمون هر نوبت هم‌پوشانی ندارند و هر گروه یک بار در بخش آزمون قرار می‌گیرد. تعداد گروه‌های متمایز باید دست‌کم به تعداد نوبت‌ها برسد. این ابزار برچسب گروهی را که به آن داده‌اید جدا می‌کند؛ درستی هویت مشتری یا جدایی زمانی را تضمین نمی‌کند.

نسخه نگاشت هویت‌ها را همراه تقسیم داده ثبت کنید. راهنمای تطبیق رکوردهای مشتری توضیح می‌دهد چرا شباهت نام، اثبات یکی بودن دو شخص نیست. جدا ماندن دو شناسه متعلق به یک مشتری، نشت را پنهان می‌کند. ادغام اشتباه مشتری‌های نامرتبط هم گروهی بزرگ و ساختگی می‌سازد و پوشش آزمون را تغییر می‌دهد.

شناسه گمشده را با شناسه یکتای ردیف جایگزین نکنید و نتیجه را «آزمون مشتری جدید» ننامید. قرار دادن همه شناسه‌های گمشده در یک گروه هم رابطه‌ای بی‌دلیل می‌سازد. بررسی هویت، استفاده از شواهد معتبر منشأ، یا گزارش جداگانه گروه حل‌نشده انتخاب‌های روشن‌تری هستند. تعداد ردیف‌ها و مشتری‌های حذف‌شده و علت حذف را بنویسید؛ کنار گذاشتن بی‌سروصدای موارد دشوار، جمعیت آزمون را عوض می‌کند.

تاریخ سفارش با زمان دانستن نتیجه فرق دارد

دو زمان را جدا کنید. نخست، لحظه پیش‌بینی که تعیین می‌کند کدام ویژگی‌ها مجاز بوده‌اند. دوم، زمان توقف داده‌های آموزشی که نشان می‌دهد مدل هنگام آموزش کدام نتیجه‌ها را می‌دانسته است. قدیمی بودن تاریخ سفارش به‌تنهایی، استفاده از نتیجه آن را مجاز نمی‌کند.

فرض کنید آموزش در اول ژوئیه متوقف شده است. سفارشی در ۲۵ ژوئن ثبت شده و برچسب آن می‌گوید آیا طی ۳۰ روز مرجوع شده است؛ نتیجه نهایی تازه در ۲۵ ژوئیه معلوم می‌شود. فایل خروجی ماه اوت این برچسب را دارد، اما مدلِ اول ژوئیه به آن دسترسی نداشته است. این ردیف نباید با آن برچسب نهایی وارد نسخه آموزشی آن روز شود، مگر اینکه قاعده جداگانه و موجهی برای زمان دسترسی به برچسب تعریف شده باشد.

در مقابل، برای نمره دادن به پیش‌بینی ۱۰ ژوئیه می‌توان بعداً از نتیجه نهایی همان سفارش استفاده کرد. آزمون باید منتظر معلوم شدن واقعیت بماند. آنچه مجاز نیست، وارد کردن آن نتیجه یا خلاصه حساب شامل رویدادهای بعدی به ورودیِ پیش‌بینی ۱۰ ژوئیه است. راهنمای زمان و حقیقت داده همین تفاوت میان زمان رویداد و زمان دانستن را باز می‌کند.

در مرجع TimeSeriesSplit، داده‌ها به ترتیب زمان تقسیم می‌شوند و بخش آموزش در نوبت‌های بعدی گسترش می‌یابد. پارامتر gap تعداد نمونه است، نه تعداد روز؛ مقایسه مدت بازه‌های آزمون نیز به فاصله زمانی برابر نمونه‌ها وابسته است. این ابزار آرگومان groups را نادیده می‌گیرد. برای سفارش‌های نامنظم، بازه تقویمی را صریح بسازید: فاصله هفت ردیفی، فاصله هفت‌روزه نیست و جدایی زمان، جدایی مشتری را تضمین نمی‌کند.

برای مشتری ناآشنا در آینده، هر دو مرز را نگه دارید

اگر وعده محصول درباره سفارش آینده مشتری ناآشناست، مشتری‌های آزمون را از تمام توسعه مدل کنار بگذارید؛ پیش‌پردازش، انتخاب ویژگی و تنظیم آستانه هم جزو توسعه‌اند. سپس سفارش‌های واجد شرایط همان مشتری‌ها را در دوره بعدی، با ورودی بازسازی‌شده در لحظه پیش‌بینی بسنجید. ردیفی که خارج از بازه آزمون افتاده، صرفاً به دلیل دشواری ارزیابی نباید به آموزش منتقل شود.

این ترکیب، روش پیشنهادی ژرف است؛ هیچ‌یک از دو ابزار بالا به‌تنهایی هر دو شرط را برقرار نمی‌کند. برای هر تقسیم، نسخه داده منبع، نسخه نگاشت مشتری، عضویت گروه‌ها، مرز آموزش، بازه آزمون، قاعده نهایی شدن برچسب و علت حذف‌ها را ثبت کنید. اگر تصادفی‌سازی دارید، بذر آن را هم نگه دارید. خودِ فهرست تخصیص ردیف‌ها لازم است؛ یک بذر ثابت، فایل داده‌ای را که هر روز تغییر می‌کند شناسایی نمی‌کند.

اگر کاربرد، نخستین خرید است، گروهی با همین تعریف انتخاب کنید. نبود شناسه در یک جدول به معنای نخستین خرید نیست. وقتی سابقه قدیمی در دسترس نیست، تازه بودن مشتری تأیید نشده است. در بازپخش دوره‌های متوالی هم بنویسید مدل در هر مرز دوباره آموزش می‌بیند یا ثابت می‌ماند؛ این‌ها دو خدمت متفاوت‌اند.

آزمون نهایی را از تنظیم مدل جدا نگه دارید. راهنمای تقسیم داده گوگل نقش آموزش، اعتبارسنجی و آزمون را تفکیک می‌کند، درباره نمونه‌های تکراری هشدار می‌دهد و توضیح می‌دهد استفاده مکرر برای تصمیم‌گیری، اعتبار مجموعه آزمون را فرسوده می‌کند. اگر نتیجه آزمون نهایی باعث تغییر ویژگی یا آستانه شد، این استفاده را ثبت کنید و شاهد تازه‌ای برای ارزیابی بخواهید؛ مجموعه قبلی دیگر دست‌نخورده نیست.

پیش‌پردازش هم بخشی از آموزش است

حتی با جدایی کامل مشتری‌ها، یک تبدیلِ آموخته‌شده از کل داده می‌تواند اطلاعات آزمون را وارد مدل کند. جایگزینی مقدار گمشده، مقیاس‌بندی و انتخاب ویژگی بیرون از مسئولیت آموزش نیستند، فقط چون کدشان زودتر اجرا می‌شود. راهنمای خطاهای رایج اسکی‌کیت‌لرن توصیه می‌کند این تبدیل‌ها از داده آموزشی آموخته شوند و برای رعایت مرز در اعتبارسنجی، در یک زنجیره پردازش قرار بگیرند.

زنجیره پردازش، هویت اشتباه مشتری یا ویژگی‌ای را که از آینده ساخته شده اصلاح نمی‌کند. سازنده جدول ورودی را هم بازبینی کنید. هر ویژگی باید منبع، زمان دسترسی، بازه تجمیع و وضعیت آموخته‌شده مشخصی داشته باشد؛ بررسی کنید آیا آن وضعیت از داده کنارگذاشته‌شده استفاده کرده است یا نه.

نمونه افزوده آموزشی را فقط از منبع مجاز آموزشی بسازید و شناسه والد را همراهش نگه دارید. در غیر این صورت، خروجی بعدی ممکن است اعضای یک خانواده را بی‌خبر در مجموعه‌های مختلف پخش کند. اگر یک مدل زبانی تاریخچه مشتری را خلاصه می‌کند، مرز زمانی ورودی آن باید قابل بررسی باشد. خلاصه روانِ اتفاقات آینده، همچنان اطلاعاتی است که خدمت واقعی آن روز نداشته است.

نمره را برای سفارش حساب می‌کنید یا برای مشتری؟

هزاران سفارش از چند مشتری محدود، معادل هزاران مشتری مستقل نیست. کنار معیار عملکرد، تعداد مشتری متمایز، سفارش به‌ازای هر مشتری، تعداد نمونه هر کلاس و پوشش زمانی را گزارش کنید. از گروه کوچک یا بسیار متمرکز، ادعای دقیق درباره کل جمعیت نسازید.

یک مثال صرفاً حسابی این تفاوت را نشان می‌دهد: مشتری اول ۹۰ سفارش دارد و میانگین خطای مطلق پیش‌بینی او یک روز است. مشتری دوم ۱۰ سفارش دارد و این خطا برای او پنج روز است. میانگین با وزن برابر برای هر سفارش، ۱٫۴ روز می‌شود. با وزن برابر برای هر مشتری، میانگین سه روز است. هیچ‌کدام ذاتاً فریبنده نیست؛ هرکدام اولویت متفاوتی را توصیف می‌کند.

پیش از مقایسه مدل‌ها، اولویت محصول را اعلام کنید و هرجا تمرکز مشتری مهم است، هر دو عدد را نشان دهید. نتیجه مشتری آشنا و ناآشنا را نیز جدا نگه دارید. مدل‌های رقیب باید روی ردیف‌ها و گروه‌های واجد شرایط یکسان سنجیده شوند. نمره بهتر روی گروه آسان‌تری که پس از حذف‌ها باقی مانده، شاهد بهبود روی جمعیت اولیه نیست.

پیامد نادر محدودیت واقعی ایجاد می‌کند. اگر تعداد کمی از گروه‌های مشتری نمونه مثبت داشته باشند، بعضی نوبت‌ها برای معیار مورد نظر مناسب نیستند. برای زیباتر شدن نسبت کلاس‌ها، سفارش‌های یک مشتری را در دو سوی مرز نگذارید. با توجیه روشن تعداد نوبت‌ها را کمتر کنید، گروه‌های مستقل بیشتری گرد آورید یا ناکافی بودن شواهد را اعلام کنید. گروه‌بندی به‌خودی‌خود تضمین نمی‌کند همه نوبت‌ها به یک اندازه اطلاعات بدهند؛ اثر گروه‌های بسیار بزرگ را جداگانه بررسی کنید.

تقسیم داده باید قابل بازبینی و قابل رد شدن باشد

پیش از پذیرفتن نمره، شروط تقسیم را با فهرست ثبت‌شده بررسی کنید. برای ادعای مشتری ناآشنا، هم‌پوشانی مشتری میان توسعه و آزمون نهایی باید صفر باشد. برای همه کاربردها، تکرار ناخواسته منبع، مجاز بودن زمان ویژگی‌ها، دسترس‌پذیری برچسب آموزشی و تطبیق حذف‌ها با داده منبع را بسنجید. مجموعه اعتبارسنجی را فراموش نکنید؛ فقط آخرین مقایسه آموزش و آزمون مهم نیست.

به آزمون‌های کوچک، خطای عمدی بدهید: نام مستعار در دو بخش، برچسب دیررس در آموزش، خلاصه حساب شامل آینده و سند کپی‌شده با نام فایل تازه. نتیجه مورد انتظار باید رد مشخص یا استثنایی با طبقه‌بندی صریح باشد. ردیف‌ها را بی‌سروصدا حذف نکنید تا آزمون بالاخره سبز شود؛ خود خطا بخشی از شواهد بررسی است.

با تغییر نگاشت هویت، اضافه شدن کانال فروش، تغییر تأخیر برچسب‌ها یا حرکت کسب‌وکار از خریداران تکراری به جذب مشتری، تقسیم را دوباره بررسی کنید. حتی اگر کد مدل ثابت بماند، سؤال ارزیابی عوض شده است. شرط پذیرش این نیست که «ردیف‌های آزمون متفاوت بودند». باید بتوان گفت این آزمون همان مشتری‌ها، همان اطلاعات مجاز و همان دوره‌ای را نمایندگی می‌کند که درباره‌اش ادعا داریم.

یادداشت منابع — بازبینی ۲ اکتبر ۲۰۲۶

این مطلب راهنمای کاربردی بخش معمول بلاگ است. جدول‌ها، تاریخ‌های نمونه، محاسبه‌ها و کنترل‌های پیشنهادی، تحلیل ژرف و مثال فرضی‌اند؛ نتیجه اندازه‌گیری‌شده از مشتری یا سامانه عملیاتی نیستند. پنج منبع از پروژه اسکی‌کیت‌لرن، گوگل و پژوهشگران پرینستون آمده‌اند؛ سه صفحه یک پروژه، سه سازمان مستقل محسوب نمی‌شوند.

• کاپور و نارایانان؛ نشت داده و بحران بازتولیدپذیری، نسخه اول پیش‌چاپ، ۱۴ ژوئیه ۲۰۲۲؛ طبقه‌بندی نشت و دامنه ادعای تعمیم.
• اسکی‌کیت‌لرن؛ GroupKFold، مستندات جاری با نمایش نسخه ۱٫۹٫۱ هنگام بازبینی؛ جدایی گروه‌ها.
• اسکی‌کیت‌لرن؛ TimeSeriesSplit، همان نسخه مستندات؛ ترتیب زمانی و فاصله بر حسب تعداد نمونه.
• اسکی‌کیت‌لرن؛ خطاهای رایج، مستندات جاری بررسی‌شده در تاریخ بالا؛ آموختن پیش‌پردازش در مرز آموزش.
• گوگل؛ تقسیم مجموعه داده اصلی، آخرین به‌روزرسانی ۳ دسامبر ۲۰۲۵؛ نقش مجموعه‌ها، نمونه تکراری و استفاده مکرر از آزمون.