一个人搭建AI旅行推荐系统：从模型到上线的完整复盘

旅行规划这件事，本质上是个信息整合的苦力活。你要打开七八个标签页，比价、看评价、查攻略，最后把碎片信息手动拼成一个决策。Nomova.ai的作者想解决这个问题——不是做另一个OTA平台，而是用AI把推荐逻辑彻底重做一遍。

这个项目的完整技术栈已经开源。作者详细记录了如何从PyTorch模型开发，一路推进到Vertex AI的生产部署。整个系统的核心挑战在于：怎么让机器学习 pipeline 既能快速迭代，又能稳定服务真实用户。

三层架构的切分逻辑

系统被拆成三个独立层：特征处理、模型推理、服务部署。这种切分不是架构洁癖，而是为了解决一个实际问题——数据科学家改特征工程的时候，不能每次都让后端工程师跟着重构API。

特征层负责把原始交互数据（点击、停留时长、筛选条件）转换成结构化信号，包括三类：行为历史、目的地偏好、以及预算/天数等硬性约束。模型层用PyTorch做排序预测，输出个性化推荐列表。部署层则完全托管在Vertex AI上，负责弹性扩缩容和版本管理。

这种设计让实验和生产解耦。作者可以本地训练新模型，验证效果后直接推送到Vertex AI的端点，不影响线上流量。

三个真实踩过的坑

冷启动是新用户的死穴。系统没有历史数据时，需要一套fallback逻辑生成初始推荐。作者的做法是用热门目的地+用户填写的偏好标签做混合排序，而不是直接给全局热门。

个性化与泛化的平衡更难拿捏。模型太贴合用户历史，会陷入"信息茧房"；太追求通用相关性，又变成千篇一律。解决方法是特征选择上的刻意设计——既保留用户长期偏好，也引入目的地本身的流行度信号作为正则项。

生产迁移是最后一个坎。本地开发和云端部署的环境差异，导致模型在Vertex AI上的推理延迟比预期高了40%。最终通过批量预测和缓存策略解决，而不是重写模型结构。

技术选型的取舍

为什么选择Vertex AI而不是自建K8s集群？作者的考量很实际：这个项目是个人副业，没有运维团队。托管服务虽然贵一点，但把"凌晨三点被报警叫醒"的风险转移给了Google。

PyTorch的选择则是因为动态图更适合快速实验。作者提到，早期用静态图框架时，改一个特征输入就要重新编译整个计算图，迭代速度被拖慢。切换到PyTorch后，模型结构的调整成本大幅降低。

整个系统的代码量控制在可维护范围内——核心推荐服务约2000行Python，特征pipeline用Apache Beam实现，基础设施用Terraform管理。没有微服务拆分，没有复杂的服务网格，单体式部署但逻辑分层清晰。

对同类项目的启示

这个案例最值得参考的不是技术深度，而是scope控制。作者明确放弃了实时学习（online learning），选择批量重训的简化方案；放弃了多目标优化，只做单一排序目标；放弃了复杂的用户画像体系，用显式偏好+隐式行为的两层结构。

这些"不做"的决定，让项目从idea到上线控制在三个月内。对于个人开发者或小团队来说，这种克制可能比任何架构技巧都更重要。

项目已开源，包含完整的模型训练脚本、特征定义和Terraform配置。如果你正在搭建类似的推荐系统，这份代码的参考价值在于：它展示了一个"刚好够用"的生产系统长什么样，而不是一个过度设计的demo。