Создайте RAG-чатбот на основе контента WordPress (2026)

Sergey Nesmachny
Sergey Nesmachny
26.06.2026
7 мин чтения
RAG-чатбот на WordPress за 6 шагов: ответы по вашим статьям со ссылками на источники

Обычные AI-чатботы уверенно ошибаются при ответах о вашем продукте. Задайте ему вопрос о собственной документации, и он либо галлюцинирует, либо извиняется. Решение — RAG (Retrieval-Augmented Generation) — когда модель отвечает на основе ваших материалов, а не данных обучения. Вот как я создал RAG-чатбот на основе контента WordPress с нуля.

Это практическое руководство к моей статье об использовании WordPress как RAG-backend. В той статье рассказывается об архитектуре хранилища и индексирования — базе знаний, разбиении на части, встраивании и хранилище векторов Qdrant. Здесь я сосредоточусь на другой половине: цикл получения результатов-ответы, который превращает этот индекс в работающий чатбот.

Что мы строим

У чатбота одна работа: взять вопрос пользователя, найти самые релевантные отрывки из контента WordPress и позволить LLM ответить, используя только эти отрывки — со ссылкой на исходный пост. Четыре основных компонента:

  1. База знаний — ваши посты и страницы WordPress, доступные через REST API.
  2. Индекс — фрагменты этого контента, преобразованные в встраивания и хранящиеся в векторной базе данных (я использую Qdrant).
  3. Цикл получения результатов — встраивание вопроса, поиск в индексе, получение лучших совпадений.
  4. Шаг ответа — передача этих совпадений в LLM в качестве контекста и потоковая передача ответа.

Части 1 и 2 рассматриваются в статье о backend. Это руководство строит части 3 и 4.

Шаг 1: Получение контента из WordPress

Все начинается с REST API. WordPress уже предоставляет ваш опубликованный контент в виде JSON — не требуется никаких плагинов:

// Fetch published posts to index
const res = await fetch(
  'https://cms.example.com/wp-json/wp/v2/posts?per_page=100&_fields=id,link,title,content,modified'
)
const posts = await res.json()

Поле modified имеет значение — это то, как вы позже будете поддерживать индекс в актуальном состоянии. Удалите HTML из content.rendered до чистого текста перед разбиением на части.

Шаг 2: Разбиение на части и встраивание

Разделите каждый пост на перекрывающиеся отрывки в несколько сотен токенов, встройте каждый и сохраните вектор с его метаданными (ID поста, название, URL, дата модификации). Это шаг индексирования, подробно описанный в статье о backend, поэтому я не буду его повторять — важным результатом является коллекция Qdrant, где каждый вектор знает, из какого поста WordPress он поступил.

Шаг 3: Цикл получения результатов

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

async function retrieve(question, k = 5) {
  // 1. Embed the question with the same embedding model as the content
  const { data } = await embed(question)
  const vector = data[0].embedding

  // 2. Find the k closest chunks in Qdrant
  const hits = await qdrant.search('wp_knowledge', {
    vector,
    limit: k,
    with_payload: true,
  })

  // 3. Return the text plus where it came from
  return hits.map(h => ({
    text: h.payload.text,
    title: h.payload.title,
    url: h.payload.url,
    score: h.score,
  }))
}

Две вещи определяют качество получения результатов: использование одной и той же модели встраивания с обеих сторон и сохранение k маленьким (3–5). Заполнение контекста двадцатью фрагментами ухудшает ответы, а не улучшает.

Шаг 4: Создание подсказки и получение ответа

Теперь соберите полученные отрывки в обоснованную подсказку. Системная инструкция — это где вы останавливаете галлюцинации — скажите модели отвечать только из контекста и признавать, когда она не может:

function buildMessages(question, chunks) {
  const context = chunks
    .map((c, i) => `[${i + 1}] ${c.title}\n${c.text}\nSource: ${c.url}`)
    .join('\n\n')

  return [
    {
      role: 'system',
      content:
        'You answer using ONLY the context below. ' +
        'If the answer is not there, say you do not know. ' +
        'Cite sources as [1], [2] and list their URLs.',
    },
    { role: 'user', content: `Context:\n${context}\n\nQuestion: ${question}` },
  ]
}

Передайте эти сообщения в ваш LLM (я потоково передаю ответ, чтобы чат ощущался живым), затем визуализируйте цитируемые URL-адреса как ссылки обратно на исходные посты WordPress. Этот шаг цитирования делает бота надежным — каждое утверждение на один клик от его источника.

Шаг 5: Подключение интерфейса чата

Фронт-энд — это простая часть. Предоставьте цикл выше как единую конечную точку API (POST /api/chat) которая принимает вопрос и потоково передает ответ. Затем поместите виджет чата в любое место — React-компонент на сайте, страница WordPress или внутреннюю панель администратора. Одна и та же конечная точка может питать публичного помощника документации и приватный инструмент поддержки; отличается только исходный контент.

Шаг 6: Честность и свежесть

Два правила поддерживают полезность RAG-чатбота в production:

  • Всегда цитируйте, всегда разрешайте “Я не знаю”. Бот, который придумывает ответы, хуже, чем отсутствие бота. Обоснование плюс цитирование — это вся суть.
  • Переиндексируйте при редактировании. Подключите события сохранения/публикации WordPress так, чтобы измененные посты автоматически переобрабатывались. Привяжите это к modified временной метке и индекс никогда не будет отставать от опубликованного.

Стек и стоимость

WordPress (контент) + модель встраивания + Qdrant (векторы) + любой LLM (ответы) + тонкий API для их соединения. Qdrant имеет открытый исходный код и самостоятельно размещается, WordPress вы уже запускаете, единственная измеряемая стоимость — это токены встраивания и завершения — копейки для типичной базы знаний. Без платы SaaS чатбота за пользователя.

Ошибки, которые я допустил

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

Заключение

RAG-чатбот на WordPress — это в основном сантехника, которую у вас уже есть: REST API для контента, хранилище векторов для получения результатов и LLM для финального ответа. Правильно настройте разбиение на части и цитирование, и у вас есть помощник, который отвечает из вашей реальной базы знаний — не из воображения модели. Начните с архитектуры backend, затем постройте цикл выше на вершине.

Часто задаваемые вопросы

Как построить RAG-чатбот на контенте WordPress?

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

Нужен ли плагин для создания RAG-чатбота WordPress?

Нет. Основной WordPress REST API уже предоставляет ваш контент в виде JSON, что все, что нужно конвейеру получения результатов. Вы можете добавить небольшой плагин или mu-плагин для запуска переиндексирования при сохранении, но сам чатбот находится во внешнем сервисе (Node API, Worker или аналогичном), а не внутри WordPress.

Какую LLM должен использовать RAG-чатбот WordPress?

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

Как чатбот остается в синхронизации с редактированием в WordPress?

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

Как предотвратить галлюцинации RAG-чатбота?

Инструктируйте модель отвечать только на основе полученного контекста, говорить «Я не знаю», когда ответ отсутствует, и указывать каждый источник. В сочетании с хорошей поиск (одна и та же модель эмбеддинга с обеих сторон, небольшой top-k), закрепление плюс цитирование источников держат ответы привязанными к вашему реальному контенту.

Дешево ли запускать RAG-чатбот WordPress?

Да. Вы повторно используете WordPress для контента и самостоятельно размещаемое хранилище векторов с открытым исходным кодом, такое как Qdrant, для поиска, поэтому единственная измеряемая стоимость — это токены эмбеддинга и завершения — обычно копейки для обычной базы знаний, без подписки SaaS-чатбота на одного пользователя.

Sergey Nesmachny

Автор

Sergey Nesmachny

Поделиться: