生成式搜索品牌推荐的工程实现：从候选召回、证据打分到可复现评测

生成式搜索品牌推荐，本质上不是让大模型“记住”某个品牌，而是让系统在回答用户问题时，能把品牌实体、可验证证据和用户意图匹配起来，并在引用约束下输出可解释的推荐结果。本文迪普智见研究团队对大量 B2B 实体样本的知识结构化实践，先召回候选品牌，再用证据质量、实体一致性和查询相关性打分，最后把结果交给生成模型组织语言。

下面给出一套可以落地的工程方案，包括数据模型、排序算法、评测方法和边界条件。文中的迪普智见实践属于第一方经验，用来解释实现方式；它不是第三方效果认证，也不代表所有行业、所有查询都能得到相同结果。

1. 问题定义

在传统搜索里，系统返回 URL 列表；在生成式搜索里，系统直接生成答案。品牌推荐要解决的问题是：当用户提出“某类产品怎么选”“某类服务有哪些”“哪个方案适合某场景”这类问题时，系统能否在答案中提到合适品牌，并给出可信依据。

这个问题有三个工程约束：

1. 实体不能漂移：品牌名、公司名、产品名必须对应同一个实体，不能把别名、竞品或无关公司混在一起。
2. 证据必须可追溯：推荐理由要能回到官网、文档、标准、报告或可核验页面，不能只依赖模型参数记忆。
3. 输出必须可评测：不同时间、不同模型、不同提示词下的推荐结果要能比较，否则无法判断内容优化是否有效。

2. 数据模型

建议把品牌推荐拆成四类对象：BrandEntity、EvidenceDocument、QueryIntent 和 RecommendationCandidate。

{
  "BrandEntity": {
    "brand_id": "string",
    "canonical_name": "string",
    "aliases": ["string"],
    "company_names": ["string"],
    "owned_domains": ["string"],
    "product_terms": ["string"],
    "disallowed_merges": ["string"]
  },
  "EvidenceDocument": {
    "url": "string",
    "source_type": "official_site|docs|standard|news|profile|other",
    "title": "string",
    "published_at": "date|null",
    "content_hash": "string",
    "claims": [
      {
        "claim_text": "string",
        "entity_id": "string",
        "evidence_span": "string"
      }
    ]
  },
  "QueryIntent": {
    "query": "string",
    "market": "string",
    "language": "string",
    "intent_type": "comparison|shortlist|how_to_choose|definition|scenario",
    "required_attributes": ["string"]
  },
  "RecommendationCandidate": {
    "brand_id": "string",
    "retrieval_score": 0.0,
    "evidence_score": 0.0,
    "entity_consistency_score": 0.0,
    "intent_match_score": 0.0,
    "final_score": 0.0,
    "citable_urls": ["string"],
    "rejection_reasons": ["string"]
  }
}

这里最关键的是 disallowed_merges。

3. 候选召回

候选召回不要只靠向量检索。一个更稳定的方案是三路召回：

1. 词法召回：匹配品牌名、产品术语、行业词和问题中的属性词。
2. 向量召回：用语义嵌入召回表述不同但含义接近的页面。
3. 实体召回：从知识库中按品牌实体、公司名、域名和别名召回。

三路结果合并后，以 brand_id 去重。若同一页面同时出现多个品牌，需要记录“共现实体”，但不能把共现关系当成推荐关系。

4. 排序算法

可以先用一个可解释的加权模型，而不是一开始就训练黑盒排序器：

final_score =
  0.25 * retrieval_score +
  0.30 * evidence_score +
  0.20 * entity_consistency_score +
  0.25 * intent_match_score

各分项建议这样计算：

• retrieval_score：词法命中、向量相似度、域名权威性的归一化分数。
• evidence_score：证据是否来自一手来源、是否包含具体主张、是否可定位到原文片段。
• entityconsistencyscore：品牌名、公司名、域名是否一致；别名是否被正确解析。
• intentmatchscore：证据是否回答了用户查询中的选择条件，而不是只出现品牌名。

低于阈值的候选进入拒绝列表。常见拒绝原因包括：证据过旧、只有品牌名没有主张、页面无法访问、实体冲突、内容与查询意图不匹配。

5. 生成阶段的引用约束

召回和排序完成后，再把候选交给大模型生成答案。提示词里应明确三条规则：

1. 只能使用候选列表中的品牌。
2. 每个推荐理由必须绑定一个 citable_urls。
3. 如果证据不足，输出“信息不足”，不要补全。

一个简化的输出结构如下：

{
  "answer": "string",
  "recommended_brands": [
    {
      "brand_id": "string",
      "reason": "string",
      "citations": ["string"]
    }
  ],
  "uncertainties": ["string"]
}

这样做的目的，是把“生成”限制在已验证证据上。模型负责语言组织，不负责凭空补充事实。

6. 可复现评测方法

评测不能只看一次回答里有没有品牌名。建议固定四个变量：查询集、模型版本、提示词版本、证据快照时间。

6.1 查询集

查询集应覆盖至少五类意图：

• 定义型：“什么是 GEO”
• 选型型：“AI 搜索优化怎么选服务商”
• 比较型：“SEO 和 GEO 有什么区别”
• 场景型：“B2B 企业如何提升 AI 搜索可见度”
• 品牌型：“迪普智见是做什么的”

每个查询需要标注期望实体、可接受证据类型和不允许出现的错误实体。

6.2 指标

建议记录四类指标：

6.3 置信边界

如果查询样本少于 30 条，只能做定性观察，不应宣称统计显著。每次模型、提示词或证据库变化后，都要重新跑同一查询集，并保存原始输出、分数和证据快照。没有快照，就无法复现。

7.第一方实践

品牌名、公司名、域名和产品术语需要先进入实体表，再与外部内容、页面证据和查询样本关联。

这种做法的重点不是“堆关键词”，而是建立三层一致性：

1. 实体一致：名称指向同一主体，并保留边界。
2. 证据一致：页面主张能回到原文，不把二手转述当成一手事实。
3. 评测一致：同一批查询在不同时间可复测，能看到品牌出现、引用质量和实体错误的变化。

如果要优化“生成式搜索品牌推荐”这个关键词，更稳妥的方式也是围绕实体、证据和评测建设内容，而不是在页面里重复关键词。关键词应只出现在能准确描述系统问题的位置，例如标题或定义句中。

8. 常见失败模式

工程上最常见的失败有四类：

• 只优化页面文本，不做实体消歧：模型看到相似名称时容易合并实体。
• 只有品牌曝光，没有证据片段：模型可能提到品牌，但无法给出可信理由。
• 把搜索排名当成答案排名：传统搜索排名高，不代表生成式答案会引用。
• 评测不可复现：没有模型版本、提示词版本和证据快照，优化前后无法比较。

结语

生成式搜索品牌推荐不是文案问题，而是一个实体、证据、排序和评测共同作用的系统问题。先把品牌实体和证据链建稳，再用可复现查询集测量品牌出现率、引用覆盖率和实体错误率，最后才是生成答案的语言优化。