یه نکته‌ی جذاب در مقاله‌ی جدید مهندسی Uber اینه که برای نصف‌کردن latency جست‌وجوی Uber Eats، فقط سراغ بهینه‌سازی مدل یا زیرساخت نرفتن؛ کل مسیر «تایپ‌کردن تا دیدن اولین نتایج» رو اندازه گرفتن.

مثلاً hydration رو به دو بخش شکستن: داده‌هایی که ranking واقعاً لازم داره وارد critical path می‌شن و اطلاعات نمایشی مثل قیمت و تخفیف، هم‌زمان و جداگانه دریافت می‌شن. چند retrieval کم‌بازده رو هم حذف کردن، زنجیره‌ها رو زودتر deduplicate کردن و با گروه‌بندی آیتم‌های مشابه، تعداد lookupها رو بیشتر از ۱۰۰ برابر کاهش دادن. حتی در سرویس‌های Go، جای pointer و value type رو بازنگری کردن؛ چون در بعضی سرویس‌ها GC بیش از ۴۰٪ CPU رو مصرف می‌کرد. نمونه‌ی خوبی از این‌که performance معمولاً با یک ترفند عجیب بهتر نمی‌شه؛ بلکه باید کار اضافه، dependency اشتباه و allocationهای ریز روی hot path رو پیدا کرد!

اما برای من، جذاب‌ترین بخش ماجرا agent loop اوبر بود. به یک coding agent هدف مشخص کاهش latency و ابزارهایی برای خواندن traceهای واقعی production، پیدا‌کردن spanهای کند، نوشتن fix، بازکردن PR و اجرای benchmark داده بودن. بعد agent در یک حلقه‌ی «اندازه‌گیری ← تشخیص ← اصلاح ← اعتبارسنجی» جلو می‌رفت تا یا به هدف برسه یا بازده تغییر بعدی از یک حد کمتر بشه. نکته‌ی مهم اینه که اینجا agent صرفاً کد تولید نمی‌کنه؛ به observability و verification وصل شده و هر تغییر باید اثر قابل‌اندازه‌گیری داشته باشه. برای اینکه افزایش سرعت کیفیت نتایج جست‌وجو رو خراب نکنه هم یک سیستم ارزیابی مبتنی بر LLM ساخته بودن تا feedback loop سریع‌تر بشه.

به نظرم این دقیقاً یکی از کاربردهای جدی AI agentها در مهندسی نرم‌افزاره: سپردن بهینه‌سازی‌های کوچیک، کم‌هیجان ولی پرتعداد یا allocation نامناسب به سیستمی که پروداکشن رو مشاهده می‌کنه، تغییر می‌ده و نتیجه رو دوباره اندازه می‌گیره.


https://www.uber.com/gb/en/blog/uber-eats-search-pipeline


@gocasts