为什么 embedding 这样设计不是偷懒向量维度绑定 Qdrant collection,如果允许各用户/各厂商混用 embedding 模型,不同维度和语义空间的向量进同一个 collection,匹配直接失效。所以 embedding 锁死在部署级是正确的;真正的坑反而是之前记录过的遗留项——embedding 只在简历上传时生成,没有批量回填任务,意味着将来切换embedding 模型/厂商前必须先做 re-embed backfill,否则旧向量和新向量不兼容。文章目录回填任务Backfill Task解释结合你的场景来理解为什么说这是个坑一个好的设计应该包含“回填任务”Backfill Task解释回填Backfill是数据工程和软件开发中的一个常见术语意思是对历史已有的数据补跑某个新增的处理流程。结合你的场景来理解时间点发生了什么过去系统上线后用户陆续上传简历每份简历在上传时生成 embedding 向量并存入向量数据库现在你想换一个更好的 embedding 模型比如从text-embedding-ada-002换到text-embedding-3-large问题旧简历的向量是用旧模型生成的新简历的向量是用新模型生成的两者维度/语义空间不同无法放在一起做相似度搜索回填任务就是写一个批处理脚本/任务把所有历史简历重新拉出来用新模型重新生成 embedding 向量覆盖掉旧的向量。这个过程就叫re-embed backfill。为什么说这是个坑因为系统没有预先设计好这个批量回填的能力导致没有现成的脚本/任务— 需要临时开发一个批量处理程序遍历所有历史简历重新调用 embedding API数据量大时成本高、耗时长— 如果有几十万份简历重新调用 API 会产生大量费用和时间切换期间存在兼容性问题— 在回填完成之前旧向量和新向量共存搜索质量会下降可能需要双写— 过渡期可能需要同时维护新旧两套向量索引一个好的设计应该包含✅ 一个可触发的批量 re-embed 任务比如一个 Celery task 或 Airflow DAG✅ 支持分批处理避免一次性打爆 API✅ 支持版本管理给向量打上模型版本号方便灰度切换✅ 回填完成前的双索引策略保证搜索不中断一句话总结回填任务就是回头把老数据用新规则重新处理一遍的批处理任务。没有它换模型时就会非常痛苦。