«حذف ارجاعات اشتباه»؛ استراتژی AIdeazz برای بهینه‌سازی موتورهای زاینده

اگر یک مدل زبانی ادعایی را به نام شما نسبت دهد اما جزئیات حیاتی آن را حذف کند، اعتبار فنی شما در چشم مشتریان احتمالی نابود می‌شود. این دقیقاً همان چالشی بود که النا رِویچِوا (Elena Revicheva)، بنیان‌گذار AIdeazz، با آن مواجه شد تا متوجه شود قواعد قدیمی سئو در عصر موتورهای پاسخ‌گو دیگر کار نمی‌کنند. او با جزئیات شرح داد که چگونه یک وظیفه بازاریابی ساده به یک مسئله مدل‌سازی داده تبدیل شد.

به گزارش AIdeazz، مشکل زمانی شروع شد که Perplexity در پاسخ‌های خود، سه بار به صفحات او ارجاع داده بود، اما رِویچِوا متوجه شد که این ارجاعات حاوی خطا هستند. در یک مورد، مدل یک الگوی مسیریابی چند-عاملی (multi-agent routing pattern) را به عنوان یک موفقیت برای AIdeazz معرفی کرد، در حالی که او در پست اصلی خود صراحتاً آن را یک شکست توصیف کرده بود. مدل تنها جمله مربوط به «راهکار» یا دور زدن مشکل را استخراج کرده و عبارت حیاتی «این روش در محیط عملیاتی شکست خورد» (this broke in production) را نادیده گرفته بود.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی توهمات مدل‌های زبانی اشاره کردیم، مشکل در اینجا نه لزوماً توهم، بلکه «فشرده‌سازی مخرب» است. این نوع خطاها در استخراج داده‌ها می‌تواند پیامدهای حقوقی جدی داشته باشد؛ چنان‌که دادگاه مونیخ اخیراً گوگل را به دلیل ارائه اطلاعات نادرست در مرورهای هوش مصنوعی مسئول شناخته است. در بهینه‌سازی موتورهای زاینده (GEO) — که اساساً با سئو متفاوت است زیرا برای ماشینی بهینه می‌شود که داده‌ها را برای کاربر خلاصه می‌کند — هدف دیگر رتبه اول در یک لیست از لینک‌ها نیست، بلکه بقای نام شما در سنتز نهایی ماشین است. در جست‌وجوی سنتی، کاربر استخراج و سنتز را انجام می‌دهد، اما در یک موتور زاینده، این هوش مصنوعی است که تصمیم می‌گیرد آیا نام شما در فرآیند فشرده‌سازی باقی می‌ماند یا خیر. طبق گزارش AIdeazz، واحد موفقیت از «جایگاه رتبه» (rank position) به این تغییر یافته است که «آیا مدل یک منبع را درست نقل‌قول کرده و به درستی به آن نسبت داده است یا خیر». این امر نیازمند ورودی‌های متفاوتی است؛ زیرا یک موتور جستجو صفحه را ایندکس و رتبه‌بندی می‌کند، اما یک موتور زاینده تکه‌هایی (chunks) را بازیابی کرده، آن‌ها را به یک LLM می‌دهد و پاراگرافی می‌نویسد که ممکن است نام منبع را ذکر کند یا نکند.

تکه‌بندی (Chunking) — یعنی بریدن متن به قطعات کوچک، شبیه به تکه‌تکه کردن یک کیک بلند برای بلع راحت‌تر — ریشه این خطاهای ارجاع است. رِویچِوا شناسایی کرد که موتورهای زاینده متن را در قطعاتی، معمولاً بین ۲۰۰ تا ۸۰۰ توکن (Token)، بازیابی می‌کنند. این فرآیند تکه‌بندی اغلب بافت (context) را نابود می‌کند. اگر یک ادعا و شرط یا تعدیل‌کننده آن در تکه‌های مختلف قرار داشته باشند، مدل ممکن است یکی را بدون دیگری بازیابی کند. برای مثال، ادعایی مانند «ما تماس‌های حساس به تأخیر را به Groq مسیریابی می‌کنیم» ممکن است به عنوان یک تکه تمیز باقی بماند، در حالی که عبارت «...اما این باعث عدم همگام‌سازی وضعیت شد و بعداً آن را بازگرداندیم» در تکه‌ای دیگر در ۶۰۰ توکن فاصله قرار می‌گیرد. نتیجه این است که پاسخ نهایی AI، یک شکست را به عنوان یک قابلیت (feature) معرفی می‌کند.

برای حل این بحران، او استراتژی‌ای متمرکز بر سه ستون پیاده کرد: نویسندگی ساختارمند (structured authorship)، مالکیت بادوام (durable ownership) و دقت در سطح تکه (chunk-level precision). او متوجه شد که Perplexity، جست‌وجوی ChatGPT و Claude با دسترسی به وب، ترجیح می‌دهند جملات فکتی (fact-based) مجزا را که به منابع روشن متصل هستند، نقل‌قول کنند. نثرهای مبهم که فکت قابل استخراج ندارند، معمولاً خلاصه می‌شوند اما نسبت داده نمی‌شوند، که منجر به نبود لینک، نبود ارجاع و نبود سیگنال اعتبار می‌شود.

او چارچوبی فنی و سخت‌گیرانه را روی سایت خود که بر بستر Oracle Cloud با یک استک چند-عاملی و بدون هیچ توزیع پولی اجرا می‌شود، پیاده کرد:

• ادعاهای خودبسنده (Self-Contained Claims): هر ادعای محوری به‌گونه‌ای بازنویسی شد که در سطح یک تکه (Chunk) کامل و مستقل باشد. هر ادعا، شرط یا تعدیل‌کننده خود را در همان جمله یا جمله بلافاصله بعد از آن حمل می‌کند. مثلاً به جای «ما برای سرعت از Groq استفاده می‌کنیم»، از داده‌های دقیق استفاده کرد: «ما تماس‌های عامل تلگرام با SLA زیر ۲ ثانیه را به Llama 3.3 70B در Groq می‌فرستیم؛ تماس‌های نیازمند قابلیت استفاده از ابزار (tool-use reliability) به Claude Sonnet می‌روند و تأخیر ۱.۸ ثانیه‌ای اضافه را می‌پذیرند».
• داده‌های درون‌متنی در مقابل نمودارها: اعداد مستقیماً در متن قرار گرفتند. او کشف کرد که نمودارها برای یک تکه‌بند متن (text chunker) اساساً نامرئی هستند و همین موضوع، اعداد درون‌متنی را برای بازیابی حیاتی می‌کند.
• اسکیمای JSON-LD: او ساختارهای FAQPage و TechArticle را به صورت JSON-LD اضافه کرد تا متن واقعی ادعاها در فیلدهای schema.org منعکس شود. این لایه ساختارمند، نثر متن را تقویت می‌کند. به‌طور مشخص برای صفحات عامل‌ها، او از اسکیمایی با جزئیات زیر استفاده کرد:
  • @context: "https://schema.org"
  • @type: "TechArticle"
  • headline: "Routing LLM calls across Groq and Claude in a multi-agent system"
  • author: یک شیء شخص برای Elena Revicheva متصل به https://aideazz.xyz/portfolio
  • knowsAbout: ["multi-agent systems", "LLM routing", "Oracle Cloud Infrastructure"]
  • datePublished: "2024-11-02"
  • dateModified: "2025-01-14"
  • about: "LLM provider routing under latency constraints"
  • citation: "Production deployment on Oracle Cloud Free Tier ARM instances"
• رندر سمت سرور (SSR): محتوا از React (که در سمت کاربر رندر می‌شد) به HTML (رندر سمت سرور) منتقل شد. کراولرهای AI پیش از این فقط یک پوسته خالی در صفحات رندر شده در سمت کاربر می‌دیدند. این تغییر که در یک پنجره زمانی چهار ساعته روی نمونه‌های ARM رایگان اوراکل اعمال شد، تعداد صفحاتی که در ارجاعات مبتنی بر بازیابی ظاهر می‌شدند را تقریباً دو برابر کرد.
• دسترسی robots.txt: برای اینکه محتوا قابل نقل‌قول باشد، باید قابل کراول باشد. او صراحتاً اجازه دسترسی PerplexityBot، GPTBot، ClaudeBot و Google-Extended را در فایل robots.txt داد. قطعه کد مورد استفاده عبارت بود از:
  User-agent: PerplexityBot Allow: /
User-agent: GPTBot Allow: /
User-agent: ClaudeBot Allow: /
User-agent: Google-Extended Allow: /
  او ریسک این موضوع که OpenAI ممکن است بدون ذکر منبع روی این محتوا آموزش ببیند را پذیرفت، زیرا معتقد است مزیت نقل‌قول‌ها بیشتر از نشت داده‌های آموزشی است؛ چرا که مزیت رقابتی (moat) او عامل‌های در حال اجراست، نه متن‌ها.

یکی دیگر از نقاط کلیدی، حل شکاف نویسندگی (Authorship Gap) بود. بسیاری از بنیان‌گذاران فنی در پلتفرم‌هایی که کنترل ندارند، مانند Medium، Substack یا dev.to منتشر می‌کنند. وقتی ارجاعات در این پلتفرم‌ها رخ می‌دهد، اعتبار به پلتفرم می‌رسد، نه به سازنده. رِویچِوا با انتقال نسخه کانونی (canonical) هر پست فنی به دامنه aideazz.xyz و باقی گذاشتن لینک‌های راهنما در پلتفرم‌های دیگر با تگ rel="canonical" که به دامنه او اشاره می‌کرد، حضور خود را تثبیت کرد. پس از دو ماه، ارجاعات Perplexity از «medium.com/@...» به دامنه شخصی او تغییر یافت.

او همچنین با استفاده از ویژگی sameAs در اسکیمای Person، پروفایل خود را به گیت‌هاب، لینکدین و عامل‌های زنده متصل کرد. او لینک‌های دوجانبه بین پروفایل نویسنده و مصنوعات دنیای واقعی (مانند بات تلگرام و عامل واتس‌اپ که کاربران می‌توانند به آن‌ها پیام دهند) ایجاد کرد. این کار به موتورها اجازه می‌دهد هویت «النای سازندهٔ عامل‌ها» را شناسایی کرده و او را از دیگران تفکیک کنند. این هم‌مکانیِ «ادعا» و «مدرک» — حتی با وجود اینکه یک LLM نمی‌تواند خودش به بات پیام دهد — احتمال اینکه نسخه او نقل‌قول شود را افزایش می‌دهد. او تأکید می‌کند که برای یک سازنده، داشتن نرم‌افزاری در حال اجرا که نام او روی آن باشد، قوی‌ترین دارایی GEO موجود است.

در بحث مالکیت بادوام و زیرساخت، رِویچِوا با توصیه رایج «همه‌جا باشید» مخالف است. در عوض، پیشنهاد می‌کند فقط با «اشاره‌گرها» (pointers) همه‌جا باشید اما در دامنه‌هایی که مالک آن‌ها هستید، نسخه کانونی را نگه دارید. این موضوع حیاتی است زیرا موتورهای زاینده مکرراً دوباره کراول و رتبه‌بندی می‌کنند. ادعایی که امروز نقل‌قول شده ممکن است اگر پلتفرم میزبان سیاست robots خود را تغییر دهد یا صفحات تگ را بازسازماندهی کند، ناپدید شود. او شاهد بود که پستی در dev.to که شش هفته توسط Perplexity نقل‌قول شده بود، ناگهان پس از تغییر صفحات تگ توسط پلتفرم، دیگر ظاهر نشد؛ چون او کنترل ساختار URL را نداشت، نتوانست آن را اصلاح کند.

با کنترل دامنه aideazz.xyz، او موارد زیر را حفظ می‌کند:

• ماندگاری URL: آدرس یک ادعا هرگز تغییر نمی‌کند. هنگام بروز به‌روزرسانی‌ها، او فیلد dateModified را تغییر می‌دهد نه مسیر URL را.
• کنترل کراول: او اختیار مستقیم دارد که کدام ربات‌های AI وارد شوند و محتوا را چگونه ببینند.
• پایداری زیرساخت: استفاده از نمونه‌های ARM رایگان اوراکل به او اجازه داد تا سریعاً به HTML رندر شده در سرور منتقل شود و مطمئن شود کراولرهای AI با پوسته‌های خالی React مواجه نمی‌شوند.

بر اساس بررسی نتایج پس از چهار ماه، که از طریق لاگ‌های ارجاع و بررسی‌های دستی سنجیده شد، رِویچِوا اثرگذاری تغییرات را به این ترتیب رتبه‌بندی کرد:

۱. بیشترین اثر: ادعاهای فکتی خودبسنده با اعداد درون‌متنی. این بزرگترین اثر منفرد بود و مشکل نسبت دادن غلط (misattribution) را eliminated کرد.
۲. اثر زیاد: تجمیع کانونی در دامنه شخصی. او هشدار می‌دهد که اگر این مرحله نادیده گرفته شود، جبران آن دشوار است و باید زود انجام شود.
۳. اثر متوسط: محتوای رندر شده در سرور همراه با باز کردن دسترسی ربات‌های AI. این تغییر، صفحات نامرئی را صرفاً با تغییرات زیرساختی، مرئی کرد.
۴. اثر کمتر: داده‌های ساختاریافته JSON-LD و لینک‌های دوجانبه نویسنده-به-مصنوع. JSON-LD نتایج قابل اندازه‌گیری برای Google AI Overviews در Search Console طی پنج هفته نشان داد، در حالی که لینک‌های نویسنده اثری کند اما تجمعی در طول هفته‌ها داشتند.

او صراحتاً اشاره کرد که صفحات طولانی و «جامع» عملکرد ضعیفی داشتند. یک صفحه ۹۰۰ کلمه‌ای با ۵ ادعای تمیز و قابل استخراج، بیشتر از یک مقاله ۴۰۰۰ کلمه‌ای پر از «حاشیه و مقدمات طولانی» ارجاع گرفت. موتورهای زاینده به «دقت قابل استخراج» پاداش می‌دهند، نه به تراکم کلمات کلیدی یا تعداد دفعات پست گذاشتن.

در مورد محدودیت‌های صادقانه و اعتبارسنجی، رِویچِوا اذعان می‌کند که این داده‌ها بیشتر «جهت‌نما» هستند تا «قطعی». چون موتورهایی مثل Perplexity ابزاری شبیه Search Console ندارند، او به لاگ‌های ارجاع و بررسی‌های دستی متکی است. او هشدار می‌دهد که هرگونه «امتیاز GEO» (GEO score) که توسط فروشندگان عرضه می‌شود، احتمالاً عددی ساختگی است. علاوه بر این، رفتارهای بازیابی و رتبه‌بندی بدون اطلاع قبلی تغییر می‌کنند، به این معنی که تاکتیک‌های خاص ممکن است مصرفی و موقتی باشند، در حالی که اصول — مالکیت دامنه، بیان تمیز فکت‌ها، اثبات نویسندگی و قابل کراول بودن — بادوام می‌مانند.

برای تأیید اینکه آیا محتوا «آماده تکه‌بندی» (chunk-ready) است، رِویچِوا یک تست اعتبارسنجی ساده پیشنهاد می‌کند: هر برش ۳۰۰ کلمه‌ای از صفحه را در یک LLM تازه (بدون بافت دیگر) قرار دهید و از آن بخواهید ادعا و شرط/تعدیل‌کننده آن را بیان کند. اگر مدل نتواند تعدیل‌کننده را تنها از روی آن برش بازسازی کند، یعنی بافت در تکه‌ها تقسیم شده است و بازیابی احتمالاً آن را گم خواهد کرد. این رویکرد برای مدیریت داده‌های متناقض مشابه با الگوی رجیستری SAGE است که برای حل تضادها در داده‌های تاریخی طراحی شد. او این بررسی را روی هر پاراگراف محوری انجام می‌دهد تا از تکرار تجربه اولیه نسبت دادن غلط جلوگیری کند.

برای توسعه‌دهندگان و ابزارهای B2B، این موضوع حتی در مقیاس کوچک نیز اهمیت دارد. در حالی که یک ابزار B2B ممکن است تنها ۵۰ خریدار بالقوه داشته باشد، اما آن خریدارانی که از Perplexity برای تحقیق درباره تامین‌کنندگان استفاده می‌کنند، خواهند دید که آیا AI نام آن ابزار را می‌برد یا رقیب را. از آنجایی که کارهای فنی — اسکما، رندر سرور و ادعاهای تمیز — نسبتاً ارزان هستند، آستانه «ارزش داشتن» این کار پایین است. برای توسعه‌دهندگان، مزیت رقابتی دیگر خودِ متن نیست، بلکه نرم‌افزاری است که متن به آن اشاره می‌کند. با ماشین‌خوان کردن پیوند بین «ادعا» و «مدرک»، سازندگان می‌توانند اعتبار خود را از پلتفرم‌هایی که محتوایشان را میزبانی می‌کنند، پس بگیرند.

گام بعدی شما

• محتوای حساس و فنی خود را از فرمت‌های پراکنده به یک دامنه شخصی منتقل کرده و از تگ canonical استفاده کنید.
• هر جمله کلیدی را به‌گونه‌ای بنویسید که اگر جدا از متن اصلی خوانده شود، همچنان معنا و شرطش را منتقل کند.
• دسترسی ربات‌های AI را در robots.txt باز کنید و از رندر سمت سرور برای اطمینان از دیده شدن محتوا استفاده نمایید.

اما تأثیر این استراتژی بر هزینه استنتاج مدل‌ها هنگام بازیابی داده‌ها متفاوت است — به تحلیل ما درباره هزینه استنتاج در مدل‌های بزرگ مراجعه کنید.