解读

面试官想验证两点：

1. 你是否理解“小时级更新”在国内真实业务场景下的压力——高峰时段可能一小时涌入百万级新增/变更文档，且内容需立即被召回。
2. 你是否能把“实时”拆解成可落地的工程指标：索引延迟<5 min、召回率下降<1%、QPS 抖动<5%，并给出成本可控的分布式方案。

知识点

1. 增量分区索引：按业务主键做一致性哈希分片，每片独立构建Delta IVF+PQ子索引，避免全局重建。
2. 双缓冲热切换：写侧持续写内存映射文件（MMap）+ RocksDB WAL，读侧通过版本号+原子指针无锁切换，实现零停机刷盘。
3. 分层合并策略：小时级小层（L0）采用HNSW 动态插入保证<30 s可见；天级大层（L1）用GPU 加速 IVF 训练合并，降低写放大至 0.3 倍。
4. CDC 流式链路：基于Flink-CDC监听 MySQL binlog/ES _seq_no，过滤掉业务逻辑删除标记，只推送有效变更到Kafka 压缩主题，保证Exactly-Once。
5. 向量预计算去重：对内容做SimHash64去重，汉明距离≤3即视为重复，跳过索引，节省30% 计算资源。
6. 灰度验证：新索引先接入5% 影子流量，对比召回@100 差异<0.5% 才全量切换，防止模型漂移。

答案

“面对小时级语料更新，我会把链路拆成采、算、存、查四个阶段，每阶段都设 SLA 并做降级预案。

采：利用Flink-CDC直接监听业务库 binlog，把变更事件按主键哈希发到 Kafka 压缩主题，单分区峰值 20 MB/s 仍可保证端到端延迟≤40 s。

算：消费侧用Flink CEP识别同一文档的多次更新，只做最后一次快照的向量化，调用自研 ONNX 轻量化模型（维度 768，INT8 量化），单次批 512 条，GPU P4 延迟 90 ms，CPU 回退方案延迟 400 ms。

存：向量先写内存 HNSW（efConstruction=200，M=32），每累积 10 万条或 5 min 触发一次增量 IVF 训练，生成Delta 分区文件（PQ 编码 64 byte/向量），通过RocksDB WAL持久化；同时把旧分区标记lazy delete，磁盘水位>80% 时启动L1 合并，用GPU 加速聚类把 1 亿向量重新训练成 IVF4096，写放大控制在 0.3 倍。

查：网关层维护版本号+原子指针，查询请求携带业务分片键，路由到最新可读分区；若分区正在合并，自动降级到上一版本+Delta 补偿查询，召回率下降<0.3%。

监控：对索引延迟、CPU/GPU 利用率、Kafka 堆积量设多维度告警，超过阈值自动触发弹性扩容（K8s HPA，GPU 节点 30 s 内拉起）。

通过这套方案，我们在电商商品库实测中把索引更新延迟从 60 min 降到平均 3 min 40 s，P99 延迟 5 min，成本仅增加 18%。

拓展思考

1. 如果业务要求分钟级实时，可把 HNSW 层直接换成基于 CUDA 的 Dynamic IVF，但需解决GPU 显存上限问题；此时可引入CRDT 冲突-free 语义，让多机房同时写同一张分片，跨城延迟<500 ms。
2. 当语料出现概念漂移（如突发热点事件），需联动在线学习把新语义即时注入模型；可设计双塔增量训练：旧塔冻结做召回，新塔用对比学习微调，A/B 测试确认效果后切换，避免灾难性遗忘。