Подготовить FAQ для сайта с нейросетью — значит собрать вопросы, которые действительно задают посетители, и ответить на них по сведениям, подтверждённым для конкретного бизнеса. Нейросеть может помочь оформить ответы и разложить результат по структуре; если нужного условия нет в исходных данных, его сначала уточняют, а не дописывают по догадке. Ниже — порядок работы, готовый промпт и полностью заполненный учебный пример.
Какие данные собрать и как выбрать помощника
Для одной страницы подготовьте четыре вещи: вопросы из обращений, факты о бизнесе, границы страницы и правила текста. Присвойте каждому вопросу свой ID. Факты внесите отдельно: так можно проверить, на каком сведении основан ответ. Для каждого факта и вопроса укажите источник и дату, если она известна. Для настоящей задачи передавайте сохранённый текст страницы или разрешённый файл, а не только адрес страницы.
Если похожие обращения объединяются в один FAQ-пункт, сохраните в рабочем результате каждый исходный ID и формулировку. Так посетитель видит один ответ по общей теме, а вы не теряете обращения, на которых он основан. Идеи вопросов, которые предложила модель, отмечайте отдельно: это темы для проверки, а не обращения реальных клиентов.
Для разовой подготовки текста можно начать с текстового помощника. Например, ГигаЧат поддерживает анализ DOCX, PDF и TXT. Справка ГигаЧата о работе с документами. Это описание поддержки форматов, а не подтверждение точности сгенерированных ответов. В справке также указано, что ГигаЧат может создавать оригинальный текст, краткое содержание или простое объяснение существующей работы: ГигаЧат: работа с текстом.
Выбирайте инструмент по задаче: какие материалы можно передать, кто получит к ним доступ, подходит ли контур обработки данных, как проверить результат и каковы условия и бюджет. Не передавайте помощнику лишние персональные сведения. Для реальной задачи сначала проверьте разрешённый контур и условия обработки данных у поставщика. Если цена или условия не указаны в доступной вам информации, сверяйтесь с официальными условиями, а не подставляйте предположительную сумму.
Для одной страницы, когда исходники готовы и специалист по бизнесу может уточнить пробелы, обычно достаточно подготовить текст и проверить его по источникам. Если задача включает интеграцию с сайтом, передачу сложных запросов человеку, логи или проверку сценариев, это уже отдельная работа. Текстовый помощник сам по себе не означает, что такие процессы настроены. В этой инструкции разбирается подготовка блока FAQ, а не создание всей страницы или интеграционного сценария.
Порядок работы от исходников до результата
- Ограничьте тему страницей. Например, если страница посвящена замене молнии на рюкзаке и порядку обращения, вопросы о других услугах мастерской отправляйте в проверку. Границы страницы помогают не превратить FAQ в общее меню бизнеса.
- Задайте максимум вопросов. Поле
target_max_questions— потолок, а не число, которое нужно обязательно набрать. Если подходящих подтверждённых вопросов меньше, верните меньше; причину укажите в рабочем JSON. Не добавляйте темы только ради заполнения лимита. - Опишите стиль и форму. В
style_rulesукажите обращение, тон и ограничения формулировок. Вpage_scope— тему и границы страницы. Например: «на вы, деловой понятный русский, без восклицаний и новых обещаний». - Передайте вопросы и факты раздельно. Для вопросов сохраните точный текст, ID и источник обращения. Для фактов — ID, точную формулировку, источник и, если есть, дату. Сам вопрос показывает, что спросил человек, но не подтверждает ответ.
- Поручите агенту собрать и проверить черновик. По заданным правилам агент может сопоставить ответы с фактами, сохранить связи с источниками, отметить дубли и вопросы вне темы. Непокрытые вопросы он отправляет в
questions_to_business, а идеи модели — отдельно вreview. - Уточните только то, чего не хватает. Человек сообщает отсутствующие бизнес-условия и принимает решения по исключениям. Сверку ID, источников, фактов и границ страницы можно задать агенту; обязательная ручная вычитка каждого ответа здесь не является условием процесса.
- Разделите рабочий результат и текст для посетителя. Рабочий JSON нужен для проверки источников и статусов. Публичный блок содержит только принятые вопросы и ответы — без служебных пометок об источниках и проверках.
Промпт и пример
Промпт ниже задаёт правила для одной страницы. Перед запуском замените значения в строках и числах, а массивы заполните своими данными. Не оставляйте плейсхолдеры вроде [уникальный ID] без кавычек: это невалидный JSON. Для примера входные данные относятся к вымышленной условной мастерской и полностью приведены ниже.
Подготовь рабочий FAQ для одной страницы по переданным вопросам и фактам.
ВХОДНЫЕ ДАННЫЕ
{
"target_max_questions": 3,
"style_rules": "На вы, деловой понятный русский, без восклицаний и новых обещаний.",
"page_scope": "ЗАМЕНИТЕ: тема страницы и её границы",
"questions": [
{
"question_id": "Q1",
"question": "ТОЧНАЯ ФОРМУЛИРОВКА ОБРАЩЕНИЯ",
"source_id": "ID_ИСТОЧНИКА_ОБРАЩЕНИЯ",
"kind": "customer_request"
}
],
"facts": [
{
"fact_id": "F1",
"fact": "ТОЧНЫЙ ПОДТВЕРЖДЁННЫЙ ФАКТ",
"source_id": "ID_ИСТОЧНИКА_ФАКТА"
}
],
"sources": [
{
"source_id": "ID_ИСТОЧНИКА_ОБРАЩЕНИЯ",
"source_name": "ТОЧНОЕ НАЗВАНИЕ ИСТОЧНИКА",
"source_date": null,
"kind": "customer_request",
"url": null
},
{
"source_id": "ID_ИСТОЧНИКА_ФАКТА",
"source_name": "ТОЧНОЕ НАЗВАНИЕ ИСТОЧНИКА",
"source_date": null,
"kind": "business_fact",
"url": null
}
]
}
ПРАВИЛА РАБОТЫ
1. Для утверждений о бизнесе используй только переданные facts. Не добавляй сведения из общих знаний, аналогий или догадок.
2. Сохраняй точный текст и ID каждого исходного вопроса. Если объединяешь дубли, перечисли все исходные вопросы с ID и источниками; ничего не теряй.
3. Вопросы из обращений отделяй от тем, предложенных моделью. Идеи модели помещай в review как темы для проверки, не называй их обращениями клиентов.
4. Для каждого ответа укажи fact_ids и включи в выходной facts_catalog соответствующие точные факты и source_id. Для каждого исходного вопроса сохрани question_id, точную формулировку и source_id.
5. Если ответа нет или факта недостаточно, не додумывай. Помести вопрос в questions_to_business и укажи, чего именно не хватает.
6. Не придумывай цену, срок, гарантию, способ оценки, исключение или условие обслуживания. Если известна только часть ответа, явно обозначь её предел и отправь вопрос на уточнение, когда без недостающей информации посетитель может понять ответ неверно.
7. Соблюдай target_max_questions как верхнюю границу. Не добавляй вопросы ради заполнения лимита. Темы вне page_scope помещай в review с причиной.
8. Верни только валидный JSON следующей структуры. Используй реальные входные ID и данные; строки ниже — поясняющие значения, их нужно заменить.
{
"faq": [
{
"question_id": "ID ОСНОВНОГО ВОПРОСА",
"source_questions": [
{
"question_id": "ИСХОДНЫЙ ID",
"question": "ТОЧНЫЙ ИСХОДНЫЙ ВОПРОС",
"source_id": "ID ИСТОЧНИКА ВОПРОСА"
}
],
"question": "ВОПРОС ДЛЯ FAQ",
"answer": "ОТВЕТ ТОЛЬКО ПО ФАКТАМ",
"fact_ids": ["ID ПОДТВЕРЖДАЮЩЕГО ФАКТА"],
"status": "supported или needs_clarification"
}
],
"facts_catalog": [
{
"fact_id": "ID ФАКТА",
"fact": "ТОЧНАЯ ФОРМУЛИРОВКА ФАКТА",
"source_id": "ID ИСТОЧНИКА ФАКТА"
}
],
"questions_to_business": [
{
"question_ids": ["ID ВОПРОСА"],
"question": "ЧТО НУЖНО УТОЧНИТЬ У БИЗНЕСА",
"reason": "КАКОГО ФАКТА НЕ ХВАТАЕТ"
}
],
"review": [
{
"question_ids": ["ID ИСХОДНЫХ ВОПРОСОВ ИЛИ ПУСТОЙ МАССИВ"],
"question": "ВОПРОС ИЛИ ПРЕДЛОЖЕННАЯ ТЕМА",
"source_id": "ID ИСТОЧНИКА ИЛИ null",
"reason": "ДУБЛЬ, ТЕМА ВНЕ ГРАНИЦ СТРАНИЦЫ ИЛИ ИДЕЯ ДЛЯ ПРОВЕРКИ"
}
],
"sources": [
{
"source_id": "ID ИСТОЧНИКА",
"source_name": "ТОЧНОЕ НАЗВАНИЕ ИСТОЧНИКА",
"source_date": "ДАТА ИЛИ null",
"kind": "ТИП ИСТОЧНИКА",
"url": "АДРЕС ИЛИ null"
}
]
}
Входные данные учебного примера
{
"target_max_questions": 3,
"style_rules": "На вы, деловой понятный русский, без восклицаний и новых обещаний.",
"page_scope": "Замена молнии рюкзака и порядок обращения в условную мастерскую.",
"questions": [
{
"question_id": "Q1",
"question": "Меняете молнию на рюкзаке?",
"source_id": "DEMO_QUESTIONS",
"kind": "fictional_request"
},
{
"question_id": "Q2",
"question": "Сколько стоит?",
"source_id": "DEMO_QUESTIONS",
"kind": "fictional_request"
},
{
"question_id": "Q3",
"question": "Можно без записи?",
"source_id": "DEMO_QUESTIONS",
"kind": "fictional_request"
}
],
"facts": [
{
"fact_id": "F1",
"fact": "Мастерская заменяет молнии на рюкзаках.",
"source_id": "DEMO_BRIEF"
},
{
"fact_id": "F2",
"fact": "Цена согласуется до начала работ.",
"source_id": "DEMO_BRIEF"
},
{
"fact_id": "F3",
"fact": "Приём ведётся по записи.",
"source_id": "DEMO_BRIEF"
}
],
"sources": [
{
"source_id": "DEMO_QUESTIONS",
"source_name": "учебные обращения условной мастерской",
"source_date": null,
"kind": "fictional_request",
"url": null
},
{
"source_id": "DEMO_BRIEF",
"source_name": "учебный бриф условной мастерской",
"source_date": null,
"kind": "fictional_assumption",
"url": null
}
]
}
Рабочий результат для проверки
{
"faq": [
{
"question_id": "Q1",
"source_questions": [
{
"question_id": "Q1",
"question": "Меняете молнию на рюкзаке?",
"source_id": "DEMO_QUESTIONS"
}
],
"question": "Меняете молнию на рюкзаке?",
"answer": "Да, меняем молнии на рюкзаках.",
"fact_ids": ["F1"],
"status": "supported"
},
{
"question_id": "Q2",
"source_questions": [
{
"question_id": "Q2",
"question": "Сколько стоит?",
"source_id": "DEMO_QUESTIONS"
}
],
"question": "Сколько стоит?",
"answer": "Стоимость согласуем до начала работ.",
"fact_ids": ["F2"],
"status": "supported"
},
{
"question_id": "Q3",
"source_questions": [
{
"question_id": "Q3",
"question": "Можно без записи?",
"source_id": "DEMO_QUESTIONS"
}
],
"question": "Можно без записи?",
"answer": "Приём ведём по записи.",
"fact_ids": ["F3"],
"status": "supported"
}
],
"facts_catalog": [
{
"fact_id": "F1",
"fact": "Мастерская заменяет молнии на рюкзаках.",
"source_id": "DEMO_BRIEF"
},
{
"fact_id": "F2",
"fact": "Цена согласуется до начала работ.",
"source_id": "DEMO_BRIEF"
},
{
"fact_id": "F3",
"fact": "Приём ведётся по записи.",
"source_id": "DEMO_BRIEF"
}
],
"questions_to_business": [
{
"question_ids": ["Q2"],
"question": "Какую сумму или диапазон стоимости можно сообщить, если посетителю нужна именно числовая цена?",
"reason": "В учебных данных указано только, что цену согласуют до начала работ; числовая цена неизвестна. Ответ сообщает известный порядок, но не называет сумму."
}
],
"review": [],
"sources": [
{
"source_id": "DEMO_QUESTIONS",
"source_name": "учебные обращения условной мастерской",
"source_date": null,
"kind": "fictional_request",
"url": null
},
{
"source_id": "DEMO_BRIEF",
"source_name": "учебный бриф условной мастерской",
"source_date": null,
"kind": "fictional_assumption",
"url": null
}
]
}
В Q2 есть ответ о порядке согласования, но нет числовой цены. Поэтому пример не добавляет сумму, фотооценку или бесплатную диагностику. Если для посетителя нужен именно числовой ответ, его сначала уточняют у бизнеса. Иначе можно оставить только подтверждённую формулировку о согласовании до начала работ.
Это вымышленные учебные обращения и условия, а не сведения о реальной мастерской, клиентский кейс или результат испытания сервиса.
Чистый публичный блок
- Меняете молнию на рюкзаке? Да, меняем молнии на рюкзаках.
- Сколько стоит? Стоимость согласуем до начала работ.
- Можно без записи? Приём ведём по записи.
Проверка, ограничения и следующий шаг
До публикации задайте агенту проверку результата по конкретным условиям:
- у каждого вопроса сохранены точный исходный текст, ID и источник;
- у каждого ответа указаны
fact_ids, а текст соответствующих фактов и их источники находятся вfacts_catalog; - ни один ответ не содержит деталей, которых нет в переданных фактах;
- дубли объединены без потери исходных формулировок и ID;
- вопросы вне
page_scopeи идеи модели находятся вreview, а не представлены как реальные обращения; - непокрытые сведения находятся в
questions_to_business, а не превращаются в публичные обещания; - каждый FAQ-пункт относится к теме страницы, а не подменяет содержание других разделов.
Это рабочие правила проверки, а не гарантия, что модель всегда выполнит их без ошибки. Человек уточняет отсутствующие бизнес-факты и принимает решения по исключениям. После изменения исходных сведений можно снова передать актуальный материал и попросить агента сопоставить с ним ответы, отметить расхождения и обновить рабочий JSON. Это предлагаемая процедура; она не означает, что любой помощник самостоятельно обнаружит изменения на сайте.
На страницу можно вынести обычный блок вопросов и ответов или разместить их в раскрывающемся формате. В обоих случаях агент может проверить, что ответы доступны посетителю и совпадают с принятым текстом. Если для другого потребителя отдельно нужна структурированная разметка, её проверяют на соответствие видимому содержимому и актуальной схеме. Здесь не предлагается универсальная разметка FAQPage и не обещается расширенный результат в поиске.
Расширенные результаты с часто задаваемыми вопросами больше не показываются в результатах поиска Google. Журнал изменений Google. FAQ в этой задаче нужен, чтобы дать человеку ответы по подтверждённым сведениям; это не обещание роста видимости или конверсии.
Самостоятельная подготовка текста подходит для блока на одной странице. Если нужны интеграция, передача сложных обращений человеку, логи или проверка сценариев, это уже более широкая задача, чем написание FAQ. Для полной страницы смотрите инструкцию «Как создать лендинг с помощью нейросети: по шагам». Если сначала нужно собрать и разобрать вопросы аудитории, пригодится «Анализ целевой аудитории с помощью нейросети: пример».
Автор метода «Машиночитаемый маркетинг»