تبدیل توانمندیهای خیرهکننده هوش مصنوعی به برنامههای نرمافزاری پایدار چالشهای جدید و تازهای را بهوجود میآورد، اما کلیدهای غلبه بر آنها اساسی و کسلکنندهاند.
دنبالکنندگان معمول هوش مصنوعی را در X دنبال کنید—آندرو انگ، پیج بیلی، دمیس هسابیس، تام وولف، سانتیاگو والداراما و غیره—و شروع به کشف الگوهایی در چالشهای نوظهور هوش مصنوعی و چگونگی حل آنها توسط توسعهدهندگان میکنید. در حال حاضر، این افراد برجسته حداقل دو نیروی مواجههگر با توسعهدهندگان را نشان میدهند: دستاوردهای شگفتانگیز توانمندی که با مشکلات نرمافزاری بسیار آشنا (و سرسخت) همراه است. مدلها مرتباً هوشمندتر میشوند؛ برنامهها در همان نقاط خراب میشوند. فاصله بین دموی اولیه و محصول پایدار همچنان محلی است که بیشتر مهندسی در آن رخ میدهد.
تیمهای توسعه چگونه از این بنبست عبور میکنند؟ با بازگشت به اصول پایه.
اشیا (عاملها) از هم میپاشند
آندرو انگ بر روی نکتهای تأکید کرده است که بسیاری از سازندگان از طریق تجربه سختآلود یاد گرفتهاند: « وقتی عوامل دادهای شکست میخورند، اغلب بهصورت بیصدا شکست میخورند — پاسخهای با اطمینان که در واقع اشتباه هستند را میدهند و کشف علت شکست میتواند دشوار باشد.» او بر ارزیابی سیستماتیک و قابلیت مشاهده برای هر گامی که یک عامل برمیدارد تأکید میکند، نه فقط دقت انتها به انتها. ممکن است واژه «کدنویسی احساس» را دوست داشته باشیم، اما توسعهدهندگان هوشمند بهشدت بهکارگیری تستهای واحد، ردگیریها و بررسیهای سلامت برای برنامههای عامل، ابزارها و حافظه را تحمیل میکنند.
به عبارت دیگر، آنها عاملها را شبیه به سیستمهای توزیعشده رفتار میدهند. هر مرحله را با OpenTelemetry ابزار میکنید، مجموعههای دادهٔ «طلایی» کوچک برای ارزیابیهای قابل تکرار نگه میدارید و رگرسیونها را روی برنامهها و ابزارها همانطور که برای APIها انجام میدهید، اجرا میکنید. این موضوع زمانی بحرانی میشود که ما فراتر از برنامههای ساده حرکت کنیم و شروع به معماریسازی سامانههای عاملکننده کنیم، جایی که اندرو انگ اشاره میکند که خود عاملها برای نوشتن و اجرای تستها استفاده میشوند تا دیگر عاملها صادق بمانند. این یک متا است، اما وقتی چارچوب تست مانند نرمافزار واقعی رفتار میکند — نسخهبندیشده، بازبینیشده و اندازهگیریشده — مؤثر است.
سانتیاگو والداراما همان هشدار را بازتاب میدهد، گاهی اوقات پیشنهاد یک گام بزرگ به عقب میکند. راهنمایی او بهنوعی خوشطبعانه غیرپرتزویی است: از وسوسهٔ تبدیل همه چیز به یک عامل خودداری کنید. اگرچه «واقعاً وسوسهانگیز است که بدون دلیل پیچیدگی اضافه کنیم»، دور زدن این وسوسه سودمند است. اگر یک تابع ساده کافی است، از یک تابع ساده استفاده کنید چون همانطور که او میگوید «توابع عادی تقریباً همیشه برندهاند».
داده را اصلاح کنید، نه فقط مدل
قبل از اینکه حتی بهبهبود مدل خود فکر کنید، باید بازیابی را اصلاح کنید. همانطور که انگ پیشنهاد میکند، اکثر «پاسخهای بد» از سیستمهای RAG (تولید افزایشی بازیابی) خودساخته هستند — نتیجهٔ تقسیمبندی ناپخته، فقدان متادیتا یا پایگاه دانش نامنظم. این یک مشکل مدل نیست؛ یک مشکل داده است.
تیمهایی که موفق میشوند دانش را مانند یک محصول میدانند. آنها کورپوسهای ساختاریافته میسازند و گاهی از عاملها برای استخراج موجودیتها و روابط به یک گراف سبک استفاده میکنند. سیستمهای RAG خود را مانند یک موتور جستجو ارزیابی میکنند: بر اساس تازگی، پوشش و نرخ موفقیت در برابر یک مجموعهٔ طلایی از سوالات. تقسیمبندی تنها یک پیشفرض کتابخانهای نیست؛ یک رابط است که باید با سلسلهمراتبهای نامگذاریشده، عناوین و شناسههای پایدار طراحی شود.
و فراموش نکنید JSON. تیمها بهطور فزایندهای از «متن آزاد و دعا کردن» به درخواستهای مبتنی بر طرحواره با اعتبارسنجهای سخت در مرز حرکت میکنند. این کار کسلکننده بهنظر میرسد تا وقتی که تجزیهکنندههایتان دیگر خراب نمیشوند و ابزارهایتان دیگر اشتباه نمیکنند. خروجی محدود LLMها را تبدیل میکند از کارآموزان پرحرف به خدماتی که میتوانند بهصورت ایمن دیگر خدمات را فراخوانی کنند.
کاپیپایلوتهای برنامهنویسی را بر ریلهای ایمنی قرار دهید
آخرین تلاش OpenAI در مورد GPT-5-Codex کمتر «تکمیل خودکار» است و بیشتر به مسألهٔ «رباتهای هوش مصنوعی» اشاره دارد که مخزن شما را میخوانند، خطاها را نشان میدهند و یک درخواست ادغام (pull request) باز میکنند، همانطور که همبنیانگذار OpenAI، گرگ براکمن، پیشنهاد میکند. در همین زمینه، او مرور خودکار کد را در خط فرمان Codex برجسته کرده است، با اجرای موفق حتی زمانی که به مخزن «غلط» اشاره میشد (راه خود را پیدا کرد)، و در دسترس بودن عمومی GPT-5-Codex در Responses API. این یک سطح جدید از توانمندی آگاهی از مخزن است.
همانطور که والداراما میگوید، « اجازه دادن به هوش مصنوعی برای نوشتن تمام کد من، مانند پرداخت به یک ساملیر برای نوشیدن تمام شراب من است.» بهعبارت دیگر، از ماشین برای تسریع کدی استفاده کنید که مایل به مالکیت آن هستید؛ قضاوت را برونسپاری نکنید. در عمل، این به این معناست که توسعهدهندگان باید حلقهٔ بین تغییرات پیشنهادی هوش مصنوعی و CI خود را محکمتر کنند (ادغام مستمر) و تستها را بر روی هر تغییر تولید شده توسط هوش مصنوعی اعمال کنند و ترکیبها را در ساختهای قرمز مسدود کنند (چیزی که بهتازگی نوشتم).
تمام این موارد یادآوری دیگری است که ما هنوز به حالت خودکار در استفاده از genAI نرسیدهایم. برای مثال، DeepMind گوگل با Gemini ۲.۵ Deep Think نشاندهندهٔ «تفکر» قویتر و بلندمدت شده است. این برای توسعهدهندگانی که نیاز دارند مدلها بدون نظارت مداوم، منطق چندمرحلهای را زنجیرهبندی کنند، مهم است. اما این شکاف قابلیت اطمینان بین یک جدول ردهبندی و هدف سطح سرویس زمان بالا بودن را از بین نمیبرد.
تمام این مشاورهها برای کد مفید هستند، اما معادلهٔ بودجهای نیز وجود دارد، همانطور که توماس تونگوز استدلال میکند. بهراحتی فراموش میشود، اما متر همیشه در حال اندازهگیری تماسهای API با مدلهای پیشرفته است و ویژگیای که در دموی اولیه درخشان بهنظر میرسد میتواند در مقیاس بزرگ به یک سیاهچالهٔ مالی تبدیل شود. در همان زمان، برنامههای حساس به تأخیر نمیتوانند برای یک مدل کند و گرانقیمت مانند GPT‑۴ صبر کنند تا یک پاسخ ساده تولید کند.
این موضوع منجر به پیدایش یک نوع جدید از مهندسی هوش مصنوعی متمرکز بر بهینهسازی هزینه‑ عملکرد شد. هوشمندترین تیمها این را بهعنوان یک نگرانی معماری درجه یک، نه پسنگری، میپذیرند. آنها مسیریابهای هوشمند یا «سلسلهمراتب مدلها» میسازند که پرسشهای ساده را به مدلهای ارزانتر و سریعتر (مانند Haiku یا Gemini Flash) میفرستند و مدلهای پرهزینه و پرقدرت را برای وظایف استدلال پیچیده محفوظ میدارند. این رویکرد نیاز به طبقهبندی قوی هدف کاربر در ابتدا دارد — یک مسئلهٔ مهندسی کلاسیک که اکنون بر روی ارکستراسیون LLM اعمال میشود. علاوه بر این، تیمها فراتر از Redis ساده برای ذخیرهسازی موقت رفتهاند. مرز جدید ذخیرهسازی معنایی است، جایی که سامانهها معنای پاسخ یک پرسش را نه فقط متن دقیق، ذخیره میکنند، به طوری که میتوانند یک نتیجهٔ کششده را برای پرسشهای آیندهٔ معنایی مشابه ارائه دهند. این تبدیل بهینهسازی هزینه را به یک عمل اصلی و انضباطی میکند.
یک سیاهچالهٔ فوقالعاده بزرگ: امنیت
و سپس امنیت وجود دارد که در عصر هوش مصنوعی مولد به بُعدی جدید و سورئال دست یافته است. همان ریلهای ایمنی که بر کد تولید شده توسط هوش مصنوعی اعمال میکنیم باید بر ورودی کاربر نیز اعمال شوند، زیرا هر پرسشی باید بهعنوان ممکن است خصمانه رفتار شود.
ما فقط دربارهٔ آسیبپذیریهای سنتی صحبت نمیکنیم. ما دربارهٔ تزریق پرامپت صحبت میکنیم، جایی که یک کاربر مخرب یک LLM را فریب میدهد تا دستورالعملهایش را نادیده بگیرد و دستورات مخفی را اجرا کند. این یک خطر نظری نیست؛ در واقع در دنیای واقعی رخ میدهد و توسعهدهندگان اکنون با فهرست ۱۰ برتر OWASP برای برنامههای مدلهای زبانی بزرگ روبرو هستند.
راهحلها ترکیبی از بهداشت امنیتی قدیمی و جدید هستند. این به معنای ایزولهسازی دقیق ابزارهایی است که یک عامل میتواند استفاده کند، اطمینان از حداقل امتیاز. این به معنای پیادهسازی اعتبارسنجی خروجی سختگیرانه و، مهمتر از آن، اعتبارسنجی نیت قبل از اجرای هر دستوری که توسط LLM تولید شده است. این دیگر فقط دربارهٔ تمیز کردن رشتهها نیست؛ بلکه دربارهٔ ساختن یک حاشیهحفاظ اطراف قدرت اما بهطرز خطرناکی نرمپذیر استدلال مدل است.
استانداردسازی در راه؟
یکی از موفقیتهای کمصدا در سال گذشته، پیشرفت مستمر «پروتکل زمینهٔ مدل» (Model Context Protocol) و دیگران به سمت تبدیل شدن به روشی استاندارد برای ارائه ابزارها و دادهها به مدلها بوده است. MCP جذاب نیست، اما این همان چیزی است که آن را بسیار مفید میکند. این پروتکل رابطهای مشترکی با کدهای اتصال کمتر وعده میدهد. در صنعتی که همه چیز روزانه تغییر میکند، این واقعیت که MCP بیش از یک سال بدون جایگزینی باقی مانده است یک دستاورد آرام است.
این همچنین فرصتی برای رسمیکردن دسترسی حداقل‑امتیاز برای هوش مصنوعی فراهم میکند. ابزارهای یک عامل را مانند APIهای تولیدی رفتار کنید: به آنها حوزهها، کوتاها و لاگهای نظارتی بدهید و برای اقدامات حساس تأییدهای صریح طلب کنید. قراردادهای ابزارهای سفتوسخت را تعریف کنید و گواهینامهها را همانطور که برای هر حساب سرویس دیگر میچرخانید، چرخاندن کنید. این یک انضباط قدیمی برای مشکلی جدید است.
در واقع، این عملیگرایی ساکت این روشهای برتر نوظهور است که به روند کلی بزرگتری اشاره میکند. چه دربارهٔ تست عاملها، مسیردهی مدل، اعتبارسنجی پرامپت یا استانداردسازی ابزار صحبت کنیم، تم پایهای یکسان است: صنعت هوش مصنوعی سرانجام به کار جدی، اغلب غیرپرتزویی تبدیل تواناییهای خیرهکننده به نرمافزار پایدار میپردازد. این حرفهسازی بزرگ یک رشتهٔ پیش از قبل تخصصی است.
دور چرخهٔ هیجانزدگی بهدنبال پنجرههای زمینهای بزرگتر و مهارتهای استدلال نوین خواهد گشت و این خوب است؛ این علم است. اما ارزش واقعی تجاری توسط تیمهایی که درسهای سختکسبشدهٔ دههها مهندسی نرمافزار را اعمال میکنند، باز میشود. آنها داده را مانند یک محصول، APIها را مانند یک قرارداد، امنیت را مانند یک پیشنیاز و بودجهها را مانند چیزهای واقعی میدانند. آیندهٔ ساختن با هوش مصنوعی، همانطور که میدانیم، کمتر شبیه به یک نمایش جادویی و بیشتر شبیه به یک پروژهٔ نرمافزاری بهخوبی ادارهشده است. و اینجایی است که پول واقعی وجود دارد.
پست های مرتبط
غلبه بر چالشهای توسعه هوش مصنوعی