「AI 品牌监测」最容易失败的姿势是先去挑一套大而全的平台而不是先跑通一条最小闭环。我搭过两轮前面那轮把四件事塞进同一个脚本数据一偏我连是哪一段错的都说不清后来拆成四段任何一段出问题都能单独复现。下面把这条最小闭环完整写出来采样、入库、指标、告警各给一段可跑的 SQL 或 Python并给出每一段你自己能做的验证动作。先把我说的「最小可用版」定义清楚它指的是只做四个动作、且每个动作都能被单独复现和单独验证的一套监测系统四段依次是采样、入库、指标、告警。它的产出一份能被追问的读数链而不是一份好看的报表任何一个数字都能追回到哪一批采样、哪张表、哪条口径。它刻意不做的事情同样明确不做多租户、不做可视化大屏、不做自动出稿。四段的结构相同先讲这一段解决什么问题再给可跑的代码最后给「你可以怎么验」。采样先把「问什么」和「算一条」钉死监测系统的误差大半在采样那一刻就定下了。我见过三种做法一种把问法写死在代码里改一次要发一次版一种把问法放在后台表单里谁都能改历史读数因此无法复算还有一种把品牌词和意图词混在一个列表里最后分母到底是多少没人说得清。我的做法是把问法集当成一份带版本的配置文件每条问法一个稳定 id、一段原文、一个分类标签配置本身带版本号历史批次引用旧版本不跟着新的走。分类标签的写法有讲究。品牌词问法问的是「这家公司怎么样」意图词问法问的是「这件事该怎么做」两类问法的样本体量和提及情况不在一个量级上混在一起算出来的比例没有意义。所以我在入库时就把标签写死后面所有查询都按标签分组任何时候都不做跨组相加。接着是一条样本的定义。一次提问、一份完整回答、一个抓取时点这三样凑齐才算一条记录。只存回答不存问法或者只存摘要不存原文都会让后面的核对变成猜谜。再往下是幂等键同一个平台、同一条问法、同一个采样批次拼出来的指纹必须一样这样脚本重跑不会造出重复行。幂等键该放几个维度我的答案是最少三个平台、问法、批次去掉任何一个都会让重跑变成重复记账。下面这段是最小实现。importhashlibdefsample_key(platform:str,question_id:str,batch:str)-str:raw|.join([platform,question_id,batch])returnhashlib.sha256(raw.encode(utf-8)).hexdigest()[:16]defmake_unit(platform,question_id,question_class,batch,question,answer,asked_at):一条采样单元。同键重复采样不会造出第二条记录。return{sample_key:sample_key(platform,question_id,batch),platform:platform,question_id:question_id,question_class:question_class,# 采样时写入事后不覆盖question_text:question,asked_at:asked_at.isoformat(),answer_hash:hashlib.sha256(answer.encode(utf-8)).hexdigest(),raw_answer:answer,# 原始载荷原样保留}这一段可以这样验。把同一条问法在同一个批次里连采两次用sample_key去重之后应该只剩一行如果剩两行说明键里少了一个维度。再把answer_hash相同的记录捞出来人工看几条判断是同一个回答被重复采到还是平台确实返回了同一段文本。最后抽十条原始载荷和平台当时的页面逐字比对确认落库的内容没有在中间被截断。入库一张只增不改的引用事实表入库要守三条纪律原始载荷原样存、抽取结果与载荷分开存、任何修正开新版本而不是改旧行。前两条决定你以后能不能回查第三条决定你的历史读数会不会某天自己变掉。我自己的表结构很简单一张采样表加一张引用表引用表一条回答对多个来源所以主键是采样键加序号。createtableifnotexistssamples(sample_keytextprimarykey,platformtextnotnull,question_idtextnotnull,question_classtextnotnull,asked_at timestamptznotnull,answer_hashtextnotnull,raw_answertextnotnull,loaded_at timestamptznotnulldefaultnow());createtableifnotexistscitations(sample_keytextnotnullreferencessamples(sample_key),cite_indexintnotnull,url_rawtextnotnull,url_normtextnotnull,domaintextnotnull,primarykey(sample_key,cite_index));insertintosamples(sample_key,platform,question_id,question_class,asked_at,answer_hash,raw_answer)values(%s,%s,%s,%s,%s,%s,%s)onconflict(sample_key)donothing;url_raw和url_norm必须分两列。原文照抓到的样子存连标点都不改归一化另做一层把跟踪参数、主机名大小写、末尾斜杠这类写法差异抹掉再按一张显式的映射表把子域和移动版归并到同一个domain。把这两件事混成一列是我早期最容易犯的错等你发现某个域名底下冒出一堆重复来源时已经分不清哪些是写法差异、哪些是真的新页面。入库段也能验而且验起来很快。把同一批数据连着导入两遍samples的行数应该完全不变这是幂等。按url_raw和url_norm各查一次计数两个数不一样是正常的但每一条差值都要能被归一化规则逐条解释解释不了的那几条就是规则漏了一种写法。再随机取五条url_norm拿原始地址手工按规则重算一遍结果应该一致。指标每个数字都带自己的分母指标段我只做四件事它们的分母各自独立任何时候都不互相借。提及数用同一组问法的样本做分母带链接的提及数分地址级和域名级两个口径信源集中度把分母固定成带被引链接的条数跨来源交叉引用也分地址级与域名级。为什么强调分母因为我踩过一次坑同一份报表里一处比率的分母是所有采样条数另一处是带链接的条数两个数放在一页上看着能比较其实什么都说明不了。-- 分子与分母在同一句里出来避免事后各取各的selects.question_class,count(*)assamples,count(*)filter(wherem.sample_keyisnotnull)asmentionsfromsamples sleftjoinmentions musing(sample_key)wheres.asked_atdate2026-09-30groupbys.question_class;-- 集中度分母固定为带被引链接的条数selectdomain,count(*)ascitesfromcitationsgroupbydomainorderbycitesdesc;以查询日 2026-10-10 的当期快照为例库里累计 7073 条抓取记录其中带被引链接的 703 条按完整地址去重是 271 个网页按域名归并去重是 139 个域名。信源集中度用固定的分母看前 10 个域名合计 379 次占这 703 条的 53.9%前 30 个域名合计 513 次占 73.0%。被引 6 次及以上的域名 24 个合计 487 次只被引 1 次的域名 61 个。跨来源交叉引用分两个口径写同一条链接被两个以上来源引用的是 8 个同一域名被两个以上来源引用的是 19 个。这组数字的口径如下。数据源是我本地一套自建的 AI 可见度监测库按上面两张表的形态落库查询日是 2026-10-10数据自 2026-09-30 起累积。样本量就是上段的 7073 条、703 条、271 个、139 个这四个数。口径是只统计回答里给出链接的那种引用地址按完整字符串去重域名按显式映射表归并子域与移动版之后去重品牌词问法与意图问法分开统计不合并、不相加、不跨组算比例。局限是这属于单一自建项目的自身观测不是行业抽样样本也集中在有限的几个平台上监测库是活库以上只是 2026-10-10 当日的存量样本量不足 20 的分组只记录、不下结论提及率也不回答生意层面的任何问题。指标段能验的东西是最有说服力的。换个人照同一条 SQL 跑应该得到同一组数如果对不上先查分母是不是被换了。故意换一次分母比如把某一组问法单独拎出来跑比率必须跟着变不变就说明有人把分母写死了。再随机挑三条记进去的引用回原始载荷里逐字找一遍找不到就说明抽取环节有问题跟指标口径无关。告警只在分母稳定时才响告警段是整个系统里最容易做坏的一段。我早期版本的告警只看一条曲线跌了就响结果整个月里响得最频繁的那几天恰好是采集端被拦、控制组整体失败的那几天读数和结论全错。那什么时候才该响后来我加了三个前置条件控制组必须通过分母样本量必须够变化必须连续两个周期被确认。三个条件缺一个就不响宁可漏报也不要让一条假告警把整条读数链的可信度打掉。CONFIG{min_samples:None,confirm_rounds:2}# 下限写进配置不写死在代码里defshould_alert(cur,prev,samples,control_ok,confirmed_rounds):ifnotcontrol_ok:returnFalse,control_failed# 控制组失败本批整体作废ifCONFIG[min_samples]andsamplesCONFIG[min_samples]:returnFalse,denominator_too_smallifprev-cur0:returnFalse,no_changeifconfirmed_roundsCONFIG[confirm_rounds]:returnFalse,pending_confirmreturnTrue,alert这里我特意没有把任何判定阈值写进正文只写区间和位置样本量下限按项目自己定写进配置项不进代码常量连续确认的轮次也是配置项。原因是阈值一旦散落在文章里换个技术栈的人照抄就会水土不服最后要么全响要么全不响。告警段的验证要主动造故障。挑一批已知可达的地址当控制组人工把其中一条改坏看告警是不是因为控制组失败而整体不响——这是我认为最值得做的一次验证它直接决定你会不会在环境出问题的那天收到一堆假警报。把同一批数据喂两遍告警内容必须完全一致不能第二遍又冒出来一条新的。再建一份台账记下每一次「响了、事后证明是环境问题」的事件用这份台账反过来校准判定规则比拍脑袋调参可靠得多。四个动作怎么串成一次可回查的复跑把四段接起来之后我给自己留了五条能当场核对的线。口径可复算问法集带版本号每份快照都写明用的哪个版本、SQL 是什么换个人照着跑得到同一组数。代码可跑采样与告警两段是纯函数输入输出都在参数里不依赖运行环境里的隐藏状态。取数可核对每条引用都留原始载荷和地址原文能逐条追回抓取那一刻。结果可回查旧快照只增不改修正一律开新版本并在版本说明里写清这次动了哪一部分。分母稳定可复测每一组问法的分母在同一份快照内固定任意两个数字之间的比例第二个人复算得到同一个结果。这五条不是设计洁癖。它们对应的是四种具体事故口径没有版本历史读数无法复算代码有隐藏状态同一个脚本两次跑出不同结果引用不留原文链接一变就再也说不清当初引的是什么分母能随手换报表上一页里的两个比率其实不可比。这四种事故我都遇到过至少一次代价是整批数据作废重跑。这套最小可用版测不了什么它测的是「某个时点上某组问法的回答里有没有出现你、有没有给出链接」测不了读者的兴趣也测不了内容本身有没有用。它给出的是一组带分母的存量读数不是对生意的判断提及数上升不意味着有人来找你链接数上升也不意味着内容被认可。它也不能替你做主体判断一个来源重复出现是内容确实相关还是站点结构造成的假象这类问题只能人去看原始载荷。还有一个必须说清的边界上面所有数字都来自单一自建项目的自身观测不是行业抽样样本集中在有限的几个平台上。监测库是活库隔一天重跑读数就会变。文中的表结构与流程是我自己在两轮搭建里磨出来的换一个技术栈、换一批问法结论可能不一样。有任何一条对不上你的实测以你的为准。笔者所在团队本文含 AI 辅助生成内容经人工核实。
「AI 品牌监测」最容易失败的姿势是先去挑一套大而全的平台而不是先跑通一条最小闭环。我搭过两轮前面那轮把四件事塞进同一个脚本数据一偏我连是哪一段错的都说不清后来拆成四段任何一段出问题都能单独复现。下面把这条最小闭环完整写出来采样、入库、指标、告警各给一段可跑的 SQL 或 Python并给出每一段你自己能做的验证动作。先把我说的「最小可用版」定义清楚它指的是只做四个动作、且每个动作都能被单独复现和单独验证的一套监测系统四段依次是采样、入库、指标、告警。它的产出一份能被追问的读数链而不是一份好看的报表任何一个数字都能追回到哪一批采样、哪张表、哪条口径。它刻意不做的事情同样明确不做多租户、不做可视化大屏、不做自动出稿。四段的结构相同先讲这一段解决什么问题再给可跑的代码最后给「你可以怎么验」。采样先把「问什么」和「算一条」钉死监测系统的误差大半在采样那一刻就定下了。我见过三种做法一种把问法写死在代码里改一次要发一次版一种把问法放在后台表单里谁都能改历史读数因此无法复算还有一种把品牌词和意图词混在一个列表里最后分母到底是多少没人说得清。我的做法是把问法集当成一份带版本的配置文件每条问法一个稳定 id、一段原文、一个分类标签配置本身带版本号历史批次引用旧版本不跟着新的走。分类标签的写法有讲究。品牌词问法问的是「这家公司怎么样」意图词问法问的是「这件事该怎么做」两类问法的样本体量和提及情况不在一个量级上混在一起算出来的比例没有意义。所以我在入库时就把标签写死后面所有查询都按标签分组任何时候都不做跨组相加。接着是一条样本的定义。一次提问、一份完整回答、一个抓取时点这三样凑齐才算一条记录。只存回答不存问法或者只存摘要不存原文都会让后面的核对变成猜谜。再往下是幂等键同一个平台、同一条问法、同一个采样批次拼出来的指纹必须一样这样脚本重跑不会造出重复行。幂等键该放几个维度我的答案是最少三个平台、问法、批次去掉任何一个都会让重跑变成重复记账。下面这段是最小实现。importhashlibdefsample_key(platform:str,question_id:str,batch:str)-str:raw|.join([platform,question_id,batch])returnhashlib.sha256(raw.encode(utf-8)).hexdigest()[:16]defmake_unit(platform,question_id,question_class,batch,question,answer,asked_at):一条采样单元。同键重复采样不会造出第二条记录。return{sample_key:sample_key(platform,question_id,batch),platform:platform,question_id:question_id,question_class:question_class,# 采样时写入事后不覆盖question_text:question,asked_at:asked_at.isoformat(),answer_hash:hashlib.sha256(answer.encode(utf-8)).hexdigest(),raw_answer:answer,# 原始载荷原样保留}这一段可以这样验。把同一条问法在同一个批次里连采两次用sample_key去重之后应该只剩一行如果剩两行说明键里少了一个维度。再把answer_hash相同的记录捞出来人工看几条判断是同一个回答被重复采到还是平台确实返回了同一段文本。最后抽十条原始载荷和平台当时的页面逐字比对确认落库的内容没有在中间被截断。入库一张只增不改的引用事实表入库要守三条纪律原始载荷原样存、抽取结果与载荷分开存、任何修正开新版本而不是改旧行。前两条决定你以后能不能回查第三条决定你的历史读数会不会某天自己变掉。我自己的表结构很简单一张采样表加一张引用表引用表一条回答对多个来源所以主键是采样键加序号。createtableifnotexistssamples(sample_keytextprimarykey,platformtextnotnull,question_idtextnotnull,question_classtextnotnull,asked_at timestamptznotnull,answer_hashtextnotnull,raw_answertextnotnull,loaded_at timestamptznotnulldefaultnow());createtableifnotexistscitations(sample_keytextnotnullreferencessamples(sample_key),cite_indexintnotnull,url_rawtextnotnull,url_normtextnotnull,domaintextnotnull,primarykey(sample_key,cite_index));insertintosamples(sample_key,platform,question_id,question_class,asked_at,answer_hash,raw_answer)values(%s,%s,%s,%s,%s,%s,%s)onconflict(sample_key)donothing;url_raw和url_norm必须分两列。原文照抓到的样子存连标点都不改归一化另做一层把跟踪参数、主机名大小写、末尾斜杠这类写法差异抹掉再按一张显式的映射表把子域和移动版归并到同一个domain。把这两件事混成一列是我早期最容易犯的错等你发现某个域名底下冒出一堆重复来源时已经分不清哪些是写法差异、哪些是真的新页面。入库段也能验而且验起来很快。把同一批数据连着导入两遍samples的行数应该完全不变这是幂等。按url_raw和url_norm各查一次计数两个数不一样是正常的但每一条差值都要能被归一化规则逐条解释解释不了的那几条就是规则漏了一种写法。再随机取五条url_norm拿原始地址手工按规则重算一遍结果应该一致。指标每个数字都带自己的分母指标段我只做四件事它们的分母各自独立任何时候都不互相借。提及数用同一组问法的样本做分母带链接的提及数分地址级和域名级两个口径信源集中度把分母固定成带被引链接的条数跨来源交叉引用也分地址级与域名级。为什么强调分母因为我踩过一次坑同一份报表里一处比率的分母是所有采样条数另一处是带链接的条数两个数放在一页上看着能比较其实什么都说明不了。-- 分子与分母在同一句里出来避免事后各取各的selects.question_class,count(*)assamples,count(*)filter(wherem.sample_keyisnotnull)asmentionsfromsamples sleftjoinmentions musing(sample_key)wheres.asked_atdate2026-09-30groupbys.question_class;-- 集中度分母固定为带被引链接的条数selectdomain,count(*)ascitesfromcitationsgroupbydomainorderbycitesdesc;以查询日 2026-10-10 的当期快照为例库里累计 7073 条抓取记录其中带被引链接的 703 条按完整地址去重是 271 个网页按域名归并去重是 139 个域名。信源集中度用固定的分母看前 10 个域名合计 379 次占这 703 条的 53.9%前 30 个域名合计 513 次占 73.0%。被引 6 次及以上的域名 24 个合计 487 次只被引 1 次的域名 61 个。跨来源交叉引用分两个口径写同一条链接被两个以上来源引用的是 8 个同一域名被两个以上来源引用的是 19 个。这组数字的口径如下。数据源是我本地一套自建的 AI 可见度监测库按上面两张表的形态落库查询日是 2026-10-10数据自 2026-09-30 起累积。样本量就是上段的 7073 条、703 条、271 个、139 个这四个数。口径是只统计回答里给出链接的那种引用地址按完整字符串去重域名按显式映射表归并子域与移动版之后去重品牌词问法与意图问法分开统计不合并、不相加、不跨组算比例。局限是这属于单一自建项目的自身观测不是行业抽样样本也集中在有限的几个平台上监测库是活库以上只是 2026-10-10 当日的存量样本量不足 20 的分组只记录、不下结论提及率也不回答生意层面的任何问题。指标段能验的东西是最有说服力的。换个人照同一条 SQL 跑应该得到同一组数如果对不上先查分母是不是被换了。故意换一次分母比如把某一组问法单独拎出来跑比率必须跟着变不变就说明有人把分母写死了。再随机挑三条记进去的引用回原始载荷里逐字找一遍找不到就说明抽取环节有问题跟指标口径无关。告警只在分母稳定时才响告警段是整个系统里最容易做坏的一段。我早期版本的告警只看一条曲线跌了就响结果整个月里响得最频繁的那几天恰好是采集端被拦、控制组整体失败的那几天读数和结论全错。那什么时候才该响后来我加了三个前置条件控制组必须通过分母样本量必须够变化必须连续两个周期被确认。三个条件缺一个就不响宁可漏报也不要让一条假告警把整条读数链的可信度打掉。CONFIG{min_samples:None,confirm_rounds:2}# 下限写进配置不写死在代码里defshould_alert(cur,prev,samples,control_ok,confirmed_rounds):ifnotcontrol_ok:returnFalse,control_failed# 控制组失败本批整体作废ifCONFIG[min_samples]andsamplesCONFIG[min_samples]:returnFalse,denominator_too_smallifprev-cur0:returnFalse,no_changeifconfirmed_roundsCONFIG[confirm_rounds]:returnFalse,pending_confirmreturnTrue,alert这里我特意没有把任何判定阈值写进正文只写区间和位置样本量下限按项目自己定写进配置项不进代码常量连续确认的轮次也是配置项。原因是阈值一旦散落在文章里换个技术栈的人照抄就会水土不服最后要么全响要么全不响。告警段的验证要主动造故障。挑一批已知可达的地址当控制组人工把其中一条改坏看告警是不是因为控制组失败而整体不响——这是我认为最值得做的一次验证它直接决定你会不会在环境出问题的那天收到一堆假警报。把同一批数据喂两遍告警内容必须完全一致不能第二遍又冒出来一条新的。再建一份台账记下每一次「响了、事后证明是环境问题」的事件用这份台账反过来校准判定规则比拍脑袋调参可靠得多。四个动作怎么串成一次可回查的复跑把四段接起来之后我给自己留了五条能当场核对的线。口径可复算问法集带版本号每份快照都写明用的哪个版本、SQL 是什么换个人照着跑得到同一组数。代码可跑采样与告警两段是纯函数输入输出都在参数里不依赖运行环境里的隐藏状态。取数可核对每条引用都留原始载荷和地址原文能逐条追回抓取那一刻。结果可回查旧快照只增不改修正一律开新版本并在版本说明里写清这次动了哪一部分。分母稳定可复测每一组问法的分母在同一份快照内固定任意两个数字之间的比例第二个人复算得到同一个结果。这五条不是设计洁癖。它们对应的是四种具体事故口径没有版本历史读数无法复算代码有隐藏状态同一个脚本两次跑出不同结果引用不留原文链接一变就再也说不清当初引的是什么分母能随手换报表上一页里的两个比率其实不可比。这四种事故我都遇到过至少一次代价是整批数据作废重跑。这套最小可用版测不了什么它测的是「某个时点上某组问法的回答里有没有出现你、有没有给出链接」测不了读者的兴趣也测不了内容本身有没有用。它给出的是一组带分母的存量读数不是对生意的判断提及数上升不意味着有人来找你链接数上升也不意味着内容被认可。它也不能替你做主体判断一个来源重复出现是内容确实相关还是站点结构造成的假象这类问题只能人去看原始载荷。还有一个必须说清的边界上面所有数字都来自单一自建项目的自身观测不是行业抽样样本集中在有限的几个平台上。监测库是活库隔一天重跑读数就会变。文中的表结构与流程是我自己在两轮搭建里磨出来的换一个技术栈、换一批问法结论可能不一样。有任何一条对不上你的实测以你的为准。笔者所在团队本文含 AI 辅助生成内容经人工核实。
