Подготовка контента для RAG-поиска: заголовки сайта

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

На практике сосредоточьтесь на трёх вещах:

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

Кто, как и зачем. Это руководство предназначено для руководителей документации и владельцев веб-контента. Оно объединяет проверку текущей реализации обхода сайта и ответов с источниками в Achla, первичную документацию с указанной датой и контролируемый издателем протокол тестирования. Протокол ещё не выполнялся, поэтому все результаты неизвестны. Цель — помочь издателям проверить изменения, которыми они управляют, а не создать впечатление, будто заголовки гарантируют более качественные ответы.

Что делает контент сайта удобнее для извлечения в RAG?

Retrieval-augmented generation, или RAG, использует найденные исходные материалы, чтобы обосновывать сгенерированный ответ. Система поиска может оценивать фрагмент отдельно от всей страницы, которая его окружает. Например, в документации Microsoft для Azure AI Search описано разбиение больших документов, чтобы их части можно было сопоставлять независимо. Это описание системы Microsoft, а не универсальная формула заголовков.

Поэтому для издателя контент, готовый к извлечению, — это контент, важные разделы которого остаются понятными даже при ограниченном окружающем контексте. Полезный раздел называет свой предмет, отвечает на один связный вопрос, указывает существенные условия и держит важные исключения рядом. Ясная структура упрощает проверку источника и воспроизводимость эксперимента, но влияние на конкретный результат RAG всё равно нужно измерять.

Что может изменить издатель, а что остаётся в поисковом стеке?

Самая безопасная отправная точка для подготовки RAG-контента — строгая граница между исходной страницей и бэкендом поставщика.

Что может изменить издатель сайта?

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

Это редакционные изменения. Если вам нужен коммерческий сценарий, а не метод подготовки текста, посмотрите страницу об AI-поиске по документации.

Чем управляет поставщик поисковой системы?

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

Это руководство также не объясняет установку или архитектуру бэкенда. Для этой отдельной задачи прочитайте, как добавить AI-поиск без разработки бэкенда.

Как проверить заголовки и разделы до переписывания?

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

Какие заголовки скрывают предмет?

Ищите общие подписи, понятные только потому, что читатель помнит предыдущий заголовок. Синтетический слабый заголовок «Ограничения» станет полезнее как «Ограничения офлайн-экспорта отчётов». Новая формулировка называет и тему, и тип информации, не навязывая всем страницам один шаблон.

Какие разделы смешивают решения или зависят от пропущенного контекста?

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

Какие факты заперты в изображениях, таблицах или подписях?

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

Как заголовкам сохранять предмет и область раздела?

Пишите заголовки сайта для RAG как указатели для занятого читателя: достаточно конкретные, чтобы предсказать содержание раздела, достаточно короткие для быстрого просмотра и вложенные согласно реальной организации страницы.

Как сохранить смысловую, а не декоративную иерархию?

Используйте один H1 для главной темы страницы, H2 — для основных вопросов, а H3 — для более узких вопросов внутри раздела. W3C объясняет, что заголовки передают организацию контента, а заголовки более низкого уровня создают подразделы внутри более высокого. Следуйте этой смысловой иерархии заголовков, потому что она улучшает структуру страницы и навигацию, а не потому, что W3C обещает эффект для RAG.

Где должен находиться прямой ответ?

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

Где должны находиться условия и исключения?

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

Как сделать каждый раздел понятным сам по себе?

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

Что должно находиться в одном разделе?

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

Сколько контекста нужно повторять?

Повторяйте только то, что устраняет неоднозначность. Замените «Он доступен через 30 дней» на «Экспорт журнала аудита доступен через 30 дней», если иначе предмет потеряется. Не повторяйте полное название продукта в каждом предложении и не заполняйте раздел вариантами ключевых слов.

Как оформлять списки и таблицы?

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

Как провести тест извлечения до и после с фиксированными запросами?

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

Как зафиксировать вопросы и ожидаемые источники?

Выберите авторизованный подключённый сайт. Назначьте запросам идентификаторы, сохраните точные формулировки и укажите канонический источник, который должен подтверждать каждый ответ. Добавьте реалистичные перефразировки и честные случаи без ответа. Не включайте персональные, конфиденциальные, учётные или секретные данные.

Синтетический пример входных данных:

Что нужно отдельно записать в исходной точке?

Для каждого запроса зафиксируйте, появился ли ожидаемый источник, действительно ли цитата подтверждает ответ и полон ли сам ответ. Считайте это проверкой цитируемого источника и не сводите поля к одному показателю «точности». Более глубокий процесс проверки описан в материале о том, как проверить, подтверждают ли цитаты ответ.

Что можно менять во время теста?

Редактируйте только заголовки, границы разделов, явно названные предметы, расположенный рядом текст ответа, условия, исключения и текстовые эквиваленты. Сохраните версию контента и разницу между версиями (diff). Не меняйте разбиение на фрагменты, поля схемы (schema), форматы эмбеддингов или индексации, поисковые конвейеры, переранжирование (reranking) либо пороговые значения и не создавайте впечатление, будто Achla предоставляет эти настройки.

Как повторно выполнить те же запросы?

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

Как интерпретировать положительные, нулевые, отрицательные и смешанные результаты?

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

Что делать, если правильный источник отсутствует?

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

Что делать, если источник найден, но цитата или ответ слабы?

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

Что делать, если изменений нет, результат ухудшился или оказался смешанным?

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

Что включить в чек-лист издателя по подготовке RAG-контента?

• Сохраните ясную связь страницы с RAG и заголовками.
• Дайте странице один описательный H1.
• Используйте H2 для основных вопросов, а H3 — для более узкой области.
• Помещайте прямой ответ рядом с заголовком.
• Держите одну связную тему, решение или процедуру вместе.
• Называйте продукты, роли, регионы, версии и исключения там, где они действуют.
• Добавляйте видимый текст для существенных фактов, находящихся только на изображениях.
• Отделяйте правки издателя от загрузки данных под контролем поставщика.
• Зафиксируйте запросы и ожидаемые источники до изменения структуры контента.
• Отдельно записывайте извлечение, подтверждение цитатами и полноту ответа, включая отрицательные результаты.

Каковы ограничения и следующий шаг?

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

Чтобы выполнить протокол на авторизованном публичном сайте через обычный продуктовый процесс, подключите свой сайт. Дополнительные материалы доступны в редакционных руководствах Achla по AI-поиску.