معماری محتوای مناسب هوش مصنوعی؛ از Entity تا Schema و Semantic Structure

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

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

اینجاست که مفهوم معماری محتوا اهمیت متفاوتی پیدا می کند.

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

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

اما داشتن دانش به تنهایی کافی نیست. این دانش باید به شکلی سازماندهی شود که روابط میان مفاهیم برای سیستم های هوشمند قابل درک باشد. اینجاست که Semantic Structure، ساختار Headingها، ارتباط میان بخش های محتوا، Internal Linking، طراحی Knowledge Chunkها و معماری صفحات اهمیت پیدا می کنند.

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

بنابراین، معماری محتوای مناسب هوش مصنوعی را نمی توان به Schema، Semantic SEO یا حتی تولید محتوای بیشتر تقلیل داد. مسئله اصلی، هماهنگ کردن لایه های مختلف دانش است؛ از هویت و موجودیت ها گرفته تا موضوعات، روابط، پرسش ها، محتوا، ساختار صفحات، داده های ساختاریافته و منابعی که می توانند اعتبار این دانش را تقویت کنند.

این مقاله دقیقاً از همین مسیر حرکت می کند.

ابتدا بررسی می کنیم که Entity چگونه نقطه آغاز فهم هویت و موضوع است و چرا معماری محتوا باید پیش از تولید صفحه، بر پایه موجودیت ها و روابط آن ها طراحی شود. سپس به سراغ Knowledge Graph و Knowledge Architecture می رویم تا ببینیم چگونه می توان دانش یک کسب و کار را به مجموعه ای منسجم از مفاهیم، موجودیت ها و روابط تبدیل کرد.

در ادامه، Semantic Structure را بررسی خواهیم کرد؛ اینکه چگونه باید موضوعات، زیرموضوعات، Headingها، پاراگراف ها، لینک های داخلی و واحدهای دانشی را کنار یکدیگر قرار داد تا محتوا فقط مجموعه ای از جملات نباشد، بلکه ساختاری قابل فهم و قابل بازیابی ایجاد کند.

پس از آن به Schema می رسیم و جایگاه واقعی آن را در این معماری مشخص می کنیم؛ از ارتباط Schema با Entity و Knowledge Graph گرفته تا نحوه هماهنگی داده های ساختاریافته با محتوای واقعی صفحه و هویت برند.

در بخش های بعدی نیز به یکی از مهم ترین مسائل عصر مدل های زبانی می پردازیم: Retrieval و AI Citation. زیرا معماری محتوا زمانی ارزش واقعی خود را نشان می دهد که بخش های مختلف دانش بتوانند به صورت مستقل و در عین حال در بستر درست، بازیابی و مورد استفاده قرار گیرند.

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

از Entity آغاز می کنیم، به Knowledge Architecture می رسیم، ساختار معنایی را شکل می دهیم، محتوا را به واحدهای قابل فهم و بازیابی تبدیل می کنیم، Schema را در جای درست خود قرار می دهیم و در نهایت همه این اجزا را به یکدیگر متصل می کنیم.

چرا که در عصر هوش مصنوعی، دیگر فقط این سؤال مطرح نیست که:

«چه محتوایی تولید کنیم؟»

بلکه سؤال مهم تر این است:

«دانش خود را چگونه معماری کنیم تا هم انسان آن را بفهمد و هم ماشین بتواند آن را درک، بازیابی، اعتبارسنجی و به موقع استفاده کند؟»

چرا معماری محتوا در عصر هوش مصنوعی تغییر کرده است؟

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

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

تفاوت معماری صفحه محور با معماری دانش محور

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

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

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

به بیان ساده، در معماری صفحه محور می پرسیم:

«این اطلاعات را در کدام صفحه قرار دهیم؟»

اما در معماری دانش محور ابتدا می پرسیم:

«این اطلاعات چه جایگاهی در دانش ما دارد و با چه مفاهیمی ارتباط دارد؟»

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

چرا دیگر «مقاله خوب» به تنهایی کافی نیست؟

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

دلیل آن ساده است. یک مدل زبانی ممکن است برای پاسخ به یک پرسش، فقط به یک مقاله کامل نیاز نداشته باشد. ممکن است تنها به یک تعریف، یک آمار، یک توضیح تخصصی، یک رابطه میان دو Entity یا یک بخش مشخص از یک مقاله نیاز داشته باشد.

در چنین شرایطی، کیفیت کل مقاله مهم است، اما کیفیت و ساختار واحدهای دانشی داخل مقاله نیز اهمیت پیدا می کند.

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

بنابراین، مسئله این نیست که «مقاله خوب» دیگر ارزش ندارد. مسئله این است که مقاله خوب باید بخشی از یک معماری خوب باشد.

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

نقش ساختار در فهم، بازیابی و استفاده از محتوا

ساختار محتوا در اینجا فقط به معنای استفاده درست از H1، H2 و H3 نیست. Headingها یکی از اجزای این ساختار هستند، اما معماری معنایی بسیار گسترده تر است.

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

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

این موضوع در فرآیند Retrieval اهمیت بیشتری پیدا می کند. اگر یک سیستم هوشمند در پاسخ به سؤال کاربر به دنبال بخش مشخصی از دانش باشد، محتوایی که واحدهای دانشی روشن، Context کافی و ارتباط معنایی مشخص دارد، ظرفیت بیشتری برای بازیابی خواهد داشت.

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

بنابراین، معماری محتوا را نباید صرفاً مسئله ای برای بهبود تجربه خواندن یا حتی بهینه سازی موتور جستجو دانست. معماری محتوا در حال تبدیل شدن به معماری انتقال دانش است.

صفحه، مقاله، Heading، لینک داخلی، Entity، Schema و حتی یک پاراگراف، دیگر اجزای کاملاً مستقل نیستند. هرکدام باید در جایگاه خود بخشی از یک سیستم بزرگ تر را تشکیل دهند.

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

و شاید همین جاست که تفاوت اصلی میان «سایتی که محتوا دارد» و «برندی که صاحب دانش است» آشکار می شود.

دیدگاه فرهود

در مورد معماری محتوا در عصر هوش مصنوعی، از نگاه من یک نکته بسیار مهم وجود دارد: آنچه امروز درباره ساختاردهی و سازماندهی دانش صحبت می کنیم، در اصل ادامه مسیری است که سئوکاران سال ها قبل آغاز کرده بودند؛ اما یک تفاوت اساسی در نگاه امروز وجود دارد.

ما سال ها تلاش کردیم محتوا را عمیق تر کنیم، موضوعات مرتبط را در کنار یکدیگر قرار دهیم، از Headingها استفاده کنیم، صفحات را با لینک های داخلی به هم متصل کنیم و ساختار مناسبی برای سایت ایجاد کنیم. اما در بسیاری از موارد، این فعالیت ها با یک هدف مشخص انجام می شد: دیده شدن در یک کلمه کلیدی یا جذب ترافیک از یک جستجوی مشخص.

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

به نظر من، تفاوت مهم عصر هوش مصنوعی همین جا شکل می گیرد.

امروز دیگر فقط نمی پرسیم:

«آیا این صفحه برای یک موضوع مشخص بهینه شده است؟»

بلکه باید بپرسیم:

«آیا مجموعه این صفحات در کنار یکدیگر می توانند یک حوزه دانش را به شکل منسجم توضیح دهند؟»

این تغییر، معماری محتوا را از یک مسئله صرفاً سئویی به یک مسئله دانشی تبدیل می کند.

برای توضیح این موضوع، همیشه یک مثال ساده از دوران تدریسم و تحصیل در رشته الکترونیک به ذهنم می رسد.

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

اما آیا هدف دانشگاه فقط این است که دانشجو چندین درس را پاس کند؟

طبیعتاً نه.

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

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

دانش واقعی در همین ارتباط ها شکل می گیرد.

به نظر من، یک سایت نیز باید چنین مسیری داشته باشد.

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

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

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

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

ما از Heading Structure شروع کردیم و به ساختار صفحات رسیدیم؛ از ساختار صفحات به ارتباط میان مقالات رسیدیم و امروز باید یک قدم جلوتر برویم و بپرسیم:

آیا این ارتباط ها در نهایت یک دانش منسجم و قابل فهم ایجاد می کنند؟

اگر پاسخ مثبت باشد، دیگر با مجموعه ای از صفحات روبه رو نیستیم؛ بلکه با یک Knowledge Ecosystem مواجهیم.

و شاید مهم ترین تغییر همین باشد:

در گذشته، تلاش می کردیم هر صفحه را برای دیده شدن بهینه کنیم؛ امروز باید کل ساختار دانش را برای فهمیده شدن معماری کنیم.

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

به همین دلیل، معماری محتوای مناسب هوش مصنوعی را نباید صرفاً مجموعه ای از تکنیک های جدید سئو دانست. این معماری در نهایت درباره یک سؤال بنیادی تر است:

آیا ما فقط اطلاعات تولید می کنیم، یا واقعاً در حال ساختن دانش هستیم؟

Entity؛ نقطه شروع معماری محتوای قابل فهم برای هوش مصنوعی

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

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

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

Entity چیست و چرا برای مدل های زبانی اهمیت دارد؟

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

اما اهمیت Entity برای مدل های زبانی فقط در «شناخت نام» خلاصه نمی شود. مسئله اصلی این است که سیستم بتواند بفهمد این موجودیت چیست، چه ویژگی هایی دارد و در چه شبکه ای از مفاهیم و روابط قرار گرفته است.

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

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

تعریف هویت برند، نویسنده، محصول و موضوع

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

برای مثال، یک سایت تخصصی ممکن است چنین ساختاری داشته باشد:

Brand → Author → Article → Topic → Service → Organization

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

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

باید بدانیم:

• برند دقیقاً چیست؟
• چه خدمات یا محصولاتی ارائه می کند؟
• نویسندگان و متخصصان مرتبط با آن چه کسانی هستند؟
• حوزه تخصصی برند چیست؟
• چه موضوعاتی به صورت مستقیم یا غیرمستقیم به آن مربوط هستند؟
• چه موجودیت های دیگری در این حوزه با برند ارتباط دارند؟

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

بنابراین، Entity Architecture زمانی ارزشمند است که هویت موجودیت ها با دانش واقعی موجود در اکوسیستم هماهنگ باشد.

ارتباط میان Entityها و شکل گیری Context

یک Entity به تنهایی اطلاعات محدودی در اختیار ما قرار می دهد. بخش مهمی از معنا از رابطه میان Entityها شکل می گیرد. برای مثال، نام یک فرد به تنهایی اطلاعات چندانی درباره تخصص او ارائه نمی کند. اما اگر بدانیم این فرد نویسنده چند مقاله تخصصی است، در یک سازمان مشخص فعالیت می کند، درباره موضوع مشخصی پژوهش کرده و منابع دیگری نیز به آثار او اشاره کرده اند، Context بسیار غنی تری ایجاد می شود.

در اینجا، معنا فقط در خود Entity نیست؛ در روابط میان Entityها نیز وجود دارد. این همان جایی است که معماری محتوا از تولید متن فراتر می رود. فرض کنید یک فروشگاه تخصصی درباره یک محصول مقاله ای منتشر می کند. اگر مقاله فقط نام محصول را ذکر کند، اطلاعات محدودی ارائه شده است. اما اگر ارتباط محصول با برند، دسته محصول، ویژگی ها، کاربردها، مواد اولیه، مخاطب هدف، مقالات آموزشی و سایر محصولات مرتبط نیز مشخص باشد، یک Context بسیار گسترده تر شکل می گیرد.

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

این شبکه می تواند به شکل یک Knowledge Graph نیز مدل سازی شود، اما نکته مهم این است که Knowledge Graph از هیچ ساخته نمی شود. ابتدا باید Entityها و روابط واقعی میان آن ها وجود داشته باشند و سپس بتوان آن روابط را ساختاردهی و نمایش داد. به همین دلیل، در معماری محتوای مناسب هوش مصنوعی، سؤال مهم فقط این نیست که:

«چه Entityهایی در صفحه وجود دارند؟»

بلکه باید پرسید:

«این Entityها چه رابطه ای با یکدیگر دارند و این روابط چه Contextی ایجاد می کنند؟»

تفاوت Entity محور بودن با Keyword محور بودن

Keyword و Entity دو مفهوم متضاد نیستند، اما نقطه تمرکز آن ها متفاوت است.

در رویکرد Keyword محور، معمولاً مسئله از یک عبارت شروع می شود. مثلاً:

«خرید لپ تاپ»

سپس تلاش می کنیم صفحه ای ایجاد کنیم که برای این عبارت و عبارت های مشابه مرتبط، قابلیت دیده شدن داشته باشد.

اما در رویکرد Entity محور، سؤال گسترده تر است:

«لپ تاپ چیست، چه برندهایی دارد، چه ویژگی هایی دارد، چه نیازهایی را پاسخ می دهد، چه انواعی دارد، چه اشخاص و سازمان هایی درباره آن دانش تولید کرده اند و این مفهوم با چه موضوعات دیگری ارتباط دارد؟»

در اینجا کلمه کلیدی همچنان اهمیت دارد، اما دیگر مرکز معماری نیست. Keyword به ما کمک می کند بفهمیم کاربران چگونه چیزی را جستجو می کنند؛ Entity به ما کمک می کند بفهمیم آن چیز در جهان دانش چه جایگاهی دارد. این تفاوت در معماری محتوا بسیار مهم است.

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

به همین دلیل، حرکت از Keyword به Entity به معنای کنار گذاشتن Keyword SEO نیست. بلکه به معنای قرار دادن Keyword در جایگاه درست خود است.

کلمه کلیدی نشانه ای از زبان کاربر است؛ Entity بخشی از ساختار دانش پشت آن زبان است.

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

دیدگاه فرهود

اگر بخواهم درباره Entity و Context از نگاه خودم و مدلی که در سال های اخیر روی آن کار کرده ام صحبت کنم، فکر می کنم یکی از مهم ترین تغییرات عصر جدید را باید در تفاوت میان «ادعا کردن» و «نشان دادن» جستجو کرد.

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

«من اینجا هستم.»

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

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

اما این هم هنوز کافی نیست. باید کسانی که خودشان در آن حوزه حضور دارند نیز بتوانند این تخصص را ببینند و درباره آن صحبت کنند. اینجاست که مفهوم Entity و Context برای من معنای عمیق تری پیدا می کند.

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

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

خود اکوسیستم شروع به توضیح دادن آن برند می کند.

به نظر من، تفاوت مهم SEO چند سال پیش با چیزی که امروز در حال شکل گیری است نیز دقیقاً همین جاست. در گذشته، گاهی تلاش می کردیم نام برند را در همه جا ببینیم؛ مثل همان بنری که روی دیوار می زنیم تا همه بدانند اینجا چه کسی حضور دارد. اما امروز مسئله فقط این نیست که نام شما دیده شود. مسئله این است که وقتی نام شما دیده شد، چه چیزی درباره شما قابل فهم باشد.

اگر نام یک برند در ده ها صفحه وجود داشته باشد اما هیچ تصویر مشخصی از تخصص، دانش، ارتباطات و جایگاه آن ایجاد نکند، صرف دیده شدن نام، دانش چندانی تولید نمی کند. در مقابل، اگر هر حضور دیجیتال برند بخشی از یک تصویر بزرگ تر را تکمیل کند، به تدریج یک هویت دانشی شکل می گیرد. در اینجا، Entity دیگر صرفاً یک «نام» نیست؛ نماینده یک هویت در شبکه دانش است. و Context همان چیزی است که به این هویت معنا می دهد. شاید بتوان تفاوت این دو دوره را خیلی ساده این طور بیان کرد:

قبلاً می گفتیم: «من هستم.»

امروز باید کاری کنیم که دیگران بتوانند بفهمند «من چه هستم».

و این تفاوت کوچکی نیست. در گذشته ممکن بود با تبلیغ، رتبه، لینک یا تکرار نام بتوانیم توجه ایجاد کنیم. اما توجه با اعتبار یکی نیست. اعتبار زمانی شکل می گیرد که آنچه درباره خودمان می گوییم، با آنچه در رفتار، محتوا و ارتباطات ما دیده می شود همخوانی داشته باشد و دیگران نیز بتوانند آن را تأیید کنند. به همین دلیل، من Entity را جدا از Context نمی بینم.

یک برند بدون Context فقط یک اسم است؛ Context است که به آن اسم معنا، جایگاه و اعتبار می دهد.

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

اگر دانش را درست ساخته باشیم، خود اکوسیستم به جای ما خواهد گفت که هستیم.

معماری دانش؛ قبل از تولید محتوا باید چه چیزی ساخته شود؟

یکی از مهم ترین تغییرات در معماری محتوا، تغییر نقطه شروع است. در بسیاری از فرایندهای سنتی تولید محتوا، کار با یک کلمه کلیدی، یک موضوع یا حتی یک عنوان آغاز می شد و سپس نویسنده تلاش می کرد متنی مناسب برای آن تولید کند. در این مدل، معماری معمولاً بعد از شکل گیری محتوا معنا پیدا می کرد. اما اگر قرار باشد یک سایت به یک منبع دانشی تبدیل شود، بهتر است مسیر برعکس شود. ابتدا باید دانش را معماری کرد و سپس محتوا را روی آن معماری ساخت.

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

ترسیم Knowledge Graph و روابط میان مفاهیم

Knowledge Graph را می توان یکی از ابزارهای مهم برای دیدن ساختار دانش پیش از تولید محتوا دانست. هدف از آن صرفاً ترسیم چند دایره و خط میان مفاهیم نیست. مسئله اصلی این است که بفهمیم چه چیزهایی را می دانیم و این دانسته ها چگونه به یکدیگر متصل هستند.

فرض کنیم موضوع اصلی یک سایت «بازاریابی دیجیتال» باشد. این موضوع می تواند با Entityهایی مانند SEO، Content Marketing، AI Search، برند، کاربر، موتور جستجو، مدل زبانی، ابزارهای تحلیلی و ده ها مفهوم دیگر ارتباط داشته باشد. اما ارزش Knowledge Graph زمانی مشخص می شود که رابطه میان این عناصر نیز مشخص شود.

مثلاً:

Brand → دارای → Entity

Entity → مرتبط با → Topic

Topic → پاسخ دهنده به → User Intent

Content → توضیح دهنده → Topic

Author → متخصص در → Topic

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

این نگاه یک مزیت مهم دیگر هم دارد. وقتی شبکه دانش قبل از تولید محتوا ترسیم شود، احتمال تولید محتوای تکراری، پراکنده یا بی ارتباط کاهش پیدا می کند. به جای اینکه هر بار از صفر تصمیم بگیریم چه چیزی بنویسیم، می توانیم ببینیم در کدام قسمت از شبکه هنوز دانش کافی نداریم. در نتیجه، Knowledge Graph پیش از آنکه ابزار نمایش دانش باشد، می تواند ابزار طراحی آن باشد.

Entity Mapping و شناسایی موجودیت های اصلی و فرعی

بعد از مشخص شدن حوزه کلی، باید بدانیم چه موجودیت هایی در آن حوزه اهمیت دارند. Entity Mapping دقیقاً با همین مسئله سروکار دارد. در یک موضوع مشخص، همه موجودیت ها اهمیت یکسانی ندارند. برخی Entityهای اصلی هستند و بخش مرکزی دانش را تشکیل می دهند و برخی دیگر برای توضیح، تکمیل یا ایجاد Context در کنار آن ها قرار می گیرند.

برای مثال، اگر موضوع یک سایت «دوربین عکاسی» باشد، دوربین یک Entity اصلی است. اما برند دوربین، مدل، لنز، سنسور، عکاس، سبک عکاسی، کاربرد، قیمت و حتی نرم افزارهای مرتبط می توانند Entityهای مرتبط باشند.

این مرحله کمک می کند قبل از تولید محتوا بدانیم دقیقاً درباره چه چیزهایی صحبت خواهیم کرد. نکته مهم این است که Entity Mapping نباید تبدیل به یک فهرست بلند از کلمات و اسامی شود. ارزش آن زمانی ایجاد می شود که مشخص کنیم هر Entity چه نقشی در دانش موضوع دارد و با چه Entityهای دیگری ارتباط دارد.

برای برند نیز همین مسئله اهمیت دارد.

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

Question Mapping و اتصال پرسش ها به دانش

دانش زمانی ارزشمند است که بتواند مسئله ای را حل کند. به همین دلیل، بعد از شناسایی Entityها باید بدانیم کاربران درباره آن ها چه می پرسند. اینجاست که Question Mapping وارد معماری می شود. در این مرحله، سؤال ها صرفاً برای پیدا کردن Keyword جدید استخراج نمی شوند. هدف این است که بفهمیم کاربر برای شناخت یک موضوع، چه مسیر پرسشی را طی می کند.

برای مثال، درباره یک مفهوم ممکن است پرسش های زیر شکل بگیرد:

• این مفهوم چیست؟
• چرا اهمیت دارد؟
• چگونه کار می کند؟
• چه تفاوتی با مفهوم مشابه دارد؟
• چه مزایا و محدودیت هایی دارد؟
• چگونه می توان آن را اجرا کرد؟
• چه اشتباهاتی در استفاده از آن وجود دارد؟
• در چه شرایطی نباید از آن استفاده کرد؟

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

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

این همان نقطه ای است که Intent با معماری دانش ارتباط پیدا می کند. کاربر ممکن است یک سؤال کوتاه بپرسد، اما پشت آن سؤال چند نیاز اطلاعاتی وجود داشته باشد. معماری خوب باید بتواند این نیازها را شناسایی کند و پاسخ ها را در جای مناسب قرار دهد. بنابراین Question Mapping فقط نقشه سؤال ها نیست؛ نقشه مسیر فهم کاربر است.

Knowledge Coverage و تشخیص شکاف های دانشی

وقتی Entityها، روابط و پرسش ها مشخص شدند، تازه می توان فهمید چه چیزی کم داریم. این مرحله با مفهوم Knowledge Coverage ارتباط دارد. در اینجا مسئله دیگر این نیست که چند مقاله منتشر کرده ایم یا چند Keyword را پوشش داده ایم. مسئله این است که چه مقدار از دانش مورد نیاز برای درک کامل یک موضوع را پوشش داده ایم؟

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

در این مرحله می توان بررسی کرد:

• چه Entityهایی هنوز توضیح داده نشده اند؟
• کدام پرسش های مهم بدون پاسخ مانده اند؟
• چه روابطی میان مفاهیم هنوز توضیح داده نشده است؟
• کدام موضوعات بیش از حد پوشش داده شده اند؟
• کدام بخش ها به منبع، مثال یا شواهد بیشتری نیاز دارند؟

در نتیجه، تولید محتوا از یک فعالیت دائمی و گاهی بی هدف، به یک فرایند Gap Closing تبدیل می شود. به جای اینکه صرفاً بگوییم «این هفته چه مقاله ای منتشر کنیم؟»، می پرسیم: «کدام بخش از دانش ما هنوز ناقص است؟» این تغییر سؤال، تغییر بزرگی در استراتژی محتوا ایجاد می کند.

تبدیل نقشه دانش به معماری محتوا

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

• کدام موضوع باید یک Pillar باشد.
• کدام موضوعات باید به عنوان Cluster توسعه پیدا کنند.
• هر مقاله قرار است چه Entityهایی را پوشش دهد.
• هر Heading قرار است به چه پرسشی پاسخ دهد.
• چه صفحاتی باید به یکدیگر لینک شوند.
• کدام محتوا باید مرجع اصلی یک مفهوم باشد.
• چه بخش هایی باید در چند صفحه مختلف به یکدیگر متصل شوند.
• و هر محتوا چه نقشی در تکمیل دانش کلی سایت دارد.

در این نگاه، ساختار محتوا دیگر فقط مجموعه ای از H1، H2 و H3 نیست. Heading ساختار ظاهری محتواست؛ معماری دانش ساختار معنایی آن است. این تفاوت بسیار مهم است. ممکن است دو مقاله دقیقاً از ساختار H1 و H2 مناسبی برخوردار باشند، اما تنها یکی از آن ها بخشی از یک معماری دانشی بزرگ تر باشد. در معماری دانش محور، هر صفحه باید جایگاه خود را بداند.

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

Entityها مشخص می کنند درباره چه چیزهایی صحبت می کنیم.

Knowledge Graph نشان می دهد این چیزها چگونه به هم مرتبط هستند.

Question Mapping مشخص می کند کاربران درباره آن ها چه می خواهند بدانند.

Knowledge Coverage نشان می دهد چه بخش هایی هنوز ناقص هستند.

و در نهایت، Content Architecture این نقشه را به محتوایی قابل فهم برای انسان و ماشین تبدیل می کند.

شاید بتوان کل این فرایند را در یک جمله خلاصه کرد:

محتوای خوب از یک عنوان خوب شروع نمی شود؛ از یک نقشه دانشی درست شروع می شود.

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

دیدگاه فرهود

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

برای رسیدن به این هدف، معمولاً لازم نبود دانش جدید زیادی به او بدهم.

گاهی چیزی را قبلاً یاد گرفته بود، اما در لحظه به خاطر نمی آورد. گاهی فقط یک مفهوم کوچک و به ظاهر ساده را نمی دانست و با یاد گرفتن همان نکته، مسیر حل مسئله برایش روشن می شد. گاهی هم دانش مورد نیاز را قبلاً به شکل دیگری یاد گرفته بود، اما هنوز نتوانسته بود ارتباط آن را با مسئله جدید پیدا کند.

بنابراین، کاری که من انجام می دادم بیشتر از اینکه «ارائه پاسخ» باشد، ایجاد پل میان دانسته های قبلی و مسئله جدید بود.

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

به نظر من، معماری دانش در یک سایت نیز دقیقاً باید همین نگاه را داشته باشد.

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

باید بدانیم برای فهمیدن این موضوع، کاربر چه دانش قبلی را نیاز دارد، چه مفاهیمی را ممکن است نداند، چه ارتباطی میان این مفاهیم وجود دارد و این مفاهیم با چه ترتیبی بهتر درک می شوند.

در واقع، شاید یک کاربر برای فهمیدن یک مفهوم جدید به ده قطعه دانش نیاز داشته باشد، اما لازم نباشد همه آن ده مورد را از ابتدا برای او توضیح دهیم. ممکن است هفت مورد را قبلاً بداند، دو مورد را فراموش کرده باشد و فقط یکی را اصلاً نشناسد.

اگر معماری دانش درستی داشته باشیم، می توانیم این مسیر را طراحی کنیم.

به همین دلیل، من Knowledge Coverage را صرفاً به معنای «پوشش دادن همه موضوعات» نمی دانم. پوشش واقعی زمانی اتفاق می افتد که دانش های لازم برای فهم یک موضوع، همراه با روابط میان آن ها و مسیر رسیدن از یک مفهوم به مفهوم دیگر در اختیار کاربر قرار گرفته باشد.

این موضوع یک تفاوت مهم ایجاد می کند.

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

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

اینجا دیگر با Content Collection مواجه نیستیم؛ با Knowledge Architecture مواجهیم.

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

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

بنابراین، وقتی درباره معماری دانش صحبت می کنم، منظورم فقط این نیست که:

«چه چیزی را باید به کاربر بگوییم؟»

بلکه چند سؤال دیگر نیز باید همزمان مطرح شوند:

کاربر برای فهم این موضوع چه چیزهایی را باید بداند؟

کدام یک از این دانش ها را احتمالاً از قبل دارد؟

کدام مفهوم ممکن است برای او گم شده باشد؟

این مفاهیم چگونه به یکدیگر متصل می شوند؟

و مهم تر از همه، ترتیب طبیعی حرکت از یک مفهوم به مفهوم بعدی چیست؟

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

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

یک سایت تخصصی نیز باید همین کار را انجام دهد.

دانش را ارائه کند، ارتباط میان دانش ها را بسازد و مسیر رسیدن به درک را برای کاربر روشن کند.

در نهایت، شاید بهترین معماری محتوا آن معماری نباشد که بیشترین پاسخ های آماده را در اختیار کاربر می گذارد؛ بلکه معماری ای باشد که حتی بعد از خواندن محتوا، چیزی در ذهن کاربر ساخته باشد که بتواند با استفاده از آن، سؤال بعدی را خودش پاسخ دهد.

و به نظر من، این دقیقاً تفاوت میان انتقال اطلاعات و ساختن دانش است.

Semantic Structure؛ محتوا چگونه برای ماشین قابل فهم می شود؟

وقتی درباره قابل فهم بودن محتوا برای مدل های زبانی صحبت می کنیم، نباید تصور کنیم که مسئله فقط به استفاده از کلمات درست یا قرار دادن چند Keyword در متن محدود می شود. یک متن ممکن است از نظر واژگان بسیار غنی باشد، اما همچنان ساختار معنایی روشنی نداشته باشد.

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

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

ارتباط معنایی میان مفاهیم، موجودیت ها و موضوعات

معنا معمولاً در یک مفهوم منفرد قرار ندارد؛ بخش زیادی از معنا از رابطه میان مفاهیم شکل می گیرد. فرض کنیم درباره «مدل های زبانی» صحبت می کنیم. این مفهوم می تواند با Entityهایی مانند OpenAI، Google، Anthropic، Retrieval، Training Data، AI Citation و Generative Search ارتباط داشته باشد. اما صرف حضور این نام ها در یک مقاله، ساختار معنایی ایجاد نمی کند. باید مشخص شود این موجودیت ها چه رابطه ای با موضوع دارند.

مثلاً Retrieval چه نقشی در پاسخگویی مدل های زبانی دارد؟ Training Data چه تفاوتی با اطلاعات بازیابی شده دارد؟ AI Citation چگونه با انتخاب منابع ارتباط پیدا می کند؟ Generative Search چه تفاوتی با جستجوی سنتی دارد؟ وقتی این روابط توضیح داده می شوند، Context شکل می گیرد. بنابراین در معماری Semantic، هدف این نیست که Entityهای بیشتری را در یک صفحه قرار دهیم. هدف این است که روابط معنادار میان آن ها را توضیح دهیم.

این موضوع تفاوت مهمی با Keyword Stuffing دارد. در Keyword Stuffing ممکن است چندین عبارت مرتبط را عمداً در یک صفحه قرار دهیم تا موتور جستجو ارتباط موضوعی را تشخیص دهد. اما در ساختار معنایی، ارتباط باید در خود دانش محتوا وجود داشته باشد. اگر دو مفهوم واقعاً با یکدیگر ارتباط دارند، محتوا باید بتواند این رابطه را توضیح دهد. به همین دلیل، Semantic Structure را می توان نوعی معماری روابط دانست؛ معماری ای که به سیستم کمک می کند بفهمد هر مفهوم در کجای موضوع قرار گرفته است.

Topic، Subtopic و ارتباط میان بخش های محتوا

هر موضوع بزرگ از مجموعه ای از موضوعات کوچک تر تشکیل شده است. اگر موضوع اصلی یک سایت «SEO» باشد، می توانیم با Subtopicهایی مانند Technical SEO، Semantic SEO، Entity SEO، Content Strategy، Internal Linking و بسیاری موضوعات دیگر مواجه شویم. اما صرفاً داشتن این Subtopicها به معنای ساختن یک معماری معنایی نیست. باید مشخص باشد که هر Subtopic چه نسبتی با Topic اصلی دارد و چه نسبتی با سایر Subtopicها دارد.

برای مثال، Semantic SEO می تواند با Entity SEO ارتباط داشته باشد، Entity SEO می تواند با Knowledge Graph مرتبط شود و Knowledge Graph می تواند بخشی از معماری دانش یک سایت باشد. در نتیجه، محتوا نباید به شکل مجموعه ای از جزیره های موضوعی ساخته شود. یک Topic اصلی باید بتواند به Subtopicهای خود معنا بدهد و Subtopicها نیز باید بتوانند درک Topic اصلی را عمیق تر کنند.

این مسئله حتی در ساختار یک مقاله نیز اهمیت دارد.

اگر مقاله ای درباره «معماری محتوای مناسب هوش مصنوعی» نوشته می شود، بخش Entity، بخش Knowledge Graph، بخش Semantic Structure و بخش Schema نباید صرفاً چهار عنوان مستقل باشند. باید مشخص باشد که چرا این بخش ها در کنار یکدیگر قرار گرفته اند و چگونه یک مفهوم بزرگ تر را تکمیل می کنند. در چنین حالتی، مقاله دیگر مجموعه ای از Headingها نیست؛ بلکه مسیر حرکت میان مفاهیم است.

ساختار معنایی Headingها و Paragraphها

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

«نکات مهم»

از نظر معنایی اطلاعات کمی در اختیار خواننده و ماشین قرار می دهد.

در مقابل:

«نقش Entity در شکل گیری Context برای مدل های زبانی»

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

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

به همین ترتیب، Heading باید محدوده آن بخش را مشخص کند و Paragraphهای زیر آن باید همان محدوده را توسعه دهند. در چنین ساختاری، ارتباط میان:

Heading → Paragraph → Concept → Entity → Context

روشن تر می شود.

این همان چیزی است که باعث می شود ساختار محتوا علاوه بر انسان، برای سیستم های ماشینی نیز قابل تفسیرتر باشد.

Context و جلوگیری از تولید محتوای جزیره ای

یکی از مشکلات رایج در سایت های محتوایی، تولید Island Content است. مقاله منتشر می شود، اطلاعاتی ارائه می دهد و حتی ممکن است رتبه خوبی هم بگیرد، اما هیچ ارتباط معناداری با سایر دانش موجود در سایت ندارد. این محتوا شبیه جزیره ای است که در نقشه سایت قرار گرفته، اما جاده ای به آن وجود ندارد. Context دقیقاً برای جلوگیری از این اتفاق اهمیت دارد.

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

برای مثال، اگر مقاله ای درباره Citation Engineering نوشته شده است، نباید صرفاً تعریف این مفهوم را ارائه کند. باید مشخص باشد که Citation Engineering چه ارتباطی با Entity SEO، اعتبار برند، Reference Content و GEO دارد.

در این صورت، مقاله به بخشی از یک Knowledge Ecosystem تبدیل می شود. در غیر این صورت، فقط یک صفحه دیگر به آرشیو سایت اضافه شده است. از همین جا اهمیت Context روشن می شود:

محتوا زمانی واقعاً معنا پیدا می کند که جایگاه آن در میان سایر دانش ها مشخص باشد.

طراحی Content Chunkهای مستقل و قابل بازیابی

در معماری محتوای مناسب برای هوش مصنوعی، یک تغییر مهم دیگر نیز باید در نظر گرفته شود: ممکن است تمام مقاله شما یکجا مصرف نشود. یک مدل زبانی یا سیستم Retrieval ممکن است تنها بخش مشخصی از یک صفحه را برای پاسخ به سؤال کاربر بازیابی کند. بنابراین، باید محتوا را به واحدهایی تقسیم کنیم که هر کدام بتوانند یک مفهوم یا مسئله مشخص را تا حد مناسبی پوشش دهند. به این واحدها می توان Content Chunk یا در نگاه دانشی تر، Knowledge Unit گفت.

یک Chunk خوب نباید صرفاً چند جمله بریده شده از یک مقاله باشد. باید Context کافی داشته باشد تا اگر از بخش های دیگر جدا شد، هنوز مشخص باشد درباره چه موضوعی صحبت می کند.

برای مثال، جمله:

«این روش باعث افزایش دقت می شود.»

به تنهایی تقریباً هیچ اطلاعاتی ندارد.

افزایش دقت چه چیزی؟ کدام روش؟ در چه شرایطی؟

اما اگر Chunk مشخص کند:

«در فرآیند Retrieval، استفاده از محتوای دارای Context مشخص می تواند به سیستم کمک کند بخش مرتبط تری از دانش را برای پاسخ به پرسش کاربر بازیابی کند.»

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

هر Chunk باید تا حد امکان:

• یک مفهوم مشخص داشته باشد.
• Context کافی برای فهم آن ارائه کند.
• بتواند یک سؤال یا بخشی از یک نیاز اطلاعاتی را پاسخ دهد.
• ارتباط خود را با موضوع اصلی حفظ کند.
• در صورت بازیابی مستقل، همچنان قابل تفسیر باشد.

در نتیجه، معماری Semantic فقط درباره ساختار صفحه نیست.

ما در واقع چند لایه را همزمان معماری می کنیم:

Topic مشخص می کند موضوع اصلی چیست.

Subtopic موضوع را به بخش های معنادار تقسیم می کند.

Entity مشخص می کند چه موجودیت هایی در این دانش حضور دارند.

Relationship ارتباط میان آن ها را روشن می کند.

Heading و Paragraph این ساختار را در سطح صفحه به زبان قابل فهم تبدیل می کنند.

و Content Chunk دانش را به واحدهایی تبدیل می کند که می توانند مستقل از کل صفحه نیز قابل استفاده و بازیابی باشند.

در نهایت، یک اصل ساده باقی می ماند:

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

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

Semantic Structure؛ ارتباط های ساختار یافته و اصولی

اگر بخواهیم Semantic Structure را خیلی ساده توضیح دهیم، شاید یکی از بهترین مثال ها صحنه هایی باشد که در فیلم های جنایی می بینیم. کارآگاه را تصور کنید که پشت یک میز یا مقابل یک برد ایستاده است. یک عکس از مظنون روی برد قرار دارد، کنار آن نقشه ای از شهر دیده می شود، چند منطقه روی نقشه علامت خورده، تصویر یک خودرو در گوشه ای قرار گرفته، یک شیء پیدا شده از محل حادثه هم روی میز است و شاید نام چند نفر نیز روی برگه های مختلف نوشته شده باشد.

اما هیچ کدام از این اطلاعات به تنهایی معما را حل نمی کنند.

عکس، فقط یک عکس است.
نقشه، فقط یک نقشه است.
شیء پیدا شده، فقط یک شیء است.

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

در واقع، معما از جایی حل می شود که اطلاعات از حالت پراکنده خارج شده و به یک ساختار مرتبط تبدیل می شوند. این دقیقاً همان چیزی است که در Semantic Structure به دنبال آن هستیم.

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

برای مثال، اگر در یک سایت مشخص باشد که:

این برند چه کسی است،
چه نویسنده ای درباره آن موضوع می نویسد،
نویسنده در چه حوزه ای تخصص دارد،
این موضوع با چه Entityهایی ارتباط دارد،
این مقاله کدام پرسش را پاسخ می دهد،
و این پرسش در کدام بخش از Knowledge Ecosystem قرار گرفته است،

دیگر با مجموعه ای از صفحات مستقل مواجه نیستیم. ما یک ساختار دانشی ساخته ایم. به همین دلیل، Semantic Structure را نباید صرفاً «استفاده درست از Headingها، Paragraphها و لینک های داخلی» بدانیم. این موارد ابزارهای ایجاد ساختار هستند، اما خود ساختار نیستند.

ساختار زمانی شکل می گیرد که بتوانیم رابطه میان اجزای دانش را مشخص کنیم.

در واقع، می توان گفت:

Semantic Structure یعنی تبدیل اطلاعات پراکنده به مجموعه ای از مفاهیم مرتبط، به گونه ای که رابطه میان آن ها قابل درک و قابل استفاده باشد.

این نگاه تفاوت مهمی با معماری محتوای قدیمی دارد. در گذشته ممکن بود بگوییم:

«برای این Keyword یک مقاله بنویس.»

بعد برای Keyword دیگری مقاله دیگری تولید کنیم و در نهایت چندین صفحه داشته باشیم که هر کدام به تنهایی اطلاعات مناسبی ارائه می کنند. اما سؤال مهم تر این است:

این صفحات چه چیزی به یکدیگر اضافه می کنند؟

چه رابطه ای میان آن ها وجود دارد؟

اگر کاربر این مقاله را خواند، برای فهم مقاله بعدی چه چیزی از آن با خود خواهد داشت؟

و مهم تر از همه:

آیا این صفحات در کنار هم یک دانش منسجم می سازند یا فقط مجموعه ای از اطلاعات پراکنده هستند؟

از این منظر، Semantic Structure همان برد کارآگاه است. ما فقط اطلاعات را روی برد نمی چسبانیم؛ رشته ارتباط میان آن ها را پیدا می کنیم. و شاید همین جا بتوانیم یکی از تفاوت های مهم میان Information و Knowledge را نیز ببینیم:

Information می گوید چه چیزی وجود دارد.
Knowledge نشان می دهد این چیزها چگونه به یکدیگر مربوط هستند.

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

«چه اطلاعاتی داریم؟»

بلکه باید بپرسیم:

«این اطلاعات چگونه به یکدیگر متصل هستند؟»

چون گاهی پاسخ یک سؤال در هیچ اطلاعات جدیدی پنهان نشده است.

پاسخ از ارتباط درست میان اطلاعاتی به دست می آید که از قبل وجود داشته اند.

و این، به نظرم، یکی از ساده ترین و دقیق ترین راه ها برای فهم Semantic Structure است:

اطلاعات را روی برد قرار نده؛ ارتباط میان آنها را پیدا کن.