Интеграция AI: чат-боты, RAG, семантический поиск, рекомендации
Большинство «AI-чат-ботов» на сайтах — это просто обёртка над GPT-4o с системным промптом «ты помощник компании X». Без контекста реальных данных компании. Пользователь спрашивает о конкретном тарифе — бот галлюцинирует цену. Спрашивает о статусе заказа — получает общие фразы. Это не интеграция AI, это дорогой FAQ.
RAG как основа полезного чат-бота
Retrieval-Augmented Generation — стандартный подход, когда нужно, чтобы модель отвечала на основе реальных документов компании. Схема: пользовательский запрос → поиск релевантных фрагментов в векторной БД → вставка фрагментов в контекст → ответ модели.
Детали реализации, которые определяют качество:
Chunking стратегия. Документ нельзя просто разбить на куски по 500 токенов. Если разрезать посередине абзаца, смысл теряется. Рекурсивный text splitter с overlap 10–15% — минимум. Для структурированных документов (договоры, инструкции) — семантический сплиттер по разделам.
Модель эмбеддингов. text-embedding-3-large от OpenAI или intfloat/multilingual-e5-large для русскоязычного контента. Качество поиска напрямую зависит от модели — разница между ada-002 и e5-large на русском тексте ощутима.
Векторная БД. pgvector для проектов, где уже есть PostgreSQL — ставишь расширение, добавляешь колонку типа vector(1536), создаёшь HNSW-индекс. Для больших объёмов (10M+ документов) — Qdrant или Weaviate. На проекте с базой знаний из 80 000 статей поддержки pgvector с HNSW-индексом давал p95 поиска в 12ms — этого достаточно.
Гибридный поиск. Только векторный поиск плохо находит точные совпадения (артикулы, имена, аббревиатуры). Только полнотекстовый поиск не понимает смысл. Комбинация через RRF (Reciprocal Rank Fusion): векторный поиск + BM25, результаты смешиваются. В Qdrant это называется sparse-dense hybrid search.
Reranking. После первичного поиска (top-20 кандидатов) прогоняем через cross-encoder модель (cross-encoder/ms-marco-MiniLM-L-6-v2) для точного переранжирования. Это добавляет 50–100ms, но значительно улучшает relevance.
Семантический поиск на сайте
Поиск «красные кроссовки для бега» должен найти товары с описанием «беговые кеды алого цвета», даже если слова не совпадают. Обычный LIKE-поиск это не умеет.
Архитектура: при добавлении товара/статьи автоматически генерируем эмбеддинг и сохраняем в pgvector. При поиске — эмбеддим запрос, ищем ближайших соседей по cosine similarity. Индекс HNSW на 100 000 векторов строится за 2–3 минуты, занимает ~400MB в памяти для 1536-мерных векторов.
Рекомендательные системы
Коллаборативная фильтрация («пользователи, похожие на вас, покупали X») требует истории взаимодействий — минимум несколько месяцев данных. Для нового продукта работает content-based: эмбеддинг текущего просматриваемого товара → поиск похожих по векторному расстоянию.
Гибридная модель: content-based для новых пользователей, коллаборативная для тех, у кого есть история. Switching threshold — обычно после 10–20 взаимодействий переключаемся на коллаборативную. LightFM умеет объединять оба подхода в одной модели.
Для e-commerce с реальным трафиком — A/B тестирование рекомендаций обязательно. CTR и conversion rate на рекомендованные товары — основные метрики, не accuracy модели.
Стриминг ответов
Пользователь не должен ждать, пока модель сгенерирует весь ответ. Server-Sent Events для стриминга токенов — стандарт. OpenAI SDK поддерживает stream: true, возвращает AsyncIterator. На фронтенде — Vercel AI SDK или самописный EventSource-обработчик.
Типичная ошибка: стримить на фронтенд через WebSocket вместо SSE. Для однонаправленного потока SSE проще и надёжнее.
Оркестрация агентов
Простой чат-бот отвечает на вопросы. Агент может выполнять действия: создать тикет, проверить статус заказа, забронировать время. LangChain или LangGraph для оркестрации цепочек вызовов инструментов. Vercel AI SDK (useChat + tools) для Next.js-проектов — интеграция в несколько строк.
Главная сложность агентов — надёжность. Модель иногда вызывает не тот инструмент или передаёт неверные параметры. Валидация через Zod-схемы на входе каждого инструмента, structured outputs для детерминированного JSON.
Процесс работы
Начинаем с аудита данных: что есть, в каком формате, насколько актуально. Нет смысла строить RAG на устаревшей документации. Прототип за 1–2 недели с замером метрик (retrieval precision, hallucination rate через LLM-as-judge). Затем итерации по качеству — chunking, модель эмбеддингов, reranking.
Мониторинг в продакшене: LangSmith или Langfuse для трейсинга цепочек вызовов, логирование запросов для ручного аудита качества.
Сроки
RAG-чат-бот с индексацией существующей базы знаний: 3–6 недель. Семантический поиск поверх существующего каталога: 2–4 недели. Рекомендательная система с A/B тестированием: 6–10 недель. Мультиагентная система с инструментами и интеграциями: от 8 недель.