最近一直在做一件很有意思的事盯着豆包、DeepSeek 这类 AI APP看它们在回答用户问题时到底会不会主动提起我们的品牌词。你可能觉得这不就是“舆情监控”嘛但实际做下来才发现它和传统舆情完全不是一回事——用户不会把自己的对话内容发到网上AI 也不会给你一份“推荐了哪些品牌”的报表。想拿到这个数据只能靠我们自己去“问”它。这篇文章就聊聊我们如何把这件事做成一套自动化运维系统覆盖整体思路、数据采集、判定逻辑、定时调度、可视化展示和踩坑实录。如果你在品牌团队、增长团队或者自动化运维岗位需要量化“AI 应用里有多少比例的回答提到了自己的品牌”那这套方案可以直接抄作业。1. 品牌词采纳率监控到底在监控什么1.1 从一次“AI 推荐翻车”说起事情起因是某公司发现一个奇怪现象用户在 AI 应用里问“有什么好用的在线文档工具”AI 一口气推荐了好几款产品唯独没提该公司自家产品。一线销售反馈说用户现在做购买决策前都会先去问一遍 AI如果 AI 始终不推荐自家品牌销售聊得再多也白搭。这个现象背后藏着一个量化指标品牌词采纳率。定义很简单一段时间内AI 应用在回答中主动提及目标品牌词的次数除以有效的提问样本总数。比如我们设计了 20 个模拟用户问题如果 AI 回答里有 8 次提到了目标品牌词那当天采纳率就是 40%。但问题来了这个指标不像网页搜索排名那样有现成工具可查AI 应用没有提供“品牌曝光报告”也不会告诉你它内部的推荐逻辑。唯一的办法就是我们主动去提问、去触发、去记录再用一套自动化流程把散落的对话数据处理成可阅读的趋势图表。这就是整个项目的出发点。1.2 为什么传统舆情监控不够用传统舆情监控干的是另一件事抓取新闻、社媒帖子、评论区的内容看用户怎么说你。这套体系对公开内容有效但对 AI 对话场景基本失效原因有三个第一AI 对话是私密的一对一交互不会被搜索引擎收录也不会被爬虫抓取。第二即使你能抓到部分对话内容也拿不到完整上下文很难判断品牌词是“被推荐了”还是“被吐槽了”。第三用户问法千差万别同一个品牌词在不同对话里可能被缩写、被同义替代甚至被翻译成英文传统关键词监控根本覆盖不全。所以我们需要的是一套“主动探测系统”自己设计问题、自己发起对话、自己解析回答把 AI 应用当作一个黑盒来反复测试最后把测试结果汇总成监控报表。这和接口监控、拨测监控的思路非常相似只是被探测的对象从服务器变成了 AI 应用。1.3 监控指标怎么定义才科学很多团队上来就只统计一个“有没有提到品牌词”实测下来会漏掉大量信息。我在落地时把指标拆成了三层第一层是基础采纳率就是命中品牌词的样本数除以总样本数这个指标用于看大盘趋势。第二层是表现形式差异记录品牌词是以什么形态出现的。有的 AI 回答用全称有的用简称有的用“某家的产品”这种模糊指代。不同的表述方式会影响用户感知需要单独跟踪。比如某产品全称叫“某某智能助手”但 AI 回复里只出现“某某助手”这类简称命中也要算一种形态至少说明模型对品牌有记忆。第三层是推荐倾向光“提到”还不够还要判断是被正面推荐、负面评价还是中性提及。一个回答里写着“某品牌不太好用但是生态完善”你把它算作采纳就会失真。所以在判定环节我会先把回答分成“明确推荐”“折中提及”“负面评价”三个类型分类统计最后再合成一个加权采纳率。这三层指标设计是整个监控体系的底层逻辑。后面所有代码、流程、可视化都是围绕这些口径展开的。2. 整体方案设计一条从探测到展示的数据链路2.1 技术选型背后的取舍逻辑选型前先明确了几个约束团队里主要用 Python数据量每天几千条对话记录不想为了一个监控项目专门搭大数据平台且需要一个方便业务方每天看的可视化看板。基于这些约束技术栈定为Python 作为主力开发语言负责所有采集和判定逻辑存储先用 SQLite单表几万条记录完全没问题后续数据量上来再平滑迁移到 PostgreSQL可视化直接用 Grafana接 SQLite 数据源画趋势图和告警规则都够用。有同学可能会问为什么不直接上 Elasticsearch 或者 ClickHouse因为品牌词采纳率监控本质上是低基数的小数据量场景每天几千条记录Elasticsearch 反而增加了运维复杂度。SQLite 单文件部署定时任务写库后 Grafana 直接读取整条链路三个组件就能跑通出了问题也好排查。另外一个核心选择是采集方式。目前主流 AI 应用有两类接口一类提供了公开 API你可以直接调用对话接口返回结构化数据解析成本最低另一类没有开放 API只有 Web 端聊天界面这时候只能用自动化浏览器模拟用户输入从页面上抓取回答。两种方式我都实测过后面会分别说明适用场景和坑点。2.2 数据采集的两种方式及选型建议先讲 API 直连模式。优点是稳定、速度快、响应内容是纯文本不需要处理页面 DOM缺点是部分产品不开放 API或者免费额度有限。我在对接某款 AI 应用时官方 API 文档写得还算清楚但接口地址、鉴权方式各不相同需要花半天时间逐个适配。这个阶段最大的成本不是写代码而是读文档和处理各家鉴权差异。再讲自动化浏览器模式。我用的是 Playwright它能模拟完整浏览器行为打开网页、输入问题、点击发送、等待回答、然后截取页面文本。这套方案的通用性很强任何有 Web 界面的 AI 应用都能接入不用等官方开放 API缺点是速度慢、资源占用高而且一旦页面改版selector 就全失效了。实际选型时我的建议是先查官方 API有就直接用没有 API 再用 Playwright 兜底。千万不要一上来就全量做浏览器自动化维护成本会拖垮整个项目。2.3 提问模板与探测策略探测效果好不好一半取决于问题怎么设计。我们不会只用一句“你推荐什么产品”反复问那样模型会记住你的固定模式结果越跑越失真。我设计了四类问题模板覆盖不同类型用户的真实问法直接推荐型“推荐几个好用的在线协作工具要求支持多人实时编辑。”对比选择型“A 产品和 B 产品哪个更适合初创团队请从价格和功能两方面对比。”功能寻找型“我想找一个能自动生成会议纪要的工具最好还能和日历联动。”负面排除型“有哪些文字识别工具是比较坑的我想避开它们。”每一类下面准备了 5 到 8 个具体问题全部存入一个问题池。每次运行时从问题池里随机抽取 6 到 8 个问题分别发给各 AI 应用。这样做有两个原因一是避免同一批问题反复出现导致模型输出记忆偏移二是尽量模拟真实用户多样化的提问方式让采纳率统计更有代表性。提问过程中还要保留完整上下文。AI 回答是流式的有些品牌词可能在中间段落出现有些在最后总结里才出现。我要求采集模块把每次回答的全文都存下来不截断、不预处理方便后面判定模块做二次分析。3. 实操过程与核心环节实现3.1 搭建基础采集框架整个项目我按模块拆成四层probe探测、judge判定、store存储、scheduler调度。目录结构大致是这样brand_monitor/ ├── probe/ │ ├── api_probe.py # API 直连模式采集 │ └── browser_probe.py # Playwright 浏览器模式采集 ├── judge/ │ ├── text_clean.py # 文本清洗 │ ├── rule_match.py # 规则匹配 │ └── semantic_judge.py # 语义判定兜底 ├── store/ │ ├── sqlite_store.py # 入库逻辑 │ └── migrate.py # 建表与迁移 ├── scheduler.py # 定时调度 ├── config.yaml # 品牌词表、问题池、API 配置 └── main.py # 入口probe 模块是整个系统的输入源头。先定义统一的数据结构每次探测返回一个包含时间、AI 应用名、问题、原始回答的字典后续所有模块只认这个结构无论你用的是 API 模式还是浏览器模式。# probe/probe_result.py dataclass class ProbeResult: app_name: str # 豆包/DeepSeek/其他 question: str # 本次提问原文 answer: str # AI 回答全文 raw_metadata: dict # 扩展字段如请求耗时、token 数 probe_time: str # 探测时间抓到的原始回答绝不直接入库先经过 judge 模块判定再连同判定结果一起写库。这样后面如果判定规则调整可以从库里捞出原始文本重新跑一遍不用重新探测。3.2 判定逻辑从“提到了”到“真的推荐了”判定模块是准确率的关键。我们走了三步清洗、规则匹配、语义兜底。第一步是文本清洗。AI 回答里经常带 Markdown 标记、列表符号、多余空行还有“根据我的了解”“目前市面上”这类套话。清洗阶段把这些信息去掉保留下纯粹的品牌相关表述。第二步是规则匹配。这里要建一个品牌词表除了品牌名本身还要包含常见的简称、英文缩写和易错写法。比如品牌名是“星光笔记”那词表里要加“星光”“xingguang”“星光笔记app”等形式。匹配时先做大小写归一化、全半角归一化再用 Python 的正则或者简单的子串匹配。# judge/rule_match.py import re BRAND_TERMS [ r星光笔记, r星光助手, rxingguang, r星光 ] def clean_text(raw: str) - str: text raw.lower() text re.sub(r#{1,6}\s*, , text) # 去掉 markdown 标题 text re.sub(r\*{1,2}([^*])\*{1,2}, r\1, text) # 去掉加粗 text re.sub(r([^]), r\1, text) # 去掉行内代码 text re.sub(r\s, , text) return text.strip() def match_brand(text: str) - dict: hits [] for term in BRAND_TERMS: if re.search(term, text): hits.append(term) return { hit: len(hits) 0, hit_terms: list(set(hits)) }规则匹配速度最快能覆盖 80% 以上的场景。但它的局限也很明显品牌词可能被改写成“一个叫星光的工具”“最近很火的那款笔记软件”规则就失效了。所以第三步用语义相似度做兜底。这里我用了一个轻量方案把品牌名和回答文本分别做向量化计算余弦相似度超过阈值就判定为“疑似提及”。向量化模型没有用太大的一个本地跑得动的中文 embedding 模型就够。判断不了的就打标签“need_review”人工复核一批之后把结果回流到规则库不断增补词表。三段式判定下来准确率能到 95% 以上偶尔有误判也会集中在模糊指代上不影响大盘趋势。3.3 统计口径与置信度计算采集和判定都跑通之后下一个问题就是如何从一批样本算出可信的采纳率。当天采纳率的公式是采纳率 命中品牌词的样本数 / 有效样本数。但这里有个坑如果当天只跑了 5 个问题中了 2 个你能说采纳率是 40% 吗样本量太小这个数字没有统计意义。为了回答“至少跑多少个问题才算数”我用二项分布的置信区间来算。假设真实采纳率是 20%要让它和 25% 区分开需要多少样本按 95% 置信度推算公式为 n (z^2 * p * (1-p)) / d^2其中 z1.96p0.2d0.05。代入后是 n (1.96^2 * 0.2 * 0.8) / 0.05^2大约等于 245.86所以最少要采集 250 个有效样本。实际操作中我就按这个逻辑配置每天的探测量。单家 AI 应用每天至少 300 个问题周六日也不停这样算出的采纳率才敢拿到周会上讲。需要补充一句这里所说的“有效样本”指的是 AI 成功返回了完整回答的样本。遇到超时、空回复、内容审核拦截的情况一律剔除出统计不计入分母。3.4 定时调度与数据可视化调度层面用了 APScheduler每天凌晨 2 点启动当天的探测任务这个时间点 API 压力小而且不会影响业务高峰。# scheduler.py from apscheduler.schedulers.blocking import BlockingScheduler def run_daily(): # 1. 随机抽取当日问题池 # 2. 调用 probe 采集 # 3. 调用 judge 判定 # 4. 落库 pass scheduler BlockingScheduler(timezoneAsia/Shanghai) scheduler.add_job(run_daily, cron, hour2, minute0, idbrand_probe) scheduler.start()这里有一个很容易踩的坑任务堆叠。默认 APScheduler 在任务执行时间超过调度间隔时不会重复触发但如果你手动触发补跑就可能和定时任务撞车。我的解决办法是在任务开头用 SQLite 建一个 job_lock 表记录当天是否已跑过已跑过就跳过保证一天最多跑一次。数据入库后可视化就简单了。Grafana 接 SQLite 数据源建一个趋势图横轴是日期纵轴是采纳率按 AI 应用分系列展示。再建一个表格图展示最近 7 天各品牌词命中率排名。SQL 大致长这样SELECT date(probe_time) AS day, app_name, ROUND(100.0 * SUM(hit) / COUNT(*), 2) AS adoption_rate FROM probe_records WHERE date(probe_time) date(now, -7 day) GROUP BY day, app_name ORDER BY day ASC;看板配好之后我把地址丢给品牌团队他们每天自己点开看不需要我出一份 PPT。这套东西之所以能跑起来核心就是降低了使用门槛业务方不用看 Python 代码打开浏览器就知道趋势怎么样。3.5 告警规则设计只看趋势还不够异常要及时感知。我们在 Grafana 里配了两条告警规则。第一条是掉零告警如果某家 AI 应用连续三天采纳率为 0触发 alert说明 AI 可能把你的品牌词彻底遗忘了需要人工介入排查。第二条是突降告警当日采纳率比前 7 天均值下降超过 30% 时触发这种情况通常意味着 AI 应用更新了模型或调整了推荐策略。告警渠道用了企业 IM 机器人直接把消息推到品牌群里相关同事第一时间能看到。实测下来掉零告警最有价值。因为采纳率突变大概率有真实原因——要么品牌词表该更新了要么模型版本换了两条原因背后的处理逻辑完全不同人工介入越早越好。4. 常见问题与排查技巧实录4.1 多次采样结果不一致怎么办AI 生成本身有随机性。同一个问题问十次可能八次提到品牌词两次不提所以单个样本的命中与否没有绝对意义。我们不去追求单次判定百分百准确而是用多次采样均值加置信区间来判断整体趋势。在周会上展示数据时我会把样本量和置信区间一起展示让决策者明白 40% 的采纳率背后有 400 个有效样本支撑而不是靠 10 个样本猜出来的。4.2 API 限流和并发冲突不同 AI 应用的 API 限流策略差别很大。有的按分钟限制 60 次请求有的按并发数限制 5 个。一上来就把并发开到 10 个线程很容易触发 429 限流导致大面积采集失败。我的做法是先在配置里给每个应用单独设置 max_concurrency 和 retry 参数。请求失败时用指数退避重试第一次等 2 秒第二次 4 秒第三次 8 秒最多重试 3 次。对面有 429 响应头的严格按照 Retry-After 字段等待。import time import random def request_with_retry(func, retries3): delay 2 for attempt in range(retries): try: return func() except RateLimitError: time.sleep(delay random.uniform(0, 1)) delay * 2 raise ProbeFailedError(retries exhausted)4.3 判定误报和漏报误报往往出在“品牌词也是通用词”的场景。举例来说如果你的品牌词带“云”字那 AI 回答里大量出现“云端”“多云”也会被匹配命中采纳率直接虚高。后来我在规则匹配里加了一层上下文窗口品牌词前后各取 10 个字符如果上下文窗口出现“不是”“不建议”“缺点是”等负面词就把这条标为负面提及单独统计不进采纳数。漏报则主要因为品牌词写法太多样。AI 有时会直接说“一款笔记应用”而不点名这属于逻辑上无法靠文本规则识别的类别。我的处理是把这类漏报记录到 unreviewed 表里每周人工抽查把确认是品牌指代的表达方式补充进词表。4.4 定时任务堆叠导致数据延迟这是一个典型的运维问题。某天凌晨探测脚本因为 AI 应用 API 超时多跑了一个小时早晨 8 点同事补跑结果和当天凌晨任务叠加数据库里出现重复记录当天的采纳率分母直接翻倍图表上出现一个明显异常的凹陷。排查后发现问题不在数据格式而在调度设计。后来加了两层防护第一层在 scheduler 入口检查任务锁同一个日期只允许一个任务运行第二层在 SQLite 表里对 (probe_time, app_name, question) 加唯一索引重复写入直接插入失败。CREATE UNIQUE INDEX idx_probe_unique ON probe_records (probe_time, app_name, question);加上唯一索引之后重复问题再也没出现过。4.5 浏览器模式卡死用 Playwright 跑浏览器自动化时经常遇到页面加载超时、弹窗遮挡、点击无响应这类问题。最麻烦的是无头模式跑久了容易内存泄漏任务跑第 50 个问题就开始崩溃。一般的处理思路是设置每个步骤的显式等待时长不要依赖隐式等待。还有一个很有效的技巧每处理完 20 个问题就重启一次浏览器上下文释放内存。实测把任务吞吐量从 200 条提升到 800 条不崩溃。如果后续还要处理更大量的浏览器采集建议把采集任务做成横向扩展多开几个容器分摊压力。5. 我踩过坑之后的一些体会整个项目从立项到第一条可用看板上线大概花了两周时间。真正耗时的不是写代码而是和几家 AI 应用逐一适配采集方式以及不断调整问题池让数据波动变小。回过头看有三件事如果再来一次我会更早做。第一问题池要提前设计好并冻结。我们前期频繁修改问题池导致前后两批数据口径不一致采纳率对比没有参考价值。建议第一次建池后就定一个“冻结日期”之后只增不删新增问题单独标记这样历史趋势才是对齐的。第二原始回答必须留痕。之前为了省数据库空间只存判定结果不存原文后来要调整判定规则时发现无据可查。现在我的表结构里一定保留 answer 字段哪怕看起来很占空间它换来的是你随时能回溯、能复核、能重新判定的能力。第三把异常当常态来设计。API 超时、限流、页面改版都不是偶发事件而是必然事件。代码里每个外部依赖都要有兜底逻辑调度任务要支持失败重跑且不产生重复数据。这套系统能稳定跑几个月靠的不是某个聪明的算法而是这些不起眼的防御性设计。如果你也想搭一套 AI 品牌词采纳率监控别一上来就铺大而全的平台先用 SQLite 加 Python 脚本跑通单日流程再慢慢加可视化。跑出第一张趋势图的那一天你会觉得这活儿从一开始就没白折腾。 
长河君 · 2026/10/22 5:16:54 · 阅读 1.2k AI品牌词采纳率监控系统：从数据采集到可视化落地方案
最近一直在做一件很有意思的事盯着豆包、DeepSeek 这类 AI APP看它们在回答用户问题时到底会不会主动提起我们的品牌词。你可能觉得这不就是“舆情监控”嘛但实际做下来才发现它和传统舆情完全不是一回事——用户不会把自己的对话内容发到网上AI 也不会给你一份“推荐了哪些品牌”的报表。想拿到这个数据只能靠我们自己去“问”它。这篇文章就聊聊我们如何把这件事做成一套自动化运维系统覆盖整体思路、数据采集、判定逻辑、定时调度、可视化展示和踩坑实录。如果你在品牌团队、增长团队或者自动化运维岗位需要量化“AI 应用里有多少比例的回答提到了自己的品牌”那这套方案可以直接抄作业。1. 品牌词采纳率监控到底在监控什么1.1 从一次“AI 推荐翻车”说起事情起因是某公司发现一个奇怪现象用户在 AI 应用里问“有什么好用的在线文档工具”AI 一口气推荐了好几款产品唯独没提该公司自家产品。一线销售反馈说用户现在做购买决策前都会先去问一遍 AI如果 AI 始终不推荐自家品牌销售聊得再多也白搭。这个现象背后藏着一个量化指标品牌词采纳率。定义很简单一段时间内AI 应用在回答中主动提及目标品牌词的次数除以有效的提问样本总数。比如我们设计了 20 个模拟用户问题如果 AI 回答里有 8 次提到了目标品牌词那当天采纳率就是 40%。但问题来了这个指标不像网页搜索排名那样有现成工具可查AI 应用没有提供“品牌曝光报告”也不会告诉你它内部的推荐逻辑。唯一的办法就是我们主动去提问、去触发、去记录再用一套自动化流程把散落的对话数据处理成可阅读的趋势图表。这就是整个项目的出发点。1.2 为什么传统舆情监控不够用传统舆情监控干的是另一件事抓取新闻、社媒帖子、评论区的内容看用户怎么说你。这套体系对公开内容有效但对 AI 对话场景基本失效原因有三个第一AI 对话是私密的一对一交互不会被搜索引擎收录也不会被爬虫抓取。第二即使你能抓到部分对话内容也拿不到完整上下文很难判断品牌词是“被推荐了”还是“被吐槽了”。第三用户问法千差万别同一个品牌词在不同对话里可能被缩写、被同义替代甚至被翻译成英文传统关键词监控根本覆盖不全。所以我们需要的是一套“主动探测系统”自己设计问题、自己发起对话、自己解析回答把 AI 应用当作一个黑盒来反复测试最后把测试结果汇总成监控报表。这和接口监控、拨测监控的思路非常相似只是被探测的对象从服务器变成了 AI 应用。1.3 监控指标怎么定义才科学很多团队上来就只统计一个“有没有提到品牌词”实测下来会漏掉大量信息。我在落地时把指标拆成了三层第一层是基础采纳率就是命中品牌词的样本数除以总样本数这个指标用于看大盘趋势。第二层是表现形式差异记录品牌词是以什么形态出现的。有的 AI 回答用全称有的用简称有的用“某家的产品”这种模糊指代。不同的表述方式会影响用户感知需要单独跟踪。比如某产品全称叫“某某智能助手”但 AI 回复里只出现“某某助手”这类简称命中也要算一种形态至少说明模型对品牌有记忆。第三层是推荐倾向光“提到”还不够还要判断是被正面推荐、负面评价还是中性提及。一个回答里写着“某品牌不太好用但是生态完善”你把它算作采纳就会失真。所以在判定环节我会先把回答分成“明确推荐”“折中提及”“负面评价”三个类型分类统计最后再合成一个加权采纳率。这三层指标设计是整个监控体系的底层逻辑。后面所有代码、流程、可视化都是围绕这些口径展开的。2. 整体方案设计一条从探测到展示的数据链路2.1 技术选型背后的取舍逻辑选型前先明确了几个约束团队里主要用 Python数据量每天几千条对话记录不想为了一个监控项目专门搭大数据平台且需要一个方便业务方每天看的可视化看板。基于这些约束技术栈定为Python 作为主力开发语言负责所有采集和判定逻辑存储先用 SQLite单表几万条记录完全没问题后续数据量上来再平滑迁移到 PostgreSQL可视化直接用 Grafana接 SQLite 数据源画趋势图和告警规则都够用。有同学可能会问为什么不直接上 Elasticsearch 或者 ClickHouse因为品牌词采纳率监控本质上是低基数的小数据量场景每天几千条记录Elasticsearch 反而增加了运维复杂度。SQLite 单文件部署定时任务写库后 Grafana 直接读取整条链路三个组件就能跑通出了问题也好排查。另外一个核心选择是采集方式。目前主流 AI 应用有两类接口一类提供了公开 API你可以直接调用对话接口返回结构化数据解析成本最低另一类没有开放 API只有 Web 端聊天界面这时候只能用自动化浏览器模拟用户输入从页面上抓取回答。两种方式我都实测过后面会分别说明适用场景和坑点。2.2 数据采集的两种方式及选型建议先讲 API 直连模式。优点是稳定、速度快、响应内容是纯文本不需要处理页面 DOM缺点是部分产品不开放 API或者免费额度有限。我在对接某款 AI 应用时官方 API 文档写得还算清楚但接口地址、鉴权方式各不相同需要花半天时间逐个适配。这个阶段最大的成本不是写代码而是读文档和处理各家鉴权差异。再讲自动化浏览器模式。我用的是 Playwright它能模拟完整浏览器行为打开网页、输入问题、点击发送、等待回答、然后截取页面文本。这套方案的通用性很强任何有 Web 界面的 AI 应用都能接入不用等官方开放 API缺点是速度慢、资源占用高而且一旦页面改版selector 就全失效了。实际选型时我的建议是先查官方 API有就直接用没有 API 再用 Playwright 兜底。千万不要一上来就全量做浏览器自动化维护成本会拖垮整个项目。2.3 提问模板与探测策略探测效果好不好一半取决于问题怎么设计。我们不会只用一句“你推荐什么产品”反复问那样模型会记住你的固定模式结果越跑越失真。我设计了四类问题模板覆盖不同类型用户的真实问法直接推荐型“推荐几个好用的在线协作工具要求支持多人实时编辑。”对比选择型“A 产品和 B 产品哪个更适合初创团队请从价格和功能两方面对比。”功能寻找型“我想找一个能自动生成会议纪要的工具最好还能和日历联动。”负面排除型“有哪些文字识别工具是比较坑的我想避开它们。”每一类下面准备了 5 到 8 个具体问题全部存入一个问题池。每次运行时从问题池里随机抽取 6 到 8 个问题分别发给各 AI 应用。这样做有两个原因一是避免同一批问题反复出现导致模型输出记忆偏移二是尽量模拟真实用户多样化的提问方式让采纳率统计更有代表性。提问过程中还要保留完整上下文。AI 回答是流式的有些品牌词可能在中间段落出现有些在最后总结里才出现。我要求采集模块把每次回答的全文都存下来不截断、不预处理方便后面判定模块做二次分析。3. 实操过程与核心环节实现3.1 搭建基础采集框架整个项目我按模块拆成四层probe探测、judge判定、store存储、scheduler调度。目录结构大致是这样brand_monitor/ ├── probe/ │ ├── api_probe.py # API 直连模式采集 │ └── browser_probe.py # Playwright 浏览器模式采集 ├── judge/ │ ├── text_clean.py # 文本清洗 │ ├── rule_match.py # 规则匹配 │ └── semantic_judge.py # 语义判定兜底 ├── store/ │ ├── sqlite_store.py # 入库逻辑 │ └── migrate.py # 建表与迁移 ├── scheduler.py # 定时调度 ├── config.yaml # 品牌词表、问题池、API 配置 └── main.py # 入口probe 模块是整个系统的输入源头。先定义统一的数据结构每次探测返回一个包含时间、AI 应用名、问题、原始回答的字典后续所有模块只认这个结构无论你用的是 API 模式还是浏览器模式。# probe/probe_result.py dataclass class ProbeResult: app_name: str # 豆包/DeepSeek/其他 question: str # 本次提问原文 answer: str # AI 回答全文 raw_metadata: dict # 扩展字段如请求耗时、token 数 probe_time: str # 探测时间抓到的原始回答绝不直接入库先经过 judge 模块判定再连同判定结果一起写库。这样后面如果判定规则调整可以从库里捞出原始文本重新跑一遍不用重新探测。3.2 判定逻辑从“提到了”到“真的推荐了”判定模块是准确率的关键。我们走了三步清洗、规则匹配、语义兜底。第一步是文本清洗。AI 回答里经常带 Markdown 标记、列表符号、多余空行还有“根据我的了解”“目前市面上”这类套话。清洗阶段把这些信息去掉保留下纯粹的品牌相关表述。第二步是规则匹配。这里要建一个品牌词表除了品牌名本身还要包含常见的简称、英文缩写和易错写法。比如品牌名是“星光笔记”那词表里要加“星光”“xingguang”“星光笔记app”等形式。匹配时先做大小写归一化、全半角归一化再用 Python 的正则或者简单的子串匹配。# judge/rule_match.py import re BRAND_TERMS [ r星光笔记, r星光助手, rxingguang, r星光 ] def clean_text(raw: str) - str: text raw.lower() text re.sub(r#{1,6}\s*, , text) # 去掉 markdown 标题 text re.sub(r\*{1,2}([^*])\*{1,2}, r\1, text) # 去掉加粗 text re.sub(r([^]), r\1, text) # 去掉行内代码 text re.sub(r\s, , text) return text.strip() def match_brand(text: str) - dict: hits [] for term in BRAND_TERMS: if re.search(term, text): hits.append(term) return { hit: len(hits) 0, hit_terms: list(set(hits)) }规则匹配速度最快能覆盖 80% 以上的场景。但它的局限也很明显品牌词可能被改写成“一个叫星光的工具”“最近很火的那款笔记软件”规则就失效了。所以第三步用语义相似度做兜底。这里我用了一个轻量方案把品牌名和回答文本分别做向量化计算余弦相似度超过阈值就判定为“疑似提及”。向量化模型没有用太大的一个本地跑得动的中文 embedding 模型就够。判断不了的就打标签“need_review”人工复核一批之后把结果回流到规则库不断增补词表。三段式判定下来准确率能到 95% 以上偶尔有误判也会集中在模糊指代上不影响大盘趋势。3.3 统计口径与置信度计算采集和判定都跑通之后下一个问题就是如何从一批样本算出可信的采纳率。当天采纳率的公式是采纳率 命中品牌词的样本数 / 有效样本数。但这里有个坑如果当天只跑了 5 个问题中了 2 个你能说采纳率是 40% 吗样本量太小这个数字没有统计意义。为了回答“至少跑多少个问题才算数”我用二项分布的置信区间来算。假设真实采纳率是 20%要让它和 25% 区分开需要多少样本按 95% 置信度推算公式为 n (z^2 * p * (1-p)) / d^2其中 z1.96p0.2d0.05。代入后是 n (1.96^2 * 0.2 * 0.8) / 0.05^2大约等于 245.86所以最少要采集 250 个有效样本。实际操作中我就按这个逻辑配置每天的探测量。单家 AI 应用每天至少 300 个问题周六日也不停这样算出的采纳率才敢拿到周会上讲。需要补充一句这里所说的“有效样本”指的是 AI 成功返回了完整回答的样本。遇到超时、空回复、内容审核拦截的情况一律剔除出统计不计入分母。3.4 定时调度与数据可视化调度层面用了 APScheduler每天凌晨 2 点启动当天的探测任务这个时间点 API 压力小而且不会影响业务高峰。# scheduler.py from apscheduler.schedulers.blocking import BlockingScheduler def run_daily(): # 1. 随机抽取当日问题池 # 2. 调用 probe 采集 # 3. 调用 judge 判定 # 4. 落库 pass scheduler BlockingScheduler(timezoneAsia/Shanghai) scheduler.add_job(run_daily, cron, hour2, minute0, idbrand_probe) scheduler.start()这里有一个很容易踩的坑任务堆叠。默认 APScheduler 在任务执行时间超过调度间隔时不会重复触发但如果你手动触发补跑就可能和定时任务撞车。我的解决办法是在任务开头用 SQLite 建一个 job_lock 表记录当天是否已跑过已跑过就跳过保证一天最多跑一次。数据入库后可视化就简单了。Grafana 接 SQLite 数据源建一个趋势图横轴是日期纵轴是采纳率按 AI 应用分系列展示。再建一个表格图展示最近 7 天各品牌词命中率排名。SQL 大致长这样SELECT date(probe_time) AS day, app_name, ROUND(100.0 * SUM(hit) / COUNT(*), 2) AS adoption_rate FROM probe_records WHERE date(probe_time) date(now, -7 day) GROUP BY day, app_name ORDER BY day ASC;看板配好之后我把地址丢给品牌团队他们每天自己点开看不需要我出一份 PPT。这套东西之所以能跑起来核心就是降低了使用门槛业务方不用看 Python 代码打开浏览器就知道趋势怎么样。3.5 告警规则设计只看趋势还不够异常要及时感知。我们在 Grafana 里配了两条告警规则。第一条是掉零告警如果某家 AI 应用连续三天采纳率为 0触发 alert说明 AI 可能把你的品牌词彻底遗忘了需要人工介入排查。第二条是突降告警当日采纳率比前 7 天均值下降超过 30% 时触发这种情况通常意味着 AI 应用更新了模型或调整了推荐策略。告警渠道用了企业 IM 机器人直接把消息推到品牌群里相关同事第一时间能看到。实测下来掉零告警最有价值。因为采纳率突变大概率有真实原因——要么品牌词表该更新了要么模型版本换了两条原因背后的处理逻辑完全不同人工介入越早越好。4. 常见问题与排查技巧实录4.1 多次采样结果不一致怎么办AI 生成本身有随机性。同一个问题问十次可能八次提到品牌词两次不提所以单个样本的命中与否没有绝对意义。我们不去追求单次判定百分百准确而是用多次采样均值加置信区间来判断整体趋势。在周会上展示数据时我会把样本量和置信区间一起展示让决策者明白 40% 的采纳率背后有 400 个有效样本支撑而不是靠 10 个样本猜出来的。4.2 API 限流和并发冲突不同 AI 应用的 API 限流策略差别很大。有的按分钟限制 60 次请求有的按并发数限制 5 个。一上来就把并发开到 10 个线程很容易触发 429 限流导致大面积采集失败。我的做法是先在配置里给每个应用单独设置 max_concurrency 和 retry 参数。请求失败时用指数退避重试第一次等 2 秒第二次 4 秒第三次 8 秒最多重试 3 次。对面有 429 响应头的严格按照 Retry-After 字段等待。import time import random def request_with_retry(func, retries3): delay 2 for attempt in range(retries): try: return func() except RateLimitError: time.sleep(delay random.uniform(0, 1)) delay * 2 raise ProbeFailedError(retries exhausted)4.3 判定误报和漏报误报往往出在“品牌词也是通用词”的场景。举例来说如果你的品牌词带“云”字那 AI 回答里大量出现“云端”“多云”也会被匹配命中采纳率直接虚高。后来我在规则匹配里加了一层上下文窗口品牌词前后各取 10 个字符如果上下文窗口出现“不是”“不建议”“缺点是”等负面词就把这条标为负面提及单独统计不进采纳数。漏报则主要因为品牌词写法太多样。AI 有时会直接说“一款笔记应用”而不点名这属于逻辑上无法靠文本规则识别的类别。我的处理是把这类漏报记录到 unreviewed 表里每周人工抽查把确认是品牌指代的表达方式补充进词表。4.4 定时任务堆叠导致数据延迟这是一个典型的运维问题。某天凌晨探测脚本因为 AI 应用 API 超时多跑了一个小时早晨 8 点同事补跑结果和当天凌晨任务叠加数据库里出现重复记录当天的采纳率分母直接翻倍图表上出现一个明显异常的凹陷。排查后发现问题不在数据格式而在调度设计。后来加了两层防护第一层在 scheduler 入口检查任务锁同一个日期只允许一个任务运行第二层在 SQLite 表里对 (probe_time, app_name, question) 加唯一索引重复写入直接插入失败。CREATE UNIQUE INDEX idx_probe_unique ON probe_records (probe_time, app_name, question);加上唯一索引之后重复问题再也没出现过。4.5 浏览器模式卡死用 Playwright 跑浏览器自动化时经常遇到页面加载超时、弹窗遮挡、点击无响应这类问题。最麻烦的是无头模式跑久了容易内存泄漏任务跑第 50 个问题就开始崩溃。一般的处理思路是设置每个步骤的显式等待时长不要依赖隐式等待。还有一个很有效的技巧每处理完 20 个问题就重启一次浏览器上下文释放内存。实测把任务吞吐量从 200 条提升到 800 条不崩溃。如果后续还要处理更大量的浏览器采集建议把采集任务做成横向扩展多开几个容器分摊压力。5. 我踩过坑之后的一些体会整个项目从立项到第一条可用看板上线大概花了两周时间。真正耗时的不是写代码而是和几家 AI 应用逐一适配采集方式以及不断调整问题池让数据波动变小。回过头看有三件事如果再来一次我会更早做。第一问题池要提前设计好并冻结。我们前期频繁修改问题池导致前后两批数据口径不一致采纳率对比没有参考价值。建议第一次建池后就定一个“冻结日期”之后只增不删新增问题单独标记这样历史趋势才是对齐的。第二原始回答必须留痕。之前为了省数据库空间只存判定结果不存原文后来要调整判定规则时发现无据可查。现在我的表结构里一定保留 answer 字段哪怕看起来很占空间它换来的是你随时能回溯、能复核、能重新判定的能力。第三把异常当常态来设计。API 超时、限流、页面改版都不是偶发事件而是必然事件。代码里每个外部依赖都要有兜底逻辑调度任务要支持失败重跑且不产生重复数据。这套系统能稳定跑几个月靠的不是某个聪明的算法而是这些不起眼的防御性设计。如果你也想搭一套 AI 品牌词采纳率监控别一上来就铺大而全的平台先用 SQLite 加 Python 脚本跑通单日流程再慢慢加可视化。跑出第一张趋势图的那一天你会觉得这活儿从一开始就没白折腾。