Implementing AI-Powered Semantic Search for Website Content

Ordinary site search only returns articles if they contain the exact query words. A user searches for "how to pay" but doesn't find the article "payment methods". Semantic search solves this: it understands meaning, not strings. We implement such systems for online stores, documentation, and portals. Our experience: over 10 projects with AI search, certified solutions based on PostgreSQL and Qdrant. Contact us to discuss your scenario. One client achieved a 300% ROI within 6 months by reducing support tickets and decreasing page bounce rate.

Why Semantic Search Outperforms Full-Text Search?

Full-text search (PostgreSQL tsvector, Elasticsearch) matches words. Semantic search matches meaning. It converts text into a vector—a numeric array of 768–3072 numbers. Texts with close vectors are semantically similar. In our benchmarks, hybrid search delivers 3x better coverage than full-text search and 2x better precision than vector alone. This improves relevant result accuracy, especially for long and conversational queries.

How We Do It: Stack and Case Study

For an online store with 50,000 products, we implemented Hybrid search using OpenAI embeddings and pgvector. Result: average response time 0.3 seconds, accuracy 92%.

Model selection. We use text-embedding-3-small (1536 dimensions)—the optimal balance of speed and quality. For Russian it delivers excellent results.

Vector database. PostgreSQL with pgvector extension and HNSW index:

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);

Indexing. We split text into chunks of 400 tokens with 50-word overlap, get embeddings via OpenAI API, and save to the table:

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,
  });
  // Save to pgvector in batches of 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, /* ... */]);
  }
}

Search. We combine vector and full-text search via 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;
}

What Is Hybrid Search and Why Do You Need It?

Hybrid search combines vector and full-text results via RRF. This compensates for each method's weaknesses: vector search finds by meaning but may miss exact terms; full-text does the opposite. Together they ensure high relevance even for complex queries. We use this approach in all projects. Important: quality implementation requires experience—our engineers guarantee results.

How to Choose an Embedding Model for Russian?

Model choice is critical. Multilingual models (e.g., Cohere) often underperform compared to Russian-specialized ones. We tested several options and recommend:

Source: OpenAI Embeddings documentation

Process of Work

1. Content audit — identify text types, size, update frequency.
2. Model and vector DB selection — determine trade-off between quality and budget.
3. Content indexing and chunking — setup for optimal retrieval.
4. Search API development — endpoint with parameters: query, filters, pagination.
5. UI creation — search bar, snippets with highlighting, progressive loading.
6. Testing — A/B test with current search, metric monitoring.
7. Deployment and monitoring — alerts on latency, queries without results.

Example of incremental reindexing: To avoid reindexing all documents on every change, we use triggers on the content table and a task queue (Bull/PGBoss). On insert or update, a reindex task is created for that document only. A background worker picks up the task, gets embeddings, and updates the corresponding chunk. This keeps data current without full reindexing even with thousands of daily changes.

Estimated Timelines

Implementation cost: from $3,000 depending on data volume.

What's Included

• Complete architecture documentation (DB schema, API spec, deployment guide).
• Turnkey source code with CI/CD.
• Access to repository, data dump, monitoring dashboard.
• Team training (2–3 hours).
• 3 months of technical support.

Common mistakes: improper chunking (optimal 300-500 tokens with 50-100 overlap), choosing a model without considering language (multilingual models often perform worse on Russian), and missing reranking (cross-encoder rerank fixes this).

Want to implement meaning-based search? Contact us to discuss your project. Get a consultation for your use case.

AI Integration: Chatbots, RAG, Semantic Search, Recommendations

In 8 out of 10 projects, an "AI chatbot" turns out to be an expensive wrapper over GPT-4o with a system prompt. Without access to real company data. The user asks "how much does the Premium plan cost?" — the bot hallucinates a price out of thin air. Asks "when will my order arrive?" — gets a polite "contact support." This is not integration — it's imitation. We have implemented RAG solutions in 30+ projects over 5 years: from e-commerce stores to medical portals. We guarantee: useful AI assistance begins where the model reads your documents, not generic answers.

How do we build RAG systems?

Retrieval-Augmented Generation — standard architecture: query → find relevant fragments in a vector DB → insert found context → model response. But the devil is in the implementation details. Let's break down key components that determine quality.

Chunking. Cutting a document into 500-token pieces without regard for structure is a guarantee of losing meaning. If the cut lands in the middle of a paragraph, context breaks. Solution — recursive RecursiveCharacterTextSplitter with 10–15% overlap for documentation. For contracts and instructions, we use a semantic splitter: extract headings, lists, code blocks — each section becomes an independent chunk. Difference in search quality: on a medical project, precision increased from 0.55 to 0.84 just by proper chunking.

Embedding model. For Russian-language texts, intfloat/multilingual-e5-large gives a noticeable accuracy boost over outdated text-embedding-ada-002. In our measurements, NDCG@10 on a test set of 10,000 query-document pairs is 12% higher. OpenAI text-embedding-3-large is good for English content, but for Russian we recommend BAAI/bge-m3 or the mentioned e5-large.

Vector DB. If you already have PostgreSQL — pgvector saves resources. Install extension CREATE EXTENSION vector, add column vector(1024), create HNSW index. On a project with 80,000 support articles, p95 search time was 12 ms. That's enough. For catalogs with millions of items — Qdrant or Weaviate: native hybrid search and sharding out of the box.

What does hybrid search give?

Vector-only search is blind to exact matches: SKUs like "ABC-123", proper names, abbreviations are lost. Full-text-only search doesn't catch synonyms and paraphrasing. Combining via RRF (Reciprocal Rank Fusion) gives the best of both worlds: BM25 + vector search, results merged. In practice, recall@20 increases from 0.65 to 0.92 — the difference is noticeable to the user.

Reranking — final filter: top-20 candidates from hybrid search are run through a cross-encoder cross-encoder/ms-marco-MiniLM-L-6-v2. It adds 50–100 ms to response time, but relevance improves by another 5–10%. Without reranking, the chatbot may show irrelevant documents.

How to implement semantic search on a site?

A search for "comfortable leather armchairs" should find products described as "soft chairs made of natural leather" — ordinary LIKE search cannot do this. Our architecture: when adding a product/post, automatically generate an embedding via multilingual-e5-large, store it in pgvector. On query, embed it with the same model, search nearest neighbors via cosine distance with HNSW index. For a catalog of 100,000 items, index builds in 3 minutes, memory ~400 MB (1536-dimensional vectors). Average search time: 20 ms.

What about recommendation systems?

Collaborative filtering ("users like you bought X") requires history — at least 2–3 months of data with 1000+ active users. For startups or small projects, we use content-based: embedding of current product → search nearest neighbors by cosine similarity. When enough statistics accumulate (usually 15–20 interactions per user), we switch to a hybrid LightFM model. It combines behavior and product features. In our e-commerce project with 50,000 SKUs, the hybrid model increased conversion in the recommendation block by 18% (A/B test lasted 2 weeks).

How does streaming work?

Users shouldn't wait for the entire text to be generated — it kills UX. Server-Sent Events (SSE) is the protocol for token streaming. OpenAI SDK supports stream: true, returning an AsyncIterator. On frontend — Vercel AI SDK (useChat) or custom EventSource. Typical mistake: using WebSocket for unidirectional streaming — SSE is simpler (less code, built-in reconnect). Stack: Node.js + SSE + React.

How to orchestrate agents?

A simple chatbot answers. An agent performs actions: creates a Jira ticket, checks order status in CRM, books a calendar slot. For orchestration, we use LangGraph: state graph where each node is a model or tool call. Vercel AI SDK useChat + tools for Next.js allows adding integration in 10 lines of code. Main challenge — reliability: the model sometimes calls the wrong tool or passes malformed parameters. Protection — Zod schemas for each tool and structured outputs to guarantee JSON.

What does the work include?

Additionally: we hand over vectorizer source code, monitoring dashboards (Langfuse), admin panel access for knowledge base updates. Post-production support — 1 month free.

What are the timelines?

Pricing is calculated individually after project discovery. We'll evaluate your project in 1 day. Contact us — we'll show how to turn AI from a toy into a profit-driving tool.