从条件匹配到相似检索：同程旅行慧行搜索的火车换乘方案向量化实践

老板要求全部门五个人一小时内出发，从上海出差去北京，公司只能报销二等座，而且晚上九点前必须抵达。但偏偏，一小时内的所有直达高铁全部售罄……这或许是许多京沪线上打工人的常态。

这时候，有经验的，就会直接打开同程旅行。

借助高效的相似方案召回，同程旅行不仅能按照用户的人数、时间、预算、座位约束条件找到最佳的直达线路；也能在直达票售罄的情况下，帮助用户快速找到如：车内换座直达、短换乘时间等替代方案。

与此同时，作为中国领先的旅游平台，同程旅行还可以提供交通票务、住宿预订、景点门票、度假产品及相关增值旅游服务，一站式解决用户出行中的多种需求。

以下就是同程关于如何实现高效出行方案推荐的实践心得。

01 

出行的替代方案，为什么不能只靠规则筛选

用户选中的直达车无票后，系统要解决的并不只是还有哪些方案能走，还需要告诉用户：哪个替代方案的体验更能满足用户原本的多条件约束。

两者对应的是不同的解决方案。

前者可以使用规则，站点是否可达、时间是否有效、是否有余票，都可以通过明确条件筛选。

但“像不像原方案”没有单一标准。一个中转方案可能换了车次和路径，却在出发时间、总时长和价格上都很接近原方案；另一个方案看似差异不大，却可能因为跨站、长时间等待或深夜换乘，明显增加出行成本。

也就是说，替代方案的好坏并不取决于某几条规则是否命中，继续增加规则虽然能覆盖更多情况，但这不仅会导致规则数量迅速膨胀，也很难准确表达用户对出行方案的综合判断。

基于这一判断，同程旅行慧行搜索团队新增了一条相似方案召回链路：以当前直达方案为参照，从海量中转方案中找出整体体验更接近的候选，再交给下游精排和重排，用于补充规则难以覆盖的候选。

首期方案中，实验选择了火车票无票中转详情页。在这个场景中，用户已经选定了一趟具体的直达方案，系统可以直接以它作为查询对象，从两程中转方案中寻找相似方案。相比从模糊的搜索意图出发，这个场景的查询目标更明确，也更适合验证相似召回的效果。

确定验证场景后，方案落地的第一步，就是明确查询方案与候选方案从哪里来，并把海量原始方案整理成可检索的数据集。

02 

第一步：从 12 亿原始方案中构建查询方案集与候选方案集

确定以用户原本选择的直达方案寻找替代方案后，系统能找到的原始中转方案约有 12 亿条，很显然，我们没必要把所有原始数据直接写入向量数据库。

这时候，离线侧会按照检索用途准备两类数据：

查询方案集（内部称 Query 方案集合）：全国范围内符合业务规则的直达方案，离线生成对应的查询向量；

候选方案集（内部称 Total 方案集合）：对约 12 亿条原始中转方案进行质量和合法性过滤后，缩减到约 3 亿条，作为 Milvus 中的检索候选。

接着，离线侧会将两类方案统一整理成模型可消费的结构化表示，为后续向量编码做准备。

03

第二步：用大模型生成基础表征，用用户协同信号校准向量空间

为便于理解，方案向量的生成与校准过程可以概括为两部分：

1、将结构化方案编码为 34 维向量

直达和中转方案，在表达上天然不是同一种结构，那么让它们具备统一的特征结构？

为了统一模型输入，系统会把直达方案展开成“第一程和第二程为同一车次”的两段式表示：例如某趟 A 到 B 的 G1车次，会表示成两段均为 G1，并额外标记“同车次”。（这只是结构对齐，并不意味着实际发生换乘。）

随后，系统会将方案整理成分段文本。其中包含起终点、两段车次类型与车次号，出发、到达和中转时段，以及是否深夜换乘、是否同车次、是否跨站、卧铺时间、价格区间和总运行时长等信息。

接下来，系统会提升站点、时间、价格和时长等体验信息的权重影响后，采用 Qwen2.5-0.5B-Instruct编码为统一的向量表示。然后将向量压缩，Qwen2.5-0.5B-Instruct原始输出为 896 维，经过多层网络可以被压缩为 32 维。

但仅靠通用语义还不够。对火车方案来说，是否跨站、是否深夜换乘会显著改变真实出行体验。为了避免这些业务信号在高维语义中被弱化，系统会将同车次、跨站、异常换乘、深夜换乘四类特征单独编码独立映射为 2 维表示，再与前面的 32 维语义向量拼接并进行 L2 归一化，得到最终的 34 维方案向量。

2、用高协同方案对校准向量空间

两个方案是否可以互相替代，用户行为本身就是很有价值的信号。

为此，慧行搜索进一步统计了同一用户在同一 OD（Origin-Destination，起终点组合）、设定时间窗口内对不同方案的点击与下单行为，并根据方案对被共同点击、共同下单的频次计算协同强度。

其中，协同强度超过阈值的方案，会被构造为正样本，用于表达用户在真实浏览和决策过程中表现出的方案偏好。

正样本外，同一批次中的其他方案默认作为负样本。通过对比学习，模型拉近高协同方案对，推远缺少协同关系的方案。

不过，批内采样也可能产生“假负样本”：行为数据是稀疏的。两个方案即使非常相似，也可能因为没有形成明确的协同行为而被误当成负样本。为减少相反监督，训练时会计算方案向量之间的余弦相似度，过滤超过设定相似度阈值的负样本；负样本不足时，再从批次中补充距离更远的方案。

经过这轮训练，“寻找原方案的替代方案”已经被转化成了一个向量检索问题，可以实现根据用户原本选择的直达方案，从候选库中找出距离它最近的一批中转方案。

04 

第三步：Milvus 如何承载数亿向量的在线检索与每日更新

前面解决了什么样的方案更相似，接下来还要把这种相似性真正用于线上检索。

这里有两个现实问题：一是候选方案每天都在变化，向量数据库必须持续更新；二是线上找的不是单纯向量最相似的方案，而是要在当前可用的方案里找最相似的。

因此，查询方案和候选方案采用了不同的存储方式。查询方案向量会每日同步到 Redis，便于在线链路快速获取；候选方案向量每日写入 Milvus，承担大规模相似候选检索。

在线请求到达时，系统会根据用户选中的直达方案从 Redis 取得对应的查询向量，再由 Milvus 在数亿候选方案中执行 ANN 检索，从而避免请求期间实时计算 Embedding。

离线更新：新 Collection 就绪后切换 Alias

火车方案具有很强的时效性，候选集每天都会变化。当前检索主要依赖以下字段：

（HNSW 构建参数为 M=16、efConstruction=200）

如果直接在正在提供查询的 Collection 上大批量更新数据和重建索引，很容易影响线上检索。

慧行因此采用整库更新的方式：每天凌晨重新生成候选方案及其 34 维向量，写入新的 Milvus Collection。索引和数据准备完成后，再通过 Alias 切换线上指向。

过程中，在线服务始终访问固定别名，新库构建期间仍然由旧库正常提供查询，只有新库完全就绪后才完成切换。

在线召回：融合标量过滤与向量近邻搜索

面向无票替代、详情页相似推荐等出行场景，入口服务会先完成请求识别。它根据用户上下文生成查询向量，同时拼装起终点、发车时间等业务过滤条件，将完整检索请求下发至 Milvus，然后 Milvus再通过 HNSW + COSINE 在符合条件的向量中返回最相似的 Top 候选。

在这个在线召回的过程中中，Milvus 会同时承担标量过滤和向量近邻搜索两项核心工作。

比如，为了防止召回当日已经发车的出行方案，系统会将全天切分为 48 个时间桶，通过标量字段 level 进行标记，字段取值区间为 [0, 47]。针对当日候选集，查询表达式会追加 level >= 当前时间桶 的标量过滤条件，先排除出发时间已经过期的候选方案。

这种标量与向量的混合查询，让硬性业务约束和软性相似度判断可以在同一召回链路中完成：标量条件保证候选可用，向量检索则从中找出整体出行体验最接近的方案。

再之后，召回结果会在随后与原车次、同车方案及其他换乘/无票候选合并，进入精排。精排综合实时余票、价格、总时长和换乘体验打分，并可继续使用 item embedding 作为特征；重排再叠加品类权重和业务规则，最终由前端展示 Top 方案。

而在性能体验上，当前同程线上采用的是 Milvus 2.5.21 集群模式，管理约 3 亿条向量。在数百 QPS 的请求量级下，P95 查询耗时约为 30 ms。

05 

实验复盘：相似召回取得正向收益

相似召回最终要验证的，不是能不能找到向量距离更近的方案，而是这些原本难以通过规则发现的候选，是否真的增加了用户愿意选择的方案。

团队因此进行了线上对照实验。结果显示，相较原有召回链路，加入相似方案召回后，净票和营收两项核心指标均取得正向收益。

这也为我们后续将类似逻辑推广到更多业务，提供了坚实的事实例证。

文章来自于微信公众号 “Zilliz”，作者 “Zilliz”