Реализация AI-поиска по контенту сайта (Semantic Search)

Обычный поиск по сайту выдаёт статьи только если в них встречаются точные слова запроса. Пользователь ищет «как оплатить» — не находит статью «способы расчёта». Семантический поиск решает эту проблему: он понимает смысл, а не строки. Мы внедряем такие системы для интернет-магазинов, документации и порталов. Наш опыт — более 10 проектов с AI-поиском, сертифицированные решения на базе PostgreSQL и Qdrant. Свяжитесь с нами, чтобы обсудить ваш сценарий.

Почему семантический поиск лучше полнотекстового? — реализация ai поиска

Полнотекстовый поиск (PostgreSQL tsvector, Elasticsearch) ищет по совпадению слов. Семантический — по смыслу. Он преобразует текст в вектор — числовой массив из 768–3072 чисел. Тексты с близкими векторами семантически похожи. Это даёт прирост точности релевантных результатов в 2–3 раза, особенно для длинных и разговорных запросов.

Как мы это делаем: стек и кейс

Для интернет-магазина с 50 000 товаров мы внедрили гибридный поиск на базе OpenAI embeddings и pgvector. Результат: среднее время ответа 0,3 секунды, точность 92%.

Выбор модели. Используем text-embedding-3-small (1536 измерений) — оптимальный баланс скорости и качества. Для русского языка он даёт отличные результаты.

Векторная база. PostgreSQL с расширением pgvector и HNSW-индексом:

CREATE EXTENSION vector;

CREATE TABLE content_chunks (
  id BIGSERIAL PRIMARY KEY,
  content_id BIGINT REFERENCES content(id),
  chunk_text TEXT NOT NULL,
  chunk_index INT,
  embedding vector(1536),
  metadata JSONB
);

CREATE INDEX ON content_chunks USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

Индексация. Разбиваем текст на чанки по 400 токенов с перекрытием 50 слов, получаем эмбеддинги через OpenAI API и сохраняем в таблицу:

import OpenAI from 'openai';
const openai = new OpenAI();

async function indexContent(contentItem) {
  const chunks = chunkText(contentItem.body, { maxTokens: 400, overlap: 50 });
  const { data: embeddings } = await openai.embeddings.create({
    model: 'text-embedding-3-small',
    input: chunks,
  });
  // Сохраняем в pgvector батчами по 100
  for (let i = 0; i < chunks.length; i += 100) {
    const batchChunks = chunks.slice(i, i + 100);
    const batchEmbeds = embeddings.slice(i, i + 100);
    await db.query(`
      INSERT INTO content_chunks (content_id, chunk_text, chunk_index, embedding, metadata)
      VALUES ($1, $2, $3, $4::vector, $5)
    `, [contentItem.id, batchChunks, /* ... */]);
  }
}

Поиск. Комбинируем векторный и полнотекстовый поиск через RRF (Reciprocal Rank Fusion):

async function semanticSearch(query, { limit = 10, threshold = 0.7 } = {}) {
  const { data: [{ embedding }] } = await openai.embeddings.create({
    model: 'text-embedding-3-small',
    input: query,
  });
  const results = await db.query(`
    WITH semantic AS (
      SELECT content_id, chunk_text,
             1 - (embedding <=> $1::vector) AS score,
             ROW_NUMBER() OVER (ORDER BY embedding <=> $1::vector) AS rank
      FROM content_chunks
      ORDER BY embedding <=> $1::vector
      LIMIT 20
    ),
    fulltext AS (
      SELECT id AS content_id, body AS chunk_text,
             ts_rank(to_tsvector('russian', body), plainto_tsquery('russian', $2)) AS score,
             ROW_NUMBER() OVER (ORDER BY ts_rank(...) DESC) AS rank
      FROM content
      WHERE to_tsvector('russian', body) @@ plainto_tsquery('russian', $2)
      LIMIT 20
    )
    SELECT COALESCE(s.content_id, f.content_id) AS id,
           COALESCE(s.chunk_text, f.chunk_text) AS text,
           (COALESCE(1.0 / (60 + s.rank), 0) + COALESCE(1.0 / (60 + f.rank), 0)) AS rrf_score
    FROM semantic s FULL OUTER JOIN fulltext f ON s.content_id = f.content_id
    ORDER BY rrf_score DESC
    LIMIT $3
  `, [`[${embedding.join(',')}]`, query, limit]);
  return results.rows;
}

Что такое гибридный поиск и зачем он нужен?

Гибридный поиск объединяет результаты векторного и полнотекстового методов через RRF. Это компенсирует слабости каждого: векторный поиск находит по смыслу, но может пропустить точное вхождение термина; полнотекстовый — наоборот. Вместе они обеспечивают высокую релевантность даже для сложных запросов. Мы используем этот подход во всех проектах. Важно: качественное внедрение требует опыта — наши инженеры гарантируют результат.

Как выбрать embedding-модель для русского языка?

Выбор модели критичен. Multilingual-модели (например, Cohere) часто уступают специализированным на русском. Мы тестировали несколько вариантов и рекомендуем:

Source: OpenAI Embeddings documentation

Процесс работы

1. Аудит контента — выделяем типы текстов, размер, частоту обновлений.
2. Выбор модели и векторной БД — определяем компромисс между качеством и бюджетом.
3. Настройка индексации — чанкинг, конфигурация индекса, batch-обработка.
4. Разработка API поиска — endpoint с параметрами: запрос, фильтры, пагинация.
5. Создание UI — поисковая строка, сниппеты с подсветкой, прогрессивная загрузка.
6. Тестирование — A/B-тест с текущим поиском, мониторинг метрик.
7. Деплой и мониторинг — алерты по задержкам, запросы без результатов.

Сроки ориентировочно

Итого: от 8 до 12 рабочих дней. Стоимость рассчитывается индивидуально.

Что входит в работу

• Полная документация архитектуры (схема БД, API спецификация, инструкция по развёртыванию).
• Исходный код под ключ с CI/CD.
• Доступ к репозиторию, дампу данных, мониторинг-дашборду.
• Обучение команды (2–3 часа).
• Техническая поддержка 3 месяца.

Типичные ошибки при внедрении

• Неправильный чанкинг: слишком длинные чанки (>1000 токенов) снижают точность, слишком короткие — теряют контекст. Оптимум: 300–500 токенов с перекрытием 50–100.
• Выбор модели без учёта языка: multilingual-модели (например, Cohere) часто работают хуже на русском, чем специализированные OpenAI embeddings.
• Отсутствие переранжирования: даже хороший векторный поиск иногда выдаёт нерелевантные топ-результаты. Cross-encoder rerank исправляет это.

Хотите внедрить семантический поиск? Свяжитесь с нами — обсудим ваш проект. Получите консультацию по вашему сценарию использования.

Интеграция AI: чат-боты, RAG, семантический поиск, рекомендации

В 8 из 10 проектов «AI-чат-бот» оказывается дорогой обёрткой над GPT-4o с системным промптом. Без доступа к реальным данным компании. Пользователь спрашивает «сколько стоит тариф Премиум» — бот галлюцинирует цену из воздуха. Спрашивает «когда придёт заказ» — получает вежливое «напишите в поддержку». Это не интеграция — это имитация. Мы за 5 лет внедрили RAG-решения в 30+ проектах: от интернет-магазинов до медицинских порталов. Гарантируем: полезная AI-помощь начинается там, где модель читает ваши документы, а не общие ответы.

Как мы строим RAG-системы?

Retrieval-Augmented Generation — стандартная архитектура: запрос → поиск релевантных фрагментов в векторной БД → вставка найденного в контекст → ответ модели. Но дьявол в деталях реализации. Разберём ключевые узлы, которые определяют качество.

Chunking. Резать документ на куски по 500 токенов без оглядки на структуру — гарантия потери смысла. Если разрез пришёлся на середину абзаца, контекст разрывается. Решение — рекурсивный RecursiveCharacterTextSplitter с overlap 10–15% для документации. Для контрактов и инструкций используем семантический сплиттер: выделяем заголовки, списки, блоки кода — каждый раздел становится независимым чанком. Разница в качестве поиска: на одном медицинском проекте precision вырос с 0.55 до 0.84 только за счёт правильной нарезки.

Модель эмбеддингов. Для русскоязычных текстов intfloat/multilingual-e5-large даёт заметный прирост точности против устаревшей text-embedding-ada-002. По нашим замерам, NDCG@10 на тестовой выборке из 10 000 пар «запрос-документ» на 12% выше. OpenAI text-embedding-3-large — хороший вариант для англоязычного контента, но для русского рекомендуем BAAI/bge-m3 или упомянутую e5-large.

Векторная БД. Если у вас уже стоит PostgreSQL — pgvector экономит ресурсы. Ставим расширение CREATE EXTENSION vector, добавляем колонку vector(1024), создаём HNSW-индекс. На проекте с 80 000 статей поддержки p95 поиска — 12 мс. Этого хватает. Для каталогов с миллионами единиц — Qdrant или Weaviate: нативный гибридный поиск и шардирование «из коробки».

Что даёт гибридный поиск?

Только векторный поиск слеп к точным совпадениям: артикулы «ABC-123», имена собственные, аббревиатуры теряются. Только полнотекстовый поиск не улавливает синонимы и перефразирования. Комбинация через RRF (Reciprocal Rank Fusion) даёт лучшее из двух миров: BM25 + векторный поиск, результаты смешиваются. На практике recall@20 растёт с 0.65 до 0.92 — разница заметна пользователю.

Reranking — финальный фильтр: top-20 кандидатов из гибридного поиска прогоняем через cross-encoder cross-encoder/ms-marco-MiniLM-L-6-v2. Он добавляет 50–100 мс к ответу, но relevance поднимает ещё на 5–10%. Без reranking чат-бот может показывать нерелевантные документы.

Семантический поиск на сайте

Поиск «удобные кожаные кресла» должен находить товары с описанием «мягкие стулья из натуральной кожи» — обычный LIKE-поиск не способен. Наша архитектура: при добавлении товара/поста автоматически генерируем эмбеддинг через multilingual-e5-large, сохраняем в pgvector. На запросе — эмбеддим его той же моделью, ищем ближайших соседей через cosine distance с HNSW-индексом. Для каталога из 100 000 позиций индекс строится 3 минуты, в памяти ~400 Мбайт (1536-мерные векторы). Cреднее время поиска — 20 мс.

Рекомендательные системы

Коллаборативная фильтрация («пользователи, похожие на вас, покупали X») требует истории — минимум 2–3 месяца данных с 1000+ активных пользователей. Для стартапов или малых проектов используем content-based: эмбеддинг текущего товара → поиск ближайших соседей по косинусной близости. Когда накапливается статистика (обычно 15–20 взаимодействий на пользователя), переключаемся на гибридную модель LightFM. Она объединяет и поведение, и признаки товаров. У нас в e-commerce проекте с 50 000 SKU гибридная модель повысила конверсию в рекомендательный блок на 18% (A/B-тест длился 2 недели).

Стриминг ответов

Пользователь не обязан ждать, пока модель сгенерирует весь текст — это убивает UX. Server-Sent Events (SSE) — протокол для стриминга токенов. OpenAI SDK поддерживает stream: true, возвращая AsyncIterator. На фронтенде — Vercel AI SDK (useChat) или самописный EventSource. Типичная ошибка: использовать WebSocket для однонаправленного стрима — SSE проще (меньше кода, встроенный реконнект). Стек: Node.js + SSE + React.

Оркестрация агентов

Простой чат-бот отвечает. Агент — выполняет действия: создаёт тикет в Jira, проверяет статус заказа в CRM, бронирует слот в календаре. Для оркестрации используем LangGraph: граф состояний, где каждый узел — вызов модели или инструмента. Vercel AI SDK useChat + tools для Next.js позволяет добавить интеграцию в 10 строк кода. Главная сложность — надёжность: модель иногда вызывает не тот инструмент или передаёт кривые параметры. Защита — Zod-схемы на каждый инструмент и structured outputs для гарантии JSON.

Что входит в работу

Дополнительно: мы передаём исходный код векторизатора, дашборды мониторинга (Langfuse), доступ к админке для обновления базы знаний. Постпродакшн-поддержка — 1 месяц бесплатно.

Сроки

Стоимость рассчитывается индивидуально после знакомства с проектом. Оценим ваш проект за 1 день. Свяжитесь с нами — расскажем, как превратить AI из игрушки в инструмент, который приносит прибыль.