На сайте появилось живое RAG-демо: можно задать вопрос по материалам блога и получить ответ через GigaChat со ссылками на конкретные статьи. Это не «чат, который всё знает», а разбор по уже опубликованным постам.
Ниже — как это устроено, чем RAG отличается от обычного виджета-помощника, какие лимиты стоят на демо и куда смотреть, если нужна такая же схема на своём WordPress.
Зачем RAG, если уже есть AI-чат
На лендингах и основном сайте уже работает свой AI-помощник: он понимает контекст страницы, знает тарифы и умеет оставлять заявку. Это удобно для продаж и навигации.
RAG решает другую задачу. Когда вопрос касается сотен статей блога — VPS, почта, Beget, WordPress, реклама, боты — модели недостаточно «общего знания» и краткого промпта. Нужен поиск по реальному тексту сайта и ответ строго по найденным фрагментам.
Проще говоря:
- обычный чат отвечает из модели и короткого контекста страницы;
- RAG сначала достаёт куски из базы знаний, потом просит модель сформулировать ответ только по ним и приложить источники.
Идея близка к тому, о чём уже писал в разборе OCC-RAG: модель должна опираться на документы, а не додумывать «от себя».
Что можно попробовать прямо сейчас
Страница демо встроена в сам WordPress-сайт: шапка, меню, тема — всё как у обычной записи. Открыть можно здесь:
https://krivoshein.site/rag-demo/
На момент запуска индекс собирается с блога через WordPress REST API. В статусе видно порядка 390+ постов и около 1800+ текстовых чанков. Предпочитаемый провайдер ответа — GigaChat.
В интерфейсе есть готовые вопросы-подсказки и свободное поле. После ответа показываются:
- текст ответа;
- провайдер и число сработавших фрагментов;
- список источников со ссылками на статьи блога и короткими сниппетами.
Пункт также добавлен в меню «Сервисы» / «Услуги» и в сетку на странице сервисов.
Как это работает под капотом
Схема короткая и понятная. Именно её видно на самой демо-странице.
1. Индекс
Посты блога читаются из wp-json/wp/v2. Текст режется на чанки — куски удобного размера, чтобы по ним можно было искать, а не тащить в модель целиком весь архив.
2. Retrieval
По вопросу выбираются наиболее релевантные фрагменты. На практике это top-k по совпадению с запросом, а не «модель сама решила, что вспомнить».
3. GigaChat
Найденные куски уходят в промпт как CONTEXT. Модель формулирует ответ по ним. Если в индексе нет подходящего материала, честный результат — сказать, что по блогу этого нет, а не сочинять.
4. Источники
К ответу прикладываются ссылки на статьи. Это и есть проверка для читателя: можно открыть пост и сверить формулировку.
Технически демо живёт на WordPress-странице через shortcode, а API — на support-бэкенде. Для посетителя это одна страница сайта, без отдельного «голого» HTML вне темы.
Лимиты демо и чего здесь нет
Это публичное демо, не бесплатный полный продукт «поставь и забудь».
- лимит запросов: 12 в час и 30 в сутки с одного клиента (защита от случайного и неслучайного перегруза);
- база — материалы этого блога, не произвольные PDF и не чужой сайт «из коробки» в открытом демо;
- нет обещания, что ответ всегда идеален: качество зависит от того, что реально написано в постах, и от того, как вопрос сформулирован.
Если запрос упрётся в лимит, демо прямо подскажет, куда смотреть дальше — на внедрение, а не на бесконечный бесплатный API.
Где обычно ломается такая схема
Даже при рабочей модели узкие места предсказуемы.
- Плохой индекс. В REST не попал нужный тип контента, обрезан HTML, чанки слишком крупные или слишком мелкие.
- Слабый retrieval. Вопрос общий («расскажи про серверы»), а в блоге десятки разных постов — без уточнения модель получает шумный контекст.
- Галлюцинации вне CONTEXT. Если промпт разрешает фантазировать, появятся уверенные, но пустые ответы. Жёсткое «только по найденному» здесь принципиально.
- Кеш и статика. Если отдать демо как отдельный HTML вне WordPress, пропадёт шапка сайта, меню и единый UX. Публичная страница специально сделана WP-страницей в теме.
- CORS и origin. Браузерный fetch с основного домена на API support должен быть разрешён явно, иначе статус и ask молча «недоступны».
Как проверить, что демо живое
- Откройте страницу RAG-демо и убедитесь, что видна шапка сайта и блок со статистикой индекса.
- Задайте конкретный вопрос из тематики блога — например про VPS, перенос почты, Beget или WordPress.
- Посмотрите, вернулись ли источники со ссылками на реальные посты.
- Откройте 1-2 источника и сверьте, есть ли там близкий смысл. Если ссылки «мимо» — проблема скорее в retrieval или формулировке вопроса, а не в «магии GigaChat».
Статус API для проверки с сервера (нужен GET, не HEAD):
curl -sS https://support.krivoshein.site/api/v1/blog-rag/status
В ответе обычно есть поля вроде ready, posts, chunks, provider_preferred и возраст индекса.
Что это даёт бизнесу на WordPress
Для сайта услуг и блога RAG полезен там, где уже накоплен контент:
- быстрые ответы клиенту по базе статей и FAQ;
- меньше «пойди почитай 40 постов»;
- прозрачность: рядом со ссылками на источники;
- связка с AI-ready: сайт уже понятен и людям, и моделям/агентам через нормальную структуру,
llms.txtи прочие «ботовые» точки входа.
Отдельно это стыкуется с темой WordPress для AI-агентов: сначала сайт должен быть читаемым для машин, потом уже имеет смысл навешивать поиск по знаниям.
Внедрение, а не только демо
Публичная страница показывает принцип на живом блоге. Полное внедрение на чужом WordPress — отдельные работы: индекс, политика ответов, лимиты, провайдер (в т.ч. GigaChat), виджет или страница, мониторинг и обновление базы после публикаций.
Для этого смотрите пакеты на AI-ready и связанные направления вроде Bot-ready. Там как раз про подготовку сайта к AI и автоматизации, а не про «ещё один красивый чат без базы».
Контакты, если нужно обсудить внедрение: krivoshein.site/contacts.
Короткий вывод
RAG по блогу — это способ заставить ИИ отвечать по вашим материалам и показывать, откуда взята мысль. На krivoshein.site/rag-demo это можно потрогать руками: индекс с WordPress, retrieval, GigaChat, источники. Дальше — либо пользоваться как витриной, либо заказывать такую же схему под свой контент.
