راهنمای آمادگی مصاحبه شغلی مهندس هوش مصنوعی

معرفی

شایستگی‌های مورد سنجش

برای آشنایی بهتر با این راهنما، توجه به موارد زیر می‌تواند مفید باشد.

• تبدیل مسئله محصول به راه‌حل هوش مصنوعی

  توانایی تشخیص اینکه مدل واقعاً چه مسئله‌ای را حل می‌کند، ورودی و خروجی قابل‌قبول چیست و چه زمانی راه‌حل ساده‌تر از مدل مناسب‌تر است.

• توسعه سرویس با Python و API

  توانایی ساخت سرویس قابل‌استفاده، اعتبارسنجی ورودی، مدیریت خطا، طراحی قرارداد API و اتصال آن به سرویس‌های دیگر.

• طراحی RAG و مدیریت زمینه

  درک آماده‌سازی اسناد، بازیابی، انتخاب زمینه، ارجاع به منبع، کنترل پاسخ بدون پشتوانه و محدودیت‌های جست‌وجوی معنایی.

• ارزیابی خروجی مدل

  توانایی ساخت مجموعه آزمون، تعریف معیار پذیرش، بررسی پاسخ‌های نامطلوب و مقایسه نسخه‌های پرامپت، مدل یا جریان بازیابی.

• مهندسی پرامپت و خروجی ساخت‌یافته

  طراحی دستور، تعیین نقش و محدودیت، مدیریت زمینه و اعتبارسنجی خروجی مدل برای استفاده در فرایندهای محصول.

• داده، پایگاه داده و جست‌وجوی برداری

  درک کیفیت داده، قطعه‌بندی اسناد، متادیتا، PostgreSQL و کاربرد pgvector در بازیابی اطلاعات سازمانی.

• عملیاتی‌سازی و مشاهده‌پذیری

  شناخت استقرار سرویس، ثبت درخواست و خطا، پایش تأخیر و هزینه، نسخه‌بندی و بازتولید خطاهای تولیدی.

• امنیت و حریم خصوصی

  تشخیص ریسک ارسال داده حساس به مدل یا سرویس بیرونی، کنترل دسترسی، اعتبارسنجی ورودی و مقابله با سوءاستفاده از ابزارها.

• ارتباط فنی با محصول و تیم

  توانایی توضیح محدودیت، عدم‌قطعیت و هزینه مدل به مدیر محصول و هماهنگی با بک‌اند، داده، زیرساخت و امنیت.

برنامه آماده‌سازی

در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.

• مرور پروژه قابل‌ارائه

  یک پروژه را انتخاب کنید که بتوانید از ابتدا تا انتها توضیح دهید: مسئله کاربر، منبع داده، معماری، API، معیار ارزیابی، خطاهای شناخته‌شده و گام بعدی. برای هر تصمیم، جایگزین‌های ردشده را نیز آماده کنید؛ مثلاً دلیل استفاده از RAG به‌جای قراردادن همه اسناد در پرامپت.

  مخزن GitHub باید راهنمای اجرا، متغیرهای محیطی بدون کلید محرمانه، نمونه درخواست API و محدودیت‌های پروژه را داشته باشد. اگر پروژه عمومی نیست، نمودار معماری و نمونه‌های ناشناس‌شده از ورودی و خروجی آماده کنید.

• طراحی RAG و کیفیت بازیابی

  رابطه میان کیفیت سند، قطعه‌بندی، بردارسازی متن (embedding)، متادیتا، بازیابی و پاسخ نهایی را مرور کنید. بتوانید توضیح دهید برای پرسش‌های بیرون از دامنه چه رفتاری تعریف می‌کنید و چگونه منبع بازیابی‌شده را به کاربر نشان می‌دهید.

  یک مجموعه کوچک از پرسش‌های واقعی بسازید و برای هر پرسش، پاسخ مرجع یا معیار قضاوت مشخص کنید. پاسخ درست با منبع نامرتبط را از پاسخ روان اما بی‌پشتوانه جداگانه بررسی کنید.

• API و مهندسی سرویس

  با Python و FastAPI یک نقطه پایانی API (endpoint) طراحی کنید که ورودی را اعتبارسنجی کند، خطاهای سرویس مدل را مدیریت کند و پاسخ قابل‌پیش‌بینی بدهد. تفاوت خطای کاربر، خطای وابستگی بیرونی و خطای داخلی را در کد و پاسخ API مشخص کنید.

  برای پرسش‌های فنی، قرارداد درخواست و پاسخ، timeout، retry محدود، ثبت شناسه درخواست و تست مسیرهای خطا را مرور کنید.

• ارزیابی، هزینه و تأخیر

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

  تمرین کنید دو نسخه پرامپت یا دو تنظیم بازیابی را با یک مجموعه ثابت مقایسه کنید؛ تغییر هم‌زمان چند عامل، نتیجه را غیرقابل‌تفسیر می‌کند.

• امنیت داده و رفتارهای پرخطر مدل

  سناریوهای نشت داده در لاگ، ارسال متن حساس به سرویس بیرونی، prompt injection و فراخوانی ابزار با ورودی غیرقابل‌اعتماد را مرور کنید. بتوانید کنترل‌های متناسب مانند حداقل‌سازی داده، کنترل دسترسی، فهرست مجاز ابزارها و اعتبارسنجی خروجی را پیشنهاد دهید.

• آمادگی متناسب با شاخه آگهی

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

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

• تمرین طراحی سامانه

  یک مسئله مانند دستیار مستندات داخلی را در ۲۰ دقیقه طراحی کنید: کاربران، داده مجاز، مسیر درخواست، ذخیره‌سازی، بازیابی، مدل، API، لاگ، معیار ارزیابی و مسیر جایگزین هنگام ناموفق‌بودن مدل. در طراحی، فرض‌های خود را صریح بیان کنید.

چک‌لیست آماده‌سازی

موارد زیر را یک‌به‌یک بررسی کنید تا چیزی جا نماند:

• یک پروژه کامل را با مسئله، معماری، معیار ارزیابی و محدودیت‌ها مرور کرده‌ام.
• لینک GitHub یا مستندات نمونه‌کارم قابل‌دسترسی و بدون کلید محرمانه است.
• برای پروژه‌ام نمونه درخواست و پاسخ API آماده کرده‌ام.
• می‌توانم تولید تقویت‌شده با بازیابی (Retrieval-Augmented Generation یا RAG)، تنظیم مدل و استفاده مستقیم از API مدل را توضیح دهم.
• یک مجموعه پرسش آزمون و معیار ارزیابی برای خروجی پروژه‌ام دارم.
• خطاهای مهم پروژه و روش رفع یا کاهش آن‌ها را آماده کرده‌ام.
• مفاهیم timeout، retry، rate limit و مدیریت خطای سرویس مدل را مرور کرده‌ام.
• ریسک‌های داده حساس، prompt injection و ثبت لاگ را برای پروژه‌ام بررسی کرده‌ام.
• شرح وظایف آگهی و ابزارهای موردنیاز آن را با تجربه خود تطبیق داده‌ام.
• پرسش‌هایم درباره داده، مدل، معیار کیفیت و استقرار تیم را آماده کرده‌ام.
• محیط جلسه آنلاین، اینترنت، دسترسی مخزن و نمایش نمونه‌کار را آزموده‌ام.

سئوالاتی که از شما می‌پرسند

• نمونه‌کار

  پروژه هوش مصنوعی شما چه مسئله‌ای را حل می‌کرد و چرا استفاده از مدل برای آن ضروری بود؟

  سنجش توانایی تعریف مسئله، تشخیص تناسب راه‌حل هوش مصنوعی و پرهیز از استفاده نمایشی از مدل.

  راهنمای پاسخ و نمونه پاسخ

  مسئله را با کاربر، تصمیم یا فرایند مشخص بیان کنید. توضیح دهید راه‌حل قبلی چه کمبودی داشت و مدل چه بخشی را بهبود می‌داد. سپس معیار موفقیت را نام ببرید؛ مانند کاهش زمان یافتن پاسخ در مستندات یا افزایش پوشش پاسخ‌های قابل‌استناد.

  اگر راه‌حل غیرهوشمند نیز ممکن بود، دلیل انتخاب مدل و هزینه یا ریسک آن را صادقانه مقایسه کنید.

  در پروژه من، کاربران برای یافتن سیاست‌های داخلی باید چند فایل پراکنده را جست‌وجو می‌کردند. مسئله، تولید متن نبود؛ پیدا کردن پاسخ مستند در زمان کوتاه بود. RAG را انتخاب کردم تا پاسخ فقط بر اساس اسناد تأییدشده تولید شود و منبع آن نمایش داده شود. موفقیت را با ارتباط پاسخ، وجود منبع درست و زمان پاسخ سنجیدم. برای پرسش‌های خارج از اسناد، سامانه به‌جای حدس‌زدن اعلام می‌کرد اطلاعات کافی ندارد.

• فنی

  RAG چیست و در چه شرایطی آن را به استفاده مستقیم از یک مدل زبانی ترجیح می‌دهید؟

  سنجش درک تولید تقویت‌شده با بازیابی و توانایی تشخیص کاربرد آن برای دانش متغیر یا سازمانی.

  راهنمای پاسخ و نمونه پاسخ

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

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

  در RAG، پیش از تولید پاسخ، اسناد مرتبط با پرسش بازیابی می‌شوند و مدل با تکیه بر همان زمینه پاسخ می‌دهد. آن را برای مستندات محصول، آیین‌نامه‌های داخلی یا اطلاعاتی که مرتب تغییر می‌کنند ترجیح می‌دهم، چون به‌روزرسانی دانش با تغییر اسناد انجام می‌شود، نه آموزش دوباره مدل. اما اگر بازیابی منبع اشتباه را برگرداند، مدل هم احتمالاً پاسخ نامرتبط می‌دهد؛ بنابراین کیفیت بازیابی را جدا از کیفیت تولید ارزیابی می‌کنم.

• فنی

  اگر پاسخ‌های سامانه RAG روان اما نادرست هستند، چگونه منشأ خطا را پیدا می‌کنید؟

  سنجش روش عیب‌یابی زنجیره بازیابی و تولید، نه صرفاً پیشنهاد تغییر پرامپت.

  راهنمای پاسخ و نمونه پاسخ

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

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

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

• فنی

  برای یک API مبتنی بر مدل زبانی چه خطاها و کنترل‌هایی را طراحی می‌کنید؟

  سنجش درک تولید نرم‌افزار قابل‌اعتماد پیرامون مدل و سرویس‌های بیرونی.

  راهنمای پاسخ و نمونه پاسخ

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

  برای خروجی، قالب ساخت‌یافته و اعتبارسنجی پس از تولید را توضیح دهید. retry باید محدود و فقط برای خطاهای موقت باشد تا هزینه و بار اضافی نسازد.

  در ورودی، نوع درخواست، طول متن و سطح دسترسی کاربر را بررسی می‌کنم و برای جلوگیری از مصرف بی‌رویه، rate limit می‌گذارم. فراخوانی مدل timeout دارد و خطاهای موقت با retry محدود و backoff مدیریت می‌شوند. برای پاسخ‌های ساخت‌یافته، خروجی مدل را با schema اعتبارسنجی می‌کنم؛ اگر معتبر نبود، پاسخ کنترل‌شده یا خطای قابل‌پیگیری برمی‌گردانم. متن حساس را کامل در لاگ نگه نمی‌دارم و برای هر درخواست یک شناسه ثبت می‌کنم تا بتوانم خطا را بدون افشای داده کاربر بررسی کنم.

• موقعیتی

  مدیر محصول می‌خواهد دستیار شرکت برای همه پرسش‌ها پاسخ قطعی بدهد، اما داده‌های موجود ناقص است. چه پیشنهاد می‌دهید؟

  سنجش توانایی مدیریت انتظار محصول، بیان محدودیت مدل و طراحی رفتار ایمن در ابهام.

  راهنمای پاسخ و نمونه پاسخ

  به‌جای پذیرش یا رد کلی درخواست، دامنه دانش، گروه‌های پرسش و هزینه پاسخ نادرست را مشخص کنید. پیشنهاد دهید تصمیم پاسخ‌گویی بر پایه معیار اعتبارسنجی‌شده روی مجموعه ارزیابی باشد؛ مانند وجود منبع معتبر، کیفیت رتبه‌بندی و نتایج آزمون‌های برچسب‌خورده.

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

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

• فنی

  چگونه کیفیت یک قابلیت هوش مصنوعی را پیش از انتشار ارزیابی می‌کنید؟

  سنجش توانایی تعریف ارزیابی تکرارپذیر و تفکیک کیفیت مدل از معیارهای محصول و عملیات.

  راهنمای پاسخ و نمونه پاسخ

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

  در کنار کیفیت، تأخیر، هزینه، نرخ خطا و رفتار موارد خارج از دامنه را بسنجید. ارزیابی دستی نمونه‌های پرریسک را حذف نکنید.

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

• نمونه‌کار

  در پروژه خود چگونه داده یا اسناد را برای بازیابی آماده کردید؟

  سنجش تجربه عملی در کیفیت داده، قطعه‌بندی، متادیتا و اثر آن‌ها بر پاسخ مدل.

  راهنمای پاسخ

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

  اگر داده ناقص یا دارای دسترسی محدود بود، مرز دسترسی و رفتار سامانه در نبود منبع را توضیح دهید.

• موقعیتی

  هزینه فراخوانی مدل پس از رشد استفاده از محصول دو برابر شده است. چگونه مسئله را بررسی و اولویت‌بندی می‌کنید؟

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

  راهنمای پاسخ و نمونه پاسخ

  ابتدا هزینه را بر حسب endpoint، نوع درخواست، مدل، طول ورودی و خروجی، کاربر یا جریان محصول تفکیک کنید. بررسی کنید افزایش ناشی از رشد مشروع استفاده، زمینه بیش‌ازحد، retry، درخواست‌های تکراری یا سوءاستفاده است.

  راه‌حل‌ها را با اثر بر کیفیت مقایسه کنید: cache برای درخواست‌های مناسب، محدودکردن زمینه، انتخاب مدل کوچک‌تر برای کارهای ساده، خلاصه‌سازی کنترل‌شده و سقف مصرف. هر تغییر باید با ارزیابی کیفیت همراه باشد.

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

• رفتاری

  نمونه‌ای بگویید که بازخورد کاربران یا تیم پشتیبانی نشان داد خروجی مدل با انتظار محصول فاصله دارد.

  سنجش مسئولیت‌پذیری در برابر رفتار واقعی سرویس و توانایی تبدیل بازخورد کیفی به اقدام فنی.

  راهنمای پاسخ و نمونه پاسخ

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

  روشن کنید آیا مشکل از داده، بازیابی، پرامپت، قرارداد API یا انتظار نادرست محصول بود و چگونه از تکرار آن جلوگیری کردید.

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

• رفتاری

  وقتی توسعه‌دهنده بک‌اند با استفاده از یک فریم‌ورک جریان مدل مخالف است، چگونه درباره تصمیم فنی به توافق می‌رسید؟

  سنجش همکاری میان‌رشته‌ای و توانایی انتخاب ابزار بر اساس نیاز نگهداری، نه علاقه شخصی.

  راهنمای پاسخ و نمونه پاسخ

  اختلاف را به معیارهای روشن تبدیل کنید: پیچیدگی جریان، قابلیت تست، مشاهده‌پذیری، وابستگی به کتابخانه، سرعت توسعه و توان تیم برای نگهداری. توضیح دهید چه زمانی پیاده‌سازی ساده با Python و FastAPI از فریم‌ورک مناسب‌تر است.

  به نمونه اولیه محدود یا مقایسه فنی کوتاه اشاره کنید و تصمیم را همراه با پیامدهای نگهداری مستند کنید.

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

• فرهنگی

  برای کار با داده‌های حساس مشتری در یک قابلیت هوش مصنوعی چه خط قرمزهایی دارید؟

  سنجش بلوغ حرفه‌ای در حریم خصوصی، امنیت داده و توانایی متوقف‌کردن تصمیم پرریسک.

  راهنمای پاسخ و نمونه پاسخ

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

  برای ریسک prompt injection یا فراخوانی ابزار، جداسازی دستورهای سیستمی، محدودسازی ابزارها و اعتبارسنجی اقدام‌های حساس را توضیح دهید.

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

• فنی

  چه زمانی استفاده از مدل متن‌باز را به API یک ارائه‌دهنده مدل ترجیح می‌دهید؟

  سنجش توانایی مقایسه مالکیت داده، هزینه، تأخیر، کیفیت، زیرساخت و بار نگهداری.

  راهنمای پاسخ و نمونه پاسخ

  مقایسه را چندبعدی انجام دهید: حساسیت داده، نیاز به کنترل محیط اجرا، حجم استفاده، کیفیت مدل برای زبان و وظیفه هدف، تأخیر، هزینه زیرساخت و توان تیم برای استقرار و پایش.

  تأکید کنید مدل متن‌باز الزاماً ارزان‌تر یا مناسب‌تر نیست؛ هزینه GPU، مقیاس‌پذیری، به‌روزرسانی و عملیات نیز باید محاسبه شود.

  اگر داده بسیار حساس است یا سازمان باید محیط اجرا را کنترل کند، مدل متن‌باز می‌تواند گزینه قابل‌بررسی باشد؛ به شرطی که تیم توان استقرار، مقیاس‌پذیری و پایش آن را داشته باشد. برای محصولی با حجم کم و نیاز به شروع سریع، API ممکن است زمان عرضه و پیچیدگی عملیات را کاهش دهد. تصمیم را با آزمون روی داده واقعی، هزینه کل مالکیت، تأخیر و کیفیت وظیفه می‌گیرم، نه صرفاً بر اساس اندازه یا محبوبیت مدل.

• فرهنگی

  اگر بدانید مدل در یک سناریوی مهم پاسخ قابل‌اعتماد نمی‌دهد، چگونه موضوع را با مدیر محصول مطرح می‌کنید؟

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

  راهنمای پاسخ

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

  معیار تصمیم و آزمایش بعدی را مشخص کنید تا گفت‌وگو به اختلاف سلیقه تبدیل نشود.

• نمونه‌کار

  اگر بخواهید همین پروژه را یک ماه دیگر ادامه دهید، چه چیزی را اول بهبود می‌دهید؟

  سنجش خودارزیابی فنی، شناخت بدهی‌های پروژه و اولویت‌بندی واقع‌بینانه.

  راهنمای پاسخ و نمونه پاسخ

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

  از فهرست‌کردن فناوری‌های متعدد بدون مسئله مشخص پرهیز کنید.

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

پرسش‌های شما از پنل مصاحبه

• کاربرد اصلی قابلیت هوش مصنوعی در این تیم چیست و کاربر در کدام نقطه از محصول با آن روبه‌رو می‌شود؟

  روشن می‌کند نقش روی یک مسئله محصول واقعی کار می‌کند یا صرفاً نمونه‌سازی پراکنده انجام می‌دهد.

• منابع داده این قابلیت چیست و مسئول کیفیت، به‌روزرسانی و سطح دسترسی به آن‌ها چه تیمی است؟

  کیفیت و مالکیت داده، امکان تحویل یک راه‌حل RAG یا مدل‌محور قابل‌اعتماد را تعیین می‌کند.

• تیم پاسخ مدل را با چه معیارهایی ارزیابی می‌کند و چه کسی درباره آماده‌بودن برای انتشار تصمیم می‌گیرد؟

  نشان می‌دهد سازمان فقط دموی مدل می‌خواهد یا برای کیفیت و ریسک خروجی فرایند دارد.

• مدل‌ها از طریق API بیرونی استفاده می‌شوند، در زیرساخت خودتان اجرا می‌شوند یا هر دو مسیر وجود دارد؟

  بر ابزارها، محدودیت داده، هزینه، مسئولیت عملیاتی و نوع تجربه موردنیاز اثر مستقیم دارد.

• در رخدادهایی مانند پاسخ نادرست، افشای احتمالی داده یا افزایش ناگهانی هزینه مدل، روند واکنش تیم چیست؟

  بلوغ عملیاتی و میزان جدی‌گرفتن امنیت و مشاهده‌پذیری را آشکار می‌کند.

• این نقش با کدام افراد در بک‌اند، محصول، داده و امنیت همکاری روزانه دارد؟

  مرز مسئولیت‌ها و کیفیت همکاری میان تیمی را روشن می‌کند.

• نمونه‌ای از دشوارترین محدودیت فنی فعلی این قابلیت چیست: کیفیت، داده، تأخیر، هزینه یا استقرار؟

  به شما کمک می‌کند مسئله واقعی نقش و انتظارهای فنی آن را پیش از پذیرش پیشنهاد بشناسید.

اشتباه‌های رایج

در ادامه تعدادی از اشتباهاتی که اغلب افراد در مصاحبه شغل «مهندس هوش مصنوعی» انجام می‌دهند، آمده است. پرهیز از انجام این اشتباهات، می‌تواند شانس شما را برای پذیرفته شدن از مصاحبه و استخدام نهایی بیشتر کند.

• معرفی پروژه به‌عنوان دموی ابزار گفت‌وگو

  پروژه را با مسئله، جریان داده، API، معیار ارزیابی، خطاهای شناخته‌شده و تصمیم‌های مهندسی توضیح دهید؛ نه فقط با نام مدل یا ابزار.

• پاسخ‌دادن به هر مشکل با تغییر پرامپت

  در عیب‌یابی، داده، بازیابی، زمینه، مدل و قرارداد خروجی را جداگانه بررسی کنید. نشان دهید پرامپت تنها یکی از اجزای سامانه است.

• نداشتن معیار برای کیفیت خروجی

  پیش از مصاحبه، مجموعه‌ای از پرسش‌های آزمون و معیارهای روشن مانند اتکا به منبع، درستی، تأخیر و هزینه آماده کنید.

• نادیده‌گرفتن پاسخ خارج از دامنه

  توضیح دهید سامانه در نبود منبع معتبر باید ناتوانی خود را اعلام کند، درخواست شفاف‌سازی دهد یا کاربر را به مسیر جایگزین هدایت کند.

• بی‌توجهی به داده حساس و لاگ‌ها

  برای پروژه خود مشخص کنید چه داده‌ای ذخیره یا ارسال می‌شود، چه کسی دسترسی دارد و چگونه متن حساس را در لاگ و محیط آزمایش کنترل می‌کنید.

• ادعای تسلط بر ابزار بدون توضیح انتخاب آن

  برای ابزارهایی مانند LangChain، Docker یا pgvector، مسئله‌ای را بیان کنید که با آن حل کرده‌اید و محدودیت یا جایگزین ابزار را نیز بشناسید.

• پنهان‌کردن محدودیت‌های نمونه‌کار

  محدودیت‌ها را شفاف بگویید و برای هر مورد، اقدام بعدی واقع‌بینانه پیشنهاد دهید. شناخت مرزهای راه‌حل نشانه ضعف نیست.

پس از مصاحبه

پرسش‌های پرتکرار

در این بخش، به تعدادی از پرسش‌های رایج درباره این راهنما پاسخ داده شده است.

آموزش‌های مرتبط در فرادرس

• آموزش چت جی پی تی ChatGPT API، از مهندسی پرامپت تا پروژه‌های کاربردی + گواهینامه آموزش ویدئویی
• آموزش مهندسی پرامپت + بهینه‌سازی عملکرد پرامپت‌ها در مدل‌های زبانی + گواهینامه آموزش ویدئویی
• آموزش شکل‌دهنده‌های پرامپت یا Prompt Decorators برای بهبود پاسخ‌های هوش مصنوعی + گواهینامه آموزش ویدئویی
• دوره‌های محبوب هوش مصنوعی فرادرس آموزش ویدئویی
• دوره‌های محبوب یادگیری ماشین فرادرس آموزش ویدئویی
• رشته هوش مصنوعی چیست؟ – هر آنچه باید بدانید آموزش متنی