情景检索慢通常不是向量算法本身的问题，而是查询范围没有被前置裁剪。当用户同时给出时间条件和语义相似度条件时，如果只依赖向量索引，执行器往往先做全库相似度搜索，再按时间字段逐条过滤。百万级数据下这种路径会让单次查询延迟从几十毫秒涨到数秒。要解决这个问题，比较直接的做法是引入时间索引，让时间条件先裁剪出候选集合，再交给语义索引做精细匹配。

一、先看清执行顺序带来的性能差异

假设一个文档库有200万条记录，每条记录包含发布时间和文本向量。用户查询最近7天内与故障描述最相似的前20条。在没有时间索引的情况下，系统先跑HNSW向量检索，得到例如1000个候选，再检查这些候选的时间字段，最后保留满足时间范围的记录。由于向量检索返回的结果不保证时间均匀分布，可能大量候选来自很久以前，真正符合时间的候选很少。这样不仅多算了向量距离，还需要额外访问存储取时间字段，造成磁盘IO和内存放大。

反之，如果先按时间索引取出最近7天的文档ID列表，比如得到3.2万条记录，再在这3.2万条向量上进行语义搜索，搜索空间缩小了约98%。近似最近邻算法的复杂度与候选集大小呈次线性关系，但候选集越小，基础开销越低。压测中可以看到，先时间过滤再语义匹配的P99延迟通常只有全库检索的十分之一以下。因此，查询执行顺序的调整是优化第一步。

这里有一个常见的误区：以为向量索引本身可以带上过滤条件。实际上像FAISS这类库，过滤查询需要用IDSelector或重构索引，如果时间过滤不是索引的一部分，仍然需要在内部遍历候选。把时间字段作为外部索引独立维护，可以避免高维向量索引频繁重建。

二、时间索引的实现方式：倒排时间线、分区和位图

时间索引最简单有效的形态是按时间粒度维护倒排列表。以小时为例，可以维护每小时一个文档ID列表，称为时间桶。写入时根据文档发布时间计算出桶ID，把文档ID追加到对应桶中。查询时根据时间范围计算出需要访问的桶集合，合并得到候选ID。示例结构如下：

# 时间桶倒排索引示例
time_buckets = {}
def add_doc(doc_id, timestamp):
    bucket = int(timestamp // 3600)  # 按小时取整
    time_buckets.setdefault(bucket, []).append(doc_id)
def query_time_range(start_ts, end_ts):
    start_bucket = int(start_ts // 3600)
    end_bucket = int(end_ts // 3600)
    candidates = []
    for b in range(start_bucket, end_bucket + 1):
        candidates.extend(time_buckets.get(b, []))
    return candidates

上面的代码把小时间桶结果直接拼接，但如果时间跨度较大，例如查询一整年，合并出的列表可能超过内存限制。这时可以把时间桶进一步组织成分区文件或使用位图索引。RoaringBitmap可以在很小的空间内表示大量整数ID，多个时间桶的位图做OR运算非常快。也可以按天甚至按月维护粗粒度索引，再结合小时级细粒度索引做二次过滤。

时间分区是另一种更工程化的方式。例如Elasticsearch按时间字段创建索引时，通常按天滚动索引，查询时只打开对应日期的索引分片。这种做法天然把时间裁剪下沉到存储层，缺点是需要管理索引生命周期、分片数量可能较多。对于自建检索系统，可以用时间分区键组织段文件，每个段内只包含同一时间范围的文档，查询时跳过无关段。

选择时间粒度时需要考虑写入模式和查询模式。如果大多数查询只关心最近15分钟，那么分钟级或小时级粒度更合适；如果查询往往按天聚合，太细的粒度会产生大量小文件，影响元数据管理。可以根据日志分析结果设置多级时间索引，例如先按天定位到分区，再在分区内按小时快速裁剪。

三、混合查询重写：先过滤后排序还是先排序后过滤

有了时间索引和语义索引，还需要在查询入口设置一个重写器，把用户原始条件转换成物理执行计划。重写器负责判断时间范围的选择率。如果时间范围很窄，比如最近1小时，候选集很小，直接先时间过滤再语义排序即可。如果时间范围很宽，比如最近两年，但语义条件非常明确，可能需要先跑语义索引拿到较多候选，再用时间条件过滤。但总体而言，情景检索中时间条件通常选择率较高，先过滤后排序更常用。

下面是一个简单的查询规划示例，展示如何把时间范围和向量条件组合起来：

# 假设已有向量索引 vector_index 和时间桶 time_index
import numpy as np
def hybrid_search(query_vec, start_ts, end_ts, top_k=20):
    # 第一步：时间索引裁剪
    candidate_ids = time_index.query_time_range(start_ts, end_ts)
    if not candidate_ids:
        return []
    # 第二步：在候选集内做向量检索
    # 实际框架可使用 FAISS IDSelector 或批量计算距离
    distances = []
    for doc_id in candidate_ids:
        doc_vec = vector_index.get_vector(doc_id)
        dist = np.dot(query_vec, doc_vec)  # 余弦相似度简化表示
        distances.append((doc_id, dist))
    # 第三步：按相似度排序，截取 Top-K
    distances.sort(key=lambda x: x[1], reverse=True)
    return distances[:top_k]

上面的示例是朴素实现，候选集很大时逐条计算会慢。生产环境应使用向量索引的批量接口，把候选ID作为过滤器传入。例如FAISS的IDSelectorArray可以配合search方法，只检索ID列表中的向量。如果用Elasticsearch，可以在bool查询中组合filter时间范围和knn语义查询。无论哪种实现，关键是减少参与距离计算的向量数量。

还有一类优化是结果融合。当同一文档同时被时间索引和语义索引命中，但语义分数不够高时，是否因为时间近而提升排名？这需要根据业务调整权重。可以先归一化时间新鲜度和相似度，再加权求和，避免旧文档永远无法进入结果。这里推荐在重写器层保留两种分数，最后统一融合，不要过早丢弃候选。

四、调优实践：缓存、失效与召回率平衡

时间索引天然适合缓存。对于固定的时间范围查询，例如最近24小时如果每分钟执行一次，其实大部分结果可以复用。可以缓存时间桶合并后的候选ID集合，过期时间设置为时间窗口推进的增量。例如维护一个滑动窗口，每新增一个时间桶就把最旧的桶移出缓存。这样高频查询不再重复扫描时间索引。缓存时要注意内存占用，候选ID集合较大时使用压缩位图。

索引失效是另一个常见问题。文档删除或更新时间字段后，时间桶里的文档ID必须同步更新。如果只追加不删除，查询结果会包含已过期或已迁移的文档，导致脏读。可以在时间桶旁维护一个活跃ID集合，或者使用日志结构合并树定期清理。删除操作频繁时，建议把时间索引做成可变的，并用版本号控制缓存失效。

召回率和性能的权衡也重要。如果时间索引粒度太粗，比如按月，取一个月的候选集可能仍然很大；如果粒度太细，跨多个桶的边界查询会漏掉部分文档，尤其是文档时间字段存在时区或格式转换误差时。建议在时间过滤时增加少量冗余，例如把边界向外扩展一个时间桶，然后交给语义阶段做精确过滤，兼顾正确性和性能。监控指标应包括候选集大小、过滤后数量和最终命中数，持续观察是否存在过早过滤。