What is RAG, and how do voice assistants answer from your site content?

What is RAG? A short, clear definition

RAG stands for retrieval augmented generation. The idea is simple: instead of asking the language model the question bare, you first fetch the text passages most relevant to it from a trusted source (your knowledge base), then tell the model to 'answer based on these sources.' The model now speaks from the evidence in front of it, not from memory.

Think of it as an open-book exam. In a closed-book exam a student writes only what they remember and fabricates where unsure. In an open book they first find the right page, then answer from it. RAG moves the model from closed book to open book — and the 'book' is your website.

A classic LLM has two core problems: its knowledge is frozen at training time (it knows nothing about yesterday's campaign, your new product, or your current return policy), and even when unsure it can produce a confidently worded wrong answer. RAG solves both: the retrieved content is both current and yours.

Embeddings: turning text into 'meaning'

How does a computer know that 'how do I return an item' and 'sending a product back' mean the same thing, even with no shared keyword? The answer is embeddings. An embedding turns a piece of text into a several-hundred-dimensional array of numbers (a vector). Texts that mean similar things land near each other in this space; unrelated texts land far apart.

RAQS embeds your content with Azure's text-embedding-3-small model. Every text chunk on your site is embedded and stored ahead of time, and when a visitor asks a question, that question is embedded with the same model on the fly. The question 'which content is most relevant?' now becomes a mathematical proximity problem: 'which content vectors are closest to the question vector?'

This is far stronger than keyword matching: even if a visitor uses none of the exact words on your page, you can still catch the passage that matches in meaning. That matters a lot for voice assistants, because people speak in loose, everyday language — not the formal terms written on a page.

Hybrid retrieval: vector + keyword

Semantic (vector) search alone isn't always enough. For a product code, model name, SKU or a rare term — say 'is the XR-450 in stock?' — an exact word match is sharper than semantic similarity. Conversely, for loose phrasing like 'how long does shipping take,' semantic search shines. So RAQS uses both at once: hybrid retrieval.

In practice two searches run in parallel. The first is a semantic vector search over pgvector; the second is PostgreSQL's full-text keyword search. The two ranked lists are merged into one with RRF (Reciprocal Rank Fusion) — each result gets a fair score based on its rank position in both lists. Results that capture both meaning and exact term rise to the top.

As a final step, a similarity threshold kicks in: if no chunk is relevant enough, the system marks what it has as 'not relevant enough' rather than forcing an answer. This threshold is a critical fuse that prevents hallucination — more on that next.

Why does RAG prevent hallucination?

Hallucination is when a model fabricates a convincing but wrong answer even on something it isn't sure about. RAG breaks this in two ways. First: the model is instructed to derive the answer from the passages put in front of it, not from its own head — so generation is bound to retrieved evidence. Second: when retrieval comes back empty, the model is told 'there is no source to answer from,' and the assistant honestly says 'I don't know.'

RAQS adopts this behavior as a deliberate design choice: the assistant speaks only from your knowledge base, and when there's no match it doesn't invent an answer — it says it doesn't know. For a voice assistant a brand puts on its site, this is non-negotiable: a wrong price, a wrong return policy, or a promise of a product that doesn't exist is a real cost.

So don't think of RAG as merely 'smarter search.' Its real value is binding the answer to an auditable source: behind every answer is content you approved, crawled, or uploaded.

How RAQS builds it end to end: crawl → chunk → embed → search

In RAQS, making a voice assistant answer from your site content runs through a four-step pipeline. Step 1 — Crawl: your sitemap and pages are crawled. JS-rendered SPA sites are processed with a headless browser so they don't come back empty; text is cleanly extracted with trafilatura, stripped of menu/footer noise; robots.txt is respected and a per-plan page quota applies. Instead of crawling you can paste text/FAQ or upload PDF, Word, TXT, MD and CSV files.

Step 2 — Chunking: long pages are split into meaningful chunks that fit the model context and cover a single topic. Step 3 — Embedding: each chunk is embedded with Azure text-embedding-3-small and stored in pgvector; at the same time the text enters PostgreSQL's full-text index for keyword search.

Step 4 — Search and answer: when a visitor speaks, the question is embedded with the same model, hybrid retrieval (vector + keyword + RRF + threshold) fetches the most relevant chunks, and these are given as context to the Azure OpenAI gpt-4o-mini brain. The brain produces the reply on the Pipecat pipeline, transported with low latency over LiveKit and voiced with Azure Speech. On e-commerce, schema.org JSON-LD data on product pages (name, brand, price, stock, category) is extracted too — so 'is X in stock, how much?' is answered correctly.

<script async src="https://raqs.ai/v1/raqs.js"
  data-raqs="YOUR_SITE_KEY"></script>