وقتی درباره روندهای هوش مصنوعی صحبت می‌کنیم، نام مدل‌ها و ویدئوهای نمایشی زودتر از مسائل واقعی محصول دیده می‌شوند. برای یک تیم مهندسی، سؤال مفیدتر این است: کدام تغییر می‌تواند زمان انجام یک کار مشخص را کم کند، کیفیت آن را بهتر کند و در محیط واقعی قابل نگهداری بماند؟ این مقاله نگاهی تحلیلی به چند جهت مهم دارد؛ پیشنهادهای اجرایی آن چارچوب تصمیم‌گیری تحریریه هستند و گزارش عملکرد محصولات شرکت محسوب نمی‌شوند.
۱. مهندسی زمینه به جای انباشتن دستورها
در مقاله مهندسی زمینه Anthropic، توجه از متن دستور به مجموعه اطلاعاتی منتقل می‌شود که مدل هنگام پاسخ‌گویی می‌بیند: سابقه گفت‌وگو، نتیجه ابزارها و اسناد مرتبط. پیام کاربردی این بحث، انتخاب اطلاعات لازم در زمان مناسب است. این جهت‌گیری را باید از مسابقه طولانی‌تر کردن ورودی جدا کرد؛ ورودی بیشتر لزوماً پاسخ بهتر نمی‌سازد.
برای شروع، مسیر یک درخواست واقعی را روی کاغذ رسم کنید. مشخص کنید کاربر چه می‌خواهد، چه داده‌ای معتبر است و چه چیزی هنوز معلوم نیست. سپس به هر قطعه اطلاعات، مالک، تاریخ به‌روزرسانی و سطح دسترسی بدهید. یک سند قیمت منقضی‌شده ممکن است از ده‌ها مثال خوب، زیان بیشتری ایجاد کند. پیش از خرید زیرساخت پیچیده، همین نظم اطلاعاتی می‌تواند بسیاری از ابهام‌های پروژه را آشکار کند.
۲. عامل‌ها به زیرساخت قابل بازیابی نیاز دارند
مقاله معماری Managed Agents در Anthropic در ۱۹ فروردین ۱۴۰۵، جداسازی جلسه، حلقه اجرای عامل و محیط اجرای ابزار را توضیح می‌دهد. این نمونه نشان می‌دهد بحث عامل‌ها فقط درباره قدرت مدل نیست؛ نگهداری وضعیت و مرزهای اجرا هم اهمیت دارند. این معماری مربوط به همان سرویس است و به معنای برتری تضمینی آن برای همه پروژه‌ها نیست.
در پروژه خود، یک آزمایش ساده تعریف کنید: اگر ارتباط وسط کار قطع شد، درخواست از کجا ادامه پیدا می‌کند؟ اگر کاربر دوباره دکمه ارسال را زد، عملیات مالی یا ثبت سفارش تکرار می‌شود؟ یک شناسه عملیات و وضعیت روشن، برای اعتماد کاربر ارزش بیشتری از اصطلاحات پیچیده دارد. بهتر است ابتدا کاری محدود مانند دسته‌بندی درخواست پشتیبانی را انتخاب کنید و اختیارات آن را فقط پس از بررسی رفتار واقعی گسترش دهید.
۳. چندوجهی بودن باید مسئله مشخصی را حل کند
ترکیب متن، صوت و تصویر زمانی مفید است که کاربر از قبل با این داده‌ها کار می‌کند. در مرکز تماس، شنیدن شماره سفارش و ادامه مکالمه اهمیت دارد؛ در بررسی یک سند، خواندن جدول و محل امضا مطرح است. پیشنهاد ما این است که پیش از انتخاب مدل، ورودی‌های خراب و ناقص را جمع‌آوری کنید: صدای محیط، عکس تار، صفحه چرخیده و متن با اعداد فارسی. کیفیت محصول معمولاً در همین مرزها روشن می‌شود.
رابط کاربری باید راه اصلاح داشته باشد. متن تشخیص‌داده‌شده را در موقعیت مناسب نشان دهید، امکان ویرایش بدهید و هنگام ابهام یک سؤال کوتاه بپرسید. برای داده حساس، مسیر حذف و مدت نگهداری را از ابتدا مشخص کنید. چنین تصمیم‌هایی بخشی از طراحی تجربه کاربر هستند؛ نمی‌توان آن‌ها را به روز انتشار موکول کرد و انتظار داشت فقط با افزودن یک جمله به دستور مدل حل شوند.
۴. روند مناسب را با یک آزمایش انتخاب کنید
برای هر ایده، برگه‌ای با چهار مورد بسازید: کار هدف، داده لازم، معیار موفقیت و هزینه شکست. مثلاً در پاسخ‌گویی سازمانی، کاهش ارجاع‌های غیرضروری تنها زمانی ارزش دارد که پاسخ‌ها همچنان درست و قابل پیگیری باشند. در توسعه اپلیکیشن، سرعت تولید کد باید همراه با قابلیت نگهداری سنجیده شود. اگر معیار روشن ندارید، هنوز زمان تصمیم قطعی درباره فناوری نرسیده است.
از نمونه کوچک تا تصمیم قابل دفاع
یک جریان محدود را با کاربران واقعی آزمایش کنید و نتیجه را با روش فعلی مقایسه کنید. هزینه اصلاح، زمان آموزش کارکنان و مواردی را که سامانه باید به انسان ارجاع دهد ثبت کنید. سپس تصمیم بگیرید کدام بخش ارزش گسترش دارد. برای تیم‌های کوچک، تمرکز روی یک مسئله پرتکرار معمولاً از ساختن هم‌زمان چند قابلیت پراکنده، تصویر روشن‌تری از ارزش محصول می‌دهد.
در نهایت، دنبال کردن روندها یعنی یادگیری و بازبینی انتخاب‌ها، نه تعویض دائمی ابزار. خروجی مناسب این بررسی یک فهرست کوتاه از آزمایش‌های قابل اجراست: سازمان‌دهی دانش، محدود کردن ابزارها، سنجش پاسخ‌ها و طراحی مسیر اصلاح. این چهار کار پایه‌ای کمک می‌کنند فناوری جدید با مسئله واقعی سازمان پیوند بخورد و برنامه توسعه به مجموعه‌ای از وعده‌های مبهم تبدیل نشود.
منابع و مطالعهٔ بیشتر
- Effective context engineering for AI agents
- Scaling Managed Agents: Decoupling the brain from the hands
بررسی منابع: ۲۱ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
