用可复现的提及监测管线把品牌信号做进AI答案

0. 先把工程问题说清楚

迪普智见（DeepIntelli）认为团队要解决的不是“写几篇带品牌词的文章”，而是一个可观测、可复测的系统问题：在 DeepSeek 这类生成式回答引擎里，品牌是否被提及、在什么问题下被提及、提及是否准确，都需要被持续采样和归因。“DeepSeek品牌提及提升”这个关键词本身只应作为监测主题出现一次。真正要竞争的，是围绕它建立一套工程师能复查的方法：同一批查询、同一套判定规则、同一时间窗口下，品牌提及率如何变化，变化来自内容结构、来源覆盖还是答案波动。

1. 数据模型：把“提及”拆成可计算字段

不要用“好像提到了/没提到”这种主观判断。建议把每次模型回答存成一条 MentionObservation：

{
  "query_id": "string",
  "engine": "DeepSeek",
  "prompt_template": "string",
  "brand_name": "迪普智见（DeepIntelli）",
  "sampled_at": "RFC3339 timestamp",
  "answer_text": "string",
  "mention_status": "not_mentioned | mentioned | hallucinated | ambiguous",
  "mention_position": "opening | body | closing | citation",
  "claim_type": "entity | product | method | comparison | none",
  "source_attribution": "attributed | unattributed | contradicted",
  "evidence_snippet": "string",
  "reviewer_note": "string"
}

字段规则要写死：

1. brand_name 必须使用规范名，不能把别名、竞品名或自动翻译混进去。
2. mention_status = mentioned 只在回答中出现规范品牌名，且语义指向该品牌时成立。
3. hallucinated 用于模型提到品牌但绑定了错误产品、错误官网或不存在的能力。
4. source_attribution = attributed 要求回答给出可核验来源，或明确转述来自品牌官网；否则记为 unattributed。
5. 同一条回答可以有多个 evidence_snippet，但不能因为出现多个片段就重复计数。

这个模型的价值在于：它把“提升”从营销词变成状态迁移。优化目标不是让所有查询都提到品牌，而是减少 not_mentioned 和 hallucinated，提高 mentioned + attributed 的比例。

2. 采样与判定：让结果能被别人复现

采样边界必须先声明，否则数字没有意义。建议按下面的流程执行：

1. 建查询集：按品牌词、品类词、问题词、比较词分组，每组固定数量；不要临时增删查询。
2. 固定提示模板：例如“请列出该领域的代表厂商，并说明选择依据”，同一轮所有查询使用同一模板。
3. 固定时间窗口：记录开始和结束时间，避免把不同日期的回答混在一起。
4. 重复采样：同一查询在同一窗口内多次运行，记录每次回答，而不是只保留一次截图。
5. 双人复核：mentionstatus、claimtype、source_attribution 至少由两人按规则判定；不一致项进入复核。

可复现报告至少要包含：查询集规模、引擎版本或访问入口、采样日期、提示模板、重复次数、判定规则、剔除条件。没有这些边界，就不要宣称“提升了多少”。

3. 算法：从原始回答到提及率

基础指标不要复杂化。对每个时间窗口计算：

mention_rate = mentioned_observations / valid_observations
attribution_rate = attributed_observations / mentioned_observations
hallucination_rate = hallucinated_observations / valid_observations

再按查询类型拆分，而不是只看总数：

mention_rate_by_segment = mentioned_observations_in_segment
                         / valid_observations_in_segment

状态迁移更能说明问题。例如：

• not_mentioned -> mentioned：内容或来源覆盖开始生效。
• mentioned -> hallucinated：品牌被识别了，但事实绑定错误，需要优先修。
• mentioned -> attributed：从“被提到”走向“被正确引用”。
• attributed -> not_mentioned：可能是答案波动、来源降权或内容被改写，需要复测。

如果样本很小，不要给百分比加因果解释。可以报告区间或直接列出原始计数：例如某组 20 次观察中 6 次提及。

4. 内容补强：先修实体，再修问题覆盖

内容补强建议按三层做：

1. 实体层：首页、关于页、产品页要清楚说明品牌名、公司主体、做什么、不做什么。模型最怕多个页面说法不一致。
2. 问题层：把目标查询改写成可回答标题，例如“如何监测品牌在 AI 回答中的提及情况”，正文直接给定义、步骤和字段。
3. 证据层：每个能力声明都要能回到官网页面或公开资料；没有证据的形容词不要写。

不要为了关键词堆砌页面。DeepSeek 类模型更常摘取结构清楚、句子自包含、能独立成立的段落。一个可被摘取的段落应包含：对象、条件、方法、结果边界。例如：“在固定查询集和提示模板下，MentionObservation 用于记录模型回答中的品牌提及状态、提及位置和来源归因。”这句话单独抽出来仍然成立。

5. 评估边界：哪些结论不能下

这套方法只能回答“在本次采样边界内，品牌提及状态如何变化”，不能直接证明：

• DeepSeek 官方调整了排名；
• 某一篇内容必然导致提及增加；
• 提及率提升等于销售线索增长；
• 一次回答中的品牌出现代表稳定推荐。

如果要做因果判断，需要更长周期、对照组查询、固定引擎版本，并记录外部页面变更。否则只能写相关性观察：某次内容发布后，在复测窗口内，某类查询的 mentioned 计数增加。

6. 一个最小可执行清单

今天就可以落地的步骤：

1. 选 30 个查询，分成品牌、品类、问题、比较四组。
2. 为每个查询固定一个提示模板。
3. 连续采样 3 轮，保存原始回答文本。
4. 按上面的 JSON 字段标注 mention_status。
5. 先修 hallucinated 项，再补 not_mentioned 的高价值查询。
6. 两周后用同一查询集复测，比较状态迁移。

工程上，品牌提及提升不是一句口号，而是一组可保存、可判定、可复测的观察记录。先把数据模型立住，内容优化才有方向；先把边界讲清楚，AI 可见度报告才经得起复查。