‏چطور Grab با عوامل هوش مصنوعی بهره‌وری تیمش رو نجات داد

تیم Analytics Data Warehouse یا ADW در Grab — سوپراپ معروف جنوب‌شرق آسیا — بیش از ۱۵ هزار جدول داده رو مدیریت می‌کنه که ماهانه حدود هزار نفر از اونا استفاده می‌کنن. مشکل اصلی اینجا بود که مهندسان ارشد این تیم، هفته‌ای دو روز کامل رو صرف پاسخ به سؤال‌های ساده‌ای مثل «چرا این ID ناخواناست؟» می‌کردن. هر جواب نیاز به جستجو در کاتالوگ داده‌ها، ردیابی دستی خط سیر داده، اعتبارسنجی SQL و بررسی لاگ‌ها داشت.

تیم وقتی الگوی این سؤال‌ها رو آنالیز کرد، یه نکته‌ی مهم پیدا کرد: سؤال‌ها متفاوت بودن، ولی فرایند پاسخ دادن همیشه ثابت می‌موند. این ثبات، سیگنال خوبیه برای اتوماسیون. معماری سیستمی که ساختن روی یه اصل مهم بنا شده: جدا کردن «مغز» از «دست». مغز همون مدل زبانی (LLM) هست که استدلال می‌کنه، و دست‌ها عوامل تخصصی هستن که اطلاعات می‌گیرن، کوئری اجرا می‌کنن و با سیستم‌ها تعامل دارن.

از نظر تکنولوژی، از FastAPI برای مدیریت درخواست‌ها، LangGraph برای هماهنگی منطق چندعاملی (که شامل حلقه‌های بازگشتی و انتقال وظایف بین عوامل هست)، Redis برای کش و PostgreSQL برای ذخیره‌ی تاریخچه‌ی مکالمات استفاده کردن. سه پلتفرم داخلی هم به این سیستم متصلن: Hubble برای کاتالوگ متادیتا، Genchi برای کیفیت داده، و Lighthouse برای پایش وضعیت پایپ‌لاین‌ها.

معماری سیستم دو مسیر اصلی داره. مسیر بررسی برای سؤال‌های خواندنی (read-only) طراحی شده و چهار عامل تخصصی رو به‌کار می‌گیره: Classifier که سؤال رو تحلیل و مسیریابی می‌کنه، Data Agent که روی داده‌های واقعی کوئری می‌زنه، Code Search Agent که خط سیر تبدیل داده‌ها رو در کدبیس دنبال می‌کنه، و On-call Agent که وضعیت سلامت پایپ‌لاین‌ها رو چک می‌کنه. در نهایت Summarizer Agent یافته‌های همه رو ترکیب می‌کنه. مسیر بهبود برای عملیات نوشتنی مثل اضافه کردن ستون جدیده — اینجا یه عامل واحد درخواست رو پردازش می‌کنه، ولی همیشه یه مهندس انسانی باید تأیید بده.

وقتی سیستم به محیط واقعی رسید، چهار چالش جدی پیش اومد. اول سرریز context بین عوامل: با استفاده از tiktoken توکن‌ها رو ردیابی کردن و وقتی به حد مجاز نزدیک می‌شدن، پیام‌های قدیمی رو خلاصه می‌کردن. دوم ابزارهای اضافه: اول بیش از ۳۰ ابزار داشتن که توضیحات طولانی داشت و کارایی رو پایین می‌آورد — با حذف اطلاعات غیرضروری و خلاصه‌سازی، وضعیت بهتر شد. سوم ریسک اجرای کد: چهار لایه‌ی دفاعی ساختن شامل طبقه‌بندی ورودی، اعتبارسنجی SQL، محدودیت زمانی اجرا، و کنترل تغییرات. چهارم اعتماد کاربر: ابتدا همه‌ی پاسخ‌ها تا تأیید مهندس پنهان می‌موند که گلوگاه جدیدی ایجاد کرد؛ راه‌حل نهایی اینه که پاسخ‌ها فوری با برچسب «بررسی‌نشده» نمایش داده می‌شن.

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

نکات کلیدی:

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