向量检索怎样为时间敏感文档设置有效期过滤

我在排查知识库问答时遇到过一种很隐蔽的“答得像对的”故障：问题本身没有变化，召回内容也很相似，但回答引用的是已经失效的制度、价格或接口说明。原因通常不是 embedding 不够相似，而是检索只看向量距离，没有把文档的有效期放进候选条件。

实用做法是把生效时间、失效时间和查询时刻统一成可比较的元数据，并在向量相似度计算前先过滤当前无效文档。这样“相关”与“现在可用”是两道独立判断，时间边界也能单独复查。

官方地址：https://milvus.io/docs/filtered-search.md

过期内容为什么还会排在相似结果里

故障一般从一个时间点开始：运营人员把旧规则标记为失效，用户的问题仍然能命中这篇旧文档，而且相似度还不低。若检索请求只携带查询向量和 top-k，向量库并不知道“这条内容今天还能不能用”，它只能按语义距离返回候选。

我会先把现象拆成两个问题。第一个问题是“这段文本是否和查询相关”，由向量相似度回答；第二个问题是“它在查询时刻是否有效”，由结构化时间条件回答。把第二个问题塞进文本内容里并不稳定：模型可能读懂“已于某日废止”，也可能因为旧内容和问题高度相似而仍然把它排在前面。

因此，时间敏感文档至少需要带着 valid_from、valid_until 和明确的时间口径入库。向量只是语义表示，不能单独承担生命周期管理。

设计有效期字段时，先把时间语义固定下来

字段设计不必复杂，但要先约定边界。下面这组语义比较容易在服务之间保持一致：valid_from 表示文档开始可用的时刻，valid_until 表示失效时刻；查询时使用 valid_from 且 valid_until > query_time。后一条使用右开区间，正好到失效时刻就不再召回。

无期限文档不要把一个随意的未来日期写进去，否则以后修改业务规则时很容易忘记它的来源。可以使用约定的空值、独立的 is_permanent，或在数值字段中用 0 表示“没有失效时间”；具体选哪一种，要看向量库对空值和布尔过滤的支持情况。

时间字段最好统一为 UTC，再在展示层转换为本地时间。若一部分文档保存本地时间、另一部分保存 UTC，过滤表达式本身可能完全正确，结果却会在跨时区部署后发生偏移。

把有效期过滤放在向量召回的候选范围前面

支持标量或 metadata 条件的向量库，通常可以在搜索请求中同时提交过滤表达式和查询向量。下面用 Python 写一个通用的调用形状，字段采用整数秒；它展示的是过滤协议，不绑定某个具体 SDK 的全部参数。

from datetime import datetime, timezone

def build_validity_filter() -> tuple[int, str]:
    # 查询时刻只生成一次，避免同一请求里的上下界跨秒不一致。
    now = int(datetime.now(timezone.utc).timestamp())
    # valid_until 为 0 时代表无期限；具体表达式语法按向量库文档调整。
    expression = (
        f"valid_from  {now})"
    )
    return now, expression


def search_current_documents(client, collection_name, query_vector, limit=5):
    # 先限制生命周期，再在有效候选中按向量相似度取 top-k。
    query_time, expression = build_validity_filter()
    results = client.search(
        collection_name=collection_name,
        data=[query_vector],
        filter=expression,
        limit=limit,
        output_fields=["document_id", "valid_from", "valid_until"],
    )
    # 记录查询时刻，便于复查某次结果使用的时间口径。
    return {"query_time": query_time, "results": results}

这个结构表达了一个关键边界：先用时间条件缩小候选集合，再让向量相似度决定同一有效范围内的排序。官方向量数据库文档通常把这种条件称为 scalar 或 metadata filter；有的实现支持在 ANN 前过滤，有的还提供迭代过滤模式，实际性能和表达式能力要以使用的产品文档为准。

注意代码中把 now 固定成一次计算的值。如果生效条件和失效条件分别读取当前时间，刚好处在边界秒的文档可能出现前后判断不一致。返回查询时刻也很有用：出现争议时，可以把“为什么当时召回”还原为字段和时间的组合，而不是只保留一个相似度分数。

无期限和缺字段不能混成一种情况

真实数据里常见三种记录：有明确起止时间的文档、只有生效时间的长期文档，以及历史数据里根本没有时间字段的文档。它们的业务含义不同，过滤时也不能用一个宽松默认值全部放行。

尤其要防止“缺字段 = 0”被误解为“从 Unix 纪元开始有效”。如果旧数据没有可靠来源，宁可把它放入需要人工确认的集合，也不要让它无条件进入生产回答。时间过滤的目标是缩小不确定性，而不是用默认值掩盖不确定性。

用四个时间切片复查召回范围

不需要先看复杂的整体指标，先准备几条相同语义、不同时间状态的文档就能暴露边界问题：一条尚未生效，一条当前有效，一条刚好到失效时刻，一条已经失效。再加一条无期限文档和一条缺字段文档，分别观察过滤器的预期行为。

如果尚未生效的文档仍然出现，通常是生效条件没有加入；如果刚失效的文档仍然出现，要检查右开区间、秒和毫秒的换算；如果无期限文档消失，则要回看空值或标记的表达式。不要只看返回的文本，要把文档 ID、valid_from、valid_until 和 query_time 一起记录到可控的排查日志中。

我会把“时间过滤命中”与“向量相似度排序”分开记账。这样以后换向量模型、调 top-k 或更换过滤索引时，仍能知道结果变化是候选范围变了，还是有效候选内部的排序变了。

只在文本里写“已过期”，还需要 metadata 过滤吗？

需要。文本中的过期说明可以帮助模型理解背景，但不能稳定替代结构化条件。生命周期字段适合做硬范围约束，正文适合提供解释和出处，两者承担的职责不同。

把过滤放到向量搜索之后可以吗？

可以作为兜底，但不应默认依赖它。后过滤可能先取到一批无效文档，过滤后剩余数量不足，甚至把本应有效的候选挤出 top-k；能在召回范围前表达时间条件时，优先使用前置过滤。