企业级舆情监控，听起来是个很庞大的系统，但真正把它拆开之后会发现，核心就三件事：把数据采回来，把噪音洗干净，把关键信息找出来。这套系统是我给某集团做舆情平台时的完整实战项目，服务对象是市场部和公关部，目标只有一个——在负面信息大面积扩散之前，让相关的人先看到预警，而不是等热搜上了再去补救。

整套链路从采集端开始，用反爬虫沙箱解决“拿数据不稳”的问题；中间用向量引擎做语义检索，而不是传统关键词匹配，因为舆情文本里大量是“虽然没有提到品牌名，但明显在说你家产品”的隐晦表达；最后用GPT-5.2做情感分析、事件分类、摘要和报告生成，让公关团队每天打开的不是一堆原始链接，而是一份可以直接汇报的结论性文档。这篇文章会把这条链路从头到尾拆开讲，包括技术选型、参数配置、踩坑记录和优化路径，适合正在搭舆情平台、信息监控系统或者内容中台的团队参考。

1. 整体设计与方案选型

1.1 舆情系统的核心难点与设计目标

很多人以为舆情监控就是“爬新闻+搜关键词”，实际做了才发现完全不是一回事。企业舆情系统真正难在四个地方：

• 数据源极其分散。新闻门户、行业垂直站、论坛、评论区、公开社交媒体，每个源的结构都不同，有的需要处理JS渲染，有的接口不稳定，有的必须模拟用户行为才能拿到完整内容。
• 信息噪音占比太高。一个品牌名在一天内可能产生几千条相关文本，但其中一半是广告、转载、无意义讨论，真正跟“负面事件”相关的可能只有几十条。如果靠人工读，十个人都不够用。
• 关键词匹配会漏掉大量潜在风险。用户不会每次都用你的官方品牌名，更多是用简称、拼音、错别字，甚至“这家店”“那个平台”来指代。关键词规则写得再全，也追不上人类表达的变化。
• 实时性要求很苛刻。舆情事件的生命周期往往只有几个小时，如果告警链路多绕了半小时，可能就已经从个别评论发酵成行业新闻了。

所以我定设计目标时，没有追求“全量采集所有互联网信息”，那是搜索引擎做的事。系统的核心目标是：对指定品牌和行业主题，做到分钟级采集、语义级去重、自动识别风险事件、生成可读报告。简单说，就是让系统每天代替公关团队完成80%的初筛工作。

1.2 技术栈选型：为什么是向量引擎加GPT-5.2

传统舆情系统通常用ES做全文检索，加上一堆正则规则跑分类。ES的倒排索引对精确词匹配很高效，但遇到同义表达、指代不清、上下文语义理解这些场景，效果非常有限。比如“某品牌充电宝在高温下鼓包”和“用了三个月电池凸起，客服还说是正常现象”，这两句话没有共享任何关键词，但语义上高度相关。向量检索的价值就在这里——把文本映射成高维向量，通过余弦相似度找到语义相近的内容，哪怕字面完全不一样。

我在这套系统里选了某开源向量数据库作为核心检索引擎，没有用全量ES方案。对比过几个主流引擎，大致情况是这样的：

最终选了向量数据库B。理由很直接：舆情数据单日增量在几十万条量级，单机千万级向量足够跑一年半，而且它原生支持payload过滤，可以在检索时直接按时间、来源、情感类型过滤，不用先召回再做后置裁剪。QPS压力也不大，内部系统最多几十个并发查询，完全不必上分布式。

GPT-5.2在这套系统里承担的角色不是“聊天机器人”，而是分析引擎。它负责四件事：单条文本的情感判断与事件分类、多条相关文本的聚合摘要、周期报告生成、以及对外沟通话术的建议生成。因为GPT-5.2支持结构化输出，可以直接返回JSON格式的标签和评分，我才能把它嵌入到自动化工单里，而不是靠人去复制粘贴回答。

1.3 整体架构与数据流设计

整条链路可以拆成六个模块：采集器、清洗管道、向量化服务、检索服务、分析服务、展示与告警。

采集器负责从各信息源抓取原始页面，解析出标题、正文、发布时间、来源、链接。清洗管道负责去HTML标签、去广告噪声、识别正文主体、做文本去重。向量化服务把清洗后的文本切成块，调用Embedding接口生成向量，写入向量库。检索服务提供语义查询，支持按时间范围、来源类型、情感标签过滤。分析服务在检索结果之上调用GPT-5.2做细粒度分类和摘要，最终生成报告数据。展示与告警层读报告数据，画大屏、推Webhook、发邮件。

模块之间用消息队列解耦。采集器只管把原始记录丢进队列，清洗和向量化是消费端，可以独立扩容。这样做的原因是采集速度和分析速度天然不匹配：采集高峰可能一分钟涌入几百条数据，而向量化接口和GPT调用都有速率限制，如果做成同步调用，采集端会被分析速度拖死。用队列缓冲之后，系统在高负载下只会产生“消息堆积”，不会产生“数据丢失”。

这里面有个容易被忽略的设计：原始数据和分析数据要分开存储。数据库A只存向量和元数据，原始页面正文存在对象存储和MySQL里。原因第一是向量库不适合存长文本，第二是后续如果更换Embedding模型，需要重新向量化全部数据，如果把原始文本丢了就彻底没救了。

2. 数据采集与反爬虫沙箱实战

2.1 信息源配置与合规采集边界

在做信息源规划时，我先跟法务确认了合规边界。系统只采集公开可访问的信息，不碰需要账号登录才能看的私密内容，不做任何绕过付费墙或规避访问控制的操作。遵守目标站点的robots协议和访问频率限制，是这条链路绝对不能碰的红线。

优先级上，首选RSS和官方公开API，这些渠道稳定、结构规整、不受页面改版影响。比如主流新闻站、科技媒体、行业公告基本都有RSS输出，采集成本极低。其次才是页面采集，针对没有RSS但公开可访问的论坛和垂直社区。页面采集变化风险高，必须做好监控和告警，一旦解析规则失效，系统能立刻发现而不是默默产出空数据。

对于公开社交媒体，优先走官方开放平台接口，限制多但有保障。采集频率也必须控制：单源请求间隔不低于10秒，整体并发控制在合理范围内。真实采集中，大多数站点其实不介意被高频访问，但它们很介意“像爬虫”的访问特征，所以核心不在于伪装，而在于把访问节奏模拟得像个真人用户。

2.2 沙箱环境与浏览器模拟的核心设计

反爬虫沙箱这个词听起来很玄，实际落地就是一套浏览器自动化服务。我用的方案是Python加Playwright，每个采集任务跑在一个独立的浏览器上下文里。为什么不用简单的requests直接抓？因为很多舆情源是前端渲染的SPA页面，requests拿到的HTML是空壳，正文数据都是通过后续异步请求加载出来的。Playwright能真正打开无头浏览器，执行JavaScript，拿到的DOM跟真实用户看到的一致。

沙箱里要做的不只是打开页面，还包括几个关键点：

• 用户代理、屏幕指纹、时区、语言都要设置成真实浏览器的样子。
• 设置合理的浏览器窗口大小，尽量模拟真实分辨率。
• 页面加载后要等待必要的网络空闲时间，避免DOM还没渲染完就抓内容。
• 每完成一个页面的采集，强制清理Cookie和缓存，避免会话污染。

采集器核心代码大概是这样的：

from playwright.sync_api import sync_playwright import random def fetch_with_sandbox(url, wait_selector): with sync_playwright() as p: browser = p.chromium.launch( headless=True, args=["--disable-blink-features=AutomationControlled"] ) context = browser.new_context( viewport={"width": 1920, "height": 1080}, user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36", locale="zh-CN", timezone_id="Asia/Shanghai" ) page = context.new_page() page.goto(url, timeout=30000, wait_until="domcontentloaded") page.wait_for_selector(wait_selector, timeout=10000) # 等网络空闲，确保异步数据加载完成 page.wait_for_load_state("networkidle") html = page.content() # 随机延迟，避免规律性访问 page.wait_for_timeout(random.randint(2000, 5000)) browser.close() return html

这段代码里有个很容易踩的坑：AutomationControlled特征。无头浏览器默认会暴露navigator.webdriver属性，很多站点就是靠这个判断来访者是不是自动化工具。加了这个启动参数，再把用户代理设置成真实浏览器版本，被识别的概率会明显降低。但我不建议做过度的指纹伪装，伪装得越刻意，反而容易触发风控系统。

2.3 请求出口调度与限速策略

采集任务来自不同的信息源，请求出口如果长期固定在同一批IP上，很容易被目标站点整体限制。我的做法是维护一个出口IP池，采集器发出的每个请求都通过出口网关调度。这个逻辑跟负载均衡类似，核心目的不是隐藏身份，而是让访问来源分布更接近真实用户的网络环境，同时避免单出口被限流连累所有采集任务。

出口池的健康检查很重要。每个出口IP用之前，先发一次探针请求，确认目标站点的响应状态码正常；如果连续返回403或429，就把这个IP摘掉，等冷却时间过后再重新探测。实际运行中，出口池的可用率会直接影响采集成功率，我建议至少保留三倍的冗余量。

限速策略上，我采用的是“单源并发上限+全局滑动窗口”的组合。单源并发上限设为2，也就是说同一个目标域名同时最多只有两个请求在跑。全局滑动窗口控制每分钟总请求数，默认不超过300。超出阈值的请求直接进入队列等待，而不是硬闯。这样系统整体看起来就是个正常访问量的用户集群，而不是扫描机器人。

这里有个值得说的细节：不同源可以设置不同的限速档位。行业垂直站通常流量不大，对采集也不敏感，可以把间隔降到5秒；大型新闻门户有成熟的CDN和风控团队，必须把间隔拉到15秒以上。档位策略通过YAML配置管理，我在采集服务里做了一张域名到档位的映射表，新加数据源时只需要改配置，不用改代码。

source_rules: "news.site-a.com": concurrency: 1 interval: 15 enabled: true "forum.site-b.com": concurrency: 2 interval: 10 enabled: true "blog.site-c.com": concurrency: 3 interval: 5 enabled: true

2.4 正文解析与增量抓取机制

拿到HTML之后，下一步是从DOM里提取结构化字段。首选方式是XPath定位正文节点，辅以CSS选择器做兜底。不同站点的DOM结构差异很大，我单独做了解析器注册表，每个站点对应一套提取规则。正文提取不能只取article标签，因为很多页面的正文其实嵌套在div里，需要结合阅读量、正文长度、标点密度做启发式判断。

我总结了一套实用的解析策略：先尝试提取页面里的“主内容容器”特征，比如article、main、content这一类class名；如果命中不到，就统计页面里所有div的文本密度，取文本最长且包含句号比例最高的那个块作为正文。这个方法对大多数文章型页面都有效，但如果是论坛帖子和评论列表，就要按楼层结构逐条解析。

增量抓取是舆情采集的另一个重点。每次全量抓取不现实，效率和对方站点负载都难以接受。我的做法是维护一张URL指纹表，对每个已抓取的链接计算MD5指纹并存入Redis，新抓到的链接先查指纹，存在就直接跳过。同时按时间窗口做增量，比如只抓最近24小时内更新的页面。对于没有明显时间字段的论坛帖，用页面里的“最后回复时间”作为增量依据。

URL指纹表不能永久膨胀，我设置了30天过期时间。超过30天的链接如果再次出现，一般说明该内容被重新编辑或推荐到了首页，重新抓一次成本很低，却可能拿到更新后的信息。

2.5 采集沙箱的踩坑记录

第一个坑是页面交互验证。某些站点点击翻页或展开全文时会弹出拖拽验证组件。普通采集器直接卡死。我的处理方案是：在沙箱里预置一个验证处理队列，如果检测到验证组件出现，就截屏留证，把任务标记为“需要人工介入”，同时通过告警推给值班人员。不要试图写脚本去自动破解验证，一是技术上容易被对抗，二是合规风险大。人工介入后调整策略，比写对抗代码更稳妥。

第二个坑是字体解析。很多新闻站正文里会混入特殊字体和图标字体，直接把文字提取出来会得到一堆乱码或方框。解决方法是等页面加载完成后，执行脚本检查字体文件是否就绪，必要时强制等待document.fonts.ready。

第三个坑是采集失败的不透明性。刚开始上线时，我只记录“采集失败”这个状态，结果排查时完全不知道是超时、被限流、还是页面结构变了。后来我在采集器里加了失败原因分类：超时、连接错误、状态码异常、内容为空、解析失败。每种原因都有独立计数，日志直接输出到监控平台。没有这个分类，排查问题的效率至少要低三倍。

3. 文本清洗、向量化与语义检索

3.1 数据清洗与字段规整

清洗管道是容易被低估的环节。原始HTML里除了正文，还有导航栏、推荐位、广告、页脚版权、相关阅读这些噪声。如果不做深度清洗，把整页HTML直接塞给向量化接口，不仅浪费Token，还会让向量里混入大量跟事件无关的信息，检索精度明显下降。

清洗流程拆成五步：

• 将HTML转成纯文本，去掉脚本、样式、隐藏节点。
• 按段落切分文本，过滤掉字数少于10的碎片，比如“打开APP阅读全文”这类引导文案。
• 去除重复段落，很多页面会把头条标题重复渲染在正文前后。
• 规整发布时间、来源、作者、URL等元数据。
• 对正文做编码修正，统一转UTF-8，处理乱码和特殊空格。

清洗后的每条记录，我存成统一的JSON结构，包含id、source、url、title、content、publish_time、crawl_time、author、tags。这套结构贯穿整条链路，后续向量化、检索、分析、报告都读这个标准格式。

有个细节要注意：发布时间解析比想象中难。中文站点有“刚刚”、“5分钟前”、“昨天”、“昨天 23:14”这类模糊时间表达，必须写一套解析器转成标准时间。转换不准会直接影响舆情趋势图，因为数据点的时间戳错了，整条趋势线就失真了。

3.2 文本分块策略：为什么不能整篇向量化

把整篇文章直接转成一个向量，是很多人会犯的错误。文章的语义是复合的，一条新闻可能前半段讲公司财报，后半段讲产品召回，整篇向量化之后，向量会被“平均”成一个四不像的语义，检索召回时定位不到具体段落。所以必须分块。

分块参数我选的是每块256个Token，相邻块重叠50个Token。为什么是这个数字？如果块太短，比如小于100个Token，单个块包含的语义太少，检索时容易匹配到“无意义”的片段；如果块太长，超过500个Token，块内可能出现多个子主题，向量表示依然会被平均化。重叠的作用是保住切片边界的上下文连续性，避免“召回的时候，关键信息恰好落在上一块的末尾被切掉”这种尴尬情况。

分块时最好按自然段落优先切，而不是机械地按字数硬切。我的实现逻辑是：遍历正文的段落，如果当前块还没到256个Token，就继续追加段落；如果追加下一个段落会超过上限，就在当前块尾部补一段重叠文本，然后开启新块。这样每块基本在语义上是完整的，检索效果比纯按字符切好很多。

3.3 向量化模型与维度选择

向量化模型的选择直接决定检索精度的上限。我最终用了GPT-5.2自带的Embedding接口，输出维度是1024维。为什么不用开源小模型？舆情文本里大量包含反讽、隐晦表达、行业术语和指代不清的表述，小模型在语义理解上的表现明显不足，尤其对“阴阳怪气”的负面舆情几乎无感。大模型的Embedding接口虽然贵一点，但精度优势足够覆盖成本。

维度1024是个折中值。维度越高，能刻画的语义越丰富，但存储成本和检索延迟也会上升。在千万级向量的场景里，1024维的向量库占用约为每百万条4GB左右，单机完全扛得住。如果维度升到2048，存储翻倍，召回提升有限，整体性价比反而是下降的。

批量向量化时，我设置每批128条文本，串行调用Embedding接口会太慢，并行度太高又容易触发限流。经过实测，128这个数字配合8路并发，既能跑满接口配额，又不会频繁报错。向量化结果写入向量库之前，一定要检查归一化。绝大多数向量引擎默认使用余弦相似度，如果Embedding接口不返回归一化向量，检索结果就会出现偏差。

向量索引参数也值得说。我用的是HNSW算法，核心参数有M和ef_construction。M控制每层最大连接数，默认16，调到32会让召回变好但索引体积变大，索引构建时间变长。ef_construction控制构建时的搜索宽度，默认200，我保持不动。查询侧还有个ef参数，越大召回越准但延迟越高，我线上设为128，P99延迟控制在30ms以内。

3.4 语义检索与过滤策略

向量检索不能只是“查相似”。舆情系统里，用户永远只关心最近的舆情，而不是三个月前的陈年旧事，所以检索时一定要带过滤条件。向量数据库B的Payload过滤很好用，查询时可以直接指定时间范围、来源列表、情感类型作为过滤条件，先把候选集合缩到一个合理范围，再执行向量相似度计算。这比“先暴力Top1000再程序过滤”快得多，也准得多。

Top-K的选择上，我的粗排参数是K=100。也就是向量检索返回最相似的100条，这100条只代表“语义相似”，不代表“一定是相关事件”。所以后续必须做重排精排，把粗排结果喂给一个交叉编码器或者直接喂给GPT-5.2打分，重新排序后取前10条用于生成分析结论。粗排+精排的双级结构，核心指标是从“语义相似”提升到“事件相关”。

相似度阈值我设的是0.62。低于这个阈值的文本，大概率只是用词接近但话题不同。这个数字不是拍脑袋定的，而是拿5000条人工标注数据做阈值扫描，在精确率和召回率交叉点上取的。不同业务场景阈值要微调：如果是要抓潜在风险，阈值可以降到0.55，宁可多召回一些误报；如果是做日常报告，阈值提到0.7，保证报告里的内容都足够相关。

检索代码大致长这样：

from qdrant_client import QdrantClient from qdrant_client.models import Filter, FieldCondition, MatchValue, Range client = QdrantClient(host="localhost", port=6333) query_vector = embedding_model.encode(query_text) search_result = client.search( collection_name="public_opinion", query_vector=query_vector, limit=100, query_filter=Filter( must=[ FieldCondition(key="publish_time", range=Range(gte=start_ts)), FieldCondition(key="source_type", match=MatchValue(value="news")) ] ), search_params={"ef": 128} )

3.5 向量化与检索的常见坑

维度不一致是最低级也最常见的错。换了Embedding模型版本之后，忘了同步更新集合配置，查询时报维度错误，整个服务直接挂掉。解决办法是在代码里做模型版本和集合维度的强绑定，加一个环境变量校验，不匹配就拒绝启动。

第二个坑是文本为空。清洗管道如果某条记录最终正文为空，向量化时会得到空向量，写入向量库就是一条垃圾数据，检索时还可能拉低结果质量。我加了一层“空文本直接丢弃，不向量化，只记录日志”的逻辑。

第三个坑是模型版本更新导致的语义漂移。换了一次Embedding模型之后，新旧文本的向量空间分布不一致，老数据用旧模型向量化，新数据用新模型向量化，检索效果会变得非常奇怪。要么就永远不换模型，要么就一次性做全量重向量化。这里没有中间路线。

4. 舆情分析、GPT-5.2生成报告与可视化大屏

4.1 用GPT-5.2做情感分析与事件分类

清洗和向量化解决的问题是“找到相关文本”，但企业最终关心的是“这件事严不严重、要不要管”。这一步交给GPT-5.2做分析。我不是把每条文本都塞给GPT，而是只把重排后高相关的Top-N条文本送入分析服务，大幅降低成本和延迟。

Prompt设计对输出质量影响巨大。我不用自由对话式Prompt，而是用“角色设定+任务指令+输出格式约束”的结构。角色设定为“资深舆情分析师”；任务指令明确要求从情感极性、情绪类型、事件类型、影响主体、负面程度五个维度分析；输出格式严格限定为JSON，并给出示例。这样一来，GPT-5.2返回的结果直接就能落到结构化字段，不需要再做解析。

情感极性分三类：正面、中性、负面。情绪类型细化为愤怒、担忧、失望、质疑、调侃、其他。事件类型按业务需要定义，比如产品安全、服务投诉、高管言论、财务问题、行业政策等。影响等级分1到5级，5级代表“可能引发大规模负面传播”，需要立刻处置。

影响等级不是让GPT直接拍脑袋给的，我要求它在输出里附上判断依据，并参考三个信号：传播源头的权威度、文本中的情绪强度、是否包含明确的时间地点人物等事实要素。如果一条负面文本来自有影响力的行业媒体，又点名了公司全称，还描述了具体事故细节，等级必然高于一条匿名论坛的吐槽。

调用GPT-5.2时有个关键操作：开启结构化输出模式。这样输出的JSON格式是稳定可解析的，不会出现“好的，我来分析”之类的废话前缀。我在代码里强制要求最低置信度阈值，如果单条文本的分析置信度低于0.6，就把这条转入人工复核队列，而不是直接采信。

4.2 基于事件的聚合与摘要生成

单条文本分析完之后，还要把相关文本聚合成“事件”。这一步用聚类算法加规则。规则上，同一事件至少满足三个条件：涉及主体相同、时间窗口相近（比如72小时内）、语义向量距离低于阈值。聚类算法我用的是DBSCAN，它的好处是不需要预先指定簇的数量，适合舆情事件数量动态变化的场景。

事件聚合完成后，GPT-5.2生成事件摘要。摘要里必须包含六要素：事件经过、涉事主体、关键时间节点、传播范围、情感占比、当前风险等级。为了保证摘要不遗漏关键信息，我用了“填充式模板+生成方式”：先让GPT从原始文本里抽取指定字段，填到一个事件事实表里，再基于事实表生成段式摘要。这比直接让它阅读全部文本写摘要更可控，也不容易扔进上下文里的信息太长导致丢失重点。

生成日报和周报时也是类似逻辑。日报模板是固定的Markdown风格，包括今日舆情总览、Top5热点事件、负面占比趋势、需关注的高危主体、建议动作。这些内容全部由GPT-5.2根据当天的事件数据填充。报告生成前，我会把所有数据先算好，包括负面数量、事件数、来源分布、趋势百分比，GPT只负责把这些数字写成有逻辑的文案。计算交给代码，表达交给大模型，各司其职。

这里有个抑制幻觉的关键操作：限定GPT只能基于我提供的数据字段输出，不允许凭常识补充。在Prompt里明确写“如果数据中没有的信息，直接回答无”。跑了一段时间后，因为“自己脑补背景”而产生的错误内容，比初版下降了90%以上。

4.3 可视化大屏与告警联动

报告数据要让人看得懂，可视化这一步不能省。前端大屏我用的是开源图表库，配合一个轻量级后端聚合服务。大屏上显示五个核心区域：舆情趋势折线图、负面情感占比饼图、来源渠道分布柱状图、Top热点事件列表、高危主体排名。

大屏数据不能直接查向量库，向量库的定位是检索而不是聚合统计。我单独建了一张舆情指标表，统计服务每隔5分钟跑一次聚合任务，把时间段内的负面数量、事件数、来源分布、对品牌有影响的主体写入Redis缓存，大屏接口只读缓存。这样大屏刷新不会有任何检索压力。

告警规则我配置了三个等级：

• 黄色告警：近1小时内负面数量超过日常均值2倍，推送给值班人员。
• 橙色告警：检测到高危主体相关负面事件，且影响等级达到4级，推送市场部负责人。
• 红色告警：单事件24小时传播量达到500条，或影响等级5级，直接推送给VP级别。

告警通道先走Webhook，再走邮件。Webhook接企业内部即时通讯工具，实现手机端秒级通知。邮件作为补充，附上系统生成的事件摘要，方便决策者在路上就能了解情况。

告警阈值不能写死成全局常量，不同品牌的舆论基数差异极大。头部品牌的负面量日常可能就是几百条，而小品牌一天总共才几十条相关文本。我的做法是每个监控主体单独配置基线，系统每7天自动计算一次日均值和标准差，阈值设为均值加2倍标准差，实现动态自适应。

4.4 性能优化与成本控制

大模型调用是这套系统里最大的成本项。向量化接口每百万Token的费用会随着文本量增长，GPT-5.2的分析调用更是按Token计费。优化核心只有一个：减少无谓的调用。

我做了三层过滤。第一层是向量检索粗筛，从源头把“看起来不相关”的内容过滤掉。第二层是重排精排，只让Top-N条文本进入GPT分析，而不是把当天所有抓到的文本都交给大模型处理。第三层是去重聚合，同一个事件的多篇报道只选代表性文本做深度分析，其余文本只保留统计信息。

异步任务编排上也做了细化。清洗、向量化、分析、报告生成分别对应不同的队列和Worker组，每个环节的并发数独立配置。向量化Worker是IO密集型的，并发可以高一点；GPT分析是API密集型且受配额管控，并发设低，用队列限流。

我还在分析服务里做了一个相似性缓存。如果新到的文本与某条已分析文本的向量相似度超过0.95，并且发布来源相同，就直接复用之前的分析结果，不再消耗一次GPT调用。实测下来，这个缓存命中率能到20%左右，省下的费用相当可观。

5. 常见问题与排查技巧实录

5.1 检索结果不准：语义漂移与阈值问题

症状是“明明是一篇很相关的负面报道，向量检索却排到了几十名开外”。排查思路分三步：先看查询文本的分词和Embedding结果是否正常，再检查候选文本的清洗是否干净，最后看阈值设置是否过严。

我遇到比较多的情况是召回阈值设得太高。公关团队看的是“跟品牌相关的所有内容”，所以我把线上召回阈值调整为：粗排阶段阈值设为0.55，保证召回；重排阶段再由GPT打分筛掉不相关项。粗排只负责“别漏”，精排才负责“精准”。

另一种情况是舆情事件的语义跟查询词有偏移。比如用户输入“充电安全问题”，但实际事件的表达是“半夜起火”。这时候应该换一种策略：不是靠一次Embedding查询，而是先用规则把事件类型候选集圈出来，再在候选集内做向量排序。检索和规则是互补关系，不是替代关系。

5.2 采集链路突然掉线：网页结构变更

网页改版是采集系统最常见的事故。新闻站点每隔几个月就会调整一次DOM结构，哪怕只是改一个class名字，旧的XPath就失效了。我上线的第一天就遇到这种情况，表现为某个源连续两小时零新增，但采集任务显示成功。

排查时发现解析器把正文提取成了空字符串。原因是页面改版后，正文外层容器class从article-content改成了article_body。我当时没有监控“单源新增量”这个指标，所以故障延迟了两小时才发现。

此后我给每个解析器加了“最小有效解析长度”的校验：如果解析出的正文长度低于50个字符，就认为解析失败，触发告警并暂停该源的采集，避免产出大量脏数据。运维同学看到告警后去更新XPath规则，比写任何自动修复脚本都靠谱。

5.3 GPT分析结果不稳定：同一批数据两次结果不同

大模型本身有随机性，两次调用同一个Prompt，输出可能不同。如果用于展示和报告，这种不确定就让人很头疼。我做了三件事：把温度参数调到0.1，降低随机性；把输入文本拼接顺序固定，避免内容顺序影响判断；关键字段判断用“投票法”，同一条文本重复分析3次，取多数结论。

如果对某个结论的置信度始终低于阈值，我保留现场数据并做人工复核。这里想强调的是：GPT-5.2分析结果再强，也不能完全替代人工。系统优化目标是让人从“看每条数据”变成“只审核高危和低置信度数据”，而不是完全甩手。

5.4 报告数据滞后：分析链路卡在哪一步

用户反馈大屏数据比实际时间晚一个小时，第一反应都是去看采集器是否停摆，但大部分时候采集没问题，卡点反而是向量化和分析环节。

向量化慢的原因通常是Embedding接口限流，进程在等待重试。分析慢的原因则往往是大语言模型单批处理耗时太长，加上排队。我的排查方法是给每条消息打上时间戳，记录每个节点入队和出队时间，然后把链路耗时拆出来对比。最后发现瓶颈在GPT分析的并发数太低，从3路加到10路之后，端到端延迟从40分钟降到了8分钟。

5.5 磁盘告警：向量索引膨胀过快

系统上线三个月后，向量库磁盘占用比预估的多了50%。排查发现是HNSW索引的M参数当初为了追求召回设成了32，索引体积显著增大。还有一个原因是删除数据时用的是软删除，向量文件里堆积了大量标记删除但未物理清理的旧数据。

处理办法是调整M回16，跑了一次优化和清理任务，磁盘占用立刻降了约30%。这类参数在部署前一定要做压力测试，不能想当然。如果模棱两可，保守设置永远比激进设置更适合生产环境。

写在最后的一点体会

这套系统从搭建到稳定运行，我最大的感受是：舆情监控工程的重点不在某一个单点上，而在链路协同。只把向量检索调好，采集断了就没有数据；只把采集做好，分析不准就会天天误报；只把GPT Prompt写漂亮，前面数据质量太差照样是垃圾进垃圾出。每一个环节都要为下一个环节负责，这可能是系统工程最朴素也最容易被忽略的道理。

如果团队当前资源有限，我建议先砍掉可视化大屏，优先做好“采集-清洗-告警”这条最短闭环。一条紧急告警加一篇AI生成的摘要，比任何酷炫大屏都能救企业于水火。等这条链路稳定了，再逐步加上语义检索、自动报告和历史趋势分析，系统就会越用越顺手。最后再提一句，合规是一切的前提，采集边界和数据处理范围务必在项目启动前就想清楚，后期返工的代价远比你想象中大。