Посетитель сайта Avenex нажимает на один из стартовых вопросов в чат-виджете и получает ответ со ссылкой на раздел сайта, если ответ как-то связан с разделом. Попросит написать код или спросит, чьи сайты самые лучшие, получит вежливый отказ. Спросит по-английски, ответ придёт на английском.
За этим поведением стоит связка из четырёх компонентов Cloudflare: статический хостинг, Cloudflare Workers, Workers AI и D1. Worker принимает вопрос, одна модель проверяет допустимость темы, вторая готовит ответ по базе знаний из Markdown-документов. Всё укладывается в бесплатные квоты, пока не исчерпана дневная. Тот же подход переносится на документацию, каталог услуг или внутреннюю базу знаний.
Ниже разобрана архитектура, семь этапов разработки, четыре меры защиты и три реальные ошибки, которые автор встретил в процессе. Это эксперимент на небольшом сайте, а не боевая система с гарантиями безошибочности.
Что за помощник и зачем он нужен: пример Avenex
Avenex - небольшой полигон для ИИ-проектов нескольких единомышленников. Сайт размещён на Cloudflare, и у платформы нашлись все нужные компоненты, причём с бесплатными квотами. Разбор эксперимента на Habr описывает, как из этого получился бесплатный ИИ-помощник-консультант по содержимому сайта.
Задача была узкой: посетитель должен быстро разобраться с содержимым сайта, не листая разделы вручную. Помощник отвечает на вопросы по материалам сайта и там, где уместно, ссылается на конкретный раздел. Кнопка «Спросить ИИ» внизу страницы работает, пока не исчерпана дневная квота.
Для оценки подхода важна граница: ограничения встроены, чтобы помощник держался темы и экономно расходовал бесплатную квоту. От любых способов обхода они не защищают, и безошибочных ответов не гарантируют.
Из чего состоит бесплатный ИИ-консультант на Cloudflare
Архитектура состоит из четырёх частей, и каждая отвечает за своё.
| Компонент | Что делает |
|---|---|
| Статический хостинг Cloudflare | Отдаёт страницы и интерфейс чата браузеру |
| Cloudflare Workers | Выполняет код: принимает вопрос, обращается к модели, возвращает ответ |
| Workers AI | Запускает модели: одна проверяет допустимость темы, другая готовит ответ по базе знаний |
| D1 | Используется в сборке помощника, например для истории или настроек |
Почему выбрана такая связка: всё живёт на одной платформе, отдельный сервер не нужен, а у Cloudflare есть бесплатные квоты. Это не единственно верный вариант. Похожего помощника можно собрать на другом серверлесс-провайдере или на своём VPS, но тогда часть компонентов придётся подключать и оплачивать отдельно.
При росте материалов предусмотрен переход к поиску по эмбеддингам и схеме RAG с Vectorize.
Роль Worker: приём вопроса и маршрутизация
Worker выполняет код: принимает вопрос, обращается к модели, возвращает ответ. Логика потока выглядит так:
- Worker принимает вопрос посетителя вместе с историей разговора.
- Проверяет подпись истории, чтобы клиент не подменил её.
- Проверяет лимиты на IP.
- Отправляет вопрос модели-классификатору темы.
- Если тема допустима, вызывает модель, которая готовит ответ по базе знаний.
- Возвращает ответ и, когда он связан с разделом сайта, ссылку на этот раздел.
Worker держит всю маршрутизацию и решает, какому запросу дать ход, а какой отклонить. Без него модели остались бы без базы знаний, истории и ограничений.
Две модели: классификатор темы и генератор ответа
Одна модель проверяет допустимость темы. Она отсекает запросы не по теме сайта: просьбу написать код, вопрос вроде «чьи сайты самые лучшие» и похожие. Другая модель готовит ответ по базе знаний. Разделение ролей нужно, чтобы не тратить нейроны генератора на заведомо неподходящие запросы и удержать помощника в рамках темы.
Язык ответа подстраивается под вопрос: если посетитель спрашивает по-английски, ответ приходит на английском.
База знаний из Markdown-документов
База собрана из 14 Markdown-документов объёмом около 12,9 тысячи символов. Этого достаточно для простого поиска без эмбеддингов: содержимое помещается в контекст, и модель отвечает прямо по нему. Markdown удобен тем, что документы легко редактировать, версионировать и парсить, а разметка не мешает чтению.
Когда материалов станет заметно больше, простой поиск начнёт промахиваться мимо нужного фрагмента. На этот случай предусмотрен переход к поиску по эмбеддингам и схеме RAG с Vectorize.
Семь этапов разработки ИИ-помощника: от базы до приёмки
Автор прошёл семь этапов: от сбора базы и сравнения моделей до ограничения расхода, проверки границ и приёмки результата. Это реальный путь одного проекта, а не универсальная методология, но порядок шагов переносится на похожие задачи. Собрать помощника помог кодинговый ИИ-агент: он работал с файлами проекта, писал код и запускал проверки.
Этап 1-2: сбор базы знаний и сравнение моделей
Работа начинается с базы: 14 Markdown-документов, около 12,9 тысячи символов. Дальше идёт сравнение моделей. Критерии, которые имеют значение для такого помощника: качество ответов по материалам сайта, скорость ответа, расход в нейронах и поддержка языков, включая русский. Сравнение удобно вести на реальных вопросах по сайту, а не на абстрактных примерах, а модели подбирать так, чтобы уложиться в бесплатные квоты.
Этап 3-4: сборка Worker и подключение моделей
На этих этапах Worker соединяет вопрос, модели и базу: принимает запрос, вызывает модель-классификатор, затем модель-генератор, возвращает ответ. D1 хранит историю или настройки. Здесь же появляется проверка подписи истории разговора.
Кодинговый агент работал с файлами проекта и запускал проверки, поэтому сборку удобно вести итерациями. Если вы проектируете похожую схему с несколькими ролями моделей, полезно посмотреть, как разделяют обязанности в архитектуре Supervisor-Worker: там роли явно разведены, и это упрощает отладку.
Этап 5-6: ограничение расхода и проверка границ
Ограничение расхода складывается из суточного бюджета в нейронах, лимитов на IP и проверки подписи истории разговора. Проверка границ - это тесты на запросы не по теме: попросить написать код, спросить «чьи сайты самые лучшие», задать вопрос на английском. Эти ограничения нужны, чтобы помощник держался темы и экономно расходовал бесплатную квоту. Безошибочных ответов и защиты от любых способов обхода они не гарантируют.
Этап 7: приёмка результата
Критерии приёмки простые: помощник отвечает по теме, ссылается на разделы сайта, укладывается в дневную квоту и корректно отказывает на неподходящие вопросы. Проверка на живом примере: посетитель нажимает стартовый вопрос и получает ответ со ссылкой на раздел, если ответ связан с разделом. Приёмка не гарантирует безошибочность, зато задаёт базовый уровень качества, ниже которого результат не выпускают.
Защита и ограничения: как помощник держится темы и экономит квоту
Четыре меры: отдельная модель-классификатор темы, суточный бюджет в нейронах, лимиты на IP и проверка подписи истории разговора. Каждая закрывает свою проблему, и ни одна не даёт абсолютной защиты.
Модель-классификатор темы: как отсекаются неподходящие вопросы
Отдельная модель проверяет допустимость темы. Если запрос не по теме сайта, помощник вежливо отказывает: просьба написать код или вопрос «чьи сайты самые лучшие» получают отказ. Ограничение классификатора в том, что он может ошибаться и отказывать на нормальные вопросы. Это одна из реальных ошибок автора, и лечится она настройкой промпта, а не отключением фильтра.
Суточный бюджет в нейронах и лимиты на IP
Суточный бюджет в нейронах ограничивает общий расход на модель. Лимиты на IP не дают одному посетителю выесть квоту и оставить остальных без ответов. Кнопка «Спросить ИИ» внизу страницы работает, пока не исчерпана дневная квота. Это не биллинг, а защита от перерасхода: как только бюджет выбран, помощник перестаёт отвечать до следующего дня.
Проверка подписи истории разговора
История разговора подписывается, чтобы клиент не мог подменить её и обойти ограничения. Это базовый барьер, а не криптографическая защита от всех атак: он отсекает простую подмену, но не превращает систему в неприступную.
Реальные ошибки: выдуманные кейсы, пустые ответы и лишние отказы
Три проблемы проявились в процессе, и каждая показывает слабое место такого помощника. Разбор на Habr перечисляет их вместе с остальными деталями сборки и результатами проверок.
Почему модель выдумывает кейсы и как с этим бороться
Модель отвечает по базе знаний, но может добавлять несуществующие детали: придумывать кейсы, которых в базе нет. Причина в том, что генератор стремится дать правдоподобный ответ и достраивает недостающие звенья. Что помогает: ограничить контекст только релевантными документами, прямо запретить в промпте выдумывать факты, проверять ответы на реальных вопросах. Полностью галлюцинации это не убирает.
Пустые ответы из-за рассуждений
Модель уходила в рассуждения и не выдавала финальный ответ: пользователь видел пустоту вместо консультации. Лечится настройкой промпта, ограничением длины рассуждений и выбором модели, которая лучше следует инструкциям. Рабочий приём - явно требовать финальный ответ в конце.
Лишние отказы на нормальные вопросы
Классификатор темы может оказаться слишком строгим и отказывать там, где вопрос по делу. Показательный случай: на запрос по услугам сайта помощник выдал «сортировку на Python» вместо консультации. Что помогает: подобрать порог срабатывания, прогнать классификатор на реальных вопросах и добавить в промпт примеры допустимых тем. Здесь всегда баланс между безопасностью и полезностью, и его приходится настраивать под конкретную базу.
Когда переходить к RAG и Vectorize
При базе из 14 Markdown-документов и около 12,9 тысячи символов хватает простого поиска. При росте материалов предусмотрен переход к поиску по эмбеддингам и схеме RAG с Vectorize.
Что даёт RAG с Vectorize и когда он оправдан
RAG с Vectorize ищет по смыслу, а не по ключевым словам: документы разбиваются на фрагменты, для каждого считается эмбеддинг, и модель получает только те куски, что близки к вопросу. Это оправдано, когда база большая и разнородная, а простой поиск по ключевым словам даёт плохие результаты. Для маленького сайта такой слой может быть избыточен: лишняя инфраструктура и расход на эмбеддинги без заметного выигрыша в качестве. RAG не обязателен для всех, это инструмент под конкретный объём и структуру знаний.
Кому подойдёт такой помощник и какие у него ограничения
Подход подойдёт тем, кто хочет собрать похожего помощника по документации, каталогу услуг или внутренней базе знаний. Порог входа низкий: статический хостинг, Worker, две модели и база из нескольких Markdown-файлов. Материал полезен и тем, кто пока только оценивает такой сценарий и хочет понимать ограничения подхода.
Ограничения стоит держать в голове заранее. Бесплатные квоты не бесконечны, поэтому расход приходится ограничивать бюджетом и лимитами. Качество ответов зависит от базы знаний: чем точнее и полнее документы, тем реже модель достраивает факты. Защита не абсолютна: классификатор ошибается, галлюцинации случаются, лишние отказы возможны. Наращивание числа моделей или агентов само по себе не делает систему умнее, и об этом стоит помнить, если хочется добавить ещё одну роль: рой агентов не гарантирует большего интеллекта. При достаточном упорстве заморочить голову можно любой модели; как защищаться всерьёз, разбирают специалисты по red team в отдельных исследованиях.