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

اگر امروز برای استقرار عامل‌های هوش مصنوعی بودجه می‌گیرید، احتمالاً روی هوشمندی مدل تمرکز کرده‌اید، اما هزینهٔ واقعی در جایی است که باید اشتباهات مدل را شکار کنید. طبق تحلیل فنی مفصلی که در ۲۱ سپتامبر ۲۰۲۶ در dev.to منتشر شد، گلوگاه واقعی در هوش مصنوعی سازمانی، سرعت تولید نیست، بلکه ظرفیت تأیید (Verification) است.

این تحلیل به عنوان بخش پایانی یک سری شش‌گانه عمل می‌کند. در حالی که بخش‌های قبلی معماری مرجع را به ترتیب مراحل — شامل هویت، درگاه‌ها، بازیابی داده‌ها، عامل‌های محیط ایزوله (Sandboxed Agents) و سخت‌سازی حاکمیت — بررسی کردند، این بخش نهایی معماری را از زاویه بودجه می‌بیند. هدف این است که به هشت سؤالی پاسخ دهد که مدیران در دنیای واقعی می‌پرسند، نه لیستی تئوریک از آنچه «باید» بپرسند.

بسیاری از شرکت‌ها پذیرش هوش مصنوعی را یک مسئلهٔ انتخاب فروشنده می‌بینند. اما در واقعیت، گران‌ترین بخش‌های یک پشتهٔ فناوری AI، درگاه (Gateway)، فایل سیاست‌ها و دفتر کل (Ledger) هستند؛ یعنی همان اجزایی که تصمیمات انباشته‌شده سازمانی در آن‌ها ذخیره می‌شود. وقتی این اجزا به جای توابع مستقل، حول یک فروشنده خاص ساخته شوند، شرکت یک وابستگی خطرناک ایجاد می‌کند. بلوک‌های موجود در نمودار معماری در واقع «کارکردها» هستند، نه «محصولات»؛ بنابراین ترتیب قرارگیری آن‌ها به این موضوع بستگی ندارد که چه مدلی در درون آن‌ها قرار گرفته است.

واقعیت حضور انسان در چرخه

هوش مصنوعی در گردش‌کارهای حساس، جایگزین انسان نمی‌شود، بلکه جایگاه انسان را تغییر می‌دهد. در یک پروژه آزمایشی که شامل سه اپیزود پایلوت و ۵۰ فیلم‌نامه (Beat Scripts) بود، تک‌تک فیلم‌نامه‌ها توسط مدل تولید شدند. از نظر فنی، سنتز نهایی می‌توانست در همان روزی که فیلم‌نامه‌ها تمام شدند اجرا شود. اما این اتفاق نیفتاد، زیرا دروازهٔ خروجی یک انسان بود که باید هر بخش را از نظر فیلم‌نامه، تصویر و ریتم بازبینی می‌کرد. در نهایت، همین فرآیند خواندن تبدیل به کل زمان‌بندی باقی‌مانده پروژه شد.

به محض اینکه تولید سریع شد، دیگر محدودکننده نبود. گلوگاه کاملاً به بازبین انسانی منتقل شد. در یک معماری تحت نظارت، تأیید انسانی به عنوان یک بلوک مجزا در مرحله ۴ ترسیم می‌شود که زیر کانکتورهای «نوشتن» (Write) و «ارسال» (Send) قرار دارد و فلشی به سمت آن‌ها می‌رود که روی آن نوشته شده: «ارسال و نوشتن نیاز به انسان دارد». هیچ چیزی در مرحله ۵ این الزام را حذف نمی‌کند.

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

حل مسئله نشت داده‌ها

امنیت داده‌ها نیازمند دو قانون سخت‌گیرانه است که باید پیش از هر معماری تعریف شوند: اول اینکه هر چه در چت چسبانده شد، «ارسال شده» تلقی شود (زیرا از دیدگاه شرکت، همین‌طور است) و دوم اینکه اعتبارنامه‌ها (Credentials) هرگز نباید در متن گفتگو جابه‌جا شوند. یک فایل اعتبارنامه می‌تواند توسط یک فرآیند خوانده شود، اما نباید در تاریخچه گفتگو چاپ شود.

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

• رابط‌های برنامه‌نویسی (API) مدل‌های ابری: باید خارج از مرز سازمان قرار گیرند.
• درگاه (Gateway): هر فلشی که به APIها می‌رسد باید ابتدا از درگاه عبور کند، جایی که باکس فیلتر اطلاعات شناسایی شخصی (PII) و جلوگیری از نشت داده (DLP) قرار دارد. هیچ مسیر دومی برای خروج وجود ندارد.
• محدودسازی نقش‌ها: مرحله ۲ نشت‌هایی را که به سمت داخل حرکت می‌کنند پوشش می‌دهد. ایندکس بازیابی با برچسب «محدود شده بر اساس نقش» (Scoped by Role) مشخص شده است تا اطمینان حاصل شود سؤالی که از بخش مارکتینگ پرسیده شده، نمی‌تواند رکوردهایی را برگرداند که فقط بخش پشتیبانی باید ببیند. این چالش‌های دسترسی در واقع بخشی از مسئله پیچیده‌تر مجوزدهی پراکنده در سیستم‌های عامل‌محور است که ریشه بسیاری از ریسک‌های امنیتی را تشکیل می‌دهد.

با اجرای این موارد، شرکت سؤال «نشت داده» را به یک سؤال «حسابرسی» تبدیل می‌کند که سپس توسط دفتر کل در مرحله ۵ پاسخ داده می‌شود.

هزینه پنهان «تکمیل‌های کاذب»

یکی از خطرناک‌ترین حالت‌های شکست، «تکمیل کاذب» (False Completion) است؛ جایی که یک عامل گزارش می‌دهد تسک انجام شده، در حالی که خروجی (Artifact) اصلاً وجود ندارد. این یک «پاسخ غلط» نیست، بلکه گزارشِ کاری است که هرگز اتفاق نیفتاده است. در یک تست کنترلی با ۲۰ اجرا روی یک مدل محلی کوچک، عاملی که فاقد دروازه تأیید بود، در ۱۸ مورد گزارش تکمیل داد در حالی که خروجی مفقود بود.

اضافه کردن یک «دروازه» (Gate) — مکانیزمی که وجود خروجی را خارج از محیط عامل بررسی می‌کند — این تکمیل‌های کاذب را حذف می‌کند. برای مقابله با این دست خطاها و توهمات مدل در محیط‌های سازمانی، استفاده از چارچوب‌هایی مانند PicNet می‌تواند به حذف توهمات در دستیارهای RAG کمک کند. در مجموعه بعدی شامل ۱۲۰ اجرای نمره‌گذاری شده روی چهار ترکیب مختلف از مدل و تسک، بازوی دارای دروازه در ۱۸، ۱۴، ۷ و ۲۰ مورد از ۲۰ مورد، خروجی‌های معتبر تولید کرد. تکمیل‌های کاذب در هر چهار مورد ناپدید شدند، هرچند توانایی واقعی در انجام تسک لزوماً بهبود نیافت (یک مدل همچنان فقط در ۷ مورد از ۲۰ مورد موفق بود).

با این حال، این دقت بهای پردازشی دارد. در یک مطالعه حذف (Ablation Study)، فعال کردن دروازه باعث شد توکن‌های ورودی به ۱.۶۶ برابر حالت کنترل برسد و زمان پاسخ‌دهی (p95 wall clock time) از ۸۷ ثانیه به ۱۶۹ ثانیه افزایش یابد. هر اجرای مسدود شده دوباره تکرار می‌شود و این تکرارها در انتهای توزیع زمانی قرار می‌گیرند.

اندازه‌گیری معیارهای درست

مدیران اغلب با میانگین هزینه‌ها یا زمان‌ها مواجه می‌شوند، اما نویسنده معتقد است میانگین آماری است که برای پنهان کردن نوسانات طراحی شده است. در یک تسک اصلاح کد روی یک مدل محلی دیگر، میانگین مصرف توکن تنها ۱۶٪ تغییر کرد، اما میانه (Median) از ۱۸,۶۱۲ به ۳۷,۰۶۸ توکن جهش کرد. یعنی وسط توزیع دو برابر شد، اما میانگین به سختی این تغییر را ثبت کرد.

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

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

استقرار استراتژیک و مالکیت

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

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

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

در مورد اجرا، نویسنده تفکیک بین مشاوران و تیم‌های داخلی را پیشنهاد می‌کند:

• خرید بازبینی طراحی: از متخصصان برای محدودسازی نقش‌ها (مرحله ۱) و مسیرهای تأیید (مرحله ۴) استفاده کنید. این‌ها قطعات محدودی از کار هستند که خروجی آن‌ها در اختیار شرکت می‌ماند.
• مالکیت قوانین: فایل سیاست‌های مرحله ۵ باید توسط افرادی نوشته شود که قانون بر آن‌ها اعمال می‌شود. قوانینی که توسط مشاورانی نوشته شود که سپس سازمان را ترک می‌کنند، به‌ندرت دنبال می‌شوند. نویسنده مثالی شخصی می‌زند از قانونی که نوشته بود و بیست روز صرف توصیف سیستمی کرد که دیگر وجود نداشت، چون هیچ‌کس به یاد نمی‌آورد برای چه بوده است. این اهمیت مالکیت داخلی در زمان‌های بحرانی یا تغییرات ساختاری بیشتر می‌شود؛ برای مثال، برنامه‌ریزی برای بازیابی پس از انحلال تیم‌های AI نشان می‌دهد که داشتن مستندات و قوانینی که توسط تیم داخلی درک شده باشد، چقدر در بقای پروژه حیاتی است.

گلوگاه توزیع

حتی وقتی زمان تولید به نزدیک صفر برسد، اثر کلی بر کسب‌وکار توسط «کانال توزیع» محدود می‌شود. خروجی همان روز می‌رسد، اما اثر آن طبق زمان‌بندی کانال توزیع ظاهر می‌شود. برای اکثر سازمان‌ها، کانال توزیع محدودکننده است، نه محتوا.

به عنوان مثال، پستی که بخش صفر این سری را معرفی می‌کرد، حدود ۲۲ ساعت پس از انتشار، ۱۴۸ بازدید و ۷ لایک داشت. اولین پست در پلتفرمی دیگر تنها ۳ بازدید گرفت. در حالی که نوشتن این‌ها اکنون کسری از زمان قبلی را می‌گیرد، اما اعداد مربوط به دسترسی (Reach) تغییر نکردند.

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

خلاصه معماری

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

چهار سؤال توسط اجزای خاص پاسخ داده می‌شوند: باکس تأیید، خط مرزی و ایندکس محدود شده، ردیف معیارها و دروازه (Gate). چهار سؤال دیگر بر عهده قضاوت‌ها باقی می‌مانند. برای کسانی که قصد اجرا دارند، یک صفحه کنترل متن‌باز برای بخش تحت نظارت سیستم در aine-control-plane ارائه شده است.

گام بعدی شما

• بودجه‌های AI خود را از «هزینه توکن» به «هزینه ساعتِ بازبین انسانی» تغییر دهید.
• برای اولین پروژه، بخشی را انتخاب کنید که تست‌های خودکار دارد (مثل مهندسی) تا گلوگاه تأیید را به حداقل برسانید.
• قوانین حاکمیتی را به جای مشاوران، از کاربران نهایی بخواهید بنویسند تا قابلیت اجرا داشته باشند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.