تصور کنید مدیر محصولی هستید که بودجه هزاران دلاریاش را صرف تبلیغاتی میکند که فقط میگویند «CTR پایین است»، اما نمیگویند چرا. اگر امروز برای تحلیل ویدیوهای تبلیغاتی به حدس و گمان تکیه میکنید، باید بدانید که اکنون سیستمی وجود دارد که دقیقاً میگوید کدام ثانیه از ویدیو باعث ریزش مخاطب شده است. چرا یک تبلیغ خاص جواب میدهد و دقیقاً چه چیزی باید در مرحله بعد ساخته شود؟ در حالی که گزارشهای سنتی صرفاً ذکر میکنند که هزینه افزایش یافته یا نرخ بازگشت سرمایه (ROAS) کاهش یافته است، یک عامل هوش مصنوعی خلاق اکنون میتواند این پاسخهای دقیق را ارائه دهد. با تبدیل تحلیل تبلیغات به یک مسئله دادهای ساختاریافته (به جای یک وظیفه تولید متن)، این سیستم معیارهای عملکرد خام را به بریفهای خلاقانه قابل اجرا تبدیل میکند.
اکثر داشبوردهای بازاریابی فقط به سؤال «چه اتفاقی افتاد» پاسخ میدهند؛ آنها نشان میدهند که هزینه افزایش یافت، ROAS کاهش یافت یا نرخ کلیک (CTR) بهبود یافت. ممکن است یک کمپین نشانههایی از «خستگی محتوا» (Fatigue) را نشان دهد. اگرچه این اطلاعات مفید هستند، اما این سؤالی نیست که تیمهای خلاق واقعاً نیاز به پاسخ آن دارند. سؤال آنها سختتر است: چرا این محتوای خلاق جواب داد و برای ویدیو بعدی چه بسازیم؟
یک محتوای تبلیغی نتیجه مجموعهای از تصمیمات مشخص است: قلاب (بهویژه سه ثانیه اول)، پرسونا، زاویه پیامرسانی، پیشنهاد (Offer)، فراخوان به اقدام (CTA)، فرمت بصری و صدا. چالش واقعی درک این است که چگونه این تصمیمات خاص با عملکرد (Performance) مرتبط میشوند. راهکار، سیستمی است که ابتدا شواهد قطعی — شامل ساختار، آمار، سطح اطمینان و مدارک — را محاسبه کند و تنها پس از آن اجازه دهد یک عامل (Agent) روی نتایج استدلال کند.
تفاوت بین ابزاری که میگوید «ویدیوی شما شکست خورده است» با ابزاری که میگوید «قلابهای UGC با دوربین گوشی برای خریداران جدید در دو ثانیه اول بهتر از معرفیهای استودیویی عمل میکنند» را تصور کنید. مورد دوم اجازه میدهد یک سیستم حلقه-بسته ایجاد شود که در آن تحلیل مستقیماً به چرخه تولید بعدی اثر میگذارد. این اتوماسیون در تحلیل، مکمل ابزارهایی است که تولید و تغییر اندازه فرمتهای تبلیغاتی را به صورت خودکار مدیریت میکنند تا توزیع محتوا بهینهتر شود.
ژنوم خلاقانه و معماری دادهها
بنیان این سیستم «ژنوم خلاقانه» است. بهجای یک پاراگراف متن، یک مدل چندوجهی (Multimodal) ویدیو را تماشا کرده و یک استخراج ساختاریافته را برمیگرداند. این ژنوم واحدهای اتمیک و حیاتی را ثبت میکند:
- قلاب (Hook) و متن دقیق آن: دقیقاً چه چیزی در شروع ویدیو گفته و دیده میشود.
- اطلاعات زمانبندی: برچسبهای زمانی حیاتی، مانند لحظهای که محصول برای اولین بار ظاهر میشود.
- زمانبندی CTA: زمان دقیق وقوع فراخوان به اقدام.
- پیامرسانی و سبک: زاویه پیام، ادعاهای خاص مطرح شده در تبلیغ، سبک بصری، پرسونا و ویژگیهای صوتی.
برای اینکه این دادهها در میان هزاران تبلیغ قابل پرسوجو باشند، سیستم هر ژنوم را به مجموعهای از برچسبهای خلاقانه نمایهشده (Indexed Tags) گسترش میدهد. ذخیره دادهها به صورت بلوکهای JSON برای تحلیلهای مقیاس بزرگ ناکارآمد است. شما نمیتوانید بهطور بهینه بپرسید کدام انواع قلابها بهتر عمل میکنند یا کدام ترکیبات در حال خستگی هستند، در حالی که دادهها در JSONهای تودرتو قرار دارند. در عوض، سیستم از ردیفهای کوچک و نمایهشده با فرمت (entity, dimension, value) استفاده میکند.
برای مثال، یک برچسب میتواند hook_type = ugc_handheld باشد که دارای confidence = 0.82 (درجه اطمینان) و evidence = { timestamp: 2.5s, quote: "..." } (شواهد) است. این تبدیل تضمین میکند که ژنوم نشاندهنده هویت یک محتوای خاص است، در حالی که برچسبها نشاندهنده «دایره لغات خلاقانه» کل حساب کاربری هستند.
این رویکرد ساختاریافته اجازه میدهد سیستم عملیات GROUP BY را روی برچسبها انجام دهد و آنها را مستقیماً به دادههای عملکرد در ClickHouse متصل (Join) کند. این کار نیاز به تحلیل JSONهای عمیق برای یافتن الگوهای برنده و بازنده، ترکیبات برچسب، خوشههای جاسازی (Embedding Clusters) یا شکافهای رقابتی را حذف میکند. با نگه داشتن دادههای عملکرد در ClickHouse و اتصال آنها در زمان پرسوجو، معیارها همواره بهروز میمانند.
فراتر از ژنوم و برچسبها، معماری شامل چندین موجودیت پشتیبان است:
- creative_patterns: شناساییهای روزانه از ترکیبهای برنده/بازنده، عملکرد برچسبها، خوشههای برداری و شکافهای رقبا.
- creative_kb_summaries: یک سند جاری از اینکه «چه چیزی برای این برند جواب میدهد» که به عنوان زمینه (Context) برای عامل استفاده میشود.
- competitor_ad_analysis: ژنومهای استخراج شده مخصوصاً از تبلیغات رقبا برای شناسایی زاویههایی که برند از دست داده است.
- creative_analysis_jobs: صفی که فرآیندهای کند استخراج را مدیریت میکند.
- Embeddings: ذخیره شده در Chroma برای بازیابی معنایی.
- Memory cards: قطعات قابل استفاده مجدد از دانش خاص هر حساب کاربری.
معماری سیستم سه لایهای
پلتفرم از طریق سه مؤلفه اصلی عمل میکند:
۱. کارگر استخراج خلاقانه (Creative Extraction Worker): یک فرآیند طولانیمدت که صف درخواستها را تخلیه میکند. این بخش دارایی خلاق را شناسایی کرده، تصویر یا ویدیو را برای مدل آپلود میکند، استخراج ساختاریافته را اجرا میکند، پاسخ را اعتبارسنجی کرده و ژنوم و برچسبها را ذخیره میکند. یک استخراج واحد معمولاً بین ۳۰ تا ۹۰ ثانیه زمان میبرد.
۲. خط لوله هوشمند روزانه (Daily Intelligence Pipeline): یک شغل زمانبندی شده که ژنومها را با دادههای عملکرد ترکیب میکند تا منحنیهای خستگی، الگوهای برنده/بازنده، شکافهای رقابتی و یک خلاصه بینش (Insight Digest) را پیشمحاسبه کند. این تضمین میکند که وقتی کاربر چت را باز میکند، تحلیلهای سنگین قبلاً انجام شده است. عامل هر بار حساب را از دادههای خام بازکشف نمیکند، بلکه با شواهد ساختاریافته شروع میکند.
۳. زمان اجرای عامل (Agent Runtime): لایه تعاملی که هدف کاربر را تفسیر میکند، زمینه محدود به حساب را میسازد، حافظهها را بازیابی میکند، ابزارها را انتخاب کرده، آنها را از طریق یک محیط کنترلشده اجرا میکند و در نهایت یک پاسخ مستند یا یک بریف خلاقانه را ترکیب و ارائه میدهد. این ساختار تکعاملی میتواند در آینده به مدلهای پیشرفتهتری ارتقا یابد، همانطور که عاملهای چندنفره در حال جایگزینی باتهای تککاربره در مدیریت دانش سازمانی هستند تا تحلیلهای پیچیدهتری از طریق همکاری چندین Agent ممکن شود.
مهندسی برای قابلیت اطمینان و هزینه
استخراج ویدیو کندترین و گرانترین عملیات است. برای جلوگیری از پرداخت هزینه برای یک تحلیل تکراری، سیستم از یک اثر انگشت قطعی (Deterministic Fingerprint) استفاده میکند: sha256("creative_id | video_id | body | title"). از آنج که محتواهای Meta عملاً تغییرناپذیر هستند (ویرایش یک تبلیغ باعث ایجاد یک creative_id جدید میشود)، این هش بهطور قابلاعتمادی رسانه را شناسایی میکند. فقط فیلدهای منبع خام در هش گنجانده میشوند.
کارگر بر اساس اثر انگشت سه مسیر را دنبال میکند:
- اثر انگشت یکسان و تبلیغ یکسان: کل شغل را نادیده میگیرد.
- اثر انگشت یکسان اما تبلیغ متفاوت: ژنوم موجود را بدون فراخوانی مدل کپی میکند. این بزرگترین منبع صرفهجویی است، زیرا یک محتوا اغلب در مجموعههای تبلیغاتی یا کمپینهای مختلف تکرار میشود.
- بدون اثر انگشت منطبق: استخراج کامل را اجرا میکند.
برای مدیریت شغلها، توسعهدهنده بهجای بروکرهایی مانند RabbitMQ یا SQS، از یک جدول Postgres با استفاده از FOR UPDATE SKIP LOCKED استفاده کرد. این رویکرد باعث میشود ادعای شغلها تراکنشی باشد، اجازه دهد اولویتبندی از طریق ORDER BY پیادهسازی شود و وضعیت صف قابل مشاهده باشد. وقتی دو کارگر بهطور همزمان شغلها را درخواست میکنند، SKIP LOCKED تضمین میکند که آنها مجموعههای مجزایی از شغلها را دریافت کنند بدون اینکه پردازش تکراری رخ دهد. اگرچه در حال حاضر با یک نسخه کارگر اجرا میشود، اما منطق آن برای موازیسازی افقی در آینده ایمن است.
اولویت بر اساس هزینه ۳۰ روز اخیر تعیین میشود، به این معنی که خلاقترینهای با هزینه بالاتر ابتدا تحلیل میشوند. این تضمین میکند که حتی در صورت تکمیل جزئی دستهها، بیشترین ارزش فراهم شود. برای مدیریت کرشها، مدت اجاره (lease) و تعداد تلاشها در همان تراکنشی که شغل را رزرو میکند، بهروزرسانی میشود. این کار مانع از آن میشود که شغلها در صورتی که کارگر قبل از ثبت شکست کرش کند، برای همیشه در حلقه بمانند.
سیستم از یک ماشین حالت استفاده میکند: queued (در صف) $ \rightarrow $ leased (اجاره شده) $ \rightarrow $ done (انجام شده). در صورت شکست، به queued باز میگردد. پس از سه تلاش ناموفق، به وضعیت dead منتقل میشود، جایی که یک رکورد قابل بازپخش نگه داشته میشود. اگر یک کارگر به دلیل کمبود حافظه (OOM) کشته شود یا گیر کند، برچسب زمانی leased_until در نهایت منقضی شده و چرخه بعدی کارگر بهطور خودکار شغل را دوباره در صف قرار میدهد. خودِ اجاره به عنوان یک تایماوت عمل میکند.
برای تضمین استحکام، سیستم شامل جایگزینهای (Fallbacks) تدریجی است. اگر ویدیویی قابل بازیابی نباشد، کارگر تصویر بندانگشتی (Thumbnail) یا فریم قلاب را تحلیل کرده و ژنوم را به عنوان «استخراج جایگزین» علامت میزند. اگر مسیر مدل Claude در دسترس نباشد، سیستم بهطور شفاف به Gemini تغییر مسیر میدهد. علاوه بر این، یکتایی (Idempotency) از طریق ایندکسهای منحصربهفرد در صفبندی و آپسرتهای (Upserts) نوشتن ژنوم اعمال میشود و تلاشهای مجدد را ایمن میکند.
اصل «اول محاسبه، بعد روایت»
فلسفه اصلی سیستم این است که مدل نباید محاسبات ریاضی انجام دهد یا تصمیم بگیرد که آیا یک الگو از نظر آماری معنادار است یا خیر. اپلیکیشن ابتدا شواهد را محاسبه میکند. برای هر الگو، سیستم موارد زیر را محاسبه میکند:
- ROAS تجمیعی (Pooled)
- نرخ برد وزندار بر اساس هزینه (Spend-weighted win rate)
- میزان بهبود نسبت به خط پایه حساب (Lift)
- اندازه نمونه و بازههای اطمینان (Confidence Intervals)
بازههای اطمینان مانع از آن میشوند که نوسانات تصادفی در نمونههای کوچک به عنوان سیگنالهای قوی ارائه شوند. «خستگی» یک «حس» از سوی هوش مصنوعی نیست، بلکه بر اساس یک منحنی زوال (Decay Curve) است که CTR را در مقابل نمایشهای (Impressions) تجمعی برازش میکند. خوشههای برداری در Chroma بهطور ریاضی شناسایی میشوند؛ از مدل صرفاً خواسته میشود که آن خوشهها را نامگذاری کرده و توضیح دهد. دلتای عملکرد پیش از تولید توصیهها محاسبه میشود. تنها پس از محاسبه این مقادیر قطعی است که مدل آنها را دریافت میکند تا به زبان خواندنی تبدیل کند.
هرنس عامل و ابزارها (Agent Harness)
عامل بهجای دسترسی خام به دیتابیس، از طریق ابزارهای تایپشده (Typed Tools) با سیستم تعامل میکند. این کار از تولید SQLهای произвоه جلوگیری کرده و جداسازی حسابها را تضمین میکند. تعریف یک ابزار شامل یک نام واضح، اسکیمای ورودی تایپشده، الزامات محدوده حساب، قوانین اعتبارسنجی و یک اسکیمای خروجی ساختاریافته است.
مثالهایی از قابلیتهای ابزارهای خاص عبارتند از:
- خواندن عملکرد خلاقانه و بررسی خستگی.
- یافتن الگوهای برنده/بازنده و زاویههای رقبا.
- بازیابی ژنومها، برچسبها و محتواهای مشابه معنایی از طریق Embeddings.
- بارگذاری دانش در سطح حساب و حافظهها.
- تولید یک بریف خلاقانه ساختاریافته.
برای مثال، بهجای SQL، مدل یک عملیات محدود را درخواست میکند: { "account_id": "account_123", "window_days": 30, "dimension": "hook_type", "minimum_spend": 500 }. سپس هرنس، کوئری امن را اجرا میکند.
هرنس عامل حلقه زیر را مدیریت میکند: برنامهریزی $ \rightarrow $ فراخوانی ابزار $ \rightarrow $ اعتبارسنجی آرگومانها $ \rightarrow $ اجرا $ \rightarrow $ مشاهده نتیجه $ \rightarrow $ بهروزرسانی زمینه $ \rightarrow $ ادامه یا پاسخ. هرنس حداکثر تعداد مراحل، بودجه فراخوانی ابزار، تایماوتها و جایگزینهای مدل را اعمال میکند. این لایه شکستهای ابزار را به مشاهدات تایپشده تبدیل میکند تا عامل بتواند دوباره تلاش کند، ابزار جایگزین را انتخاب کند یا توضیح دهد چرا شواهدی در دسترس نیست.
مهندسی زمینه و حافظه
برای جلوگیری از پرت کردن حواس مدل با دادههای نامرتبط، یک «سازنده زمینه» (Context Builder) کوچکترین وضعیت مفید را جمعآوری میکند. مدل نباید هر فکتی که ذخیره شده است را دریافت کند. سازنده زمینه موارد را بر اساس معیارهای زیر فیلتر میکند: آیا این مورد با درخواست فعلی مرتبط است؟ آیا مربوط به حساب صحیح است؟ آیا مفیدتر از موارد دیگر است که برای بودجه توکنها رقابت میکنند؟ آیا شواهد کافی برای تأثیرگذاری بر پاسخ دارد؟
زمینه از چندین منبع جمعآوری میشود:
- درخواست فعلی کاربر و محدوده حساب/برند.
- خلاصههای جاری پایگاه دانش و الگوهای خلاقانه مرتبط.
- کارتهای حافظه بازیابی شده و محتواهای مشابه معنایی.
- وضعیت گفتگوهای اخیر و نتایج ابزارهای فراخوانی شده در اجرای جاری.
حافظه به دو لایه تقسیم میشود:
۱. حافظه گفتگو (Conversation Memory): پیامهای کوتاهمدت برای درک تبادل فعال.
۲. حافظه دانش برند (Brand Knowledge Memory): یک نمای فشرده و بهروز شده در سطح حساب در جدول creative_kb_summaries که از شواهد جاری ساخته شده است و نه از ترانسکریپتهای خام.
هر پاسخ توسط یک قرارداد خروجی و سیاست پرامپت (Prompt Policy) هدایت میشود. پرامپت رفتار را تعریف میکند: تفکیک واقعیتها از تفاسیر، استفاده از ابزارها برای اعداد، هرگز اختراع نکردن معیارها و بیان عدم قطعیت در زمانی که شواهد ضعیف هستند. عامل باید بین این موارد تمایز قائل شود:
- واقعیت (Fact): مستقیماً توسط دادههای محاسبه شده پشتیبانی میشود.
- استنتاج (Inference): یک تفسیر منطقی از یک یا چند واقعیت.
- پروکسی (Proxy): یک اندازهگیری غیرمستقیم که به دلیل عدم دسترسی به اندازهگیری ایدهآل استفاده شده است.
- توصیه (Recommendation): یک اقدام پیشنهادی که توسط شواهد موجود پشتیبانی میشود.
بستن حلقه خلاقیت
این معماری از «گزارشدهی» به یک «حلقه» حرکت میکند: تحلیل $ \rightarrow $ شناسایی الگوها $ \rightarrow $ بازیابی حافظه $ \rightarrow $ پیشنویس مفهوم $ \rightarrow $ تولید $ \rightarrow $ اجرا $ \rightarrow $ تحلیل.
ویژگیهای ساختاریافتهای که برای توضیح یک پیروزی (Win) استفاده میشوند، برای مشخص کردن محتوای بعدی به کار میروند. خروجی نهایی یک پیشنهاد کلی نیست، بلکه یک بریف خلاقانه ساختاریافته است:
- فرمت: UGC دوربین گوشی (Handheld)
- پرسونا: خریدار اول
- قلاب: بیان مشکل در ثانیه اول
- نمایش محصول: قبل از ثانیه ۲.۰
- زاویه: مشکل $ \rightarrow $ نمایش $ \rightarrow $ اثبات
- CTA: مستقیم
- اجتناب از: نسخههای قلابهای خسته شده فعلی
- شواهد: بر اساس عملکرد ۳۰ روز اخیر حساب
این رویکرد تمرکز را از «پرامپت دادن به مدل» به «ساختن یک هرنس» تغییر میدهد. در حالی که پرامپت شکلدهنده استدلال است، هرنس شکلدهنده اجراست — مدیریت میکند که مدل به چه چیزی دسترسی داشته باشد، شکستها چگونه مدیریت شوند و چه چیزی باید قبل از بازگرداندن پاسخ درست باشد. کار مهندسی واقعی، ساختن یک سیستم عاملیت (Agentic) قابل اطمینان، یکتا (Idempotent)، کنترلشده از نظر هزینه و آگاه از حافظه است که در اطراف مدل قرار میگیرد.
گام بعدی شما
- اگر از LLM برای تحلیل دادهها استفاده میکنید، محاسبات آماری را به کد بسپارید و فقط نتایج نهایی را برای تفسیر به مدل بدهید.
- برای کاهش هزینه استنتاج در پردازشهای تکراری، از سیستم هشینگ (Fingerprinting) برای شناسایی داراییهای مشابه استفاده کنید.
- دسترسی مدل به دیتابیس را از طریق Tool-calling با ورودیهای محدودشده (Schema-based) مدیریت کنید تا امنیت دادهها حفظ شود.
اما مدیریت حافظه در مقیاس وسیع، چالشهای پیچیدهتری دارد — به تحلیل ما درباره پروتکل زمینه مدل (MCP) مراجعه کنید.
گفتگو