نقش مهندس مستقر در محل در OpenAI چه معنایی دارد

وقتی Codex منتشر شد، یکی از اعضای تیم از من پرسید: «وقتی Codex بتواند موارد کاربردی را که چند ماه گذشته صرف ساختنشان کرده‌ایم، یک‌باره پیاده کند، ما چه می‌کنیم؟»

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

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

این تیم را در اوایل سال ۲۰۲۵ تأسیس کردم تا آنچه را «شکاف استقرار» می‌نامیم، برطرف کنیم: فاصلهٔ میان آنچه مدل‌ها ظاهراً قادر به انجامش هستند و آنچه مردم می‌توانند با اطمینان در کارشان استفاده کنند.

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

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

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

یافتن مهندسان مستقر در محلِ بااستعداد، هم‌زمان با بالا بردن حداقل معیار «به‌اندازهٔ کافی خوب»، مستلزم آزمودن و به‌کارگیری مداوم رویکردهای تازه بوده است.

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

یک نمایش اولیهٔ چشمگیر می‌تواند مدت‌ها همه را تحت تأثیر بگذارد، پیش از آنکه کسی بپرسد آیا در دنیای واقعی هم کار می‌کند یا نه.

وظیفهٔ ما حل مسئلهٔ مشتری با کیفیتی است که بتوانیم در محیط عملیاتی پای آن بایستیم.

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

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

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

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

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

تا آن زمان، قابلیت‌های Codex پیشرفت کرده بود. یکی از مهندسان مستقر در محل، بازسازی برنامهٔ خود بر پایهٔ Codex را آزمایش کرد و سپس با تیم همکاری کرد تا موارد کاربرد را به یک چارچوب آزمون مشترک با محوریت Codex منتقل کنند.

برنامه‌های اختصاصی به افزونه‌ها و مهارت‌هایی تبدیل شدند که بر اجزای پایهٔ مشترک Codex بنا شده بودند. Codex به رابط کاربری هم تبدیل شد و توانستیم رابط‌های ترمینالی و خط فرمان جداگانه‌ای را که برای هر مورد کاربرد نوشته بودیم، کنار بگذاریم.

توانستیم حدود ۹۰٪ از کد اختصاصی هر پروژه را حذف کنیم و این موضوع شیوهٔ ساخت، نگهداری و گسترش این گردش‌کارها را تغییر داد:

• می‌توانستیم از بهبودهای متمرکز Codex بهره ببریم و میزان کد واسط موردنیاز برای هر مورد کاربرد را کاهش دهیم

• قابلیت‌های کلیدی در قالب مهارت‌ها و افزونه‌ها بسته‌بندی شدند تا اشتراک‌گذاری آن‌ها میان تیم‌ها و کنترل متمرکزشان توسط مرکز تعالی هوش مصنوعی آسان‌تر شود. در نتیجه، گسترش راهکار از یک تیم به تیم دیگر می‌توانست به سادگیِ جایگزین کردن اتصال‌دهنده‌ها یا سرورهای MCP جدید، ساخت ارزیابی‌های تازه (که برای آن هم مهارتی داشتیم) و شروع کار باشد.

• در یک نمونه در اوت ۲۰۲۶، استقرار اولیه دو ماه طول کشید. گسترش راهکار به تیم دوم یک روز زمان برد. با گسترش کار، تیم‌های بعدی سریع‌تر راه افتادند؛ این روند ادامه داشته است، چنان‌که در یک مورد کاربرد در اوت ۲۰۲۶، پس از استقرار اولیهٔ دوماهه، راه‌اندازی برای تیم دوم فقط یک روز طول کشید.

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

به همین دلیل ترتیب کار مهم است. الگوهای زبانی بزرگ (LLM) به ما امکان می‌دهند سریع بسازیم. از این سرعت استفاده کنید تا چیزی ارزشمند به دست کاربران برسانید، یاد بگیرید چه چیزی در عمل دوام می‌آورد و سپس آنچه را جواب می‌دهد گسترش دهید.

همین اصل در همهٔ همکاری‌ها صدق می‌کند.

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

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

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

این راه دیگرِ از میان بردن نیاز به خودمان است: کمک کنیم مسئله‌ای که مدل‌های امروز نمی‌توانند حل کنند، به قابلیتی تبدیل شود که مدل‌های آینده ارائه می‌دهند. ثمرهٔ کار ما فراتر از ساعت‌هایی است که با هر مشتری می‌گذرانیم.

به OpenAI پیوستم تا کمک کنم هوش مصنوعی در کار روزمرهٔ مردم مفید باشد. این هدف همچنان راهنمای تیم است. اغلب به تیم می‌گویم که در بیشتر مواردِ توسعهٔ الگوهای زبانی بزرگ (LLM)، اصل تیغ اُکام صدق می‌کند: ساده‌ترین راهکار، بهترین است. در شرکتی که با پژوهش‌های پیشرو شناخته می‌شود و در صنعتی که اغراق بر آن سایه انداخته، می‌خواهیم چیزهایی بسازیم که مطمئن کار کنند و افرادی که در عمل از آن‌ها استفاده می‌کنند بتوانند به آن‌ها تکیه کنند.

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

اگر مسئلهٔ دشواری دارید که می‌خواهید حلش کنید، مشتاق همکاری با شما هستیم. اگر می‌خواهید در حل این مسائل کمک کنید، خوشحال می‌شویم به ما بپیوندید.

پس وقتی Codex می‌تواند کاری را انجام دهد که ما ماه‌ها صرف ساختنش کرده‌ایم، چه می‌کنیم؟

سراغ مسئلهٔ دشوارتر بروید