‏فیگما به کد، قبل از عصر LLM

نویسنده تو این پست تعریف می‌کنه که اولین نسخهٔ Figma-to-code رو تو Builder.io ساخته، خیلی قبل از اینکه LLMها بیان. ادیتور بصری‌شون به بازاریاب‌ها و دیزاینرها اجازه می‌داد هر چیزی رو همون‌جایی بذارن که درست به نظر می‌رسید، ولی خروجی باید یه چیدمان ریسپانسیو می‌شد. فیگما و وب هر دو سند رو درختی نگه می‌دارن، فقط درخت فیگما می‌تونه خیلی شلوغ‌تر باشه: نودها هرجا که ترکیب‌بندی لازم داشته نشستن و نسخه‌های قدیمی زیر یه مستطیل سفید مات قایم شدن.

کپی کردن یک‌به‌یک هر نود به یه المان با position absolute فقط تو یه سایز صفحه درست دیده می‌شه و هرجای دیگه می‌شکنه. پس سؤال واقعی گروه‌بندی بود: یه فریم خوش‌ظاهر می‌تونه ۴۰۰ نود خواهر و برادر داشته باشه و هیچ‌چی توش نمی‌گه کدوم‌ها با هم یه گروهن. مدل‌های درخت تصمیم هم تعداد ورودی ثابت می‌خوان، ولی یه فایل فیگما می‌تونه یه نود ساده باشه یا یه غول ۳۰ مگابایتی.

ایدهٔ اصلی این بود که به‌جای پرسیدن کل درخت از مدل، دو تا candidate merge (یعنی دو پیشنهاد برای اینکه کدوم دو نود زیر یه پرنت جدید برن) بهش داده بشه و مدل بگه هر دو درسته، هیچ‌کدوم درست نیست، یا فقط یکی‌شون. هر candidate می‌شد ۲۱ عدد از جنس هندسه و ساختار: ابعاد گروه، باکس دربرگیرنده، ترازبندی، فاصله‌ها و تعداد فرزندها. دو تا candidate یعنی ۴۲ ورودی، مهم نیست دیزاین چقدر بزرگه.

compare(candidateA, candidateB)
  → probabilities for [both valid, neither valid, only A valid, only B valid]

مدل نهایی gradient-boosted decision trees با XGBoost بود، چون سرعت مهم بود: بازسازی سلسله‌مراتب یعنی یه تورنمنت از مقایسه‌ها، اعمال برنده‌هایی که مستطیل‌هاشون روی هم نمی‌افته، و بعد دور بعدی. دادهٔ آموزش هم از خود اینترنت میومد؛ سایت ریسپانسیو رو با Chromium رندر می‌کردن، باندینگ‌باکس هر المان رو با getBoundingClientRect() می‌گرفتن و رابطهٔ پرنت-فرزند HTML اصلی جواب درست حساب می‌شد. با ۱۰۰۰ نود، نزدیک ۵۰۰ هزار جفت ممکن وجود داره، پس اول جفت‌هایی که از نظر هندسی محال بودن فیلتر می‌شدن.

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

نکات کلیدی:

• هر candidate merge با ۲۱ ویژگی هندسی توصیف می‌شد، پس هر مقایسه ۴۲ ورودی داشت، مستقل از اندازهٔ دیزاین
• مدل XGBoost بود و بین چهار کلاس انتخاب می‌کرد: هر دو معتبر، هیچ‌کدوم، فقط A، فقط B
• امتیازها تو تورنمنت جمع می‌شن، پس می‌تونن از ۱ بیشتر یا از ۰ کمتر بشن
• نسخهٔ سپتامبر ۲۰۲۳ بیشترین امتیاز رو به‌عنوان آستانه می‌گرفت، یا ۹۵ درصد اون برای بیشتر از ۲۰ candidate
• مدل متن و رنگ رو نمی‌دید و فقط هندسه و ساختار رو ورودی می‌گرفت