作者简介
mczhao，携程高级研发经理，关注自然语言处理技术。
spike，携程高级后端开发专家，关注AI技术。
团队热招岗位：多模态算法工程师（内容理解）、高级/资深算法工程师（内容挖掘）、搜索引擎开发工程师
在AI快速发展的浪潮中，传统的关键词搜索早已难以满足用户日益复杂的需求。尤其在酒店预订领域，如何精准理解“2大1小”“江浙周边遛娃”这类模糊却真实的意图，成了提升用户体验的关键。本文将带您深入探索语义搜索如何颠覆传统检索方式，从实体识别、向量召回到大模型加持的语义理解，全面解析携程在智能搜索上的技术路径与实践经验。读完此文，您将看到一个未来——用户只需自然表达需求，系统便可一步到位，智能推荐最匹配的酒店。这不仅是搜索技术的革新，更是用户体验的革命。
一、背景
二、我们的目标：降低搜筛费力度
三、核心AI能力
3.1. 命名实体识别
3.2. 实体链接
四、总结与展望
一、背景
过去一年，人工智能（AI）搜索技术实现了迅猛的发展，携程也已推出了自研的智能产品，如“问道”、“TripGen”等。这些产品底层均应用了先进的语义搜索能力，以提升垂直领域的信息召回与用户体验。
传统在线酒店预订流程通常以关键词搜索为核心，是用户选择酒店的重要通道之一。如果在酒店搜索流程中进一步融入更智能、更贴合用户意图的语义搜索能力，将极大地改善用户的预订体验，使所有用户都能直观地感受到AI带来的便捷与精准。
传统搜索引擎大多依赖于倒排索引技术，即通过关键词精确匹配的方式来满足用户的基本搜索需求。但随着用户期望与搜索习惯的持续演变，这种单一的关键词匹配方式逐渐暴露出明显不足。
例如，以下用户查询无结果 ：
上海的五星级酒店推荐
上海带室内温泉的酒店
江浙周边适合遛娃的酒店
静安寺1公里以内的酒店
京都当地特色酒店
太湖周边四星以上酒店
上海2大1小适合带娃中高端酒店
上海2大1小11月份3天2晚适合带娃的热门酒店
浙江网红出片的酒店
这些问题的深层原因在于：
首先，倒排索引技术对关键词表达的精确度要求极高，因此用户若未使用标准关键词，搜索结果的相关性便会显著下降。例如系统可以识别“宠物友好”，但难以关联用户搜索的“可以带宠物”意图。
其次，现有搜索引擎在处理词义歧义时能力有限，无法在上下文中灵活判断用户的真实需求。
最后，缺乏深层语义理解能力，使得搜索引擎在处理复杂查询时难以捕捉语言的多样性和细腻性，从而限制了用户体验的提升。
二、我们的目标：降低搜筛费力度
以下以“上海热门泳池酒店”为例，展示用户因缺乏语义搜索功能所面临的繁琐操作：
1）初次查询无结果 ：用户在搜索框中输入“上海热门泳池酒店”，结果为空，找不到符合需求的推荐。
2）尝试调整查询词 ：用户简化查询词，输入“上海泳池”，找到上海包含泳池的全部酒店。
3）尝试到筛选项手动筛选“热门泳池” ：
此时，系统未将“热门泳池”列为热门筛选项，用户需在筛选列表中滑动五个屏幕，才能找到“特色泳池”相关筛选项（而且用户内心未必觉得完全match心中所需）。
最终，用户筛选出上海特色泳池酒店列表，再次进入浏览页面查找心仪的酒店。
这个例子展示了一个看似简单的搜索意图背后的真实用户搜索过程。由于搜索系统缺乏语义理解能力，用户不得不降低搜索的复杂度，从“上海热门泳池酒店”简化到“上海泳池”，再通过筛选项进行自行手动筛选。在没有语义搜索的情况下，用户通过简化搜索词逻辑、扩大搜索召回结果，然后手动进行细粒度筛选来实现搜索目的。这一过程不仅耗时，而且用户体验不佳。此外，用户在搜索过程中可能会因为链路过长而失去耐心和信心，最终导致用户离开应用程序。
1）“上海热门泳池”无法被正确识别
2）只能单独搜索“上海泳池”
3）到筛选项手动筛选“特色泳池”
4）酒店列表页浏览
我们的目标：降低搜索费力度
当用户输入“ 东京2大1小2间房明年2月5入住7天亲子酒店推荐 ”查询时，系统会自动将其中的各要素（如地点、入住人数、日期、房间数量等）与相应筛选条件匹配，直接引导用户至符合条件的酒店列表页面。这样的智能搜索流程极大简化了操作步骤，消除了手动设置筛选条件的繁琐过程。用户不再需要反复调整筛选项，而是能够直接获得高度相关的结果。这不仅显著减少了搜索和筛选的时间与精力消耗，还大幅提升了用户体验，使用户能够更快速、轻松地找到符合特定需求的酒店选项。
用户输入：东京2大1小2间房明年2月5入住7天亲子酒店推荐
列表页自动匹配：
三、核心AI能力
为了实现语义搜索，我们使用了以下先进的AI技术：
实体识别技术： 语义搜索的实现依赖于AI深度学习技术，它能够对用户输入进行实体识别。当用户输入复杂的搜索词时，系统通过深度学习模型自动识别出关键实体（如地点、日期、房间类型等），并准确区分同一词汇在不同上下文中的含义。这使得搜索引擎能够精准理解用户的真实意图，避免因歧义导致的错误结果。
实体链接技术：语义搜索还依赖于强大的实体链接技术，这块主要是依靠向量搜索能力来实现与OTA垂直领域系统的无缝对接。通过将用户的搜索内容与垂直领域信息向量化，系统能够在高维空间中精准匹配用户需求。这种向量搜索不仅突破了传统的关键字匹配限制，还深度理解用户的语义输入，将其需求与OTA系统中的海量信息高效关联，从而提供个性化和高度相关的搜索结果。
3.1. 命名实体识别
在用户搜索时，搜索引擎需要理解搜索词的深层含义，而这种理解依赖于命名实体识别（NER, Named Entity Recognition）技术。NER是自然语言处理（NLP）中的关键技术之一，它能够从文本中识别出特定的实体（如人名、地名、时间、组织等），并对这些实体进行分类。通过NER，搜索引擎能够识别和提取用户搜索词中的关键信息，使搜索结果更加精准和相关。
NER的核心功能
在酒店搜索场景中，NER的核心功能是识别用户查询中的关键信息，以便理解用户的真实需求。例如，当用户输入“江浙周边适合遛娃的酒店”时，NER模块可以识别出“江浙”、“遛娃”和“酒店”三个关键实体：
“江浙” ：被识别为地理位置。
“酒店” ：作为搜索目标。
“遛娃” ：描述所需的酒店属性，即适合带孩子。
同时，NER模块会过滤掉无关的词汇（如“的”、“周边”、“适合”等），从而提升搜索引擎对用户意图的识别精度。这种精准的实体识别能力，使NER成为实现精确搜索和推荐的第一步。
3.1.1. 基于LLM的实现
在设计方案时，我们充分参考了NLU技术的演进历程，从早期的基于规则的方法到统计模型，再到深度学习的应用。这一历程帮助我们清晰认识到各种技术方案的优劣：
基于规则的方法 ：在特定领域和简单场景中表现良好，但高度依赖专家规则，灵活性和扩展性较差，难以适应复杂多样的用户查询。
统计方法 ：在数据驱动任务上有所突破，但在细粒度的语义理解方面，精准度仍然不足。
深度学习方法 ：提高了特定任务的NLU效果，但需要大量标注数据，且跨领域泛化能力有限。
基于以上技术的局限性，我们决定在方案中直接采用千问7B这样的大型语言模型（LLM）。相比传统方法，千问7B具有明显优势，其深层语义理解能力、广泛的知识储备和跨领域的泛化能力特别适合酒店搜索等复杂场景。在设计上，千问7B的高维嵌入和注意力机制能够精准识别复杂查询中的细微语义。例如，当用户输入多条件查询时，千问7B可以快速识别出不同的语义成分（如地点、设施、偏好等），并将这些条件精确映射到相应的酒店特征上。
模型优化
此外，我们利用TensorRT对模型进行加速，通过实施层间融合、张量融合以及在推理过程中采用较低精度的计算，有效地提升了在线推理的性能并减少了内存占用。这些优化措施将在线推理的响应时间从3000毫秒大幅缩短至300毫秒左右，显著提高了实体识别的效率。
3.2. 实体链接
在用户搜索过程中，实体识别模块成功识别出搜索中的关键实体后，接下来需要将这些实体与OTA（在线旅行社）领域的知识图谱进行匹配。这一任务由实体链接模块（Entity Linking）完成。Entity Linking的作用是将用户输入中的实体（如地名、酒店类型、特色服务等）与知识图谱中的对应节点精确关联，使得系统能够召回所有符合条件的酒店。
Entity Linking的核心技术包括实体嵌入（embedding）和向量引擎召回机制。实体嵌入通过将识别出的实体转化为特定的数值向量，使其可以与知识图谱中的节点相匹配。向量引擎则基于这些嵌入向量快速搜索相关内容，从而精准地找到符合用户需求的酒店，确保搜索结果既准确又相关。
3.2.1. 实体嵌入技术
在实体链接任务中，选择合适的嵌入模型 (embedding model) 至关重要，因为模型的性能直接影响实体匹配的准确性和召回效果。经过对比分析，我们评估了多种嵌入模型在多语言和中文环境下的表现，以找到最优方案。
模型选择与部署
在多语言环境下，E5系列模型表现优异，而在中文环境中，BGE系列模型更为出色。由于远程调用大型语言模型（LLM）的响应时间通常超过1秒，难以满足生产环境的实时性需求，因此我们选择了本地部署。通过对比发现，BGE-M3模型在显存占用和响应速度上与E5系列相当，但在召回精度上更符合我们的需求，因此BGE-M3成为首选方案。
性能对比与阈值设置
在模型性能对比中，E5小型模型的相似度分数分布较集中，即使完全不相关的句子，相似度也常高于0.8。因此在E5模型中，设定相似度阈值在0.93可能导致负样本过度召回，而提高到0.94则容易漏掉正样本。
相比之下，BGE-M3模型的分数分布更为离散：对相似句子给出高分，对不相似句子则给出低分，从而便于合理设置阈值。实测数据表明，BGE-M3在低分句子上的相似度确实较低，验证了其良好的区分能力。
结论
最终，我们选择BGE-M3模型作为实体嵌入的最佳方案。BGE-M3不仅在中文环境下表现优异，还有效平衡了召回率和准确性，使其在实际场景中能够精准、高效地支持实体链接任务。
3.2.2. 向量召回机制
在向量召回机制的设计过程中，我们对当前主流的向量数据库方案进行了调研分析，评估维度包括性能表现、系统扩展性以及资源投入等多个方面。结合携程酒店搜索业务的特点与实际需求，我们选择了基于Elasticsearch（ES）的方案，构建向量召回能力，以实现稳定可靠的向量检索与管理。
目前常见的向量数据库解决方案大致可以分为三类：向量索引组件+自建服务、专用向量数据库以及传统数据库+向量索引组件。不同类型的方案在部署方式、系统特性和应用场景上具有各自的优势。如下图所示：
向量索引组件 + 自建服务
此类方案通常基于开源的向量检索库，如 Faiss、SPTag 和 Lucene HNSW。它们具备灵活性强、可控性高等特点，适用于对系统定制化有较高要求的场景。该方式需要搭配自建的数据服务和检索框架，适合具备一定技术能力和运维能力的团队。
专用向量数据库
如 Milvus、Qdrant 和 Proxima 等，专为向量检索场景设计，具备良好的系统性能和一定的可扩展能力。此类产品适合对向量搜索精度和响应效率要求较高的场景，在部分业务中已具备较成熟的使用实践。
传统数据库 + 向量索引组件
典型如 Elasticsearch、PostgreSQL（pgvector）和 RedisSearch。此类方案在保留传统数据库能力的同时，通过集成向量索引功能支持近似向量检索。它们在系统稳定性、生态支持和集成成本方面具备一定优势，适合业务需求相对明确、对系统易用性要求较高的场景。
综合考虑业务稳定性、系统维护成本与平台技术栈的契合度，我们最终选用了 Elasticsearch 作为向量召回机制的核心组件，并结合 HNSW 向量索引构建方案。该方案在携程酒店搜索场景下运行良好，满足了高效召回的性能要求，同时也保障了系统的易维护性与整体成本的可控性。
索引技术与算法选择
为确保高效的向量检索，我们在ES中采用了HNSW算法 (Hierarchical Navigable Small World)。HNSW算法能够在高维空间中实现快速的最近邻搜索，非常适合精确匹配的实体链接任务。对于酒店搜索，向量召回的核心任务是将用户意图与知识图谱中的酒店数据准确对接。
四、总结与展望
通过语义理解技术，搜索引擎正在从传统的被动式信息呈现方式，转型为更加智能、互动的用户体验平台。不再简单地平铺所有内容，而是基于用户需求精准推送相关信息，真正做到“用户需要什么，我们就提供什么”。
主动预测和理解用户的潜在需求，使用户无需费力在屏幕上滚动或筛选大量信息，快速找到所需内容。例如，用户可以通过自然语言输入复杂问题或多维需求，而搜索引擎则会根据语境、个性化偏好以及语义关系进行精准匹配和推荐。这种以用户需求为中心的互动方式，将使得搜索体验更加顺畅、自然。
通过将AI技术深入融入搜索过程，未来的搜索平台将实现从信息提供到全方位服务的跨越，帮助用户在更短时间内完成决策，同时提供更高质量的体验。
【推荐阅读】
“携程技术”公众号
分享，交流，成长
746
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
