很多团队做 RAG 时，注意力都放在模型选择上，但真正决定效果上限的，往往是检索层设计。

Qdrant 作为向量数据库，在高性能检索与过滤能力上非常适合生产级 RAG。

构建流程总览

一个可用的检索层至少包含：

文档清洗与分块
向量化与入库
向量检索 + 元数据过滤
重排序（可选）
结果拼接与生成

分块策略建议

常见误区是统一固定 chunk 大小。

更推荐按内容类型分层：

FAQ：短块，强调精确命中
技术文档：中块，保留上下文
政策/合同：较大块，减少语义断裂

同时保留章节、版本、时间等元数据，后续过滤会更准确。

检索策略建议

1. 向量检索 + 过滤组合

生产场景通常需要先过滤再检索，例如：

只看最近 90 天文档
只看某业务线知识库
只看已发布版本

2. 动态 TopK

不要固定 k=4。对复杂问题可提高召回量，再通过重排压缩上下文。

3. 重排序提升相关性

当召回量上来后，重排模型通常能显著提升最终回答质量。

评估指标

建议同时监控：

Retrieval Recall（是否召回关键片段）
Context Precision（上下文是否噪声过高）
Answer Groundedness（回答是否基于检索内容）

只看“用户主观感觉”很难持续优化。

总结

Qdrant 提供了构建高性能 RAG 检索层的核心能力，但效果取决于整条数据与评估链路。把检索当成产品能力持续运营，而不是一次性配置，才能长期提升 Agent 质量。

若你已经有线上流量，建议优先做“问题分层 + 检索策略分层”，通常比盲目更换模型更有效。

Qdrant additions

嵌入模型选择：不是越大越好

很多团队选嵌入模型的直觉是"参数越大效果越好"，但 RAG 场景下不一定。判断标准应该是：

与你业务领域语料的相似度排序一致性
单次嵌入延迟（影响入库与查询吞吐量）
向量维度对存储成本的影响
多语言支持需求

实践里 multilingual-e5-large、bge-m3、Cohere embed-multilingual-v3 是常见折中点。OpenAI text-embedding-3-small/large 在通用中文表现稳定，但成本随 chunk 数量线性增加。

混合检索：BM25 + 向量的双轨召回

纯向量检索在以下场景会失效：

专有名词、型号、版本号
短查询词（少于 5 个 token）
业务术语与文档表述差异大

常见做法是 BM25 + 向量召回融合（Reciprocal Rank Fusion）。Qdrant 原生只做向量检索，但融合可以在客户端完成。建议打分权重从 0.5/0.5 开始，再根据评估结果调整。

Payload 过滤器的索引策略

Qdrant 的 payload 过滤依赖字段索引。生产中常被忽略：

高频过滤字段必须建索引（关键词、整数、布尔）
数组字段（tags）建 keyword 索引，限制 array 长度
时间字段必须 ISO8601，避免字符串比较
过滤组合多时考虑用 should 而不是 must

过滤器命中顺序也会影响延迟。Qdrant 在 1.7+ 引入了优化器，但还是要先用 .explain() 看 query plan。

重排序模型的选型与陷阱

重排序不是越多越好。常见误区：

把 cross-encoder 用在召回前——成本爆炸
用 LLM 做重排序——延迟不可控
不区分 query 类型——短查询和长查询共用同一个 reranker

推荐分层策略：第一层用轻量 bi-encoder（已在向量库里），第二层用 cross-encoder（如 bge-reranker-large），只在候选进入 top 20 后调用。

评估集构建：从日志到离线集

最实用的评估集来源是线上 query 日志：

收集最近 30 天 query，去重
按业务类型人工标注"是否答对"
抽取 200-500 条作为离线集
每次检索配置改动都跑一次

不要试图构造"完美的测试集"——业务变化快，3 个月前的标注就过时了。短期集 + 持续更新 远胜一次性大而全的评估集。

Qdrant + RAG 检索优化指南：从召回到回答质量