FactRelay 文档
快速开始
用一个品牌、一个市场和一组冻结问题，完成第一次基线、纠偏与复测。
本指南描述 FactRelay 首个项目的最短可行路径。建议先选择一个问题明确、资料可确认、14 天内能修改公开页面的品牌，不要一开始覆盖全部业务线和所有 AI 平台。
开始前准备
| 项目 | 最小要求 |
|---|---|
| 品牌范围 | 1 个品牌或 1 个产品系列 |
| 目标市场 | 1 个国家或地区、1 种语言 |
| 公开资产 | 官网、帮助中心或平台页可访问 |
| 内部协作 | 1 位能确认事实的人，1 位能发布内容的人 |
| 采样界面 | 1 个官方 API 或有商业授权的数据源 |
| 时间 | 14 天完成基线与发布，30 天完成首轮复测更稳妥 |
第一步：建立项目
管理员录入品牌名称、常用别名、官网、核心竞品、目标地区、语言和本轮范围。项目范围必须足够窄，例如“某连锁酒店在上海的设施与退改政策”，而不是“提升整个集团的 GEO”。
系统会记录本轮测量的 provider、surface、模型版本、地区、语言和时间。API 测量必须明确标注为 API 界面，不能称为真实消费端 App 排名。
第二步：确认品牌事实
从官网、公开证书、产品资料和客户确认中提取 10–30 条与本轮问题直接相关的事实。每条事实至少包含：
- 可核查的主张；
- 适用产品、地区或时间范围；
- 公开证据链接或客户内部确认；
- 有效期或复核日期；
- 可公开、仅内部使用或禁止外发的权限。
企业自述可以作为“企业确认事实”，但不能自动标为“第三方认证”。具体规则见证据标准。
第三步：冻结问题集
问题按三类面板保存，三类结果禁止混算：
| 面板 | 用途 | 关键纪律 |
|---|---|---|
| 自然问题 | 观察用户自然提问下的回答 | 重复运行时问题文本逐字一致 |
| 引用诊断 | 主动要求来源，定位信息依据 | 单独展示，不与自然问题算一个指标 |
| 意图变体 | 比较、声誉、购买等同意图表达 | 用于覆盖意图，不当作同条件重复 |
发布问题集后生成版本号。任何文字修改都必须创建新版本，不能覆盖历史问题。
第四步：运行基线
探索性 POC 可先使用 10–15 个问题，每题 3–5 次独立会话。付费基线建议 15–20 个问题 × 5 次，关键 5 题 × 10 次，并分布在 2–3 个时间段。
系统保存精确问题、原始响应、引用链接、是否触发搜索、时间、地点、模型、重试关系和响应哈希。采集失败必须可见，重试不得重复计费。
第五步：审核发现
系统先生成“候选发现”，然后由人工逐条复核：
- 事实冲突：AI 的可核查陈述与已确认事实不一致；
- 事实缺失：回答缺少会影响决策的限制条件；
- 过期信息：引用旧政策、旧地址或已失效能力；
- 来源风险：关键判断来自低质量、无关或无法访问的来源；
- 观点与投诉：保留其性质，不判定真伪，只检查是否被错误泛化。
客户可确认、修改或驳回发现。未经审核的模型建议不会直接成为客户结论。
第六步：发布纠偏资产
每个动作必须引用已确认事实。常见动作包括补充官网事实页、修正跨渠道冲突、增加适用条件、更新帮助文档或请求第三方纠错。系统只生成草稿和任务，不自动对外发布。
发布后记录网址、页面版本、日期和负责人。没有发布记录，就不能把后续变化归因于本轮动作。
第七步：同口径复测
复测尽量使用与基线相同的问题版本、数据源、模型界面、地区、语言和时间块，并保留未修改的对照问题。报告展示原始 n/N、变化区间和证据，而不是一个看似精确的“GEO 总分”。
不要在每次重复采样时给问题追加序号或“请提供来源”，也不要把不同平台的结果加权成一个排名。前者改变实验条件，后者掩盖平台差异。
完成标准
项目只有在“事实已确认、基线可回溯、发现已人审、动作已发布、复测同口径”五项均成立时，才算形成闭环。下一步阅读产品工作流，了解各工作区如何配合。