همه در حال ساخت عاملهای هوش مصنوعی هستند. اما هیچکس درباره بدهی فنی صحبت نمیکند.
اکثر توسعهدهندگان با مفهوم بدهی فنی (technical debt) آشنا هستند. بدهی فنی همان میانبری است که امروز میزنید و فردا مشکلساز میشود. معمولاً این بدهی در کد شما نهفته است و خود را به شکل منطقهای پیچیده و نامنظم یا کتابخانههای قدیمی نشان میدهد.
عاملهای هوش مصنوعی (AI agents) این قاعده را تغییر میدهند.
عاملها نوع جدیدی از بدهی ایجاد میکنند. این بدهی فقط در کد شما نیست؛ بلکه در پرامپتها (prompts)، لایههای حافظه و ادغام ابزارها (tool integrations) نهفته است. این بدهی بهصورت بیصدا رشد میکند.
در اینجا چهار نوع از «بدهی عاملی» (agentic debt) که باید مراقب آنها باشید، آورده شده است:
۱. بدهی پرامپت (Prompt Debt) یک پرامپت سادهی دوخطی اغلب به یک بیانیهی ۳۰۰ خطی تبدیل میشود. توسعهدهندگان برای رفع خطاهای جزئی، دستورالعملهای جدیدی اضافه میکنند. طولی نمیکشد که دیگر هیچکس نمیداند چرا کلمات خاصی در آنجا قرار دارند. اگر از تغییر دادن یک پرامپت میترسید، یعنی دچار بدهی پرامپت شدهاید. این مسئله هزینهها را افزایش و سرعت سیستم شما را کاهش میدهد.
۲. بدهی بافتار (Context Debt) تیمها اغلب تصور میکنند دادهی بیشتر به معنای نتیجهی بهتر است. آنها کل پایگاههای داده و فایلهای PDF را در پنجرهی بافتار (context window) میریزند. این یک اشتباه است. حجم بالای دادههای بیربط (noise) باعث توهم (hallucination) و تأخیر (latency) بالا میشود. سیستمهای هوشمند به جای صرفاً بلعیدن دادهها، آنها را فیلتر میکنند.
۳. بدهی ارزیابی (Evaluation Debt) کدهای سنتی تستهای مشخصی دارند؛ شما X را وارد میکنید و انتظار Y را دارید. اما عاملها متفاوت هستند. آنها احتمالی (probabilistic) عمل میکنند و ممکن است به یک سوال یکسان، پاسخهای متفاوتی بدهند. اگر عاملها را بدون خط لولههای ارزیابی خودکار (automated evaluation pipelines) عرضه کنید، در واقع دارید در تاریکی حرکت میکنید.
۴. بدهی ابزار (Tool Debt) دادن دسترسی به تمام APIهای شرکت به یک عامل، خطرناک است. این کار ریسکهای امنیتی و شکستهای پیچیده ایجاد میکند. اگر یک عامل ۲۵ ابزار داشته باشد اما فقط از پنج تای آنها استفاده کند، آن ۲۰ ابزار دیگر صرفاً بدهی هستند.
چگونه این مشکل را حل کنیم:
- با پرامپتها مانند کد رفتار کنید. از کنترل نسخه (version control) و بازبینی همتا (peer review) استفاده کنید.
- بافتار خود را مدیریت کنید. فقط دادهها را به درون سیستم نریزید. از رنکرها (rerankers) برای تمیز نگه داشتن اطلاعات استفاده کنید.
- ابتدا سیستمهای ارزیابی را بسازید. قبل از اضافه کردن ویژگیهای جدید، مجموعهدادههای تست (test datasets) ایجاد کنید.
- از اصل «حداقل دسترسی» استفاده کنید. به عاملها فقط ابزارهایی را بدهید که برای عملکردشان نیاز دارند.
تیمهایی که پیروز میشوند، فقط بهترین دموها را نمیسازند؛ آنها سیستمهایی میسازند که پایدار و قابل نگهداری باقی میمانند.
Optional learning community: https://t.me/GyaanSetuAi
