Booking.com 向量数据库迁移揭示的 AI 工程化稳定性挑战

Booking.com 在 RAG 架构中将向量数据库从初步跑通转向工业级稳定时，发现单纯依赖 QPS 或索引速度无法解决极高并发下的延迟抖动。在这种海量旅游数据实时同步且需毫秒级响应的场景中，一致性与可用性的权衡成为核心矛盾。许多产品在处理大规模更新时必须重建索引，这会导致查询性能掉速甚至暂时不可用。单纯升级实例规格或增加内存往往无法解决问题，因为瓶颈实则在磁盘 I/O 调度与内存管理。当数据量级达到千万或亿级，且涉及城市、价格区间等复杂过滤条件的 Hybrid Search 时，多数数据库的效率会明显降低。

选型时需重点考量三个维度：一是 HNSW 索引构建时的资源占用，避免在动态更新时触发 OOM；二是是否具备高效缓存机制以区分冷热数据；三是 API 的生态兼容性，防止封闭 SDK 增加迁移成本。基础设施选型不能只看 Benchmark 跑分，应将可扩展性与运维复杂度置于与检索精度同等的位置。面对 1 亿次稳定查询的需求，应测试数据量增长 10 倍后的延迟曲线，避免初创期的技术债在业务增长时导致性能崩盘。

在用户体验层面，Booking.com 曾于 2019 年被讨论其在电商界面过度使用说服技巧，为此有人开发了旨在减少这类干扰的 Chrome 浏览器扩展。对比 Airbnb 那些基于事实且具告知性的繁忙提示，Booking.com 的部分提示虽能提供房间数量及最后预订时间的有用信息，但部分设计过于强调紧迫感，导致用户产生必须快速下单的压力。这种将信息性转化为高转化率的策略，反映出其在产品工程化中对用户心理驱动的把控。