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

تصور کنید ابزاری دارید که ایمیلی بی‌نقص می‌نویسد، اما از پیام‌های اسلک (Slack)، تقویم یا جزئیات پروژه‌های شما هیچ خبری ندارد؛ در واقع شما با ابزاری سر و کار دارید که چشم‌بند زده است. مایکل فورای (Michael Foree)، مدیر علوم داده در استک اور‌فلو (Stack Overflow)، معتقد است همین شکاف در اتصال داده‌ها، یک «گلوگاه هوش مصنوعی» ایجاد کرده که مانع از پذیرش کامل عامل‌های (Agents) خودکار توسط کاربران می‌شود. این تحلیل در یک بررسی دقیق درباره اینکه چگونه «مهندسی زمینه» (Context Engineering) ارزش واقعی یک سامانه هوش مصنوعی را تعیین می‌کند، ارائه شده است. این بینش بر اساس گفتگوهای گسترده فورای با طیف متنوعی از متخصصان، از جمله مدیران فناوری (CTO)، مهندسان، تحلیل‌گران، طراحان گرافیک و مدیران پروژه شکل گرفته است.

شکاف زمینه (The Context Gap)

برای اکثر کاربران، هوش مصنوعی در محیط‌های ایزوله یا در خلأ باکفایت به نظر می‌رسد، اما به محض ورود به یک جریان کاری (Workflow) واقعی، شکست می‌خورد. فورای اشاره می‌کند که اگرچه AI قادر است بیشتر آنچه مردم می‌خواهند را انجام دهد، اما فاقد اتصال با ابزارهای واقعی است که مردم هر روز با آن‌ها کار می‌کنند.

برای درک بهتر، تلاش مورد نیاز برای استفاده از یک AI فعلی جهت پاسخ به تنها یک ایمیل را تصور کنید: شما باید متن ایمیل را کپی-پاست کنید، پیش‌زمینه و جزئیات مربوطه را از اپلیکیشن‌های دیگر استخراج کرده و ارائه دهید، پاسخ را طی یک یا دو بار تکرار و ویرایش اصلاح کنید و در نهایت آن را به‌صورت دستی به کلاینت ایمیل خود بازگردانید. این یک «بار کاری سنگین» (Heavy Lift) برای وظیفه‌ای است که باید بسیار ساده باشد.

این فرآیند تکه‌تکه شده، یک توازن منفی میان «تلاش» و «ارزش» ایجاد می‌کند. برای اینکه یک AI بتواند به‌طور خودکار به ایمیلی پاسخ دهد، نه تنها به اتصال مستقیم با ابزار ایمیل نیاز دارد، بلکه به یک مؤلفه «انسان در حلقه» (Human-in-the-loop) نیازمند است؛ جایی که کاربر بتواند بگوید: «نزدیک است، اما کاملاً درست نیست» و AI پیش از ارسال نهایی، مشکل را برطرف کند. بدون این ساختار، اغلب سریع‌تر است که کاربر ایمیل را خودش بنویسد.

با تکیه بر چالش‌های رایج صنعت در بازیابی داده‌ها — مشابه مفاهیم RAG (تولید تقویت‌شده با بازیابی) و فراخوانی ابزار (Tool Calling) — مشکل بنیادین این است که AI نمی‌تواند به‌طور بومی «بداند» فرستنده کیست یا تاریخچه یک پروژه چیست، مگر اینکه انسانی به‌طور دستی آن زمینه را مهندسی کند. در همین راستا، تلاش‌هایی برای استانداردسازی این اتصالات در جریان است، مانند آنچه در پروتکل MCP برای کاهش بار کاری ادغام هوش مصنوعی مشاهده می‌شود تا فرآیندهای متصل‌سازی از حالت دستی و پراکنده خارج شوند.

مکانیسم‌های گلوگاه هوش مصنوعی

فورای چندین مانع اصلی را شناسایی کرده است که مانع از تبدیل شدن AI به یک عامل واقعاً خودکار می‌شود:

• سیلوهای داده (Data Silos): اطلاعات به‌طور پراکنده در گوگل درایو، اسلک، جیرا (Jira) و رشته‌های ایمیل قرار دارند. برای ایجاد یک جریان کاری خودکار ایمیل، انسان باید تنظیمات گسترده‌ای انجام دهد: اتصال گوگل درایو برای دسترسی به بریف‌ها و درخواست‌های پیشنهاد (RFPs)، اعطای دسترسی به کانال‌های خاص اسلک و دادن اجازه به AI برای فشردن دکمه «ارسال». بسیاری از کاربران این فرآیند را بیش از حد خسته‌کننده می‌یابند، به‌ویژه اگر آن تسک را تنها یک یا دو بار در ماه انجام دهند.
• مشکل حواس‌پرتی (The Distraction Problem): وقتی داده‌های خام بیش از حد به AI داده می‌شود، مدل اغلب توسط اطلاعات نامرتبط «منحرف» می‌شود. فورای از استعاره شخصی استفاده می‌کند که می‌خواهد از روی یک تنه درخت بپرد اما توسط بلوبری‌ها حواسش پرت می‌شود؛ اگر به AI بگویید از روی تنه درخت بپرد اما اشاره کنید که بلوبری‌ها در نزدیکی هستند، ممکن است به‌جای پریدن، پاسخی درباره بلوبری‌ها بدهد.
• شکاف حدس‌زنی (The Guessing Gap): مدل‌ها مگر اینکه به‌طور خاص آموزش ببینند که به جزئیات خاصی اهمیت دهند — مانند اندازه تنه درخت یا وجود یک گودال آب — آموزش دیده‌اند که «حدس بزنند». در فضای تجاری، این بدان معناست که اگر AI به دنبال به‌روزرسانی «پروژه XYZ» باشد، ممکن است با هر ایمیلی که نام «جو» در آن است یا هر سندی که به پروژه اشاره دارد غرق شود و پاسخی دهد که با زمینه خاص پرسش مطابقت ندارد.
• هزینه توکن‌ها (Token Costs): این حواس‌پرتی‌ها نه تنها کیفیت خروجی را کاهش می‌دهند، بلکه هزینه توکن‌ها و زمان را افزایش می‌دهند. هر تکه داده نامرتبطی که وارد سیستم می‌شود، منابع پردازشی بیشتری مصرف می‌کند.

در حالی که مدل‌های زبانی بزرگ (LLM) جدیدتر در مقایسه با مدل‌های سه سال پیش — که فورای عملکرد آن‌ها در تشخیص تفاوت بین «حدس زدن» و «درخواست زمینه» را «پایین» (Abysmal) توصیف می‌کند — در حذف محتوای مزاحم و پرسیدن سوالات تکمیلی بهتر عمل می‌کنند، اما آن‌ها اساساً روی داده‌های عمومی آموزش دیده‌اند. این مدل‌ها هنوز فاقد آن «دستور پخت محرمانه» (Secret Sauce) هستند که مربوط به رویه‌های داخلی و اختصاصی هر شرکت است.

حل شکاف داده‌های اختصاصی

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

به جای آموزش مدل‌ها روی داده‌های خصوصی — که یک ریسک امنیتی جدی است — تیم آن‌ها در حال ساخت یک «متصل‌کننده دانش» (Knowledge Connector) است. این سیستم، زمینه لازم را برای AI فراهم می‌کند و سپس از یک سیستم «انسان در حلقه» برای تأیید پاسخ استفاده می‌کند.

در این مدل، AI یک سوال را شناسایی کرده و بر اساس داده‌های داخلی، پاسخی را پیشنهاد می‌دهد و سپس از یک متخصص انسانی می‌پرساند: «من تقریباً مطمئنم جواب این است... می‌توانید تأیید کنید که من به درستی به سوال پاسخ داده‌ام؟». این فرآیند به انسان اجازه می‌دهد AI را بر اساس سناریوهای خاص اصلاح کند و دقیقاً توضیح دهد که در یک موقعیت خاص چه کاری باید انجام شود. این کار یک حلقه بازخورد ایجاد می‌کند که مهندسی زمینه را بدون قرار دادن داده‌های حساس در مجموعه‌های آموزشی مدل پایه، بهبود می‌بخشد.

مهندسی زمینه در صنایع مختلف

این گلوگاه بسته به نقش کاربر به‌گونه‌ای متفاوت ظاهر می‌شود، همان‌طور که در نظرسنجی‌های فورای از افراد فنی و غیرفنی مشاهده شد:

• نقش‌های فنی: مدیران فناوری (CTO) و مهندسان با بار سنگین تنظیمات دستی API وe ناامیدی ناشی از حدس‌های «توهم‌آمیز» در زمانی که AI به یک سند داخلی خاص دسترسی ندارد، مواجه هستند. در محیط‌های سازمانی (Enterprise)، هزینه و تلاش برای راه‌اندازی نرم‌افزارهای جدید بیشتر است و این باعث می‌شود گلوگاه شدیدتر احساس شود.
• نقش‌های غیرفنی: برای افرادی مانند طراحان گرافیک، گلوگاه در نبود ابزارهای متصل برای تکرارهای سریع است. فورای مثالی از شخصی می‌زند که در حال بازطراحی یک اتاق نشیمن است؛ AI می‌توانست به‌درستی ترکیب رنگ پرده‌ها را شناسایی کند و چیدمان مبلمان را پیشنهاد دهد، اما کاربر مجبور بود به‌طور دستی عکسی با گوشی بگیرد، آن را ایمیل کند و سپس با AI تعامل کند. این گسست در اتصال مانع از تبدیل شدن ابزار به یک «عامل خودکار» می‌شود که مثلاً بتواند یک فروشگاه رنگ نزدیک را از طریق گوگل‌مپ پیدا کند و به کاربر اجازه دهد بدون ترک محیط AI، رنگ را بخرد.
• گردش‌های مصرف‌کننده: حتی کارهای ساده‌ای مانند خرید خواربار همچنان دستی باقی مانده است. در حالی که AI می‌تواند لیستی بر اساس حساسیت‌های غذایی اعضای خانواده و یک برنامه زمانی شلوغ تولید کند، فروشگاه‌های خواربار به‌ندرت APIهای خود را برای عامل‌های AI باز می‌کنند، زیرا ریسک‌های امنیتی وجود دارد و انگیزه‌ای برای فروشگاه‌ها نیست. مگر اینکه شخص ثالثی مانند Instacart انگیزه‌ای ایجاد کند، در غیر این صورت «آخرین مایل» از جریان کاری AI همچنان قطع است.

مسیر دستیابی به کاربرد بهتر AI

فورای روشی را پیشنهاد می‌کند که از برنامه‌های درسی مدارس ابتدایی وام گرفته شده و «مشاهده و تعجب» (Observe and Wonder) نام دارد. این روش شامل توقف آگاهانه برای شناسایی تک‌تک اطلاعاتی است که یک انسان به‌طور طبیعی پیش از انجام یک کار در نظر می‌گیرد. این رویکرد، دقیقاً عکس ذهنیتی است که در پذیرش اولیه AI حاکم بود: «فقط انجامش بده» (Just Do).

مهندسی زمینه گام‌به‌گام شامل موارد زیر است:

۱. مشاهده جریان کار: بلند فکر کردن درباره منابع اطلاعاتی که یک انسان هنگام ارسال یک ایمیل خاص در نظر می‌گیرد (و یا نادیده می‌گیرد). برای مثال، بررسی اینکه آیا پاسخ به «جو» به سطح اهمیت او یا تاریخچه رشته پیام‌های یک پروژه خاص بستگی دارد یا خیر.
۲. لیست کردن منابع داده: شناسایی تمام منابع مرتبط (ایمیل‌ها، چت‌ها، بریف‌ها) که اپلیکیشن پاسخ‌دهنده باید به آن‌ها دسترسی داشته باشد. اگر به‌روزرسانی پروژه XYZ مورد نیاز است، انسان باید تشخیص دهد که این داده در اسلک است، جیرا است یا در یادداشت‌های یک جلسه.
۳. فیلتر کردن نویز: تعیین اینکه AI باید کدام اطلاعات زائد را رد کند تا دچار حواس‌پرتی نشود.
۴. تست شبیه‌سازی (Mock Testing): آزمایش AI در موقعیت‌های شبیه‌سازی شده برای کشف اینکه چرا مدل به‌جای یک تکه داده، به سراغ داده‌ای دیگر رفته است. این یک فرآیند خلاقانه برای حل مسئله است تا بفهمند چه چیزی فراموش شده یا چه چیزی باعث حواس‌پرتی مدل شده است.
۵. معماری تکرارپذیر: اصلاح فرآیند برای افزایش کاربرد (Jazz up) و مستندسازی نتایج برای ساخت یک معماری کلی‌تر و بهتر از زمینه.

این رویکرد با کدنویسی نه به عنوان یک هدف، بلکه به عنوان وسیله‌ای برای رسیدن به هدف برخورد می‌کند. فورای این تجربه را با خدمات ابری AWS مقایسه می‌کند؛ او از کسی که به‌سختی می‌توانست نام AWS را هجی کند، به کسی تبدیل شد که توانست در یک بعدازظهر یک وب‌سایت میزبانی‌شده را راه‌اندازی کند، زیرا ابری‌سازی مدیریت سرور را ساده کرده بود. به‌طور مشابه، «کدنویسی بر اساس حس و شهود» (Vibe Coding) به افراد اجازه می‌دهد از کد به‌عنوان ابزاری برای رسیدن به اهداف استفاده کنند — مانند ساخت یک اپلیکیشن خرید خواربار در یک بعدازظهر — بدون اینکه پیش‌زمینه فنی عمیقی داشته باشند. او اشاره می‌کند که اگرچه برخی بیان‌های هنری سنتی ممکن است کمرنگ شوند، اما فرم جدیدی از بیان در حال انفجار است زیرا سد ورود به این حوزه پایین آمده است.

برای آینده هوش مصنوعی، فورای با قطبی‌سازی این فناوری — جایی که یا به عنوان منجی مطلق یا نابودگر بشریت دیده می‌شود — مخالفت می‌کند. در عوض، هدف باید این باشد که تشخیص دهیم AI صرفاً یک ابزار دیگر است. برندگان واقعی کسانی خواهند بود که روی نقاط قوت AI نسبت به انسان و نقاط ضعف آن تمرکز کنند، از عجله برای «فقط انجام دادن» دست بکشند و در عوض زمان بگذارند تا الزامات زمینه خاص جریان‌های کاری خود را به‌دقت بررسی کنند.

گام بعدی شما

• برای هر تسک تکراری، یک لیست از «منابع داده‌ای» که در حال حاضر دستی چک می‌کنید تهیه کنید.
• هنگام استفاده از AI، به‌جای دستورات کلی، «محدودیت‌های زمینه» را تعریف کنید (مثلاً: فقط از فایل X برای پاسخ استفاده کن و هر چیز دیگری را نادیده بگیر).
• اگر توسعه‌دهنده هستید، روی پیاده‌سازی لایه‌های فیلتراسیون قبل از ارسال داده به مدل تمرکز کنید تا توکن‌های اضافی مصرف نشود.

اما تأثیر این رویکرد بر هزینه عملیاتی مدل‌های استدلالی حتی پیچیده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی هزینه استنتاج مراجعه کنید.