۹۰٪ آژانس‌های هوش مصنوعی صرفاً پوسته‌ای برای مهندسی پرامپت هستند

اگر امروز برای پیاده‌سازی یک مدل یادگیری ماشین سفارشی هزینه می‌کنید، احتمالاً دارید پول یک مهندس ارشد را می‌دهید تا برایتان چند خط پرامپت بنویسد. طبق گزارش 2pizza.team، ۹۰ درصد پیشنهاداتی که مدیران در سال ۲۰۲۶ برای یادگیری ماشین سفارشی دریافت می‌کنند، در واقع فقط فراخوانی‌های API مدل‌های Claude یا GPT هستند که در یک گردش‌کار n8n پیچیده شده‌اند. این رقم تکان‌دهنده نشان‌دهنده شکافی رو به گسترش میان ادعاهای بازاریابی و تحویل فنی است. در واقع، بسیاری از کسب‌وکارها نرخ‌های مربوط به ML سفارشی را برای چیزی می‌پردازند که در اصل «مهندسی پرامپت همراه با یک فاکتور» است. اگرچه این کار یک فعالیت مهندسی مشروع است، اما هرگز نباید به عنوان «یادگیری ماشین سفارشی» فروخته یا قیمت‌گذاری شود. این تفاوت بنیادین میان استفاده از ابزارهای آماده و درک عمیق معماری مدل‌هاست که در تحلیل ما درباره تفاوت مصرف API و تسلط بر ترنسفورمرها به تفصیل بررسی شده است.

این وضعیت در حالی رخ می‌دهد که سازمان‌ها از هیجانات اولیه هوش مصنوعی زاینده (Generative AI) عبور کرده‌اند و حالا به دنبال بهبودهای قابل اندازه‌گیری در اقتصاد واحد (Unit Economics) هستند. ساخت یک سیستم تولید بازیابی‌افزا (RAG) روی اسناد، زنجیره کردن فراخوانی‌های LLM در یک گردش‌کار، یا پرامپت دادن به یک مدل بنیادی برای نوشتن با لحنی خاص، مهندسی ارزشمندی است، اما یادگیری ماشین سفارشی نیست. وقتی یک آژانس این گردش‌کارها را به عنوان یادگیری ماشین معرفی می‌کند، این اولین سیگنال شماست تا بفهمید آن‌ها در نهایت چه چیزی تحویل خواهند داد.

یادگیری ماشین واقعی یعنی آموزش مدل‌ها از روی داده‌ها و مالکیت کامل زیرساخت استقرار برای حل یک مسئله تجاری خاص. این راهنما نسخه صادقانه‌ای از نحوه ارزیابی یک آژانس مهندسی یادگیری ماشین در سال ۲۰۲۶ ارائه می‌دهد؛ اینکه در اولین تماس چه بپرسید، به کدام ادعاها اعتماد کنید و چگونه قرارداد را ساختاردهی کنید تا ریسک روی دوش آژانس باشد، نه شما.

تعریف یادگیری ماشین سفارشی واقعی

بر اساس گزارش منتشر شده توسط 2pizza.team، یادگیری ماشین سفارشی واقعی که واقعاً اقتصاد واحد یک کسب‌وکار را تغییر می‌دهد، تنها در سه شکل ظاهر می‌شود:

• مدل‌های آموزش‌دیده سفارشی روی داده‌های اختصاصی: این مدل‌ها برای وظایف پیش‌بینی با ریسک بالا استفاده می‌شوند؛ مواردی مانند پیش‌بینی ریزش مشتری (Churn Prediction)، امتیازدهی ریسک (Risk Scoring)، پیش‌بینی تقاضا و سیستم‌های توصیه (Recommendation Systems). در برخی صنایع حساس، استفاده از مدل‌های زبانی کوچک (SLM) به دلیل هزینه کمتر و کارایی بالاتر در عملیات مالی جایگزین مدل‌های غول‌پیکر شده است.
• تنظیم دقیق مدل‌های بنیادی (Fine-tuned Foundation Models): این مورد تنها زمانی کاربرد دارد که تنظیم دقیق، یک بهبود قابل اندازه‌گیری و کمی نسبت به مهندسی پرامپت استاندارد ایجاد کند.
• معماری‌های تخصصی: این معماری‌ها برای مسائلی مورد نیاز هستند که مدل‌های چندمنظوره در آن‌ها شکست می‌خورند؛ مانند تحلیل سری‌های زمانی با فصلی‌های پیچیده یا وظایف چندوجهی (Multi-modal) در دامنه‌های تخصصی.

فیلتر چهار سوالی

برای جداسازی آژانس‌های آماده برای محیط تولید (Production-ready) از شرکت‌های برندینگ، مدیران باید در اولین تماس چهار سؤال تشخیصی خاص بپرسند. این سؤالات کسانی را که ML واقعی تحویل می‌دهند از کسانی که آن را فقط به عنوان یک برند می‌فروشند، جدا می‌کند.

سؤال ۱: آیا می‌توانم مدل‌هایی را که از صفر آموزش داده‌اید ببینم؟
دموها را قبول نکنید. درخواست کنید تا نمونه‌هایی از نمونه‌های مستقر در محیط تولید (Production Instances) را ببینید که در آن آژانس مالک فرآیند آموزش باشد. اگر پاسخ آن‌ها یک ادغام API مدل بنیادی باشد که در یک داشبورد شیک پیچیده شده است، آن‌ها مدل سفارشی آموزش نمی‌دهند. این برای بسیاری از کاربردها مناسب است، اما شما نباید برای آن نرخ‌های ML سفارشی بپردازید.

سؤال ۲: ممیزی داده‌ها (Data Audit) را چگونه مدیریت می‌کنید؟
هر آژانسی که بدون دیدن داده‌ها قیمت مدل را اعلام کند، یا کورکورانه پیش می‌رود یا تصمیم گرفته که داده‌های خاص شما اهمیتی ندارند. هر دو مورد زنگ خطر هستند. یک شرکت حرفه‌ای فاز اولی را اجرا می‌کند که شامل موارد زیر است:

• ترسیم نقشه شمای داده‌های شما (Mapping Schema)
• بررسی در دسترس بودن ویژگی‌ها (Feature Availability)
• تأیید تعاریف متغیر هدف (Target Variable)
• بررسی عدم توازن کلاس‌ها (Class Imbalance)
• اعتبارسنجی صحت پنجره‌های زمانی برای جلوگیری از نشت داده‌های آینده (Future-data Leakage)

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

سؤال ۳: متدولوژی ارزیابی آفلاین شما چیست؟
آژانس چگونه ثابت می‌کند مدل قبل از ورود به محیط تولید کار می‌کند؟ پاسخ درست باید شامل اعتبارسنجی متقابل آگاه از زمان (Time-aware Cross-validation)، پنجره‌های کنار گذاشته شده (Held-out Windows)، بررسی‌های کالیبراسیون و یک مجموعه داده ارزیابی واقعی باشد که توزیع محیط تولید را منعکس کند.

پاسخ غلط، یک تقسیم ساده آموزش-تست (Train-test split) بدون در نظر گرفتن زمان، یا ادعای این است که مدل را در محیط تولید اعتبارسنجی می‌کنند. اعتبارسنجی متقابل آگاه از زمان حیاتی است، زیرا تقسیمات تصادفی باعث نشت اطلاعات آینده می‌شوند و مدل‌هایی می‌سازند که در حالت آفلاین درخشان به نظر می‌رسند اما بلافاصله در محیط تولید سقوط می‌کنند.

سؤال ۴: چه زمانی به من می‌گویید که مدل سفارشی نسازم؟
این سؤال تشخیصی است. آژانسی که بدون توجه به مسئله، همیشه ML سفارشی می‌فروشد، در این سؤال شکست می‌خورد. یک آژانس قابل اعتماد، ML سفارشی را یکی از چندین ابزار می‌بیند و موارد خاصی را نام می‌برد که در آن‌ها شما را به مسیر دیگری هدایت می‌کند؛ مثلاً زمانی که APIهای آماده نیاز شما را پوشش می‌دهند، حجم داده‌های شما بسیار کم است، یا RAG مسئله را ارزان‌تر حل می‌کند. اگر نتوانند مواردی را نام ببرند که در آن پاسخشان «نه» است، به کارهایی بله می‌گویند که در نهایت شکست می‌خورند.

شناسایی نشانه‌های خطر (Red Flags)

مدیران باید نسبت به آژانس‌هایی که در اسلایدهای ارائه (Pitch Decks) خود به جای نمونه‌های مدل‌های اجرا شده، فقط از طرح‌های گرافیکی (Mockups) یا محصولات «به‌زودی» استفاده می‌کنند، محتاط باشند. سایر نشانه‌های هشداردهنده عبارتند از:

• راهکارهای تک‌ابزاری: هر مسئله با یک ابزار یکسان پاسخ داده می‌شود؛ همیشه تنظیم دقیق، همیشه RAG یا همیشه یک چت‌بات.
• کمبود استعداد ML: تیم هیچ مهندس ML واقعی ندارد و فقط از مهندسان پرامپت یا توسعه‌دهندگان Full-stack استفاده می‌کند که کلمه «AI» را به پروفایل لینکدین خود اضافه کرده‌اند.
• قیمت‌گذاری مبهم: قیمت‌گذاری به جای اینکه بر اساس محدوده پروژه (Scoped) باشد، بر اساس توکن است. این نشان می‌دهد آژانس یک بازفروشنده (Reseller) است، نه یک سازنده.
• جهل در مورد کالیبراسیون: آژانس نمی‌تواند توضیح دهد اگر مدل بدکالیبره (Miscalibrated) شود چه اتفاقی می‌افتد. اگر کالیبراسیون را نمی‌فهمند، هرگز تصمیمات امتیازدهی شده (Scored Decisions) را در محیط تولید مستقر نکرده‌اند.
• مطالعات موردی مبهم: در Case Studyها ذکر نشده که چه چیزی آموزش داده شده، از چه داده‌هایی استفاده شده یا معیار ارزیابی (Evaluation Metric) دقیقاً چه بوده است.
• وعده‌های زودهنگام: قبل از دیدن داده‌های شما، عدد دقیقی برای دقت (Accuracy) مدل وعده می‌دهند.
• به‌کارگیری غلط تکنولوژی: برای مسائلی که RAG به وضوح بهتر و ارزان‌تر حل می‌کند، تنظیم دقیق (Fine-tuning) پیشنهاد می‌دهند.

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

امضای یک قرارداد تک‌مرحله‌ای با قیمت ثابت برای کل ساخت، تمام ریسک را به مشتری منتقل می‌کند. اگر در هفته سوم مشخص شود داده‌ها غیرقابل استفاده هستند، شما هزینه پنج هفته ساخت را پرداخت کرده‌اید و آژانس انگیزه دارد پروژه را به هر قیمتی پیش ببرد تا متوقف نشود. ساختار درست، دو فاز با یک خروجی صریح برای توقف است.

فاز اول: ممیزی (The Audit)
این فاز دو تا چهار هفته و با قیمت ثابت اجرا می‌شود. تمرکز بر ممیزی داده‌ها، بررسی در دسترس بودن ویژگی‌ها و ساخت آداپتور در صورت نیاز است. در پایان فاز اول، یکی از سه نتیجه زیر رخ می‌دهد:
۱. داده‌ها آماده‌اند و ساخت مدل ارزشمند است $ \rightarrow $ رفتن به فاز دوم.
۲. داده‌ها دارای نقص‌هایی هستند که باید اصلاح شوند $ \rightarrow $ اصلاح داده‌ها با خروجی‌های مشخص.
۳. مسئله توجیه‌کننده ML سفارشی نیست $ \rightarrow $ توقف پروژه و پرداخت هزینه فقط برای فاز اول.

فاز دوم: ساخت (The Build)
با فرض اینکه فاز اول ساخت را تأیید کند، فاز دوم شامل آموزش مدل، ارزیابی آفلاین، کالیبراسیون و استقرار در محیط Staging است.

نکته حیاتی، اجرای مدل در «حالت سایه» (Shadow-mode) است. در حالت سایه، مدل روی داده‌های زنده اجرا شده و امتیاز تولید می‌کند، اما هیچ اقدام پایین‌دستی (Downstream Action) صورت نمی‌گیرد. این کار دو تا چهار هفته شواهد تولیدی فراهم می‌کند که ثابت کند رکوردهای علامت‌گذاری شده توسط مدل، واقعاً همان‌طور که پیش‌بینی شده رفتار می‌کنند، پیش از آنکه بودجه‌ای برای کمپین‌ها بر اساس این امتیازها هزینه شود.

تحویل و قیمت‌گذاری

تحویل (Handover) یک نقطه شکست بحرانی است. مدلی که فقط آژانس بتواند آن را بازآموزی کند، یک تله برای وابستگی (Lock-in) است. مشتریان باید بر مستنداتی تأکید کنند که شامل موارد زیر باشد:

• خط لوله مهندسی ویژگی (Feature Engineering Pipeline)
• شمای داده‌های آموزشی (Training Data Schema)
• فرمت آرتیفکت مدل (Model Artefact Format)
• رویه کالیبراسیون (Calibration Procedure)
• دفترچه راهنمای بازآموزی (Retraining Runbook)

اگر آژانس تحویل را به عنوان یک موضوع ثانویه می‌بیند، قصد دارد به وابستگی دائمی شما تبدیل شود.

قیمت‌گذاری در سال ۲۰۲۶ بسته به پیچیدگی متفاوت است. یک مدل امتیازدهی محدود روی داده‌های تمیز ممکن است در محدوده پایین پنج رقمی (دلار) باشد. یک سیستم حفظ مشتری (Retention) یا پیش‌بینی با تلاش‌های واقعی در مهندسی داده، در محدوده متوسط پنج رقمی است. سیستم‌های چندمدلی با معماری‌های سفارشی و زیرساخت تولید، قیمت‌های بالاتری دارند.

قیمت‌ها باید بر اساس پروژه و گره خورده به خروجی‌ها (Deliverables) باشند، نه معیارهای کیفی. آژانسی که دقت ۹۰٪ را با قیمت ثابت وعده می‌دهد، یا زمینه مسئله را نمی‌فهمد یا قصد دارد با پیش‌بینی کلاس اکثریت یا گلچین کردن مجموعه ارزیابی به آن عدد برسد. قراردادهای ماهانه (Retainers) برای بازآموزی، نظارت بر رانش داده‌ها (Drift Monitoring) و مهندسی ویژگی مشروع هستند اما باید جدا از ساخت اولیه قیمت‌گذاری شوند.

ترکیب تیمی مورد انتظار

یک پروژه ML سفارشی واقعی حداقل به یک مهندس ML، یک مهندس Backend یا زیرساخت و یک مدیر محصول مسلط به دامنه (Domain-savvy) نیاز دارد تا بین نیازهای تجاری و کارهای فنی ترجمه کند.

عامل تعیین‌کننده این است که مهندس ML فقط یک مهندس پرامپت نباشد. درباره سوابق آن‌ها در PyTorch یا TensorFlow، تجربه آن‌ها در استفاده از Gradient Boosting در محیط تولید و متدولوژی دقیق ارزیابی آفلاین آن‌ها سؤال کنید.

چه زمانی از ML سفارشی اجتناب کنیم

صرفه‌جویی در هزینه اغلب به معنای اجتناب کامل از ML سفارشی است. APIهای آماده از Anthropic، OpenAI و ارائه‌دهندگان مدل‌های باز-وزن (Open-weight)، درصد زیادی از نیازها را پوشش می‌دهند. RAG معمولاً برای تزریق دانش دامنه بهتر از تنظیم دقیق (Fine-tuning) عمل می‌کند و سیستم‌های مبتنی بر قانون (Rules-based) برای تصمیمات پایدار که ردپای حسابرسی (Audit Trail) در آن‌ها یک الزام قانونی است، برتر هستند.

آژانسی که بتواند تشخیص دهد مشکل شما یک مسئله ML سفارشی نیست و شما را به درستی راهنمایی کند، در بلندمدت بسیار ارزشمندتر از آژانسی است که همیشه گران‌ترین گزینه را می‌فروشد. ارجاع شما به یک ادغام API، سیگنالی از اعتماد است، نه از دست دادن درآمد.

گام بعدی شما

• در اولین جلسه با پیمانکار ML، سؤال چهارم (چه زمانی مدل نسازم؟) را بپرسید تا میزان صداقت فنی آن‌ها را بسنجید.
• اگر پروژه‌ای در دست دارید، قرارداد را به دو فاز «ممیزی» و «ساخت» تقسیم کنید تا ریسک مالی کاهش یابد.
• از تیم فنی بخواهید متدولوژی ارزیابی آفلاین (Offline Evaluation) را به صورت مکتوب ارائه دهد.

اما هزینه استنتاج این مدل‌ها در مقیاس بالا چطور مدیریت می‌شود؟ به تحلیل ما درباره‌ی بهینه‌سازی هزینه‌های GPU مراجعه کنید.