简介一份以南京市为例应用机器学习技术分析旅游方式偏好的学术论文适合旅游管理、数据挖掘方向的研究者与高校学生用作参考文献或专业指导。该研究将旅游方式界定为团队旅游与自助旅游两类基于人口统计特征与个人价值观设计问卷并采用C4.5 Rule Induction Algorithm进行两次学习建模先用神经网络集成生成虚拟样本再扩充数据集并归纳出可读的决策规则从而建立从游客特征到旅游方式偏好的非线性映射。文档为PDF格式单文件约474KB便于检索与收藏。目前已有125人学习研究结论显示南京市居民偏好集中于团队旅游与自助旅游所得到的决策规则和算法流程对后续同类偏好预测、旅游产品设计及机器学习方法应用均有参考价值。1. 把南京市旅游偏好做成机器学习项目先想清楚预测目标当拿到基于机器学习技术的旅游方式偏好研究——以南京市为例这个题目时大多数人第一反应是找数据集、跑算法。但在我做过的几个偏好类项目里翻车往往不是模型不行而是预测目标没定义清楚。这个题目的本质是用机器学习模型从南京游客的问卷、订单、轨迹或点评数据中学习出什么人在什么场景下更偏好哪种旅游方式。它解决的是文旅场景里最实在的几个决策问题——给游客做行程推荐、给景区做客群定位、给营销活动做人群圈选。适合做这件事的人有两类一类是手里握着南京文旅数据、想把统计分析报告升级成可预测模型的从业者另一类是拿它做机器学习课程设计选题或毕业论文、需要一套能完整落地技术流程的学生。无论哪类人第一步都不是选算法而是把偏好翻译成可训练的标签。2. 数据与特征工程三条数据路线和一组能直接复用的清洗代码旅游偏好研究和常见的点击率预测有个关键区别标签不是现成的。点击率有明确的正负样本而旅游方式偏好通常要自己整理。以南京市为例能走的数据路线主要有三条我一般会根据手里已有的数据源选一条或两条组合。数据路线典型来源能提取的偏好信号主要成本问卷路线景区游客问卷、线上调研主观偏好、出行目的、同行人结构样本量小需要清洗量表行为路线OTA订单、票务系统、酒店预订实际消费内容、频次、客单价特征稀疏冷启动难位置路线POI数据、轨迹数据游览顺序、停留时长、活动半径涉及地理编码噪声大实践里最稳妥的组合是问卷定标签、行为补特征问卷给你真实的主观偏好行为数据给你客观的消费证据。这两者结合模型的预测结果才不至于停留在自说自话。下面我会用一份模拟的南京问卷数据结构来讲清洗流程代码同样适用于你手里真实的数据。2.1 问卷数据清洗把想去哪玩变成可训练的多标签问卷里最常见的题型是您对以下哪些旅游方式感兴趣这类多选题选项包括文化历史、自然风光、都市休闲、亲子娱乐等。原始数据通常是逗号或分号分隔的字符串不能直接进模型。第一步是把这些字符串拆开转成标准的多标签格式。import pandas as pd # 原始问卷pref列存的是文化历史;自然风光这样的分隔字符串 df pd.read_csv(nanjing_survey.csv) df[pref_list] df[pref].apply( lambda x: x.split(;) if isinstance(x, str) else [] ) # 候选偏好集合按南京常见玩法定义别漏掉其他 categories [ 文化历史, 自然风光, 都市休闲, 亲子娱乐, 美食体验, 户外运动 ] # 生成多标签列游客勾选了就在对应列上置1 for cat in categories: df[flabel_{cat}] df[pref_list].apply( lambda x: 1 if cat in x else 0 ) # 如果做单标签分类取第一个勾选项为主标签 df[main_label] df.apply( lambda x: next( (c for c in categories if c in x[pref_list]), 其他 ), axis1 ) print(df[[user_id, pref, main_label] [flabel_{c} for c in categories]].head())这段代码的逻辑分三层先用apply把字符串拆成列表再遍历候选集合生成独立的 0/1 列最后按需求聚合出主标签。转换完成后每一行问卷就变成了一个标准的监督学习样本。参数上需要注意两点。第一categories的顺序会影响主标签的取值如果游客同时勾了文化历史和自然风光next会把排在前面的类目设为主标签。我的习惯是把这个顺序和实际业务优先级对齐而不是随便排列。第二对其他这类兜底类别要单独处理不能让主标签里混入大量未定义值否则后面训练分类器时类别会失衡。清洗完成后建议立刻检查每个label_*列的分布正常情况应该是几类偏好各占 10% 到 30%如果某一类占比超过一半说明问卷设计本身就存在引导性。2.2 特征工程人口属性之外还要加入行程时间特征标签有了接下来是特征。很多初学者在这里只会用性别、年龄、收入这类人口属性结果模型训练出来跟不同城市的通用模型没有区别。旅游偏好的核心变量其实在行程场景里——同样是南京一个周末周边游的游客和一个专程飞来的游客偏好模式截然不同。所以我在做这个项目时会额外构造一组行程特征。import numpy as np # 用已有的出发地和游玩天数构造行程距离与时长特征 df[travel_distance_km] df.apply( lambda r: haversine_distance(r[origin_city], 南京) if r[origin_city] else -1, axis1 ) df[stay_days] df[departure_date] - df[arrival_date] df[stay_days] df[stay_days].apply(lambda x: max(x.days, 1)) # 时间特征周末和非周末的偏好差异很大 df[is_weekend] (df[arrival_date].dt.weekday 5).astype(int) # 同行人特征家庭出行和独行游客选的旅游方式完全不一样 df[has_children] df[companion_type].apply( lambda x: 1 if 儿童 in str(x) else 0 ) # 核弹级特征人均预算 df[budget_per_person] df[total_budget] / df[group_size].clip(lower1) feature_cols [ age, gender, income_level, travel_distance_km, stay_days, is_weekend, has_children, budget_per_person, visit_freq_per_year, source_channel ]这些特征的构造逻辑是围绕游客决策场景展开的。travel_distance_km用出发地与南京的球面距离近似代替交通成本虽然比真实路网距离粗糙但相关性足够stay_days直接反映行程深度深度游和一日游对旅游方式的偏好差异非常显著budget_per_person是客单价信号能区分高端定制和大众观光。需要提醒的是距离计算函数haversine_distance要自己实现用经纬度坐标算球面距离网上有现成的公式。数据里如果出发地字段是缺失的我建议统一填 -1 而不是 0因为 0 在距离特征里有真实含义会让模型误解为同城游客。另外日期字段一定要先pd.to_datetime统一格式否则dt.weekday会直接报错。这些特征之间还藏着一组强交互比如长途多日高预算几乎直接指向深度文化游树模型能自动学交互但如果你转到逻辑回归就要手动构造交叉项。2.3 按游客分组划分数据集别把同一个人切进训练和测试这个坑我踩过而且是在项目中期才发现的。如果一份数据里有同一个游客的多条旅游记录直接train_test_split随机划分就会把同一个人一部分记录放进训练集、另一部分放进测试集。模型在测试集上表现极好但一上线就崩因为模型其实在记忆这个人本身的偏好而不是学到泛化的规律。from sklearn.model_selection import GroupShuffleSplit # 以user_id为分组单位切分数据 gss GroupShuffleSplit(n_splits1, test_size0.2, random_state42) train_idx, test_idx next(gss.split(X, y, groupsdf[user_id])) X_train, X_test X.iloc[train_idx], X.iloc[test_idx] y_train, y_test y.iloc[train_idx], y.iloc[test_idx] # 验证分组正确两个集合的user_id不能有交集 assert set(df[user_id].iloc[train_idx]).isdisjoint(df[user_id].iloc[test_idx])GroupShuffleSplit的作用是保证同一个user_id的所有样本只会出现在训练集或测试集的一侧。最后那个assert是保险丝我每次划分完都会跑一遍。如果你的数据是纯问卷、每人只有一行那就无所谓分组但只要有重复游客这条就是硬规矩。分组划分还会连带影响交叉验证的方式。后面做调参时不能用普通的KFold要用GroupKFold否则你在验证集上看到的精度依然是被污染的。这一点很多机器学习实战教程不会特意强调但在游客偏好这种强个体差异的场景里不按个体分组就是给模型作弊。3. 模型选型与训练从 LightGBM 跑通基线到 K-Means 做分群数据准备妥当后模型选型反而是我比较放心的环节。旅游偏好预测是典型的表格数据多分类任务类别在 5 到 8 个之间特征以分类变量和连续变量混合为主。这类问题的首选不是神经网络而是梯度提升树——样本量几千到几万时LightGBM 和 XGBoost 的稳健性明显好过深度学习。3.1 样本量决定模型路线表格数据优先试树模型我见过很多把旅游偏好建模直接搬 BERT 或 WideDeep 的方案结果数据只有几千行神经网络还没收敛就过拟合了。表格数据的规律是样本量低于 10 万时树模型通常能以更少调参成本拿到更好的结果只有当你拿到百万级订单数据时才值得考虑深度模型。所以在南京这个题目里我的路线很清晰先跑 LightGBM 做基线再用聚类做无监督分群两者互为补充。LightGBM 在这个场景里有三个不可替代的优势。第一原生支持类别特征像source_channel这种渠道字段不需要做独热编码直接传categorical_feature参数就行。第二训练速度快几千行数据几十秒出结果迭代特征时不用干等。第三特征重要性可以直接输出方便向业务方解释哪些变量在驱动偏好判断。3.2 用 LightGBM 跑通第一版偏好预测参数与调优第一版模型不建议一上来就调参先把流程跑通最重要。我习惯用默认参数加少量调整目标是尽快得到一个可评估的性能基准。import lightgbm as lgb from sklearn.model_selection import train_test_split from sklearn.metrics import accuracy_score, f1_score # 特征与标签已经过上一章清洗y是main_label编码后的整数 X df[feature_cols] y df[main_label].astype(category).cat.codes X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, stratifyy, random_state42 ) model lgb.LGBMClassifier( n_estimators500, learning_rate0.05, num_leaves31, max_depth6, min_child_samples20, class_weightbalanced, random_state42, verbose-1 ) model.fit( X_train, y_train, eval_set[(X_test, y_test)], eval_metricmulti_logloss ) y_pred model.predict(X_test) print(acc:, accuracy_score(y_test, y_pred)) print(macro-f1:, f1_score(y_test, y_pred, averagemacro)) # 输出特征重要性确认没有奇怪的字段排在最前 importance pd.Series(model.feature_importances_, indexfeature_cols) print(importance.sort_values(ascendingFalse))这里几个参数说清楚。n_estimators500给足迭代次数靠learning_rate0.05控制步长防止过拟合我一般先固定这两个再谈别的。num_leaves31是 LightGBM 最敏感的参数太大会学过头太小欠拟合31 对应默认配置的合理起点。class_weightbalanced是因为旅游偏好类别天然不平衡比如美食体验类可能只有自然风光类的三分之一不加权重模型会往大类偏。stratifyy是分类问题划分数据集时的重点参数按类别比例抽样——确保训练集和测试集里各类别的占比和全量数据一致。诊断时我优先看macro-f1而不是accuracy因为准确率在大类占比高时很有欺骗性如果自然风光占 40%模型全预测它也有 40% 的准确率但宏平均 F1 能暴露出小类别全被忽略的问题。第一版跑完后调参顺序我会按num_leaves → min_child_samples → feature_fraction → learning_rate走。先用RandomizedSearchCV配合GroupKFold搜一组 200 步的参数再人工微调。不要一上来就跑网格搜索那个时间成本在你反复改特征时是巨大浪费。3.3 用 K-Means 给南京游客分群轮廓系数与聚类数选择监督学习的偏好预测解决给已知偏好的人预测方式的问题但业务方经常还会问南京游客到底能分成几类。这个问题适合用无监督聚类回答。我在实际项目中会用 K-Means 在标准化后的特征上做分群然后把每一群的特征均值拿出来标注人群标签。from sklearn.cluster import KMeans from sklearn.preprocessing import StandardScaler from sklearn.metrics import silhouette_score cluster_features [ age, budget_per_person, travel_distance_km, stay_days, visit_freq_per_year ] X_cluster df[cluster_features].fillna(-1) X_scaled StandardScaler().fit_transform(X_cluster) # 对K3到K6做轮廓系数对比同时记录各簇样本量 for k in range(3, 7): km KMeans(n_clustersk, n_init10, random_state42) labels km.fit_predict(X_scaled) score silhouette_score(X_scaled, labels) print(fK{k}, silhouette{score:.3f}, cluster sizes:, np.bincount(labels))StandardScaler是必须的——budget_per_person量纲是几百到几千stay_days是 1 到 10不清洗就会让预算在距离计算里一票否决其他特征。n_init10是新版 sklearn 推荐的默认值它让 K-Means 从 10 个不同初始中心出发选最优结果避免陷入局部最优。轮廓系数是最常用的选 K 参考但它是玄学不是真理。我在南京项目里遇到的实际情况是 K4 时轮廓系数只有 0.28K5 反而掉到 0.23但结合业务看K5 的分群结果明显更有解释力——多出来的那一组是亲子家庭游特征上has_children1占比极高。所以不要只盯着 silhouette 数值要把聚类结果输出成一张各特征均值表让业务方看到每一组的画像差异是否成立。4. 旅游偏好建模避坑指南五个最常见的翻车点这部分写的是我真实踩过的坑和从其他项目里学来的教训。每一条都按现象、原因、解决三段来写方便你对照排查自己的数据流程。4.1 现象模型 AUC 和 F1 都很高实际推荐却不准我在南京一个景区合作项目里模型在测试集上 macro-F1 做到 0.78业务方高高兴兴上线做推荐结果用户实际到访率没有显著提升。排查后发现采样偏差在作祟——训练数据里 80% 的问卷是在钟山风景区门口发的样本天然偏向喜欢自然风光和历史文化的游客。测试集也来自同一个采样池AUC 当然好看但它并不能代表南京市全域游客的偏好分布。原因本质是样本选择偏差。景区门口发问卷等于把不来这个景区的人全部排除在样本之外模型学到的其实是在钟山景区受访者中谁会选哪种方式。解决方法是回到数据源头用分层抽样重新构造训练集按南京各区的游客到访比例、淡旺季分布分别配额采样至少要保证各主要景区和商圈都有覆盖。条件允许时把线上问卷的投放范围从景区扩大到酒店、高铁站和本地生活 App让样本池更接近真实游客流。4.2 现象问卷里选文化历史的游客实际消费全在美食店铺这是自我报告偏好和真实行为偏好的系统性偏差。游客填问卷时会选择更体面或更符合自我期待的选项但实际掏钱订票、排队吃饭时行为很诚实。终端表现为问卷标签和订单特征高度不匹配模型训练时特征和标签互相矛盾学出来的决策边界一塌糊涂。解决思路有两个方向。第一是标签清洗如果数据里同时有问卷和消费记录用消费行为修正问卷标签比如问卷选了文化历史但连续三条订单都是餐饮类就把主标签改成美食体验。第二是特征加权在训练集里把问卷来源的样本权重降低把行为来源的样本权重提高。我个人的习惯是构建一个标签可信度分数用行为一致率给每条样本打折然后把这个分数作为sample_weight传入 LightGBM 的fit。4.3 现象时间泄漏让模型看到未来验证指标虚高时间泄漏是这类项目里最隐蔽的问题。具体现象是模型对 2023 年的数据预测非常准但上线后对当前游客完全不灵。我的排查经历指向一个字段——是否重游特征里包含了游客完成本次旅行之后的信息或者干脆把训练集和验证集按时间混着切分让模型提前看到了后几个月的热门趋势变化。归类起来是两类错误特征泄漏和切分泄漏。特征泄漏的解法是把所有特征的构造时间对齐到预测时间点之前比如用游客历史上一次南京出行的偏好来预测本次绝不能用本次结束后的评价数据。切分泄漏的解法是改用时间序列切分用 2023 年 1 月到 8 月的数据训练用 9 月到 12 月的数据验证完全按时间顺序来。GroupShuffleSplit 解决的是个体交叉问题时间切分解决的是趋势穿越问题两个都要做。4.4 现象新景区没有历史数据模型直接推荐失败做南京市全域旅游推荐时遇到一个典型问题——新开发的文旅街区比如刚落地的艺术园区没有任何订单数据和用户标签模型遇到这种冷启动样本时只能按平均水平预测推荐结果跟随机差不多。原因是模型依赖历史行为特征而冷启动样本的这些特征全部是缺失值或默认值。解决思路是切换到内容特征的相似性匹配。先把新景区的 POI 数据变成特征集包括景区类型、消费均价、亲子设施、位处哪个区、地铁可达性然后用这些内容特征计算它和已有景区画像的余弦相似度找到最相近的 3 个成熟景区再用这些景区的历史偏好分布做加权平均。比如新街区在艺术展览这个维度上和老门东相似就参考老门东的游客偏好向量来做首轮推荐。这会损失一点精度但至少不是随机瞎猜。4.5 现象偏好类别不平衡模型只会预测周边游我第一次训练南京偏好模型时发现周边游占比超过一半导致模型把所有样本都猜成周边游F1 依然有 0.5 左右。分类器为了最大化整体准确率会主动牺牲小类别的正确率这对业务是毁灭性的——运营方最想触达的恰恰是利润更高的深度游和定制游。解决分三步。第一步在数据层面做类别重采样对文化历史户外运动这类小类别使用过采样对周边游大类欠采样让训练集的类别分布接近均匀。第二步在算法层面加class_weightbalanced让损失函数对小类别的错判施加更高惩罚。第三步在评估层面必须用 macro-F1 或类别加权 F1 替代准确率。如果重采样后依然有小类学不动要进一步检查是不是该类别下的样本特征本身就混乱必要时合并类别比如把户外运动和自然风光合并成户外自然。5. 把模型结论解释给业务方SHAP 值、南京市分区画像与重训节奏模型训练完成不等于项目交付。旅游文旅项目的业务方往往不是算法工程师他们不会因为 LightGBM 跑赢逻辑回归就认可你他们要看到的是为什么给中年人推荐文化深度游为什么雨花台区的游客和建邺区的游客偏好差异这么大。这一章讲怎么把模型结果翻译成业务语言。5.1 SHAP 值定位关键变量别再只给业务方看特征重要性LightGBM 自带feature_importances_但它只告诉你特征被分裂的频率不告诉你特征对预测结果起正作用还是负作用。业务方问预算到底怎么影响偏好的频率图回答不了。这时候上 SHAP 值。import shap # SHAP需要原始特征且对多分类模型要指定class_index explainer shap.TreeExplainer(model) # 注意多分类时shap_values返回列表每个元素对应一个类别 shap_values explainer.shap_values(X_test) # 只看主标签对应的类别 class_names df[main_label].astype(category).cat.categories label_index list(class_names).index(文化历史) shap.summary_plot( shap_values[label_index], X_test, feature_namesfeature_cols, plot_typebar )这段代码里shap_values[label_index]是关键多分类模型的 SHAP 值是一个列表不指定索引就会报错或者画出不可读的图。summary_plot的bar模式给出全局重要性排序如果要看每个特征对文化历史偏好的正负影响方向把plot_type去掉画默认的小提琴图能看到travel_distance_km越大、越倾向于选择文化历史类旅游这个结论直接可以写进业务报告。我给文旅项目做交付时通常会产出一张关键变量与偏好方向的对照表。比如预算越高越倾向文化深度游有儿童同行的游客显著偏向亲子娱乐省外游客更偏好都市休闲内的夫子庙秦淮河一线。这些结论从 SHAP 图里可以直接抓取而且比回归系数更容易向领导解释。5.2 南京市分区画像把预测结果转成地图上看得懂的人群标签业务方最爱看的东西是画像和地图。我在这个项目里会做一件事——把模型预测结果按南京市行政区聚合输出一张各区游客偏好结构表。具体做法是对每个区的游客样本统计模型预测概率的平均值或用多数投票得到该区主流偏好再叠加该区样本的特征均值做交叉解释。区域主流偏好核心特征驱动建议投放内容玄武区文化历史长途、高预算明孝陵深度讲解套餐秦淮区美食体验年轻、短途老门东夜宵路线江宁区亲子娱乐有儿童、周末牛首山亲子票建邺区都市休闲商务出行、快节奏河西 CBD 购物线路这张表的产出流程是写一段分组聚合的 pandas 操作但我建议不要只输出表面概率一定要回看特征均值来印证否则会出现建邺区被预测成亲子娱乐但该区样本里根本没几个带儿童游客这种矛盾画像。聚合后再接地理可视化把主流偏好渲染成南京市分区地图这是项目汇报时最容易打动业务方的交付物。5.3 重训节奏按月重训与按季度重训的取舍偏好模型和搜索推荐模型不同游客的偏好结构不会每个月剧烈变化频繁重训只会引入无关噪声。我的默认节奏是按季度重训主模型按月度只更新特征统计量。理由有三层第一旅游偏好受季节和节假日影响明显——清明、五一、国庆三个高峰期之后偏好分布会发生变化季度重训能自然吸收这些变化第二问卷数据的收集周期本身需要时间第一季度发出去的问卷往往要到季度末才能收齐足够数量数据时间窗决定了重训频率的物理上限第三频繁重训会带来评估成本翻倍每次重训都要重新跑一组时间序列验证这个人力消耗往往被低估。月度更新的特征是那些短期变化快的变量比如景区热度指数、地铁新线路开通带来的可达性变化。我会把这两类更新拆成两个流水线特征流水线每月跑一次模型流水线每季度跑一次中间相差一个月的数据刚好用于验证上一版模型是否需要退役。6. 模型上线前的最小验证方案A/B 测试与回访问卷最后一个落地步骤也是最容易被技术团队跳过的一步——上线验证。很多项目做到模型评估就停了把测试集表现当成最终结论交付给业务方但测试集只是在历史数据上的回放场景稍一变结论可能完全失效。我在南京这类文旅项目里模型上线前会做一个最小成本的真实验证组合规模不大但能回答两个关键问题模型推荐是否真的高于原有做法用户对推荐内容的接受度到底如何。最小方案分两支。第一支是线上 A/B 测试在已有的门票或行程推荐入口把流量按 7:3 分给旧规则和新模型旧规则可以是热门排序或按景区运营方人工推荐新模型输出偏好预测结果。指标看两个就够了推荐内容的点击率或购买转化率以及人均停留时长变化。不要同时改多个变量否则分不清提升来自模型还是新上线的内容素材。测试周期建议不要少于 14 天覆盖至少一个完整周末因为南京这类旅游城市的周中和周末游客结构差异太大只看工作日结果会被严重误导。第二支是回访问卷A/B 测试能告诉你新模型转化率更高但不能告诉你游客觉得推荐对不对。我会在游客完成行程后触发一份三五题的小问卷问三个与模型相关的核心问题推荐内容是否符合预期、本次成行偏好是否与你原本计划一致、哪些因素导致你最终改变了选择。回访数据样本不需要大300 到 500 份即可但每一条都要关联到模型预测的记录便于做预测是否命中真实决策的交叉分析。如果回访问卷里 60% 以上的人认为推荐基本符合预期同时 A/B 测试转化率有 3 个点以上的提升这个模型就可以放心交给业务方长期使用。最后说一个我自己吃过亏的教训在跑这个项目时我先急着优化模型精度把 A/B 测试平台和回访问卷模板推迟了一个月才启动。结果模型调了四版每一版在离线指标上都有提升但上线后用户反馈数据跟不上根本说不清哪一版真正有效。现在我惯用的收尾顺序是先搭好验证链路再回头调模型——验证先行调参就自然有方向。希望这个流程能帮你少走一段我走过的弯路。本文还有配套的精品资源点击获取