جداسازی لایه استدلال از اجرا؛ راهکار Fluency برای مدیریت ۳ میلیارد دلار بودجه

تصور کنید مدیریت ۳ میلیارد دلار بودجه سالانه را به دست سیستمی بسپارید که هر بار به یک سؤال، پاسخی متفاوت می‌دهد. در دنیای تبلیغات دیجیتال، چنین ریسکی به معنای فاجعه مالی است و دقیقاً به همین دلیل است که Fluency لایه استدلال را از لایه اجرا جدا کرده است. مدیریت بودجه‌های کلان نیازمند دقتی است که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — به‌تنهایی قادر به ارائه آن نیستند. طبق اعلام این شرکت، راهکار آن‌ها محصور کردن استدلال‌های احتمالی هوش مصنوعی در یک لایه اجرای قطعی است تا داده‌ها، دارایی‌های خلاقانه، موجودی‌ها، الزامات انطباق، مخاطبان، استراتژی کمپین، گزارش‌دهی و گردش‌های کاری اجرا در مقیاس وسیع و بدون خطا هماهنگ شوند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، تکیه بر خروجی‌های احتمالی در سیستم‌های مالی خطرناک است. صنعت تبلیغات طی دو دهه از جایگذاری‌های دستی به خرید برنامه‌ریزی‌شده (Programmatic) و مزایده‌های لحظه‌ای (RTB) رسید. این تغییر اجازه داد تا نرم‌افزارها در کسری از میلی‌ثانیه تصمیمات مالی بگیرند، اما در عین حال زیرساختی عظیم و تشنه‌ی انرژی ایجاد کرد. اکنون نوبت به «تبلیغات عامل‌محور» (Agentic Advertising) رسیده است؛ جایی که عامل‌های هوش مصنوعی (AI Agents) گردش‌های کاری پیچیده مدیریت کمپین را با استفاده از جریان‌های کاری تحت نظارت مدیریت می‌کنند تا کنترل‌های استراتژیک و استانداردهای برند حفظ شود.

تکامل تکنولوژی تبلیغات (Ad-Tech)

این گذار توسط پیشکسوتانی مانند اریک پیکارد (Eric Picard)، نایب‌رئیس ارشد محصول در Fluency هدایت می‌شود که مسیر شغلی او بازتاب‌دهنده رشد این صنعت است. تجربه پیکارد از تأسیس شرکت Bluestreak در سال ۱۹۹۷ آغاز شد. او در آن زمان به ایجاد اولین استانداردهای نمایش (Impression Standards) با همکاری دفتر تبلیغات تعاملی (IAB) و شورای رتبه‌بندی رسانه (MRC) کمک کرد. در Bluestreak، تیم پیکارد چندین نوآوری پیشگامانه را معرفی کرد، از جمله برخی از اولین تبلیغات ویدئویی و صوتی، اولین سیستم مدیریت تگ‌ها (Tag Management System) و اولین مدل تخصیص چند-لمسی (Multi-touch Attribution) در تمامی انواع رسانه‌های دیجیتال.

دوران فعالیت پیکارد در مایکروسافت، مقیاس این فرصت را بیشتر نمایان کرد. او مأموریت داشت استراتژی جهانی ورود مایکروسافت به حوزه Ad-tech را بنویسد؛ این تصمیم پس از مشاهده این واقعیت گرفته شد که گوگل به ازای هر نسخه از ویندوز، بیشتر از خود مایکروسافت درآمد کسب می‌کرد. پیکارد بررسی‌های دقیقی (Due Diligence) روی بیش از ۱۵۰ شرکت انجام داد و نظارت بر تصاحب هفت شرکت را بر عهده گرفت. تحت این استراتژی، تیم مهندسی Ad-tech از ۲۰۰ نفر به ۱,۵۰۰ مهندس افزایش یافت و درآمد رسانه‌ای از ۷۵۰ میلیون دلار به بیش از ۵ میلیارد دلار جهش کرد. امروزه درآمد تبلیغات جستجو در این حوزه به حدود ۱۵ میلیارد دلار می‌رسد.

ریشه‌های مزایده لحظه‌ای (RTB)

یکی از لحظات کلیدی در این تکامل، تصاحب شرکت AdECN بود که توسط جف گرین تأسیس شده بود. در حالی که مایکروسافت گزینه‌های دیگری مانند Right Media را بررسی می‌کرد، AdECN را برای ساخت یک مزایده جهانی غیرهمزمان (Asynchronous) برای پیشنهاددهندگان خارجی انتخاب کرد. اگرچه صرافی RTB شرکت AdECN هرگز به‌طور کامل از حالت بتا خارج نشد، اما به عنوان کاتالیزوری برای اکوسیستم مدرن عمل کرد. این اتفاق منجر به تأسیس AppNexus توسط برایان اوکلی شد — که در نهایت به شریکی اصلی تبدیل شد و بعدها توسط مایکروسافت خریداری گشت — و همچنین منجر به تأسیس The Trade Desk توسط جف گرین شد.

نقش‌های بعدی پیکارد این تخصص را عمیق کرد. او Rare Crowds را تأسیس کرد، جایی که تیمش مفهوم «کیوریتور برنامه‌ریزی‌شده» (Programmatic Curation) را ابداع کردند. او همچنین نقش‌های مدیریتی در Pandora داشت که بزرگترین صرافی تبلیغات صوتی را اداره می‌کرد، و در Yieldmo فعالیت کرد که در آن به ساخت اولین صرافی تبلیغاتی با محوریت حریم خصوصی کمک نمود. در طول این سال‌ها، او در هیئت مدیره IAB Techlab و کمیته اجرایی آن عضو بود.

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

ریسک هوش مصنوعی احتمالی

به گفته پیکارد، خطر اصلی استفاده از LLMها برای بودجه‌های تبلیغاتی، ماهیت احتمالی (Probabilistic) آن‌هاست. مدل‌های زبانی بزرگ طوری طراحی شده‌اند که به یک سؤال واحد، پاسخ‌های متفاوتی بدهند، که این امر آن‌ها را ذاتاً برای محاسبات ریاضی یا کنترل‌های مالی سخت‌گیرانه غیرقابل اعتماد می‌کند. پیکارد خاطرنشان می‌کند که اگرچه یک LLM ممکن است به نظر برسد که ریاضیات بلد است، اما اغلب این کار را با نوشتن یک اسکریپت انجام می‌دهد و به‌طور بومی «قطعی» (Deterministic) نیست.

او استدلال می‌کند که به دلیل همین واریانس ذاتی، هرگز اجازه نمی‌دهد یک LLM امور مالی او را مدیریت کند، اظهارنامه‌های مالیاتی‌اش را ثبت کند یا حتی یک پست وبلاگی را بدون ویرایش دقیق بنویسد. از آنجایی که موتورهای احتمالی برای خلاقیت و «تفکر» طراحی شده‌اند، اساساً در انجام یک کار به یک شکل یکسان در هر بار تکرار، ضعیف هستند. این موضوع باعث می‌شود آن‌ها برای کنترل مستقیم بودجه‌های تبلیغاتی بدون یک لایه قطعی، بیش از حد ریسکی باشند.

معماری تبلیغات عامل‌محور

سیستم Fluency «تفکر» را از «انجام دادن» جدا می‌کند. لایه احتمالی (LLM) تطبیق الگوها، تحلیل خلاقانه و استراتژی را بر عهده دارد. لایه قطعی (لوله‌ها) تغییرات واقعی را روی پلتفرم‌های تبلیغاتی اجرا می‌کند.

• حفاظ‌های قطعی (Deterministic Guardrails): اگر یک قانون تجاری بتواند در قالب منطق «اگر/آنگاه» (IF/THEN) بیان شود، Fluency آن را به عنوان یک قانون سخت‌گیرانه کدنویسی می‌کند. این تضمین می‌کند که تغییر بودجه یا توقف یک کمپین هر بار دقیقاً به یک شکل رخ دهد. این امر از تصمیمات مالی نامنظم ناشی از ماهیت احتمالی AI جلوگیری می‌کند. این رویکرد در واقع پاسخی به چالش‌های پایداری در محیط‌های عملیاتی است، چرا که صرفاً تکیه بر مهندسی پرامپت برای کنترل عامل‌های سازمانی کافی نیست.
• حضور انسان در چرخه (Human-in-the-Loop): سیستم به مشتریان اجازه می‌دهد تحمل ریسک خود را تنظیم کنند. تصمیمات کم‌ریسک به‌طور خودمختار انجام می‌شوند، در حالی که ناهنجاری‌های پرریسک یا قضاوت‌های ذهنی، هشداری برای مداخله انسانی ارسال می‌کنند تا انسان بتواند «فرمان را به دست بگیرد».
• قابلیت حسابرسی: به دلیل انطباق با استاندارد SOC2، هر اقدام ثبت (Log) می‌شود. قوانین تجاری کدنویسی‌شده به عنوان مشخصات فنی خود عمل می‌کنند و از «انحراف» (Drift) بین مستندات و رفتار واقعی سیستم جلوگیری می‌کنند. گزارش‌های تغییرات، هر اصلاح را نسبت به کاربر یا عاملی که آن را آغاز کرده است، ردیابی می‌کند.
• استدلال بین‌پلتفرمی: Fluency در کانال‌های جستجو، شبکه‌های اجتماعی و کانال‌های برنامه‌ریزی‌شده عمل می‌کند. در حالی که APIها «لوله‌های ثابتی» از کارهایی هستند که می‌توان انجام داد، Fluency «دفترچه‌های راهنمای» (Playbooks) خاص هر مشتری و بهترین شیوه‌ها را در قالب دستورالعمل‌هایی کدنویسی می‌کند که LLMها برای دستیابی به نتایج متمایز برای هر کلاینت از آن‌ها پیروی می‌کنند.

حل مشکل «مایل آخر»

در حالی که پروتکل‌های AAMP (مدیریت تبلیغات عامل‌محور) در IAB TechLab بر بهبود زیرساخت RTB از طریق پروکسی کردن LLMها در سیستم‌های لحظه‌ای با استفاده از کشینگ (Caching) تمرکز دارد، Fluency بر سطح حساب (Account) و خلاقیت تمرکز می‌کند. این همان چیزی است که پیکارد «مشکل مایل آخر» می‌نامد: ناکارآمدی در ایجاد و مدیریت دستی هزاران نسخه تبلیغاتی در سطح حساب.

این تمرکز با پروژه AdCP (تبلیغات عامل‌محور) که توسط AgenticAdvertising.org مدیریت می‌شود، همسو است. پیکارد اولین مشخصات فنی برای «حاکمیت و انطباق» (Governance and Compliance) را برای AdCP نوشت و تشخیص داد که کارهایی که انسان‌ها در مدیریت کمپین و گردش‌های کاری خلاقانه انجام می‌دهند، اصلی‌ترین حوزه‌ای است که برای اتوماسیون آماده است. Fluency هشت سال پیش از آنکه LLMها برای تبدیل شدن به «عامل» آماده شوند، در حال پیاده‌سازی این عامل‌های قطعی بود. در واقع، برای موفقیت در چنین محیط‌هایی، سیستم باید به جای یک دستیار ساده، به یک سامانه کنش‌گرا تبدیل شود که مستقیماً بر روی عملیات اثر می‌گذارد.

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

پیاده‌سازی فنی و حاکمیت

پیاده‌سازی تبلیغات عامل‌محور در پلتفرم‌های متنوع نیازمند پیمایش در ساختارهای داده‌ای و الزامات سیاستی متفاوت است. پیکارد تأکید می‌کند که اگرچه APIها به‌خوبی مستند شده‌اند، اما آن‌ها فقط توصیف می‌کنند که چه کاری می‌توان انجام داد، نه اینکه بهترین شیوه‌ها برای چگونه انجام دادن آن چیست. Fluency این شکاف را با وارد کردن دفترچه‌های راهنمای خاص مشتری به زمینه (Context) مدل LLM پر می‌کند و به هوش مصنوعی اجازه می‌دهد بر اساس نیازهای استراتژیک خاص هر برند استدلال کند.

حسابرسی و انطباق

در یک محیط تحت نظارت، توانایی بررسی اشتباهات و اثبات انطباق بسیار حیاتی است. Fluency این موضوع را از طریق چندین مکانیسم حل می‌کند:

• انطباق با SOC2: پلتفرم برای برآورده کردن استانداردهای سخت‌گیرانه امنیتی و عملیاتی ساخته شده است.
• گزارش‌های تغییرات (Change Logs): هر تغییر نسبت به کاربر یا عامل خاصی که اقدام را آغاز کرده است، ثبت می‌شود.
• رندر کردن منطق (Logic Rendering): از آنجایی که قوانین تجاری در نرم‌افزار کدنویسی شده‌اند، منطق می‌تواند در صورت نیاز به زبان تجاری ساده تبدیل شود. این به حسابرسان اجازه می‌دهد دستورالعمل‌های سیستم را بدون نیاز به خواندن کدهای خام درک کنند.
• صفر کردن انحراف (Zero Drift): با تبدیل قانون به خودِ مشخصات فنی، Fluency تضمین می‌کند که هیچ شکافی بین قصد مستند شده و رفتار واقعی سیستم وجود ندارد.

درس‌هایی برای صنایع تحت نظارت

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

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

در حال حاضر Fluency ماهانه بیش از ۲۵۰,۰۰۰ کمپین را پشتیبانی می‌کند و تقریباً ۳ میلیارد دلار بودجه تبلیغاتی سالانه را مدیریت می‌کند. با استفاده از LLMها برای کمک به ساخت مجموعه‌قوانین اولیه و نوشتن اسکریپت‌های اتوماسیون، این شرکت زمان پیوستن (Onboarding) آژانس‌های جدید را کاهش داده است؛ فرآیندی که پیش از این مانند پیاده‌سازی یک CRM طولانی و چندماهه بود.

این تغییر، نقش انسان را از «خاموش کردن آتش‌ها» به استراتژی سطح بالا منتقل می‌کند. ماشین کارهای عملیاتی تکراری را انجام می‌دهد، در حالی که انسان فرمان را برای قضاوت‌های ذهنی و آزمایش‌های خلاقانه در دست نگه می‌دارد.

گام بعدی شما

• اگر از ابزارهای AI برای مدیریت بودجه استفاده می‌کنید، بررسی کنید آیا لایه‌ای برای اعتبارسازی خروجی‌ها (Validation Layer) دارید یا مستقیماً به APIها متصل هستید.
• در طراحی سیستم‌های عامل‌محور، منطق‌های مالی را از لایه استدلال LLM جدا کرده و در قالب توابع قطعی (Deterministic Functions) پیاده کنید.
• استانداردهای SOC2 را برای ثبت تغییرات (Change Logs) در سیستم‌های خودتان به عنوان اولویت قرار دهید.

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