简介：基于Python的酒庄数据分析推荐系统项目文档，是一份面向具备Python基础、熟悉数据分析与Web开发的研发人员、数据科学家或软件工程师的完整实践范例。项目以酒庄业务为场景，讲解协同过滤与内容过滤相结合的混合推荐策略，覆盖用户-酒款交互矩阵构建、SVD矩阵分解、余弦相似度计算、冷启动规则等算法模块，并串联需求分析、MySQL数据库设计、后端接口（含Flask实现示例）、Tkinter GUI、模型评估与可视化等完整软件工程环节。整个资源打包为1个docx文档，容量仅128KB，以单个Word文件承载项目架构说明与详尽代码示例，便于离线查阅和随文复现；全文章节化组织，从项目背景、目标意义、技术挑战到模型架构与应用领域形成完整闭环。文档还提供了从数据生成、清洗、模型训练到前后端交互的完整示例，以及系统部署、监控与安全考量，能够帮助读者理清从原始数据到最终推荐结果的闭环链路，并迁移至线上商城、会员运营等实际场景。目前已有66人学习，适合作为个人项目实战或团队技术方案参考。
1. 酒庄数据分析推荐系统到底是做什么的：先认清需求和三条边界
一个中等规模的酒庄，一年几千笔订单、几十个SKU，滞销款往往不是酒本身不行，而是没人把它推到合适的客户面前。酒庄数据分析场景下的推荐系统，目标不是做大平台那种“猜你喜欢”，而是把库存里的动销慢酒款，匹配给高概率复购的老客户。基于Python来实现，是因为整条链路可以用一套语言打通：SQLite存数据，Pandas做清洗和特征，Scipy算相似度，PyQt5做界面，不需要引入Spark或Elasticsearch这类重型组件，小团队也能维护。适合谁读这篇笔记？酒庄或酒商的运营人员、用Python做毕业设计的学生，以及想给会员做个性化推荐的零售小团队。动手之前先立三条边界：数据量级在万条以内，推荐对象是注册会员而不是游客，评分和订单能回流进数据库。这三条边界决定了后面所有的表结构设计和算法选型，先把需求定死，才不会把系统做成一个昂贵的玩具。
2. 从业务到表结构：酒庄数据库设计、数据清洗与特征工程落地
2.1 四张核心表的DDL：wines、customers、orders、ratings
酒类推荐系统的数据基础比算法重要，我见过的翻车案例里，一半以上是表结构设计不到位：要么订单表没有酒款ID，要么评分表没有用户ID，算法再好也无从下手。按业务对象拆分，最少需要四张表：酒款、客户、订单、评分。下面这套DDL是SQLite写法，放到Python工程里可以直接执行，建库后所有增删改查都用标准SQL完成。
CREATE TABLE IF NOT EXISTS wines ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, -- 酒款名称，GUI展示用 winery TEXT DEFAULT '', -- 酒庄/酒厂名 vintage INTEGER DEFAULT 0, -- 年份，0表示未知 grape TEXT DEFAULT '', -- 主葡萄品种，如赤霞珠 region TEXT DEFAULT '', -- 产区，如宁夏贺兰山东麓 category TEXT DEFAULT 'red', -- red/white/sparkling/sweet alcohol REAL DEFAULT 0, -- 酒精度 price REAL NOT NULL, -- 当前零售价，用于价格带分层 capacity TEXT DEFAULT '750ml', stock INTEGER DEFAULT 0, created_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE IF NOT EXISTS customers ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, phone TEXT DEFAULT '', level TEXT DEFAULT '普通会员', city TEXT DEFAULT '', registered_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE IF NOT EXISTS orders ( id INTEGER PRIMARY KEY AUTOINCREMENT, customer_id INTEGER NOT NULL, wine_id INTEGER NOT NULL, quantity INTEGER DEFAULT 1, total_price REAL DEFAULT 0, ordered_at TEXT DEFAULT (datetime('now', 'localtime')), FOREIGN KEY (customer_id) REFERENCES customers(id), FOREIGN KEY (wine_id) REFERENCES wines(id) ); CREATE TABLE IF NOT EXISTS ratings ( id INTEGER PRIMARY KEY AUTOINCREMENT, customer_id INTEGER NOT NULL, wine_id INTEGER NOT NULL, rating INTEGER NOT NULL CHECK(rating BETWEEN 1 AND 5), comment TEXT DEFAULT '', created_at TEXT DEFAULT (datetime('now', 'localtime')), UNIQUE(customer_id, wine_id) ); CREATE INDEX IF NOT EXISTS idx_orders_customer ON orders(customer_id); CREATE INDEX IF NOT EXISTS idx_ratings_wine ON ratings(wine_id);建表时有几个细节直接决定后续代码好不好写。wines 表里的 stock 字段必须保留，推荐模块在生成结果之前要过滤掉库存为0的酒款，否则运营第一天就会被客户投诉“推荐了买不到的酒”。ratings 表上的 UNIQUE(customer_id, wine_id) 约束不是可有可无的，它保证一个会员对同一款酒只能有一条评分，第二次评分应该走 UPDATE，否则训练数据里同一对用户和物品出现两条记录，相似度矩阵会被重复计数污染。订单表和评分表是两套数据源，订单代表真实购买行为，评分代表主观偏好，两者在后续特征工程里要分开处理，不能混成一张表。
2.2 用Python把脏数据变成可用特征
数据库建好后第一步不是建模，而是做数据质量检查。常见做法是写一个清洗脚本，每次喂给算法的DataFrame都从清洗函数出口走一遍，避免在训练代码里重复处理异常值。下面这段代码处理三类典型脏数据：空酒款ID、年份异常、单价为0，顺便做订单维度去重。
import sqlite3 import pandas as pd import re def load_clean_data(db_path="winery.db"): conn = sqlite3.connect(db_path) wines = pd.read_sql_query("SELECT * FROM wines", conn) orders = pd.read_sql_query("SELECT * FROM orders", conn) ratings = pd.read_sql_query("SELECT * FROM ratings", conn) conn.close() # 1. 订单表：丢弃酒款或客户缺失的记录 orders.dropna(subset=["wine_id", "customer_id"], inplace=True) # 2. 年份清洗：合理区间是1900到当前年份，其余置0 current_year = pd.Timestamp.now().year wines["vintage"] = wines["vintage"].apply( lambda v: v if re.fullmatch(r"\d{4}", str(v)) and 1900 <= int(v) <= current_year else 0 ) # 3. 价格清洗：价格为0的用同款酒均价填充 avg_price = wines.groupby("winery")["price"].transform("median") wines["price"] = wines["price"].apply( lambda p: p if p and p > 0 else avg_price[wines.index[wines["price"] == p][0]] ) # 4. 订单去重：同客户同酒款同一天同数量，视为重复录入 orders.drop_duplicates( subset=["customer_id", "wine_id", "ordered_at", "quantity"], keep="first", inplace=True ) return wines, orders, ratings清洗脚本里有三个处理思路值得说明。年份清洗用的是正则加数值区间双重校验，因为年份列在数据库里可能被录入成字符串，直接比较大小会出错。价格填充用的是同酒庄的中位数而不是全表均值，同一个酒庄的定价体系更接近，不会出现用大众餐酒价格去填高端系列的情况。订单去重保留第一条记录，因为重复录入通常是同一时间点的重复操作，保留较早那条更符合业务时序。
洗数据时注意SQLite连接的生命周期。上面代码在函数内部打开连接、读完三个表之后立刻关闭，这比一直持有一个全局连接更安全。后台脚本可以接受每次重连，但后面GUI环境里连接管理要单独设计，因为SQLite的线程模型和桌面程序的事件循环有冲突，这个坑在第5章会专门展开。
2.3 特征工程里的三个必做字段：价格带、产区偏好、消费频次
酒庄推荐和图书、视频推荐不同，用户在酒这件事上极度依赖“记忆中的风格”：他上次买的宁夏赤霞珠，下次大概率还会在赤霞珠和附近产区里挑。所以特征工程要围绕可解释字段做，不要一上来就上Embedding。我一般会在用户侧加工出三个字段：价格带、产区和葡萄品种偏好、消费频次，分别对应消费能力、口味惯性和活跃度。
def build_features(wines, orders, ratings): # 酒款侧：价格带分成四档 wines["price_band"] = pd.cut( wines["price"], bins=[0, 150, 400, 800, 99999], labels=["入门", "口粮", "精品", "收藏"] ) # 订单侧：按客户聚合偏好 order_feat = orders.merge( wines[["id", "grape", "region", "price_band"]], left_on="wine_id", right_on="id", how="left" ) user_pref = order_feat.groupby("customer_id").agg( fav_grape=("grape", lambda s: s.mode().iloc[0] if s.mode().size else ""), fav_region=("region", lambda s: s.mode().iloc[0] if s.mode().size else ""), order_cnt=("wine_id", "nunique"), total_spend=("total_price", "sum") ).reset_index() # 用户侧：消费频次分层 user_pref["user_level"] = pd.cut( user_pref["order_cnt"], bins=[0, 2, 6, 20, 9999], labels=["新客", "常客", "熟客", "大客户"] ) return wines, user_pref价格带用pd.cut分箱后，推荐阶段可以直接把“同价格带”作为硬约束或加权因子。酒类消费的阶层感很强，给常喝口粮酒的客户推收藏级酒款，转化率会非常难看。fav_grape和fav_region取的是订单中出现频次最高的值，mode在样本量少时容易返回空值，所以要加size判断。order_cnt用酒款去重数而不是订单行数，因为一次买两箱同一款酒的客户，和回购过三款不同酒的客户，对推荐系统的意义完全不同。
特征工程做完后，可以顺手把清洗和特征构建流程串成一个pipeline函数，输出wines和user_pref两张表。后续推荐引擎读这两张表就够了，不需要每次训练都重新洗一遍原始数据。这也是为了后面GUI设计做准备，推荐接口只需要接收一个客户ID，内部自己查特征，界面层不接触任何Pandas对象。
3. 推荐引擎实现：基于物品协同过滤加混合排序，参数怎么调
3.1 为什么先试基于物品的协同过滤而不是矩阵分解
数据量只有万级、评分稀疏度经常超过97%时，SVD这类矩阵分解模型很容易过拟合，调参成本却很高。基于物品的协同过滤（ItemCF）在酒品这种品类相对稳定的场景有天然优势：酒款之间的关系相对持久，客户的口味变化却很慢，物品相似度矩阵可以隔天甚至隔周更新，而用户向量每次请求实时计算。对比一下，UserCF在客户数少于酒款数的酒庄场景里，活跃用户一旦稍多，近邻集合抖动剧烈，不如ItemCF稳定。
选择ItemCF还有一个运营层面的理由：推荐结果容易解释。给运营或老板看报告时，能说清“这款酒和会员买过的某款酒相似”，比甩出“模型认为概率是0.87”更有说服力。矩阵分解的黑匣子属性在酒庄这种重视会员关系的业务里是减分项。只有当订单数据积累超过十万条，且运营明确要求做实时个性化推送时，才值得引入ALS或双塔模型，那是后话。
3.2 评分矩阵构建与物品相似度计算：稀疏矩阵是底线
显式评分数据通常只有几千条，直接构造稠密矩阵是浪费内存。正确做法是用SciPy的稀疏矩阵，先转成LIL格式追加数据，再转CSR参与运算。CSR格式做矩阵乘法效率高，LIL格式适合逐行写入，两段式构建能省掉一大块临时开销。
import numpy as np from scipy.sparse import lil_matrix, csr_matrix def build_matrices(ratings): # 客户ID和酒款ID映射成连续下标 uid_map = {u: i for i, u in enumerate(sorted(ratings["customer_id"].unique()))} iid_map = {w: j for j, w in enumerate(sorted(ratings["wine_id"].unique()))} n_users, n_items = len(uid_map), len(iid_map) mat = lil_matrix((n_users, n_items), dtype=np.float32) for _, row in ratings.iterrows(): # 评分中心化：减3，让负反馈真正起抑制作用 rating = row["rating"] - 3.0 if rating != 0: mat[uid_map[row["customer_id"]], iid_map[row["wine_id"]]] = rating return mat.tocsr(), uid_map, iid_map def compute_item_similarity(mat, k=20): # 按用户做归一化，消除用户打分尺度的差异 row_norm = np.asarray(mat.sum(axis=1)).ravel() row_norm[row_norm == 0] = 1 normed = mat.multiply(1.0 / row_norm[:, None]) # 物品相似度 = 归一化评分矩阵的转置点乘，得到 item x item 稀疏矩阵 sim = (normed.T @ normed).tocsr() # 每行只保留相似度最高的k个物品，控制后续排序噪声和内存 sim = sim.tolil() for i in range(sim.shape[0]): row = sim.getrowview(i) if row.nnz > k: data = np.asarray(row.data).ravel() order = np.argsort(data)[::-1][:k] keep = np.zeros_like(data, dtype=bool) keep[order] = True row.data = data[keep] if data[keep].size else [] row.rows = [row.rows[0][j] for j in np.where(keep)[0]] return sim.tocsr()这段代码里有两个容易被忽视的细节。一是评分中心化，把1到5分减掉3分，让1到2分变成负反馈，在相似度传播时不会把“都买了一瓶刚才的酒”的弱关联放大；如果直接用原始分数，低分酒和客户真正喜欢的酒会得到同样的正向传播效果。二是物品相似度矩阵的topk截断，k默认20，这个值在几百个SKU的酒庄里够用，如果酒款超过五千个还不想截断，内存占用会快速上涨，而且稀疏矩阵会变得越来越稠密，后面几轮推荐的耗时也会指数增长。
3.3 混合排序：物品相似度之外叠加内容匹配和流行度
纯ItemCF的毛病是只看共同购买关系，不看酒本身。在酒庄场景里，两瓶完全不同风格的酒可能因为同一批客户都买过，被算成高相似度。所以最后一步要做一个混合打分，把内容匹配和流行度作为修正项叠加上去。内容匹配依赖的是第2章构建的产区、葡萄品种和价格带特征。
def blended_recommend(uid, mat, sim, wine_meta, user_pref, top_n=10, alpha=0.6, beta=0.2): u = uid_map.get(uid) if u is None: return [] # 用户已评分的物品集合 u_vec = mat.getrow(u) rated_idx = set(u_vec.indices) scores = {} # 从用户评分过的物品出发，沿相似度传播 for iid_i, r_ui in zip(u_vec.indices, u_vec.data): if abs(r_ui) < 0.5: # 评分接近3分的弱反馈不参与传播 continue sim_row = sim.getrow(iid_i) for iid_j, s_ij in zip(sim_row.indices, sim_row.data): if iid_j in rated_idx: continue scores[iid_j] = scores.get(iid_j, 0) + s_ij * r_ui # 候选池先取前3倍数量，再叠加油田修正，保留排序空间 cand = sorted(scores.items(), key=lambda x: -x[1])[: top_n * 3] if not cand: return [] result = [] for iid_j, s in cand: meta = wine_meta[iid_j] pref = user_pref.get(uid, {}) match = 0.0 if meta.get("grape") and meta["grape"] == pref.get("fav_grape"): match += 1.0 if meta.get("region") and meta["region"] == pref.get("fav_region"): match += 1.0 if meta.get("price_band") and meta["price_band"] == pref.get("price_band"): match += 0.5 pop = np.log1p(meta.get("order_cnt", 1)) final_score = s * alpha + match * (1 - alpha) + pop * beta result.append((iid_j, final_score)) result.sort(key=lambda x: -x[1]) return result[:top_n]三个参数决定了推荐性格。alpha是ItemCF得分权重，默认0.6，追求个性化就调大到0.75，但数据稀疏时调大会让结果退化到单一相似链。beta是流行度补偿，默认0.2，主要给新酒款“作弊”用的，保证没有任何评分的新品也能靠订单量露个脸。match得分上限是2.5，如果某个候选酒款在品种、产区、价格带三个维度全匹配，它会被强行拉进Top10，这也是解决冷启动问题最朴素的兜底方案。
候选集先取3倍再修正，是因为传播得分容易集中在少数热门物品上，直接截断Top10会让修正项几乎没有作用空间。取3倍后，内容匹配的强信号才有机会把某款被相似度低估但特征完全吻合的酒顶上去。这个做法不是为了刷指标，是为了让运营在结果里看到“合理的意外”，而不是永远只有永远卖得最好的那几款。
4. GUI设计落地：用PyQt5把推荐系统做成能用的桌面工具
4.1 界面框架选型：PyQt5还是Tkinter
如果只做一个能跑的演示程序，Tkinter够用，但酒庄的实际使用场景里需要展示酒款表格、评分按钮、推荐理由、销量趋势图，还要让店员能快速操作，Tkinter的控件风格和表格能力都偏弱。PyQt5的QTableView、QChart、信号槽机制更适合做这种带数据交互的桌面工具。很多入门者看到Python数据分析与可视化，就想着上ECharts做网页，但对内使用的工具，桌面程序反而更省事，不需要部署Web服务，一台收银机就能跑。
PyQt5另一个优势是线程模型完整。数据库查询放到QThread里跑，界面主线程不会被SQLite的读写阻塞，这在门店场景里很关键，店员点了“刷新推荐”界面卡死三秒，第一反应就是关掉程序重开。Tkinter虽然也能用threading，但线程间通信要手动加队列，代码结构容易乱。
4.2 主界面与推荐展示区的核心代码
界面结构按使用频率划分，左侧放客户列表，中间是推荐结果表格，右侧是当前选中酒款的信息面板和评分按钮。推荐结果表格的每一行都要带“推荐理由”列，把算法打分翻译成“因为你偏好赤霞珠，推荐同品种酒款”这样的人话。下面这段代码展示最核心的异步查询和界面更新骨架。
from PyQt5.QtCore import QThread, pyqtSignal from PyQt5.QtWidgets import QMainWindow, QTableView, QPushButton, QVBoxLayout, QWidget class RecommendWorker(QThread): result_ready = pyqtSignal(list) def __init__(self, db_path, customer_id, parent=None): super().__init__(parent) self.db_path = db_path self.customer_id = customer_id def run(self): # 这里调用统一推荐入口，内部会连接数据库、查特征、算相似度 recs = get_recommendations(self.db_path, self.customer_id) self.result_ready.emit(recs) class MainWindow(QMainWindow): def __init__(self, db_path): super().__init__() self.db_path = db_path self.worker = None self.rec_table = QTableView() refresh_btn = QPushButton("刷新推荐") refresh_btn.clicked.connect(self.refresh_recommendations) layout = QVBoxLayout() layout.addWidget(refresh_btn) layout.addWidget(self.rec_table) container = QWidget() container.setLayout(layout) self.setCentralWidget(container) def refresh_recommendations(self): customer_id = self.current_customer_id() if customer_id is None: return # 每次刷新先清掉旧任务，避免快速点击导致并发信号 if self.worker and self.worker.isRunning(): self.worker.terminate() self.worker.wait() self.worker = RecommendWorker(self.db_path, customer_id) self.worker.result_ready.connect(self.render_recommendations) self.worker.start() def render_recommendations(self, recs): # 把推荐记录填充到QTableView的model里，省略model封装 pass这里有两个很重要的工程习惯。第一，刷新按钮每次点击前，先检查旧worker是否还在运行，如果在运行就终止并等待退出，否则用户快速点两下按钮，两个线程同时读SQLite，虽然SQLite能扛，但界面会同时触发两次表格刷新，视觉上像弹跳。第二，所有数据库读取都放在RecommendWorker.run里，MainWindow里不出现任何sqlite3调用，这样后面如果要换MySQL或加缓存层，只需要改worker内部实现。
推荐结果表格的列设计我一般会这样定：第1列酒款名称，第2列价格，第3列库存，第4列推荐理由，第5列一个“打分”按钮。打分按钮弹出一个1到5分的对话框，提交后往ratings表里写数据，并用UPDATE ON CONFLICT处理重复评分。这样推荐系统就有了反馈闭环，店员每次给客户推荐完，顺手录一个评分，数据会越滚越厚，算法效果会随使用时长自然变好。
4.3 部署配置与依赖清单：Python版本、数据库文件和GUI三件套
给酒庄交付时，最怕的是对方机器上没有Python环境。常见做法是要求目标机器安装Python 3.10或3.11版本，然后把依赖写进requirements.txt，用pip一次性装完。如果对方不会装环境，可以先用PyInstaller打包成文件夹版交付，但打包时会遇到PyQt5资源文件路径问题，后面会讲。
pip install pandas scipy pyqt5 pyinstaller这是最小依赖集合。pandas负责清洗和特征，scipy负责稀疏矩阵运算，pyqt5负责界面，pyinstaller只用于最终打包。不建议在这个项目里引入numpy单独装，因为scipy和pandas都依赖它，pip会自动带上。如果觉得SQLite不够正式，想换MySQL，需要自己处理连接池和同步问题，还要在目标机器上装MySQL服务端，复杂度会明显上升。对于单机酒庄场景，SQLite的零配置优势更大，数据库就一个winery.db文件，备份就是复制文件，运维成本几乎为零。
打包时要注意数据库文件的路径问题。开发环境里winery.db和脚本放在同一目录，但用PyInstaller打包后程序会解压到临时目录，直接用相对路径很可能找不到数据库。靠谱做法是把数据库路径做成配置文件，打包后允许用户把winery.db放在程序目录里，启动时先检查存在性，不存在就自动建库并导入初始种子数据。
5. 推荐系统避坑与排查：五个最常见的翻车现场和修复方法
5.1 跑出来的推荐结果几乎等于热门榜
现象：不管换哪个会员，Top10里永远都是销量最高的那几款酒，个性化效果约等于零。原因：评分矩阵稀疏度太高，ItemCF的相似度传播在冷门物品上没有足够路径，最终排在前面的一定是获得传播次数最多的热门物品。解决：第一，把评分中心化，让1到2分变成负反馈；第二，把物品相似度做topk截断，阻断热门物品无限传播；第三，调高内容匹配项在混合打分里的权重，让产区、品种、价格带的强匹配把冷门但合适的酒顶上来。还有一个更简单的验证方法，看推荐列表里是否出现非热门酒款，如果完全没有，说明传播路径设计有问题，而不是算法参数问题。
5.2 SQLite写入把GUI卡死
现象：点完打分按钮，界面停顿两三秒才恢复。原因：评分写入直接在GUI主线程里执行，SQLite磁盘写入期间阻塞了事件循环，界面看起来就像死了。解决：写入操作不要在QThread之外执行，评分按钮点击后启动一个短任务线程，线程里单独建立一个只写连接，连接参数加上WAL模式。SQLite默认的rollback journal在并发读写时会锁整个库文件，打开WAL模式后读写可以并行，明显降低卡顿概率。如果打分动作频繁，还可以把实时写入改成先攒在内存队列里，每30秒批量落一次盘，但要注意程序退出前必须flush队列，不然会丢评分。
5.3 数据太少导致相似度矩阵全是同一瓶酒
现象：训练集只有几十条评分，相似度矩阵非零元素几乎都落在某款爆款酒上。原因：评分数据不够，所有共同购买关系都围绕着同一款走量酒展开，其他酒款之间没有共现关系。解决：别急着升级算法，先去增加数据源。把orders表转成隐式反馈，每购买一次算一次加权评分，购买频次高就当作强偏好，这样能快速把有效评分从几百条扩到几千条。酒庄场景里，订单数据通常比评分数据多十倍以上，合理利用隐式反馈是性价比最高的破局方式。如果订单也不够，就不要做协同过滤了，老老实实走规则推荐，同产区、同品种、同价格带三优先，等数据攒够了再切算法。
5.4 中文乱码和编码不一致
现象：GUI里酒款名称显示成一堆问号，或者导出报表时CSV文件用Excel打开是乱码。原因：脚本文件本身不是UTF-8编码，或者数据库里保存的字符串带上了历史遗留的其他编码。解决：第一，所有Python源码文件开头统一用UTF-8保存，PyQt5内部字符串本身就是Unicode，只要输入不是乱码，显示基本不会有问题；第二，导出CSV时用utf-8-sig编码而不是utf-8，Excel对无BOM的UTF-8识别一直有问题；第三，从旧系统迁移数据时，先做一次编码探测，最常见的坑是GBK和UTF-8混存，清洗脚本里把字节串先decode成统一编码再入库。这个坑不解决，后面做任何数据汇报都会被反复拿出来说。
5.5 新酒款永远进不了推荐结果
现象：上架一款新酒，一个月后推荐列表里还是看不到它。原因：新酒没有评分、没有历史订单，在物品相似度矩阵里没有任何传播路径。解决：建一个冷启动酒款表，把上架时间在30天内的酒单独打上“新品”标记，推荐时预留两个固定位给同价格带的新品。同时利用内容匹配规则，把新品和相似老酒做一次虚拟关联，老酒的评分可以按一定折扣映射给同产区同品种的新品，让新酒也能参与相似度传播。这种方式是运营最买账的，因为新品往往是酒庄当季主推，如果推荐系统永远推旧款，运营很快就会弃用整个系统。
6. 让推荐结果真的被运营采用：离线评估、解释性推荐与一份交付习惯
6.1 离线评测两个指标：MAP与覆盖率，先跑通再上线
很多人把推荐系统上线当终点，其实在酒庄这种小数据场景里，上线前的离线评测最重要。切分数据时不要随机切，应该按每个客户的时间顺序切，前80%做训练，后20%做验证，这样才能模拟“过去预测未来”的真实使用方式。两个指标足够：MAP用来衡量推荐列表里相关物品排得够不够靠前，覆盖率用来衡量推荐结果覆盖了多少酒款SKU。覆盖率低就说明系统永远在推爆款，对清库存没有帮助，这是运营最反感的。跑完评测后把两个指标连同推荐样例一起做成一张固定格式的表格，每次调参后都更新，形成可复盘的记录。
6.2 给推荐结果加一句人话：解释性推荐
在GUI和给运营的报表里，推荐理由字段会直接决定系统能不能被用起来。算法内部的计算逻辑是“您购买的A与B相似度0.87”，但运营需要看到的是“这款酒和您上月购买的宁夏赤霞珠来自同一产区，口感结构接近”。做解释的方式很简单，推荐结果计算完以后，从命中项里找出得分贡献最大的那个源头物品，再把源头酒款的特征和候选酒款的特征拼成人话。这个字段在GUI里要放在酒款名称旁边，字号稍微放大一点，比放一堆算法分数有用得多。
我养成了一个交付习惯：每次给酒庄部署完推荐系统，都要连续盯三天的推荐结果，挑出至少十瓶酒人工尝一下名副其实，再对照推荐理由和客户的历史订单检查是否合理。因为算法指标再漂亮，也替代不了人对酒这个品类的味觉判断。一旦发现系统把浓郁的西拉推荐给只买轻酒体白的客户，问题十有八九出在特征字段映射上，而不是算法本身。这个检查过程要在交付文档里写清楚，让运营知道后续数据积累后同样需要人工抽查。推荐系统不是装完就能甩手的黑匣子，数据回流和人工校准要长期做。希望这个从数据库到GUI的完整方案，能帮你在自己的酒庄或项目里少踩几个我踩过的坑，把系统真正用起来。
本文还有配套的精品资源，点击获取
