品牌词换一种问法得到的答案完全不一样前后矛盾。这类问题靠人肉翻聊天记录根本查不完必须有一个自动化、可量化的系统持续盯着。我把这个系统叫 GEO 监测系统底层用到了两条腿一条是大模型 API 调用负责把不同模型的回答采回来另一条是 RAG检索增强生成链路负责把模型回答放到某个品牌/产品上下文里去校验模型是不是真的认识你、怎么说你。两条腿合起来就能覆盖从用户提问到模型回答到品牌价值分析的全链路。这套东西适合谁参考如果你是做品牌市场、用户研究、SEO 优化现在也叫 GEOGenerative Engine Optimization或者你本身是做 AI 应用的工程师想了解怎么把大模型能力沉淀成业务系统这篇文章可以给你一套完整的、可以落地的架构思路和实操细节。1. 项目需求拆解与整体设计思路1.1 核心需求不只是爬回答而是评估回答刚开始我犯过一个典型错误以为这个项目就是调大模型 API把回答存下来然后做个关键词匹配就完事。实际做下来才发现这里面有两个完全不同的层次。第一层是采集层解决的是用什么模型、什么参数、什么频率去提问把原始回答稳定地拿回来。这个层次更像爬虫工程师的活。第二层是评估层解决的是模型回答里到底有没有提到我的品牌、提到了是正面还是负面、和竞品一起出现时排序如何、换个问法会不会变脸。这个层次其实是 NLP 搜索评测的活。用户真正关心的不是回答原文而是品牌在 AI 世界里的存在感和评价。所以整体设计的核心矛盾是要把非结构化、不稳定、有多样性的大模型自由文本转成结构化、可对比、可跟踪的品牌监测指标。1.2 为什么必须引入 RAG而不是直接裸调模型这里是我在架构上最重要的一个决策点。初期我做过一轮试验直接用裸模型问XX 品牌怎么样然后把回答拿来做分析。结果发现裸模型尤其是参数量较小的模型在不同时间点上对同一品牌给出的答案波动非常大而且很容易一本正经地编造品牌细节。但真实用户在主流 AI 产品里拿到的答案往往不完全是裸模型直接输出的——很多搜索类、问答类产品在背后都会做一步检索增强把网上的相关内容检索回来再让模型基于这些材料组织答案。所以如果我们只测裸模型测出来的其实是模型的记忆而不是用户实际会看到的东西。引入 RAG 之后系统流程变成用户问题进来 → 先从品牌知识库和公开资料库里做向量检索 → 把检索到的片段拼进上下文 → 再让大模型基于这些片段生成回答 → 把最终回答作为监测分析样本。这样做的好处有三点回答更接近真实用户获取信息的路径监测结果有业务参考价值。回答里引用的知识点有来源可溯为后续归因分析提供了抓手。解决了同一问题在多次调用间波动过大的问题RAG 注入的固定语料对输出起到明显的锚定作用。1.3 系统数据流向从提问池到分析报表整个系统的数据流我总结为五个阶段问题池构建把品牌词、品类词、场景词组合成覆盖用户真实意图的问题集合。检索与采样对每个问题执行 RAG 检索组装 Prompt调用各家大模型 API。响应清洗与结构化把模型的自由文本切分、去重、提取实体、标注角色品牌/竞品/品类。指标计算计算提及率、推荐排名、评价倾向、回答稳定性等指标。落库与报表写入数据库定时产出日报/周报推送告警和异常波动。这五步看起来简单但每走一步都会踩到不同的坑。接下来的部分我把每一层的关键实现细节展开说。2. 底层架构分层与关键技术选型2.1 采集层多模型 API 接入与统一封装先聊采集层。你要监测大模型品牌表现第一步是保证问题能稳定地打到不同模型嘴里。目前主流的大模型 API 各家参数风格略有差异但都支持最基本的对话补全接口。我的做法是写一个统一的模型客户端适配层输入统一所有模型都接收 messages 格式即 system、user、assistant 三段式对话上下文。输出统一把各家返回的 JSON 结构解析后只保留 text 内容、token 用量、延迟、finish_reason 等公共字段。异常统一网络超时、限流、内容审核拦截全部封装成同一种异常类型便于上层统一重试。这里有个容易被忽略的细节模型温度参数。做监测和做创作不一样创作希望温度高一点、多样性强监测要求可复现、可对比所以温度我会固定成 0.2 甚至 0同时关闭流式输出直接拿完整答案。温度设太低可能会导致回答变得机械但监测场景里稳定比精彩重要得多。并发调用方面我采用异步并发 信号量控制。每个模型服务商都有自己的 RPM每分钟请求数和 TPM每分钟 token 数限制盲目并发会触发 429 限流反而降低吞吐。我的经验是把并发上限设置为服务商限制的 70% 左右留出冗余给重试和突发流量。2.2 检索层知识库建设与向量检索细节RAG 链路里最难的部分不在检索本身而在知识库建设。品牌监测用的知识库不能是网上随便抓的一大堆垃圾文本必须经过清洗和分级。我做了三级知识库第一级品牌官方资料。包括官网、产品文档、新闻稿、官方渠道发布的描述。这部分权威性最高检索权重也最高。第二级第三方媒体和评测内容。来自公开的技术评测、媒体报道、用户测评文章。第三级社区讨论和用户反馈。来自论坛、评论区、社交平台公开内容。这部分噪声大但对监测用户真实口碑很有价值。三级知识库在向量化之前统一做切片。切片长度我试过 128、256、512、1024 token最终稳定在 256~512 token 之间重叠窗口设 64 token。太短会丢失上下文太长则检索召回时噪声变大、embedding 表示的语义平均化。embedding 模型选择上我用过开源的中文向量模型也用过商业 API 的向量接口。结论是如果你的知识库以中文为主务必用中文语料预训练充分或针对性微调的 embedding 模型否则检索质量会明显下滑。测试方法很简单拿 50 个品牌问题去检索人工看召回 TOP 5 的相关性相关性低就直接换模型别犹豫。2.3 评测层结构化输出设计RAG 检索完成后组装好的 Prompt 发给大模型拿到回答后进入评测层。这里最大的难点是怎么把一段自然语言变成可计算的指标我的解法是二次调用模型做结构化抽取。第一轮大模型负责生成自然语言回答第二轮用更低温的模型或者同一模型把回答解析成 JSON字段包括品牌名、出现的位置、角色提及/推荐/对比、观点倾向正向/中性/负向、推荐力度等。这里要注意第二轮解析模型不能只看回答本身还要给一段分析规则作为 system 提示比如如果回答中将品牌 A 与品牌 B 并排提及请把所有品牌记录在 mentions 数组中并标注 order 字段表示出现顺序。结构化输出的好处是后面的指标计算不再需要处理模糊文本直接查 JSON 字段就行。为避免解析模型偶尔输出非法 JSON我加了一层兜底如果连续三次解析失败就把原文标记为解析失败入库人工介入。这个失败的样本其实很值钱它往往能暴露提示词设计或回答风格上的新问题。3. 全链路监测指标体系与核心实现3.1 从原始回答到监测指标五类核心维度品牌方真正关心的指标我归类为以下五类每一类背后都有对应的算法逻辑指标类别具体指标计算方式存在感品牌提及率、平均提及位置在所有样本中统计品牌被提到的概率以及首次出现的平均顺序认知评价正向/中性/负向占比基于结构化抽取的情感等级聚合推荐力推荐/不推荐/中立比例根据观点倾向和推荐力度字段统计竞品对比与指定竞品的共现率、排序胜率在同时包含两品牌的回答样本中统计谁排在前面稳定性同一问题多次回答的品牌态度离散度对同一问题多次采样的情感结果做差异分析举个例子存在感指标不只是提到或没提到还细分为品牌是主动被推荐还是仅仅作为竞品列表里凑数出现。后者在结构化字段里表现为role: comparison_list_member前者是role: primary_recommendation。这两个角色的业务价值完全不同必须拆开。3.2 回答稳定性评估最容易被低估的指标实际做下来最让我吃惊的是稳定性指标。很多品牌方以为只要模型记得我就行但反复采样之后发现同一品牌在类似问题下有时候排名第一有时候排名第三甚至有时候完全不被提及。这种波动不能简单归因于模型随机性它往往反映了模型内部知识表征、检索排序位置和 Prompt 组合方式之间的复杂关系。我设计稳定性这一类指标时采用了一个四步流程同一个问题在同一个系统配置下重复采样 N 次一般 N5。每次采样都记录态度标签、推荐力度、品牌出现位置。计算态度的分布熵。如果 5 次里 4 次正向、1 次负向熵值就很低说明模型对品牌的态度比较稳定如果 3 正 2 负熵值高说明模型认知存在明显摇摆。把波动样本单独抽出来归因到是检索材料变化、Prompt 变化还是模型本身随机性导致的。这种归因并不容易做到自动化但至少能通过日志溯源。每次采样我会把检索到的 Top 5 文档 ID、版本号、Prompt 哈希值全部落库。一旦出现异常波动直接对比两次采样的日志差异就能快速定位是哪一环变了。3.3 品牌意图分层用户问法和品牌监测的关系还有一个很容易翻车的地方用户问题的问法不同模型回答里提到品牌的方式可能天差地别。比如问推荐一款适合编程的笔记本和问某品牌笔记本值得买吗前者的品牌信息可能混在多个候选里后者则是定向评价。这两类问题的监测目的和方法完全不一样。我把问题池分成三类品类型问题不指定品牌期望模型给出候选列表。用来测品牌在品类推荐中的自然入围率。对比型问题明确写两个或以上品牌。用来测竞品排序和优劣评价。定向型问题明确提到某一个品牌。用来测该品牌在定向询问下的口碑和推荐力度。三类问题在结构化解析时用不同的规则。比如品类型问题里品牌出现顺序本身就是最重要的指标排在 Top 1 和排在 Top 5 的曝光效果差异巨大而在定向型问题里重点则是回答是否给出了积极的分析还是回避态度。把这两类混在一起算指标结果会被稀释掉完全没有意义。4. 实操过程从问题池到自动化报表4.1 问题池构建与迭代方法论问题池是整个监测系统的心脏。最开始我手工写了 200 个问题覆盖的范围看着全面跑了一个礼拜就发现问题很多问题的口径太笼统不同品牌之间根本没有区分度有些问题又太偏门模型根本不理解每次回答都在胡扯。迭代方法论后来我总结为三步从真实搜索词入手。参考公开的搜索下拉和相关搜索数据把品牌词 品类词 场景词组合成候选问题。用模型自己的困惑度来筛题。拿同一批问题跑 30 个样本如果模型对某个问题的回答反复出现我不确定、没有相关信息说明这个问题本身没有讨论基础直接剔除。持续补充长尾问题。品牌有新品类发布、行业有新热点时手动把新问题加入问题池并打上标签。问题池稳定之后每次跑批不是全量重跑而是拆成日更问题清单和周更问题清单。日更清单只跑品牌核心词和竞品词成本可控周更清单跑全量问题输出深度分析。4.2 数据落库与报表自动化数据结构设计上我用三张核心表questions 表问题 ID、问题文案、问题类型、状态、所属监测主题。samples 表每次采样的回答原文、结构化 JSON、模型标识、采样时间、RAG 版本号、检索文档 ID 列表。metrics 表按问题/品牌/时间粒度聚合好的指标行直接供报表查询。报表生成我做成每日一个定时任务逻辑是先读取当日所有 samples按品牌维度聚合指标再和昨日、上周同期做对比。生成结果写入一张 metrics 表的同时推送到企业微信/钉钉机器人。日报只推送变化量比如品牌 A 在品类型问题中提及率从 62% 下降到 41%涉及 3 个问题而不是把整篇报告都丢出来。周报才输出完整趋势图和分析。从项目管理的角度看这套报表逻辑的最大价值不是每天告诉你现在怎么样而是告诉你相比昨天、上周发生了什么变化。变化量才是品牌监测真正应该盯住的东西。4.3 成本控制token 耗费与调用节奏的平衡品牌监测系统对成本比较敏感因为它是长期 7×24 小时推进的业务系统不是一次性实验。大模型 API 按 token 计费RAG 链路里每一次采样实际要花两次 token一次是检索结果拼接成上下文的输入 token一次是生成回答和结构化解析的输出 token。我的成本控制清单分享几个实测有效的策略打开缓存。完全相同的问题 完全相同的检索上下文在一定时间窗内直接命中缓存不再调用模型。分层采样。核心品牌和重点竞品每天多次采样非核心品牌每三天一次。控制检索上下文长度。Top 5 文档、每文档切 3 段以内上下文控制在 2000 token 以内就够再多会稀释重点还浪费钱。结构化解析用小模型。解析 JSON 这类任务不需要顶级大模型用一个轻量级模型或蒸馏过的模型任务就够成本能降一个数量级。4.4 部署形态定时任务、队列与失败重试整套系统的部署形态并不复杂。我用的是 Python 写的调度主进程依赖 APScheduler 做定时触发每次触发生成一批采样任务放入队列。采样任务由消费进程从队列里取出先查缓存再并发调用各模型 API最后落库。失败重试这块非常关键。大模型 API 不像关系型数据库那样可靠超时、429、5xx 都是家常便饭。我的重试策略是普通网络异常重试 3 次间隔指数退避。限流异常sleep 到响应头里的 retry-after 时间再重试。内容审核拦截不重试直接标记为被拦截样本保留原因字段。连续失败告警同一个任务连续失败超过 5 次就告警而不是无限重试下去避免一次批量故障烧掉大量调用配额。5. 常见问题与排查技巧实录5.1 结构化解析失败率高怎么办我在系统上线初期结构化解析的成功率只有 85% 左右意味着每 100 条回答里有 15 条没法进入指标计算。排查发现主要原因是回答里大量使用了 Markdown 标题、促销式语言和复杂嵌套句式导致解析模型输出的 JSON 频繁非法。后来我做了两件事第一在解析 Prompt 里加了禁止输出 Markdown、只输出纯 JSON的约束第二对解析结果做 JSON 修复用正则把常见的裸字段、尾部逗号这些问题修掉。成功率最终稳定在 98% 以上。还剩的 2%人工看也没发现规律我猜和分析模型本身的随机性有关就不再强求。5.2 品牌词歧义导致的误判中文品牌词歧义是个大坑。有的品牌名同时是行业通用词有的品牌名和其他品牌简称撞车解析出来的实体标签经常指错对象。我的解决办法是在知识库里给每个品牌维护一个歧义排除规则列表。比如某品牌名和某个动词同形规则里就写明如果回答中该词出现在动词位置不视为品牌提及。这套规则本质上是给结构化解析模型提供一个消歧的辅助上下文实测效果立竿见影。5.3 检索材料时效性与监测结果的关系RAG 链路里知识库不是静态的需要定期更新。但更新频率不能一刀切。官方资料一个季度更新一次问题不大但社区讨论和媒体评测几周就会翻转观点不及时更新会让监测结果失真。我被这个坑绊过一次某品牌发布了新产品线我没及时更新知识库结果连续一周监测到的都是模型对该品牌认知偏旧还以为是品牌负面舆情。后来做了知识库版本管理每次全量更新记录版本号metrics 表里存了对应的知识库版本就能区分模型认知变了和知识库资料变了。5.4 一些值得继承的经验清单最后顺手整理几条容易踩但不太有人讲的模型 API 的版本会偷偷升级。同一个模型名给出的回答风格可能与一个月前完全不同监测系统的样本表里务必记录调用时的模型版本或快照标识。system prompt 里的措辞变化会显著影响品牌推荐倾向。改 prompt 之前先想清楚会不会污染历史数据对比。采样时间点要固定。大模型服务商在高峰期和中低峰期的回答质量都有细微差异为了让日报对比有意义每天同一时间段跑批。不要用单一模型代表全网大模型认知。至少跑 3 家不同模型或者 2 家模型 1 家搜索增强产品结果才有代表性。6. 这套系统的延伸价值与个人收尾体会监测系统做出来之后最初的业务目标已经达成但实际使用中我还发现了一些意料之外的延伸价值。比如当 RAG 检索链路稳定运行一段时间后沉淀下来的问题池 采样日志本身就是一个高质量的数据集。你可以用它来测试新模型的品牌友好度在新模型上线前就提前评估这个模型更偏好哪些品牌、回答风格是什么。品牌市场团队也可以用这套系统来验证 GEO 优化动作的实际效果调整了官网描述、补充了第三方评测稿之后监测指标是否在下一周出现可观测的变化。从工程角度看这个项目其实用不到什么特别玄乎的技术核心就是老老实实把检索、采样、结构化解析、落库、对比分析这几个环节做好难点全在细节和长期稳定性上。我个人在实际操作中的体会是做品牌监测系统最大的风险不是技术搞不定而是业务方对模型回答的预期不切实际——总希望有一个完美的、确定性的品牌评分。实际上大模型回答天生带随机性和时效性监测系统的价值不在于给你一个绝对分数而是告诉你趋势和异常。把预期校准好这套系统才能真正在业务里扎根。最后再分享一个小技巧如果你刚开始做不要一上来就铺全量问题池和全品牌监测。挑一个核心品类、两个品牌、五十个问题先跑两周把采集、解析、指标计算这条链路完全跑通之后再横向扩展。把单体模型问题跑透了后面的规模化只是堆机器和堆配置的问题而不是架构再发明的问题。