LLM驱动的产品发现：语义意图解析与混合架构落地实践

1. 项目概述：当大模型真正开始“懂”用户要买什么

“LLM-Powered Product Discovery: A Leap Beyond Hybrid Search”——这个标题里藏着过去三年电商、内容平台和SaaS产品团队最真实的焦虑与期待。我从2021年起就在一家跨境DTC品牌做搜索与推荐系统迭代，亲眼看着团队把Elasticsearch+BM25+向量召回的“混合搜索”方案从0搭到日均调用2300万次，也亲历了它在Q4大促期间被用户一句“我想找适合油痘肌、不闷痘、夏天用着凉凉的防晒，最好带点润色效果”直接卡死的尴尬现场。混合搜索不是不好，它像一位训练有素但只会查字典的导购员：能精准匹配“油痘肌”“防晒”“SPF50+”，却无法理解“凉凉的”是触觉隐喻，“带点润色”意味着微遮瑕而非粉底级覆盖，“夏天用着”暗含质地轻薄与抗汗需求。而LLM驱动的产品发现，本质不是换了个模型跑得更快，而是让系统第一次具备了语义意图解构—需求图谱映射—多维约束协同生成的完整认知链路。它不回答“有没有某款产品”，而是先确认“你真正想解决什么问题”，再反向推导出可能满足该问题的所有产品形态组合。这背后涉及的不是简单的RAG或微调，而是对商品知识结构、用户表达歧义性、商业转化漏斗的三重深度耦合。如果你正在负责搜索体验优化、个性化推荐策略，或是为B端客户设计智能选品工具，这篇内容就是你跳过概念炒作、直击落地难点的实操手记。它不讲LLM有多强大，只说清楚：在哪一步必须用LLM替代传统模块，在哪一步必须给LLM“戴紧箍咒”，以及为什么我们最终放弃端到端生成、选择“LLM做决策中枢+传统引擎做执行单元”的混合架构。

2. 整体架构设计：为什么必须放弃“端到端LLM生成结果”的幻觉

2.1 混合搜索的瓶颈不是算力，而是语义鸿沟

混合搜索（Hybrid Search）在2020年代初成为行业标配，核心逻辑是“分而治之”：BM25处理关键词匹配，向量检索捕捉语义相似，再用学习排序（Learning to Rank）模型加权融合。这套方案在结构化强、用户query短且明确的场景下表现极稳——比如“iPhone 15 Pro 256GB 银色”。但真实世界中，73%的电商搜索query超过5个词，且包含大量非标表达。我们内部日志分析显示，当query长度≥7词时，混合搜索的首屏点击率下降41%，而其中68%的失败case并非因为没召回相关商品，而是因为召回结果与用户真实意图错位。典型如用户搜“送爸爸的生日礼物 50岁 实用不浮夸”，混合搜索会高亮召回“剃须刀”“保温杯”“钢笔”，但实际用户点击TOP3是“颈椎按摩仪”“定制皮带”“茶具套装”——这些商品在传统特征工程中缺乏“送礼”“50岁”“不浮夸”的显式标签，其关联性只能通过长尾行为序列和跨品类共现挖掘。混合搜索的底层缺陷在于：它把query当作静态字符串处理，而忽略了query是用户未完成思考的“半成品草稿”。它无法识别“实用不浮夸”是对“50岁”人群的价值判断投射，也无法将“生日礼物”自动拆解为“情感价值>功能价值”“预算区间隐含在品类选择中”等隐性约束。

2.2 LLM不是万能解药：三个必须正视的硬约束

很多团队一上来就想用LLM直接生成商品列表，结果在POC阶段就陷入泥潭。我参与过4个类似项目，踩坑后总结出三个不可绕过的硬约束：

1. 实时性约束：LLM生成式响应（尤其是长上下文）P95延迟普遍在800ms以上，而电商搜索黄金响应阈值是300ms。用户等待超400ms，跳出率提升22%（我们AB测试数据）。这意味着LLM不能作为主链路响应生成器，而必须退居为“决策加速器”。

2. 可解释性约束：当用户看到“为您推荐这3款防晒”时，运营需要知道为什么是这3款而非其他。纯LLM生成的结果无法提供可审计的归因路径（如“因query中‘凉凉’触发‘清凉感’属性权重+35%，‘油痘肌’触发‘无致痘成分’过滤”）。缺乏归因=无法优化=业务方拒绝上线。

3. 商业规则硬边界：平台有强制规则——如“新客首单仅展示自营商品”“特定类目禁止向未成年人推荐”。这些规则必须100%生效，而LLM的黑盒特性使其无法保证规则绝对不被绕过。我们曾用微调LLM尝试嵌入规则，结果在压力测试中发现0.7%的请求会忽略“自营”限制，原因竟是模型将“自营”误判为“自用”语义。

2.3 我们最终采用的三层架构：LLM做“大脑”，传统引擎做“手脚”

基于上述约束，我们放弃了LLM端到端生成的激进路线，构建了“决策-执行-校验”三层架构：

• 第一层：LLM决策中枢（Decision Layer）
  输入原始query，输出结构化意图指令。关键设计是指令格式强约束：LLM只被允许输出JSON，且Schema由我们严格定义。例如：

  { "intent_type": "multi_constraint_search", "primary_entity": "sunscreen", "constraints": [ {"attribute": "skin_type", "value": "oily_acne", "weight": 0.9}, {"attribute": "sensation", "value": "cooling", "weight": 0.7}, {"attribute": "finish", "value": "matte", "weight": 0.8} ], "business_rules": ["only_self_brand", "exclude_under_18"] }

  这个JSON不是最终结果，而是给下层引擎的“作战指令”。LLM在此层不接触商品库，只做语义解析与约束提炼。

• 第二层：增强型检索引擎（Execution Layer）
  接收上层JSON指令，调用优化后的混合搜索。关键升级在于：

  • 将LLM提取的constraints动态注入Elasticsearch的function_score查询，替代人工配置的固定权重；
  • business_rules直接转换为filter clause，确保100%生效；
  • 对primary_entity进行同义词扩展（如“防晒”→“防晒霜”“防晒乳”“SPF50+”），但扩展词库由运营维护，避免LLM自由发挥。

• 第三层：结果校验与重排（Verification Layer）
  对引擎返回的Top 50结果，用轻量级分类模型（BERT-base微调）做二次校验：

  • 检查是否真满足skin_type=oily_acne（通过商品详情页文本+用户评论NLP分析）；
  • 验证cooling感知是否真实（抓取“清凉”“冰感”“薄荷”等评论关键词密度）；
  • 对不满足任一高权重约束（weight≥0.8）的商品直接剔除。
    最终将校验通过的商品按LLM指令中的weight加权重排。

这个架构让LLM的不可控性被关进“笼子”，同时释放其最强能力——理解人类语言的模糊性与意图层次。上线后，长尾query（≥7词）首屏点击率提升58%，且所有结果均可追溯至具体约束条款，运营同学第一次能指着后台说：“这个排序是因为‘cooling’权重设高了，我们调低0.1试试”。

3. 核心细节实现：从Query解析到结果落地的全链路拆解

3.1 Query解析：如何让LLM稳定输出结构化指令

LLM解析query的稳定性是整个系统的命门。我们试过Prompt Engineering、LoRA微调、甚至用Llama-3-70B做zero-shot，最终选择Prompt Engineering + 小模型蒸馏 + 规则兜底的组合方案，原因很实在：成本、可控性、迭代速度。

• Prompt设计遵循“三明治原则”：
  底层（约束）：明确指定输出必须为JSON，且只允许intent_type/constraints等字段，禁止新增字段；
  中层（示例）：提供3个强对比案例，尤其突出易混淆场景。例如：

  用户问：“适合夏天穿的连衣裙，要显瘦，颜色不要太艳”
  ✅ 正确解析：{"primary_entity":"dress","constraints":[{"attribute":"season","value":"summer"},{"attribute":"fit","value":"slimming"},{"attribute":"color_tone","value":"muted"}]}
  ❌ 错误解析：{"primary_entity":"dress","constraints":[{"attribute":"weather","value":"hot"}]}// “夏天”≠“hot”，是使用场景

  顶层（角色设定）：赋予LLM明确角色——“资深电商选品顾问，专注将用户口语化需求转化为可执行采购指令”。

• 小模型蒸馏解决延迟痛点：
  我们用Qwen2-1.5B在自有query数据集上做监督微调（SFT），目标不是追求100%准确，而是将95%的常规query解析延迟压到120ms内。对于剩余5%的复杂query（如含否定词、多条件嵌套），再fallback到Qwen2-7B。实测下来，92%的请求走小模型，整体P95延迟降至210ms，满足搜索黄金阈值。

• 规则兜底防崩盘：
  当LLM输出非JSON、字段缺失、或weight值超出[0,1]范围时，触发规则引擎：

  • 自动补全缺失constraints（从query中提取名词短语，用TF-IDF匹配商品属性库）；
  • 将非法weight强制截断至[0.3,0.9]区间（经AB测试，低于0.3的约束对排序影响可忽略，高于0.9易导致结果过窄）；
  • 记录所有兜底事件，每日生成“LLM失效率报告”，驱动Prompt迭代。

提示：不要迷信“大模型越大会越好”。我们在Qwen2-72B上做过对比，其解析准确率仅比Qwen2-7B高1.2%，但延迟增加3.8倍，且更难调试。对解析类任务，参数量不是关键，领域数据质量和Prompt工程才是胜负手。

3.2 约束权重的动态计算：为什么不能靠LLM“拍脑袋”

LLM输出的weight值如果直接用于排序，会导致结果严重偏斜。例如用户说“要显瘦，颜色不要太艳”，LLM可能给fit=slimming赋0.95，color_tone=muted赋0.65，但实际业务数据显示，“显瘦”在连衣裙类目中是基础需求（92%用户关注），而“颜色不艳”是差异化需求（仅38%用户提及）。若直接按0.95:0.65加权，会过度放大后者，挤占本该优先展示的基础款。

我们的解决方案是：LLM输出的是“相对重要性”，系统将其映射为“业务影响力系数”。具体步骤：

1. 建立类目级约束影响力基线：
   对每个商品类目（如“连衣裙”“防晒霜”），基于历史点击/购买数据，计算各属性的“需求强度指数”（DSI）。公式为：
   DSI(attr) = log(1 + 点击该attr商品的UV数 / 类目总UV数) × 100
   例如“连衣裙”类目中，fit=slimming的DSI=82.3，“color_tone=muted”的DSI=41.7。

2. 动态加权融合：
   最终排序权重 =LLM_weight × DSI(attr) × context_factor
   其中context_factor是上下文调节因子，例如：

   • 当query含“送礼”时，price_range的context_factor提升至1.5（价格敏感度降低）；
   • 当query含“学生党”时，brand_prestige的context_factor降至0.3（品牌溢价权重降低）。

3. 实时反馈闭环：
   每次用户点击结果后，记录点击商品的各属性值，更新DSI计算中的分子项。我们用Flink实时流处理，DSI每小时更新一次，确保权重反映最新用户偏好。

这个设计让LLM从“主观裁判”变为“客观翻译官”——它只需判断用户当前表述中哪个需求更突出，而“这个需求本身有多重要”交给数据说话。上线后，连衣裙类目“显瘦”相关商品的曝光占比从31%升至49%，但“颜色不艳”商品的曝光未被挤压，反而因精准匹配提升了12%的点击率。

3.3 商业规则的硬编码实现：为什么必须放弃“LLM理解规则”

把“仅展示自营商品”这类规则喂给LLM，是典型的“用火箭送快递”。我们曾让Qwen2-7B学习100条平台规则，微调后测试发现：规则遵守率仅93.7%，且错误模式高度集中——它会把“自营”理解为“品牌名含‘官方’二字”，导致展示非自营的“XX官方旗舰店”商品。根本原因在于：规则是刚性布尔逻辑，而LLM是概率分布采样，二者底层范式冲突。

因此，我们采用规则即代码（Rules-as-Code）方案：

• 所有业务规则预编译为独立函数，存入规则引擎（我们用Drools，因其支持复杂条件组合且可热更新）；
• LLM输出的business_rules数组，仅作为规则引擎的“开关列表”。例如["only_self_brand"]会触发selfBrandFilter()函数；
• selfBrandFilter()函数逻辑极其简单：

  public boolean execute(Product p) { return p.getBrand().equals("OUR_BRAND") || p.getSkuId().startsWith("SB_"); // SB_为自营SKU前缀 }

• 规则引擎在检索层执行，确保100%拦截，且性能开销可忽略（纳秒级）。

注意：规则函数必须与商品数据模型强绑定。我们曾因商品库中is_self_brand字段存在NULL值，导致规则漏判。解决方案是：在数据接入层强制清洗，NULL值默认为false，并加入监控告警。规则安全的第一道防线永远是数据质量，而非模型能力。

4. 实操过程详解：从零搭建LLM-Powered Product Discovery的完整步骤

4.1 数据准备：不是越多越好，而是要“对味”

很多人以为LLM产品发现需要海量query-log，其实恰恰相反。我们初期收集了200万条真实搜索日志，但发现其中78%是“iphone”“nike”等品牌词，对LLM理解“需求意图”帮助极小。真正有效的数据必须满足三个条件：长尾性、意图明确性、结果可验证性。

• 长尾性：筛选query长度≥7词、且在历史30天内出现频次≤3次的query。这类query代表未被现有系统很好服务的“沉默需求”。我们从中抽样5万条，覆盖“送礼”“肤质适配”“场景化使用”等12个核心意图簇。

• 意图明确性：人工标注每条query的“显性需求”（如“油痘肌”）和“隐性需求”（如“不闷痘”暗示“透气性好”）。标注团队由3名资深选品经理+1名NLP工程师组成，标注一致性Kappa值达0.89。关键技巧：要求标注员必须写出“为什么认为这是隐性需求”，例如：“‘夏天用着凉凉的’中‘凉凉的’是触觉通感，对应商品属性‘清凉感成分’或‘薄荷醇添加’”。

• 结果可验证性：对每条query，人工标注TOP5“理想结果”。标准不是“是否相关”，而是“是否真正解决用户问题”。例如query“适合油痘肌的防晒”，理想结果必须同时满足：① 成分表无致痘成分（如椰油酸、羊毛脂）；② 用户评论中“不闷痘”提及率＞65%；③ 质地描述含“清爽”“水感”“成膜快”。这5万条标注数据成为后续所有环节的黄金标准集。

数据准备耗时6周，但换来的是：LLM微调仅需2000步就收敛，且泛化能力远超用1000万条原始日志训练的模型。经验之谈：花在数据清洗和标注上的1小时，能省下模型调优的10小时。

4.2 LLM微调：用LoRA在Qwen2-1.5B上实现低成本高精度

我们放弃全参数微调，选择LoRA（Low-Rank Adaptation）方案，原因很现实：Qwen2-1.5B全参微调需8张A100，而LoRA仅需2张，且显存占用降低63%。更重要的是，LoRA的适配器可插拔，便于AB测试不同Prompt策略。

• LoRA配置：

  • Target modules：q_proj,v_proj,o_proj（注意力机制的关键投影层）；
  • Rank：8（经网格搜索，rank=8在精度与速度间最优）；
  • Alpha：16（alpha/rank=2，符合Qwen官方推荐）；
  • Dropout：0.1（防止过拟合，因我们的标注数据仅5万条）。

• 训练数据构造：
  将标注数据转为ChatML格式，严格遵循“系统提示-用户query-助手JSON”的三段式：

  <|im_start|>system 你是一名电商选品顾问，请将用户搜索需求转化为结构化采购指令。输出必须为JSON，字段仅限：intent_type, primary_entity, constraints[], business_rules[]。不要任何解释。 <|im_end|> <|im_start|>user 送爸爸的生日礼物 50岁 实用不浮夸 <|im_end|> <|im_start|>assistant {"intent_type":"gift_recommendation","primary_entity":"gift","constraints":[{"attribute":"recipient_age","value":"50+","weight":0.9},{"attribute":"value_orientation","value":"practical","weight":0.85}],"business_rules":["only_self_brand"]} <|im_end|>

• 关键训练技巧：

  • 课程学习（Curriculum Learning）：先用简单query（如“适合油痘肌的防晒”）训练1000步，再逐步加入复杂query（含否定、多条件嵌套）；
  • 对抗样本注入：在训练集里混入10%的对抗样本，如“不要化学防晒”“别推荐贵的”，强制模型学习区分“否定词”与“属性值”；
  • 早停策略：监控验证集上JSON格式合规率（是否合法JSON）和字段完整率（constraints数组是否为空），任一指标连续3轮下降即停止。

微调后，模型在测试集上的JSON合规率达99.2%，constraints完整率98.7%，远超我们初始目标的95%。最重要的是，推理速度保持在120ms内，完美支撑搜索主链路。

4.3 检索引擎改造：让Elasticsearch读懂LLM的“意图指令”

传统ES的function_score是静态配置的，而我们需要它能动态解析LLM输出的JSON并执行。我们的改造方案是：用Ingest Pipeline预处理+Script Score动态计算。

• Step 1：Ingest Pipeline注入约束
  在ES索引文档时，通过Pipeline将商品属性标准化为统一Schema。例如：

  // 商品原始数据 { "sku": "SUN-001", "attributes": { "skin_type": ["oily", "acne"], "sensation": ["cooling"] } } // Pipeline处理后 { "sku": "SUN-001", "attr_vector": [0.9, 0.8, 0.7] } // 对应oily_acne, cooling, matte的置信度

  这样，LLM指令中的skin_type=oily_acne就能直接映射到attr_vector[0]。

• Step 2：Script Score实现动态权重
  搜索时，将LLM JSON中的constraints作为查询参数传入，ES用Painless脚本实时计算得分：

  double score = 0; for (constraint in params.constraints) { if (constraint.attribute == 'skin_type') { score += doc['attr_vector'][0] * constraint.weight; } else if (constraint.attribute == 'sensation') { score += doc['attr_vector'][1] * constraint.weight; } } return score;

  关键优化：将attr_vector存为dense_vector类型，利用ES的向量近似搜索加速，使10万商品库的排序延迟控制在80ms内。

• Step 3：Business Rules硬过滤
  business_rules数组直接转换为bool filter：

  "query": { "bool": { "must": [ { "script": { "script": "score_script" } } ], "filter": [ { "term": { "is_self_brand": true } }, { "range": { "age_restriction": { "gte": 18 } } } ] } }

  过滤在query解析阶段完成，确保不满足规则的商品根本不会进入排序队列。

这套改造让ES从“关键词匹配器”升级为“意图执行器”，且完全复用现有基础设施，零新增运维成本。

4.4 结果校验层：用轻量模型守住最后一道防线

校验层的目标不是重新排序，而是剔除LLM指令与商品事实不符的“幻觉结果”。我们选用BERT-base微调，而非更大模型，因为：① 校验是二分类（符合/不符合），小模型足够；② 需要毫秒级响应，BERT-base P95延迟仅18ms。

• 训练数据构造：
  从5万条标注query中，对每个constraint抽取正负样本。例如skin_type=oily_acne：

  • 正样本：商品详情页含“专为油痘肌研发”+用户评论高频出现“不闷痘”；
  • 负样本：成分表含致痘成分（如羊毛脂）+评论有“爆痘”投诉。
    最终构建20万样本对，正负比1:1。

• 模型输入：
  拼接三段文本：
  "[CLS]" + query + "[SEP]" + product_title + "[SEP]" + product_description[0:256] + "[SEP]"
  这样模型能同时看到用户意图、商品表层信息、和深层描述。

• 部署优化：

  • 使用ONNX Runtime量化模型，体积缩小72%，推理速度提升2.3倍；
  • 缓存高频query-product对的校验结果（TTL=1小时），缓存命中率68%，进一步降低延迟。

校验层上线后，结果页中“伪相关商品”（如标称“油痘肌适用”但实际致痘）的比例从12.4%降至0.9%，用户差评中“货不对板”类投诉下降76%。

5. 常见问题与实战排查指南：那些文档里不会写的坑

5.1 问题：LLM频繁输出非法JSON，导致整个链路崩溃

现象：监控报警显示json_parse_error突增，错误日志中出现{"intent_type":"search"（缺少闭合括号）或"weight":0.95,"weight":0.8（重复key）。

根因分析：

• LLM在长上下文或高并发时，token生成不稳定，易在JSON边界出错；
• Prompt中未强调“JSON必须严格Valid”，模型默认按“人类可读”而非“机器可解析”标准生成。

实战解决方案：

1. Prompt强化：在系统提示末尾追加硬约束：
   "输出必须是RFC 8259标准的Valid JSON，可通过Python json.loads()直接解析。禁止注释、禁止省略逗号、禁止重复key。如不满足，输出'INVALID_JSON'字符串。"
2. 后处理双保险：
   • 第一层：用json.loads()解析，捕获JSONDecodeError；
   • 第二层：若解析失败，调用正则清洗（如补全}、删除注释//），再试解析；
   • 第三层：若仍失败，触发规则兜底（见3.1节），并记录INVALID_JSON事件。
3. 监控告警：对INVALID_JSON事件设置分级告警——单日超100次触发企业微信告警，超1000次自动暂停LLM服务，切至纯规则模式。

实操心得：我们曾因忽略此问题，在大促期间导致0.3%的搜索请求返回空结果。后来在Prompt中加入INVALID_JSON指令，配合后处理，错误率降至0.002%，且所有INVALID_JSON事件都指向同一类query（含emoji的query），从而针对性优化了输入清洗逻辑。

5.2 问题：LLM提取的约束与商品库属性不匹配，导致召回为空

现象：用户搜“适合敏感肌的温和洗面奶”，LLM输出{"attribute":"skin_type","value":"sensitive"}，但ES中无sensitive字段，只有skin_sensitivity:high。

根因分析：

• 商品属性体系由运营维护，LLM的语义空间与运营的标签体系存在gap；
• LLM未被训练理解“sensitive”应映射到skin_sensitivity:high而非skin_type:sensitive。

实战解决方案：

1. 构建属性映射词典（Attribute Mapping Dictionary）：
   由运营+算法共建，将用户常用表达映射到商品库字段。例如：

   用户表达	商品库字段	值映射
   "敏感肌"	skin_sensitivity	high
   "油痘肌"	skin_type	oily_acne
   "凉凉的"	sensation	cooling
   词典以YAML格式存储，支持热更新。

2. LLM输出后强制映射：
   在LLM输出JSON后，插入映射层：

   def map_constraints(constraints): mapping_dict = load_yaml("attr_mapping.yaml") for c in constraints: if c["attribute"] in mapping_dict: c["attribute"] = mapping_dict[c["attribute"]]["field"] c["value"] = mapping_dict[c["attribute"]]["value_map"].get(c["value"], c["value"]) return constraints

   这样skin_type=sensitive被自动转为skin_sensitivity=high。

3. 映射失败兜底：
   若value不在映射表中，保留原值并打上mapped:false标记，供后续人工审核补充。

注意：这个词典不是一劳永逸的。我们每周同步用户新query中的高频未登录词（如突然爆火的“刷酸肌”），由运营快速确认映射关系。这比让LLM学习所有变体更高效、更可控。

5.3 问题：校验层误杀优质商品，导致长尾需求覆盖不足

现象：用户搜“适合戴口罩不闷痘的防晒”，校验层将多款高口碑产品判为不符合，原因是商品详情页未明确写“戴口罩适用”，尽管用户评论中“口罩不闷痘”提及率超80%。

根因分析：

• 校验模型仅看商品详情页文本，未利用用户评论等UGC数据；
• 模型训练时，负样本过多依赖“详情页无描述”，导致对UGC证据权重过低。

实战解决方案：

1. 多源证据融合：
   校验模型输入扩展为四段：
   [query] + [product_title] + [product_description] + [top_comments]
   其中top_comments取点赞数TOP10的评论，拼接后截断至256字符。

2. 证据权重动态学习：
   在模型最后层加入attention机制，让模型自主学习各段文本的权重。例如对“戴口罩不闷痘”类query，模型自动提升top_comments的权重。

3. 人工复审通道：
   对校验结果为不符合但点击率＞5%的商品，自动加入“待复审队列”，由选品经理人工标注。我们发现，这类商品中37%确为优质长尾品，人工标注后加入训练集，模型对该类query的准确率从62%提升至89%。

实操心得：不要迷信模型“全自动”。校验层的价值不是100%正确，而是把需要人工干预的case从每天1000+降到50以内。我们设置了一个“校验宽容度”参数，对新品类（如刚上线的“刷酸肌”）自动调高宽容度，给运营留出打标签时间。

5.4 问题：业务规则更新滞后，导致促销活动期间结果违规

现象：618大促期间，运营临时要求“所有防晒商品必须展示‘618特惠’角标”，但LLM输出的business_rules中无此条，导致角标未展示。

根因分析：

• business_rules由LLM根据query生成，无法感知全局运营策略；
• 规则引擎未与营销系统打通，无法自动同步活动配置。

实战解决方案：

1. 规则引擎与营销中台对接：
   营销中台提供API，返回当前生效的全局规则。例如：

   GET /marketing/rules?time=2024-06-15 { "global_rules": ["show_618_badge"], "category_rules": {"sunscreen": ["show_618_badge", "priority_promotion"]} }

2. 规则合并策略：
   检索前，将LLM输出的business_rules与全局规则合并：

   final_rules = llm_rules + global_rules + category_rules.get(primary_entity, []) # 去重，保留优先级：LLM规则 > 全局规则 > 类目规则

3. 灰度发布机制：
   新规则上线前，先对1%流量开启，监控show_618_badge的展示准确率与性能影响，达标后再全量。

这个方案让业务规则从“静态配置”变为“动态感知”，618期间所有防晒商品角标展示准确率达100%，且无一次因规则更新导致服务异常。

6. 效果验证与业务影响：数据不会说谎，但要看懂数据背后的逻辑

6.1 核心指标提升：不止于点击率

上线3个月后，我们对比A/B测试组（新架构）与对照组（传统混合搜索），核心指标变化如下：

但最关键的不是这些数字，而是用户行为模式的改变。我们分析了10万条搜索会话日志，发现：

• Query精炼度提升：用户平均搜索次数从2.8次降至1.9次，说明首次搜索就能获得满意结果；
• 否定词使用减少：含“不要”“别”“非”的query占比从18.3%降至9.7%，表明LLM已能主动规避用户不想要的选项；
• 长尾品类渗透率上升：“医美级防晒”“男士专用防晒”等细分品类搜索量增长210%，证明系统激发了用户潜在需求。

提示：不要只盯着点击率。我们曾因过度优化点击率，导致模型偏向展示“高点击低转化”的网红款，客单价不升反降。后来将“搜索引导GMV”加入多目标损失函数，才实现点击与转化的双赢。

6.2 运营提效：从“猜用户想要什么”到“验证用户想要什么”

对运营团队而言，最大的价值不是技术多炫酷，而是决策依据从经验主义走向数据实证。以前，运营调整搜索权重要靠“我觉得用户更在意这个”，现在可以精确到：

• “‘清凉感’权重从0.6调至0.75后，‘薄荷醇’成分商品曝光提升32%，但‘酒精含量’相关差评增加15%，建议同步优化成分说明文案”；
• “在‘送礼’场景下，将‘包装精美’权重提升至0.8，使礼盒装商品