Представим сайт городской мастерской, где посетители спрашивают о часах работы, правилах записи и подготовке к занятию. Бот должен отвечать по утверждённым страницам, показывать откуда взял ответ и признавать, когда источника недостаточно.
Собери ограниченную базу ответов
Начни с небольшого набора версионированных материалов: актуальные часы, правила записи, возврат, доступность помещения и контакты. У каждой страницы должны быть владелец, дата проверки и ссылка. Не добавляй в базу черновики, приватные переписки или старые условия без пометки. Если два источника расходятся, пометь конфликт и направь посетителя к человеку вместо выбора удобного ответа.
При поиске по документам модель должна получить конкретные фрагменты и метаданные источника. OpenAI Retrieval описывает возвращаемые chunks, similarity score и происхождение файла; это можно использовать, чтобы показать читателю ссылку на страницу (Retrieval guide). Сходство помогает найти материал, но само по себе не доказывает, что ответ следует из него.
Ответ с опорой, отказ, эскалация
В интерфейсе разделяй три исхода:
- Есть актуальный источник: коротко ответить и дать ссылку с разделом.
- Нет подтверждения или источники конфликтуют: сказать, что бот не может подтвердить условие, не угадывать и предложить официальный канал.
- Нужна индивидуальная помощь: с согласия посетителя создать обращение/передать контакт человеку и сообщить, что именно будет отправлено.
Для вопроса «Можно прийти с собакой?» бот не должен выводить доступность из общей фотографии помещения. Он ищет прямое правило; если его нет — отвечает, что это нужно уточнить у администратора. Для «занятие завтра в 18:00 ещё свободно?» статическая статья недостаточна: запрос должен идти к живому расписанию или человеку.
Промпт не является защитной границей. Текст страницы, сообщения пользователя и найденные фрагменты считай данными, а не инструкциями менять роль бота или раскрывать секреты. OpenAI отдельно предупреждает о риске галлюцинаций и рекомендует оценивать поведение на широком наборе входов и ограничивать последствия модели (Safety best practices). Эти меры снижают риск, но не обещают безошибочности.
Тесты на полезность и срыв
Собери сценарии из реальных типов вопросов, но без персональных данных: прямой ответ с источником; вопрос вне базы; устаревшая страница; конфликт двух правил; попытка попросить скрытый prompt; запрос динамического наличия мест; сообщение, требующее оператора. Для каждого укажи ожидаемое поведение, правильную ссылку и условие эскалации. Оценивай не только красивый текст, но и корректность источника, отказа и передачи.
Перед передачей человеку показывай текст заявки и контакт, которые будут отправлены. Не обещай мгновенный ответ, если команда не обязалась его обеспечить. Храни только нужные сведения и предусмотренный срок; не записывай автоматически весь диалог, если это не требуется продукту.
Пример задачи генератору
«Добавь виджет ответов по опубликованным страницам мастерской. Каждый ответ показывает страницу-источник; при отсутствии подходящего фрагмента бот не отвечает по памяти и предлагает контакт. Динамические места не выдумывать; эскалация спрашивает согласие и показывает передаваемые данные. Не добавляй оплату и личные аккаунты». Это спецификация для разработки, не доказательство запущенного бота. До реального использования отдельно подключи проверенную базу, настрой сбор данных и проверь конкретную интеграцию.