Qdrant向量库单/多集合选型及实现1的ANN效果优化咨询

我是Qdrant新手，计划将训练pipeline生成的近3天embeddings存入Qdrant向量库，附带含语言信息的payload，核心需求是使用Qdrant的ANN功能。现有两种实现方案：

• 实现1：将3天数据存入单个集合，不构建全局索引，按日期和语言分区，查询时基于日期和语言过滤执行ANN，但结果匹配度仅为KNN的50%左右；
• 实现2：按日期创建独立collection，每个collection构建全局索引，按语言分区，查询时基于语言过滤执行ANN，匹配度达KNN的98%左右，但存在成本与扩展性问题。

当前配置 #

{'result': {'status': 'green',
  'optimizer_status': 'ok',
  'vectors_count': 3517432,
  'indexed_vectors_count': 3517432,
  'points_count': 3517432,
  'segments_count': 15,
  'config': {'params': {'vectors': {'size': 128,
     'distance': 'Cosine',
     'hnsw_config': {'m': 0,
      'ef_construct': 200,
      'full_scan_threshold': 10000,
      'on_disk': True,
      'payload_m': 50},
     'on_disk': True},
    'shard_number': 3,
    'replication_factor': 1,
    'write_consistency_factor': 1,
    'on_disk_payload': True},
   'hnsw_config': {'m': 0,
    'ef_construct': 100,
    'full_scan_threshold': 10000,
    'max_indexing_threads': 0,
    'on_disk': False,
    'payload_m': 16},
   'optimizer_config': {'deleted_threshold': 0.2,
    'vacuum_min_vector_number': 1000,
    'default_segment_number': 0,
    'max_segment_size': None,
    'memmap_threshold': None,
    'indexing_threshold': 100,
    'flush_interval_sec': 5,
    'max_optimization_threads': 1},
   'wal_config': {'wal_capacity_mb': 32, 'wal_segments_ahead': 0},
   'quantization_config': None},
  'payload_schema': {'dt': {'data_type': 'keyword', 'points': 3517432},
   'language': {'data_type': 'keyword', 'points': 3517432}}},
 'status': 'ok',
 'time': 0.001034984}

方案优化与选择建议 #

提升实现1的ANN效果的配置调整 #

实现1匹配度低的核心原因是未构建有效全局HNSW索引，且现有参数设置不合理，可通过以下调整改善：

• 启用全局HNSW索引：当前配置中hnsw_config.m=0会直接禁用HNSW索引，将其调整为16-32（适配128维向量的推荐值），同时把ef_construct提升至300-500，让索引构建时建立更完善的邻居关系，从根本上提升召回率。
• 优化过滤适配参数：调整vectors.hnsw_config.payload_m至20-30，让HNSW索引更好适配dt和language的过滤条件，减少过滤后索引碎片化导致的召回损失。
• 合并分段减少全量扫描：当前segments_count=15，过多分段易导致过滤后单分段数据量低于full_scan_threshold=10000，触发全量扫描。可调整optimizer_config.max_segment_size（比如设为500000）和default_segment_number，合并小分段，让过滤后的数据能利用HNSW索引查询。
• 查询时提升候选节点数：在ANN查询请求中设置ef_search=200-300，遍历更多候选节点提升召回率，仅会带来少量查询延迟增加。

方案选择建议 #

• 优先选择优化实现1：单个集合架构的维护成本更低、扩展性更好，调整上述配置后，召回率大概率能接近实现2的98%水平，无需承担多collection的运维复杂度。
• 仅在优化后仍无法达标时考虑实现2：若业务对召回率要求极高，且能接受多collection的运维成本（比如开发定时创建/清理collection的脚本、管理分片资源），再采用按日期分collection的方案。

内容的提问来源于stack exchange，提问作者S Tripathi