یک اسکریپت ۳۳۰ خطی پایتون؛ چرخه بازخورد داده‌محور برای تولید محتوای یوتیوب

تصور کنید یک اسکریپت ۳۳۰ خطی پایتون که هر روز در GitHub Actions اجرا می‌شود و استراتژی محتوایی یک کانال یوتیوب را تغییر می‌دهد. در این سیستم، اسکریپت‌های تولیدشده توسط هوش مصنوعی دیگر در خلاء نوشته نمی‌شوند، بلکه یک چرخه بازخورد بسته (Closed-loop) داده‌های عملکردی را می‌خواند تا جهت خلاقانه محتوای فردا را تعیین کند.

این ابزار در زمانی عرضه شده که بسیاری از تولیدکنندگان محتوا از مدل‌های زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برای تولید انبوه استفاده می‌کنند اما با مشکل «انحراف محتوایی» (Content Drift) روبرو هستند؛ وضعیتی که در آن هوش مصنوعی ویدیوهایی تولید می‌کند که دیگر با مخاطبان ارتباط نمی‌گیرند. در حالی که بیشتر خط‌لوله‌های اتوماسیون خطی هستند (یعنی مسیری یک‌طرفه از نوشتن پرامپت تا رندر نهایی)، این سیستم یک لایه بازگشتی اضافه کرده است که در آن داده‌های واقعی عملکرد، زمینه و محتوای پرامپت را دیکته می‌کنند.

به نقل از راهنمای فنی منتشرشده در وب‌سایت dev.to در تاریخ ۲۵ ژوئن ۲۰۲۶، این سیستم بر پایه YouTube Data API v3 کار می‌کند. برای جلوگیری از ثبت سخت‌افزاری (Hardcoding) شناسه‌های حساس و حفظ امنیت، اسکریپت از یک استراتژی چهارمرحله‌ای برای شناسایی استفاده می‌کند. این استراتژی با بهره‌گیری از متغیرهای محیطی و مکانیسم‌های جایگزین جستجو (Search Fallbacks) تلاش می‌کند تا هندل (Handle) صحیح کانال را بیابد. پس از شناسایی موفقیت‌آمیز، سیستم ۳۰ ویدیوی اخیر و تمامی آمار و ارقام مربوط به آن‌ها را استخراج می‌کند.

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

• عملکرد بالا (HIGH Performers): ویدیوهایی که تعداد بازدید آن‌ها مساوی یا بیشتر از ۱.۵ برابرِ مقدار میانه باشد.
• عملکرد پایین (LOW Performers): ویدیوهایی که بازدید آن‌ها مساوی یا کمتر از ۰.۶ برابرِ میانه باشد؛ البته به شرطی که حداقل ۷۲ ساعت از زمان انتشار آن‌ها گذشته باشد تا فرصت بازدید داشته باشند.
• خنثی (Neutral): هر چیزی که بین این دو بازه باشد نادیده گرفته می‌شود تا نویز داده‌ها کاهش یابد.

نویسنده این پروژه به طور مشخص دلیل انتخاب «میانه» به جای «میانگین» (Mean) را این ذکر کرده است که از تغییر شدید معیار پایه جلوگیری شود؛ در واقع، اگر یک ویدیوی تک‌ویرال (بسیار پربازدید) داشته باشیم، میانگین را به شدت بالا می‌برد و باعث می‌شود بقیه ویدیوهای خوب به اشتباه در دسته «عملکرد پایین» قرار بگیرند، اما میانه در برابر این داده‌های پرت مقاوم است.

از آنجا که API یوتیوب از «آرکتایپ‌های» (Archetypes) داخلی هوش مصنوعی (مثلاً دسته‌هایی مثل «آموزشی» یا «مرور») اطلاعی ندارد، اسکریپت از مکانیسم «هم‌پوشانی عنوان» (Title-Overlap) استفاده می‌کند. سیستم عناوین ویدیوهای استخراج شده از API را با لیست محلی صف آپلودها تطبیق می‌دهد؛ اگر حداقل چهار کلمه کلیدی و معنادار بین این دو هم‌پوشانی داشته باشند، آن ویدیو به آرکتایپ مربوطه متصل می‌شود.

برای درک دقیق‌تر اینکه چرا یک ویدیو موفق شده است، سیستم «قلاب‌ها» (Hooks) یا همان جملات آغازین را بر اساس اولین کلمه اسکریپت تحلیل می‌کند:

• پرسشی: ویدیوهایی که با کلمات «چرا»، «چگونه» یا «چه» شروع می‌شوند.
• عددی: ویدیوهایی که با اعداد یا ارقام شروع می‌شوند.
• اول‌شخص: ویدیوهایی که با «من»، «من هستم» یا «من بوده‌ام» شروع می‌شوند.
• دستوری-متضاد: ویدیوهایی که با کلمات تاکیدی مثل «بس کنید»، «هرگز» یا «نکنید» آغاز می‌شوند.

این تحلیل‌ها در نهایت در فایلی به نام yt-knowhow-bank-en.md و در بخشی با عنوان «یادداشت‌های اتوتیونر روتین» (Routine Auto-Tuner Notes) نوشته می‌شود. مدل تولیدکننده اسکریپت، در ابتدای هر جلسه کاری، این فایل را می‌خواند. سیستم به گونه‌ای طراحی شده که کورکورانه از داده‌ها پیروی نکند، بلکه از این «نشانه های سوگیری» (Bias Hints) استفاده کند تا انتخاب‌های خود را برای نوشتن اسکریپت روز بعد اصلاح نماید.

کل این جریان کاری به صورت یک Cron Job روزانه در محیط GitHub Actions مدیریت می‌شود. توسعه‌دهنده اشاره کرده است که این سیستم بسیار بهینه است و تنها از ۳ تا ۵ واحد از سهمیه رایگان ۱۰,۰۰۰ واحدی روزانه گوگل استفاده می‌کند. برای سبک نگه داشتن ساختار، نویسنده تصمیم گرفت از YouTube Analytics API استفاده نکند، زیرا این API نیازمند مدیریت پیچیده توکن‌های رفرش (Refresh Tokens) در پروتکل OAuth 2.0 است که پیاده‌سازی آن در GitHub Actions دشوار بود.

برای کسانی که با ابزارهای بهره‌وری کار می‌کنند، این رویکرد ثابت می‌کند که «سطل‌بندی ساده» (Simple Bucketing) اغلب از «بهینه‌سازی پیچیده» بهتر جواب می‌دهد. با تبدیل عملکرد به سیگنالی برای سوگیری پرامپت (به جای یک هدف ریاضی صلب)، تولیدکننده از تله‌ی «بهینه‌سازی بیش از حد» می‌گریزد؛ جایی که محتوا ممکن است الگوریتم یوتیوب را راضی کند اما برای انسان خسته‌کننده و مصنوعی باشد.

با این حال، اتکای فعلی به تحلیل تنها کلمه اول برای طبقه‌بندی قلاب‌ها یک نقطه ضعف فنی است. با رشد مقیاس کانال، جایگزینی این منطق ساده با یک فراخوانی کوچک از مدل‌های زبانی سریع و ارزان مثل Claude Haiku برای تحلیل و دسته‌بندی کامل جمله اول، سیگنال‌های بسیار دقیق‌تری را در اختیار سیستم قرار می‌دهد.

توسعه‌دهنده سه مسیر کلیدی برای بهبود آینده شناسایی کرده است: اول، انتقال از معیار «تعداد بازدید خام» به «میانگین مدت تماشا» (Average View Duration) برای ردیابی بهتر درگیرشدگی مخاطب؛ دوم، پیاده‌سازی «هموارسازی بیزی» (Bayesian Smoothing) برای زمانی که تعداد ویدیوها کم است و داده‌ها قابل اعتماد نیستند؛ و سوم، ارتقای کامل سیستم طبقه‌بندی قلاب‌ها به مدل‌های LLM.

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

گام بعدی شما

• تصمیمات پرامپت خود را در یک فایل Markdown ذخیره کنید.
• بر اساس معیارهای ساده API (مثل بازدید یا لایک)، این فایل را به‌روزرسانی کنید تا مدل شما «یاد بگیرد» چه چیزی جواب می‌دهد.
• برای تحلیل دقیق‌تر قلاب‌ها، از مدل‌های کوچک و ارزان برای دسته‌بندی جملات آغازین استفاده کنید.

این تنها لایه نرم‌افزاری است؛ اما نحوه مدیریت هزینه‌های استنتاج در مقیاس بالا داستان دیگری دارد که در تحلیل ما درباره GPUها بررسی کرده‌ایم.