Каждый аудит ИИ добавляет в вашу дорожную карту еще одну аббревиатуру. Архитектура знаний — это возможность, которая определяет следующее решение о публикации.

Недавно я попал в еще один разговор, который стал все более знакомым. Высокопоставленный руководитель получил предупреждение от поставщика оценки видимости ИИ о том, что компания недостаточно подготовлена ​​к поиску ИИ. Среди рекомендаций было то, что появлялось чаще: компании нужен файл llms.txt.

<п>Внезапно возникший и до сих пор обсуждаемый формат публикации стал предметом беспокойства руководителей. Теперь кому-то нужно было определить, действительна ли рекомендация, оценить потенциальное воздействие, объяснить, почему компания еще не внедрила ее, и решить, следует ли перенаправить маркетинговые и инженерные ресурсы для ее решения.

Недавно я писал об этом явлении в рамках того, что я называю налогом AI FUD. Стоимость отдельной рекомендации может быть относительно небольшой, но организационные затраты на постоянное реагирование на последний внешний аудит ИИ могут стать существенными. Каждый новый аудит, презентация поставщика, протокол, аббревиатура или конкурентное заявление порождает новый раунд вопросов о том, не отстает ли организация.

<п>Проблема не в llms.txt, MCP, уценке или какой-то конкретной технологии. На самом деле они делают разные вещи. Некоторые помогают машинам обнаруживать информацию, некоторые предоставляют альтернативные способы ее представления, а третьи определяют, как системы обмениваются ею или получают к ней доступ. Технически объединять их вместе было бы неточно, но стратегически они создают один и тот же организационный искушение: рассматривать новейший механизм доставки как решение, а не изучать лежащие в его основе знания. Ошибка состоит в том, чтобы относиться к каждому из них так, как будто он представляет собой новую стратегию.

<п>После десятилетий наблюдения за вариациями этого цикла я считаю, что мы снова уделяем слишком много внимания формату и недостаточно информации, которую эти форматы должны передавать. Вместо того, чтобы сразу спрашивать: «Нужно ли нам реализовать это?», организациям следует сначала задать более фундаментальный вопрос:

“Есть ли у нас необходимые знания, чтобы поддержать это?”

Это различие становится все более важным, поскольку ИИ создает для машин все больше способов потребления организационной информации. Если базовые знания неполны, фрагментированы, противоречивы или заперты внутри отдельных отделов, добавление другого машиночитаемого формата не решит проблему. Это просто создает еще одно место для публикации тех же ограничений.

<п>Организации, которые лучше всего адаптируются, не обязательно будут теми, которые первыми внедряют каждый новый протокол. Они будут теми, кто достаточно хорошо организует и управляет своими знаниями, чтобы поддержка следующего полезного формата стала решением о публикации, а не очередным проектом реконструкции.

Охват решений создает следующий вопрос

<п>

Представьте себе клиента, который просит лучший пляжный курорт для семейного отдыха в Канкуне. “Лучший” не является атрибутом, который отель может просто добавить на страницу. Рекомендация может зависеть от доступа к пляжу, пригодности для семей, конфигурации номера, удобств, цены, наличия мест, отзывов и других критериев, вытекающих из запроса. ИИ должен оценить эти условия коллективно, прежде чем решить, какие свойства подлежат рассмотрению.

<п>Покрытие решений решает ту же проблему со стороны организации. Как только мы поймем переменные, влияющие на решение, мы сможем определить, есть ли у организации авторитетные доказательства, подтверждающие их. Если критический критерий не может быть обоснован, проблема может заключаться не в том, что бренд имеет низкий рейтинг. Возможно, он так и не предоставил достаточно доказательств, чтобы сделать вывод.

Это дает нам более надежный способ диагностировать недостаточную видимость ИИ. Вместо того, чтобы заметить, что конкурента порекомендовали, и немедленно ответить еще большим количеством контента типа «я тоже паритет», больше связей или другая сложная техническая реализация, мы должны деконструировать решение, определить критерии, влияющие на квалификацию, и определить, где наши подтверждающие доказательства являются неполными.

Другими словами, мы можем начать двигаться от простого наблюдения за тем, что произошло, к поиску доказательств того, почему это произошло. Однако, как только мы узнаем, какие доказательства должны существовать, Decision Coverage поднимает другой вопрос: Где должны находиться эти знания и как мы можем гарантировать, что каждая система получит один и тот же полный ответ?

Именно здесь одержимость этими новыми индивидуальными форматами начинает создавать проблемы.

Новый формат не поможет исправить недостающие знания

<п>Самый простой ответ на пробел в охвате решений — это поместить недостающую информацию в любой формат, который в данный момент привлекает внимание. Ежедневно LinkedIn переполнен рекомендациями по расширению схемы, созданию версии с уценкой или созданию конечной точки MCP и, да, развертыванию llms.txt.

Это может решить непосредственную проблему публикации, но не обязательно решает основную проблему знаний. Если решение клиента зависит от пяти значимых критериев, а организация может обосновать только четыре, публикация тех же четырех доказательств посредством другого протокола не приведет внезапно к установлению пятого. Мы просто предоставили тот же пробел в доказательствах в другом формате.

Это различие кажется очевидным, однако большая часть сегодняшних обсуждений реализации ИИ меняет порядок, сосредотачиваясь на цитатах, а не на источниках или методах интеграции. Расширенная схема может описывать отношения между сущностями, но не может определить, какими должны быть эти отношения. MCP может сделать множество организационных ресурсов доступными для систем искусственного интеллекта, но не может определить, содержат ли эти ресурсы знания, необходимые для ответа на вопрос клиента. Файл llms.txt может указывать машинам на информацию, но он не может компенсировать информацию, которую организация никогда не создавала.

<п>Все эти форматы являются механизмами передачи и передачи знаний. Их ценность в конечном итоге зависит от полноты и качества того, что в них вкладывают организации. Я видел более 100 проверок готовности агентов, все из которых отмечали наличие файла llms.txt, но ни один из них не критиковал глубину или качество файла для тех, у кого они были.

<п>Именно поэтому так важна нынешняя дискуссия о целостности данных. В своей недавней статье в журнале Search Engine Journal Алекс Мосс утверждает, что техническому SEO все чаще необходимо сосредотачиваться на максимизации целостности данных, поскольку системы искусственного интеллекта зависят от точных сущностей, явных связей, машиночитаемых форматов, действий и надежных сигналов восприятия. Он также сделал важное замечание, которое тесно согласуется с моим аргументом: вместо того, чтобы пытаться предсказать, какой новый протокол в конечном итоге победит, организациям следует укрепить базовые уровни, от которых зависят эти протоколы.

Целостность данных, однако, также порождает предшествующий организационный вопрос. Прежде чем мы сможем гарантировать, что информация остается точной, синхронизированной и заслуживающей доверия, нам необходимо определить, какие знания должны существовать, как эти фрагменты связаны друг с другом, кто ими владеет и какой источник следует считать авторитетным.

Целостность данных помогает гарантировать, что информация остается достоверной после ее существования. Архитектура знаний помогает гарантировать, что нужные знания существуют, правильно связаны и ими можно управлять как активом организации. И то и другое становится все более важным, поскольку системы ИИ полагаются на нашу информацию для принятия решений, а не просто возвращают документы.

Создайте базу один раз, публикуйте повсюду

<п>Во время недавнего вебинара я попытался упростить эту все более сложную среду ИИ до единого принципа: создайте каноническую базу один раз. Публикуйте везде.

Изображение автора, август 2026 г.

Идея намеренно проста, поскольку организациям не нужен другой акроним или протокол для управления. Им нужно перестать восстанавливать одни и те же знания для каждого нового пункта назначения.

<п>В основе лежат факты, взаимоотношения, политика, опыт, критерии принятия решений потребителями и подтверждающие доказательства, которые организация может авторитетно предоставить. Эти элементы необходимо зафиксировать в каноническом источнике знаний, где их можно будет связывать, управлять, обновлять и повторно использовать независимо от какого-либо конкретного формата публикации. Организации, ориентированные на искусственный интеллект, такие как Milestone, встроили его в свою систему управления контентом как канонический источник правды, способный выводить данные в любые текущие и новые форматы разметки.

Decision Coverage помогает нам определить, достаточно ли полны эти знания для поддержки важных решений клиента. Архитектура знаний обеспечивает способ организации и поддержания знаний. Различные форматы затем становятся механизмами доставки, позволяющими сделать соответствующие части этих знаний доступными для систем, которые в них нуждаются.

Сегодня эти механизмы доставки могут включать веб-контент, разметку схемы, фиды Merchant Center, API, уценку, MCP, llms.txt и другие новые форматы. Завтра список почти наверняка будет другим.

<п>Это не должно требовать восстановления базовых знаний. <п>Если каждый формат публикации поддерживает свою собственную версию фактов организации и свидетельств принятия решений, каждое обновление создает проблемы синхронизации, а каждый новый протокол создает новый проект реализации. Если эти форматы основаны на общем управляемом источнике знаний, архитектура кардинально меняется. Сложная работа происходит на уровне знаний, а уровень публикации адаптируется по мере изменения технологий и требований.

Это то, что я называю архитектурой знаний. Именно организационные возможности позволяют последовательно собирать, контролировать и доставлять проверенные знания везде, где они создают ценность.

Публикация невозможна

Это различие также объясняет некоторое мое разочарование по поводу все более свободного использования таких терминов, как «AI-готовность»; и «агент готов».

<п>Поддержка агентно-ориентированного протокола, безусловно, может облегчить взаимодействие агента с системами организации. Это полезная инфраструктура, но это не означает автоматически, что организация обладает знаниями, необходимыми агенту для принятия полезного решения.

На самом деле это две разные проблемы. Первый — организационные возможности: Может ли компания собирать, подключать, управлять, поддерживать и извлекать знания, необходимые клиентам и машинам? Второй — публикация: Может ли эти знания быть выражены через формат, требуемый конкретной поисковой системой, платформой искусственного интеллекта, агентом, приложением или протоколом?

<п>Один из моих аргументов в пользу этих форматов разметки заключается в том, что они исходят из решения поставщика, обещающего четко определенный результат. Они решают настоящую проблему для систем искусственного интеллекта: хаос современного веб-сайта, ориентированного на маркетинг, и это облегчает продажу. Некоторые из их инструментов показывают, как быстро и легко они могут создать формат, практически не упоминая о том, как они могут использовать организационные знания, поскольку ни один протокол не может создать их за нас.

<п>Протокол не может согласовать противоречивую информацию о продуктах, принадлежащую разным отделам. Он не может извлечь экспертные знания, живущие в голове продавца, определить, какие возражения клиентов имеют значение, установить, как политика влияет на конкретный продукт, или создать недостающие доказательства, выявленные с помощью покрытия решений. Это проблемы организационных знаний, которые необходимо решить, прежде чем технологии смогут дать ответы.

<п>Технологии могут раскрыть организационные возможности, но не могут заменить их.

Вот почему организации не становятся готовыми к использованию ИИ, просто внедряя больше протоколов. Они становятся готовыми к использованию ИИ, организуя свои знания настолько хорошо, что каждый полезный протокол становится еще одним местом публикации, а не очередной попыткой реконструировать то, что знает организация.

<ч2>Упорядочение знаний для принятия решений <п>На протяжении большей части истории Интернета основное внимание уделялось созданию коллекций страниц и управлению ими; Платформы CMS укрепили эту структуру, и SEO естественным образом оптимизировало страницы продуктов, страницы категорий, статьи, часто задаваемые вопросы и целевые страницы, поскольку страницы были основными единицами, с помощью которых поисковые системы получали информацию, а клиенты ее потребляли.

ИИ ослабляет эту связь.

Один вопрос клиента теперь может заставить систему искусственного интеллекта получать информацию с нескольких страниц, каналов продуктов, структурированных данных, обзоров, внешних источников, баз данных и других хранилищ знаний, прежде чем синтезировать ответ. Целевая веб-страница остается важной, но она больше не обязательно является единицей, вокруг которой строится решение.

Более надежный принцип организации – это решение клиента.

<п><эм>Что нужно знать покупателю? Какие критерии определяют, соответствует ли продукт требованиям? Какие доказательства подтверждают эти критерии? Какие альтернативы необходимо сравнивать? Какие компромиссы следует понимать? Какие политики, местоположения, ограничения доступности или другие отношения влияют на результат?

<стр>Эти вопросы напрямую связаны со структурой покрытия решений. Если мы поймем условия, которые в совокупности определяют, попадет ли продукт, услуга или организация в число кандидатов, мы сможем определить доказательства, необходимые для поддержки каждого условия. Канонический источник знаний затем обеспечивает управляемый дом для этих свидетельств, а отдельные форматы определяют, как они доставляются.

<п>Вот почему погоня за выходными форматами возвращает последовательность назад. Мы не должны начинать с пустого протокола и спрашивать, какую информацию мы можем в него поместить. Мы должны начать с решений клиентов, которые нам необходимо поддержать, убедиться, что доказательства, необходимые для этих решений, существуют, а затем определить, какие механизмы доставки делают эти знания доступными для систем, влияющих на результат.

Это инфраструктура, а не очередная тактика ИИ

Этот аргумент должен показаться знакомым всем, кто следил за моими предыдущими статьями в журнале Search Engine Journal, поскольку он расширяет позицию, которую я придерживаюсь уже некоторое время. В “SEO — это не тактика. Это инфраструктура для роста” Я утверждаю, что устойчивая производительность поиска зависит от возможностей, встроенных во всю организацию, а не от отдельных проектов оптимизации. Поиск работает лучше всего, когда продукт, контент, технология и бизнес-стратегия связаны с тем, как клиенты на самом деле находят, оценивают и выбирают решения. <п>Позже я ввел понятие «разрыв поискового капитала», чтобы количественно оценить потерю бизнес-ценности, когда организациям не удается обеспечить квалифицированную видимость, которую они должны разумно зарабатывать. В этой статье также подчеркивается растущее влияние технологий «нулевого клика» и поиска с помощью искусственного интеллекта, при которых видимость может сохраняться даже при изменении экономики взаимодействия с клиентами.

<п>Эти идеи становятся все более взаимосвязанными по мере развития ИИ. Суверенитет бренда устанавливает необходимость для организаций стать авторитетным источником собственных фактов и опыта. Click Worthiness помогает определить, где дальнейшее взаимодействие приносит достаточную дополнительную ценность для клиентов и бизнеса, чтобы оправдать инвестиции. Покрытие решений спрашивает, предоставили ли мы доказательства, которые ИИ должен оценить, сравнить, квалифицировать и с уверенностью рекомендовать нас.

<стр>Архитектура знаний обеспечивает прочную основу для этих возможностей.

Без достоверной организационной информации становится трудно установить суверенитет бренда. Без понимания решений клиентов становится сложно определить приоритет кликабельности. Без полных доказательств решения освещение решений остается неполным. Без архитектуры, способной управлять этими знаниями и повторно использовать их, каждый новый формат ИИ отправляет организацию обратно в новый цикл внедрения.

Вот почему следующий протокол ИИ не спасет стратегию SEO, которой не хватает базовых знаний. Протокол является следствием проблемы.

Следующий протокол не будет последним

<п>Я не знаю, станут ли MCP, llms.txt, Agents.md, UCP или какой-либо другой новый подход сегодня основополагающим стандартом. Некоторые из них, несомненно, станут более важными. Другие будут развиваться, сливаться с чем-то другим или исчезать так же быстро, как и предыдущие технологии, которые когда-то казались необходимыми. Именно из-за этой неопределенности организациям не следует строить свою стратегию ИИ вокруг отдельных форматов. Следующий протокол не будет последним.

Организациям, которые строят свою стратегию на сегодняшних раскрученных форматах, в конечном итоге придется перестраиваться с учетом завтрашних форматов. Организации, которые создают управляемый источник знаний на основе своего бизнес-опыта и решений клиентов, окажутся в совершенно ином положении. Когда появится следующий полезный формат, им не нужно будет заново открывать, воссоздавать и согласовывать необходимые для него знания. Им нужно будет определить, предоставляет ли этот формат новый ценный способ публикации того, что они уже знают.

Это гораздо более устойчивая модель готовности ИИ и, что более важно, гораздо более эффективное использование организационных ресурсов.

Целью не является поддержка всех возможных форматов. Это необходимо для того, чтобы знания, необходимые для принятия важных решений для клиентов, были полными, авторитетными, управляемыми и доступными для доставки в нужных форматах. Протоколы будут продолжать меняться. Механизмы доставки будут продолжать множиться, и консультанты, несомненно, продолжат находить новые элементы для проверки готовности ИИ. Стратегическое реагирование должно оставаться на удивление стабильным.

Постройте базу один раз. Публикуйте везде.