چرا پروتکل‌های جدید هوش مصنوعی جایگزین معماری دانش در سئو نمی‌شوند

نویسنده این یادداشت با یک گفت‌وگوی تازه شروع می‌کند: مدیری ارشد که هشداری از سوی فروشنده‌ای درباره ارزیابی دید در جست‌وجوی هوش مصنوعی دریافت کرده است. در میان توصیه‌ها، پیاده‌سازی فایل llms.txt هم دیده می‌شود؛ قالبی تازه و هنوز محل بحث. ناگهان یک انتخاب فنی، به دغدغه مدیران تبدیل می‌شود: آیا این توصیه درست است؟ هزینه و تأثیر آن چقدر است؟ چرا شرکت هنوز آن را پیاده نکرده و آیا منابع مهندسی و بازاریابی باید به آن اختصاص یابد؟

نویسنده این چرخه را با مفهومی به نام «مالیات ترس از هوش مصنوعی» یا AI FUD Tax توضیح می‌دهد. هزینه هر توصیه فردی ممکن است کم باشد، اما وقتی هر ممیزی، ابزار یا پروتکل تازه مجموعه‌ای از نگرانی‌های جدید ایجاد می‌کند، هزینه سازمانی به‌سرعت بالا می‌رود. نکته اصلی llms.txt، MCP یا مارک‌داون نیستند؛ هرکدام کارکرد متفاوتی دارند و از نظر فنی نمی‌توان آن‌ها را یکی دانست، اما برخورد راهبردی با همه آن‌ها یکسان است: تبدیل قالب تازه به راه‌حل، به‌جای پرداختن به دانش زیربنایی.

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

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

اگر یکی از معیارهای مهم، شواهد معتبری نداشته باشد، مشکل لزوماً رتبه ضعیف برند نیست؛ برند احتمالاً هرگز شواهد کافی برای ماندن در فهرست انتخاب را فراهم نکرده است. این نگاه، جایگزین دفاعی‌پذیرتری برای تشخیص نبودِ دید در هوش مصنوعی ارائه می‌دهد: به‌جای واکنش عجولانه با محتوای یکسان‌ساز، لینک بیشتر یا پیاده‌سازی فنی پیچیده، باید معیارهای تصمیم را تجزیه کرد و فهمید کدام بخش از شواهد پشتیبان ناقص است.

ساده‌ترین واکنش به شکافِ پوشش تصمیم، انتشار اطلاعات از دست‌رفته در همان قالبی است که این روزها توجه می‌گیرد؛ اسکیما، مارک‌داون، MCP یا llms.txt. اما اگر تصمیم مشتری به پنج معیار مهم وابسته باشد و سازمان فقط چهار معیار را ثابت کند، انتشار همان چهار مدرک از مسیر پروتکلی تازه، معیار پنجم را ایجاد نمی‌کند. اسکیما می‌تواند روابط میان موجودیت‌ها را توصیف کند اما نمی‌تواند تعیین کند این روابط چه باید باشند. MCP می‌تواند منابع سازمان را در دسترس هوش مصنوعی بگذارد اما نمی‌گوید آیا آن منابع دانش لازم برای پاسخ به پرسش مشتری را دارند. llms.txt هم می‌تواند ماشین‌ها را به اطلاعات هدایت کند اما نمی‌تواند اطلاعاتی را که سازمان هرگز تولید نکرده جبران کند.

نویسنده می‌گوید در بیش از صد ممیزی آمادگی عامل‌های هوش مصنوعی که مشاهده کرده، همه ممیزی‌ها به وجود فایل llms.txt اشاره کرده‌اند، اما هیچ‌کدام کیفیت و عمق این فایل را در سازمان‌هایی که آن را داشتند نقد نکرده‌اند. بحث تازه درباره یکپارچگی داده نیز به همین موضوع مربوط است. الکس ماس (Alex Moss) در مقاله‌ای در سرچ انجین ژورنال (Search Engine Journal) استدلال کرده است که سئو فنی باید بر بیشینه‌سازی یکپارچگی داده تمرکز کند، زیرا سیستم‌های هوش مصنوعی به موجودیت‌های دقیق، روابط صریح و قالب‌های ماشین‌خوان وابسته‌اند. اما پیش از تضمین یکپارچگی اطلاعات باید مشخص شود چه دانشی باید وجود داشته باشد، این دانش چگونه به هم متصل می‌شود، مالک آن کیست و کدام منبع مرجع در نظر گرفته می‌شود.

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

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

پوشش تصمیم مشخص می‌کند که دانش موجود تا چه اندازه تصمیم‌های مهم مشتری را پشتیبانی می‌کند؛ معماری دانش شیوه سازمان‌دهی و نگهداری آن را تعیین می‌کند؛ و قالب‌های مختلف فقط کانال تحویل می‌شوند. امروز این کانال‌ها می‌توانند محتوای وب، اسکیما، فیدهای Merchant Center، API، مارک‌داون، MCP و llms.txt باشند و فردا تقریباً قطعاً تغییر کنند. اگر هر فرمت انتشار نسخه جداگانه‌ای از واقعیت‌ها و شواهد سازمان نگه دارد، هر به‌روزرسانی به همگام‌سازی دوباره نیاز دارد. اما اگر همه این خروجی‌ها از یک منبع مشترک و مدیریت‌شده تغذیه شوند، ساختار به‌شکل اساسی تغییر می‌کند: کار اصلی فقط یک‌بار روی لایه دانش انجام می‌شود و لایه انتشار با تغییر فناوری تطبیق پیدا می‌کند.

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