ИИ-помощник по сайту компании: как отвечать по опубликованной информации

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

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

Когда сайт подходит как источник ответов

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

Эта задача отличается от поиска по закрытым корпоративным документам. Здесь источниками служат публичные страницы, но публичность ещё не означает разрешение использовать любой доступный URL. Она также отличается от установки чат-виджета: виджет отвечает за интерфейс диалога, а отбор, получение и обновление знаний — за содержание ответа. Подробнее об интерфейсной части можно прочитать в материале про подключение чат-бота к сайту.

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

Какие страницы разрешить и кто отвечает за содержание

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

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

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

Как содержание страницы попадает в базу

Маршрут можно описать как последовательность:

1. Система получает страницу из согласованного списка.
2. Проверяет результат запроса и фактический адрес после возможного перенаправления.
3. Извлекает основной текст без меню и повторяющихся элементов шаблона.
4. Делит материал на смысловые фрагменты и добавляет сведения об их происхождении.
5. Загружает подготовленные фрагменты в поисковое хранилище.

Официальная документация n8n содержит учебный workflow: HTTP Request получает данные сайта, HTML node извлекает нужное содержание, а Pinecone Vector Store отправляет его в Pinecone. Это подтверждает документированную последовательность для приведённого примера n8n, но не совместимость с любым сайтом и не готовую очистку страниц.

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

Как сохранить происхождение каждого фрагмента

Вместе с текстом фрагмента стоит хранить данные, по которым сотрудник и система смогут восстановить его происхождение.

Default Data Loader в n8n позволяет добавлять к документу метаданные. При последующем извлечении эти данные можно сопоставлять через Metadata Filter. Документация подтверждает такую возможность, но не задаёт обязательный набор полей, правила версионирования или формат ссылки в готовом ответе.

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

Как помощник находит материал и формирует ответ

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

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

Для будущего помощника полезно закрепить правила:

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

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

Как учитывать изменения опубликованных страниц

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

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

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

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

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

До разработки определите возможные состояния результата.

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

Такая передача не возникает автоматически из RAG или чат-интерфейса. Её нужно спроектировать, подключить к рабочему каналу и проверить. Отдельные требования к этому маршруту собраны в руководстве о передаче диалога сотруднику.

Синтетический пример: оплата после получения

Это условная демонстрация логики, а не клиентский кейс и не выполненный тест Switch On AI.

Условная компания публикует страницы услуг, доставки и оплаты. Посетитель спрашивает: «Можно ли оплатить заказ после получения в Казани?» На странице оплаты указана оплата после получения. На странице доставки перечислены города, но Казани среди них нет.

Помощник не должен соединять эти сведения в обещание. Корректный ожидаемый ответ выглядит так: «На странице оплаты подтверждён способ оплаты после получения. Применимость этого условия к доставке в Казань по опубликованным страницам установить нельзя». Затем помощник показывает обе страницы и предлагает передать вопрос сотруднику.

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

Как провести пилот и принять помощника

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

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

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

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

Switch On AI разрабатывает ИИ-агентов и помощников под конкретную операцию: от требований и прототипа ключевого сценария до проверки, внедрения и передачи кода в согласованном объёме. Прототип не равен полноценному внедрению. Возможность получения страниц, выбранный стек, доступы, порядок обновления и эксплуатационные расходы уточняются при разборе задачи.

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