1. “AI 无处不在”为什么反而容易失败1.1 背景从“无处不谈 AI”说起过去两年几乎每个技术团队都在讨论同一个问题我们的产品要不要接入 AI管理层希望用 AI 讲出新故事产品经理希望用 AI 提高用户留存研发同学担心不跟就会落后。于是我们看到很多“AI 功能”被快速上线智能客服、智能推荐、AI 文案、AI 绘画、AI 摘要……但一个现实的信号正在出现一旦进入生产环境很多“AI 功能”并没有带来预期中的业务提升。用户点开一次尝鲜之后不再回来运营数据没有明显改善模型预测结果不稳定反而增加了客服投诉为了维护一套 AI 链路团队付出了比传统功能高几倍的运维成本。“把 AI 放到所有地方”正在变成一种新的技术浪漫主义它看起来先进却不等于成功。这句话不是否定 AI而是提醒我们AI 在某个场景真正产生价值需要满足数据、成本、体验、容错等多重条件。如果只把“接入 AI”当成目标最终往往只是给产品增加了一层昂贵的包装。1.2 AI 功能与业务价值的差距一个 AI 功能上线并不等于业务价值产生。这中间隔着一条很长的链路模型是否解决了真实的用户问题结果是否足够稳定能支撑产品承诺用户是否愿意为 AI 结果买单或者改变使用习惯模型出错时产品有没有兜底方案整套系统的维护成本能否被收益覆盖任何一个环节出问题前面的技术投入都可能归零。举个例子某内容社区在产品首页接入 AI 自动摘要希望让用户更快理解长文。技术上模型调用一次只需要几百毫秒摘要质量也能达到“看起来合理”的水平。但上线后发现用户可以接受却不会因为摘要功能而更频繁地访问与此同时摘要偶尔会漏掉关键信息导致用户对文章产生错误预期反而增加了一轮投诉。最终这个功能被回滚到“人工摘要 规则抽取”的混合方案。这不是说自动摘要不能做而是说在该场景中AI 的“可用性”和“必要性”没有同时满足。可用性指技术能不能跑通必要性指业务上是否真的非它不可。两者缺一都不应该草率上线。1.3 “AI 原生”与“AI 装饰”的本质区别我们可以把现有产品中的 AI 分成两种AI 原生AI-NativeAI 能力是产品价值链条里不可替代的一环。例如搜索引擎的语义排序、自动驾驶的感知模块、代码助手的大模型补全。没有 AI核心业务无法成立。AI 装饰AI-DecorationAI 只是给已有产品加了一个“智能”标签。例如普通计算器加一个语音输入、普通笔记软件加一个自动标签。AI 存在但用户感知不到核心价值变化甚至会觉得多余。并不是说“AI 装饰”完全没有价值。有些装饰确实能优化体验比如翻译软件加入 OCR 识别虽然识别不是核心但能让翻译场景更闭环。关键在于如果 AI 装饰不能带来可感知的体验提升或效率提升那它就没有持续存在的理由。区分这两种状态是团队决定是否投入 AI 的第一步。2. 判断该不该用 AI一套可落地的评估框架2.1 先回答四个核心问题在讨论模型、数据和架构之前先回答四个业务问题用户真的需要这个能力吗—— 不是指“用户会不会点一下”而是“用户是否因此愿意多花时间、多付费、或者更愿意推荐产品”。这个问题现在能被规则解决吗—— 如果传统规则已经能覆盖 80% 场景AI 带来的边际收益可能很小。错误成本有多高—— 医疗诊断、金融风控、法律建议等场景AI 的一次错误可能带来巨大损失这类场景必须有强人审和兜底机制。团队有能力长期维护吗—— 模型效果会漂移数据分布会变化新的 badcase 需要不断补充。AI 不是一次上线就结束的功能而是需要持续投入的系统。如果四个问题的答案里前两个偏否定、后两个偏风险那这个功能大概率不适合盲目上 AI。2.2 需求价值评估表可以把评估过程固化成一个表格供团队在需求评审时使用。每一项打 0-5 分最后按总分排序。评估维度分数含义示例说明用户价值5 分代表核心痛点0 分代表可有可无“自动生成周报摘要”对高频周报用户价值高对普通用户价值低频率与时长是否高频使用使用时长是否够长一次点击就结束的功能AI 价值很难沉淀规则可替代性传统算法能否做到接近效果关键词抽取场景正则和 TF-IDF 通常够用数据可得性是否有足够样本是否有标注流程新业务冷启动阶段通常拿不到高质量数据容错成本错误结果给用户和业务带来多大损失审批流自动决策容错低内容标签容错较高维护成本模型迭代、数据回流、badcase 排查工作量外部 API 调用维护成本低自训练模型维护成本高团队可以在需求评审时用这个表格打分低于阈值的需求先不引入 AI而是用规则或人工流程验证需求本身是否成立。2.3 技术可行性快速验证业务判断通过后再进入技术验证阶段。这里推荐一个最小验证流程用少量样本跑通模型能力。可以使用公开大模型的 API或开源模型的本地部署不必一开始就训练自己的模型。定义“成功标准”。比如“摘要准确率达到 90%”“推荐点击率相对提升 5%”。没有指标的验证没有意义。做 1-2 周小流量用户测试。让真实用户试用记录行为数据而不是只看开发人员和 PM 的主观评价。写出验证结论。如果小流量阶段数据没有改善果断中止不要因为“已经投入了”就继续追加。下面用一个脚本示例说明如何把评估表落地成可重复的评分程序方便团队在需求评审时统一口径。# ai_feasibility_check.py # 文件路径tools/ai_feasibility_check.py def evaluate_feature(feature_name: str, dimensions: dict) - dict: 根据评估表对功能需求进行 AI 可行性评分。 :param feature_name: 功能名称 :param dimensions: 各维度得分取值 0-5 max_score len(dimensions) * 5 total_score sum(dimensions.values()) ratio total_score / max_score if ratio 0.7: suggestion 高优先级AI 价值明确可以进入技术验证 elif ratio 0.4: suggestion 中优先级建议先小范围验证并细化评估指标 else: suggestion 低优先级当前不建议引入 AI先用规则/人工方案 return { feature: feature_name, total_score: total_score, ratio: round(ratio, 2), suggestion: suggestion, detail: dimensions, } if __name__ __main__: # 示例某个功能“自动给文章打标签” result evaluate_feature( feature_name自动文章标签, dimensions{ user_value: 3, # 有一定价值但非核心 frequency: 2, # 用户触发频率一般 rule_solvability: 4, # 规则实现已经能覆盖大部分 data_availability: 3, # 有历史数据但没有标签标注 error_tolerance: 3, # 标签错误影响中等 maintenance_cost: 2, # 需要持续维护词表和模型 }, ) print(result[feature], -, result[suggestion])运行结果自动文章标签 - 低优先级当前不建议引入 AI先用规则/人工方案这个例子想说明的是有些功能看起来“可以上 AI”但综合评分后会发现先用规则方案性价比更高。等到规则方案验证了需求积累了标注数据再引入 AI成功率会大得多。3. 从演示到生产AI 功能落地的工程链路3.1 模型能力与产品能力之间的距离演示阶段一个模型能给出“看起来不错”的结果生产阶段问题会立刻变得复杂延迟用户可接受的等待时间通常只有几百毫秒模型推理时间是否达标稳定同一段输入重复调用结果是否一致结果不一致会导致用户困惑。安全模型是否可能输出敏感内容、错误事实或不当建议灰度不同用户群体是否需要不同策略监控线上效果如何跟踪badcase 如何回流这五个问题决定了一个 Demo 能不能变成线上功能。团队在做技术方案时建议把“AI 服务”当作一个独立的工程模块而不是把模型代码直接塞进业务代码里。3.2 评估指标离线指标与在线指标模型好不好不能只看几个测试用例。工程化落地时需要建立两套指标离线指标在测试集上计算的指标用于模型迭代。常见包括准确率、召回率、F1、NDCG 等。在线指标上线后用户实际行为指标用于验证业务价值。常见包括点击率、留存率、转化率、投诉率、平均使用时长。下面是一个简单的离线评估脚本示例用于计算排序模型的命中率和 NDCGK。实际项目中这个脚本会被接入训练流水线每次模型更新后自动运行。# offline_eval.py # 文件路径tools/offline_eval.py import numpy as np def evaluate_ranking(predictions, ground_truth, top_k10): 计算排序模型的 HitRateK 和 NDCGK。 :param predictions: 每个用户预测的物品 ID 列表 :param ground_truth: 每个用户真实关联的物品 ID 列表 :param top_k: 只看前 K 个结果 hit_count 0 ndcg_sum 0.0 for pred_list, true_list in zip(predictions, ground_truth): pred_top_k set(pred_list[:top_k]) if pred_top_k set(true_list): hit_count 1 dcg 0.0 for i, item in enumerate(pred_list[:top_k]): if item in true_list: dcg 1.0 / np.log2(i 2) idcg 0.0 for i in range(min(len(true_list), top_k)): idcg 1.0 / np.log2(i 2) ndcg_sum dcg / idcg if idcg 0 else 0 n len(predictions) return { fhit_rate{top_k}: round(hit_count / n, 4), fndcg{top_k}: round(ndcg_sum / n, 4), } if __name__ __main__: # 模拟数据两个用户的预测结果和真实兴趣 preds [ [a, b, c, d, e, f, g, h, i, j], [b, c, a, f, e, h, g, i, j, k], ] truths [ [a, x, y], [k, m, n], ] print(evaluate_ranking(preds, truths, top_k5))运行结果{hit_rate5: 0.5, ndcg5: 0.3333}这类指标不是用来“证明 AI 成功”的而是用来发现问题的。比如 NDCG 偏低说明排序靠前的位置没有命中的内容用户大概率看不到感兴趣的东西。这时候要去排查是召回问题、排序问题还是数据质量问题。3.3 兜底策略与降级方案任何 AI 系统都不能假设模型永远正确。生产环境必须设计降级方案当模型服务不可用时走传统规则流程或缓存结果。当模型置信度低于阈值时由人工兜底。当输入内容与训练分布差异过大时拒绝生成结果而不是强行输出。下面给出一个 FastAPI 接口示例演示带降级策略的推荐接口。这个示例的核心思想是AI 是主路径但不是唯一路径。# src/main.py # 文件路径server/src/main.py from fastapi import FastAPI from pydantic import BaseModel import random app FastAPI() class RecommendRequest(BaseModel): user_id: str item_id: str class RecommendResponse(BaseModel): item_id: str score: float source: str # ai / fallback def call_ai_model(user_id: str, item_id: str): 实际项目中这里会调用模型服务。 为了演示降级逻辑这里模拟可能失败的情况。 # 模拟模型返回置信度 confidence random.random() if confidence 0.5: return {item_id: item_id, score: confidence, source: ai} return None app.post(/recommend, response_modelRecommendResponse) def recommend(req: RecommendRequest): ai_result call_ai_model(req.user_id, req.item_id) # AI 不可用或置信度低进入降级策略 if ai_result is None or ai_result[score] 0.5: return RecommendResponse( item_idreq.item_id, scorerandom.uniform(0.2, 0.5), # 规则策略给出的保守分数 sourcefallback, ) return RecommendResponse( item_idai_result[item_id], scoreai_result[score], sourceai_result[source], ) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)这个接口的运行逻辑是先请求 AI 模型如果模型没有返回结果或置信度不够就返回规则策略的保守分数并标记来源。下游业务方看到source字段是fallback时可以选择更保守的展示方式比如不放首页推荐位。4. 实战复盘一个“不该上 AI”的功能这一节用一个虚构但非常有代表性的需求来做完整复盘。4.1 需求描述与分析假设产品经理提出在后台管理系统中加入“自动生成库存预警文案”功能根据仓库库存、销售趋势、季节因素生成提醒文案例如“某商品近三日销量下滑 20%当前库存可使用 12 天建议关注补货”。初看这个需求非常适合 AI 生成。但实际上文案格式固定、变量明确、规则清晰用模板加简单计算就能实现。我们按前面的评估框架来分析维度得分分析用户价值5 分对运营确实有帮助频率与时长3 分每天触发一次不算高频规则可替代性5 分模板完全可以实现数据可得性5 分库存与销量数据现成容错成本3 分文案出错可能误导运营维护成本3 分需要持续维护 prompt 和处理模型错误计算综合得分(535533) / 30 0.8看起来是“高优先级”。但这里要注意我们还需要看“规则可替代性”和“维护成本”两个维度的真实含义。规则可替代性已经接近满分说明传统模板能解决 90% 场景这种情况引入 AI 的边际收益很低而且模型不稳定可能带来负收益。4.2 替代方案设计更合理的方案是用模板渲染# inventory_warning.py # 文件路径server/inventory_warning.py from string import Template def build_warning_message(item: dict) - str: 根据库存数据生成预警文案。 :param item: 包含商品名称、销量变化、可用天数等字段 template Template( 【库存预警】$item_name 近 $days 天销量变化 $sales_change% 当前库存可用 $available_days 天建议$action。 ) if item[sales_change] -20: action 关注补货安排 elif item[available_days] 7: action 尽快补货 else: action 持续观察 return template.substitute( item_nameitem[name], daysitem[days], sales_changef{item[sales_change]:.0f}%, available_daysitem[available_days], actionaction, ) if __name__ __main__: demo_item { name: A 类手套, days: 3, sales_change: -23.5, available_days: 12, } print(build_warning_message(demo_item))运行结果【库存预警】A 类手套 近 3 天销量变化 -24%当前库存可用 12 天建议关注补货安排。这个方案的优势是成本极低几乎没有推理开销。结果可预测不会出现模型幻觉。容易测试模板逻辑可以写单元测试。运营人员可以快速修改文案格式。4.3 复盘结论这个功能最终没有使用大模型。复盘时得出的结论是需求本身真实且有价值但并不需要 AI。模板方案已经能达到目标AI 的边际价值接近于零。引入 AI 后还要处理生成不稳定、接口成本、维护 prompt 等问题整体成本大于收益。这个例子告诉我们不要被“AI 能做什么”冲昏头脑而是要先明确“需求到底是什么”。很多需求的核心是信息准确、到达及时、格式清晰这些用规则系统可能做得更好。5. 实战案例一个“应该上 AI”的场景5.1 需求分析与方案设计相对地我们再来看一个真正适合 AI 的场景。假设业务方提出用户输入一段模糊需求希望在商品库中找到最匹配的 3 个商品。例如用户输入“适合送给喜欢跑步的男朋友的生日礼物”系统需要在几千个商品中找出相关内容。这个需求有三个特点输入是自然语言很难用关键词精确匹配。候选商品数量大人工配置规则成本过高。用户需求多样化规则无法穷举。按照评估框架这个场景的数据可得性、规则可替代性、用户价值都比较适合 AI 介入。技术方案上可以采用“文本向量召回 规则精排”的方式第一步将用户输入和商品标题、标签、描述都转换为向量。第二步用向量相似度召回 Top 20 候选。第三步用规则或小模型精排过滤无关商品。第四步返回 Top 3 结果并标记召回过程。5.2 核心代码实现下面用 Python 演示核心流程。实际项目中向量模型可以是本地部署的 embedding 模型也可以通过微服务调用。# semantic_search.py # 文件路径server/semantic_search.py import numpy as np def load_embedding_model(): 真实项目中这里会加载 embedding 模型例如 BGE、M3E 等。 这里用随机向量模拟便于独立运行。 return lambda text: np.random.rand(128) def recall_candidates(query_embedding, item_embeddings, top_k20): 基于向量余弦相似度召回候选商品 scores [] for item_id, emb in item_embeddings.items(): # 余弦相似度 cos_sim np.dot(query_embedding, emb) / ( np.linalg.norm(query_embedding) * np.linalg.norm(emb) 1e-8 ) scores.append((item_id, float(cos_sim))) scores.sort(keylambda x: x[1], reverseTrue) return scores[:top_k] def rerank(query_text, candidates): 精排阶段可以用规则过滤也可以接入精排模型。 这里只做简单的分数过滤演示。 filtered [] for item_id, score in candidates: if score 0.3: continue filtered.append((item_id, score)) return filtered[:3] def search(query_text, item_metadata, item_embeddings, embed_model): 完整搜索流程向量召回 - 精排 - 输出 Top3 query_emb embed_model(query_text) candidates recall_candidates(query_emb, item_embeddings, top_k20) results rerank(query_text, candidates) return [ { item_id: item_id, score: round(score, 4), title: item_metadata[item_id][title], } for item_id, score in results ] if __name__ __main__: embed_model load_embedding_model() items { 101: {title: 男士运动跑鞋, tags: 跑步,运动,男鞋}, 102: {title: 机械键盘, tags: 数码,办公,键盘}, 103: {title: 运动水杯, tags: 运动,水杯,礼物}, 104: {title: 瑜伽垫, tags: 运动,瑜伽,健身}, 105: {title: 领带, tags: 商务,男装,礼物}, } # 真实项目中商品 embedding 需要提前离线计算并持久化 item_embeddings {iid: embed_model(info[title]) for iid, info in items.items()} query 适合送给喜欢跑步的男朋友的生日礼物 results search(query, items, item_embeddings, embed_model) for r in results: print(r)这个示例 AI功能为什么总失败？一套评估框架与落地指南
1. “AI 无处不在”为什么反而容易失败1.1 背景从“无处不谈 AI”说起过去两年几乎每个技术团队都在讨论同一个问题我们的产品要不要接入 AI管理层希望用 AI 讲出新故事产品经理希望用 AI 提高用户留存研发同学担心不跟就会落后。于是我们看到很多“AI 功能”被快速上线智能客服、智能推荐、AI 文案、AI 绘画、AI 摘要……但一个现实的信号正在出现一旦进入生产环境很多“AI 功能”并没有带来预期中的业务提升。用户点开一次尝鲜之后不再回来运营数据没有明显改善模型预测结果不稳定反而增加了客服投诉为了维护一套 AI 链路团队付出了比传统功能高几倍的运维成本。“把 AI 放到所有地方”正在变成一种新的技术浪漫主义它看起来先进却不等于成功。这句话不是否定 AI而是提醒我们AI 在某个场景真正产生价值需要满足数据、成本、体验、容错等多重条件。如果只把“接入 AI”当成目标最终往往只是给产品增加了一层昂贵的包装。1.2 AI 功能与业务价值的差距一个 AI 功能上线并不等于业务价值产生。这中间隔着一条很长的链路模型是否解决了真实的用户问题结果是否足够稳定能支撑产品承诺用户是否愿意为 AI 结果买单或者改变使用习惯模型出错时产品有没有兜底方案整套系统的维护成本能否被收益覆盖任何一个环节出问题前面的技术投入都可能归零。举个例子某内容社区在产品首页接入 AI 自动摘要希望让用户更快理解长文。技术上模型调用一次只需要几百毫秒摘要质量也能达到“看起来合理”的水平。但上线后发现用户可以接受却不会因为摘要功能而更频繁地访问与此同时摘要偶尔会漏掉关键信息导致用户对文章产生错误预期反而增加了一轮投诉。最终这个功能被回滚到“人工摘要 规则抽取”的混合方案。这不是说自动摘要不能做而是说在该场景中AI 的“可用性”和“必要性”没有同时满足。可用性指技术能不能跑通必要性指业务上是否真的非它不可。两者缺一都不应该草率上线。1.3 “AI 原生”与“AI 装饰”的本质区别我们可以把现有产品中的 AI 分成两种AI 原生AI-NativeAI 能力是产品价值链条里不可替代的一环。例如搜索引擎的语义排序、自动驾驶的感知模块、代码助手的大模型补全。没有 AI核心业务无法成立。AI 装饰AI-DecorationAI 只是给已有产品加了一个“智能”标签。例如普通计算器加一个语音输入、普通笔记软件加一个自动标签。AI 存在但用户感知不到核心价值变化甚至会觉得多余。并不是说“AI 装饰”完全没有价值。有些装饰确实能优化体验比如翻译软件加入 OCR 识别虽然识别不是核心但能让翻译场景更闭环。关键在于如果 AI 装饰不能带来可感知的体验提升或效率提升那它就没有持续存在的理由。区分这两种状态是团队决定是否投入 AI 的第一步。2. 判断该不该用 AI一套可落地的评估框架2.1 先回答四个核心问题在讨论模型、数据和架构之前先回答四个业务问题用户真的需要这个能力吗—— 不是指“用户会不会点一下”而是“用户是否因此愿意多花时间、多付费、或者更愿意推荐产品”。这个问题现在能被规则解决吗—— 如果传统规则已经能覆盖 80% 场景AI 带来的边际收益可能很小。错误成本有多高—— 医疗诊断、金融风控、法律建议等场景AI 的一次错误可能带来巨大损失这类场景必须有强人审和兜底机制。团队有能力长期维护吗—— 模型效果会漂移数据分布会变化新的 badcase 需要不断补充。AI 不是一次上线就结束的功能而是需要持续投入的系统。如果四个问题的答案里前两个偏否定、后两个偏风险那这个功能大概率不适合盲目上 AI。2.2 需求价值评估表可以把评估过程固化成一个表格供团队在需求评审时使用。每一项打 0-5 分最后按总分排序。评估维度分数含义示例说明用户价值5 分代表核心痛点0 分代表可有可无“自动生成周报摘要”对高频周报用户价值高对普通用户价值低频率与时长是否高频使用使用时长是否够长一次点击就结束的功能AI 价值很难沉淀规则可替代性传统算法能否做到接近效果关键词抽取场景正则和 TF-IDF 通常够用数据可得性是否有足够样本是否有标注流程新业务冷启动阶段通常拿不到高质量数据容错成本错误结果给用户和业务带来多大损失审批流自动决策容错低内容标签容错较高维护成本模型迭代、数据回流、badcase 排查工作量外部 API 调用维护成本低自训练模型维护成本高团队可以在需求评审时用这个表格打分低于阈值的需求先不引入 AI而是用规则或人工流程验证需求本身是否成立。2.3 技术可行性快速验证业务判断通过后再进入技术验证阶段。这里推荐一个最小验证流程用少量样本跑通模型能力。可以使用公开大模型的 API或开源模型的本地部署不必一开始就训练自己的模型。定义“成功标准”。比如“摘要准确率达到 90%”“推荐点击率相对提升 5%”。没有指标的验证没有意义。做 1-2 周小流量用户测试。让真实用户试用记录行为数据而不是只看开发人员和 PM 的主观评价。写出验证结论。如果小流量阶段数据没有改善果断中止不要因为“已经投入了”就继续追加。下面用一个脚本示例说明如何把评估表落地成可重复的评分程序方便团队在需求评审时统一口径。# ai_feasibility_check.py # 文件路径tools/ai_feasibility_check.py def evaluate_feature(feature_name: str, dimensions: dict) - dict: 根据评估表对功能需求进行 AI 可行性评分。 :param feature_name: 功能名称 :param dimensions: 各维度得分取值 0-5 max_score len(dimensions) * 5 total_score sum(dimensions.values()) ratio total_score / max_score if ratio 0.7: suggestion 高优先级AI 价值明确可以进入技术验证 elif ratio 0.4: suggestion 中优先级建议先小范围验证并细化评估指标 else: suggestion 低优先级当前不建议引入 AI先用规则/人工方案 return { feature: feature_name, total_score: total_score, ratio: round(ratio, 2), suggestion: suggestion, detail: dimensions, } if __name__ __main__: # 示例某个功能“自动给文章打标签” result evaluate_feature( feature_name自动文章标签, dimensions{ user_value: 3, # 有一定价值但非核心 frequency: 2, # 用户触发频率一般 rule_solvability: 4, # 规则实现已经能覆盖大部分 data_availability: 3, # 有历史数据但没有标签标注 error_tolerance: 3, # 标签错误影响中等 maintenance_cost: 2, # 需要持续维护词表和模型 }, ) print(result[feature], -, result[suggestion])运行结果自动文章标签 - 低优先级当前不建议引入 AI先用规则/人工方案这个例子想说明的是有些功能看起来“可以上 AI”但综合评分后会发现先用规则方案性价比更高。等到规则方案验证了需求积累了标注数据再引入 AI成功率会大得多。3. 从演示到生产AI 功能落地的工程链路3.1 模型能力与产品能力之间的距离演示阶段一个模型能给出“看起来不错”的结果生产阶段问题会立刻变得复杂延迟用户可接受的等待时间通常只有几百毫秒模型推理时间是否达标稳定同一段输入重复调用结果是否一致结果不一致会导致用户困惑。安全模型是否可能输出敏感内容、错误事实或不当建议灰度不同用户群体是否需要不同策略监控线上效果如何跟踪badcase 如何回流这五个问题决定了一个 Demo 能不能变成线上功能。团队在做技术方案时建议把“AI 服务”当作一个独立的工程模块而不是把模型代码直接塞进业务代码里。3.2 评估指标离线指标与在线指标模型好不好不能只看几个测试用例。工程化落地时需要建立两套指标离线指标在测试集上计算的指标用于模型迭代。常见包括准确率、召回率、F1、NDCG 等。在线指标上线后用户实际行为指标用于验证业务价值。常见包括点击率、留存率、转化率、投诉率、平均使用时长。下面是一个简单的离线评估脚本示例用于计算排序模型的命中率和 NDCGK。实际项目中这个脚本会被接入训练流水线每次模型更新后自动运行。# offline_eval.py # 文件路径tools/offline_eval.py import numpy as np def evaluate_ranking(predictions, ground_truth, top_k10): 计算排序模型的 HitRateK 和 NDCGK。 :param predictions: 每个用户预测的物品 ID 列表 :param ground_truth: 每个用户真实关联的物品 ID 列表 :param top_k: 只看前 K 个结果 hit_count 0 ndcg_sum 0.0 for pred_list, true_list in zip(predictions, ground_truth): pred_top_k set(pred_list[:top_k]) if pred_top_k set(true_list): hit_count 1 dcg 0.0 for i, item in enumerate(pred_list[:top_k]): if item in true_list: dcg 1.0 / np.log2(i 2) idcg 0.0 for i in range(min(len(true_list), top_k)): idcg 1.0 / np.log2(i 2) ndcg_sum dcg / idcg if idcg 0 else 0 n len(predictions) return { fhit_rate{top_k}: round(hit_count / n, 4), fndcg{top_k}: round(ndcg_sum / n, 4), } if __name__ __main__: # 模拟数据两个用户的预测结果和真实兴趣 preds [ [a, b, c, d, e, f, g, h, i, j], [b, c, a, f, e, h, g, i, j, k], ] truths [ [a, x, y], [k, m, n], ] print(evaluate_ranking(preds, truths, top_k5))运行结果{hit_rate5: 0.5, ndcg5: 0.3333}这类指标不是用来“证明 AI 成功”的而是用来发现问题的。比如 NDCG 偏低说明排序靠前的位置没有命中的内容用户大概率看不到感兴趣的东西。这时候要去排查是召回问题、排序问题还是数据质量问题。3.3 兜底策略与降级方案任何 AI 系统都不能假设模型永远正确。生产环境必须设计降级方案当模型服务不可用时走传统规则流程或缓存结果。当模型置信度低于阈值时由人工兜底。当输入内容与训练分布差异过大时拒绝生成结果而不是强行输出。下面给出一个 FastAPI 接口示例演示带降级策略的推荐接口。这个示例的核心思想是AI 是主路径但不是唯一路径。# src/main.py # 文件路径server/src/main.py from fastapi import FastAPI from pydantic import BaseModel import random app FastAPI() class RecommendRequest(BaseModel): user_id: str item_id: str class RecommendResponse(BaseModel): item_id: str score: float source: str # ai / fallback def call_ai_model(user_id: str, item_id: str): 实际项目中这里会调用模型服务。 为了演示降级逻辑这里模拟可能失败的情况。 # 模拟模型返回置信度 confidence random.random() if confidence 0.5: return {item_id: item_id, score: confidence, source: ai} return None app.post(/recommend, response_modelRecommendResponse) def recommend(req: RecommendRequest): ai_result call_ai_model(req.user_id, req.item_id) # AI 不可用或置信度低进入降级策略 if ai_result is None or ai_result[score] 0.5: return RecommendResponse( item_idreq.item_id, scorerandom.uniform(0.2, 0.5), # 规则策略给出的保守分数 sourcefallback, ) return RecommendResponse( item_idai_result[item_id], scoreai_result[score], sourceai_result[source], ) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)这个接口的运行逻辑是先请求 AI 模型如果模型没有返回结果或置信度不够就返回规则策略的保守分数并标记来源。下游业务方看到source字段是fallback时可以选择更保守的展示方式比如不放首页推荐位。4. 实战复盘一个“不该上 AI”的功能这一节用一个虚构但非常有代表性的需求来做完整复盘。4.1 需求描述与分析假设产品经理提出在后台管理系统中加入“自动生成库存预警文案”功能根据仓库库存、销售趋势、季节因素生成提醒文案例如“某商品近三日销量下滑 20%当前库存可使用 12 天建议关注补货”。初看这个需求非常适合 AI 生成。但实际上文案格式固定、变量明确、规则清晰用模板加简单计算就能实现。我们按前面的评估框架来分析维度得分分析用户价值5 分对运营确实有帮助频率与时长3 分每天触发一次不算高频规则可替代性5 分模板完全可以实现数据可得性5 分库存与销量数据现成容错成本3 分文案出错可能误导运营维护成本3 分需要持续维护 prompt 和处理模型错误计算综合得分(535533) / 30 0.8看起来是“高优先级”。但这里要注意我们还需要看“规则可替代性”和“维护成本”两个维度的真实含义。规则可替代性已经接近满分说明传统模板能解决 90% 场景这种情况引入 AI 的边际收益很低而且模型不稳定可能带来负收益。4.2 替代方案设计更合理的方案是用模板渲染# inventory_warning.py # 文件路径server/inventory_warning.py from string import Template def build_warning_message(item: dict) - str: 根据库存数据生成预警文案。 :param item: 包含商品名称、销量变化、可用天数等字段 template Template( 【库存预警】$item_name 近 $days 天销量变化 $sales_change% 当前库存可用 $available_days 天建议$action。 ) if item[sales_change] -20: action 关注补货安排 elif item[available_days] 7: action 尽快补货 else: action 持续观察 return template.substitute( item_nameitem[name], daysitem[days], sales_changef{item[sales_change]:.0f}%, available_daysitem[available_days], actionaction, ) if __name__ __main__: demo_item { name: A 类手套, days: 3, sales_change: -23.5, available_days: 12, } print(build_warning_message(demo_item))运行结果【库存预警】A 类手套 近 3 天销量变化 -24%当前库存可用 12 天建议关注补货安排。这个方案的优势是成本极低几乎没有推理开销。结果可预测不会出现模型幻觉。容易测试模板逻辑可以写单元测试。运营人员可以快速修改文案格式。4.3 复盘结论这个功能最终没有使用大模型。复盘时得出的结论是需求本身真实且有价值但并不需要 AI。模板方案已经能达到目标AI 的边际价值接近于零。引入 AI 后还要处理生成不稳定、接口成本、维护 prompt 等问题整体成本大于收益。这个例子告诉我们不要被“AI 能做什么”冲昏头脑而是要先明确“需求到底是什么”。很多需求的核心是信息准确、到达及时、格式清晰这些用规则系统可能做得更好。5. 实战案例一个“应该上 AI”的场景5.1 需求分析与方案设计相对地我们再来看一个真正适合 AI 的场景。假设业务方提出用户输入一段模糊需求希望在商品库中找到最匹配的 3 个商品。例如用户输入“适合送给喜欢跑步的男朋友的生日礼物”系统需要在几千个商品中找出相关内容。这个需求有三个特点输入是自然语言很难用关键词精确匹配。候选商品数量大人工配置规则成本过高。用户需求多样化规则无法穷举。按照评估框架这个场景的数据可得性、规则可替代性、用户价值都比较适合 AI 介入。技术方案上可以采用“文本向量召回 规则精排”的方式第一步将用户输入和商品标题、标签、描述都转换为向量。第二步用向量相似度召回 Top 20 候选。第三步用规则或小模型精排过滤无关商品。第四步返回 Top 3 结果并标记召回过程。5.2 核心代码实现下面用 Python 演示核心流程。实际项目中向量模型可以是本地部署的 embedding 模型也可以通过微服务调用。# semantic_search.py # 文件路径server/semantic_search.py import numpy as np def load_embedding_model(): 真实项目中这里会加载 embedding 模型例如 BGE、M3E 等。 这里用随机向量模拟便于独立运行。 return lambda text: np.random.rand(128) def recall_candidates(query_embedding, item_embeddings, top_k20): 基于向量余弦相似度召回候选商品 scores [] for item_id, emb in item_embeddings.items(): # 余弦相似度 cos_sim np.dot(query_embedding, emb) / ( np.linalg.norm(query_embedding) * np.linalg.norm(emb) 1e-8 ) scores.append((item_id, float(cos_sim))) scores.sort(keylambda x: x[1], reverseTrue) return scores[:top_k] def rerank(query_text, candidates): 精排阶段可以用规则过滤也可以接入精排模型。 这里只做简单的分数过滤演示。 filtered [] for item_id, score in candidates: if score 0.3: continue filtered.append((item_id, score)) return filtered[:3] def search(query_text, item_metadata, item_embeddings, embed_model): 完整搜索流程向量召回 - 精排 - 输出 Top3 query_emb embed_model(query_text) candidates recall_candidates(query_emb, item_embeddings, top_k20) results rerank(query_text, candidates) return [ { item_id: item_id, score: round(score, 4), title: item_metadata[item_id][title], } for item_id, score in results ] if __name__ __main__: embed_model load_embedding_model() items { 101: {title: 男士运动跑鞋, tags: 跑步,运动,男鞋}, 102: {title: 机械键盘, tags: 数码,办公,键盘}, 103: {title: 运动水杯, tags: 运动,水杯,礼物}, 104: {title: 瑜伽垫, tags: 运动,瑜伽,健身}, 105: {title: 领带, tags: 商务,男装,礼物}, } # 真实项目中商品 embedding 需要提前离线计算并持久化 item_embeddings {iid: embed_model(info[title]) for iid, info in items.items()} query 适合送给喜欢跑步的男朋友的生日礼物 results search(query, items, item_embeddings, embed_model) for r in results: print(r)这个示例