“去年冬天的雪景”这句话人读起来没有压力交给文搜图却容易变成两次误会模型只理解“冬天、雪景”的视觉语义页面又把“去年”粗暴换算成最近 365 天。Moment Scope 这次要解决的不是搜索框样式而是把相对时间变成可复测的日历区间再对语义候选做第二阶段约束。一、结果看起来都对年份却全错了Moment Scope 是一个本地相册检索 Demo。最初的链路很直将照片纳入文搜图索引调用语义搜索按分数展示前 20 张。输入“海边日落”“蓝色汽车”时效果不错输入“去年冬天的雪景”时首屏也确实都是雪景但 6 张里有 4 张来自 2024 年。这类错误很隐蔽因为单张图片符合视觉描述只有把时间轴拉出来才会发现不对。我一开始尝试把查询改写成“2025 年冬天的雪景”结果模型仍不保证把年份当作硬条件。语义模型擅长召回“像什么”拍摄时间却是媒体资产的结构化事实两者不该混在一次打分里。最后采用两阶段方案第一阶段让 Core Vision Kit 尽量召回相关图片第二阶段从 Media Library Kit 对应的资产记录中读取拍摄时间以半开区间过滤再在区间内重排。本文固定以 2026 年 10 月 2 日为锚点查询去年冬天的雪景产品约定“去年冬天”为2025-12-01 00:00到2026-03-01 00:00结束时间不包含。任务 ID 为SEARCH-1002-01语义候选 42 张时间命中 9 张最终展示 6 张总耗时 286 ms。二、相对时间先变成明确合同“去年”并不难难的是“去年冬天”跨过自然年。如果直接取anchor.getFullYear() - 1再把开始和结束都放在同一年会得到 2025 年 12 月到 2025 年 3 月的倒置区间。另一个常见错误是用 90×24 小时推算季度在有夏令时的地区会出现小时偏移。当前问题是给搜索层一个不含歧义的区间合同。这里按日历构造本地时间并使用[startMs, endExclusiveMs)半开区间避免最后一天的 23:59:59.999 处理。exportinterfaceTimeWindow{label:stringstartMs:numberendExclusiveMs:number}exportfunctionparseRelativeWindow(query:string,anchor:Date):TimeWindow|undefined{constyearanchor.getFullYear()if(query.includes(去年冬天)){return{label:去年冬天,startMs:newDate(year-1,11,1,0,0,0,0).getTime(),endExclusiveMs:newDate(year,2,1,0,0,0,0).getTime()}}if(query.includes(去年12月)){return{label:去年12月,startMs:newDate(year-1,11,1).getTime(),endExclusiveMs:newDate(year,0,1).getTime()}}returnundefined}代码在用户提交查询后、调用语义搜索前执行。2026-10-02作为 anchor 时去年冬天会稳定得到 2025-12-01 至 2026-03-01而不是“向前 365 天”。半开区间也让 2026-03-01 零点自然落到区间外筛选表达式只需要 start end。Demo 只覆盖两个短语正式产品应把“上周、春节前后、最近三个月”交给独立的日期语法层并明确地区、周起始日和节日日历。不要在界面渲染时临时解析否则每次重组都会制造不同锚点。该函数无资源需要释放但 anchor 必须在一次任务开始时冻结午夜跨日后也不能偷偷变化。三、语义召回与时间事实不能互相替代时间解析完成后我没有先从相册筛出三个月的图片再建临时语义索引。那样会频繁维护索引成本高也容易在相册变更时漏图。Moment Scope 保持一个长期语义索引先取topK80的候选再把候选 URI 与媒体资产账本对齐。当前问题是异步搜索可能连续触发旧查询不能覆盖新查询。协调器用epoch隔离迟到结果并把状态拆为PARSING → SEARCHING → FILTERING → COMPLETED。exportinterfaceSemanticHit{uri:stringsemanticScore:number}exportclassSearchCoordinator{privateepoch:number0asyncrun(query:string,anchor:Date):PromiseSearchViewModel{constminethis.epochconstwindowparseRelativeWindow(query,anchor)if(!window)thrownewError(TIME_EXPRESSION_UNSUPPORTED)consthits:SemanticHit[]awaittextSearchImage.search(query,{topK:80})if(mine!this.epoch)thrownewError(STALE_SEARCH_RESULT)constassetsawaitMediaAssetLedger.resolve(hits.map(itemitem.uri))if(mine!this.epoch)thrownewError(STALE_ASSET_RESULT)returnbuildRankedResult(SEARCH-1002-01,hits,assets,window)}invalidate():void{this.epoch}}第一段 await 回来后检查一次资产查询回来后再检查一次因为两段都有可能迟到。用户快速把“去年冬天”改成“去年夏天”时旧任务可以继续完成底层 Promise却没有资格写页面。这样 UI 不需要猜哪个结果更新得晚。这里的textSearchImage.search()代表工程内对 Core Vision Kit 的封装具体参数应以当前 SDK 为准。正式项目需要在服务创建和页面退出时成对执行初始化、释放并对相册授权失效单独报错。invalidate()只阻止提交不等于释放底层索引会话二者需要分别处理。也不要在每次输入字符变化时直接搜索至少应在明确提交或稳定停顿后运行。四、二阶段重排要先硬过滤再谈分数我曾把时间匹配做成 20% 的加分项结果一张语义分极高的 2024 年雪景仍能挤进首屏。时间短语既然已经解析成硬约束就不该只是“偏好”。因此二阶段先过滤拍摄时间再在命中集合中结合语义分与时间中心距离重排。当前问题是把 42 个候选收敛为 9 个时间命中并稳定选出 6 个。下面的函数还会排除缺少拍摄时间的资产这些资产进入“时间未知”分组而不是伪造文件修改时间。exportinterfaceMediaFact{uri:stringdateTakenMs?:number}exportfunctionrerank(hits:SemanticHit[],facts:Mapstring,MediaFact,window:TimeWindow):RankedPhoto[]{constcenter(window.startMswindow.endExclusiveMs)/2constradius(window.endExclusiveMs-window.startMs)/2returnhits.flatMap((hit:SemanticHit){consttakenfacts.get(hit.uri)?.dateTakenMsif(takenundefined||takenwindow.startMs||takenwindow.endExclusiveMs){return[]}consttimeScore1-Math.min(1,Math.abs(taken-center)/radius)return[{uri:hit.uri,takenMs:taken,semanticScore:hit.semanticScore,finalScore:hit.semanticScore*0.86timeScore*0.14}]}).sort((a,b)b.finalScore-a.finalScore).slice(0,6)}数据变化很明确42 张语义候选经过时间硬过滤剩 9 张然后按86% 语义 14% 区间中心度排序截取 6 张。中心度不是“越靠近今天越好”而是让同分照片在冬季中段略靠前这个权重属于产品策略日志必须记录版本方便以后解释排序变化。易错点是把文件修改时间当成拍摄时间。用户编辑或迁移图片后修改时间会改变不适合支撑“去年冬天”。对于截图、下载图或元数据被清除的图片本 Demo 不纳入硬时间结果。正式项目可以提供“包含时间未知图片”的开关但要清楚标注不能让兜底破坏查询语义。五、缓存只缓存事实不缓存一次搜索的结论为了降低 80 个 URI 的资产查询开销我给MediaAssetLedger加了小型缓存。第一次实现用 URI 永久缓存拍摄时间后来发现用户编辑照片、替换同 URI 内容后会读到旧事实。现在缓存项包含资产版本与短 TTL相册变更回调会按 URI 失效。当前问题是缓存命中也必须尊重资产版本页面退出时还要释放媒体查询句柄。interfaceFactCacheEntry{fact:MediaFact revision:numberexpiresAt:number}exportclassMediaFactCache{privatevalues:Mapstring,FactCacheEntrynewMap()get(uri:string,revision:number,now:number):MediaFact|undefined{constitemthis.values.get(uri)if(!item||item.revision!revision||item.expiresAtnow)returnundefinedreturnitem.fact}put(uri:string,fact:MediaFact,revision:number,now:number):void{this.values.set(uri,{fact,revision,expiresAt:now5*60*1000})}invalidate(uri:string):void{this.values.delete(uri)}clear():void{this.values.clear()}}缓存只保存媒体事实不保存“去年冬天”的最终 6 张。因为锚点、查询词、排序权重变化后最终结论都可能不同。页面销毁时协调器先invalidate()再注销相册变更监听最后释放搜索服务缓存可以随 ViewModel 清空。若缓存做成进程级服务就要限制容量不能让相册 URI 无限增长。六、DevEco Studio 里我只盯四个数字项目目录按pages/MomentScopePage.ets、model/TimeWindow.ets、service/SearchCoordinator.ets、service/MediaAssetLedger.ets、utils/RelativeTimeParser.ets拆分。页面不负责算日期也不直接访问媒体资产。调试日志固定打印SEARCH-1002-01 anchor2026-10-02、window2025-12-01..2026-03-01、semantic42 timeHit9 final6、State FILTERING - COMPLETED cost286ms。这四组数据能快速判断错在解析、召回、过滤还是渲染。截图中右侧模拟器展示 6 张冬季结果中间代码停在半开区间判断底部 HiLog 与正文完全一致。若只打印“搜索成功”即使结果年份错了日志也不会留下任何证据。七、运行结果与产品边界最终手机页把“去年冬天”解释结果直接展示在搜索框下方2025.12.01—2026.02.28。状态为COMPLETED语义候选 42、时间命中 9、最终结果 6任务 ID 是SEARCH-1002-01。这次修复后搜索结果不再依赖模型是否“理解年份”。但边界仍然要说清时间解析是产品规则不是自然语言的唯一答案拍摄时间可能缺失或被修改跨时区旅行照片还涉及拍摄地时区与当前时区的选择。Moment Scope 当前按设备本地日历解释并把时间未知资产排除在严格结果之外。八、结语文搜图做得越像自然语言入口越不能把所有词都交给一个语义分数。视觉描述适合模型召回时间、地点、相册归属更适合结构化事实约束。把二者拆成两阶段后结果不只“看起来像”还能够解释为什么属于这段时间。工程上真正重要的是三个细节冻结任务锚点、使用半开日历区间、让旧异步结果失去提交权。它们让一句模糊的人话最终变成可测试、可记录、可回放的搜索合同。