Обычные AI-чатботы уверенно ошибаются при ответах о вашем продукте. Задайте ему вопрос о собственной документации, и он либо галлюцинирует, либо извиняется. Решение — RAG (Retrieval-Augmented Generation) — когда модель отвечает на основе ваших материалов, а не данных обучения. Вот как я создал RAG-чатбот на основе контента WordPress с нуля.
Это практическое руководство к моей статье об использовании WordPress как RAG-backend. В той статье рассказывается об архитектуре хранилища и индексирования — базе знаний, разбиении на части, встраивании и хранилище векторов Qdrant. Здесь я сосредоточусь на другой половине: цикл получения результатов-ответы, который превращает этот индекс в работающий чатбот.
Что мы строим
У чатбота одна работа: взять вопрос пользователя, найти самые релевантные отрывки из контента WordPress и позволить LLM ответить, используя только эти отрывки — со ссылкой на исходный пост. Четыре основных компонента:
- База знаний — ваши посты и страницы WordPress, доступные через REST API.
- Индекс — фрагменты этого контента, преобразованные в встраивания и хранящиеся в векторной базе данных (я использую Qdrant).
- Цикл получения результатов — встраивание вопроса, поиск в индексе, получение лучших совпадений.
- Шаг ответа — передача этих совпадений в 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-чатбота на одного пользователя.



