‏TabFM گوگل و Postgres شاخه‌دار Neon: ایجنت علم داده بدون آموزش مدل

TabFM یه مدل پایه (foundation model) برای داده‌های جدولی از Google Research هست. روش معمول اینه که داده رو تمیز کنی، feature بسازی و یه مدل gradient boosted tree رو از اول آموزش بدی. با TabFM لازم نیست: ردیف‌هایی که جوابشون رو می‌دونی بهش می‌دی، ردیف‌های بدون جواب رو هم ته جدول می‌ذاری و خودش تو یه مرحله پیش‌بینی می‌کنه. به گفتهٔ نویسنده، این همون اتفاقیه که GPT-3 برای متن افتاد و حالا جدول‌ها هم بهش رسیدن.

TabFM فقط روی داده‌های مصنوعی آموزش دیده که از گراف‌های علّی تصادفی ساخته شدن. پس هیچ دیتاست واقعی‌ای رو حفظ نکرده و یه روش کلی برای حدس زدن مقدارهای ناشناخته یاد گرفته. طبق مقاله، روی یه دیتاست مصنوعی ریزش مشتری (churn) تو یه SaaS، همین روش بدون هیچ feature engineering از یه مدل درختی تنظیم‌شده بهتر بود، هرچند امتیازش حدود ۰.۶۰ بود و جای بهتر شدن داشت.

نقطه‌ضعفش اینه که معنی ستون‌ها رو نمی‌فهمه. همه چیز براش فقط عدده و نمی‌دونه یه ستون مبلغ ماهانه‌ست یا دما، یا اینکه «۰» تو یه ستون یعنی «اندازه‌گیری نشده». محققای گوگل برای حل این مشکل معماری TabFusion Auto رو ساختن: TabFM ثابت می‌مونه و یه ایجنت LLM بالای سرش اسم ستون‌ها رو بررسی می‌کنه، کد تبدیل داده می‌نویسه و پیش‌بینی‌ها رو تنظیم می‌کنه. این ترکیب تو بنچمارک TabArena به رتبه‌های بالا رسیده. کد اصلیش عمومی نیست ولی خود الگو با هر مدل کدنویس قابل تکراره.

نویسنده سه چیز رو برای امنیت این ایجنت لازم می‌دونه. اول اینکه دیکشنری داده رو به شکل comment روی ستون‌های Postgres ذخیره کنی تا ایجنت معنی هر فیلد رو همون‌جا ببینه. دوم یه sandbox: قابلیت branching تو Neon (یعنی یه کپی copy-on-write از کل دیتابیس) تو حدود یه ثانیه ساخته می‌شه. ایجنت همهٔ آزمایش‌هاش رو اون‌جا انجام می‌ده و اگه خراب کرد، branch پاک می‌شه و دیتابیس اصلی دست نمی‌خوره.

سومی و مهم‌ترینش جلوگیری از data leakage هست، یعنی استفاده از featureی که موقع پیش‌بینی واقعاً وجود نداشته. تو تست churn یه ستون نشون می‌داد مشتری قبلاً درخواست لغو داده یا نه. این ستون تقریباً بی‌نقص جواب رو لو می‌داد، چون بعد از اتفاق پر می‌شد. طبق مقاله، ایجنت تو حدود نصف اجراها از همین ستون استفاده کرد و مدلش روی داده‌های ماه بعد از یه مدل تمیز بدتر شد. راه‌حل اینه که branch آموزشی رو به زمان دقیق قبل از بازهٔ پیش‌بینی برگردونی تا این ستون اصلاً هنوز وجود نداشته باشه.

به گفتهٔ نویسنده، زیرساخت این الگو (comment روی ستون‌ها، branchهای ایزوله و برگشت به یه لحظهٔ خاص) همین الان برای production آماده‌ست و با هر مدلی کار می‌کنه. ولی خود TabFM آماده نیست، چون وزن‌هاش فقط برای استفادهٔ پژوهشی و غیرتجاری منتشر شدن. پس بهتره فعلاً به چشم یه نقشهٔ معماری بهش نگاه کنی.

نکات کلیدی:

• TabFM کاملاً روی داده‌های مصنوعی ساخته‌شده از گراف‌های علّی تصادفی آموزش دیده.
• TabFM معنی ستون‌ها رو نمی‌فهمه و الگوی TabFusion Auto با یه ایجنت LLM این رو جبران می‌کنه.
• branch تو Neon یه کپی copy-on-write از دیتابیسه که حدود یه ثانیه‌ای ساخته می‌شه.
• تو تست churn، ایجنت تو حدود نصف اجراها از ستون لو‌دهندهٔ لغو اشتراک استفاده کرد.
• وزن‌های TabFM فعلاً فقط برای استفادهٔ پژوهشی و غیرتجاری آزادن.