multi-source-verification

name	multi_source_verification
description	多源交叉验证、实体存在性确认、先取超集后过滤的综合验证策略
trigger	数据需要交叉验证、实体可能不存在、或需要从超集中筛选子集
success_rate	0
status	seed
trigger_conditions	{"domain":["general"],"entity_types":["any"],"attribute_types":["any"],"coverage_gap_pattern":"conflicting_sources"}
cost_hint	mid
effectiveness_score	0

Skill: Multi-Source Verification（多源验证与过滤策略）

目标

解决三类验证性检索问题：

1. 实体存在性验证：确认特定命名实体（事件、组织）是否真实存在，避免在幽灵实体上浪费搜索预算
2. 多源数据融合：需要跨多个独立数据源进行交叉引用、筛选和去重的复杂查询
3. 超集过滤：从标准列表中检索满足特定条件的子集，当该子集不存在独立页面时

核心策略：先验证存在性 -> 分治获取数据 -> 程序化融合/过滤。

适用场景

1. 实体存在性可疑：查询包含具体名称、时间、地点的事件或组织，但初始搜索未找到官方信源
   • 例："2023年韩国伍德斯托克音乐节的演出阵容"
2. 多源交叉查询：需要查找同时出现在多个不同来源中的实体
   • 例："既在 Billboard 榜单上又获得 MTV 提名的歌曲"
3. 超集子集过滤：从标准权威列表中筛选满足特定属性的子集
   • 例："诺贝尔和平奖得主中曾任国家元首的人"
4. 数据清洗需求：涉及去重、名称标准化处理

不适用场景

• 常识性实体查询（如"2024年奥运会"）
• 单一来源可直接回答的简单查询
• 目标子集本身拥有广为人知的独立页面

核心原则

原则1：存在性优先

在查询任何属性之前，必须先确认实体是否真实存在或如期举行。 将"搜索结果缺失"视为"实体可能不存在"的强信号，而非仅仅是"没搜到"。

原则2：及时止损

一旦验证逻辑判定实体极大概率不存在，立即停止搜索并报告结果。 禁止尝试更多变体搜索浪费预算。

原则3：分治获取

不要试图搜索"交集"。分别获取各个源的完整原始数据列表，先获取全量数据，再在本地处理。

原则4：超集优先

永远不要先搜索交集或特定子集。首先寻找包含所有候选人的"超集"页面， 获取完整列表后，通过访问个体页面或利用上下文来验证特定条件。

原则5：程序化融合

依靠 Python 执行能力进行数据清洗、交集运算和过滤，而非依赖搜索引擎的布尔逻辑。

执行流程

流程A：实体存在性验证

Step 1：初始存在性探测

• 使用实体全名 + 官方关键词搜索
• 查询模板："[Entity Name] [Year] [Location]" official site
• 判断：找到官方网站/主流媒体报道 -> 实体存在，转常规检索。仅有社交媒体/二手票务 -> 进入否定性验证

Step 2：否定性验证

• 主动搜索实体的"取消/虚假"信息
• 查询模板：[Entity Name] cancelled / [Entity Name] fake OR scam OR hoax
• 找到辟谣或取消公告 -> 确认无效，终止任务

Step 3：权威信源缺失确认

• 扩大范围搜索主办方或相关背景，确认是否为同名误用
• 若经多步仍无权威证据 -> 判定为"无证据表明该实体存在"，停止消耗预算

流程B：多源数据融合

Step 1：复杂度评估与探测

• 分析问题，识别涉及的数据源（Source A, Source B）
• 尝试1-2次直接搜索，若触发 NO_PROGRESS 信号，立即进入分治模式

Step 2：分治数据获取

• 将查询拆解为独立的数据获取子任务
• 分别获取各源的完整原始数据列表
• 不要在搜索关键词中加入复杂的交集条件

Step 3：程序化分析

• 使用 Python 进行解析、标准化、交集运算、去重
• 处理名称差异（如 "Feat." vs "featuring"）
• 生成最终列表并添加 Evidence

流程C：超集过滤

Step 1：定位超集列表

• 搜索包含所有候选人的标准列表页
• 查询模板：site:wikipedia.org "List of [Base Entity]"

Step 2：批量提取候选名单

• 打开 Wikipedia 列表页后用 find() 提取完整表格，不要在搜索引擎层面过滤

Step 3：逐一验证筛选条件

• 遍历候选人名单，针对筛选条件进行核实
• 先检查列表页简介；信息不足再打开详情页

补充策略 (from dataset mining: constraint_satisfaction)

核心原则

1. 条件拆分：将复合问题拆成独立、可验证的原子条件，避免一次性搜索整句。
2. 先宽后窄：先用最独特或最少歧义的条件做首轮过滤，再逐步叠加剩余条件。
3. 交叉验证：对候选结果用剩余条件逐一核验，任一不符即淘汰。
4. 结构化检索：优先使用“实体+属性”或“实体+关系+实体”的短关键词组合，而非长自然语言。

标准执行流程

1. 列条件：把问题中的限定词全部列出，标注类型（时间/地点/人物/机构/事件/属性）。
2. 选锚点：评估各条件的唯一性，选最少结果、最少歧义的作为首轮“锚点”。
3. 首轮检索：用锚点条件构造最短关键词（如“波兰 解释学 哲学家”）。
4. 生成候选：从首轮结果中提取可能实体列表（人名、州名、球队名等）。
5. 条件核验：对每条候选，用剩余条件逐一验证（如“该大学荣誉主席是21世纪法国思想家？”）。
6. 淘汰不符：任一条件不满足即剔除，直到只剩唯一匹配。
7. 补全细节：对最终匹配实体，补全问题要求的附加信息（参议员名单、转会细节等）。
8. 二次确认：用反向查询确认（如“Alexis Sanchez 2018 转会 曼联”）。

检索策略模板

• {国籍} {领域/职业} {核心理论或属性}
  例：波兰 哲学家 解释学
• {实体A} {关系动词} {实体B} site:wikipedia.org
  例：University of Warsaw honorary president 21st century French philosopher

补充策略 (from dataset mining: entity_disambiguation)

核心原则

1. 先全局后局部：先用宽泛搜索确认实体存在哪些可能指向，再逐步添加限定条件缩小范围
2. 交叉验证：通过多个独立来源（官网、维基、权威数据库）确认同一实体身份
3. 上下文锚定：利用问题中的时间、地点、领域等线索作为筛选条件

标准执行流程

1. 歧义检测
   用基础查询"{entity}"搜索，观察结果是否出现多个不同对象（如不同地点的学校、不同领域的人物）

2. 初步分类
   根据搜索结果将歧义实体分类：同名不同地？同名不同领域？不同产品线？

3. 添加限定词
   逐步加入问题中提供的限定条件：

   • 地理限定："{entity} {city/state/country}"
   • 领域限定："{entity} {profession/product type}"
   • 时间限定："{entity} {year}"

4. 权威源确认
   优先检查：

   • 官方网站（学校官网、公司官网）
   • 维基百科消歧义页（"Roxbury High School (disambiguation)"）
   • 行业数据库（IMDb人物、IEEE产品库）

5. 交叉验证
   对比至少2个独立来源对同一实体的描述是否一致（如学校地址、人物生卒年）

6. 最终确认
   当满足以下任一条件时停止：

   • 所有权威源指向同一实体
   • 限定条件已足够排除其他可能性（如“1877年歌剧演员”）

检索策略模板

• 基础歧义检测："{entity}" site:wikipedia.org（优先查看消歧义页）
• 精准定位："{entity} {unique_attribute}"（如"Roxbury High School New Jersey"）
• 排除法："{entity} -{irrelevant_term}"（如"Wayne Anderson -football"排除橄榄球运动员）