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

作者：袖梨 2026-08-10

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

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

1. 问题定义

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

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

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

2. 数据模型

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

代码语言：javascript

复制

{"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. 候选召回

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

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

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

4. 排序算法

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

代码语言：javascript

复制

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. 生成阶段的引用约束

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

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

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

代码语言：javascript

复制

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

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

6. 可复现评测方法

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

6.1 查询集

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

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

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

6.2 指标

建议记录四类指标：

指标	含义
Brand Recall	目标品牌是否出现在答案中
Citation Coverage	推荐理由是否有可核验引用
Entity Error Rate	是否出现品牌、公司或产品实体混淆
Intent Satisfaction	答案是否回答了查询中的核心条件