TabFM گوگل: پیش‌بینی روی جدول‌ها بدون آموزش مدل
هوش مصنوعی
گوگلخلاصهٔ کامل‌تر
TabFM یه foundation model (یعنی مدل بزرگ و عمومی که برای کارهای مختلف آماده‌ست) از Google Research هست که مخصوص داده‌های جدولی ساخته شده. تو روش‌های معمول مثل XGBoost یا LightGBM، برای هر مسئلهٔ جدید باید داده رو تمیز کنی، feature بسازی، مدل رو آموزش بدی و تنظیمش کنی. TabFM این چرخه رو کلاً حذف می‌کنه. یه جدول بهش می‌دی که هم ردیف‌های با جواب معلوم داره، هم ردیف‌هایی که می‌خوای پیش‌بینی بشن، و مدل تو یه forward pass جای خالی‌ها رو پر می‌کنه.
این روش اسمش in-context learning هست، یعنی مدل از نمونه‌هایی که تو خود ورودی می‌بینه یاد می‌گیره، نه از آموزش جدا. همون ترفندیه که GPT-3 رو بدون fine-tune برای هر کار مفید کرد. اینجا هیچ gradient update یا checkpoint مخصوص دادهٔ تو ذخیره نمی‌شه و «مدل» تو عملاً همون جدولیه که به‌عنوان پرامپت می‌دی. تو این مقاله اومده که داده‌های جدولی تا حالا لحظهٔ GPT-3 خودشون رو نداشتن و TabFM تلاش گوگل برای همینه.
نکتهٔ جالب نحوهٔ آموزششه. گوگل مدل رو فقط با جریانی از جدول‌های مصنوعی آموزش داده. برای هر جدول یه causal graph تصادفی (یعنی نقشه‌ای از اینکه کدوم متغیر روی کدوم اثر می‌ذاره) ساختن، ردیف‌ها رو از روش تولید کردن و بعد چند خونه رو قایم کردن تا مدل حدسشون بزنه. اینطوری مدل نمی‌تونه میان‌بُرهای یه دیتاست خاص رو حفظ کنه و مجبوره یه روش کلی برای استدلال روی جدول یاد بگیره.
ولی همین باعث یه ضعف جدی شده: TabFM هیچ‌وقت اسم ستون ندیده، پس همه‌چیز براش فقط عدده. نمی‌فهمه 1 و 2 و 3 کد دسته‌بندیه یا 0 یعنی «اندازه‌گیری نشده». نویسنده می‌گه تو یه تست پیش‌بینی ریزش مشتری (churn)، خروجی خام TabFM از یه gradient-boosted tree تنظیم‌شده ضعیف‌تر بود، با اینکه هیچ feature engineering لازم نداشت.
راه‌حل گوگل معماری‌ایه به اسم TabFusion Auto. TabFM ثابت می‌مونه و فقط پیش‌بینی می‌کنه، و یه LLM دورش نقش هماهنگ‌کننده رو داره: اسم ستون‌ها رو می‌خونه، کد تبدیل ستون‌ها رو می‌نویسه، ردیف‌های مفید رو برای context انتخاب می‌کنه و پیش‌بینی آخر رو کالیبره می‌کنه. طبق پژوهش، این ترکیب تو بنچمارک TabArena نتیجهٔ رقابتی گرفته. ولی کدش منتشر نشده و باید خودت پیاده‌ش کنی.
نویسنده هشدار می‌ده که اجرای این روش به‌شکل agent ریسک داره. بزرگ‌ترینش data leakage هست، یعنی ستونی که فقط بعد از اتفاق افتادن نتیجه پر میشه (مثل پرچم «پیشنهاد نگه‌داشتن ارسال شد») تو تست عالی به نظر میاد ولی تو پیش‌بینی واقعی بی‌فایده‌ست. برای همین agent باید روی یه کپی جدا از دیتابیس کار کنه و بتونه دیتابیس رو همون‌طور که تو یه لحظهٔ مشخص از گذشته بوده query بزنه.
نکات کلیدی:
- TabFM بدون مرحلهٔ آموزش و تنظیم hyperparameter، تو یه forward pass روی کل جدول پیش‌بینی می‌کنه.
- فقط با جدول‌های مصنوعی ساخته‌شده از causal graphهای تصادفی آموزش دیده.
- معنی ستون‌ها رو نمی‌فهمه و تو یه تست churn از gradient-boosted tree تنظیم‌شده ضعیف‌تر بوده.
- TabFusion Auto یه LLM رو کنار TabFM می‌ذاره و تو بنچمارک TabArena نتیجهٔ رقابتی گرفته، ولی کدش منتشر نشده.
- وزن‌های مدل فقط برای استفادهٔ پژوهشی و غیرتجاری منتشر شدن.
- data leakage بزرگ‌ترین ریسک وقتیه که agent خودش featureها رو انتخاب می‌کنه.
