چگونه Airbnb با استفاده از LLMها مهاجرت تست‌ها را تسریع کرد

به لطف ترکیب مناسب اتوماسیون گردش کار و مدل‌های زبانی بزرگ (LLM)، Airbnb فرآیند به‌روزرسانی پایگاه کد خود برای پذیرش کتابخانه تست React (RTL) را به طور قابل توجهی تسریع کرد و نزدیک به ۳۵۰۰ فایل تست React که در ابتدا از Enzyme استفاده می‌کردند را تبدیل نمود.

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

یکی از مهم‌ترین درس‌هایی که مهندسان Airbnb آموختند این بود که مهندسی پرامپت (prompt engineering) کمتر از تلاش مجدد برای تبدیل تا زمان موفقیت مؤثر بود؛ رویکردی که مهندس نرم‌افزار کارکنان Airbnb، چارلز کووی-برانت، آن را "نیروی بی‌رحمانه" (brute force) توصیف کرد.

برای مؤثرتر کردن این فرآیند، مهندسان Airbnb فرآیند مهاجرت را به چند مرحله تقسیم کردند: ابتدا بازنویسی (refactoring) از Enzyme به RTL، سپس رفع هرگونه خطای یافت شده در تست‌های Jest، اجرای لینتر (linter) و در نهایت، کامپایلر TypeScript.

این رویکرد مبتنی بر مرحله، پایه محکمی برای خط لوله (pipeline) اتوماسیون ما فراهم کرد. این امکان را به ما داد تا پیشرفت را ردیابی کنیم، نرخ شکست برای مراحل خاص را بهبود بخشیم و در صورت نیاز فایل‌ها یا مراحل را دوباره اجرا کنیم.

کووی-برانت می‌گوید مزیت دیگر این رویکرد، امکان اجرای همزمان مهاجرت برای صدها فایل در یک زمان بود.

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

در پایان مهاجرت، پرامپت‌های ما به اندازه‌ای بین ۴۰,۰۰۰ تا ۱۰۰,۰۰۰ توکن گسترش یافته بودند و تا ۵۰ فایل مرتبط، مجموعه‌ای کامل از مثال‌های چندشاتی (few-shot) دستی و همچنین مثال‌هایی از فایل‌های تست موجود، خوب نوشته شده و موفق از درون همان پروژه را در بر می‌گرفتند.

رویکرد مبتنی بر حلقه تلاش مجدد برای فایل‌های با پیچیدگی ساده تا متوسط مؤثر بود و امکان مهاجرت ۷۵٪ از کل فایل‌های تست را در چهار ساعت با حداکثر ده تکرار فراهم کرد. با این حال، این کار یک دنباله طولانی (long tail) از حدود ۹۰۰ فایل را باقی گذاشت.

برای آن فایل‌ها، رویکردی با اتوماسیون کمتر مورد نیاز بود. مهندسان Airbnb استراتژی "نمونه‌برداری، تنظیم، پاکسازی" (sample, tune, sweep) را اتخاذ کردند، هر مورد شکست خورده را تجزیه و تحلیل کردند، پرامپت و اسکریپت‌ها را برای رفع علت شکست به‌روزرسانی کردند و سپس فرآیند را برای فایل تحت تأثیر دوباره اجرا کردند.

در حالی که فایل‌های با پیچیدگی کمتر حداکثر به ده تکرار نیاز داشتند، فایل‌های دنباله طولانی بین ۵۰ تا ۱۰۰ بار تلاش مجدد نیاز داشتند که کل فرآیند را کندتر می‌کرد. با این حال، پس از چهار روز، تیم در مجموع ۹۷٪ از فایل‌ها را تبدیل کرده بود. فایل‌های باقی‌مانده، کمتر از ۱۰۰ عدد، به صورت دستی اصلاح شدند.

در مجموع، بهره‌گیری از LLMها برای مهاجرت تست، یک پروژه مهندسی که تخمین زده می‌شد ۱.۵ سال طول بکشد را تنها در شش هفته فشرده کرد، در حالی که هدف اصلی تست و پوشش کد (code coverage) حفظ شد.