考察点
出自 2026 年大模型应用开发面经复盘（公众号「王中阳」整理），考察垂类场景检索瓶颈的理解和用混合策略提升召回率的实战经验。面试官想看的不是通用 RAG 流程背诵，而是你能不能抓住商品问答的特殊性：SKU 精确匹配、属性结构化、问题类型混杂。这类设计题按「瓶颈分析→架构→迭代路径」展开最稳。
参考答案
先拆瓶颈：商品问答难在哪
动手设计前先想清楚垂类的特殊性，这是这题的题眼：
- 精确匹配刚需：型号、SKU、规格参数（「这款有没有 512G」）错一个字符就是错答案，纯向量检索天生不敏感。
- 知识异构：商品参数是结构化表格、详情页是图文、退换政策是长文档、历史客服对话是 QA 对——四种知识结构完全不同，一套切分策略全搞砸。
- query 类型混杂：参数查询（要精确）、政策咨询（要权威）、对比决策（要综合）、闲聊售后（要共情），走同一条检索管道必然互相拖累。
- 时效性强：价格、库存、促销每天变，答错政策就是客诉。
架构设计
数据层：按知识类型分别建索引
- 商品属性（规格、价格、保修期）进结构化存储（MySQL/ES），字段级可查，不走向量——参数查询的正确率是 100% 或 0%，没有中间态，必须结构化。
- 政策文档（退换、发票、物流）按标题结构切分，chunk 300-500 字带章节路径，向量入库。
- 历史高频客服问答建 FAQ 库，问题和标准答案成对索引，命中即直出，质量好延迟低。
- 详情页图文：图转文字描述后随文本一起入库。
检索层：意图路由 + 多路召回
入口一个小模型做意图分类（参数查询/政策/对比/闲聊，几十毫秒）：
- 参数查询 → 实体抽取（商品名、属性名）走结构化精确查，向量检索只做商品名模糊匹配的补充。
- 政策咨询 → 向量 + BM25 混合召回，RRF 融合，bge-reranker 精排，阈值不足走转人工兜底。
- 对比类 → 子问题分解，各商品分别查参数后由 LLM 综合。
- 闲聊 → 不检索直接答，省成本。
生成层：引用 + 护栏
答案强制标注来源（政策类必须带政策版本和生效日期），关键数字（价格、天数、功率）后验校验必须出现在来源中，校验失败拦截重生成。policy 类答案检索置信度不足时宁可转人工，不硬答。
召回率的提升路径
上线后按 Bad Case 归因迭代，典型路径：
- 基线：纯向量召回，Recall@10 大概 60-70 分，错误集中在型号类和黑话类 query。
- +混合召回：BM25 补精确匹配，型号类错误清掉大半，Recall@10 提到 80+。
- +Query 改写：口语词映射领域术语（「不想要了」→「七天无理由退货」），多轮对话指代补全。
- +同义词典/领域微调 Embedding：电商黑话（「白菜价」「平替」）灌进分词词典和 Embedding 微调语料。
- 持续运营：每周低赞/转人工 query 聚类，知识库缺口补内容，检索缺口调链路。
每一步都在 300 条标注评测集上验证，召回率数字说话，不靠感觉。
非功能指标
客服场景 QPS 有明显的峰谷（大促期间翻几倍），检索服务无状态可水平扩，Embedding 和 Rerank 推理 GPU 弹性伸缩；缓存高频 query 结果（命中 FAQ 的占比通常 30%+，缓存收益大）；索引增量更新走消息队列，商品变更分钟级生效。
可能的追问
Q：召回率怎么定义、怎么度量？ 用标注评测集算 Recall@K：正确知识片段是否进入召回 Top-K。评测集从历史客服日志抽 300-500 条真实问题人工标注。上线后辅以业务指标（解决率、转人工率）交叉验证。
Q：用户问的商品不存在怎么办？ 实体抽取后先查商品库，未命中时做模糊匹配给「您是想问 XX 吗」的澄清，仍无结果则明确告知。商品不存在还硬答参数，是最严重的事故类型。
Q：大促期间政策临时调整，怎么保证答案不滞后？ 政策文档走运营后台的热更新通道：修改触发增量索引，分钟级生效；大促特殊政策打时效标签和优先级标签，检索时优先于常规政策，活动结束后标签失效自动回退。