اگر برای جمع‌آوری داده‌های مستندات فنی از مرورگرهای بدون رابط (Headless Browsers) استفاده می‌کنید، احتمالاً منابع سخت‌افزاری خود را بیهوده می‌سوزانید. بسیاری از مهندسان با پیچیده کردن مسیر استخراج داده، به جای یک درخواست ساده، کل یک مرورگر را شبیه‌سازی می‌کنند که منجر به ایجاد سقف‌های حافظه و خطاهای پیش‌بینی‌نشده (Flaky Failures) می‌شود.
به نقل از یک توسعه‌دهنده در RoamProxy در گزارشی که در ۱۱ اوت ۲۰۲۶ منتشر شد، استفاده از ابزارهای سنگین اتوماسیون برای سایت‌هایی که ساختار استاتیک دارند، یک اشتباه رایج است. این رویکرد در حالی مطرح می‌شود که توسعه‌دهندگان برای ساخت خط لوله‌های تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — به حجم زیادی از متن‌های پاک و با کیفیت نیاز دارند. در این راستا، ابزارهایی مانند Scrapeless تلاش می‌کنند تا ردیابی منابع هوش مصنوعی را از اسکرین‌شات‌های ساده به داده‌های ساختاریافته تبدیل کنند تا دقت پاسخ‌دهی مدل‌ها افزایش یابد.
در حالی که ما پیش‌تر بررسی کردیم که چگونه ابزاری مانند PhishVision از رندرینگ مرورگر برای شناسایی تزریق دستورات (Prompt Injection) استفاده می‌کند، باید توجه داشت که آن مورد خاص بر تحلیل امنیتی رفتارهای پویا متمرکز است. اما استخراج متن برای یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — مسئله‌ای کاملاً متفاوت است. در اینجا هدف، دریافت محتوای خام است، نه تحلیل وضعیت اجرای کدها در مرورگر. این تغییر رویکرد در استخراج داده، در واقع بخشی از روند گسترده‌تری است که در آن هوش مصنوعی زاینده، استخراج داده را از وابستگی شدید به ساختار HTML نجات داده است و انعطاف‌پذیری سیستم‌ها را در برابر تغییرات سایت‌ها افزایش داده است.
ریشه‌ی مشکل در توهمِ رندرینگ
بسیاری از توسعه‌دهندگان به اشتباه با نگاه به پنل Elements در ابزار DevTools، درباره‌ی نحوه رندر شدن یک سایت قضاوت می‌کنند. این پنل در واقع حالت نهایی DOM یا همان وضعیت «هیدراته شده» (Hydrated) را نشان می‌دهد — یعنی حالتی که پس از اجرای کامل جاوااسکریپت شکل گرفته است — و نه آنچه سرور در ابتدا به عنوان پاسخ ارسال کرده است.
از آنجا که سایت‌های مستندات، اپلیکیشن‌های وب دلخواه و پیچیده نیستند، بلکه عمدتاً توسط تعداد محدودی از «تولیدکننده‌های سایت استاتیک» (Static Site Generators) ساخته می‌شوند، محتوا در مکان‌های قابل پیش‌بینی قرار دارد. این بدان معناست که رندرینگ جاوااسکریپتی که در مرورگر مشاهده می‌کنید، اغلب تنها برای بهبود جست‌وجو و ناوبری است و محتوای اصلی از قبل در HTML وجود دارد.
طبق مستندات RoamProxy، سه مسیر اصلی برای دور زدن رندرینگ مرورگر وجود دارد:
مسیر اول: HTML استاتیک و داده‌های JSON
بسیاری از پورتال‌های مدرن، داده‌ها را مستقیماً در پاسخ اولیه (Initial Response) قرار می‌دهند.
- سایت‌های Next.js اغلب کل محتوای صفحه را در یک تگ اسکریپت با شناسه
__NEXT_DATA__ذخیره می‌کنند. توسعه‌دهندگان می‌توانند با استفاده از ابزارhttpxو یک جست‌وجوی Regex برای عبارت<script id="__NEXT_DATA__" type="application/json">(.*?)</script>، این داده‌ها را به‌صورت JSON استخراج کنند، بدون آنکه نیازی به اجرای جاوااسکریپت باشد. - Docusaurus متن مقالات را به صورت پیش‌فرض به HTML استاتیک تبدیل (Pre-render) می‌کند. بنابراین یک درخواست ساده
httpx.getبه همراه یک انتخاب‌گر (Selector) برای تگ main یا article، معمولاً برای استخراج تمام متون کافی است. - تست ۳۰ ثانیه‌ای: توسعه‌دهندگان می‌توانند این موضوع را با اجرای دستور
curl -s <url> | grep -c "some sentence you can see on the page"تأیید کنند. اگر نتیجه عدد ۱ یا بیشتر بود، یعنی محتوا در HTML اولیه وجود دارد و هیچ نیازی به مرورگر نیست.
مسیر دوم: مخازن عمومی Markdown
در پروژه‌های متن‌باز، پاک‌ترین و خالص‌ترین داده‌ها در سورس‌کد پروژه و معمولاً در پوشه‌ی docs/ قرار دارند.
- کلونینگ پراکنده (Sparse Cloning): با استفاده از دستوری مانند
git clone --depth 1 --filter=blob:none --sparseو سپس اجرایgit sparse-checkout set docsمی‌توان فایل‌های اصلی Markdown را تنها در یک درخواست دریافت کرد. - کیفیت داده: این روش باعث می‌شود تیترها و بلوک‌های کد (Code Fences) دست‌نخورده باقی بمانند. همچنین نیاز به حذف اجزای مزاحم مانند منوهای ناوبری، بنرهای کوکی یا مدیریت محدودیت‌های نرخ درخواست (Rate Limits) در هر صفحه را از بین می‌برد.
- نکته حقوقی: RoamProxy هشدار می‌دهد که پیش از وارد کردن داده‌ها، لایسنس را بررسی کنید؛ زیرا مستندات اغلب لایسنسی متفاوت از کد اصلی پروژه دارند.
مسیر سوم: نقاط انتهایی متنی اختصاصی
یک استاندارد نوظهور به نام /llms.txt در حال شکل‌گیری است که نقشه‌ای متنی، ساده و سازمان‌یافته از سایت را مخصوص مصرف مدل‌های هوش مصنوعی ارائه می‌دهد. شرکت‌های پیشرو در ابزارهای توسعه، به سرعت این استاندارد را پذیرفته‌اند.
- نقشه‌های سایت: بررسی فایل
/sitemap.xmlلیست کامل URLها را فراهم می‌کند و نیاز به خزش (Crawl) یا کشف صفحات از طریق دنبال کردن لینک‌ها را از بین می‌برد. - آرشیوهای یکپارچه: سرویس‌هایی مثل ReadTheDocs و GitBook اغلب از طریق منوی نسخه‌ها، امکان دانلود کل مستندات را در قالب‌های HTML، PDF یا ePub فراهم می‌کنند.
انتخاب این مسیرها، شکل بنیادی پروژه را تغییر می‌دهد؛ شما از یک خط لوله‌ی پیچیده که به باینری‌های سنگین مرورگر نیاز دارد، به یک اسکریپت سبک تبدیل می‌شوید که اغلب پیش از آنکه یک مرورگر بدون رابط حتی لود شود، کارش را تمام می‌کند.
چه زمانی مرورگر اجباری است؟
البته برخی موارد واقعاً پویا هستند و به مرورگر نیاز دارند:
- مستنداتی که پشت احراز هویت هستند و نشست‌ها (Sessions) توسط جاوااسکریپت در سمت کلاینت ایجاد می‌شوند.
- اکسپلوررهای API تعاملی که محتوا را در لحظه اجرا از چندین فراخوانی API مختلف جمع‌آوری می‌کنند.
- سایت‌هایی که محتوا را پشت چالش‌های جاوااسکریپتی (مانند سیستم‌های ضد بات) پنهان کرده‌اند. در مواجهه با این سدها، استراتژی‌هایی مانند رویکرد ارتقای تدریجی HatFetch برای دور زدن سیستم‌های شناسایی ربات می‌تواند راهگشا باشد تا دسترسی به داده‌های پویا حفظ شود.
برای یک توسعه‌دهنده عمل‌گرا، این رویکرد به معنای کاهش هزینه‌های زیرساخت و افزایش پایداری است. اگر امروز در حال ساخت خط لوله‌ی داده هستید، ابتدا به دنبال فایل /llms.txt یا پوشه‌ی docs/ در گیت‌هاب بگردید. مرورگر باید آخرین راهکار شما باشد، نه اولین ابزار.
گام بعدی شما
- برای تمام منابع داده‌ای خود، ابتدا وجود فایل
/llms.txtرا بررسی کنید. - در پروژه‌های متن‌باز، به جای Scraping، از Sparse Checkout در Git برای دریافت فایل‌های Markdown استفاده کنید.
- با دستور
curlساده، میزان حضور محتوا در HTML اولیه را بسنجید تا از اجرای بی‌مورد مرورگرها جلوگیری کنید.
اما بهینه‌سازی استخراج داده تنها نیمی از مسیر است؛ مدیریت این حجم از داده در پایگاه‌های داده برداری را در تحلیل بعدی بررسی خواهیم کرد.
گفتگو