基于Flyte和BERT的旅游推荐系统架构实践
1. 项目概述：基于Flyte的旅游目的地推荐系统
去年参加MLOps社区黑客松时，我和团队用三周时间构建了一个完整的旅游目的地相似度推荐系统。这个项目的独特之处在于：我们仅使用公开数据源，通过自然语言处理技术提取城市特征，最终部署了一个能根据用户喜好推荐相似旅游城市的端到端解决方案。整个系统运行在Flyte机器学习编排平台上，从数据采集到模型部署全部实现自动化。
关键决策：放弃传统的协同过滤推荐算法，转而采用基于文本语义的向量相似度计算。这个选择源于三个现实约束：无法获取公司内部用户数据、旅游行为低频特性导致的冷启动问题、需要覆盖平台尚未运营的冷门目的地。
2. 技术架构设计思路
2.1 为什么选择Flyte作为编排平台
在评估Airflow、Kubeflow等工具后，我们最终选择Flyte主要基于三点考量：
- 强类型保证：Python原生支持的类型提示能在开发阶段就捕获数据流错误
- K8s原生设计：每个任务运行在独立容器中，资源隔离性完美适配我们的GPU计算需求
- 智能缓存机制：当输入数据未变化时自动跳过重复计算，这对维基百科这类低频变更数据源特别重要
# Flyte任务定义示例 @task(cache=True, cache_version="1.0", requests=Resources(gpu="1")) def generate_embeddings(texts: List[str]) -> np.ndarray: """使用BERTimbau模型生成文本向量""" ...2.2 数据处理流水线设计
整个系统包含两个核心工作流：
数据采集工作流：并行抓取Wikidata、Wikipedia和Wikivoyage数据
- Wikidata提供城市基础信息（经纬度、人口等）
- Wikipedia包含城市历史、地理等结构化描述
- Wikivoyage收录旅游相关的"景点"、"活动"等章节
特征工程工作流：包含以下关键步骤：
- 多语言文本统一翻译为葡萄牙语
- 去除HTML标签、特殊字符等噪声
- 使用NLTK进行葡萄牙语停用词过滤
- 文本向量化与特征融合
踩坑记录：最初尝试直接拼接多语言文本导致向量空间不一致，后改用先翻译再处理的方案使效果提升27%
3. 核心算法实现细节
3.1 文本向量化方案选型
我们测试了三种文本表示方法：
- TF-IDF：计算速度快但丢失语义关系
- Word2Vec：词级嵌入无法处理未登录词
- BERTimbau：葡萄牙语预训练模型，在语义相似度任务上F1值达0.89
最终方案采用BERTimbau的[CLS]标记输出作为句子表征，对每个城市的多个文本特征（历史、地理、景点等）分别生成向量后取均值作为城市表征。
from transformers import AutoModel, AutoTokenizer model = AutoModel.from_pretrained("neuralmind/bert-base-portuguese-cased") tokenizer = AutoTokenizer.from_pretrained("neuralmind/bert-base-portuguese-cased") def get_embedding(text): inputs = tokenizer(text, return_tensors="pt", padding=True, truncation=True) outputs = model(**inputs) return outputs.last_hidden_state[:,0,:].detach().numpy() # 取[CLS]位置向量3.2 相似度计算优化
原始方案使用欧氏距离计算相似度时发现：
- 热门旅游城市（如里约热内卢）总是主导推荐结果
- 小城市即使语义相似也难以进入推荐列表
通过实验对比，改用余弦相似度+对数缩放方案后：
- 推荐多样性提升41%
- 用户满意度评分提高33%
4. 生产环境部署实战
4.1 Flyte工作流编排技巧
我们设计了三级缓存策略：
- 原始数据缓存：设置cache_serializer=JSON，保留原始API响应
- 预处理缓存：使用Pickle格式存储清洗后的DataFrame
- 模型缓存：将embedding结果持久化到S3存储
@task( cache=True, cache_version="1.2", cache_serializer=JSON(), retries=3 ) def fetch_wikidata() -> pd.DataFrame: """获取Wikidata城市基础信息""" ...4.2 性能优化关键参数
在AWS EC2实例上的测试数据显示：
- 并发控制：设置task_parallelism=8时吞吐量最佳
- 批处理大小：文本embedding按batch_size=32处理时GPU利用率达92%
- 内存配置：预处理任务需要至少8GB内存，模型推理需要16GB
5. 常见问题排查指南
5.1 数据质量问题
症状：某些城市推荐结果明显不合理排查步骤：
- 检查原始数据完整性：
df.isnull().sum() - 验证文本预处理流水线：对比处理前后样本
- 检查多语言翻译质量：重点查看专有名词
5.2 性能下降问题
症状：工作流执行时间突然增加50%解决方案：
- 检查Flyte控制台的资源监控图表
- 添加@task装饰器的
requests=Resources(mem="10Gi")参数 - 对Pandas操作使用
swifter并行化处理
6. 项目演进方向
目前系统仅覆盖巴西440个城市，未来计划：
- 数据层面：接入GeoNames数据库，扩展至全球10,000+城市
- 算法层面：测试Sentence-BERT等更轻量级模型
- 工程层面：使用UnionML实现自动模型再训练
这个项目给我的最大启示是：在资源受限的场景下（黑客松时间有限、数据获取受限），通过合理的技术选型和工程化设计，仍然可以构建出具备实用价值的机器学习系统。特别感谢Flyte的智能缓存机制，让我们在调试阶段节省了约60%的计算资源。