از خواندن برای ساختن یک کتابخانه دست بکشید. برای حل یک مسئله شروع به خواندن کنید.
بیشتر لیستهای مطالعه مهندسی بر جمعآوری دانش تمرکز دارند. مهندسی مدرن پاداش خود را به حل گلوگاهها (bottlenecks) میدهد.
اخیراً یک مهندس تازهکار لیستی با عنوان «۱۰ کتاب برتر برای مهندسان» به من نشان داد. این لیست دقیقاً شبیه لیستهای ده سال پیش بود و بر همان فرض قدیمی تکیه داشت.
فرض بر این است که خواندن کتابهای کافی شما را به مهندس بهتری تبدیل میکند. تیمهای با عملکرد بالا اینگونه یاد نمیگیرند.
بهترین مهندسان، برنامههای یادگیری خود را حول محور محدودیتها (constraints) میسازند.
لیستهای مطالعه استاندارد فرض میکنند که تمام دانش ارزشمند است. در واقعیت، ارزش مهندسی به زمینه (context) بستگی دارد.
• یک مهندس backend که با مشکلات پایگاه داده مواجه است، نیازی به کتابی درباره Agile ندارد. • تیمی که هزینه بسیار زیادی برای AI inference صرف میکند، نیازی به یک کتاب عمومی در مورد مهارتهای حرفهای (craftsmanship) ندارد. • یک استارتاپ که با مشکلات latency روبروست، نیازی به یک چارچوب رهبری ندارد.
این افراد به راهحلهایی برای گلوگاه خاصی که مقابلشان قرار دارد نیاز دارند. لیستهای مطالعه برای «کامل بودن» بهینهسازی شدهاند، اما مهندسی به «مرتبط بودن» پاداش میدهد.
مبانی مانند پایگاههای داده و شبکهسازی همچنان مهم هستند، اما دیگر کافی نیستند.
سیستمهای مدرن محدودیتهای جدیدی ایجاد میکنند. هزینههای AI inference یک نمونه بارز است. لیستهای سنتی بهندرت این مشکلات را پوشش میدهند.
چالش دیگر فقط نوشتن نرمافزار صحیح نیست؛ چالش، ساختن سیستمهای قابل اعتماد بر روی اجزای احتمالی (probabilistic components) است.
در گذشته، مهندسان با سیستمهای قطعی (deterministic) کار میکردند. ورودی یکسان، خروجی یکسانی تولید میکرد.
امروزه سیستمها متفاوت رفتار میکنند. یک prompt پاسخهای متفاوتی میدهد. یک agent مسیرهای متفاوتی را طی میکند. ارتقای یک مدل، بدون اینکه شما کد خود را تغییر دهید، رفتار سیستم را تغییر میدهد.
سوالات جدید اینها هستند: • چگونه کیفیت را ارزیابی میکنید؟ • چگونه این تغییرات را مدیریت میکنید؟
اینها موارد استثنایی (edge cases) نیستند؛ اینها وظایف روزمره مهندسی هستند.
مهندسان قوی کتابها را از ابتدا تا انتها نمیخوانند. آنها برای درک مکانیسمها مطالعه میکنند. آنها یک گلوگاه را پیدا میکنند، مکانیسم آن را شناسایی میکنند و فقط آنچه را که نیاز دارند میآموزند.
• اگر latency بالا است، روی batching مطالعه کنید. • اگر context یک مسئله است، روی retrieval مطالعه کنید. • اگر agentها شکست میخورند، روی evaluation مطالعه کنید.
این کار یادگیری را مستقیماً به تولید (production) متصل میکند. دانش به یک اهرم تبدیل میشود.
از این حلقه یادگیری استفاده کنید:
- گلوگاه را شناسایی کنید.
- منبع خاص برای آن مشکل را پیدا کنید.
- راهحل را اعمال کنید.
از تلاش برای تمام کردن یک لیست مطالعه دست بکشید. تلاش برای بهبود سیستم را شروع کنید.
پیش از مطالعه کتاب بعدی، از خود بپرسید: بزرگترین محدودیت در سیستم من چیست؟
آیا تأخیر، هزینه، قابلیت اطمینان یا قابلیت مشاهده است؟
منبعی را بیابید که آن گلوگاه را هدف قرار میدهد. مهندسی یک مسابقه مطالعه نیست، بلکه حرفهای برای حل محدودیتهاست.
سیستم تعیین میکند که در مرحله بعد چه چیزی یاد بگیرید.