Originally posted by Klim Todrik on https://manticoresearch.com/blog/conversational-search/ on Aug 20, 2026
Imagine a typical online shoe store.
A shopper opens search and types:
I need black waterproof running shoes for daily runs on wet pavement. What would you recommend?
A few years ago, almost no one expected this from a search box. The query would have been shortened to something like:
black waterproof running shoes
Then the shopper would open several product cards, compare descriptions, materials, intended use, and price, and make the decision alone.
Today, people increasingly expect search itself to do part of that work. Not because full-text search has become worse. It still performs very well with exact names, SKUs, product codes, brands, and keywords. What has changed is what people expect to be able to ask a search system.
For example, Google reported in May 2026 that AI Mode had surpassed one billion monthly users. The company notes that people are asking longer, more complex questions that previously did not fit into conventional search. (blog.google)
The same thing happens in an online store.
A query such as:
I need black waterproof running shoes for daily runs on wet pavement.
only looks like one sentence. For a search system, it contains several tasks.
It needs to extract constraints such as color and waterproofing; understand that this is about running rather than walking; account for price, size, and availability; find suitable products; and, if the user asks “which are better,” explain the differences.
No single algorithm solves all of that.
Full-text search, vector search, filters, hybrid search, and a language model each solve different parts of the problem. It is far more effective to combine them than to choose between them.
That is exactly why Manticore has Conversational Search.
Word search, semantic search, and conversation are different tasks
Start with a simple query:
Nike Pegasus 41 black
Here, the system barely needs to interpret the user’s intent. Full-text search handles it directly.
Or something even simpler:
SKU 123456
Semantic methods are not needed here.
Now consider another example:
light shoes for long summer walks
A product card may not contain the words “summer” or “long walks,” but it may include details such as “breathable material” or “lightweight construction.”
This is where vector search becomes useful.
Real queries often fall between these extremes:
black Gore-Tex shoes for everyday running
Some parameters — black and Gore-Tex — need to be preserved. Everyday running describes the user’s intent rather than an exact attribute.
For such cases, Manticore uses hybrid search, combining full-text and vector search through result ranking.
But even hybrid search returns only a list of results.
At that point, search considers its job done. The user usually does not.
It does not answer questions such as:
Which of these models are better suited to rain?
And it certainly does not handle a follow-up such as:
Which of those cost less than $120?
That is a conversation. It needs another layer.
What we built
To test this in practice, we used ConvApparel, a dataset of conversations about choosing apparel. After cleanup, it contained 82,524 products: footwear, pants, tops, and outerwear. Each product has a description, category, images, and attributes. We built Manticore Apparel Shop on this data.
For example, you can type:
I need black waterproof running shoes for jogging
The system first finds suitable products, then a language model generates an answer using them as context, while the interface shows the products themselves.
Try the demo: Manticore Apparel Shop generates a random product and a query that should retrieve it, then demonstrates that the same query does retrieve that product through Manticore.
It is important to keep the connection between the answer and the data. If the system claims that a model is suitable for rain, the user should be able to open the product and verify the source of that claim.
In this approach, the language model does not replace search. It interprets its results.
How it works
Two main commands are used:
CREATE CHAT MODEL
and
CALL CHAT(...)
First, you create a Conversational Search model and set the rules it follows.
CREATE CHAT MODEL assistant (
model='openrouter:google/gemma-4-26b-a4b-it',
timeout=60,
retrieval_limit=5,
max_document_length=3000,
custom_prompt='You are a context-only shopping assistant.
Answer using only the provided context.
Do not use outside knowledge or unsupported assumptions.
Recommend only products supported by the retrieved context.
For every recommended product, briefly explain why it matches the request.
End every recommendation with the corresponding
context source ID in the format [ref:<id>].
If none of the retrieved products support the request,
say that you do not have enough information.'
);
retrieval_limit determines how many documents enter the context. max_document_length limits the amount of text from each document.
If there is too little context, the model will not see the right products. If there is too much, latency and query cost increase. Like a person, a language model does not become smarter just because it has been given everything to read.
You can then run a query:
CALL CHAT(
'I need black waterproof running shoes for jogging',
'convapparel_products',
'assistant',
'demo-session-001',
'embedding_vector'
);
You can then continue the conversation:
CALL CHAT(
'Which of these are better for daily use?',
'convapparel_products',
'assistant',
'demo-session-001',
'embedding_vector'
);
The system uses conversation history, so the user does not need to repeat the context.
Through the HTTP API
Conversational Search is also available through the JSON API:
{
"chat": {
"query": "I need black waterproof running shoes for jogging",
"table": "convapparel_products",
"model_name": "assistant",
"conversation_uuid": "demo-session-001",
"vector_field": "embedding_vector"
}
}
The request is sent to /search.
What the system returns
The response contains:
conversation_uuiduser_query-
search_query— the search query generated by the system responsesources
search_query is particularly important.
If the user writes:
Which of these would work better in rain?
On its own, this query makes no sense without context. The system therefore forms a complete search query using the conversation history.
This also simplifies debugging: you can trace the entire chain from query to answer.
How retrieval works
Conversational Search uses vector search over an embedding field. The flow looks like this:
user question
→ conversation history
→ search query
→ vector search
→ retrieved documents
→ language model
→ answer and sources
Where search ends and conversation begins
Full-text search works well for exact queries. Vector search works with semantic ones. Hybrid search works with their combination. Conversational Search is needed when the result must be explained, compared, or refined.
Quality
We tested this on our conversational search quality benchmark, using 200 deterministic shopping queries from ConvApparel. The benchmark evaluates the product IDs returned as sources, rather than the wording of the generated answer.
In the current run, Manticore scored 0.3650 Hit@3, 0.4250 Hit@5, 0.5250 Hit@10, and 0.2790 MRR — the best result on each of those metrics among the engines tested. The full repository includes the dataset-building rules, engine configuration, smoke tasks, and raw results.
Conclusion
Search in modern systems is not one algorithm but several layers:
- full-text search
- vector search
- hybrid search
- Conversational Search
Each solves its own task. A language model does not replace search; it works on top of it.
Without good search, you do not get a smart assistant; you get a very talkative consultant that barely knows its own catalog.
Want to test the approach in practice? Try Manticore Apparel Shop: choose a random product, ask a question based on it, and confirm that the same product is found and suggested in the answer.
If you want to run it locally or explore the code, check the GitHub repository.
