عامل‌های هوش مصنوعی ۵.۷ برابر گران‌تر از اسکریپت‌های سنتی استخراج داده هستند

اگر امروز برای استخراج داده‌ها از ابزارهای کدنویسی سنتی استفاده می‌کنید، احتمالاً با شکست‌های مکرر به دلیل تغییر ساختار سایت‌ها دست‌وپنجه نرم می‌کنید. اما جایگزینی کامل این کدها با عامل‌های هوش مصنوعی، صورت‌حساب توکن‌های شما را به شکلی تکان‌دهنده افزایش می‌دهد. این تنش در مجموعه‌ای از تست‌ها برجسته شد که در آن یک توسعه‌دهنده، عملکرد یک عامل (Agent) مجهز به ابزارهای مرورگر را با یک اسکریپت استاندارد Playwright برای جمع‌آوری داده‌های ۶۰ کافی‌شاپ در سه شهر آمریکا مقایسه کرد.

این آزمایش در حالی انجام می‌شود که صنعت در حال بحث است که آیا جریان‌های کاری عامل‌محور (Agentic Workflows) جایگزین اتوماسیون سنتی خواهند شد یا خیر. در انجمن r/automation، رشته‌بحثی دقیقاً به این موضوع پرداخت که آیا یک عامل LLM می‌تواند به‌جای انسانی که انتخابگرها (Selectors) را می‌نویسد، جایگزین یک اسکرپر برای سایت‌های ساده شود. همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی هزینه‌های Claude Code اشاره کردیم، تضاد میان صلبیت کد و انعطاف‌پذیری مدل‌های زبانی همچنان گلوگاه اصلی مقیاس‌پذیری در محیط‌های عملیاتی است. این چالش هزینه‌ای است که در مقایسه با تفاوت قیمت ابزارهای متن‌باز و سرویس‌های مدیریت‌شده برای استخراج داده‌های آماده‌ی هوش مصنوعی، ابعاد جدیدی پیدا کرده است.

تفاوت این دو را این‌گونه تصور کنید: یک ربات تخصصی که فقط می‌داند چگونه یک درِ خاص را باز کند در مقابل انسانی که می‌تواند هر نوع قفلی را باز کند اما برای هر دقیقه کار هزینه می‌گیرد. اسکریپت Playwright همان ربات است و عامل Claude همان انسان است.

جزئیات عملکرد عامل

این عامل تنها به ابزارهای عمومی مرورگر دسترسی داشت: باز کردن صفحات، جست‌وجوی متن، استخراج متن صفحه و اجرای جاوااسکریپت در داخل صفحه. هیچ اسکرپری از پیش برای آن نوشته نشده بود؛ تنها کدهایی که به کار رفت، قطعات کوتاهی از جاوااسکریپت بود که خودِ عامل در حین فرآیند نوشت و اجرا کرد. مأموریت او جمع‌آوری نام‌ها، امتیازها، تعداد نظرات، آدرس‌ها و شماره تلفن‌ها از گوگل‌مپ از طریق جست‌وجوی عبارت "coffee near" در مکان‌های خاص بود.

در ۶۰ رکورد بررسی شده، عامل به نرخ دقت ۱۰۰٪ دست یافت. او موفق شد تمام فیلدها را در هر ردیف، حتی داده‌هایی که نیاز به پیمایش در ساختارهای پیچیده صفحه داشتند، استخراج کند. این تست شامل چهار اجرای مجزا بود:

• اجرای اول: ۱۰ مکان در تایمز اسکوئر، نیویورک (موفقیت ۱۰/۱۰). ۴۷ استفاده از ابزار، ۵۴ فراخوانی مدل، ۲۹۲ ثانیه زمان اجرا، ۸۷ هزار توکن در پایان کانتکست، ۲.۹۳ میلیون توکن پردازش شده و ۴۹۲ هزار توکن وزنی.
• اجرای دوم: تکرار ۱۰ مکان در تایمز اسکوئر، نیویورک (موفقیت ۱۰/۱۰). ۶۳ استفاده از ابزار، ۷۰ فراخوانی مدل، ۳۴۷ ثانیه زمان اجرا، ۱۰۸ هزار توکن در پایان کانتکست، ۵.۳۸ میلیون توکن پردازش شده و ۷۸۱ هزار توکن وزنی.
• اجرای سوم: ۱۰ مکان در یونیون اسکوئر، سان‌فرانسیسکو (موفقیت ۱۰/۱۰). ۵۸ استفاده از ابزار، ۶۷ فراخوانی مدل، ۲۹۰ ثانیه زمان اجرا، ۷۷ هزار توکن در پایان کانتکست، ۳.۶۴ میلیون توکن پردازش شده و ۵۰۷ هزار توکن وزنی.
• اجرای چهارم: ۳۰ مکان در میلنیوم پارک، شیکاگو (موفقیت ۳۰/۳۰). ۷۴ استفاده از ابزار، ۸۶ فراخوانی مدل، ۶۸۰ ثانیه زمان اجرا، ۱۲۳ هزار توکن در پایان کانتکست، ۵.۶۷ میلیون توکن پردازش شده و ۸۰۴ هزار توکن وزنی.

با این حال، هزینه منابع بسیار سنگین بود. عامل برای هر مکان بین ۱۹۰,۰۰۰ تا ۵۴۰,۰۰۰ توکن پردازش کرد. زمان اجرای هر رکورد به‌طور متوسط بین ۲۳ تا ۳۵ ثانیه بود. نکته تکان‌دهنده این است که حتی پیش از باز کردن صفحه، حدود ۳۱ هزار توکن صرف پرامپت‌های سیستمی و تعریف ابزارها می‌شود.

تحلیل هزینه‌ها و نقاط شکست

هزینه به‌ازای هر مکان ثابت نیست. در اجرای اول، هزینه هر مورد حدود ۲۹ ثانیه زمان، ۲۹۳ هزار توکن پردازش شده و ۴۹ هزار توکن وزنی بود. در اجرای چهارم که ۳ برابر مکان‌های بیشتری را مدیریت کرد، هزینه به حدود ۲۳ ثانیه زمان، ۱۸۹ هزار توکن پردازش شده و ۲۷ هزار توکن وزنی کاهش یافت. این ارزان‌ترین اجرا به‌ازای هر رکورد بود.

این کاهش هزینه به دلیل بهره‌وری کلی نبود، بلکه عامل استراتژی خود را تغییر داد: به‌جای استفاده از ابزارهای عمومی "find" و "get page text" برای هر صفحه، یک فراخوانی جاوااسکریپت در هر صفحه اجرا کرد تا مقادیر را مستقیماً از ویژگی‌های aria-label استخراج کند.

تکرارپذیری نیز نوسان داشت. اجراهای ۱ و ۲ مکان‌های یکسانی را هدف قرار دادند. در اجرای دوم، زمان اجرا ۱۹٪ و توکن‌های وزنی ۵۹٪ افزایش یافت. دلیل اصلی این بود که در اجرای دوم، فید نتایج متوقف شد (یک اسپینر روی ۶ مورد بارگذاری شده گیر کرد) و عامل مجبور شد صفحه را دوباره بارگذاری کرده و یک اسکرول برنامه‌ریزی شده را برای بازیابی اجرا کند.

در مقابل، اسکریپت Playwright که توسط یک کارگر Sonnet نوشته شده بود، به‌طور قابل‌توجهی سریع‌تر بود. این اسکریپت بر اساس یک مشخصات یک‌پاراگرافی نوشته شد و تنها یک بار برای اصلاح شرط انتظار (wait condition) تعداد نظرات نیاز به ویرایش داشت. سرعت آن ۶.۱ تا ۱۴ ثانیه برای هر URL بود و پس از استقرار، هیچ توکنی مصرف نکرد. دقت کنید که اسکریپت فقط صفحاتی را باز کرد که URL آن‌ها قبلاً توسط عامل پیدا شده بود و عملیات جست‌وجوی اولیه را انجام نداد.

اما اسکریپت شکننده بود. در ۲۸ مورد از ۵۰ ردیف، نتوانست تعداد نظرات را استخراج کند زیرا این مقادیر از طریق یک ویجت ناهمگام (Asynchronous) بارگذاری می‌شدند که اسکریپت نمی‌توانست به‌طور قابل‌اعتمادی منتظر آن بماند:

• نیویورک (۱۰ یو‌آرال): ۶ مورد نظرات خالی، ۰ شکست کلی.
• سان‌فرانسیسکو (۱۰ یو‌آرال): ۷ مورد نظرات خالی، ۰ شکست کلی.
• شیکاگو (۳۰ یو‌آرال): ۱۵ مورد نظرات خالی، ۱ شکست کلی.

یک رکورد در شیکاگو به‌طور کامل شکست خورد زیرا هدر H1 صفحه در زمان تعیین شده ظاهر نشد و باعث Timeout در Playwright شد. عامل هوش مصنوعی این سناریوها را به‌راحتی مدیریت کرد و در صورت خالی بودن صفحه اصلی، به فید نتایج جست‌وجو بازگشت.

تخریب عملکرد اسکریپت و بهای کانتکست

زمان به‌ازای هر URL برای اسکریپت در دسته ۳۰تایی شیکاگو افزایش یافت. هفت ردیف از این ۳۰ ردیف، هر کدام ۳۲ تا ۳۶ ثانیه زمان بردند. این‌ها دقیقاً همان ردیف‌هایی بودند که تعداد نظرات خالی برگردانده بودند. سایر ردیف‌ها تنها ۲ تا ۷ ثانیه زمان بردند. در دسته سان‌فرانسیسکو نیز یک ردیف ۳۲ ثانیه زمان برد. این الگو نشان‌دهنده احتمال محدود کردن دسترسی (Throttling) یا شناسایی ربات در اجراهای طولانی در یک مرورگر است.

یکی از خیره‌کننده‌ترین یافته‌ها، نحوه مقیاس‌بندی هزینه‌ها در یک اجرای واحد بود. در دسته ۳۰ موردی شیکاگو، یک‌سوم پایانی اجرا ۲.۵ برابر گران‌تر از یک‌سوم اول بود. تقسیم فراخوانی‌ها به سه بخش، رشد کانتکست را به ترتیب ۱.۱۵ میلیون، ۱.۶۴ میلیون و ۲.۸۸ میلیون توکن نشان داد. این اتفاق به دلیل گسترش پنجره متنی (Context Window) رخ می‌دهد؛ هر درخواست جدید مستلزم آن است که مدل کل تاریخچه جلسه را دوباره بخواند و این باعث تورم خطی مصرف توکن می‌شود.

راهکار ترکیبی: بهینه‌ترین مسیر

برای یافتن نقطه تعادل، یک رویکرد ترکیبی آزمایش شد: استفاده از اسکریپت برای حجم اصلی کار و استفاده از عامل فقط برای پر کردن شکاف‌ها. این شامل استفاده از عامل برای ۲۹ ردیفی بود که اسکریپت از دست داده بود (۲۸ مورد نظرات خالی و ۱ شکست سخت، به‌علاوه ۲ ردیف که در پاس اول گم شده بودند).

مقایسه رویکردها برای ۵۰ مکان:

• فقط عامل (اجراهای ۱، ۳، ۴): ۲۰۷ فراخوانی مدل، ۱,۲۶۲ ثانیه زمان، ۱۲.۲۴ میلیون توکن پردازش شده، ۱,۸۰۳ هزار توکن وزنی.
• ترکیب اسکریپت و عامل برای ردیف‌های شکاف: ۳۴ فراخوانی مدل، ۱,۰۸۸ ثانیه زمان، ۲.۸۸ میلیون توکن پردازش شده، ۵۱۹ هزار توکن وزنی.

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

دو عامل باعث برتری روش ترکیبی شد: اول اینکه اسکریپت عملیات کشف لیست را انجام نداد، و دوم اینکه عاملِ پرکننده شکاف از فراخوانی‌های دسته‌ای (Batch) استفاده کرد (۲۳ فراخوانی برای ۲۷ ردیف اول) به‌جای ۸۶ فراخوانی که عامل در اجرای چهارم برای ۳۰ ردیف استفاده کرده بود.

دقت و انحراف داده‌ها

بررسی ۳۰۰ فیلد (۶۰ ردیف در ۵ فیلد) نشان داد که هیچ عدم تطابق واقعی در مقادیر استخراج شده توسط عامل وجود ندارد. هر مقدار توسط اسکریپت یا یک خوانش دوم مرورگر (با استفاده از جاوااسکریپت روی ویجت امتیاز و دکمه‌های آدرس و تلفن) تأیید شد.

دو مشاهده خاص ثبت شد:
۱. ویرایش‌های خاموش: آدرس یک فروشگاه به صورت "10036 326 W 47th St, New York, NY 10036" ظاهر شد. اجرای اول آن را عیناً کپی کرد، اما اجرای دوم به‌طور خاموش کد پستی ابتدایی را حذف کرد. اگرچه این یک پاک‌سازی منطقی بود، اما یک ویرایش ثبت‌نشده در داده‌های منبع محسوب می‌شد.
۲. تغییرات زنده: تعداد نظرات یک مورد بین اجرای عامل و بازبینی نهایی از ۳۵۶۳ به ۳۵۶۴ افزایش یافت که تأیید می‌کند عامل داده‌ها را به‌طور دقیق و زنده می‌خواند.

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

خلاصه تضادها (Trade-offs)

• سرعت: اسکریپت‌ها ۱.۶ تا ۵.۷ برابر سریع‌تر هستند (۶.۱-۱۴ ثانیه در مقابل ۲۳-۳۵ ثانیه به‌ازای هر URL).
• هزینه: اسکریپت‌ها صفر توکن مصرف می‌کنند؛ عامل‌ها صدها هزار توکن پردازش می‌کنند.
• قابلیت اطمینان: عامل‌ها محتوای ناهمگام و تغییرات ساختاری را مدیریت می‌کنند؛ اسکریپت‌ها در وضعیت‌های غیرمنتظره (مانند Timeout هدر H1) می‌شکنند.
• توسعه: عامل‌ها نیاز به هیچ تنظیماتی ندارند؛ اسکریپت‌ها نیاز به مشخصات فنی و تکرار برای اصلاح دارند.

بهینه‌سازی بر اساس دستورالعمل (Recipe)

برای کاهش بیشتر هزینه‌ها، یک رویکرد "دستور پخت" برای اجرای ۳۰تایی شیکاگو تست شد. به‌جای اینکه عامل روش خود را انتخاب کند، از یک دستورالعمل انسانی پیروی کرد: اسکرول لیست با رویدادهای واقعی چرخ موس، استخراج تمام کارت‌ها در یک فراخوانی JS، و استفاده از فراخوانی‌های دسته‌ای برای ناوبری و خواندن aria-label.

مقایسه روش خودِ عامل (اجرای ۴) با روش دستور پخت (اجرای 5b):

• فراخوانی‌های مدل: از ۸۶ به ۴۱ کاهش یافت (۵۲٪ کاهش).
• توکن‌های پردازش شده: از ۵.۶۷ میلیون به ۲.۲۶ میلیون کاهش یافت (۶۰٪ کاهش).
• توکن‌های وزنی: از ۸۰۴ هزار به ۶۲۳ هزار کاهش یافت (۲۳٪ کاهش).
• زمان اجرا: از ۶۸۰ ثانیه به ۵۱۲ ثانیه کاهش یافت.
• پایان کانتکست: از ۱۲۳ هزار به ۹۲ هزار کاهش یافت.

این نشان می‌دهد که اگرچه دسته‌بندی (Batching) فراخوانی‌ها را کاهش می‌دهد، اما خروجی‌ها و نوشتن در حافظه پنهان (Cache) همچنان یک کف هزینه قابل توجه ایجاد می‌کنند. در این اجرا، دو دسته اسکرول هدر رفت زیرا مختصات اسکرول پنل لیست را گم کرد و نیاز به یک اسکرین‌شات کوچک برای تشخیص مشکل بود.

محدودیت‌ها و دامنه تست

این تست یک اندازه‌گیری شخصی بود، نه یک پروژه تولیدی. چندین عامل تست نشدند:

• مقیاس: تنها ۶۰ مکان در ۳ شهر آمریکا در یک سایت تست شد. هیچ حوزه یا کشور دیگری (مانند تست قبلی در شیبویا که حذف شد) گنجانده نشد.
• کشف: هزینه اسکریپت برای کشف لیست اندازه‌گیری نشد؛ اسکریپت فقط URLهای شناخته شده را بازخوانی کرد.
• محدودیت دسترسی: کند شدن به‌ازای هر URL در دسته ۳۰تایی مشاهده شد اما ایزوله و تحلیل نشد.
• مالیات: اعداد وزنی یک معیار داخلی هستند (ورودی ۱ برابر، خواندن کش ۰.۱، نوشتن کش ۲، خروجی ۵) و هزینه‌های دلاری واقعی نیستند.

این داده‌ها نشان می‌دهد که برای کارهای تکراری و با حجم بالا، عامل "بدون کد" در حال حاضر یک کالای لوکس است. بهینه‌ترین مسیر این است که از عامل‌ها برای تولید اسکرپر اولیه استفاده کنید و سپس از آن‌ها به‌عنوان یک "تیم پاک‌سازی" گران‌قیمت برای موارد خاصی (Edge Cases) استفاده کنید که کد قادر به مدیریت آن‌ها نیست.

گام بعدی شما

• اگر حجم داده‌های شما بالاست، از عامل‌های هوش مصنوعی برای نوشتن اسکریپت‌های Playwright یا Selenium استفاده کنید، نه برای اجرای مستقیم استخراج.
• برای مواردی که ساختار سایت مدام تغییر می‌کند، یک سیستم «پاک‌سازی» (Cleanup) با عامل‌های هوش مصنوعی طراحی کنید که فقط رکوردهای ناقص اسکریپت را اصلاح کنند.
• در طراحی عامل‌ها، از متدهای Batching برای کاهش تعداد فراخوانی‌های مدل و جلوگیری از تورم پنجره متنی استفاده کنید.

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