想象一家典型的线上鞋店。
一位顾客打开搜索并输入:
I need black waterproof running shoes for daily runs on wet pavement. What would you recommend?
几年前,几乎没人会对搜索框提出这种期待。这个查询通常会被简化成类似下面这样:
black waterproof running shoes
然后顾客会打开几个商品卡片,比较描述、材质、适用场景和价格,再自己做决定。
今天,人们越来越期待搜索本身就能完成一部分工作。不是因为全文检索变差了。它在处理精确名称、SKU、商品编码、品牌和关键词时依然非常出色。变化的是,人们开始期待自己能向搜索系统提出什么样的问题。
例如,Google 在 2026 年 5 月报告称,AI Mode 的月活跃用户已超过十亿。该公司指出,人们正在提出更长、更复杂的问题,而这些问题过去并不适合传统搜索。(blog.google )
在线商店里的情况也是一样。
像下面这样的查询:
I need black waterproof running shoes for daily runs on wet pavement.
表面上只是一句话。对搜索系统来说,它包含了多个任务。
它需要提取颜色、防水等约束;理解这里指的是跑步而不是步行;考虑价格、尺码和库存;找到合适的商品;如果用户追问“哪个更好”,还要解释差异。
没有任何单一算法能把这些都解决。
全文检索、向量检索、过滤器、混合搜索和语言模型,各自解决的是问题的不同部分。把它们组合起来,远比在它们之间二选一更有效。
这正是 Manticore 提供 Conversational Search 的原因。
词项搜索、语义搜索和对话是不同的任务
先看一个简单查询:
Nike Pegasus 41 black
在这里,系统几乎不需要理解用户意图。全文检索可以直接处理。
或者更简单一点:
SKU 123456
这里不需要语义方法。
再看另一个例子:
light shoes for long summer walks
商品卡片里可能没有“夏天”或“长距离步行”这些词,但可能会有“透气材质”或“轻量结构”等细节。
这就是向量检索发挥作用的地方。
真实查询往往介于这两种极端之间:
black Gore-Tex shoes for everyday running
有些参数——black 和 Gore-Tex——需要保留。Everyday running 描述的是用户意图,而不是精确属性。
在这种情况下,Manticore 会使用混合搜索,通过结果排序把全文检索和向量检索结合起来。
但即使是混合搜索,返回的也仍然只是一个结果列表。
到这一步,搜索通常就认为自己完成任务了。用户往往并不这么想。
它不会回答下面这类问题:
Which of these models are better suited to rain?
它当然也无法处理这样的追问:
Which of those cost less than $120?
这就是对话。它需要另一层能力。
我们做了什么
为了在实践中验证这一点,我们使用了 ConvApparel 这个关于服装选购对话的数据集。清理后,它包含 82,524 件商品:鞋类、裤装、上衣和外套。每件商品都有描述、类别、图片和属性。我们基于这些数据构建了 Manticore Apparel Shop。
例如,你可以输入:
I need black waterproof running shoes for jogging
系统会先找到合适的商品,然后由语言模型基于这些商品作为上下文生成回答,同时界面会展示这些商品本身。
试试这个演示: Manticore Apparel Shop 会随机生成一个商品和一个应该能检索到它的查询,然后演示同样的查询确实可以通过 Manticore 找到那个商品。

关键是要保持回答与数据之间的关联。如果系统声称某个型号适合雨天,用户应该能够打开商品并验证这条说法的来源。
在这种方式下,语言模型并不是取代搜索,而是在解释搜索结果。
它是如何工作的
主要使用两个命令:
CREATE CHAT MODEL
以及
CALL CHAT(...)
首先,你创建一个 Conversational Search 模型,并设置它遵循的规则。
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 决定有多少文档进入上下文。max_document_length 限制每个文档可使用的文本量。
如果上下文太少,模型就看不到正确的商品。如果上下文太多,延迟和查询成本就会上升。和人一样,语言模型并不会因为让它读完所有内容就变得更聪明。
然后你可以发起查询:
CALL CHAT(
'I need black waterproof running shoes for jogging',
'convapparel_products',
'assistant',
'demo-session-001',
'embedding_vector'
);
接着你还可以继续对话:
CALL CHAT(
'Which of these are better for daily use?',
'convapparel_products',
'assistant',
'demo-session-001',
'embedding_vector'
);
系统会使用对话历史,因此用户不需要重复上下文。
通过 HTTP API
Conversational Search 也可以通过 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"
}
}
请求会发送到 /search。
系统会返回什么
响应中包含:
conversation_uuiduser_querysearch_query— 系统生成的搜索查询responsesources
search_query 尤其重要。
如果用户写:
Which of these would work better in rain?
脱离上下文,这个查询本身没有意义。因此系统会利用对话历史构造一个完整的搜索查询。
这也简化了调试:你可以追踪从查询到答案的整个链路。
检索如何工作
Conversational Search 使用向量检索,基于一个 embedding 字段进行检索。流程如下:
user question
→ conversation history
→ search query
→ vector search
→ retrieved documents
→ language model
→ answer and sources
搜索在哪里结束,对话从哪里开始
全文检索适合精确查询。向量检索适合语义查询。混合搜索适合二者结合。只有当结果需要被解释、比较或进一步细化时,才需要 Conversational Search。
质量
我们使用来自 ConvApparel 的 200 条确定性购物查询,对这个 对话式搜索质量基准 进行了测试。该基准评估的是返回的商品 ID 作为来源,而不是生成答案的措辞。
在当前运行中,Manticore 取得了 0.3650 Hit@3、0.4250 Hit@5、0.5250 Hit@10 和 0.2790 MRR,在受测引擎中,这四项指标都是最佳结果。完整仓库包含数据集构建规则、引擎配置、smoke 任务和原始结果。
结语
现代系统中的搜索不是单一算法,而是多个层:
- 全文检索
- 向量检索
- 混合搜索
- Conversational Search
每一层都解决自己的任务。语言模型不会取代搜索,它是在搜索之上工作的。
没有好的搜索,你得不到智能助手;你得到的只会是一个话很多、却几乎不了解自己目录的顾问。
想在实践中试试这个方案? 访问 Manticore Apparel Shop :随机选择一个商品,基于它提一个问题,并确认答案中是否能找到并推荐同一商品。
如果你想在本地运行它或查看代码,请参阅 GitHub 仓库 。

