معماری پشت جستجوی وب در چت‌بات‌های هوش مصنوعی

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

زمانی که از ChatGPT یا Claude می‌پرسید «وب را جستجو کن»، فقط از داده‌های آموزشی خود پاسخ نمی‌دهد؛ بلکه یک سیستم جستجوی جداگانه را فراخوانی می‌کند.

بخش اول این برای اکثر مردم شناخته‌شده است.

اما واضح نیست که چقدر موتورهای جستجوی سنتی اهمیت دارند و چه میزان بر پایهٔ آن‌ها ساخته شده است.

تمام این موارد به‌طور کامل عمومی نیستند؛ بنابراین من اینجا به استنتاج ذهنی می‌پردازم. اما می‌توانیم با مشاهدهٔ سرنخ‌های مختلف از سیستم‌های بزرگ‌تر، یک مدل ذهنی مفید بسازیم.

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

اگر با RAG آشنایی دارید، بخشی از این مطالب تکراری خواهد بود، اما همچنان مفید است که ببینید سیستم‌های بزرگ‌تر چگونه خط لوله را به فاز کشف و فاز بازیابی تقسیم می‌کنند (اگر برایتان جدید است).

اگر زمان کمی دارید، می‌توانید خلاصهٔ TL;DR را بخوانید.

خلاصه

جستجوی وب در این چت‌بات‌های هوش مصنوعی احتمالاً یک فرآیند دو بخشی است. بخش اول متکی بر موتورهای جستجوی سنتی برای یافتن و رتبه‌بندی اسناد کاندید است. در بخش دوم، محتوا را از آن URLها واکشی می‌کند و پاراگراف‌های مرتبط‌ترین را با استفاده از بازیابی سطح پاراگراف استخراج می‌کند.

تغییر بزرگ (نسبت به سئو سنتی) بازنویسی پرس‌وجو و تقسیم محتوا به سطح پاراگراف است؛ که این امکان را می‌دهد تا صفحات با رتبه پایین‌تر، اگر پاراگراف‌های خاص‌شان به سؤال بهتر پاسخ دهند، از صفحات با رتبه بالاتر پیشی بگیرند.

فرآیند فنی

شرکت‌های پشت Claude و ChatGPT در مورد نحوه کارکرد سیستم‌های جستجوی وب خود در رابط کاربری چت به‌طور کامل شفاف نیستند، اما می‌توانیم با ترکیب اطلاعات، نکات زیادی استنتاج کنیم.

ما می‌دانیم که برای یافتن کاندیدها به موتورهای جستجو متکی هستند؛ در این مقیاس، این کار غیرمنطقی است. همچنین می‌دانیم که مدل زبانی بزرگ (LLM) در هنگام پایه‌گذاری پاسخ‌ خود فقط قطعاتی از متن (بخش‌ها یا پاراگراف‌ها) می‌بیند.

این نکته به‌دقت نشان می‌دهد که بازیابی مبتنی بر تعبیه (embedding) بر روی این قطعات انجام می‌شود نه بر روی کل صفحات.

این فرآیند چندین بخش دارد، بنابراین گام به گام آن را بررسی می‌کنیم.

بازنویسی پرس‌وجو و گسترش

در ابتدا، نگاهی می‌اندازیم به اینکه چگونه سیستم پرسش‌های انسانی را پاک‌سازی و گسترش می‌دهد. گام بازنویسی، گام گسترش (fan‑out) و دلیل اهمیت آن برای سئو را بررسی می‌کنیم.

فکر می‌کنم این بخش شاید شفاف‌ترین باشد و بیشترین توافق آنلاین را داشته باشد.

مرحله بهینه‌سازی پرس‌وجو دربارهٔ تبدیل یک پرس‌وجوی انسانی به چیزی دقیق‌تر است. برای مثال «لطفاً آن کفش‌های قرمز که قبلاً دربارهٔ آن صحبت کردیم را جستجو کن» به «کفش ورزشی نایک قهوه‌ای‑قرمز» تبدیل می‌شود.

از سوی دیگر، مرحله گسترش (fan‑out) به تولید بازنویسی‌های اضافی می‌پردازد. بنابراین اگر کاربری دربارهٔ مسیرهای پیاده‌روی نزدیک به خود بپرسد، سیستم ممکن است عبارات زیر را امتحان کند: «پیاده‌روی مبتدی نزدیک استکهلم»، «پیاده‌روی یک‌روزه با حمل‌ونقل عمومی در استکهلم» یا «مسیرهای مناسب خانواده در استکهلم».

این با صرفاً استفاده از مترادف‌ها متفاوت است؛ جستجوگرهای سنتی قبلاً برای این بهینه‌سازی شده‌اند.

اگر برای اولین بار این مفهوم را می‌شنوید و قانع نشده‌اید، مستندات خود گوگل دربارهٔ fan‑out پرس‌وجو هوش مصنوعی را ببینید یا کمی دربارهٔ بازنویسی پرس‌وجو تحقیق کنید.

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

آنچه می‌توانیم بگوییم این است که احتمالاً یک مدل بزرگ این بخش را انجام نمی‌دهد. اگر به پژوهش‌ها نگاه کنید، Ye و همکاران به‌صراحت از یک LLM برای تولید بازنویسی‌های قوی استفاده می‌کنند، سپس آن را به یک بازنویسگر کوچک‌تر تبدیل می‌کنند تا از تأخیر و هزینه‌های اضافه جلوگیری شود.

از نظر مهندسی، این بخش صرفاً به این معناست که می‌خواهید پرس‌وجوهای نامنظم انسان‌ها را تمیز کنید و به چیزی تبدیل کنید که درصد موفقیت بالاتری دارد.

برای افراد تجاری و سئو، به این معناست که آن پرس‌وجوهای انسانی که بهینه‌سازی می‌کردید، به پرس‌وجوهای روباتیک‌تر و شکل‌دار برای اسناد تبدیل می‌شوند.

درک من از سئو این است که قبلاً به مطابقت دقیق عبارات طولانی در عناوین و سرفصل‌ها اهمیت زیادی می‌داد. اگر کسی به «بهترین کفش دویدن برای زانوهای دردناک» بپردازد، دقیقاً این رشته را استفاده می‌کردید.

اکنون باید به موجودیت‌ها، ویژگی‌ها و روابط نیز توجه کنید.

بنابراین، اگر کاربری بپرسد «چیزی برای پوست خشک»، بازنویسی‌ها می‌توانند شامل «مرطوب‌کننده»، «غیرفشارنده»، «رطوبت‌رسان»، «سراومیدها»، «بدون عطر»، «اجتناب از الکل‌ها» باشند و نه صرفاً «چگونه یک محصول خوب برای پوست خشک پیدا کنم».

اما برای واضح بودن و جلوگیری از ابهام: ما نمی‌توانیم بازنویسی‌های داخلی را ببینیم؛ بنابراین این‌ها صرفاً مثال هستند.

اگر به این بخش علاقه دارید می‌توانید عمیق‌تر بررسی کنید. فکر می‌کنم مقاله‌های فراوانی دربارهٔ چگونگی انجام این کار به‌خوبی وجود دارد.

حال به سمت استفاده واقعی از این پرس‌وجوهای بهینه‌سازی‌شده پیش می‌رویم.

استفاده از موتورهای جستجو (برای کشف سطح سند)

امروزه این دانستهٔ عمومی است که برای دریافت پاسخ‌های به‌روز، اکثر ربات‌های هوش مصنوعی به موتورهای جستجوی سنتی متکی هستند. این تمام داستان نیست، اما وب را به مجموعه‌ای کوچکتر برای کار کردن کاهش می‌دهد.

من فرض می‌کنم که کل وب برای یک خط لوله LLM برای استخراج مستقیم محتوا بیش از حد بزرگ، پرنویز و سریع‌ال تغییر است. بنابراین با استفاده از موتورهای جستجوی پیش‌تأسیس، می‌توانید دامنهٔ کار را محدود کنید.

اگر به خط لوله‌های بزرگ RAG که با میلیون‌ها سند کار می‌کنند نگاه کنید، کاری مشابه انجام می‌دهند؛ یعنی با استفاده از فیلتر برای تصمیم‌گیری دربارهٔ اینکه کدام اسناد مهم و ارزش پردازش بیشتری دارند.

برای این بخش، شواهدی داریم.

هر دو OpenAI و Anthropic اعلام کرده‌اند که از موتورهای جستجوی شخص ثالثی مانند Bing و Brave به‌همراه خزنده‌های خودشان استفاده می‌کنند.

ممکن است Perplexity این بخش را به‌صورت مستقل توسعه داده باشد، اما در ابتدا همان کار را انجام می‌دادند.

همچنین باید در نظر بگیریم که موتورهای جستجوی سنتی مانند Google و Bing قبلاً سخت‌ترین مشکلات را حل کرده‌اند. این‌ها تکنولوژی‌های مستحکمی هستند که مواردی نظیر تشخیص زبان، امتیاز اعتبار، اعتماد دامنه، فیلتر هرزنامه و … را مدیریت می‌کنند.

دورانداز تمام این موارد برای تعبیهٔ کل وب به‌صورت خودکار به‌نظر نامعقول می‌آید.

اگرچه نمی‌دانیم برای هر پرس‌وجو چه تعداد نتایج به‌دست می‌آورند؛ آیا فقط ۲۰ یا ۳۰ برتر است؟ یک مقالهٔ غیررسمی مقایسهٔ استنادات ChatGPT و Bing را انجام داد، ترتیب رتبه‌بندی را بررسی کرد و دریافت که برخی استنادات از رتبهٔ ۲۲ به‌پایین آمده‌اند.

اگر این درست باشد، نشان می‌دهد که باید برای دیده شدن در حدود top‑20 هدف‌گذاری کنید.

علاوه‌بر این، هنوز نمی‌دانیم چه معیارهای دیگری برای تصمیم‌گیری دربارهٔ نتایج برتر استفاده می‌شود. این مقاله استدلال می‌کند که موتورهای هوش مصنوعی به‌صورت فراوان به محتواهای کسب‌شده (earned media) به‌جای سایت‌های رسمی یا شبکه‌های اجتماعی ترجیح می‌دهند.

در هر صورت، وظیفهٔ موتور جستجو (چه کاملاً شخص ثالث باشد چه ترکیبی) کشف است. آن URLها را بر پایهٔ اعتبار و کلمات کلیدی رتبه‌بندی می‌کند.

ممکن است یک نکتهٔ کوتاه از اطلاعات را شامل شود، اما این به‌تنهایی برای پاسخ به سؤال کافی نیست؛ مگر اینکه سؤال بسیار ساده‌ای مانند «مدیرعامل X کیست؟» باشد.

اما برای سؤالات عمیق‌تر، اگر مدل فقط به نکتهٔ کوتاه، عنوان و URL تکیه کند، احتمالاً جزئیات را به‌صورت غلط (hallucination) ارائه می‌دهد؛ زیرا زمینه کافی نیست.

به همین دلیل ما را به سمت معماری دو مرحله‌ای می‌برد، که در آن مرحلهٔ بازیابی تعبیه شده است (به‌زودی به آن می‌پردازیم).

این در حوزهٔ سئو چه معنایی دارد؟

این به این معناست که شما هنوز باید در موتورهای جستجوی سنتی رتبه بالایی داشته باشید تا در دستهٔ اولیهٔ اسناد پردازش‌شده قرار بگیرید؛ پس بلی، سئو کلاسیک همچنان مهم است.

اما ممکن است همچنین نیاز باشد به معیارهای جدیدی که ممکن است برای رتبه‌بندی نتایج استفاده کنند، فکر کنید.

این مرحله تماماً دربارهٔ محدود کردن دامنه به چند صفحه‌ای است که ارزش کاوش دارند، با استفاده از فناوری‌های جستجوی تثبیت‌شده به‌همراه تنظیمات داخلی. بقیه (بخش «بازگرداندن پاراگراف‌های اطلاعاتی») پس از این گام، با استفاده از تکنیک‌های بازیابی استاندارد انجام می‌شود.

خزیدن، تکه‌گذاری و بازیابی

حال به سراغ آنچه اتفاق می‌افتد وقتی سیستم چند URL جالب را شناسایی کرد، می‌رویم.

پس از عبور یک مجموعهٔ کوچک از URLها از فیلتر اول، خط لوله نسبتاً ساده است: صفحه را می‌خزد، به قطعات تقسیم می‌کند، این قطعات را تعبیه می‌کند، قطعاتی که با پرس‌وجو هم‌خوانی دارند را بازیابی می‌کند و سپس آن‌ها را دوباره رتبه‌بندی می‌کند.

این همان چیزی است که «بازیابی» (retrieval) نامیده می‌شود.

من این را «به‌لحظه» می‌نامم، چون سیستم فقط زمانی که URL به‌عنوان کاندید می‌شود، قطعات را تعبیه می‌کند و سپس این تعبیه‌ها را برای استفادهٔ مجدد ذخیره می‌کند. اگر با بازیابی آشنایی دارید، این بخش ممکن است جدید به نظر برسد.

برای خزیدن صفحه، به‌نظر می‌رسد آن‌ها از خزنده‌های خودشان استفاده می‌کنند. برای OpenAI، این OAI‑SearchBot است که سپس HTML خام را دریافت می‌کند تا بتواند پردازش شود.

خزنده‌ها عموماً JavaScript را اجرا نمی‌کنند؛ احتمالاً بر HTML تولید‌شده از سمت سرور تکیه دارند؛ بنابراین قوانین سئو همان‌ندارد: محتوا باید در دسترس باشد.

پس از دریافت HTML، محتوا باید به چیزی تبدیل شود که قابل جستجو باشد.

اگر تازه‌کار باشید، ممکن است فکر کنید هوش مصنوعی «سند را اسکن می‌کند»، اما این‌گونه نیست. اسکن کل صفحات برای هر پرس‌وجو بسیار کند و پرهزینه است.

در عوض، صفحات به پاراگراف‌ها تقسیم می‌شوند که معمولاً بر پایهٔ ساختار HTML مانند سرنویس‌ها، پاراگراف‌ها، فهرست‌ها، تقسیم‌بندی بخش‌ها و … انجام می‌شود. این‌ها در زمینهٔ بازیابی به‌عنوان «قطعات» (chunks) شناخته می‌شوند.

هر قطعه یک واحد کوچک و خودکفا می‌شود. از نظر توکن، می‌توانید در استنادات UI Perplexity ببینید که قطعات حدود چند ده توکن، شاید حدود ۱۵۰ توکن، نه هزار توکن، هستند.

یعنی حدود ۱۱۰ تا ۱۲۰ واژه.

پس از تکه‌گذاری، این واحدها با استفاده از بردارهای پراکنده (sparse) و چگال (dense) تعبیه می‌شوند. این امکان را می‌دهد که سیستم جستجوی ترکیبی (hybrid) را اجرا کند و پرس‌وجو را هم معنایی و هم کلمه‌کلیدی تطبیق دهد.

اگر تازه‌کار به جستجوی معنایی هستید، به‌طور خلاصه، به این معناست که سیستم به‌دنبال معنا می‌گردد نه کلمات دقیق؛ بنابراین پرس‌وجویی مانند «علائم کمبود آهن» و «نشانه‌های بدن کم آهن» همچنان در فضای تعبیه به‌یکدیگر نزدیک خواهند بود.

اگر مایلید بیشتر دربارهٔ تعبیه‌ها بدانید، می‌توانید مطالب بیشتری در این باره بخوانید.

پس از تکه‌گذاری و تعبیه یک صفحهٔ پرطرفدار، این تعبیه‌ها احتمالاً ذخیره‌سازی می‌شوند. هیچ‌کس یک پاسخ StackOverflow را هزاران بار در روز دوباره تعبیه نمی‌کند.

این همان دلیل واضحی است که سیستم این‌چنین سریع به‌نظر می‌رسد؛ احتمالاً ۹۵ تا ۹۸ درصد از وبی که واقعا استناد می‌شود، قبلاً تعبیه و به‌طور پرسرعت کشیده می‌شود.

اگرچه دقیقاً نمی‌دانیم تا چه حد و چقدر آن‌ها پیش‌تعبیه می‌کنند تا اطمینان حاصل شود که سیستم برای پرس‌وجوهای پرطرفدار به‌سرعت کار می‌کند.

حالا سیستم باید تصمیم بگیرد کدام قطعات مهم هستند. برای این کار از تعبیه‌های هر قطعه متن برای محاسبهٔ امتیاز هم تطبیق معنایی و هم کلمه‌کلیدی استفاده می‌کند.

قطعاتی با بالاترین امتیازها انتخاب می‌شوند؛ این می‌تواند بین ۱۰ تا ۵۰ قطعهٔ برتر باشد.

از اینجا، اکثر سیستم‌های پیشرفته از یک رتبه‌سنج (re‑ranker) (cross‑encoder) برای پردازش مجدد این قطعات برتر استفاده می‌کنند؛ این مرحله «اصلاح آشفتگی بازیابی» نام دارد، زیرا متأسفانه بازیابی همیشه به‌دلیل دلایل مختلف کاملاً قابل‌اعتماد نیست.

اگرچه آن‌ها دربارهٔ استفاده از cross‑encoder چیزی نمی‌گویند، اما Perplexity یکی از معدودهایی است که فرآیند بازیابی خود را به‌صورت باز مستند می‌کند.

API جستجوی آن‌ها می‌گوید که «اسناد را به واحدهای جزئی تقسیم می‌کند» و این واحدها را به‌صورت جداگانه امتیاز می‌دهد تا «پاراگراف‌های مرتبط‌ترین که قبلاً رتبه‌بندی شده‌اند را برگرداند».

این همه برای سئو چه معنایی دارد؟ اگر سیستم بازیابی را به‌این شکل انجام می‌دهد، صفحهٔ شما به‌عنوان یک بلوک بزرگ در نظر گرفته نمی‌شود.

صفحه به قطعات (اغلب در سطح پاراگراف یا سرنویس) تقسیم می‌شود و این قطعات همانند امتیازدهی می‌شوند. کل صفحه در زمان کشف مهم است، اما پس از شروع بازیابی، فقط قطعات مهم می‌شوند.

یعنی هر قطعه باید به سؤال کاربر پاسخ دهد.

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

در اینجا مرحلهٔ بازیابی را پوشش دادیم: سیستمی که صفحات را می‌خزد، به واحدها تقسیم می‌کند، این واحدها را تعبیه می‌کند و سپس با استفاده از جستجوی ترکیبی و رتبه‌بندی مجدد، تنها پاراگراف‌هایی را استخراج می‌کند که می‌توانند به سؤال کاربر پاسخ دهند.

انجام یک دور دیگر و تحویل قطعات به LLM

حالا به سراغ اتفاقاتی می‌رویم که پس از بخش بازیابی رخ می‌دهد، شامل ویژگی «ادامهٔ جستجو» و تحویل این قطعات به LLM اصلی.

پس از شناسایی چند قطعهٔ با رتبه بالا، سیستم باید تصمیم بگیرد که آیا این قطعات به‌حد کافی خوب هستند یا نیاز به ادامهٔ جستجو دارد. این تصمیم به‌احتمال زیاد توسط یک مدل کنترل‌کنندهٔ کوچک اتخاذ می‌شود، نه توسط LLM اصلی.

حدس می‌زنم، اما اگر مطالب کمبود یا بی‌ارتباط به‌نظر برسند، ممکن است یک دور دیگر بازیابی انجام شود. اگر محتوای قوی به‌نظر برسد، می‌تواند این قطعات را به LLM تحویل دهد.

در نقطه‌ای این انتقال رخ می‌دهد؛ پاراگراف‌های انتخاب‌شده به‌همراه برخی متادیتا به LLM اصلی منتقل می‌شوند.

مدل تمام قطعات ارائه‌شده را می‌خواند و آن‌را انتخاب می‌کند که بهترین پشتیبانی را برای پاسخی که می‌خواهد تولید کند، فراهم می‌کند.

این مدل به‌صورت مکانیکی ترتیب بازیاب را دنبال نمی‌کند؛ بنابراین تضمینی نیست که LLM از «قطعهٔ برتر» استفاده کند. ممکن است پاساژی با رتبهٔ پایین‌تر را ترجیح دهد چون واضح‌تر، خودکفا یا نزدیک‌تر به نوشتار مورد نیاز برای پاسخ باشد.

بنابراین درست مانند ما، تصمیم می‌گیرد چه چیزهایی را بگیرد و چه چیزهایی را نادیده بگیرد. حتی اگر قطعهٔ شما بالاترین امتیاز را داشته باشد، تضمینی نیست که اولین‌بار ذکر شود.

مواردی که باید در نظر بگیرید

این سیستم در واقع جعبهٔ سیاهی نیست؛ سیستمی است که افراد ساخته‌اند تا اطلاعات مناسب را به LLMها بدهند تا به سؤال کاربر پاسخ دهند.

اگر استنتاج من صحیح باشد، سیستم کاندیدها را پیدا می‌کند، اسناد را به واحدها تقسیم می‌کند، این واحدها را جستجو و رتبه‌بندی می‌کند و سپس آن‌ها را برای خلاصه‌سازی به یک LLM می‌سپارد.

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

سئوی سنتی همچنان اهمیت زیادی دارد، زیرا این سیستم بر سئو سنتی تکیه دارد. مواردی مانند داشتن نقشهٔ سایت مناسب، محتوای به‌راحتی رندرشدنی، سرنویس‌های مناسب، اعتبار دامنه و برچسب‌های تاریخ آخرین تغییر دقیق، برای مرتب‌سازی صحیح محتوای شما ضروری هستند.

همان‌طور که اشاره کردم، ممکن است آن‌ها موتورهای جستجو را با فناوری خود ترکیب کنند تا تصمیم بگیرند کدام URLها انتخاب می‌شوند؛ این نکته‌ای است که باید در ذهن داشته باشید.

اما اگر بازیابی بر روی آن انجام شود، مرتبط بودن در سطح پاراگراف نقطهٔ قدرت جدید خواهد شد.

بنابراین طراحی «پاسخ در یک قطعه» حاکم خواهد شد. (فقط این‌را به‌طرزی انجام ندهید که عجیبه؛ شاید یک TL;DR مفید باشد.) و به‌خاطر داشته باشید که از واژگان صحیح استفاده کنید: موجودیت‌ها، ویژگی‌ها، روابط، همان‌طور که در بخش بهینه‌سازی پرس‌وجو اشاره کردیم.

چگونه یک «سیستم امتیازدهی GEO» (برای سرگرمی) بسازیم

برای فهمیدن اینکه محتوای شما چه عملکردی خواهد داشت، باید محیط دشوار موجودیت محتوای شما را شبیه‌سازی کنیم؛ پس سعی می‌کنیم این خط لوله را به‌صورت معکوس مهندسی کنیم.

توجه داشته باشید، این کار ساده نیست، زیرا ما معیارهای داخلی آن‌ها را نمی‌دانیم و این سیستم به‌طور کامل عمومی نیست؛ بنابراین این را به‌عنوان یک طرح کلی در نظر بگیرید.

ایده این است که خط لوله‌ای بسازیم که بتواند بازنویسی پرس‌وجو، کشف، بازیابی، رتبه‌بندی مجدد و قاضی LLM را انجام دهد و سپس ببینیم در مقایسه با رقبای خود در موضوعات مختلف کجا قرار می‌گیرید.

می‌توانید با چند موضوع مانند «بازیابی ترکیبی برای RAG سازمانی» یا «ارزیابی LLM با LLM‑as‑judge» شروع کنید و سپس سیستمی بسازید که پرس‌وجوهای طبیعی حول این موضوعات تولید کند.

سپس این پرس‌وجوها را از طریق مرحله بازنویسی LLM عبور می‌دهید، زیرا این سیستم‌ها اغلب پیش از بازیابی، پرسش کاربر را بازنویسی می‌کنند. این بازنویسی‌ها همان‌طور که می‌خواهید از طریق خط لوله عبور می‌کنند.

اولین بررسی، قابلیت دیده شدن است. برای هر پرس‌وجو، نتایج ۲۰ تا ۳۰ برتر را در Brave، Google و Bing بررسی کنید؛ ببینید صفحهٔ شما ظاهر می‌شود یا نه و نسبت به رقبای خود در چه رتبه‌ای قرار دارد.

اگر صفحهٔ شما در این نتایج اولیه ظاهر شد، به مرحلهٔ بازیابی می‌روید.

صفحهٔ خود و صفحات رقبای خود را واکشی کنید، HTML را پاک‌سازی کنید، به قطعات تقسیم کنید، این قطعات را تعبیه کنید و یک تنظیم بازیابی ترکیبی کوچک بسازید که ترکیبی از مطابقت معنایی و کلمه‌کلیدی باشد. یک مرحلهٔ رتبه‌بندی مجدد اضافه کنید.

پس از دریافت قطعات برتر، لایهٔ نهایی را اضافه می‌کنید: یک LLM‑as‑a‑judge. حضور در پنج برتر تضمین استناد نیست، بنابراین مرحلهٔ آخر را شبیه‌سازی می‌کنید؛ چند قطعهٔ با بالاترین امتیاز (به‌همراه متادیتا) را به LLM می‌دهید و می‌بینید کدامیک را ابتدا استناد می‌کند.

وقتی این کار را برای صفحات خود و رقیبان انجام می‌دهید، می‌بینید در چه زمینه‌ای برنده یا بازنده هستید: لایهٔ جستجو، لایهٔ بازیابی یا لایهٔ LLM.

به‌خاطر داشته باشید که این هنوز یک طرح کلی است؛ نمی‌توانیم امتیازهای دقیق اعتبار را که آنها استفاده می‌کنند، بدانیم، اما اگر بخواهید سیستمی مشابه بسازید، این یک نقطهٔ شروع برای شماست.

این مقاله بیشتر بر مکانیک‌ها تمرکز داشته و کمتر بر استراتژی سئو/GEO؛ می‌دانم که این برای همه مناسب نیست.

هدف این بود که جریان از پرس‌وجوی کاربر تا پاسخ نهایی را نقشه‌کشی کنیم و نشان دهیم ابزار جستجوی هوش مصنوعی نیروی مبهمی نیست.

حتی اگر بخش‌هایی از سیستم عمومی نباشند، می‌توانیم یک طرح منطقی از آنچه در حال رخ دادن است استنتاج کنیم؛ تا به‌حال واضح است که جستجوی وب هوش مصنوعی جایگزین موتورهای جستجوی سنتی نمی‌شود.

فقط یک لایهٔ بازیابی بر روی آن‌ها افزودنی می‌شود.

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

امیدوارم خواندن آن آسان بوده باشد. اگر از آن لذت بردید، می‌توانید آن را به‌اشتراک بگذارید یا از طریق LinkedIn، Medium یا وب‌سایتم با من در تماس باشید.

❤